From b7d2cf7c817b86e705b97f72c6be192a6760a14f Mon Sep 17 00:00:00 2001 From: Etienne Carriere Date: Thu, 28 Oct 2021 16:00:08 +0200 Subject: dt-bindings: arm: Add OP-TEE transport for SCMI Introduce compatible "linaro,scmi-optee" for SCMI transport channel based on an OP-TEE service invocation. The compatible mandates a channel ID defined with property "linaro,optee-channel-id". Link: https://lore.kernel.org/r/20211028140009.23331-1-etienne.carriere@linaro.org Cc: devicetree@vger.kernel.org Cc: Rob Herring Reviewed-by: Rob Herring Reviewed-by: Cristian Marussi Signed-off-by: Etienne Carriere Signed-off-by: Sudeep Holla --- .../devicetree/bindings/firmware/arm,scmi.yaml | 65 ++++++++++++++++++++++ 1 file changed, 65 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index 5c4c6782e052..eae15df36eef 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -38,6 +38,9 @@ properties: The virtio transport only supports a single device. items: - const: arm,scmi-virtio + - description: SCMI compliant firmware with OP-TEE transport + items: + - const: linaro,scmi-optee interrupts: description: @@ -83,6 +86,11 @@ properties: description: SMC id required when using smc or hvc transports + linaro,optee-channel-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Channel specifier required when using OP-TEE transport. + protocol@11: type: object properties: @@ -195,6 +203,12 @@ patternProperties: minItems: 1 maxItems: 2 + linaro,optee-channel-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Channel specifier required when using OP-TEE transport and + protocol has a dedicated communication channel. + required: - reg @@ -226,6 +240,16 @@ else: - arm,smc-id - shmem + else: + if: + properties: + compatible: + contains: + const: linaro,scmi-optee + then: + required: + - linaro,optee-channel-id + examples: - | firmware { @@ -340,7 +364,48 @@ examples: reg = <0x11>; #power-domain-cells = <1>; }; + }; + }; + + - | + firmware { + scmi { + compatible = "linaro,scmi-optee"; + linaro,optee-channel-id = <0>; + + #address-cells = <1>; + #size-cells = <0>; + + scmi_dvfs1: protocol@13 { + reg = <0x13>; + linaro,optee-channel-id = <1>; + shmem = <&cpu_optee_lpri0>; + #clock-cells = <1>; + }; + + scmi_clk0: protocol@14 { + reg = <0x14>; + #clock-cells = <1>; + }; + }; + }; + soc { + #address-cells = <2>; + #size-cells = <2>; + + sram@51000000 { + compatible = "mmio-sram"; + reg = <0x0 0x51000000 0x0 0x10000>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x0 0x51000000 0x10000>; + + cpu_optee_lpri0: optee-sram-section@0 { + compatible = "arm,scmi-shmem"; + reg = <0x0 0x80>; + }; }; }; -- cgit From f2165301c3cc2ee70b5c2ac9be4d0e3c76aa0985 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Mon, 13 Dec 2021 14:36:23 +0100 Subject: dt-bindings: display: bridge: sn65dsi83: Make enable GPIO optional The SN65DSI8x EN signal may be tied to VCC, or otherwise controlled by means not available to the kernel. Make the GPIO optional. Signed-off-by: Laurent Pinchart Acked-by: Rob Herring Signed-off-by: Alexander Stein Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20211213133626.2498056-2-alexander.stein@ew.tq-group.com --- Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index b446d0f0f1b4..c3f3e73f740a 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -91,7 +91,6 @@ properties: required: - compatible - reg - - enable-gpios - ports allOf: -- cgit From e6ba217381955587cb18b9f32d29b75f03550846 Mon Sep 17 00:00:00 2001 From: Alexander Stein Date: Mon, 13 Dec 2021 14:36:25 +0100 Subject: dt-bindings: drm/bridge: ti-sn65dsi83: Add vcc supply bindings Add a VCC regulator which needs to be enabled before the EN pin is released. Reviewed-by: Sam Ravnborg Acked-by: Rob Herring Reviewed-by: Jagan Teki Signed-off-by: Alexander Stein Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20211213133626.2498056-4-alexander.stein@ew.tq-group.com --- Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index c3f3e73f740a..48a97bb3e2e0 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -32,6 +32,9 @@ properties: maxItems: 1 description: GPIO specifier for bridge_en pin (active high). + vcc-supply: + description: A 1.8V power supply (see regulator/regulator.yaml). + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -132,6 +135,7 @@ examples: reg = <0x2d>; enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>; + vcc-supply = <®_sn65dsi83_1v8>; ports { #address-cells = <1>; -- cgit From 0f299473c1b1c5cc85a7b3e70a7241a2ea6cc277 Mon Sep 17 00:00:00 2001 From: José Expósito Date: Fri, 7 Jan 2022 19:28:09 +0100 Subject: drm/vkms: drop "Multiple overlay planes" TODO MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Remove the task from the TODO list. Signed-off-by: José Expósito Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20220107182809.141003-3-jose.exposito89@gmail.com --- Documentation/gpu/vkms.rst | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 941f0e7e5eef..9c873c3912cc 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -124,8 +124,6 @@ Add Plane Features There's lots of plane features we could add support for: -- Multiple overlay planes. [Good to get started] - - Clearing primary plane: clear primary plane before plane composition (at the start) for correctness of pixel blend ops. It also guarantees alpha channel is cleared in the target buffer for stable crc. [Good to get started] -- cgit From fc32ca1ea6f74c1be7abf9d21b0bac8bce11bec3 Mon Sep 17 00:00:00 2001 From: Xianwei Zhao Date: Tue, 21 Dec 2021 11:00:14 +0800 Subject: dt-bindings: arm: amlogic: add S4 based AQ222 bindings Add bindings for the new Amlogic S4 SoC family, and add binds the compatible for the Amlogic S4 Based AQ222 board. S4 is an application processor designed for hybrid OTT/IP Set To Box(STB) and high-end media box applications, with quad core Cortex-A35. Signed-off-by: Xianwei Zhao Acked-by: Rob Herring Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20211221030014.434-1-xianwei.zhao@amlogic.com --- Documentation/devicetree/bindings/arm/amlogic.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 36081734f720..31df120d73b0 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -183,6 +183,12 @@ properties: - amlogic,ad401 - const: amlogic,a1 + - description: Boards with the Amlogic Meson S4 S805X2 SoC + items: + - enum: + - amlogic,aq222 + - const: amlogic,s4 + additionalProperties: true ... -- cgit From 77b6f79df66ed2919dedb834edea630f40079f12 Mon Sep 17 00:00:00 2001 From: John Harrison Date: Thu, 6 Jan 2022 16:06:21 -0800 Subject: drm/i915/guc: Update to GuC version 69.0.3 Update to the latest GuC release. The latest GuC firmware introduces a number of interface changes: GuC may return NO_RESPONSE_RETRY message for requests sent over CTB. Add support for this reply and try resending the request again as a new CTB message. A KLV (key-length-value) mechanism is now used for passing configuration data such as CTB management. With the new KLV scheme, the old CTB management actions are no longer used and are removed. Register capture on hang is now supported by GuC. Full i915 support for this will be added by a later patch. A minimum support of providing capture memory and register lists is required though, so add that in. The device id of the current platform needs to be provided at init time. The 'poll CS' w/a (Wa_22012773006) was blanket enabled by previous versions of GuC. It must now be explicitly requested by the KMD. So, add in the code to turn it on when relevant. The GuC log entry format has changed. This requires adding a new field to the log header structure to mark the wrap point at the end of the buffer (as the buffer size is no longer a multiple of the log entry size). New CTB notification messages are now sent for some things that were previously only sent via MMIO notifications. Of these, the crash dump notification was not really being handled by i915. It called the log flush code but that only flushed the regular debug log and then only if relay logging was enabled. So just report an error message instead. The 'exception' notification was just being ignored completely. So add an error message for that as well. Note that in either the crash dump or the exception case, the GuC is basically dead. The KMD will detect this via the heartbeat and trigger both an error log (which will include the crash dump as part of the GuC log) and a GT reset. So no other processing is really required. Signed-off-by: John Harrison Signed-off-by: Michal Wajdeczko Reviewed-by: Matthew Brost Link: https://patchwork.freedesktop.org/patch/msgid/20220107000622.292081-3-John.C.Harrison@Intel.com --- Documentation/gpu/i915.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index b7d801993bfa..bcaefc952764 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -539,6 +539,7 @@ GuC ABI .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h HuC --- -- cgit From d1f5a6d9d02e3e1dd91379e642f5bc4133f5cf2b Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Tue, 11 Jan 2022 21:27:14 +0100 Subject: drm/doc: overview before functions for drm_writeback.c Otherwise it's really hard to link to that, which I realized when I wanted to link to the property definitions for a question on irc. Fix it. Reviewed-by: Laurent Pinchart Fixes: e2d7fc20b3e2 ("drm/writeback: wire drm_writeback.h to kernel-doc") Cc: Sam Ravnborg Cc: Daniel Vetter Cc: Laurent Pinchart Cc: Brian Starkey Cc: Liviu Dudau Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220111202714.1128406-1-daniel.vetter@ffwll.ch --- Documentation/gpu/drm-kms.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index d14bf1c35d7e..6f9c064fd323 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -423,12 +423,12 @@ Connector Functions Reference Writeback Connectors -------------------- -.. kernel-doc:: include/drm/drm_writeback.h - :internal: - .. kernel-doc:: drivers/gpu/drm/drm_writeback.c :doc: overview +.. kernel-doc:: include/drm/drm_writeback.h + :internal: + .. kernel-doc:: drivers/gpu/drm/drm_writeback.c :export: -- cgit From d2ecf5ae59c8eef9fe2ad20d83977c2889646d4c Mon Sep 17 00:00:00 2001 From: Christian Hewitt Date: Wed, 12 Jan 2022 02:27:06 +0000 Subject: dt-bindings: arm: amlogic: add X96-AIR bindings Add board bindings for the Amediatech X96-AIR STB which ships with model variants distiguished by Ethernet configuration: models using an external Gigabit PHY have a -gbit suffix, while models using an internal 10/100 PHY have no suffix. Signed-off-by: Christian Hewitt Acked-by: Rob Herring Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20220112022713.25962-3-christianshewitt@gmail.com --- Documentation/devicetree/bindings/arm/amlogic.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 31df120d73b0..b5b995941d3b 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -170,6 +170,8 @@ properties: - description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC items: - enum: + - amediatech,x96-air + - amediatech,x96-air-gbit - bananapi,bpi-m5 - hardkernel,odroid-c4 - hardkernel,odroid-hc4 -- cgit From 3dbabb9ac746ab01c71aa019c58a2e0cc6eafe1c Mon Sep 17 00:00:00 2001 From: Christian Hewitt Date: Wed, 12 Jan 2022 02:27:08 +0000 Subject: dt-bindings: vendor-prefixes: add cyx prefix Shenzhen CYX Industrial Co., Ltd are a manufacturer of Android Set-Top Box devices. Signed-off-by: Christian Hewitt Acked-by: Rob Herring Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20220112022713.25962-5-christianshewitt@gmail.com --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 66d6432fd781..f1b4afb2876a 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -279,6 +279,8 @@ patternProperties: description: CUI Devices "^cypress,.*": description: Cypress Semiconductor Corporation + "^cyx,.*": + description: Shenzhen CYX Industrial Co., Ltd "^cznic,.*": description: CZ.NIC, z.s.p.o. "^dallas,.*": -- cgit From bc7811bd4e884bbc21cc7b7031cb7c297662db9c Mon Sep 17 00:00:00 2001 From: Christian Hewitt Date: Wed, 12 Jan 2022 02:27:09 +0000 Subject: dt-bindings: arm: amlogic: add A95XF3-AIR bindings Add board bindings for the CYX A95XF3-AIR set-top box which ships with model variants distinguished by Ethernet configuration: models using external Gigabit PHY have a -gbit suffix, while models using an internal 10/100 PHY have no suffix. Signed-off-by: Christian Hewitt Acked-by: Rob Herring Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20220112022713.25962-6-christianshewitt@gmail.com --- Documentation/devicetree/bindings/arm/amlogic.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index b5b995941d3b..2027ce81a834 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -173,6 +173,8 @@ properties: - amediatech,x96-air - amediatech,x96-air-gbit - bananapi,bpi-m5 + - cyx,a95xf3-air + - cyx,a95xf3-air-gbit - hardkernel,odroid-c4 - hardkernel,odroid-hc4 - khadas,vim3l -- cgit From bf510ace20ac153946d6d0ab6305dd8aa52eec6c Mon Sep 17 00:00:00 2001 From: Christian Hewitt Date: Wed, 12 Jan 2022 02:27:11 +0000 Subject: dt-bindings: vendor-prefixes: add haochuangyi prefix Shenzhen Haochuangyi Technology Co.,Ltd are a manufacturer of Android Set-Top Box devices. Signed-off-by: Christian Hewitt Acked-by: Rob Herring Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20220112022713.25962-8-christianshewitt@gmail.com --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index f1b4afb2876a..52ff63248892 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -483,6 +483,8 @@ patternProperties: deprecated: true "^hannstar,.*": description: HannStar Display Corporation + "^haochuangyi,.*": + description: Shenzhen Haochuangyi Technology Co.,Ltd "^haoyu,.*": description: Haoyu Microelectronic Co. Ltd. "^hardkernel,.*": -- cgit From 2ca889b1201625d36efcd51d25371d937a6a0b8f Mon Sep 17 00:00:00 2001 From: Christian Hewitt Date: Wed, 12 Jan 2022 02:27:12 +0000 Subject: dt-bindings: arm: amlogic: add H96-Max bindings Add the board binding for the Haochuangyi H96-Max STB device. Signed-off-by: Christian Hewitt Acked-by: Rob Herring Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20220112022713.25962-9-christianshewitt@gmail.com --- Documentation/devicetree/bindings/arm/amlogic.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 2027ce81a834..a073a959232c 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -177,6 +177,7 @@ properties: - cyx,a95xf3-air-gbit - hardkernel,odroid-c4 - hardkernel,odroid-hc4 + - haochuangyi,h96-max - khadas,vim3l - seirobotics,sei610 - const: amlogic,sm1 -- cgit From 8de223b94b8471b8f9b8cae6279e6fc08564ee67 Mon Sep 17 00:00:00 2001 From: José Expósito Date: Fri, 7 Jan 2022 19:02:30 +0100 Subject: drm/doc: Fix TTM acronym MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The TTM acronym is defined for the first time in the documentation as "Translation Table Maps". Afterwards, "Translation Table Manager" is used as definition. Fix the first definition to avoid confusion. Signed-off-by: José Expósito Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220107180230.132666-1-jose.exposito89@gmail.com --- Documentation/gpu/drm-mm.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index e0538083a2c0..198bcc1affa1 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -8,7 +8,7 @@ the very dynamic nature of many of that data, managing graphics memory efficiently is thus crucial for the graphics stack and plays a central role in the DRM infrastructure. -The DRM core includes two memory managers, namely Translation Table Maps +The DRM core includes two memory managers, namely Translation Table Manager (TTM) and Graphics Execution Manager (GEM). TTM was the first DRM memory manager to be developed and tried to be a one-size-fits-them all solution. It provides a single userspace API to accommodate the need of -- cgit From 52506b099e1baa204b56b170f40f680ffcabb4c1 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Wed, 22 Dec 2021 09:28:22 +0100 Subject: drm: Provide PCI module-init macros Provide helper macros to register PCI-based DRM drivers. The new macros behave like module_pci_driver() with an additional test if DRM modesetting has been enabled. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Signed-off-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-2-javierm@redhat.com --- Documentation/gpu/drm-internals.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 607f78f0f189..38afed24a75c 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -75,6 +75,12 @@ update it, its value is mostly useless. The DRM core prints it to the kernel log at initialization time and passes it to userspace through the DRM_IOCTL_VERSION ioctl. +Module Initialization +--------------------- + +.. kernel-doc:: include/drm/drm_module.h + :doc: overview + Managing Ownership of the Framebuffer Aperture ---------------------------------------------- -- cgit From 96c85308eed9a31a53a0f4f2bd6a85bb88776e93 Mon Sep 17 00:00:00 2001 From: Andrii Nakryiko Date: Wed, 19 Jan 2022 22:05:29 -0800 Subject: docs/bpf: update BPF map definition example Use BTF-defined map definition in the documentation example. Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20220120060529.1890907-5-andrii@kernel.org Signed-off-by: Alexei Starovoitov --- Documentation/bpf/btf.rst | 32 ++++++++++++++------------------ 1 file changed, 14 insertions(+), 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst index 1ebf4c5c7ddc..ab08852e53ae 100644 --- a/Documentation/bpf/btf.rst +++ b/Documentation/bpf/btf.rst @@ -565,18 +565,15 @@ A map can be created with ``btf_fd`` and specified key/value type id.:: In libbpf, the map can be defined with extra annotation like below: :: - struct bpf_map_def SEC("maps") btf_map = { - .type = BPF_MAP_TYPE_ARRAY, - .key_size = sizeof(int), - .value_size = sizeof(struct ipv_counts), - .max_entries = 4, - }; - BPF_ANNOTATE_KV_PAIR(btf_map, int, struct ipv_counts); + struct { + __uint(type, BPF_MAP_TYPE_ARRAY); + __type(key, int); + __type(value, struct ipv_counts); + __uint(max_entries, 4); + } btf_map SEC(".maps"); -Here, the parameters for macro BPF_ANNOTATE_KV_PAIR are map name, key and -value types for the map. During ELF parsing, libbpf is able to extract -key/value type_id's and assign them to BPF_MAP_CREATE attributes -automatically. +During ELF parsing, libbpf is able to extract key/value type_id's and assign +them to BPF_MAP_CREATE attributes automatically. .. _BPF_Prog_Load: @@ -824,13 +821,12 @@ structure has bitfields. For example, for the following map,:: ___A b1:4; enum A b2:4; }; - struct bpf_map_def SEC("maps") tmpmap = { - .type = BPF_MAP_TYPE_ARRAY, - .key_size = sizeof(__u32), - .value_size = sizeof(struct tmp_t), - .max_entries = 1, - }; - BPF_ANNOTATE_KV_PAIR(tmpmap, int, struct tmp_t); + struct { + __uint(type, BPF_MAP_TYPE_ARRAY); + __type(key, int); + __type(value, struct tmp_t); + __uint(max_entries, 1); + } tmpmap SEC(".maps"); bpftool is able to pretty print like below: :: -- cgit From f9eceeca3623fbce35aaa748d04b9b622a58c356 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Thu, 20 Jan 2022 12:36:47 +0100 Subject: drm: Update docs after moving DisplayPort helpers around DRM's DisplayPort helpers moved into the subdirectory dp/. Change the documentation accordingly. Signed-off-by: Thomas Zimmermann Fixes: adb9d5a2cc77 ("drm/dp: Move DisplayPort helpers into separate helper module") Acked-by: Daniel Vetter Reported-by: Jani Nikula Tested-by: Jani Nikula Cc: Thomas Zimmermann Cc: Lyude Paul Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220120113647.22484-1-tzimmermann@suse.de --- Documentation/gpu/drm-kms-helpers.rst | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 5bb55ec1b9b5..c3ce91eecbc1 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -232,34 +232,34 @@ HDCP Helper Functions Reference Display Port Helper Functions Reference ======================================= -.. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp.c :doc: dp helpers -.. kernel-doc:: include/drm/drm_dp_helper.h +.. kernel-doc:: include/drm/dp/drm_dp_helper.h :internal: -.. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp.c :export: Display Port CEC Helper Functions Reference =========================================== -.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_cec.c :doc: dp cec helpers -.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_cec.c :export: Display Port Dual Mode Adaptor Helper Functions Reference ========================================================= -.. kernel-doc:: drivers/gpu/drm/drm_dp_dual_mode_helper.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_dual_mode_helper.c :doc: dp dual mode helpers -.. kernel-doc:: include/drm/drm_dp_dual_mode_helper.h +.. kernel-doc:: include/drm/dp/drm_dp_dual_mode_helper.h :internal: -.. kernel-doc:: drivers/gpu/drm/drm_dp_dual_mode_helper.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_dual_mode_helper.c :export: Display Port MST Helpers @@ -268,19 +268,19 @@ Display Port MST Helpers Overview -------- -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c :doc: dp mst helper -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c :doc: Branch device and port refcounting Functions Reference ------------------- -.. kernel-doc:: include/drm/drm_dp_mst_helper.h +.. kernel-doc:: include/drm/dp/drm_dp_mst_helper.h :internal: -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c :export: Topology Lifetime Internals @@ -289,7 +289,7 @@ Topology Lifetime Internals These functions aren't exported to drivers, but are documented here to help make the MST topology helpers easier to understand -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c :functions: drm_dp_mst_topology_try_get_mstb drm_dp_mst_topology_get_mstb drm_dp_mst_topology_put_mstb drm_dp_mst_topology_try_get_port drm_dp_mst_topology_get_port -- cgit From af030d83da1dc0d750d7bcc88d57dd1cae5f6b61 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 11 Jan 2022 21:17:18 +0100 Subject: dt-bindings: pinctrl: samsung: convert to dtschema Convert the Samsung SoC (S3C24xx, S3C64xx, S5Pv210, Exynos) pin controller bindings to DT schema format. Parts of description and DTS example was copied from existing sources, so keep the license as GPL-2.0-only. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sam Protsenko Reviewed-by: Rob Herring Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20220111201722.327219-18-krzysztof.kozlowski@canonical.com --- .../pinctrl/samsung,pinctrl-gpio-bank.yaml | 52 +++ .../bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml | 81 +++++ .../pinctrl/samsung,pinctrl-wakeup-interrupt.yaml | 85 +++++ .../bindings/pinctrl/samsung,pinctrl.yaml | 392 +++++++++++++++++++++ .../bindings/pinctrl/samsung-pinctrl.txt | 383 -------------------- 5 files changed, 610 insertions(+), 383 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-gpio-bank.yaml create mode 100644 Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml create mode 100644 Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml create mode 100644 Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml delete mode 100644 Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-gpio-bank.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-gpio-bank.yaml new file mode 100644 index 000000000000..f73348c54748 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-gpio-bank.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/samsung,pinctrl-gpio-bank.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C/S5P/Exynos SoC pin controller - gpio bank + +maintainers: + - Krzysztof Kozlowski + - Sylwester Nawrocki + - Tomasz Figa + +description: | + This is a part of device tree bindings for Samsung S3C/S5P/Exynos SoC pin + controller. + + GPIO bank description for Samsung S3C/S5P/Exynos SoC pin controller. + + See also Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml for + additional information and example. + +properties: + '#gpio-cells': + const: 2 + + gpio-controller: true + + '#interrupt-cells': + description: + For GPIO banks supporting external GPIO interrupts or external wake-up + interrupts. + const: 2 + + interrupt-controller: + description: + For GPIO banks supporting external GPIO interrupts or external wake-up + interrupts. + + interrupts: + description: + For GPIO banks supporting direct external wake-up interrupts (without + multiplexing). Number of interrupts must match number of wake-up capable + pins of this bank. + minItems: 1 + maxItems: 8 + +required: + - '#gpio-cells' + - gpio-controller + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml new file mode 100644 index 000000000000..c71939ac8b63 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/samsung,pinctrl-pins-cfg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C/S5P/Exynos SoC pin controller - pins configuration + +maintainers: + - Krzysztof Kozlowski + - Sylwester Nawrocki + - Tomasz Figa + +description: | + This is a part of device tree bindings for Samsung S3C/S5P/Exynos SoC pin + controller. + + Pins configuration for Samsung S3C/S5P/Exynos SoC pin controller. + + The values used for config properties should be derived from the hardware + manual and these values are programmed as-is into the pin pull up/down and + driver strength register of the pin-controller. + See also include/dt-bindings/pinctrl/samsung.h with useful constants. + + See also Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml for + additional information and example. + +properties: + samsung,pins: + description: | + List of pins to configure. For initial and sleep states, the maximum + number is one pin. In other cases there is no upper limit. + + The pins should use lowercase names matching hardware manual, e.g. for + GPA0 bank: gpa0-0, gpa0-1, gpa0-2. + $ref: /schemas/types.yaml#/definitions/string-array + + samsung,pin-function: + description: | + The pin function selection that should be applied on the pins listed in the + child node is specified using the "samsung,pin-function" property. The value + of this property that should be applied to each of the pins listed in the + "samsung,pins" property should be picked from the hardware manual of the SoC + for the specified pin group. This property is optional in the child node if + no specific function selection is desired for the pins listed in the child + node. The value of this property is used as-is to program the pin-controller + function selector register of the pin-bank. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + + samsung,pin-drv: + description: Drive strength configuration. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + + samsung,pin-pud: + description: Pull up/down configuration. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + samsung,pin-val: + description: Initial value of pin output buffer. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + + samsung,pin-con-pdn: + description: Function in power down mode. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + samsung,pin-pud-pdn: + description: Pull up/down configuration in power down mode. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + +required: + - samsung,pins + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml new file mode 100644 index 000000000000..6b684a53119b --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C/S5P/Exynos SoC pin controller - wake-up interrupt controller + +maintainers: + - Krzysztof Kozlowski + - Sylwester Nawrocki + - Tomasz Figa + +description: | + This is a part of device tree bindings for Samsung S3C/S5P/Exynos SoC pin + controller. + + External wake-up interrupts for Samsung S3C/S5P/Exynos SoC pin controller. + Only one pin-controller device node can include external wake-up interrupts + child node (in other words, only one External wake-up interrupts + pin-controller is supported). + + See also Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml for + additional information and example. + +properties: + compatible: + enum: + - samsung,s3c2410-wakeup-eint + - samsung,s3c2412-wakeup-eint + - samsung,s3c64xx-wakeup-eint + - samsung,s5pv210-wakeup-eint + - samsung,exynos4210-wakeup-eint + - samsung,exynos7-wakeup-eint + + interrupts: + description: + Interrupt used by multiplexed external wake-up interrupts. + minItems: 1 + maxItems: 6 + +required: + - compatible + - interrupts + +allOf: + - if: + properties: + compatible: + contains: + enum: + - samsung,s3c2410-wakeup-eint + - samsung,s3c2412-wakeup-eint + then: + properties: + interrupts: + minItems: 6 + maxItems: 6 + + - if: + properties: + compatible: + contains: + const: samsung,s3c64xx-wakeup-eint + then: + properties: + interrupts: + minItems: 4 + maxItems: 4 + + - if: + properties: + compatible: + contains: + enum: + - samsung,s5pv210-wakeup-eint + - samsung,exynos4210-wakeup-eint + - samsung,exynos7-wakeup-eint + then: + properties: + interrupts: + minItems: 1 + maxItems: 1 + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml new file mode 100644 index 000000000000..28f0851d07bb --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml @@ -0,0 +1,392 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/samsung,pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C/S5P/Exynos SoC pin controller + +maintainers: + - Krzysztof Kozlowski + - Sylwester Nawrocki + - Tomasz Figa + +description: | + This is a part of device tree bindings for Samsung S3C/S5P/Exynos SoC pin + controller. + + Pin group settings (like drive strength, pull up/down) are available as + macros in include/dt-bindings/pinctrl/samsung.h. + + All the pin controller nodes should be represented in the aliases node using + the following format 'pinctrl{n}' where n is a unique number for the alias. + + The controller supports three types of interrupts:: + - External GPIO interrupts (see interrupts property in pin controller node); + + - External wake-up interrupts - multiplexed (capable of waking up the system + see interrupts property in external wake-up interrupt controller node - + samsung,pinctrl-wakeup-interrupt.yaml); + + - External wake-up interrupts - direct (capable of waking up the system, see + interrupts property in every bank of pin controller with external wake-up + interrupt controller - samsung,pinctrl-gpio-bank.yaml). + +properties: + $nodename: + pattern: "^pinctrl(@.*)?" + + compatible: + enum: + - samsung,s3c2412-pinctrl + - samsung,s3c2416-pinctrl + - samsung,s3c2440-pinctrl + - samsung,s3c2450-pinctrl + - samsung,s3c64xx-pinctrl + - samsung,s5pv210-pinctrl + - samsung,exynos3250-pinctrl + - samsung,exynos4210-pinctrl + - samsung,exynos4x12-pinctrl + - samsung,exynos5250-pinctrl + - samsung,exynos5260-pinctrl + - samsung,exynos5410-pinctrl + - samsung,exynos5420-pinctrl + - samsung,exynos5433-pinctrl + - samsung,exynos7-pinctrl + - samsung,exynos7885-pinctrl + - samsung,exynos850-pinctrl + - samsung,exynosautov9-pinctrl + + interrupts: + description: + Required for GPIO banks supporting external GPIO interrupts. + maxItems: 1 + + power-domains: + maxItems: 1 + + reg: + description: + Second base address of the pin controller if the specific registers of + the pin controller are separated into the different base address. + Only certain banks of certain pin controller might need it. + minItems: 1 + maxItems: 2 + + wakeup-interrupt-controller: + $ref: samsung,pinctrl-wakeup-interrupt.yaml + +patternProperties: + "^[a-z]+[0-9]*-gpio-bank$": + description: + Pin banks of the controller are represented by child nodes of the + controller node. Bank name is taken from name of the node. + $ref: samsung,pinctrl-gpio-bank.yaml + + "^[a-z0-9-]+-pins$": + oneOf: + - $ref: samsung,pinctrl-pins-cfg.yaml + required: + - samsung,pins + - type: object + patternProperties: + "^[a-z0-9-]+-pins$": + $ref: samsung,pinctrl-pins-cfg.yaml + + additionalProperties: false + + "^(initial|sleep)-state$": + patternProperties: + "^(pin-[a-z0-9-]+|[a-z0-9-]+-pin)$": + $ref: samsung,pinctrl-pins-cfg.yaml + + properties: + samsung,pins: + description: See samsung,pinctrl-pins-cfg.yaml + $ref: /schemas/types.yaml#/definitions/string-array + maxItems: 1 + + required: + - samsung,pins + + unevaluatedProperties: false + +required: + - compatible + - reg + +allOf: + - $ref: "pinctrl.yaml#" + - if: + properties: + compatible: + contains: + const: samsung,exynos5433-pinctrl + then: + properties: + reg: + minItems: 1 + maxItems: 2 + else: + properties: + reg: + minItems: 1 + maxItems: 1 + +additionalProperties: false + +examples: + - | + #include + + pinctrl@7f008000 { + compatible = "samsung,s3c64xx-pinctrl"; + reg = <0x7f008000 0x1000>; + interrupt-parent = <&vic1>; + interrupts = <21>; + + wakeup-interrupt-controller { + compatible = "samsung,s3c64xx-wakeup-eint"; + interrupts-extended = <&vic0 0>, + <&vic0 1>, + <&vic1 0>, + <&vic1 1>; + }; + + /* Pin bank with external GPIO or muxed external wake-up interrupts */ + gpa-gpio-bank { + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + // ... + + uart0-data-pins { + samsung,pins = "gpa-0", "gpa-1"; + samsung,pin-function = ; + samsung,pin-pud = ; + }; + + // ... + }; + + - | + #include + #include + + pinctrl@11400000 { + compatible = "samsung,exynos4210-pinctrl"; + reg = <0x11400000 0x1000>; + interrupts = ; + + pinctrl-names = "default"; + pinctrl-0 = <&sleep0>; + + /* Pin bank with external GPIO or muxed external wake-up interrupts */ + gpa0-gpio-bank { + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + // ... + + uart0-data-pins { + samsung,pins = "gpa0-0", "gpa0-1"; + samsung,pin-function = ; + samsung,pin-pud = ; + samsung,pin-drv = ; + }; + + // ... + + sleep0: sleep-state { + gpa0-0-pin { + samsung,pins = "gpa0-0"; + samsung,pin-con-pdn = ; + samsung,pin-pud-pdn = ; + }; + + gpa0-1-pin { + samsung,pins = "gpa0-1"; + samsung,pin-con-pdn = ; + samsung,pin-pud-pdn = ; + }; + + // ... + }; + }; + + - | + #include + #include + + pinctrl@11000000 { + compatible = "samsung,exynos4210-pinctrl"; + reg = <0x11000000 0x1000>; + interrupts = ; + + wakeup-interrupt-controller { + compatible = "samsung,exynos4210-wakeup-eint"; + interrupt-parent = <&gic>; + interrupts = ; + }; + + /* Pin bank with external GPIO or muxed external wake-up interrupts */ + gpj0-gpio-bank { + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + /* Pin bank without external interrupts */ + gpy0-gpio-bank { + gpio-controller; + #gpio-cells = <2>; + }; + + /* Pin bank with external direct wake-up interrupts */ + gpx0-gpio-bank { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + interrupt-parent = <&gic>; + interrupts = , + , + , + , + , + , + , + ; + #interrupt-cells = <2>; + }; + + // ... + + sd0-clk-pins { + samsung,pins = "gpk0-0"; + samsung,pin-function = ; + samsung,pin-pud = ; + samsung,pin-drv = ; + }; + + sd4-bus-width8-pins { + part-1-pins { + samsung,pins = "gpk0-3", "gpk0-4", + "gpk0-5", "gpk0-6"; + samsung,pin-function = ; + samsung,pin-pud = ; + samsung,pin-drv = ; + }; + + part-2-pins { + samsung,pins = "gpk1-3", "gpk1-4", + "gpk1-5", "gpk1-6"; + samsung,pin-function = ; + samsung,pin-pud = ; + samsung,pin-drv = ; + }; + }; + + // ... + + otg-gp-pins { + samsung,pins = "gpx3-3"; + samsung,pin-function = ; + samsung,pin-pud = ; + samsung,pin-drv = ; + samsung,pin-val = <0>; + }; + }; + + - | + #include + #include + + pinctrl@10580000 { + compatible = "samsung,exynos5433-pinctrl"; + reg = <0x10580000 0x1a20>, <0x11090000 0x100>; + + pinctrl-names = "default"; + pinctrl-0 = <&initial_alive>; + + wakeup-interrupt-controller { + compatible = "samsung,exynos7-wakeup-eint"; + interrupts = ; + }; + + /* Pin bank with external direct wake-up interrupts */ + gpa0-gpio-bank { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + interrupt-parent = <&gic>; + interrupts = , + , + , + , + , + , + , + ; + #interrupt-cells = <2>; + }; + + // ... + + te-irq-pins { + samsung,pins = "gpf1-3"; + samsung,pin-function = <0xf>; + }; + + // .. + + initial_alive: initial-state { + gpa0-0-pin { + samsung,pins = "gpa0-0"; + samsung,pin-function = ; + samsung,pin-pud = ; + samsung,pin-drv = ; + }; + + // ... + }; + }; + + - | + #include + #include + + pinctrl@114b0000 { + compatible = "samsung,exynos5433-pinctrl"; + reg = <0x114b0000 0x1000>; + interrupts = ; + power-domains = <&pd_aud>; + + /* Pin bank with external GPIO or muxed external wake-up interrupts */ + gpz0-gpio-bank { + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + // ... + + i2s0-bus-pins { + samsung,pins = "gpz0-0", "gpz0-1", "gpz0-2", "gpz0-3", + "gpz0-4", "gpz0-5", "gpz0-6"; + samsung,pin-function = ; + samsung,pin-pud = ; + samsung,pin-drv = ; + }; + + // ... + }; diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt deleted file mode 100644 index 9e70edceb21b..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ /dev/null @@ -1,383 +0,0 @@ -Samsung GPIO and Pin Mux/Config controller - -Samsung's ARM based SoC's integrates a GPIO and Pin mux/config hardware -controller. It controls the input/output settings on the available pads/pins -and also provides ability to multiplex and configure the output of various -on-chip controllers onto these pads. - -Required Properties: -- compatible: should be one of the following. - - "samsung,s3c2412-pinctrl": for S3C2412-compatible pin-controller, - - "samsung,s3c2416-pinctrl": for S3C2416-compatible pin-controller, - - "samsung,s3c2440-pinctrl": for S3C2440-compatible pin-controller, - - "samsung,s3c2450-pinctrl": for S3C2450-compatible pin-controller, - - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller, - - "samsung,s5pv210-pinctrl": for S5PV210-compatible pin-controller, - - "samsung,exynos3250-pinctrl": for Exynos3250 compatible pin-controller. - - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller. - - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller. - - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller. - - "samsung,exynos5260-pinctrl": for Exynos5260 compatible pin-controller. - - "samsung,exynos5410-pinctrl": for Exynos5410 compatible pin-controller. - - "samsung,exynos5420-pinctrl": for Exynos5420 compatible pin-controller. - - "samsung,exynos5433-pinctrl": for Exynos5433 compatible pin-controller. - - "samsung,exynos7-pinctrl": for Exynos7 compatible pin-controller. - - "samsung,exynos7885-pinctrl": for Exynos7885 compatible pin-controller. - - "samsung,exynos850-pinctrl": for Exynos850 compatible pin-controller. - - "samsung,exynosautov9-pinctrl": for ExynosAutov9 compatible pin-controller. - -- reg: Base address of the pin controller hardware module and length of - the address space it occupies. - - - reg: Second base address of the pin controller if the specific registers - of the pin controller are separated into the different base address. - - Eg: GPF[1-5] of Exynos5433 are separated into the two base address. - - First base address is for GPAx and GPF[1-5] external interrupt - registers. - - Second base address is for GPF[1-5] pinctrl registers. - - pinctrl_0: pinctrl@10580000 { - compatible = "samsung,exynos5433-pinctrl"; - reg = <0x10580000 0x1a20>, <0x11090000 0x100>; - - wakeup-interrupt-controller { - compatible = "samsung,exynos7-wakeup-eint"; - interrupts = <0 16 0>; - }; - }; - -- Pin banks as child nodes: Pin banks of the controller are represented by child - nodes of the controller node. Bank name is taken from name of the node. Each - bank node must contain following properties: - - - gpio-controller: identifies the node as a gpio controller and pin bank. - - #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO - binding is used, the amount of cells must be specified as 2. See the below - mentioned gpio binding representation for description of particular cells. - - Eg: <&gpx2 6 0> - <[phandle of the gpio controller node] - [pin number within the gpio controller] - [flags]> - - Values for gpio specifier: - - Pin number: is a value between 0 to 7. - - Flags: 0 - Active High - 1 - Active Low - -- Pin mux/config groups as child nodes: The pin mux (selecting pin function - mode) and pin config (pull up/down, driver strength) settings are represented - as child nodes of the pin-controller node. There should be at least one - child node and there is no limit on the count of these child nodes. It is - also possible for a child node to consist of several further child nodes - to allow grouping multiple pinctrl groups into one. The format of second - level child nodes is exactly the same as for first level ones and is - described below. - - The child node should contain a list of pin(s) on which a particular pin - function selection or pin configuration (or both) have to applied. This - list of pins is specified using the property name "samsung,pins". There - should be at least one pin specified for this property and there is no upper - limit on the count of pins that can be specified. The pins are specified - using pin names which are derived from the hardware manual of the SoC. As - an example, the pins in GPA0 bank of the pin controller can be represented - as "gpa0-0", "gpa0-1", "gpa0-2" and so on. The names should be in lower case. - The format of the pin names should be (as per the hardware manual) - "[pin bank name]-[pin number within the bank]". - - The pin function selection that should be applied on the pins listed in the - child node is specified using the "samsung,pin-function" property. The value - of this property that should be applied to each of the pins listed in the - "samsung,pins" property should be picked from the hardware manual of the SoC - for the specified pin group. This property is optional in the child node if - no specific function selection is desired for the pins listed in the child - node. The value of this property is used as-is to program the pin-controller - function selector register of the pin-bank. - - The child node can also optionally specify one or more of the pin - configuration that should be applied on all the pins listed in the - "samsung,pins" property of the child node. The following pin configuration - properties are supported. - - - samsung,pin-val: Initial value of pin output buffer. - - samsung,pin-pud: Pull up/down configuration. - - samsung,pin-drv: Drive strength configuration. - - samsung,pin-pud-pdn: Pull up/down configuration in power down mode. - - samsung,pin-drv-pdn: Drive strength configuration in power down mode. - - The values specified by these config properties should be derived from the - hardware manual and these values are programmed as-is into the pin - pull up/down and driver strength register of the pin-controller. - - Note: A child should include at least a pin function selection property or - pin configuration property (one or more) or both. - - The client nodes that require a particular pin function selection and/or - pin configuration should use the bindings listed in the "pinctrl-bindings.txt" - file. - -External GPIO and Wakeup Interrupts: - -The controller supports two types of external interrupts over gpio. The first -is the external gpio interrupt and second is the external wakeup interrupts. -The difference between the two is that the external wakeup interrupts can be -used as system wakeup events. - -A. External GPIO Interrupts: For supporting external gpio interrupts, the - following properties should be specified in the pin-controller device node. - - - interrupts: interrupt specifier for the controller. The format and value of - the interrupt specifier depends on the interrupt parent for the controller. - - In addition, following properties must be present in node of every bank - of pins supporting GPIO interrupts: - - - interrupt-controller: identifies the controller node as interrupt-parent. - - #interrupt-cells: the value of this property should be 2. - - First Cell: represents the external gpio interrupt number local to the - external gpio interrupt space of the controller. - - Second Cell: flags to identify the type of the interrupt - - 1 = rising edge triggered - - 2 = falling edge triggered - - 3 = rising and falling edge triggered - - 4 = high level triggered - - 8 = low level triggered - -B. External Wakeup Interrupts: For supporting external wakeup interrupts, a - child node representing the external wakeup interrupt controller should be - included in the pin-controller device node. - - Only one pin-controller device node can include external wakeup interrupts - child node (in other words, only one External Wakeup Interrupts - pin-controller is supported). - - This child node should include following properties: - - - compatible: identifies the type of the external wakeup interrupt controller - The possible values are: - - samsung,s3c2410-wakeup-eint: represents wakeup interrupt controller - found on Samsung S3C24xx SoCs except S3C2412 and S3C2413, - - samsung,s3c2412-wakeup-eint: represents wakeup interrupt controller - found on Samsung S3C2412 and S3C2413 SoCs, - - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller - found on Samsung S3C64xx SoCs, - - samsung,s5pv210-wakeup-eint: represents wakeup interrupt controller - found on Samsung S5Pv210 SoCs, - - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller - found on Samsung Exynos4210 and S5PC110/S5PV210 SoCs. - - samsung,exynos7-wakeup-eint: represents wakeup interrupt controller - found on Samsung Exynos7 SoC. - - interrupts: interrupt used by multiplexed wakeup interrupts. - - In addition, following properties must be present in node of every bank - of pins supporting wake-up interrupts: - - - interrupt-controller: identifies the node as interrupt-parent. - - #interrupt-cells: the value of this property should be 2 - - First Cell: represents the external wakeup interrupt number local to - the external wakeup interrupt space of the controller. - - Second Cell: flags to identify the type of the interrupt - - 1 = rising edge triggered - - 2 = falling edge triggered - - 3 = rising and falling edge triggered - - 4 = high level triggered - - 8 = low level triggered - - Node of every bank of pins supporting direct wake-up interrupts (without - multiplexing) must contain following properties: - - - interrupts: interrupts of the interrupt parent which are used for external - wakeup interrupts from pins of the bank, must contain interrupts for all - pins of the bank. - -Aliases: - -All the pin controller nodes should be represented in the aliases node using -the following format 'pinctrl{n}' where n is a unique number for the alias. - -Aliases for controllers compatible with "samsung,exynos7-pinctrl": -- pinctrl0: pin controller of ALIVE block, -- pinctrl1: pin controller of BUS0 block, -- pinctrl2: pin controller of NFC block, -- pinctrl3: pin controller of TOUCH block, -- pinctrl4: pin controller of FF block, -- pinctrl5: pin controller of ESE block, -- pinctrl6: pin controller of FSYS0 block, -- pinctrl7: pin controller of FSYS1 block, -- pinctrl8: pin controller of BUS1 block, -- pinctrl9: pin controller of AUDIO block, - -Example: A pin-controller node with pin banks: - - pinctrl_0: pinctrl@11400000 { - compatible = "samsung,exynos4210-pinctrl"; - reg = <0x11400000 0x1000>; - interrupts = <0 47 0>; - - /* ... */ - - /* Pin bank without external interrupts */ - gpy0: gpy0 { - gpio-controller; - #gpio-cells = <2>; - }; - - /* ... */ - - /* Pin bank with external GPIO or muxed wake-up interrupts */ - gpj0: gpj0 { - gpio-controller; - #gpio-cells = <2>; - - interrupt-controller; - #interrupt-cells = <2>; - }; - - /* ... */ - - /* Pin bank with external direct wake-up interrupts */ - gpx0: gpx0 { - gpio-controller; - #gpio-cells = <2>; - - interrupt-controller; - interrupt-parent = <&gic>; - interrupts = <0 16 0>, <0 17 0>, <0 18 0>, <0 19 0>, - <0 20 0>, <0 21 0>, <0 22 0>, <0 23 0>; - #interrupt-cells = <2>; - }; - - /* ... */ - }; - -Example 1: A pin-controller node with pin groups. - - #include - - pinctrl_0: pinctrl@11400000 { - compatible = "samsung,exynos4210-pinctrl"; - reg = <0x11400000 0x1000>; - interrupts = <0 47 0>; - - /* ... */ - - uart0_data: uart0-data { - samsung,pins = "gpa0-0", "gpa0-1"; - samsung,pin-function = ; - samsung,pin-pud = ; - samsung,pin-drv = ; - }; - - uart0_fctl: uart0-fctl { - samsung,pins = "gpa0-2", "gpa0-3"; - samsung,pin-function = ; - samsung,pin-pud = ; - samsung,pin-drv = ; - }; - - uart1_data: uart1-data { - samsung,pins = "gpa0-4", "gpa0-5"; - samsung,pin-function = ; - samsung,pin-pud = ; - samsung,pin-drv = ; - }; - - uart1_fctl: uart1-fctl { - samsung,pins = "gpa0-6", "gpa0-7"; - samsung,pin-function = ; - samsung,pin-pud = ; - samsung,pin-drv = ; - }; - - i2c2_bus: i2c2-bus { - samsung,pins = "gpa0-6", "gpa0-7"; - samsung,pin-function = ; - samsung,pin-pud = ; - samsung,pin-drv = ; - }; - - sd4_bus8: sd4-bus-width8 { - part-1 { - samsung,pins = "gpk0-3", "gpk0-4", - "gpk0-5", "gpk0-6"; - samsung,pin-function = ; - samsung,pin-pud = ; - samsung,pin-drv = ; - }; - part-2 { - samsung,pins = "gpk1-3", "gpk1-4", - "gpk1-5", "gpk1-6"; - samsung,pin-function = ; - samsung,pin-pud = ; - samsung,pin-drv = ; - }; - }; - }; - -Example 2: A pin-controller node with external wakeup interrupt controller node. - - pinctrl_1: pinctrl@11000000 { - compatible = "samsung,exynos4210-pinctrl"; - reg = <0x11000000 0x1000>; - interrupts = <0 46 0> - - /* ... */ - - wakeup-interrupt-controller { - compatible = "samsung,exynos4210-wakeup-eint"; - interrupt-parent = <&gic>; - interrupts = <0 32 0>; - }; - }; - -Example 3: A uart client node that supports 'default' and 'flow-control' states. - - uart@13800000 { - compatible = "samsung,exynos4210-uart"; - reg = <0x13800000 0x100>; - interrupts = <0 52 0>; - pinctrl-names = "default", "flow-control; - pinctrl-0 = <&uart0_data>; - pinctrl-1 = <&uart0_data>, <&uart0_fctl>; - }; - -Example 4: Set up the default pin state for uart controller. - - static int s3c24xx_serial_probe(struct platform_device *pdev) { - struct pinctrl *pinctrl; - - /* ... */ - - pinctrl = devm_pinctrl_get_select_default(&pdev->dev); - } - -Example 5: A display port client node that supports 'default' pinctrl state - and gpio binding. - - display-port-controller { - /* ... */ - - samsung,hpd-gpio = <&gpx2 6 0>; - pinctrl-names = "default"; - pinctrl-0 = <&dp_hpd>; - }; - -Example 6: Request the gpio for display port controller - - static int exynos_dp_probe(struct platform_device *pdev) - { - int hpd_gpio, ret; - struct device *dev = &pdev->dev; - struct device_node *dp_node = dev->of_node; - - /* ... */ - - hpd_gpio = of_get_named_gpio(dp_node, "samsung,hpd-gpio", 0); - - /* ... */ - - ret = devm_gpio_request_one(&pdev->dev, hpd_gpio, GPIOF_IN, - "hpd_gpio"); - /* ... */ - } -- cgit From 1755e227c21636ade047dc9b920f647c1d53b4e9 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 11 Jan 2022 21:17:19 +0100 Subject: dt-bindings: pinctrl: samsung: describe Exynos850 and ExynosAutov9 wake-ups Older Samsung Exynos SoCs (Exynos3250, Exynos4, Exynos5, Exynos5433) expected pin controller node with external wake-up interrupts to have one interrupt for multiplexing these wake-up interrupts. Also they expected to have exactly one such pin controller (capable of external wake-up interrupts). It seems however that newer ARMv8 Exynos SoCs like Exynos850 and ExynosAutov9 have differences of their pin controllers capable of external wake-up interrupts: 1. No multiplexed external wake-up interrupt, only direct, 2. More than one pin controller capable of external wake-up interrupts. Add dedicated Exynos850 and ExynosAutov9 compatibles. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sam Protsenko Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220111201722.327219-19-krzysztof.kozlowski@canonical.com --- .../pinctrl/samsung,pinctrl-wakeup-interrupt.yaml | 27 +++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml index 6b684a53119b..a822f70f5702 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml @@ -16,9 +16,12 @@ description: | controller. External wake-up interrupts for Samsung S3C/S5P/Exynos SoC pin controller. - Only one pin-controller device node can include external wake-up interrupts - child node (in other words, only one External wake-up interrupts + For S3C24xx, S3C64xx, S5PV210 and Exynos4210 compatible wake-up interrupt + controllers, only one pin-controller device node can include external wake-up + interrupts child node (in other words, only one External wake-up interrupts pin-controller is supported). + For newer controllers, multiple pin-controller device node can include + external wake-up interrupts child node. See also Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml for additional information and example. @@ -32,6 +35,8 @@ properties: - samsung,s5pv210-wakeup-eint - samsung,exynos4210-wakeup-eint - samsung,exynos7-wakeup-eint + - samsung,exynos850-wakeup-eint + - samsung,exynosautov9-wakeup-eint interrupts: description: @@ -41,7 +46,6 @@ properties: required: - compatible - - interrupts allOf: - if: @@ -56,6 +60,8 @@ allOf: interrupts: minItems: 6 maxItems: 6 + required: + - interrupts - if: properties: @@ -67,6 +73,8 @@ allOf: interrupts: minItems: 4 maxItems: 4 + required: + - interrupts - if: properties: @@ -81,5 +89,18 @@ allOf: interrupts: minItems: 1 maxItems: 1 + required: + - interrupts + + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos850-wakeup-eint + - samsung,exynosautov9-wakeup-eint + then: + properties: + interrupts: false additionalProperties: false -- cgit From 93f2ec9e401276fb4ea9903194a5bfcf175f9a2c Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 16 Dec 2021 12:16:27 +0100 Subject: dt-bindings: mtd: nand-controller: Fix the reg property description The reg property of a NAND device always references the chip-selects. The ready/busy lines are described in the nand-rb property. I believe this was a harmless copy/paste error during the conversion to yaml. Fixes: 212e49693592 ("dt-bindings: mtd: Add YAML schemas for the generic NAND options") Signed-off-by: Miquel Raynal Acked-by: Rob Herring Link: https://lore.kernel.org/linux-mtd/20211216111654.238086-2-miquel.raynal@bootlin.com --- Documentation/devicetree/bindings/mtd/nand-controller.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index bd217e6f5018..811f03978fc6 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -55,7 +55,7 @@ patternProperties: properties: reg: description: - Contains the native Ready/Busy IDs. + Contains the chip-select IDs. nand-ecc-engine: allOf: -- cgit From 0e7f1b557974ce297e5e4c9d4245720fbb489886 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 16 Dec 2021 12:16:28 +0100 Subject: dt-bindings: mtd: nand-controller: Fix a comment in the examples The controller properties should be in the controller 'parent' node, while properties in the children nodes are specific to the NAND *chip*. This error was already present during the yaml conversion. Fixes: 2d472aba15ff ("mtd: nand: document the NAND controller/NAND chip DT representation") Signed-off-by: Miquel Raynal Acked-by: Rob Herring Link: https://lore.kernel.org/linux-mtd/20211216111654.238086-3-miquel.raynal@bootlin.com --- Documentation/devicetree/bindings/mtd/nand-controller.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index 811f03978fc6..5cd144a9ec99 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -184,7 +184,7 @@ examples: nand-use-soft-ecc-engine; nand-ecc-algo = "bch"; - /* controller specific properties */ + /* NAND chip specific properties */ }; nand@1 { -- cgit From f0dcb5bd56ee7cf7fcca123d5df51b201d1c9e9b Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 16 Dec 2021 12:16:29 +0100 Subject: dt-bindings: mtd: nand-controller: Harmonize the property types Harmonize the different properties in this file by: * dropping the non-necessary allOf's * always defining the keywords in the following order: - first the "description" (when relevant), - then the "type"/"$ref" and the other generic keywords ("enum", "default", etc). Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/linux-mtd/20211216111654.238086-4-miquel.raynal@bootlin.com --- .../devicetree/bindings/mtd/nand-controller.yaml | 26 ++++++++++------------ 1 file changed, 12 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index 5cd144a9ec99..a4fa65e872a5 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -39,8 +39,6 @@ properties: ranges: true cs-gpios: - minItems: 1 - maxItems: 8 description: Array of chip-select available to the controller. The first entries are a 1:1 mapping of the available chip-select on the @@ -48,6 +46,8 @@ properties: chip-select as needed may follow and should be phandles of GPIO lines. 'reg' entries of the NAND chip subnodes become indexes of this array when this property is present. + minItems: 1 + maxItems: 8 patternProperties: "^nand@[a-f0-9]$": @@ -58,8 +58,6 @@ patternProperties: Contains the chip-select IDs. nand-ecc-engine: - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle description: | A phandle on the hardware ECC engine if any. There are basically three possibilities: @@ -69,24 +67,24 @@ patternProperties: case the phandle should reference the node itself. 3/ The ECC engine is external, in this case the phandle should reference the specific ECC engine node. + $ref: /schemas/types.yaml#/definitions/phandle nand-use-soft-ecc-engine: - type: boolean description: Use a software ECC engine. + type: boolean nand-no-ecc-engine: - type: boolean description: Do not use any ECC correction. + type: boolean nand-ecc-placement: - allOf: - - $ref: /schemas/types.yaml#/definitions/string - - enum: [ oob, interleaved ] description: Location of the ECC bytes. This location is unknown by default but can be explicitly set to "oob", if all ECC bytes are known to be stored in the OOB area, or "interleaved" if ECC bytes will be interleaved with regular data in the main area. + $ref: /schemas/types.yaml#/definitions/string + enum: [ oob, interleaved ] nand-ecc-algo: description: @@ -102,7 +100,6 @@ patternProperties: default: 8 nand-on-flash-bbt: - $ref: /schemas/types.yaml#/definitions/flag description: With this property, the OS will search the device for a Bad Block Table (BBT). If not found, it will create one, reserve @@ -111,6 +108,7 @@ patternProperties: few pages of all the blocks will be scanned at boot time to find Bad Block Markers (BBM). These markers will help to build a volatile BBT in RAM. + $ref: /schemas/types.yaml#/definitions/flag nand-ecc-strength: description: @@ -125,7 +123,6 @@ patternProperties: minimum: 1 nand-ecc-maximize: - $ref: /schemas/types.yaml#/definitions/flag description: Whether or not the ECC strength should be maximized. The maximum ECC strength is both controller and chip @@ -134,18 +131,19 @@ patternProperties: constraint into account. This is particularly useful when only the in-band area is used by the upper layers, and you want to make your NAND as reliable as possible. + $ref: /schemas/types.yaml#/definitions/flag nand-is-boot-medium: - $ref: /schemas/types.yaml#/definitions/flag description: Whether or not the NAND chip is a boot medium. Drivers might use this information to select ECC algorithms supported by the boot ROM or similar restrictions. + $ref: /schemas/types.yaml#/definitions/flag nand-rb: - $ref: /schemas/types.yaml#/definitions/uint32-array description: Contains the native Ready/Busy IDs. + $ref: /schemas/types.yaml#/definitions/uint32-array rb-gpios: description: @@ -155,11 +153,11 @@ patternProperties: should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted. secure-regions: - $ref: /schemas/types.yaml#/definitions/uint64-matrix description: Regions in the NAND chip which are protected using a secure element like Trustzone. This property contains the start address and size of the secure regions present. + $ref: /schemas/types.yaml#/definitions/uint64-matrix required: - reg -- cgit From 751f204a6fe6fd4a856315071c7cc9d8cf9e504d Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 16 Dec 2021 12:16:30 +0100 Subject: dt-bindings: mtd: nand-chip: Create a NAND chip description Move the NAND chip description out of the NAND controller file. Indeed, a subsequent part of the properties supported by a raw NAND chip are also supported by SPI-NAND chips. So let's create a generic NAND chip description which will be pulled by nand-controller.yaml and later by spi-nand.yaml as well. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/linux-mtd/20211216111654.238086-5-miquel.raynal@bootlin.com --- .../devicetree/bindings/mtd/nand-chip.yaml | 70 ++++++++++++++++++++++ .../devicetree/bindings/mtd/nand-controller.yaml | 50 +--------------- 2 files changed, 72 insertions(+), 48 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/nand-chip.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/nand-chip.yaml b/Documentation/devicetree/bindings/mtd/nand-chip.yaml new file mode 100644 index 000000000000..97ac3a3fbb52 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/nand-chip.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/nand-chip.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NAND Chip and NAND Controller Generic Binding + +maintainers: + - Miquel Raynal + +description: | + This file covers the generic description of a NAND chip. It implies that the + bus interface should not be taken into account: both raw NAND devices and + SPI-NAND devices are concerned by this description. + +properties: + reg: + description: + Contains the chip-select IDs. + + nand-ecc-engine: + description: | + A phandle on the hardware ECC engine if any. There are + basically three possibilities: + 1/ The ECC engine is part of the NAND controller, in this + case the phandle should reference the parent node. + 2/ The ECC engine is part of the NAND part (on-die), in this + case the phandle should reference the node itself. + 3/ The ECC engine is external, in this case the phandle should + reference the specific ECC engine node. + $ref: /schemas/types.yaml#/definitions/phandle + + nand-use-soft-ecc-engine: + description: Use a software ECC engine. + type: boolean + + nand-no-ecc-engine: + description: Do not use any ECC correction. + type: boolean + + nand-ecc-algo: + description: + Desired ECC algorithm. + $ref: /schemas/types.yaml#/definitions/string + enum: [hamming, bch, rs] + + nand-ecc-strength: + description: + Maximum number of bits that can be corrected per ECC step. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + + nand-ecc-step-size: + description: + Number of data bytes covered by a single ECC step. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + + secure-regions: + description: + Regions in the NAND chip which are protected using a secure element + like Trustzone. This property contains the start address and size of + the secure regions present. + $ref: /schemas/types.yaml#/definitions/uint64-matrix + +required: + - reg + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index a4fa65e872a5..33855eb48a79 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -52,31 +52,13 @@ properties: patternProperties: "^nand@[a-f0-9]$": type: object + $ref: "nand-chip.yaml#" + properties: reg: description: Contains the chip-select IDs. - nand-ecc-engine: - description: | - A phandle on the hardware ECC engine if any. There are - basically three possibilities: - 1/ The ECC engine is part of the NAND controller, in this - case the phandle should reference the parent node. - 2/ The ECC engine is part of the NAND part (on-die), in this - case the phandle should reference the node itself. - 3/ The ECC engine is external, in this case the phandle should - reference the specific ECC engine node. - $ref: /schemas/types.yaml#/definitions/phandle - - nand-use-soft-ecc-engine: - description: Use a software ECC engine. - type: boolean - - nand-no-ecc-engine: - description: Do not use any ECC correction. - type: boolean - nand-ecc-placement: description: Location of the ECC bytes. This location is unknown by default @@ -86,12 +68,6 @@ patternProperties: $ref: /schemas/types.yaml#/definitions/string enum: [ oob, interleaved ] - nand-ecc-algo: - description: - Desired ECC algorithm. - $ref: /schemas/types.yaml#/definitions/string - enum: [hamming, bch, rs] - nand-bus-width: description: Bus width to the NAND chip @@ -110,18 +86,6 @@ patternProperties: build a volatile BBT in RAM. $ref: /schemas/types.yaml#/definitions/flag - nand-ecc-strength: - description: - Maximum number of bits that can be corrected per ECC step. - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 1 - - nand-ecc-step-size: - description: - Number of data bytes covered by a single ECC step. - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 1 - nand-ecc-maximize: description: Whether or not the ECC strength should be maximized. The @@ -152,13 +116,6 @@ patternProperties: Ready/Busy pins. Active state refers to the NAND ready state and should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted. - secure-regions: - description: - Regions in the NAND chip which are protected using a secure element - like Trustzone. This property contains the start address and size of - the secure regions present. - $ref: /schemas/types.yaml#/definitions/uint64-matrix - required: - reg @@ -179,9 +136,6 @@ examples: nand@0 { reg = <0>; /* Native CS */ - nand-use-soft-ecc-engine; - nand-ecc-algo = "bch"; - /* NAND chip specific properties */ }; -- cgit From 3a0d6d0fb14df501c90b629c04d2c8c60615b3f3 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 16 Dec 2021 12:16:31 +0100 Subject: dt-bindings: mtd: spi-nand: Convert spi-nand description file to yaml Let's get rid of spi-nand.txt by converting it to yaml schema. While at converting this file, let's actually pull all the generic properties from nand-chip.yaml which might apply to a SPI-NAND chip. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/linux-mtd/20211216111654.238086-6-miquel.raynal@bootlin.com --- Documentation/devicetree/bindings/mtd/spi-nand.txt | 5 ---- .../devicetree/bindings/mtd/spi-nand.yaml | 27 ++++++++++++++++++++++ 2 files changed, 27 insertions(+), 5 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mtd/spi-nand.txt create mode 100644 Documentation/devicetree/bindings/mtd/spi-nand.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt b/Documentation/devicetree/bindings/mtd/spi-nand.txt deleted file mode 100644 index 8b51f3b6d55c..000000000000 --- a/Documentation/devicetree/bindings/mtd/spi-nand.txt +++ /dev/null @@ -1,5 +0,0 @@ -SPI NAND flash - -Required properties: -- compatible: should be "spi-nand" -- reg: should encode the chip-select line used to access the NAND chip diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.yaml b/Documentation/devicetree/bindings/mtd/spi-nand.yaml new file mode 100644 index 000000000000..431faac518a4 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/spi-nand.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/spi-nand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SPI-NAND flash device tree bindings + +maintainers: + - Miquel Raynal + +allOf: + - $ref: "nand-chip.yaml#" + +properties: + compatible: + const: spi-nand + + reg: + description: Encode the chip-select line on the SPI bus + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false -- cgit From 390925f60a4bbcf32fa15f819fd6ec123dd26844 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 16 Dec 2021 12:16:32 +0100 Subject: dt-bindings: vendor-prefixes: Clarify Macronix prefix When looking at compatible prefixes, Macronix is sometimes referred as "mxicy": - mxicy,mx25r1635f - mxicy,mx25u6435f - mxicy,mx25v8035f - mxicy,mx25f0a-spi and sometimes as "mxic": - mxic,multi-itfc-v009-nand-controller - mxic,enable-randomizer-otp The oldest prefix that is also the one preferred by Macronix engineers is "mxicy", so document the other one and mark it deprecated. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/linux-mtd/20211216111654.238086-7-miquel.raynal@bootlin.com --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 294093d45a23..a8ef035152d0 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -802,6 +802,9 @@ patternProperties: description: Mundo Reader S.L. "^murata,.*": description: Murata Manufacturing Co., Ltd. + "^mxic,.*": + description: Macronix International Co., Ltd. + deprecated: true "^mxicy,.*": description: Macronix International Co., Ltd. "^myir,.*": -- cgit From 90c204d3195a795f77f5bce767e311dd1c59ca17 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 16 Dec 2021 12:16:33 +0100 Subject: dt-bindings: spi: mxic: The interrupt property is not mandatory The interrupt property is not mandatory at all, this property should not be part of the required properties list, so move it into the optional properties list. Fixes: 326e5c8d4a87 ("dt-binding: spi: Document Macronix controller bindings") Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Reviewed-by: Mark Brown Link: https://lore.kernel.org/linux-mtd/20211216111654.238086-8-miquel.raynal@bootlin.com --- Documentation/devicetree/bindings/spi/spi-mxic.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-mxic.txt b/Documentation/devicetree/bindings/spi/spi-mxic.txt index 529f2dab2648..7bcbb229b78b 100644 --- a/Documentation/devicetree/bindings/spi/spi-mxic.txt +++ b/Documentation/devicetree/bindings/spi/spi-mxic.txt @@ -8,11 +8,13 @@ Required properties: - reg: should contain 2 entries, one for the registers and one for the direct mapping area - reg-names: should contain "regs" and "dirmap" -- interrupts: interrupt line connected to the SPI controller - clock-names: should contain "ps_clk", "send_clk" and "send_dly_clk" - clocks: should contain 3 entries for the "ps_clk", "send_clk" and "send_dly_clk" clocks +Optional properties: +- interrupts: interrupt line connected to the SPI controller + Example: spi@43c30000 { -- cgit From 295fca79a8ee8e140f61e1b00e2cd21bf0fd9464 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 16 Dec 2021 12:16:34 +0100 Subject: dt-bindings: spi: mxic: Convert to yaml Straightforward conversion from regular text to yaml schema of the Macronix SPI controller DT bindings. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Reviewed-by: Mark Brown Link: https://lore.kernel.org/linux-mtd/20211216111654.238086-9-miquel.raynal@bootlin.com --- .../devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml | 60 ++++++++++++++++++++++ Documentation/devicetree/bindings/spi/spi-mxic.txt | 36 ------------- 2 files changed, 60 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml delete mode 100644 Documentation/devicetree/bindings/spi/spi-mxic.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml new file mode 100644 index 000000000000..f20d100b4a68 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/mxicy,mx25f0a-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Macronix SPI controller device tree bindings + +maintainers: + - Miquel Raynal + +allOf: + - $ref: "spi-controller.yaml#" + +properties: + compatible: + const: mxicy,mx25f0a-spi + + reg: + minItems: 2 + maxItems: 2 + + reg-names: + items: + - const: regs + - const: dirmap + + interrupts: + maxItems: 1 + + clocks: + minItems: 3 + maxItems: 3 + + clock-names: + items: + - const: send_clk + - const: send_dly_clk + - const: ps_clk + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + spi@43c30000 { + compatible = "mxicy,mx25f0a-spi"; + reg = <0x43c30000 0x10000>, <0xa0000000 0x20000000>; + reg-names = "regs", "dirmap"; + clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 18>; + clock-names = "send_clk", "send_dly_clk", "ps_clk"; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-mxic.txt b/Documentation/devicetree/bindings/spi/spi-mxic.txt deleted file mode 100644 index 7bcbb229b78b..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-mxic.txt +++ /dev/null @@ -1,36 +0,0 @@ -Macronix SPI controller Device Tree Bindings --------------------------------------------- - -Required properties: -- compatible: should be "mxicy,mx25f0a-spi" -- #address-cells: should be 1 -- #size-cells: should be 0 -- reg: should contain 2 entries, one for the registers and one for the direct - mapping area -- reg-names: should contain "regs" and "dirmap" -- clock-names: should contain "ps_clk", "send_clk" and "send_dly_clk" -- clocks: should contain 3 entries for the "ps_clk", "send_clk" and - "send_dly_clk" clocks - -Optional properties: -- interrupts: interrupt line connected to the SPI controller - -Example: - - spi@43c30000 { - compatible = "mxicy,mx25f0a-spi"; - reg = <0x43c30000 0x10000>, <0xa0000000 0x20000000>; - reg-names = "regs", "dirmap"; - clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 18>; - clock-names = "send_clk", "send_dly_clk", "ps_clk"; - #address-cells = <1>; - #size-cells = <0>; - - flash@0 { - compatible = "jedec,spi-nor"; - reg = <0>; - spi-max-frequency = <25000000>; - spi-tx-bus-width = <4>; - spi-rx-bus-width = <4>; - }; - }; -- cgit From 475e826bad8c7b65d4157259c9906fcf86834f14 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 16 Dec 2021 12:16:35 +0100 Subject: dt-bindings: spi: mxic: Document the nand-ecc-engine property This SPI controller supports interacting with an external ECC engine. The nand-ecc-engine property already exist in the NAND world but also applies to SPI controller nodes which have external correction capabilities like Macronix's. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Reviewed-by: Mark Brown Link: https://lore.kernel.org/linux-mtd/20211216111654.238086-10-miquel.raynal@bootlin.com --- Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml index f20d100b4a68..9202c44b4478 100644 --- a/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml +++ b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml @@ -38,6 +38,11 @@ properties: - const: send_dly_clk - const: ps_clk + nand-ecc-engine: + description: NAND ECC engine used by the SPI controller in order to perform + on-the-fly correction when using a SPI-NAND memory. + $ref: /schemas/types.yaml#/definitions/phandle + required: - compatible - reg -- cgit From 3e2bcda631d4e612a8cd69613a15fae2f9941857 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 16 Dec 2021 12:16:36 +0100 Subject: dt-bindings: mtd: Describe Macronix NAND ECC engine Describe Macronix NAND ECC engine. This engine may be used as an external engine or can be pipelined with either a raw NAND controller or a SPI controller. Both hardware designs with a SPI controller are shown in the examples. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/linux-mtd/20211216111654.238086-11-miquel.raynal@bootlin.com --- .../bindings/mtd/mxicy,nand-ecc-engine.yaml | 77 ++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml b/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml new file mode 100644 index 000000000000..804479999ccb --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/mxicy,nand-ecc-engine.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Macronix NAND ECC engine device tree bindings + +maintainers: + - Miquel Raynal + +properties: + compatible: + const: mxicy,nand-ecc-engine-rev3 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + /* External configuration */ + spi_controller0: spi@43c30000 { + compatible = "mxicy,mx25f0a-spi"; + reg = <0x43c30000 0x10000>, <0xa0000000 0x4000000>; + reg-names = "regs", "dirmap"; + clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 15>; + clock-names = "send_clk", "send_dly_clk", "ps_clk"; + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + compatible = "spi-nand"; + reg = <0>; + nand-ecc-engine = <&ecc_engine0>; + }; + }; + + ecc_engine0: ecc@43c40000 { + compatible = "mxicy,nand-ecc-engine-rev3"; + reg = <0x43c40000 0x10000>; + }; + + - | + /* Pipelined configuration */ + spi_controller1: spi@43c30000 { + compatible = "mxicy,mx25f0a-spi"; + reg = <0x43c30000 0x10000>, <0xa0000000 0x4000000>; + reg-names = "regs", "dirmap"; + clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 15>; + clock-names = "send_clk", "send_dly_clk", "ps_clk"; + #address-cells = <1>; + #size-cells = <0>; + nand-ecc-engine = <&ecc_engine1>; + + flash@0 { + compatible = "spi-nand"; + reg = <0>; + nand-ecc-engine = <&spi_controller1>; + }; + }; + + ecc_engine1: ecc@43c40000 { + compatible = "mxicy,nand-ecc-engine-rev3"; + reg = <0x43c40000 0x10000>; + }; -- cgit From 7dbb47d64acf4aac131a2aaade726913aa62abe7 Mon Sep 17 00:00:00 2001 From: Peter Geis Date: Wed, 15 Dec 2021 16:02:45 -0500 Subject: dt-bindings: soc: rockchip: add rk3568-usb2phy-grf Add the documentation for the rk3568-usb2phy-grf node, which is separate from the usb2phy node on this chip. Signed-off-by: Peter Geis Acked-by: Rob Herring Link: https://lore.kernel.org/r/20211215210252.120923-2-pgwipeout@gmail.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index dfebf425ca49..b2ba7bed89b2 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -15,6 +15,7 @@ properties: - items: - enum: - rockchip,rk3288-sgrf + - rockchip,rk3568-usb2phy-grf - rockchip,rv1108-usbgrf - const: syscon - items: -- cgit From 066aef69079415b3c873c7fee1c1022c511c4045 Mon Sep 17 00:00:00 2001 From: Stanislav Jakubek Date: Sun, 9 Jan 2022 18:03:21 +0100 Subject: dt-bindings: serial: Convert rda,8810pl-uart to YAML Convert RDA Micro UART bindings to DT schema format. Signed-off-by: Stanislav Jakubek Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220109170321.GA12989@standask-GA-A55M-S2HP --- .../devicetree/bindings/serial/rda,8810pl-uart.txt | 17 -------- .../bindings/serial/rda,8810pl-uart.yaml | 46 ++++++++++++++++++++++ 2 files changed, 46 insertions(+), 17 deletions(-) delete mode 100644 Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt create mode 100644 Documentation/devicetree/bindings/serial/rda,8810pl-uart.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt b/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt deleted file mode 100644 index a08df97a69e6..000000000000 --- a/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt +++ /dev/null @@ -1,17 +0,0 @@ -RDA Micro UART - -Required properties: -- compatible : "rda,8810pl-uart" for RDA8810PL SoCs. -- reg : Offset and length of the register set for the device. -- interrupts : Should contain UART interrupt. -- clocks : Phandle to the input clock. - - -Example: - - uart2: serial@20a90000 { - compatible = "rda,8810pl-uart"; - reg = <0x20a90000 0x1000>; - interrupts = <11 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&uart_clk>; - }; diff --git a/Documentation/devicetree/bindings/serial/rda,8810pl-uart.yaml b/Documentation/devicetree/bindings/serial/rda,8810pl-uart.yaml new file mode 100644 index 000000000000..5f4ed8221270 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/rda,8810pl-uart.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/rda,8810pl-uart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RDA Micro UART Interface + +maintainers: + - Manivannan Sadhasivam + +allOf: + - $ref: serial.yaml# + +properties: + compatible: + const: rda,8810pl-uart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + #include + + uart3: serial@20a90000 { + compatible = "rda,8810pl-uart"; + reg = <0x20a90000 0x1000>; + interrupts = <11 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&uart_clk>; + }; +... -- cgit From 92649241a25aff95d3132c2a90292c19c887071d Mon Sep 17 00:00:00 2001 From: David Heidelberg Date: Sun, 9 Jan 2022 18:18:13 +0100 Subject: dt-bindings: msm/mdp4: convert to yaml format Convert mdp4 binding into yaml format. Signed-off-by: David Heidelberg Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220109171814.16103-1-david@ixit.cz --- .../devicetree/bindings/display/msm/mdp4.txt | 114 ------------------- .../devicetree/bindings/display/msm/mdp4.yaml | 124 +++++++++++++++++++++ 2 files changed, 124 insertions(+), 114 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/msm/mdp4.txt create mode 100644 Documentation/devicetree/bindings/display/msm/mdp4.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/mdp4.txt b/Documentation/devicetree/bindings/display/msm/mdp4.txt deleted file mode 100644 index b07eeb38f709..000000000000 --- a/Documentation/devicetree/bindings/display/msm/mdp4.txt +++ /dev/null @@ -1,114 +0,0 @@ -Qualcomm adreno/snapdragon MDP4 display controller - -Description: - -This is the bindings documentation for the MDP4 display controller found in -SoCs like MSM8960, APQ8064 and MSM8660. - -Required properties: -- compatible: - * "qcom,mdp4" - mdp4 -- reg: Physical base address and length of the controller's registers. -- interrupts: The interrupt signal from the display controller. -- clocks: device clocks - See ../clocks/clock-bindings.txt for details. -- clock-names: the following clocks are required. - * "core_clk" - * "iface_clk" - * "bus_clk" - * "lut_clk" - * "hdmi_clk" - * "tv_clk" -- ports: contains the list of output ports from MDP. These connect to interfaces - that are external to the MDP hardware, such as HDMI, DSI, EDP etc (LVDS is a - special case since it is a part of the MDP block itself). - - Each output port contains an endpoint that describes how it is connected to an - external interface. These are described by the standard properties documented - here: - Documentation/devicetree/bindings/graph.txt - Documentation/devicetree/bindings/media/video-interfaces.txt - - The output port mappings are: - Port 0 -> LCDC/LVDS - Port 1 -> DSI1 Cmd/Video - Port 2 -> DSI2 Cmd/Video - Port 3 -> DTV - -Optional properties: -- clock-names: the following clocks are optional: - * "lut_clk" -- qcom,lcdc-align-lsb: Boolean value indicating that LSB alignment should be - used for LCDC. This is only valid for 18bpp panels. - -Example: - -/ { - ... - - hdmi: hdmi@4a00000 { - ... - ports { - ... - port@0 { - reg = <0>; - hdmi_in: endpoint { - remote-endpoint = <&mdp_dtv_out>; - }; - }; - ... - }; - ... - }; - - ... - - mdp: mdp@5100000 { - compatible = "qcom,mdp4"; - reg = <0x05100000 0xf0000>; - interrupts = ; - clock-names = - "core_clk", - "iface_clk", - "lut_clk", - "hdmi_clk", - "tv_clk"; - clocks = - <&mmcc MDP_CLK>, - <&mmcc MDP_AHB_CLK>, - <&mmcc MDP_AXI_CLK>, - <&mmcc MDP_LUT_CLK>, - <&mmcc HDMI_TV_CLK>, - <&mmcc MDP_TV_CLK>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - mdp_lvds_out: endpoint { - }; - }; - - port@1 { - reg = <1>; - mdp_dsi1_out: endpoint { - }; - }; - - port@2 { - reg = <2>; - mdp_dsi2_out: endpoint { - }; - }; - - port@3 { - reg = <3>; - mdp_dtv_out: endpoint { - remote-endpoint = <&hdmi_in>; - }; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/msm/mdp4.yaml b/Documentation/devicetree/bindings/display/msm/mdp4.yaml new file mode 100644 index 000000000000..f63f60fea27c --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/mdp4.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/display/msm/mdp4.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Adreno/Snapdragon MDP4 display controller + +description: > + MDP4 display controller found in SoCs like MSM8960, APQ8064 and MSM8660. + +maintainers: + - Rob Clark + +properties: + compatible: + const: qcom,mdp4 + + clocks: + minItems: 6 + maxItems: 6 + + clock-names: + items: + - const: core_clk + - const: iface_clk + - const: bus_clk + - const: lut_clk + - const: hdmi_clk + - const: tv_clk + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + iommus: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: LCDC/LVDS + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: DSI1 Cmd / Video + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: DSI2 Cmd / Video + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: Digital TV + + qcom,lcdc-align-lsb: + type: boolean + description: > + Indication that LSB alignment should be used for LCDC. + This is only valid for 18bpp panels. + +required: + - compatible + - reg + - clocks + - ports + +additionalProperties: false + +examples: + - | + mdp: mdp@5100000 { + compatible = "qcom,mdp4"; + reg = <0x05100000 0xf0000>; + interrupts = <0 75 0>; + clock-names = + "core_clk", + "iface_clk", + "bus_clk", + "lut_clk", + "hdmi_clk", + "tv_clk"; + clocks = + <&mmcc 77>, + <&mmcc 86>, + <&mmcc 102>, + <&mmcc 75>, + <&mmcc 97>, + <&mmcc 12>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + mdp_lvds_out: endpoint { + }; + }; + + port@1 { + reg = <1>; + mdp_dsi1_out: endpoint { + }; + }; + + port@2 { + reg = <2>; + mdp_dsi2_out: endpoint { + }; + }; + + port@3 { + reg = <3>; + mdp_dtv_out: endpoint { + remote-endpoint = <&hdmi_in>; + }; + }; + }; + }; -- cgit From 5a04982df8dad24681dc5848150f507338d3e372 Mon Sep 17 00:00:00 2001 From: Michael Tretter Date: Wed, 12 Jan 2022 16:15:39 +0100 Subject: dt-bindings: dmaengine: zynqmp_dma: convert to yaml Convert the Xilinx ZynqMP DMA engine bindings to Yaml. Signed-off-by: Michael Tretter Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220112151541.1328732-2-m.tretter@pengutronix.de --- .../bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml | 85 ++++++++++++++++++++++ .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt | 26 ------- 2 files changed, 85 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml delete mode 100644 Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml new file mode 100644 index 000000000000..c0a1408b12ec --- /dev/null +++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx ZynqMP DMA Engine + +description: | + The Xilinx ZynqMP DMA engine supports memory to memory transfers, + memory to device and device to memory transfers. It also has flow + control and rate control support for slave/peripheral dma access. + +maintainers: + - Michael Tretter + +allOf: + - $ref: "../dma-controller.yaml#" + +properties: + "#dma-cells": + const: 1 + + compatible: + const: xlnx,zynqmp-dma-1.0 + + reg: + description: memory map for gdma/adma module access + maxItems: 1 + + interrupts: + description: DMA channel interrupt + maxItems: 1 + + clocks: + description: input clocks + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: clk_main + - const: clk_apb + + xlnx,bus-width: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 64 + - 128 + description: AXI bus width in bits + + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + + dma-coherent: + description: present if dma operations are coherent + +required: + - "#dma-cells" + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + + fpd_dma_chan1: dma-controller@fd500000 { + compatible = "xlnx,zynqmp-dma-1.0"; + reg = <0xfd500000 0x1000>; + interrupt-parent = <&gic>; + interrupts = <0 117 0x4>; + #dma-cells = <1>; + clock-names = "clk_main", "clk_apb"; + clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>; + xlnx,bus-width = <128>; + dma-coherent; + }; diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt deleted file mode 100644 index 07a5a7aa9ea0..000000000000 --- a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt +++ /dev/null @@ -1,26 +0,0 @@ -Xilinx ZynqMP DMA engine, it does support memory to memory transfers, -memory to device and device to memory transfers. It also has flow -control and rate control support for slave/peripheral dma access. - -Required properties: -- compatible : Should be "xlnx,zynqmp-dma-1.0" -- reg : Memory map for gdma/adma module access. -- interrupts : Should contain DMA channel interrupt. -- xlnx,bus-width : Axi buswidth in bits. Should contain 128 or 64 -- clock-names : List of input clocks "clk_main", "clk_apb" - (see clock bindings for details) - -Optional properties: -- dma-coherent : Present if dma operations are coherent. - -Example: -++++++++ -fpd_dma_chan1: dma@fd500000 { - compatible = "xlnx,zynqmp-dma-1.0"; - reg = <0x0 0xFD500000 0x1000>; - interrupt-parent = <&gic>; - interrupts = <0 117 4>; - clock-names = "clk_main", "clk_apb"; - xlnx,bus-width = <128>; - dma-coherent; -}; -- cgit From 4c18a890dff8d95ca234d184773910383a978d45 Mon Sep 17 00:00:00 2001 From: Gwendal Grignou Date: Sat, 1 Jan 2022 12:38:15 -0800 Subject: iio:proximity:sx9324: Add SX9324 support Semtech SAR sensor SX9324 is an evolution of the SX9310: It has 4 phases that can be configured to capture and process data from any of 3 CS pins and provide independent detection: proximity, table proximity or body proximity. Gather antenna data: echo sx9324-dev3 > trigger/current_trigger echo 1 > scan_elements/in_proximity0_en echo 1 > buffer/enable od -v -An --endian=big -t d2 -w2 /dev/iio\:device3 (at 10Hz, the default). Trigger events: Setting: thresh_falling_period: 2 (events) thresh_rising_period: 2 (events) in_proximity0_thresh_either_value: 300 in_proximity0_thresh_either_hysteresis: 72 using iio_event_monitor /dev/iio\:deviceX, approaching my hand to the antenna pad, I see: ... Event: time: 1634763907532035297, type: proximity, channel: 0, evtype: thresh, direction: falling Event: time: 1634763910138104640, type: proximity, channel: 0, evtype: thresh, direction: rising ... Datasheet: https://edit.wpgdadawant.com/uploads/news_file/program/2019/30184/tech_files/program_30184_suggest_other_file.pdf Signed-off-by: Gwendal Grignou Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20220101203817.290512-4-gwendal@chromium.org Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio-sx9324 | 28 ++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-sx9324 (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio-sx9324 b/Documentation/ABI/testing/sysfs-bus-iio-sx9324 new file mode 100644 index 000000000000..632e3321f5a3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-sx9324 @@ -0,0 +1,28 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_proximity_setup +Date: November 2021 +KernelVersion: 5.17 +Contact: Gwendal Grignou +Description: + SX9324 has 3 inputs, CS0, CS1 and CS2. Hardware layout + defines if the input is + + not connected (HZ), + + grounded (GD), + + connected to an antenna where it can act as a base + (DS - data shield), or measured input (MI). + + The sensor rotates measurement across 4 phases + (PH0, PH1, PH2, PH3), where the inputs are configured + and then measured. + + By default, during the first phase, [PH0], CS0 is measured, + while CS1 and CS2 are used as shields. + `cat in_proximity0_setup` returns "MI,DS,DS". + [PH1], CS1 is measured, CS0 and CS2 are shield: + `cat in_proximity1_setup` returns "DS,MI,DS". + [PH2], CS2 is measured, CS0 and CS1 are shield: + `cat in_proximity1_setup` returns "DS,DS,MI". + [PH3], CS1 and CS2 are measured (combo mode): + `cat in_proximity1_setup` returns "DS,MI,MI". + + Note, these are the chip default. Hardware layout will most + likely dictate different output. The entry is read-only. -- cgit From 656f807086deef48aeb0e2884a434e7a573675fc Mon Sep 17 00:00:00 2001 From: Gwendal Grignou Date: Sat, 1 Jan 2022 12:38:16 -0800 Subject: dt-bindings:iio:proximity: Add sx9324 binding Similar to SX9310, add biddings to setup sx9324 hardware properties. SX9324 is a little different, introduce 4 phases to be configured in 2 pairs over 3 antennas. Signed-off-by: Gwendal Grignou Reviewed-by: Rob Herring Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20220101203817.290512-5-gwendal@chromium.org Signed-off-by: Jonathan Cameron --- .../bindings/iio/proximity/semtech,sx9324.yaml | 161 +++++++++++++++++++++ 1 file changed, 161 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml new file mode 100644 index 000000000000..b8a6ee16854f --- /dev/null +++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml @@ -0,0 +1,161 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/proximity/semtech,sx9324.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Semtech's SX9324 capacitive proximity sensor + +maintainers: + - Gwendal Grignou + - Daniel Campello + +description: | + Semtech's SX9324 proximity sensor. + +properties: + compatible: + const: semtech,sx9324 + + reg: + maxItems: 1 + + interrupts: + description: + Generated by device to announce preceding read request has finished + and data is available or that a close/far proximity event has happened. + maxItems: 1 + + vdd-supply: + description: Main power supply + + svdd-supply: + description: Host interface power supply + + "#io-channel-cells": + const: 1 + + semtech,ph0-pin: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Array of 3 entries. Index represent the id of the CS pin. + Value indicates how each CS pin is used during phase 0. + Each of the 3 pins have the following value - + 0 : unused (high impedance) + 1 : measured input + 2 : dynamic shield + 3 : grounded. + For instance, CS0 measured, CS1 shield and CS2 ground is [1, 2, 3] + items: + enum: [ 0, 1, 2, 3 ] + minItems: 3 + maxItems: 3 + + semtech,ph1-pin: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: Same as ph0-pin for phase 1. + items: + enum: [ 0, 1, 2, 3 ] + minItems: 3 + maxItems: 3 + + semtech,ph2-pin: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: Same as ph0-pin for phase 2. + items: + enum: [ 0, 1, 2, 3 ] + minItems: 3 + maxItems: 3 + + semtech,ph3-pin: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: Same as ph0-pin for phase 3. + items: + enum: [ 0, 1, 2, 3 ] + minItems: 3 + maxItems: 3 + + + semtech,ph01-resolution: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16, 32, 64, 128, 256, 512, 1024] + description: + Capacitance measurement resolution. For phase 0 and 1. + Higher the number, higher the resolution. + default: 128 + + semtech,ph23-resolution: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16, 32, 64, 128, 256, 512, 1024] + description: + Capacitance measurement resolution. For phase 2 and 3 + default: 128 + + semtech,startup-sensor: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 0 + description: | + Phase used for start-up proximity detection. + It is used when we enable a phase to remove static offset and measure + only capacitance changes introduced by the user. + + semtech,ph01-proxraw-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + default: 1 + description: + PROXRAW filter strength for phase 0 and 1. A value of 0 represents off, + and other values represent 1-1/2^N. + + semtech,ph23-proxraw-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + default: 1 + description: + Same as proxraw-strength01, for phase 2 and 3. + + semtech,avg-pos-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 16, 64, 128, 256, 512, 1024, 4294967295] + default: 16 + description: | + Average positive filter strength. A value of 0 represents off and + UINT_MAX (4294967295) represents infinite. Other values + represent 1-1/N. + +required: + - compatible + - reg + - "#io-channel-cells" + +additionalProperties: false + +examples: + - | + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + proximity@28 { + compatible = "semtech,sx9324"; + reg = <0x28>; + interrupt-parent = <&pio>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW 5>; + vdd-supply = <&pp3300_a>; + svdd-supply = <&pp1800_prox>; + #io-channel-cells = <1>; + semtech,ph0-pin = <1 2 3>; + semtech,ph1-pin = <3 2 1>; + semtech,ph2-pin = <1 2 3>; + semtech,ph3-pin = <3 2 1>; + semtech,ph01-resolution = <256>; + semtech,ph23-resolution = <256>; + semtech,startup-sensor = <1>; + semtech,ph01-proxraw-strength = <2>; + semtech,ph23-proxraw-strength = <2>; + semtech,avg-pos-strength = <64>; + }; + }; -- cgit From 1412b8cfc7e73b22047a7762529578bbfae9d202 Mon Sep 17 00:00:00 2001 From: Gwendal Grignou Date: Sat, 1 Jan 2022 12:37:59 -0800 Subject: dt-bindings:iio:proximity: Add sx9360 binding Add binding to configure Semtech sx9360 sensor. It is a simpler version of sx9324. Signed-off-by: Gwendal Grignou Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20220101203800.290387-3-gwendal@chromium.org Signed-off-by: Jonathan Cameron --- .../bindings/iio/proximity/semtech,sx9360.yaml | 89 ++++++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml new file mode 100644 index 000000000000..63e1a1fd00d4 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/proximity/semtech,sx9360.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Semtech's SX9360 capacitive proximity sensor + +maintainers: + - Gwendal Grignou + - Daniel Campello + +description: | + Semtech's SX9360 proximity sensor. + +properties: + compatible: + const: semtech,sx9360 + + reg: + maxItems: 1 + + interrupts: + description: + Generated by device to announce preceding read request has finished + and data is available or that a close/far proximity event has happened. + maxItems: 1 + + vdd-supply: + description: Main power supply + + svdd-supply: + description: Host interface power supply + + "#io-channel-cells": + const: 1 + + semtech,resolution: + $ref: /schemas/types.yaml#/definitions/uint32-array + enum: [8, 16, 32, 64, 128, 256, 512, 1024] + description: + Capacitance measurement resolution. For both phases, "reference" and + "measurement". Higher the number, higher the resolution. + default: 128 + + semtech,proxraw-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + default: 1 + description: + PROXRAW filter strength for both phases. A value of 0 represents off, + and other values represent 1-1/2^N. + + semtech,avg-pos-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 16, 64, 128, 256, 512, 1024, 4294967295] + default: 16 + description: | + Average positive filter strength. A value of 0 represents off and + UINT_MAX (4294967295) represents infinite. Other values + represent 1-1/N. + +required: + - compatible + - reg + - "#io-channel-cells" + +additionalProperties: false + +examples: + - | + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + proximity@28 { + compatible = "semtech,sx9360"; + reg = <0x28>; + interrupt-parent = <&pio>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW 5>; + vdd-supply = <&pp3300_a>; + svdd-supply = <&pp1800_prox>; + #io-channel-cells = <1>; + semtech,resolution = <256>; + semtech,proxraw-strength = <2>; + semtech,avg-pos-strength = <64>; + }; + }; -- cgit From 1f69d222242c190f54ebf86eb7b9ba7b3f2d7630 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Thu, 6 Jan 2022 12:25:11 -0600 Subject: dt-bindings: iio/adc: ti,palmas-gpadc: Split interrupt fields in example Best practice for multi-cell property values is to bracket each multi-cell value. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220106182518.1435497-3-robh@kernel.org Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml b/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml index 7b895784e008..57a31356082e 100644 --- a/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml @@ -74,9 +74,9 @@ examples: compatible = "ti,twl6035-pmic", "ti,palmas-pmic"; adc { compatible = "ti,palmas-gpadc"; - interrupts = <18 0 - 16 0 - 17 0>; + interrupts = <18 0>, + <16 0>, + <17 0>; #io-channel-cells = <1>; ti,channel0-current-microamp = <5>; ti,channel3-current-microamp = <10>; -- cgit From f247d58efbce7eb017b32ed713f4770ef635eb30 Mon Sep 17 00:00:00 2001 From: Guodong Liu Date: Mon, 10 Jan 2022 16:48:40 +0800 Subject: dt-bindings: iio: adc: Add compatible for Mediatek MT8186 This commit adds dt-binding documentation of auxadc for Mediatek MT8186 SoC Platform. Signed-off-by: Guodong Liu Acked-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220110084841.575-1-guodong.liu@mediatek.com Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml index b939f9652e3a..65581ad4b816 100644 --- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml @@ -34,6 +34,7 @@ properties: - items: - enum: - mediatek,mt8183-auxadc + - mediatek,mt8186-auxadc - mediatek,mt8195-auxadc - mediatek,mt8516-auxadc - const: mediatek,mt8173-auxadc -- cgit From 9998104515d4197d774e5384df750c6384915707 Mon Sep 17 00:00:00 2001 From: Henrik Grimler Date: Tue, 18 Jan 2022 19:57:44 +0100 Subject: dt-bindings: arm: samsung: document Chagall WiFi board binding Add binding for Samsung Galaxy Tab S 10.5", based on Exynos 5420 with codename chagall-wifi. It was released in 2014 and has several siblings with similar hardware. Signed-off-by: Henrik Grimler Link: https://lore.kernel.org/r/20220118185746.299832-2-henrik@grimler.se Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml index 052cd94113d4..a2a8bf44fe9b 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml @@ -140,6 +140,7 @@ properties: items: - enum: - insignal,arndale-octa # Insignal Arndale Octa + - samsung,chagall-wifi # Samsung SM-T800 - samsung,smdk5420 # Samsung SMDK5420 eval - const: samsung,exynos5420 - const: samsung,exynos5 -- cgit From 46f8ac8497c5cad1295e07ecda222af6bb4b530a Mon Sep 17 00:00:00 2001 From: Jonathan Marek Date: Wed, 22 Dec 2021 01:37:33 +0100 Subject: media: dt-bindings: media: camss: Add qcom,sm8250-camss binding Add bindings for qcom,sm8250-camss in order to support the camera subsystem for SM8250. Cc: devicetree@vger.kernel.org Signed-off-by: Jonathan Marek Signed-off-by: Bryan O'Donoghue Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../bindings/media/qcom,sm8250-camss.yaml | 450 +++++++++++++++++++++ 1 file changed, 450 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml new file mode 100644 index 000000000000..af877d61b607 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml @@ -0,0 +1,450 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/qcom,sm8250-camss.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm CAMSS ISP + +maintainers: + - Robert Foss + +description: | + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. + +properties: + compatible: + const: qcom,sm8250-camss + + clocks: + minItems: 37 + maxItems: 37 + + clock-names: + items: + - const: cam_ahb_clk + - const: cam_hf_axi + - const: cam_sf_axi + - const: camnoc_axi + - const: camnoc_axi_src + - const: core_ahb + - const: cpas_ahb + - const: csiphy0 + - const: csiphy0_timer + - const: csiphy1 + - const: csiphy1_timer + - const: csiphy2 + - const: csiphy2_timer + - const: csiphy3 + - const: csiphy3_timer + - const: csiphy4 + - const: csiphy4_timer + - const: csiphy5 + - const: csiphy5_timer + - const: slow_ahb_src + - const: vfe0_ahb + - const: vfe0_axi + - const: vfe0 + - const: vfe0_cphy_rx + - const: vfe0_csid + - const: vfe0_areg + - const: vfe1_ahb + - const: vfe1_axi + - const: vfe1 + - const: vfe1_cphy_rx + - const: vfe1_csid + - const: vfe1_areg + - const: vfe_lite_ahb + - const: vfe_lite_axi + - const: vfe_lite + - const: vfe_lite_cphy_rx + - const: vfe_lite_csid + + interrupts: + minItems: 14 + maxItems: 14 + + interrupt-names: + items: + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csiphy3 + - const: csiphy4 + - const: csiphy5 + - const: csid0 + - const: csid1 + - const: csid2 + - const: csid3 + - const: vfe0 + - const: vfe1 + - const: vfe_lite0 + - const: vfe_lite1 + + iommus: + minItems: 8 + maxItems: 8 + + interconnects: + minItems: 4 + maxItems: 4 + + interconnect-names: + items: + - const: cam_ahb + - const: cam_hf_0_mnoc + - const: cam_sf_0_mnoc + - const: cam_sf_icp_mnoc + + power-domains: + items: + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. + - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + description: + CSI input ports. + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@2: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@3: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@4: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@5: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + reg: + minItems: 10 + maxItems: 10 + + reg-names: + items: + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csiphy3 + - const: csiphy4 + - const: csiphy5 + - const: vfe0 + - const: vfe1 + - const: vfe_lite0 + - const: vfe_lite1 + +required: + - clock-names + - clocks + - compatible + - interconnects + - interconnect-names + - interrupts + - interrupt-names + - iommus + - power-domains + - reg + - reg-names + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + #include + + soc { + #address-cells = <2>; + #size-cells = <2>; + + camss: camss@ac6a000 { + compatible = "qcom,sm8250-camss"; + + reg = <0 0xac6a000 0 0x2000>, + <0 0xac6c000 0 0x2000>, + <0 0xac6e000 0 0x1000>, + <0 0xac70000 0 0x1000>, + <0 0xac72000 0 0x1000>, + <0 0xac74000 0 0x1000>, + <0 0xacb4000 0 0xd000>, + <0 0xacc3000 0 0xd000>, + <0 0xacd9000 0 0x2200>, + <0 0xacdb200 0 0x2200>; + reg-names = "csiphy0", + "csiphy1", + "csiphy2", + "csiphy3", + "csiphy4", + "csiphy5", + "vfe0", + "vfe1", + "vfe_lite0", + "vfe_lite1"; + + interrupts = , + , + , + , + , + , + , + , + , + , + , + , + , + ; + interrupt-names = "csiphy0", + "csiphy1", + "csiphy2", + "csiphy3", + "csiphy4", + "csiphy5", + "csid0", + "csid1", + "csid2", + "csid3", + "vfe0", + "vfe1", + "vfe_lite0", + "vfe_lite1"; + + power-domains = <&camcc IFE_0_GDSC>, + <&camcc IFE_1_GDSC>, + <&camcc TITAN_TOP_GDSC>; + + clocks = <&gcc GCC_CAMERA_AHB_CLK>, + <&gcc GCC_CAMERA_HF_AXI_CLK>, + <&gcc GCC_CAMERA_SF_AXI_CLK>, + <&camcc CAM_CC_CAMNOC_AXI_CLK>, + <&camcc CAM_CC_CAMNOC_AXI_CLK_SRC>, + <&camcc CAM_CC_CORE_AHB_CLK>, + <&camcc CAM_CC_CPAS_AHB_CLK>, + <&camcc CAM_CC_CSIPHY0_CLK>, + <&camcc CAM_CC_CSI0PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY1_CLK>, + <&camcc CAM_CC_CSI1PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY2_CLK>, + <&camcc CAM_CC_CSI2PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY3_CLK>, + <&camcc CAM_CC_CSI3PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY4_CLK>, + <&camcc CAM_CC_CSI4PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY5_CLK>, + <&camcc CAM_CC_CSI5PHYTIMER_CLK>, + <&camcc CAM_CC_SLOW_AHB_CLK_SRC>, + <&camcc CAM_CC_IFE_0_AHB_CLK>, + <&camcc CAM_CC_IFE_0_AXI_CLK>, + <&camcc CAM_CC_IFE_0_CLK>, + <&camcc CAM_CC_IFE_0_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_0_CSID_CLK>, + <&camcc CAM_CC_IFE_0_AREG_CLK>, + <&camcc CAM_CC_IFE_1_AHB_CLK>, + <&camcc CAM_CC_IFE_1_AXI_CLK>, + <&camcc CAM_CC_IFE_1_CLK>, + <&camcc CAM_CC_IFE_1_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_1_CSID_CLK>, + <&camcc CAM_CC_IFE_1_AREG_CLK>, + <&camcc CAM_CC_IFE_LITE_AHB_CLK>, + <&camcc CAM_CC_IFE_LITE_AXI_CLK>, + <&camcc CAM_CC_IFE_LITE_CLK>, + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_LITE_CSID_CLK>; + clock-names = "cam_ahb_clk", + "cam_hf_axi", + "cam_sf_axi", + "camnoc_axi", + "camnoc_axi_src", + "core_ahb", + "cpas_ahb", + "csiphy0", + "csiphy0_timer", + "csiphy1", + "csiphy1_timer", + "csiphy2", + "csiphy2_timer", + "csiphy3", + "csiphy3_timer", + "csiphy4", + "csiphy4_timer", + "csiphy5", + "csiphy5_timer", + "slow_ahb_src", + "vfe0_ahb", + "vfe0_axi", + "vfe0", + "vfe0_cphy_rx", + "vfe0_csid", + "vfe0_areg", + "vfe1_ahb", + "vfe1_axi", + "vfe1", + "vfe1_cphy_rx", + "vfe1_csid", + "vfe1_areg", + "vfe_lite_ahb", + "vfe_lite_axi", + "vfe_lite", + "vfe_lite_cphy_rx", + "vfe_lite_csid"; + + iommus = <&apps_smmu 0x800 0x400>, + <&apps_smmu 0x801 0x400>, + <&apps_smmu 0x840 0x400>, + <&apps_smmu 0x841 0x400>, + <&apps_smmu 0xC00 0x400>, + <&apps_smmu 0xC01 0x400>, + <&apps_smmu 0xC40 0x400>, + <&apps_smmu 0xC41 0x400>; + + interconnects = <&gem_noc MASTER_AMPSS_M0 &config_noc SLAVE_CAMERA_CFG>, + <&mmss_noc MASTER_CAMNOC_HF &mc_virt SLAVE_EBI_CH0>, + <&mmss_noc MASTER_CAMNOC_SF &mc_virt SLAVE_EBI_CH0>, + <&mmss_noc MASTER_CAMNOC_ICP &mc_virt SLAVE_EBI_CH0>; + interconnect-names = "cam_ahb", + "cam_hf_0_mnoc", + "cam_sf_0_mnoc", + "cam_sf_icp_mnoc"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + }; + }; + }; -- cgit From 2092f0def1603cb6b735ec37783656d7089fe429 Mon Sep 17 00:00:00 2001 From: Chen-Yu Tsai Date: Thu, 9 Dec 2021 07:29:25 +0100 Subject: media: docs: vidioc-dqbuf: State all remaining fields are filled by driver The specification for VIDIOC_DQBUF is slightly ambiguous on what fields of |struct v4l2_buffer| is filled by the driver. Reword it so things are clear: the driver fills in all remaining fields not specified to be filled in by userspace applications. Signed-off-by: Chen-Yu Tsai Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/vidioc-qbuf.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst b/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst index 77e0747a6d28..e4b3d9beb9ab 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst @@ -125,7 +125,7 @@ Applications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled queue. They just set the ``type``, ``memory`` and ``reserved`` fields of a struct :c:type:`v4l2_buffer` as above, when ``VIDIOC_DQBUF`` is called with a pointer to this structure the driver -fills the remaining fields or returns an error code. The driver may also +fills all remaining fields or returns an error code. The driver may also set ``V4L2_BUF_FLAG_ERROR`` in the ``flags`` field. It indicates a non-critical (recoverable) streaming error. In such case the application may continue as normal, but should be aware that data in the dequeued -- cgit From 76a5341cea4bd8bee0f02c9fa0d067b08f95f005 Mon Sep 17 00:00:00 2001 From: Eugen Hristev Date: Mon, 13 Dec 2021 14:49:19 +0100 Subject: media: dt-bindings: media: atmel: csi2dc: add bindings for microchip csi2dc Add bindings documentation for Microchip CSI2 Demultiplexer controller. CSI2DC is a demultiplexer from Synopsys IDI interface specification to parallel interface connection or direct memory access. CSI2DC can also act as a parallel bypass from a parallel sensor to the image sensor controller/interface. Signed-off-by: Eugen Hristev Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../bindings/media/microchip,csi2dc.yaml | 197 +++++++++++++++++++++ 1 file changed, 197 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/microchip,csi2dc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml new file mode 100644 index 000000000000..e8544fb2d034 --- /dev/null +++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml @@ -0,0 +1,197 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/microchip,csi2dc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip CSI2 Demux Controller (CSI2DC) + +maintainers: + - Eugen Hristev + +description: + CSI2DC - Camera Serial Interface 2 Demux Controller + + CSI2DC is a hardware block that receives incoming data from either from an + IDI interface or from a parallel bus interface. + It filters IDI packets based on their data type and virtual channel + identifier, then converts the byte stream to a pixel stream into a cross + clock domain towards a parallel interface that can be read by a sensor + controller. + IDI interface is Synopsys proprietary. + CSI2DC can act a simple bypass bridge if the incoming data is coming from + a parallel interface. + + CSI2DC provides two pipes, one video pipe and one data pipe. Video pipe + is connected at the output to a sensor controller and the data pipe is + accessible as a DMA slave port to a DMA controller. + + CSI2DC supports a single 'port' node as a sink port with either Synopsys + 32-bit IDI interface or a parallel interface. + + CSI2DC supports one 'port' node as source port with parallel interface. + This is called video pipe. + This port has an 'endpoint' that can be connected to a sink port of another + controller (next in pipeline). + + CSI2DC also supports direct access to the data through AHB, via DMA channel, + called data pipe. + For data pipe to be available, a dma controller and a dma channel must be + referenced. + +properties: + compatible: + const: microchip,sama7g5-csi2dc + + reg: + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + description: + CSI2DC must have two clocks to function correctly. One clock is the + peripheral clock for the inside functionality of the hardware block. + This is named 'pclk'. The second clock must be the cross domain clock, + in which CSI2DC will perform clock crossing. This clock must be fed + by the next controller in pipeline, which usually is a sensor controller. + Normally this clock should be given by this sensor controller who + is also a clock source. This clock is named 'scck', sensor controller clock. + items: + - const: pclk + - const: scck + + dmas: + maxItems: 1 + + dma-names: + const: rx + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + description: + Input port node, single endpoint describing the input port. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + description: Endpoint connected to input device + + properties: + bus-type: + enum: [4, 5, 6] + default: 4 + + bus-width: + enum: [8, 9, 10, 11, 12, 13, 14] + default: 14 + + clock-noncontinuous: + type: boolean + description: + Presence of this boolean property decides whether clock is + continuous or noncontinuous. + + remote-endpoint: true + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + description: + Output port node, single endpoint describing the output port. + + properties: + endpoint: + unevaluatedProperties: false + $ref: video-interfaces.yaml# + description: Endpoint connected to output device + + properties: + bus-type: + enum: [5, 6] + default: 5 + + bus-width: + enum: [8, 9, 10, 11, 12, 13, 14] + default: 14 + + remote-endpoint: true + + required: + - port@0 + - port@1 + +additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - ports + +examples: + # Example for connecting to a parallel sensor controller block (video pipe) + # and the input is received from Synopsys IDI interface + - | + csi2dc@e1404000 { + compatible = "microchip,sama7g5-csi2dc"; + reg = <0xe1404000 0x500>; + clocks = <&pclk>, <&scck>; + clock-names = "pclk", "scck"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; /* must be 0, first child port */ + csi2dc_in: endpoint { /* input from IDI interface */ + bus-type = <4>; /* MIPI CSI2 D-PHY */ + remote-endpoint = <&csi2host_out>; + }; + }; + + port@1 { + reg = <1>; /* must be 1, second child port */ + csi2dc_out: endpoint { + remote-endpoint = <&xisc_in>; /* output to sensor controller */ + }; + }; + }; + }; + + # Example for connecting to a DMA master as an AHB slave + # and the input is received from Synopsys IDI interface + - | + #include + csi2dc@e1404000 { + compatible = "microchip,sama7g5-csi2dc"; + reg = <0xe1404000 0x500>; + clocks = <&pclk>, <&scck>; + clock-names = "pclk", "scck"; + dmas = <&dma0 AT91_XDMAC_DT_PERID(34)>; + dma-names = "rx"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; /* must be 0, first child port */ + csi2dc_input: endpoint { /* input from IDI interface */ + remote-endpoint = <&csi2host_out>; + }; + }; + + port@1 { + reg = <1>; + }; + }; + }; + +... -- cgit From 7a3b3dc3bb2eeac4adf8b01b1b6b519bcbc48cfc Mon Sep 17 00:00:00 2001 From: Benjamin Gaignard Date: Fri, 7 Jan 2022 16:54:54 +0100 Subject: media: hevc: Remove RPS named flags Marking a picture as long-term reference is valid for DPB but not for RPS. Change flag name to match with the description in HEVC spec chapter "8.3.2 Decoding process for reference picture set". PocStCurrBefore, PocStCurrAfter, PocLtCurr lists could be built by the kernel from the DPB entries struct v4l2_hevc_dpb_entry, using the information in the rps field. This way RPS flags becomes useless and are removed. This patch breaks the staging HEVC API because it introduces a new flag, changes a field name in v4l2_hevc_dpb_entry structure and removes V4L2_HEVC_DPB_ENTRY_RPS_* flags. [hverkuil: fixed some typos] Signed-off-by: Benjamin Gaignard Reviewed-by: Jernej Skrabec Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index e141f0e4eec9..e8de13e16c3b 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -3166,11 +3166,11 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - :c:func:`v4l2_timeval_to_ns()` function to convert the struct :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64. * - __u8 - - ``rps`` - - The reference set for the reference frame - (V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_BEFORE, - V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_AFTER or - V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR) + - ``flags`` + - Long term flag for the reference frame + (V4L2_HEVC_DPB_ENTRY_LONG_TERM_REFERENCE). The flag is set as + described in the ITU HEVC specification chapter "8.3.2 Decoding + process for reference picture set". * - __u8 - ``field_pic`` - Whether the reference is a field picture or a frame. -- cgit From d95a63daca85f4bca3b70e622c75586b5bf0ea5c Mon Sep 17 00:00:00 2001 From: Benjamin Gaignard Date: Fri, 7 Jan 2022 16:54:55 +0100 Subject: media: hevc: Embedded indexes in RPS Reference Picture Set lists provide indices of short and long term reference in DBP array. Fix Hantro to not do a look up in DBP entries. Make documentation more clear about it. [hverkuil: fix typo in commit log] Signed-off-by: Benjamin Gaignard Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index e8de13e16c3b..4cd7c541fc30 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -3383,15 +3383,15 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - * - __u8 - ``poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - PocStCurrBefore as described in section 8.3.2 "Decoding process for reference - picture set. + picture set": provides the index of the short term before references in DPB array. * - __u8 - ``poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - PocStCurrAfter as described in section 8.3.2 "Decoding process for reference - picture set. + picture set": provides the index of the short term after references in DPB array. * - __u8 - ``poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - PocLtCurr as described in section 8.3.2 "Decoding process for reference - picture set. + picture set": provides the index of the long term references in DPB array. * - __u64 - ``flags`` - See :ref:`Decode Parameters Flags ` -- cgit From 9cdd70ceb6faf1adfad1cc7b434c19143b08226e Mon Sep 17 00:00:00 2001 From: Yunfei Dong Date: Thu, 13 Jan 2022 05:10:41 +0100 Subject: media: dt-bindings: media: mtk-vcodec: Separate video encoder and decoder dt-bindings Separate decoder and encoder document for the dts are big difference. Signed-off-by: Yunfei Dong Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../bindings/media/mediatek,vcodec-decoder.yaml | 176 +++++++++++++++++++ .../bindings/media/mediatek,vcodec-encoder.yaml | 187 +++++++++++++++++++++ .../devicetree/bindings/media/mediatek-vcodec.txt | 131 --------------- 3 files changed, 363 insertions(+), 131 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml delete mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml new file mode 100644 index 000000000000..df1d677098fd --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml @@ -0,0 +1,176 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/mediatek,vcodec-decoder.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek Video Decode Accelerator + +maintainers: + - Yunfei Dong + +description: |+ + Mediatek Video Decode is the video decode hardware present in Mediatek + SoCs which supports high resolution decoding functionalities. + +properties: + compatible: + enum: + - mediatek,mt8173-vcodec-dec + - mediatek,mt8183-vcodec-dec + + reg: + maxItems: 12 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 8 + + clock-names: + items: + - const: vcodecpll + - const: univpll_d2 + - const: clk_cci400_sel + - const: vdec_sel + - const: vdecpll + - const: vencpll + - const: venc_lt_sel + - const: vdec_bus_clk_src + + assigned-clocks: true + + assigned-clock-parents: true + + assigned-clock-rates: true + + power-domains: + maxItems: 1 + + iommus: + minItems: 1 + maxItems: 32 + description: | + List of the hardware port in respective IOMMU block for current Socs. + Refer to bindings/iommu/mediatek,iommu.yaml. + + dma-ranges: + maxItems: 1 + description: | + Describes the physical address space of IOMMU maps to memory. + + mediatek,larb: + $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 + description: | + Must contain the local arbiters in the current Socs. + + mediatek,vpu: + $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 + description: + Describes point to vpu. + + mediatek,scp: + $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 + description: + Describes point to scp. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - iommus + - assigned-clocks + - assigned-clock-parents + +allOf: + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt8183-vcodec-dec + + then: + required: + - mediatek,scp + + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt8173-vcodec-dec + + then: + required: + - mediatek,vpu + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + #include + + vcodec_dec: vcodec@16000000 { + compatible = "mediatek,mt8173-vcodec-dec"; + reg = <0x16000000 0x100>, /*VDEC_SYS*/ + <0x16020000 0x1000>, /*VDEC_MISC*/ + <0x16021000 0x800>, /*VDEC_LD*/ + <0x16021800 0x800>, /*VDEC_TOP*/ + <0x16022000 0x1000>, /*VDEC_CM*/ + <0x16023000 0x1000>, /*VDEC_AD*/ + <0x16024000 0x1000>, /*VDEC_AV*/ + <0x16025000 0x1000>, /*VDEC_PP*/ + <0x16026800 0x800>, /*VP8_VD*/ + <0x16027000 0x800>, /*VP6_VD*/ + <0x16027800 0x800>, /*VP8_VL*/ + <0x16028400 0x400>; /*VP9_VD*/ + interrupts = ; + mediatek,larb = <&larb1>; + iommus = <&iommu M4U_PORT_HW_VDEC_MC_EXT>, + <&iommu M4U_PORT_HW_VDEC_PP_EXT>, + <&iommu M4U_PORT_HW_VDEC_AVC_MV_EXT>, + <&iommu M4U_PORT_HW_VDEC_PRED_RD_EXT>, + <&iommu M4U_PORT_HW_VDEC_PRED_WR_EXT>, + <&iommu M4U_PORT_HW_VDEC_UFO_EXT>, + <&iommu M4U_PORT_HW_VDEC_VLD_EXT>, + <&iommu M4U_PORT_HW_VDEC_VLD2_EXT>; + mediatek,vpu = <&vpu>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>; + clocks = <&apmixedsys CLK_APMIXED_VCODECPLL>, + <&topckgen CLK_TOP_UNIVPLL_D2>, + <&topckgen CLK_TOP_CCI400_SEL>, + <&topckgen CLK_TOP_VDEC_SEL>, + <&topckgen CLK_TOP_VCODECPLL>, + <&apmixedsys CLK_APMIXED_VENCPLL>, + <&topckgen CLK_TOP_VENC_LT_SEL>, + <&topckgen CLK_TOP_VCODECPLL_370P5>; + clock-names = "vcodecpll", + "univpll_d2", + "clk_cci400_sel", + "vdec_sel", + "vdecpll", + "vencpll", + "venc_lt_sel", + "vdec_bus_clk_src"; + assigned-clocks = <&topckgen CLK_TOP_VENC_LT_SEL>, + <&topckgen CLK_TOP_CCI400_SEL>, + <&topckgen CLK_TOP_VDEC_SEL>, + <&apmixedsys CLK_APMIXED_VCODECPLL>, + <&apmixedsys CLK_APMIXED_VENCPLL>; + assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL_370P5>, + <&topckgen CLK_TOP_UNIVPLL_D2>, + <&topckgen CLK_TOP_VCODECPLL>; + assigned-clock-rates = <0>, <0>, <0>, <1482000000>, <800000000>; + }; diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml new file mode 100644 index 000000000000..b72c1a50e89e --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml @@ -0,0 +1,187 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/mediatek,vcodec-encoder.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek Video Encode Accelerator + +maintainers: + - Yunfei Dong + +description: |+ + Mediatek Video Encode is the video encode hardware present in Mediatek + SoCs which supports high resolution encoding functionalities. + +properties: + compatible: + enum: + - mediatek,mt8173-vcodec-enc-vp8 + - mediatek,mt8173-vcodec-enc + - mediatek,mt8183-vcodec-enc + - mediatek,mt8192-vcodec-enc + - mediatek,mt8195-vcodec-enc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 5 + + clock-names: + minItems: 1 + maxItems: 5 + + assigned-clocks: true + + assigned-clock-parents: true + + iommus: + minItems: 1 + maxItems: 32 + description: | + List of the hardware port in respective IOMMU block for current Socs. + Refer to bindings/iommu/mediatek,iommu.yaml. + + dma-ranges: + maxItems: 1 + description: | + Describes the physical address space of IOMMU maps to memory. + + mediatek,larb: + $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 + description: | + Must contain the local arbiters in the current Socs. + + mediatek,vpu: + $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 + description: + Describes point to vpu. + + mediatek,scp: + $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 + description: + Describes point to scp. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - iommus + - assigned-clocks + - assigned-clock-parents + +allOf: + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt8183-vcodec-enc + - mediatek,mt8192-vcodec-enc + + then: + required: + - mediatek,scp + + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt8173-vcodec-enc-vp8 + - mediatek,mt8173-vcodec-enc + + then: + required: + - mediatek,vpu + + - if: + properties: + compatible: + enum: + - mediatek,mt8173-vcodec-enc + - mediatek,mt8192-vcodec-enc + - mediatek,mt8173-vcodec-enc + + then: + properties: + clock: + items: + minItems: 1 + maxItems: 1 + clock-names: + items: + - const: venc_sel + else: # for vp8 hw decoder + properties: + clock: + items: + minItems: 1 + maxItems: 1 + clock-names: + items: + - const: venc_lt_sel + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + + vcodec_enc_avc: vcodec@18002000 { + compatible = "mediatek,mt8173-vcodec-enc"; + reg = <0x18002000 0x1000>; + interrupts = ; + iommus = <&iommu M4U_PORT_VENC_RCPU>, + <&iommu M4U_PORT_VENC_REC>, + <&iommu M4U_PORT_VENC_BSDMA>, + <&iommu M4U_PORT_VENC_SV_COMV>, + <&iommu M4U_PORT_VENC_RD_COMV>, + <&iommu M4U_PORT_VENC_CUR_LUMA>, + <&iommu M4U_PORT_VENC_CUR_CHROMA>, + <&iommu M4U_PORT_VENC_REF_LUMA>, + <&iommu M4U_PORT_VENC_REF_CHROMA>, + <&iommu M4U_PORT_VENC_NBM_RDMA>, + <&iommu M4U_PORT_VENC_NBM_WDMA>; + mediatek,larb = <&larb3>; + mediatek,vpu = <&vpu>; + clocks = <&topckgen CLK_TOP_VENC_SEL>; + clock-names = "venc_sel"; + assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL>; + }; + + vcodec_enc_vp8: vcodec@19002000 { + compatible = "mediatek,mt8173-vcodec-enc-vp8"; + reg = <0x19002000 0x1000>; /* VENC_LT_SYS */ + interrupts = ; + iommus = <&iommu M4U_PORT_VENC_RCPU_SET2>, + <&iommu M4U_PORT_VENC_REC_FRM_SET2>, + <&iommu M4U_PORT_VENC_BSDMA_SET2>, + <&iommu M4U_PORT_VENC_SV_COMA_SET2>, + <&iommu M4U_PORT_VENC_RD_COMA_SET2>, + <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>, + <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>, + <&iommu M4U_PORT_VENC_REF_LUMA_SET2>, + <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>; + mediatek,larb = <&larb5>; + mediatek,vpu = <&vpu>; + clocks = <&topckgen CLK_TOP_VENC_LT_SEL>; + clock-names = "venc_lt_sel"; + assigned-clocks = <&topckgen CLK_TOP_VENC_LT_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL_370P5>; + }; diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt deleted file mode 100644 index 665a9508708e..000000000000 --- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt +++ /dev/null @@ -1,131 +0,0 @@ -Mediatek Video Codec - -Mediatek Video Codec is the video codec hw present in Mediatek SoCs which -supports high resolution encoding and decoding functionalities. - -Required properties: -- compatible : must be one of the following string: - "mediatek,mt8173-vcodec-enc-vp8" for mt8173 vp8 encoder. - "mediatek,mt8173-vcodec-enc" for mt8173 avc encoder. - "mediatek,mt8183-vcodec-enc" for MT8183 encoder. - "mediatek,mt8173-vcodec-dec" for MT8173 decoder. - "mediatek,mt8192-vcodec-enc" for MT8192 encoder. - "mediatek,mt8183-vcodec-dec" for MT8183 decoder. - "mediatek,mt8195-vcodec-enc" for MT8195 encoder. -- reg : Physical base address of the video codec registers and length of - memory mapped region. -- interrupts : interrupt number to the cpu. -- mediatek,larb : must contain the local arbiters in the current Socs. -- clocks : list of clock specifiers, corresponding to entries in - the clock-names property. -- clock-names: avc encoder must contain "venc_sel", vp8 encoder must - contain "venc_lt_sel", decoder must contain "vcodecpll", "univpll_d2", - "clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll", "venc_lt_sel", - "vdec_bus_clk_src". -- iommus : should point to the respective IOMMU block with master port as - argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml - for details. -- dma-ranges : describes the dma address range space that the codec hw access. -One of the two following nodes: -- mediatek,vpu : the node of the video processor unit, if using VPU. -- mediatek,scp : the node of the SCP unit, if using SCP. - - -Example: - -vcodec_dec: vcodec@16000000 { - compatible = "mediatek,mt8173-vcodec-dec"; - reg = <0 0x16000000 0 0x100>, /*VDEC_SYS*/ - <0 0x16020000 0 0x1000>, /*VDEC_MISC*/ - <0 0x16021000 0 0x800>, /*VDEC_LD*/ - <0 0x16021800 0 0x800>, /*VDEC_TOP*/ - <0 0x16022000 0 0x1000>, /*VDEC_CM*/ - <0 0x16023000 0 0x1000>, /*VDEC_AD*/ - <0 0x16024000 0 0x1000>, /*VDEC_AV*/ - <0 0x16025000 0 0x1000>, /*VDEC_PP*/ - <0 0x16026800 0 0x800>, /*VP8_VD*/ - <0 0x16027000 0 0x800>, /*VP6_VD*/ - <0 0x16027800 0 0x800>, /*VP8_VL*/ - <0 0x16028400 0 0x400>; /*VP9_VD*/ - interrupts = ; - mediatek,larb = <&larb1>; - iommus = <&iommu M4U_PORT_HW_VDEC_MC_EXT>, - <&iommu M4U_PORT_HW_VDEC_PP_EXT>, - <&iommu M4U_PORT_HW_VDEC_AVC_MV_EXT>, - <&iommu M4U_PORT_HW_VDEC_PRED_RD_EXT>, - <&iommu M4U_PORT_HW_VDEC_PRED_WR_EXT>, - <&iommu M4U_PORT_HW_VDEC_UFO_EXT>, - <&iommu M4U_PORT_HW_VDEC_VLD_EXT>, - <&iommu M4U_PORT_HW_VDEC_VLD2_EXT>; - mediatek,vpu = <&vpu>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>; - clocks = <&apmixedsys CLK_APMIXED_VCODECPLL>, - <&topckgen CLK_TOP_UNIVPLL_D2>, - <&topckgen CLK_TOP_CCI400_SEL>, - <&topckgen CLK_TOP_VDEC_SEL>, - <&topckgen CLK_TOP_VCODECPLL>, - <&apmixedsys CLK_APMIXED_VENCPLL>, - <&topckgen CLK_TOP_VENC_LT_SEL>, - <&topckgen CLK_TOP_VCODECPLL_370P5>; - clock-names = "vcodecpll", - "univpll_d2", - "clk_cci400_sel", - "vdec_sel", - "vdecpll", - "vencpll", - "venc_lt_sel", - "vdec_bus_clk_src"; - assigned-clocks = <&topckgen CLK_TOP_VENC_LT_SEL>, - <&topckgen CLK_TOP_CCI400_SEL>, - <&topckgen CLK_TOP_VDEC_SEL>, - <&apmixedsys CLK_APMIXED_VCODECPLL>, - <&apmixedsys CLK_APMIXED_VENCPLL>; - assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL_370P5>, - <&topckgen CLK_TOP_UNIVPLL_D2>, - <&topckgen CLK_TOP_VCODECPLL>; - assigned-clock-rates = <0>, <0>, <0>, <1482000000>, <800000000>; - }; - -vcodec_enc_avc: vcodec@18002000 { - compatible = "mediatek,mt8173-vcodec-enc"; - reg = <0 0x18002000 0 0x1000>; - interrupts = ; - iommus = <&iommu M4U_PORT_VENC_RCPU>, - <&iommu M4U_PORT_VENC_REC>, - <&iommu M4U_PORT_VENC_BSDMA>, - <&iommu M4U_PORT_VENC_SV_COMV>, - <&iommu M4U_PORT_VENC_RD_COMV>, - <&iommu M4U_PORT_VENC_CUR_LUMA>, - <&iommu M4U_PORT_VENC_CUR_CHROMA>, - <&iommu M4U_PORT_VENC_REF_LUMA>, - <&iommu M4U_PORT_VENC_REF_CHROMA>, - <&iommu M4U_PORT_VENC_NBM_RDMA>, - <&iommu M4U_PORT_VENC_NBM_WDMA>; - mediatek,larb = <&larb3>; - mediatek,vpu = <&vpu>; - clocks = <&topckgen CLK_TOP_VENC_SEL>; - clock-names = "venc_sel"; - assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>; - assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL>; - }; - -vcodec_enc_vp8: vcodec@19002000 { - compatible = "mediatek,mt8173-vcodec-enc-vp8"; - reg = <0 0x19002000 0 0x1000>; /* VENC_LT_SYS */ - interrupts = ; - iommus = <&iommu M4U_PORT_VENC_RCPU_SET2>, - <&iommu M4U_PORT_VENC_REC_FRM_SET2>, - <&iommu M4U_PORT_VENC_BSDMA_SET2>, - <&iommu M4U_PORT_VENC_SV_COMA_SET2>, - <&iommu M4U_PORT_VENC_RD_COMA_SET2>, - <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>, - <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>, - <&iommu M4U_PORT_VENC_REF_LUMA_SET2>, - <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>; - mediatek,larb = <&larb5>; - mediatek,vpu = <&vpu>; - clocks = <&topckgen CLK_TOP_VENC_LT_SEL>; - clock-names = "venc_lt_sel"; - assigned-clocks = <&topckgen CLK_TOP_VENC_LT_SEL>; - assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL_370P5>; - }; -- cgit From 4215692f50fe771be87b4fe7f44469d035916f4f Mon Sep 17 00:00:00 2001 From: Yunfei Dong Date: Thu, 13 Jan 2022 05:10:42 +0100 Subject: media: dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192 Adds decoder dt-bindings for mt8192. Signed-off-by: Yunfei Dong Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../media/mediatek,vcodec-subdev-decoder.yaml | 265 +++++++++++++++++++++ 1 file changed, 265 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml new file mode 100644 index 000000000000..d587fc3e39fb --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml @@ -0,0 +1,265 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/mediatek,vcodec-subdev-decoder.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Mediatek Video Decode Accelerator With Multi Hardware + +maintainers: + - Yunfei Dong + +description: | + Mediatek Video Decode is the video decode hardware present in Mediatek + SoCs which supports high resolution decoding functionalities. Required + parent and child device node. + + About the Decoder Hardware Block Diagram, please check below: + + +---------------------------------+------------------------------------+ + | | | + | input -> lat HW -> lat buffer --|--> lat buffer -> core HW -> output | + | || | || | + +------------||-------------------+---------------------||-------------+ + lat workqueue | core workqueue + -------------||-----------------------------------------||------------------ + || || + \/ <----------------HW index-------------->\/ + +------------------------------------------------------+ + | enable/disable | + | clk power irq iommu | + | (lat/lat soc/core0/core1) | + +------------------------------------------------------+ + + As above, there are parent and child devices, child mean each hardware. The child device + controls the information of each hardware independent which include clk/power/irq. + + There are two workqueues in parent device: lat workqueue and core workqueue. They are used + to lat and core hardware deocder. Lat workqueue need to get input bitstream and lat buffer, + then enable lat to decode, writing the result to lat buffer, dislabe hardware when lat decode + done. Core workqueue need to get lat buffer and output buffer, then enable core to decode, + writing the result to output buffer, disable hardware when core decode done. These two + hardwares will decode each frame cyclically. + + For the smi common may not the same for each hardware, can't combine all hardware in one node, + or leading to iommu fault when access dram data. + +properties: + compatible: + const: mediatek,mt8192-vcodec-dec + + reg: + maxItems: 1 + + iommus: + minItems: 1 + maxItems: 32 + description: | + List of the hardware port in respective IOMMU block for current Socs. + Refer to bindings/iommu/mediatek,iommu.yaml. + + mediatek,scp: + $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 + description: | + The node of system control processor (SCP), using + the remoteproc & rpmsg framework. + + dma-ranges: + maxItems: 1 + description: | + Describes the physical address space of IOMMU maps to memory. + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + +# Required child node: +patternProperties: + '^vcodec-lat@[0-9a-f]+$': + type: object + + properties: + compatible: + const: mediatek,mtk-vcodec-lat + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + iommus: + minItems: 1 + maxItems: 32 + description: | + List of the hardware port in respective IOMMU block for current Socs. + Refer to bindings/iommu/mediatek,iommu.yaml. + + clocks: + maxItems: 5 + + clock-names: + items: + - const: sel + - const: soc-vdec + - const: soc-lat + - const: vdec + - const: top + + assigned-clocks: + maxItems: 1 + + assigned-clock-parents: + maxItems: 1 + + power-domains: + maxItems: 1 + + required: + - compatible + - reg + - interrupts + - iommus + - clocks + - clock-names + - assigned-clocks + - assigned-clock-parents + - power-domains + + additionalProperties: false + + '^vcodec-core@[0-9a-f]+$': + type: object + + properties: + compatible: + const: mediatek,mtk-vcodec-core + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + iommus: + minItems: 1 + maxItems: 32 + description: | + List of the hardware port in respective IOMMU block for current Socs. + Refer to bindings/iommu/mediatek,iommu.yaml. + + clocks: + maxItems: 5 + + clock-names: + items: + - const: sel + - const: soc-vdec + - const: soc-lat + - const: vdec + - const: top + + assigned-clocks: + maxItems: 1 + + assigned-clock-parents: + maxItems: 1 + + power-domains: + maxItems: 1 + + required: + - compatible + - reg + - interrupts + - iommus + - clocks + - clock-names + - assigned-clocks + - assigned-clock-parents + - power-domains + + additionalProperties: false + +required: + - compatible + - reg + - iommus + - mediatek,scp + - dma-ranges + - ranges + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + #include + + video-codec@16000000 { + compatible = "mediatek,mt8192-vcodec-dec"; + mediatek,scp = <&scp>; + iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>; + dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x16000000 0x40000>; + reg = <0x16000000 0x1000>; /* VDEC_SYS */ + vcodec-lat@10000 { + compatible = "mediatek,mtk-vcodec-lat"; + reg = <0x10000 0x800>; + interrupts = ; + iommus = <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD2_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_TILE_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_WDMA_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_RG_CTRL_DMA_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_UFO_ENC_EXT>; + clocks = <&topckgen CLK_TOP_VDEC_SEL>, + <&vdecsys_soc CLK_VDEC_SOC_VDEC>, + <&vdecsys_soc CLK_VDEC_SOC_LAT>, + <&vdecsys_soc CLK_VDEC_SOC_LARB1>, + <&topckgen CLK_TOP_MAINPLL_D4>; + clock-names = "sel", "soc-vdec", "soc-lat", "vdec", "top"; + assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; + power-domains = <&spm MT8192_POWER_DOMAIN_VDEC>; + }; + + vcodec-core@25000 { + compatible = "mediatek,mtk-vcodec-core"; + reg = <0x25000 0x1000>; + interrupts = ; + iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_UFO_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_PP_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_PRED_RD_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_PRED_WR_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_PPWRAP_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_TILE_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_VLD_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_VLD2_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_AVC_MV_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_RG_CTRL_DMA_EXT>; + clocks = <&topckgen CLK_TOP_VDEC_SEL>, + <&vdecsys CLK_VDEC_VDEC>, + <&vdecsys CLK_VDEC_LAT>, + <&vdecsys CLK_VDEC_LARB1>, + <&topckgen CLK_TOP_MAINPLL_D4>; + clock-names = "sel", "soc-vdec", "soc-lat", "vdec", "top"; + assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; + power-domains = <&spm MT8192_POWER_DOMAIN_VDEC2>; + }; + }; -- cgit From 768f8d8e45f9d09aa28c9ea7c3caf86ece66ea22 Mon Sep 17 00:00:00 2001 From: Douglas Anderson Date: Tue, 11 Jan 2022 14:05:21 -0800 Subject: dt-bindings: pinctrl: drive-strength doesn't default to 2 if unspecified If the drive-strength isn't specified in the device tree then it doesn't actually default to 2. Instead, it defaults to whatever the heck the BIOS left it at. If the BIOS doesn't touch it then that means it's whatever the heck the initial state of the pin was when the SoC booted. Reported-by: Matthias Kaehlcke Signed-off-by: Douglas Anderson Reviewed-by: Matthias Kaehlcke Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20220111140519.1.Ie2662d6289af1e9758b14b37149703c846d5f509@changeid Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml index be8cb0ead62f..780f15bb5e40 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml @@ -73,7 +73,6 @@ $defs: properties: drive-strength: enum: [2, 4, 6, 8, 10, 12, 14, 16] - default: 2 description: Selects the drive strength for the specified pins, in mA. -- cgit From 210b3ef939c846f4af0602bdc660852e837bf4a8 Mon Sep 17 00:00:00 2001 From: Conley Lee Date: Sat, 15 Jan 2022 00:31:48 +0800 Subject: dt-bindings: arm: sunxi: add haoyu,a20-marsboard add haoyu,a20-marsboard dt-bindings Signed-off-by: Conley Lee Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/tencent_B6059C6C031E46EFCB05D5A5015B1C4DE608@qq.com --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index c8a3102c0fde..086c68771d2b 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -444,6 +444,11 @@ properties: - const: haoyu,a10-marsboard - const: allwinner,sun4i-a10 + - description: HAOYU Electronics Marsboard A20 + items: + - const: haoyu,a20-marsboard + - const: allwinner,sun7i-a20 + - description: MapleBoard MP130 items: - const: mapleboard,mp130 -- cgit From 1dcb6b782ff02b966b3ff45c597b8dec56cbc2b2 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Wed, 22 Dec 2021 14:59:01 +0000 Subject: dt-bindings: pinctrl: renesas,rzg2l-pinctrl: Add description for power-source property Add description for "power-source" property mentioning the values in enum are in millivolt. Suggested-by: Pavel Machek Signed-off-by: Lad Prabhakar Acked-by: Rob Herring Link: https://lore.kernel.org/r/20211222145901.23661-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml index b749c82edebd..194649bb1cfa 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml @@ -76,6 +76,7 @@ additionalProperties: output-impedance-ohms: enum: [ 33, 50, 66, 100 ] power-source: + description: I/O voltage in millivolt. enum: [ 1800, 2500, 3300 ] slew-rate: true gpio-hog: true -- cgit From c07b19de2f7ac91662aa99767815a258da6ef16f Mon Sep 17 00:00:00 2001 From: Biju Das Date: Mon, 10 Jan 2022 13:46:53 +0000 Subject: dt-bindings: pinctrl: renesas: Document RZ/V2L pinctrl Document Renesas RZ/V2L pinctrl bindings. The RZ/V2L SoC is package- and pin-compatible with RZ/G2L. No driver changes are required as the RZ/G2L compatible string "renesas,r9a07g044-pinctrl" will be used as a fallback. Signed-off-by: Biju Das Signed-off-by: Lad Prabhakar Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220110134659.30424-7-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- .../bindings/pinctrl/renesas,rzg2l-pinctrl.yaml | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml index 194649bb1cfa..9ccf54870aa4 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml @@ -4,14 +4,14 @@ $id: http://devicetree.org/schemas/pinctrl/renesas,rzg2l-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas RZ/G2L combined Pin and GPIO controller +title: Renesas RZ/{G2L,V2L} combined Pin and GPIO controller maintainers: - Geert Uytterhoeven - Lad Prabhakar description: - The Renesas SoCs of the RZ/G2L series feature a combined Pin and GPIO + The Renesas SoCs of the RZ/{G2L,V2L} series feature a combined Pin and GPIO controller. Pin multiplexing and GPIO configuration is performed on a per-pin basis. Each port features up to 8 pins, each of them configurable for GPIO function @@ -20,8 +20,15 @@ description: properties: compatible: - enum: - - renesas,r9a07g044-pinctrl # RZ/G2{L,LC} + oneOf: + - items: + - enum: + - renesas,r9a07g044-pinctrl # RZ/G2{L,LC} + + - items: + - enum: + - renesas,r9a07g054-pinctrl # RZ/V2L + - const: renesas,r9a07g044-pinctrl # RZ/G2{L,LC} fallback for RZ/V2L reg: maxItems: 1 -- cgit From 509e1a8675fcab9861fe280ebb5bf17e47349c40 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Tue, 21 Dec 2021 09:47:02 +0000 Subject: dt-bindings: arm: renesas: Document Renesas RZ/V2L SoC on SMARC EVK Document the Renesas SMARC EVK board which is based on the Renesas RZ/V2L (R9A07G054) SoC. The SMARC EVK consists of an RZ/V2L SoM module and a SMARC carrier board. The SoM module sits on top of the carrier board. Signed-off-by: Biju Das Signed-off-by: Lad Prabhakar Acked-by: Rob Herring Link: https://lore.kernel.org/r/20211221094717.16187-2-prabhakar.mahadev-lad.rj@bp.renesas.com Link: https://lore.kernel.org/r/20211221094717.16187-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/arm/renesas.yaml | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index 6a9350ee690b..fa435d6fda77 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -421,6 +421,15 @@ properties: - renesas,r9a07g044l2 # Dual Cortex-A55 RZ/G2L - const: renesas,r9a07g044 + - description: RZ/V2L (R9A07G054) + items: + - enum: + - renesas,smarc-evk # SMARC EVK + - enum: + - renesas,r9a07g054l1 # Single Cortex-A55 RZ/V2L + - renesas,r9a07g054l2 # Dual Cortex-A55 RZ/V2L + - const: renesas,r9a07g054 + additionalProperties: true ... -- cgit From 4b4a0fd666303a06bbe159552bc055b490b77cdc Mon Sep 17 00:00:00 2001 From: Biju Das Date: Mon, 10 Jan 2022 13:46:48 +0000 Subject: dt-bindings: power: renesas,rzg2l-sysc: Document RZ/V2L SoC Add DT binding documentation for the SYSC controller found on the RZ/V2L SoC. This SYSC controller is almost identical to the one found on the RZ/G2L SoC, the only difference being that SYSC on RZ/V2L has an additional register to control the DRP-AI. Signed-off-by: Biju Das Signed-off-by: Lad Prabhakar Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220110134659.30424-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml index 84ddc772b003..bb433e75a0ee 100644 --- a/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml +++ b/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml @@ -4,14 +4,14 @@ $id: "http://devicetree.org/schemas/power/renesas,rzg2l-sysc.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" -title: Renesas RZ/G2L System Controller (SYSC) +title: Renesas RZ/{G2L,V2L} System Controller (SYSC) maintainers: - Geert Uytterhoeven description: - The RZ/G2L System Controller (SYSC) performs system control of the LSI and - supports following functions, + The RZ/{G2L,V2L} System Controller (SYSC) performs system control of the LSI + and supports following functions, - External terminal state capture function - 34-bit address space access function - Low power consumption control @@ -21,6 +21,7 @@ properties: compatible: enum: - renesas,r9a07g044-sysc # RZ/G2{L,LC} + - renesas,r9a07g054-sysc # RZ/V2L reg: maxItems: 1 -- cgit From b8aec7a4a01b75973c22f004377a48593a3fef03 Mon Sep 17 00:00:00 2001 From: Daniel Beer Date: Sun, 16 Jan 2022 14:56:27 +1300 Subject: ASoC: dt-bindings: add bindings for TI TAS5805M. The TAS5805M is a class D speaker amplifier with integrated DSP. Configuration must be generated by TI's PPC3 tool and supplied as a firmware image. Signed-off-by: Daniel Beer Link: https://lore.kernel.org/r/e271d381dcf1c6036a2a22bab6ab72654455aa58.1642298336.git.daniel.beer@igorinstitute.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/tas5805m.yaml | 56 ++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/tas5805m.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/tas5805m.yaml b/Documentation/devicetree/bindings/sound/tas5805m.yaml new file mode 100644 index 000000000000..3aade02d8a96 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tas5805m.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/tas5805m.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TAS5805M audio amplifier + +maintainers: + - Daniel Beer + +description: | + The TAS5805M is a class D audio amplifier with a built-in DSP. + +properties: + compatible: + enum: + - ti,tas5805m + + reg: + maxItems: 1 + description: | + I2C address of the amplifier. See the datasheet for possible values. + + pvdd-supply: + description: | + Regulator for audio power supply (PVDD in the datasheet). + + pdn-gpios: + description: | + Power-down control GPIO (PDN pin in the datasheet). + + ti,dsp-config-name: + description: | + The name of the DSP configuration that should be loaded for this + instance. Configuration blobs are sequences of register writes + generated from TI's PPC3 tool. + $ref: /schemas/types.yaml#/definitions/string + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + tas5805m: tas5805m@2c { + reg = <0x2c>; + compatible = "ti,tas5805m"; + + pvdd-supply = <&audiopwr>; + pdn-gpios = <&tlmm 160 0>; + + ti,dsp-config-name = "mono_pbtl_48khz"; + }; + }; + +additionalProperties: true -- cgit From 55915f20ad9ae92015bf7b2c4ac854e5b720d63f Mon Sep 17 00:00:00 2001 From: Ariel D'Alessandro Date: Mon, 17 Jan 2022 10:21:07 -0300 Subject: ASoC: bindings: fsl-asoc-card: Add mclk-id optional property Support setting the sound card main clock input from the device-tree using the mclk-id property. Signed-off-by: Ariel D'Alessandro Link: https://lore.kernel.org/r/20220117132109.283365-4-ariel.dalessandro@collabora.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl-asoc-card.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt index 23d83fa7609f..b219626a5403 100644 --- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt +++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt @@ -82,6 +82,7 @@ Optional properties: - dai-format : audio format, for details see simple-card.yaml. - frame-inversion : dai-link uses frame clock inversion, for details see simple-card.yaml. - bitclock-inversion : dai-link uses bit clock inversion, for details see simple-card.yaml. + - mclk-id : main clock id, specific for each card configuration. Optional unless SSI is selected as a CPU DAI: -- cgit From 85f856f790b5fd427cb31b3f62755713174da0aa Mon Sep 17 00:00:00 2001 From: Ariel D'Alessandro Date: Mon, 17 Jan 2022 10:21:05 -0300 Subject: ASoC: Rename tlv320aic31xx-micbias.h as tlv320aic31xx.h Let's use a more generic name, so other definitions for tlv320aic31xx can be included. Signed-off-by: Ariel D'Alessandro Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220117132109.283365-2-ariel.dalessandro@collabora.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/tlv320aic31xx.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt index e372303697dc..bbad98d5b986 100644 --- a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt +++ b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt @@ -58,7 +58,7 @@ The pins can be used in referring sound node's audio-routing property. Example: #include -#include +#include tlv320aic31xx: tlv320aic31xx@18 { compatible = "ti,tlv320aic311x"; -- cgit From 8e9977e48c7c2a49e09859456dcba12a8d804a51 Mon Sep 17 00:00:00 2001 From: Alexander Stein Date: Wed, 19 Jan 2022 11:37:47 +0100 Subject: regulator: pfuze100: Add missing regulator names The valid regulator names for the subnodes does not match the ones mentioned in the description. PFUZE3000 & PFUZE3001 uses 'v33', 'vccsd' and 'vldo[1-4]' as well, so add them to the allowed node names. Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20220119103747.58305-1-alexander.stein@ew.tq-group.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/pfuze100.yaml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.yaml b/Documentation/devicetree/bindings/regulator/pfuze100.yaml index f578e72778a7..a26bbd68b729 100644 --- a/Documentation/devicetree/bindings/regulator/pfuze100.yaml +++ b/Documentation/devicetree/bindings/regulator/pfuze100.yaml @@ -70,7 +70,11 @@ properties: $ref: "regulator.yaml#" type: object - "^(vsnvs|vref|vrefddr|swbst|coin)$": + "^vldo[1-4]$": + $ref: "regulator.yaml#" + type: object + + "^(vsnvs|vref|vrefddr|swbst|coin|v33|vccsd)$": $ref: "regulator.yaml#" type: object -- cgit From 2da187304e556ac59cf2dacb323cc78ded988169 Mon Sep 17 00:00:00 2001 From: Conor Dooley Date: Mon, 17 Jan 2022 11:07:47 +0000 Subject: spi: add bindings for microchip mpfs spi Add device tree bindings for the {q,}spi controller on the Microchip PolarFire SoC. Signed-off-by: Conor Dooley Link: https://lore.kernel.org/r/20220117110755.3433142-7-conor.dooley@microchip.com Signed-off-by: Mark Brown --- .../bindings/spi/microchip,mpfs-spi.yaml | 52 ++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml b/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml new file mode 100644 index 000000000000..ece261b8e963 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/microchip,mpfs-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip MPFS {Q,}SPI Controller Device Tree Bindings + +maintainers: + - Conor Dooley + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + enum: + - microchip,mpfs-spi + - microchip,mpfs-qspi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-names: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + #include "dt-bindings/clock/microchip,mpfs-clock.h" + spi@20108000 { + compatible = "microchip,mpfs-spi"; + reg = <0x20108000 0x1000>; + clocks = <&clkcfg CLK_SPI0>; + interrupt-parent = <&plic>; + interrupts = <54>; + spi-max-frequency = <25000000>; + }; +... -- cgit From ceab11a3c0d620d9ec2c032fd8014615cf7934ec Mon Sep 17 00:00:00 2001 From: Guochun Mao Date: Tue, 18 Jan 2022 22:28:17 +0800 Subject: spi: add mt8186-nor compatible string Add MT8186 spi-nor controller support. MT8186 needs a new clock name, axi_s, for spi nor axi slave bus clock. Signed-off-by: Guochun Mao Signed-off-by: Zhen Zhang Link: https://lore.kernel.org/r/20220118142820.2729-2-guochun.mao@mediatek.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml index 4e4694e3d539..be3cc7faed53 100644 --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml @@ -30,6 +30,7 @@ properties: - mediatek,mt7622-nor - mediatek,mt7623-nor - mediatek,mt7629-nor + - mediatek,mt8186-nor - mediatek,mt8192-nor - mediatek,mt8195-nor - enum: @@ -49,6 +50,8 @@ properties: - description: clock used for controller - description: clock used for nor dma bus. this depends on hardware design, so this is optional. + - description: clock used for controller axi slave bus. + this depends on hardware design, so it is optional. clock-names: minItems: 2 @@ -56,6 +59,7 @@ properties: - const: spi - const: sf - const: axi + - const: axi_s required: - compatible -- cgit From 506ca49ae7b4f0ddd9bd0ee5adff3e580218c32c Mon Sep 17 00:00:00 2001 From: Maxim Kutnij Date: Sun, 19 Dec 2021 23:31:34 +0500 Subject: dt-bindings: mediatek: Adds a DT binding documentation for the MT6582 SoC This adds a DT binding documentation for the MT6582 SoC. Signed-off-by: Maxim Kutnij Link: https://lore.kernel.org/r/20211219183134.3849-3-gtk3@inbox.ru [mb: fix commit subject line and compatible order] Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++ Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt | 1 + Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 1 + 3 files changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 0ffe1acf1344..ab0593c77321 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -30,6 +30,10 @@ properties: - enum: - mediatek,mt6580-evbp1 - const: mediatek,mt6580 + - items: + - enum: + - prestigio,pmt5008-3g + - const: mediatek,mt6582 - items: - enum: - fairphone,fp1 diff --git a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt index e5c57d6e0186..fbd76a8e023b 100644 --- a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt +++ b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt @@ -12,6 +12,7 @@ Required properties: For those SoCs that use GPT * "mediatek,mt2701-timer" for MT2701 compatible timers (GPT) * "mediatek,mt6580-timer" for MT6580 compatible timers (GPT) + * "mediatek,mt6582-timer" for MT6582 compatible timers (GPT) * "mediatek,mt6589-timer" for MT6589 compatible timers (GPT) * "mediatek,mt7623-timer" for MT7623 compatible timers (GPT) * "mediatek,mt8127-timer" for MT8127 compatible timers (GPT) diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt index 0114871f887a..a97418c74f6b 100644 --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt @@ -8,6 +8,7 @@ Required properties: - compatible should contain: "mediatek,mt2701-wdt", "mediatek,mt6589-wdt": for MT2701 "mediatek,mt2712-wdt": for MT2712 + "mediatek,mt6582-wdt", "mediatek,mt6589-wdt": for MT6582 "mediatek,mt6589-wdt": for MT6589 "mediatek,mt6797-wdt", "mediatek,mt6589-wdt": for MT6797 "mediatek,mt7622-wdt", "mediatek,mt6589-wdt": for MT7622 -- cgit From d218159f19bf6697448d86d86ee5bb0d23faefe4 Mon Sep 17 00:00:00 2001 From: John Crispin Date: Mon, 20 Dec 2021 22:18:41 +0100 Subject: dt-bindings: Add vendor prefix for Airoha Add vendor prefix "airoha" for Airoha, a subsidiary of MediaTek Acked-by: Rob Herring Signed-off-by: John Crispin Signed-off-by: Bert Vermeulen Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20211220211854.89452-2-nbd@nbd.name Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 294093d45a23..05f86bfd0b31 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -61,6 +61,8 @@ patternProperties: description: Aeroflex Gaisler AB "^aesop,.*": description: AESOP Embedded Forum + "^airoha,.*": + description: Airoha "^al,.*": description: Annapurna Labs "^alcatel,.*": -- cgit From 51911d1c1bb3e30b57e3af1072a3b6e583f3df5f Mon Sep 17 00:00:00 2001 From: John Crispin Date: Mon, 20 Dec 2021 22:18:42 +0100 Subject: dt-bindings: arm: airoha: Add binding for EN7523 SoC and EVB Add devicetree binding for Airoha EN7523 SoC and evaluation board. Reviewed-by: Rob Herring Signed-off-by: John Crispin Signed-off-by: Bert Vermeulen Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20211220211854.89452-3-nbd@nbd.name Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/arm/airoha.yaml | 28 +++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/airoha.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/airoha.yaml b/Documentation/devicetree/bindings/arm/airoha.yaml new file mode 100644 index 000000000000..fc19b1a6f37b --- /dev/null +++ b/Documentation/devicetree/bindings/arm/airoha.yaml @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/airoha.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Airoha SoC based Platforms Device Tree Bindings + +maintainers: + - Felix Fietkau + - John Crispin + +description: + Boards with an Airoha SoC shall have the following properties. + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - items: + - enum: + - airoha,en7523-evb + - const: airoha,en7523 + +additionalProperties: true + +... -- cgit From e9fed03aebacb8873dee8e2edfbce96f27f6c730 Mon Sep 17 00:00:00 2001 From: Robert Hancock Date: Thu, 20 Jan 2022 13:58:31 -0600 Subject: ASoC: dt-bindings: simple-card: document new system-clock-fixed flag Document the new system-clock-fixed flag, which can be used to specify that the driver cannot or should not allow the clock frequency of the mapped clock to be modified. Signed-off-by: Robert Hancock Link: https://lore.kernel.org/r/20220120195832.1742271-6-robert.hancock@calian.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/simple-card.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/simple-card.yaml b/Documentation/devicetree/bindings/sound/simple-card.yaml index 45fd9fd9eb54..00597dc4f396 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.yaml +++ b/Documentation/devicetree/bindings/sound/simple-card.yaml @@ -48,6 +48,15 @@ definitions: It is useful for some aCPUs with fixed clocks. $ref: /schemas/types.yaml#/definitions/flag + system-clock-fixed: + description: | + Specifies that the clock frequency should not be modified. + Implied when system-clock-frequency is specified, but can be used when + a clock is mapped to the device whose frequency cannot or should not be + changed. When mclk-fs is also specified, this restricts the device to a + single fixed sampling rate. + $ref: /schemas/types.yaml#/definitions/flag + mclk-fs: description: | Multiplication factor between stream rate and codec mclk. @@ -134,6 +143,8 @@ definitions: $ref: "#/definitions/system-clock-frequency" system-clock-direction-out: $ref: "#/definitions/system-clock-direction-out" + system-clock-fixed: + $ref: "#/definitions/system-clock-fixed" required: - sound-dai -- cgit From 2145bb687e3fdb128066872fd952f4563d89177e Mon Sep 17 00:00:00 2001 From: Daire McNamara Date: Thu, 16 Dec 2021 14:00:21 +0000 Subject: dt-bindings: clk: microchip: Add Microchip PolarFire host binding Add device tree bindings for the Microchip PolarFire system clock controller Signed-off-by: Daire McNamara Signed-off-by: Conor Dooley Reviewed-by: Geert Uytterhoeven Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20211216140022.16146-2-conor.dooley@microchip.com Signed-off-by: Stephen Boyd --- .../devicetree/bindings/clock/microchip,mpfs.yaml | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/microchip,mpfs.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/microchip,mpfs.yaml b/Documentation/devicetree/bindings/clock/microchip,mpfs.yaml new file mode 100644 index 000000000000..0c15afa2214c --- /dev/null +++ b/Documentation/devicetree/bindings/clock/microchip,mpfs.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/microchip,mpfs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip PolarFire Clock Control Module Binding + +maintainers: + - Daire McNamara + +description: | + Microchip PolarFire clock control (CLKCFG) is an integrated clock controller, + which gates and enables all peripheral clocks. + + This device tree binding describes 33 gate clocks. Clocks are referenced by + user nodes by the CLKCFG node phandle and the clock index in the group, from + 0 to 32. + +properties: + compatible: + const: microchip,mpfs-clkcfg + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + '#clock-cells': + const: 1 + description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. See include/dt-bindings/clock/microchip,mpfs-clock.h + for the full list of PolarFire clock IDs. + +required: + - compatible + - reg + - clocks + - '#clock-cells' + +additionalProperties: false + +examples: + # Clock Config node: + - | + #include + soc { + #address-cells = <2>; + #size-cells = <2>; + clkcfg: clock-controller@20002000 { + compatible = "microchip,mpfs-clkcfg"; + reg = <0x0 0x20002000 0x0 0x1000>; + clocks = <&ref>; + #clock-cells = <1>; + }; + }; -- cgit From 7b5730f0ff24b0d7d1cb660a482384a807618a46 Mon Sep 17 00:00:00 2001 From: Rafał Miłecki Date: Mon, 24 Jan 2022 11:22:42 +0100 Subject: dt-bindings: pinctrl: Add binding for BCM4908 pinctrl MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit It's hardware block that is part of every SoC from BCM4908 family. Signed-off-by: Rafał Miłecki Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220124102243.14912-1-zajec5@gmail.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/brcm,bcm4908-pinctrl.yaml | 72 ++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/brcm,bcm4908-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm4908-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm4908-pinctrl.yaml new file mode 100644 index 000000000000..175a992f15e1 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm4908-pinctrl.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/brcm,bcm4908-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM4908 pin controller + +maintainers: + - Rafał Miłecki + +description: + Binding for pin controller present on BCM4908 family SoCs. + +properties: + compatible: + const: brcm,bcm4908-pinctrl + + reg: + maxItems: 1 + +patternProperties: + '-pins$': + type: object + $ref: pinmux-node.yaml# + + properties: + function: + enum: [ led_0, led_1, led_2, led_3, led_4, led_5, led_6, led_7, led_8, + led_9, led_10, led_11, led_12, led_13, led_14, led_15, led_16, + led_17, led_18, led_19, led_20, led_21, led_22, led_23, led_24, + led_25, led_26, led_27, led_28, led_29, led_30, led_31, + hs_uart, i2c, i2s, nand_ctrl, nand_data, emmc_ctrl, usb0_pwr, + usb1_pwr ] + + groups: + minItems: 1 + maxItems: 2 + items: + enum: [ led_0_grp_a, led_1_grp_a, led_2_grp_a, led_3_grp_a, + led_4_grp_a, led_5_grp_a, led_6_grp_a, led_7_grp_a, + led_8_grp_a, led_9_grp_a, led_10_grp_a, led_10_grp_b, + led_11_grp_a, led_11_grp_b, led_12_grp_a, led_12_grp_b, + led_13_grp_a, led_13_grp_b, led_14_grp_a, led_15_grp_a, + led_16_grp_a, led_17_grp_a, led_18_grp_a, led_19_grp_a, + led_20_grp_a, led_21_grp_a, led_22_grp_a, led_23_grp_a, + led_24_grp_a, led_25_grp_a, led_26_grp_a, led_27_grp_a, + led_28_grp_a, led_29_grp_a, led_30_grp_a, led_31_grp_a, + led_31_grp_b, hs_uart_grp, i2c_grp_a, i2c_grp_b, i2s_grp, + nand_ctrl_grp, nand_data_grp, emmc_ctrl_grp, usb0_pwr_grp, + usb1_pwr_grp ] + +allOf: + - $ref: pinctrl.yaml# + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + pinctrl@ff800560 { + compatible = "brcm,bcm4908-pinctrl"; + reg = <0xff800560 0x10>; + + led_0-a-pins { + function = "led_0"; + groups = "led_0_grp_a"; + }; + }; -- cgit From 8bdc849f76963c217b9e15467b2124fd011431f3 Mon Sep 17 00:00:00 2001 From: Marcel Ziswiler Date: Fri, 14 Jan 2022 15:14:58 +0100 Subject: dt-bindings: gpio: fix gpio-hog example Even if this is no yaml yet at least fix the example to be compliant to later schema as e.g. found in gpio-pca95xx.yaml, fairchild,74hc595.yaml and gpio/fsl-imx-gpio.yaml. Signed-off-by: Marcel Ziswiler Acked-by: Rob Herring Reviewed-by: Linus Walleij Signed-off-by: Bartosz Golaszewski --- Documentation/devicetree/bindings/gpio/gpio.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index a8895d339bfe..5663e71b751f 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -213,7 +213,7 @@ Example of two SOC GPIO banks defined as gpio-controller nodes: gpio-controller; #gpio-cells = <2>; - line_b { + line_b-hog { gpio-hog; gpios = <6 0>; output-low; -- cgit From a708078eeb992799161e794d9c569cf4f725a5b0 Mon Sep 17 00:00:00 2001 From: Li-hao Kuo Date: Tue, 25 Jan 2022 12:14:29 +0000 Subject: spi: Add Sunplus SP7021 schema Add bindings for Sunplus SP7021 spi driver Signed-off-by: Li-hao Kuo Signed-off-by: Mark Brown --- .../bindings/spi/spi-sunplus-sp7021.yaml | 81 ++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml b/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml new file mode 100644 index 000000000000..24382cdda645 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright (C) Sunplus Co., Ltd. 2021 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-sunplus-sp7021.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sunplus sp7021 SPI controller + +allOf: + - $ref: "spi-controller.yaml" + +maintainers: + - Li-hao Kuo + +properties: + compatible: + enum: + - sunplus,sp7021-spi + + reg: + items: + - the SPI master registers + - the SPI slave registers + + reg-names: + items: + - const: master + - const: slave + + interrupt-names: + items: + - const: dma_w + - const: master_risc + - const: slave_risc + + interrupts: + minItems: 3 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + - clocks + - clocks-names + - resets + - pinctrl-names + - pinctrl-0 + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + spi@9C002D80 { + compatible = "sunplus,sp7021-spi"; + reg = <0x9C002D80 0x80>, <0x9C002E00 0x80>; + reg-names = "master", "slave"; + interrupt-parent = <&intc>; + interrupt-names = "dma_w", + "master_risc", + "slave_risc"; + interrupts = <144 IRQ_TYPE_LEVEL_HIGH>, + <146 IRQ_TYPE_LEVEL_HIGH>, + <145 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clkc SPI_COMBO_0>; + resets = <&rstc RST_SPI_COMBO_0>; + pinctrl-names = "default"; + pinctrl-0 = <&pins_spi0>; + }; +... -- cgit From 5bf7fa48374eafe29dbb30448a0b0c083853583f Mon Sep 17 00:00:00 2001 From: Yong Wu Date: Thu, 13 Jan 2022 19:10:51 +0800 Subject: dt-bindings: memory: mtk-smi: Rename clock to clocks The property "clock" should be rename to "clocks", and delete the "items", the minItems/maxItems should not be put under "items". Fixes: 27bb0e42855a ("dt-bindings: memory: mediatek: Convert SMI to DT schema") Signed-off-by: Yong Wu Acked-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220113111057.29918-2-yong.wu@mediatek.com Signed-off-by: Krzysztof Kozlowski --- .../memory-controllers/mediatek,smi-common.yaml | 28 ++++++++++------------ .../memory-controllers/mediatek,smi-larb.yaml | 14 +++++------ 2 files changed, 18 insertions(+), 24 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index 3a82b0b27fa0..4fca71f34310 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -88,10 +88,9 @@ allOf: - mediatek,mt2701-smi-common then: properties: - clock: - items: - minItems: 3 - maxItems: 3 + clocks: + minItems: 3 + maxItems: 3 clock-names: items: - const: apb @@ -108,10 +107,9 @@ allOf: required: - mediatek,smi properties: - clock: - items: - minItems: 3 - maxItems: 3 + clocks: + minItems: 3 + maxItems: 3 clock-names: items: - const: apb @@ -133,10 +131,9 @@ allOf: then: properties: - clock: - items: - minItems: 4 - maxItems: 4 + clocks: + minItems: 4 + maxItems: 4 clock-names: items: - const: apb @@ -146,10 +143,9 @@ allOf: else: # for gen2 HW that don't have gals properties: - clock: - items: - minItems: 2 - maxItems: 2 + clocks: + minItems: 2 + maxItems: 2 clock-names: items: - const: apb diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index eaeff1ada7f8..bd7aa8257949 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -79,10 +79,9 @@ allOf: then: properties: - clock: - items: - minItems: 3 - maxItems: 3 + clocks: + minItems: 3 + maxItems: 3 clock-names: items: - const: apb @@ -91,10 +90,9 @@ allOf: else: properties: - clock: - items: - minItems: 2 - maxItems: 2 + clocks: + minItems: 2 + maxItems: 2 clock-names: items: - const: apb -- cgit From ddc3a324889686ec9b358de20fdeec0d2668c7a8 Mon Sep 17 00:00:00 2001 From: Yong Wu Date: Thu, 13 Jan 2022 19:10:52 +0800 Subject: dt-bindings: memory: mtk-smi: No need mediatek,larb-id for mt8167 Mute the warning from "make dtbs_check": larb@14016000: 'mediatek,larb-id' is a required property arch/arm64/boot/dts/mediatek/mt8167-pumpkin.dt.yaml larb@15001000: 'mediatek,larb-id' is a required property arch/arm64/boot/dts/mediatek/mt8167-pumpkin.dt.yaml larb@16010000: 'mediatek,larb-id' is a required property arch/arm64/boot/dts/mediatek/mt8167-pumpkin.dt.yaml As the description of mediatek,larb-id, the property is only required when the larbid is not consecutive from its IOMMU point of view. Also, from the description of mediatek,larbs in Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml, all the larbs must sort by the larb index. In mt8167, there is only one IOMMU HW and three larbs. The drivers already know its larb index from the mediatek,larbs property of IOMMU, thus no need this property. Fixes: 27bb0e42855a ("dt-bindings: memory: mediatek: Convert SMI to DT schema") Signed-off-by: Yong Wu Acked-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220113111057.29918-3-yong.wu@mediatek.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index bd7aa8257949..6d61c51893d2 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -106,7 +106,6 @@ allOf: - mediatek,mt2701-smi-larb - mediatek,mt2712-smi-larb - mediatek,mt6779-smi-larb - - mediatek,mt8167-smi-larb - mediatek,mt8192-smi-larb - mediatek,mt8195-smi-larb -- cgit From 996ebc0e332bfb3091395f9bd286d8349a57be62 Mon Sep 17 00:00:00 2001 From: Yong Wu Date: Thu, 13 Jan 2022 19:10:53 +0800 Subject: dt-bindings: memory: mtk-smi: Correct minItems to 2 for the gals clocks Mute the warning from "make dtbs_check": larb@14017000: clock-names: ['apb', 'smi'] is too short arch/arm64/boot/dts/mediatek/mt8183-evb.dt.yaml arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dt.yaml ... larb@16010000: clock-names: ['apb', 'smi'] is too short arch/arm64/boot/dts/mediatek/mt8183-evb.dt.yaml arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dt.yaml larb@17010000: clock-names: ['apb', 'smi'] is too short arch/arm64/boot/dts/mediatek/mt8183-evb.dt.yaml arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dt.yaml If a platform's larb supports gals, there will be some larbs have one more "gals" clock while the others still only need "apb"/"smi" clocks, then the minItems for clocks and clock-names are 2. Fixes: 27bb0e42855a ("dt-bindings: memory: mediatek: Convert SMI to DT schema") Signed-off-by: Yong Wu Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220113111057.29918-4-yong.wu@mediatek.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index 6d61c51893d2..c5c32c910045 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -80,9 +80,10 @@ allOf: then: properties: clocks: - minItems: 3 + minItems: 2 maxItems: 3 clock-names: + minItems: 2 items: - const: apb - const: smi -- cgit From 6d86f23c35fe7b479ceef4d3f1eef925996945fd Mon Sep 17 00:00:00 2001 From: Yong Wu Date: Thu, 13 Jan 2022 19:10:54 +0800 Subject: dt-bindings: memory: mediatek: Add mt8186 support Add mt8186 smi support in the bindings. Signed-off-by: Yong Wu Acked-by: Rob Herring Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220113111057.29918-5-yong.wu@mediatek.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/mediatek,smi-common.yaml | 4 +++- .../devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml | 3 +++ 2 files changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index 4fca71f34310..a98b359bf909 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -16,7 +16,7 @@ description: | MediaTek SMI have two generations of HW architecture, here is the list which generation the SoCs use: generation 1: mt2701 and mt7623. - generation 2: mt2712, mt6779, mt8167, mt8173, mt8183, mt8192 and mt8195. + generation 2: mt2712, mt6779, mt8167, mt8173, mt8183, mt8186, mt8192 and mt8195. There's slight differences between the two SMI, for generation 2, the register which control the iommu port is at each larb's register base. But @@ -35,6 +35,7 @@ properties: - mediatek,mt8167-smi-common - mediatek,mt8173-smi-common - mediatek,mt8183-smi-common + - mediatek,mt8186-smi-common - mediatek,mt8192-smi-common - mediatek,mt8195-smi-common-vdo - mediatek,mt8195-smi-common-vpp @@ -125,6 +126,7 @@ allOf: enum: - mediatek,mt6779-smi-common - mediatek,mt8183-smi-common + - mediatek,mt8186-smi-common - mediatek,mt8192-smi-common - mediatek,mt8195-smi-common-vdo - mediatek,mt8195-smi-common-vpp diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index c5c32c910045..4db8690829cd 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -23,6 +23,7 @@ properties: - mediatek,mt8167-smi-larb - mediatek,mt8173-smi-larb - mediatek,mt8183-smi-larb + - mediatek,mt8186-smi-larb - mediatek,mt8192-smi-larb - mediatek,mt8195-smi-larb @@ -75,6 +76,7 @@ allOf: compatible: enum: - mediatek,mt8183-smi-larb + - mediatek,mt8186-smi-larb - mediatek,mt8195-smi-larb then: @@ -107,6 +109,7 @@ allOf: - mediatek,mt2701-smi-larb - mediatek,mt2712-smi-larb - mediatek,mt6779-smi-larb + - mediatek,mt8186-smi-larb - mediatek,mt8192-smi-larb - mediatek,mt8195-smi-larb -- cgit From 8d4d0d7c43e6f87df02a0acac206b50c265962d1 Mon Sep 17 00:00:00 2001 From: Henrik Grimler Date: Mon, 24 Jan 2022 14:12:40 +0100 Subject: dt-bindings: arm: samsung: document Klimt WiFi board binding Add binding for Galaxy Tab S 8.4", based on Exynos 5420 with codename klimt-wifi. Signed-off-by: Henrik Grimler Link: https://lore.kernel.org/r/20220124131241.29946-2-henrik@grimler.se Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml index a2a8bf44fe9b..faea33e4f731 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml @@ -141,6 +141,7 @@ properties: - enum: - insignal,arndale-octa # Insignal Arndale Octa - samsung,chagall-wifi # Samsung SM-T800 + - samsung,klimt-wifi # Samsung SM-T700 - samsung,smdk5420 # Samsung SMDK5420 eval - const: samsung,exynos5420 - const: samsung,exynos5 -- cgit From a5a93e9b9ab9b4f367a773b32bbe1687006d75b7 Mon Sep 17 00:00:00 2001 From: Alim Akhtar Date: Mon, 24 Jan 2022 19:46:29 +0530 Subject: dt-bindings: add vendor prefix for Tesla Add vendor prefix for the Tesla (https://www.tesla.com) Cc: linux-fsd@tesla.com Reviewed-by: Linus Walleij Reviewed-by: Krzysztof Kozlowski Signed-off-by: Alim Akhtar Link: https://lore.kernel.org/r/20220124141644.71052-2-alim.akhtar@samsung.com Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 294093d45a23..e7a362c17df7 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1205,6 +1205,8 @@ patternProperties: description: Shenzhen Techstar Electronics Co., Ltd. "^terasic,.*": description: Terasic Inc. + "^tesla,.*": + description: Tesla, Inc. "^tfc,.*": description: Three Five Corp "^thead,.*": -- cgit From d25c5eb511df3439cd91517bcbce4b274f8972b9 Mon Sep 17 00:00:00 2001 From: Alim Akhtar Date: Mon, 24 Jan 2022 19:46:41 +0530 Subject: dt-bindings: arm: add Tesla FSD ARM SoC Add device tree bindings for the Tesla FSD ARM SoC. Cc: linux-fsd@tesla.com Reviewed-by: Krzysztof Kozlowski Signed-off-by: Alim Akhtar Link: https://lore.kernel.org/r/20220124141644.71052-14-alim.akhtar@samsung.com Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/arm/tesla.yaml | 27 ++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/tesla.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/tesla.yaml b/Documentation/devicetree/bindings/arm/tesla.yaml new file mode 100644 index 000000000000..09856da657dc --- /dev/null +++ b/Documentation/devicetree/bindings/arm/tesla.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/tesla.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tesla Full Self Driving(FSD) platforms device tree bindings + +maintainers: + - Alim Akhtar + - linux-fsd@tesla.com + +properties: + $nodename: + const: '/' + compatible: + oneOf: + + - description: FSD SoC board + items: + - enum: + - tesla,fsd-evb # Tesla FSD Evaluation + - const: tesla,fsd + +additionalProperties: true + +... -- cgit From 98ed04b33f43a80c0d9e218023abce3b47ca3539 Mon Sep 17 00:00:00 2001 From: Alim Akhtar Date: Mon, 24 Jan 2022 19:46:39 +0530 Subject: dt-bindings: pinctrl: samsung: Add compatible for Tesla FSD SoC Add compatible for Tesla Full Self-Driving SoC. The pinctrl hardware IP is similar to what found on most of the Exynos series of SoC, so this new compatible is added in Samsung pinctrl binding. Cc: linux-fsd@tesla.com Signed-off-by: Alim Akhtar Link: https://lore.kernel.org/r/20220124141644.71052-12-alim.akhtar@samsung.com Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml index 28f0851d07bb..989e48c051cf 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml @@ -56,6 +56,7 @@ properties: - samsung,exynos7885-pinctrl - samsung,exynos850-pinctrl - samsung,exynosautov9-pinctrl + - tesla,fsd-pinctrl interrupts: description: -- cgit From b1bbd3a57b94889cd17147f5594db7f0652275ef Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Mon, 17 Jan 2022 16:48:21 -0800 Subject: thermal: fix Documentation bullet list warning Fix bullet list indentation formatting to prevent a docs build warning. Use same indentation style as other files in this directory. Documentation/ABI/testing/sysfs-class-thermal:201: WARNING: Bullet list ends without a blank line; unexpected unindent. Fixes: 80da1b508f29 ("thermal: Move ABI documentation to Documentation/ABI") Signed-off-by: Randy Dunlap Reported-by: Stephen Rothwell Signed-off-by: Rafael J. Wysocki --- Documentation/ABI/testing/sysfs-class-thermal | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-thermal b/Documentation/ABI/testing/sysfs-class-thermal index 2c52bb1f864c..8eee37982b2a 100644 --- a/Documentation/ABI/testing/sysfs-class-thermal +++ b/Documentation/ABI/testing/sysfs-class-thermal @@ -203,7 +203,7 @@ Description: - for generic ACPI: should be "Fan", "Processor" or "LCD" - for memory controller device on intel_menlow platform: - should be "Memory controller". + should be "Memory controller". RO, Required -- cgit From c04421c68fd40ee33df87eea69c1a447b7985d0d Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Thu, 18 Nov 2021 22:02:08 +0100 Subject: dt-bindings: phy: qcom,usb-hs-phy: add MSM8226 compatible Add a compatible for MSM8226 which also uses the USB HS PHY. Signed-off-by: Luca Weiss Acked-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20211118210210.160895-5-luca@z3ntu.xyz --- Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt index b3b75c1e6285..6814dccb390c 100644 --- a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt @@ -9,6 +9,7 @@ PROPERTIES following: "qcom,usb-hs-phy-apq8064" + "qcom,usb-hs-phy-msm8226" "qcom,usb-hs-phy-msm8916" "qcom,usb-hs-phy-msm8974" -- cgit From 8e972afb3be633a2985081af75664a26f1929cf2 Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Tue, 25 Jan 2022 10:33:28 +0100 Subject: dt-bindings: clock: convert cs2000-cp bindings to yaml The original author of the file was added as maintainer. Signed-off-by: Daniel Mack Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220125093336.226787-2-daniel@zonque.org Signed-off-by: Stephen Boyd --- .../bindings/clock/cirrus,cs2000-cp.yaml | 63 ++++++++++++++++++++++ .../devicetree/bindings/clock/cs2000-cp.txt | 22 -------- 2 files changed, 63 insertions(+), 22 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml delete mode 100644 Documentation/devicetree/bindings/clock/cs2000-cp.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml new file mode 100644 index 000000000000..379a8bab49ca --- /dev/null +++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/cirrus,cs2000-cp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier + +maintainers: + - Kuninori Morimoto + +description: | + The CS2000-CP is an extremely versatile system clocking device that + utilizes a programmable phase lock loop. + + Link: https://www.cirrus.com/products/cs2000/ + +properties: + compatible: + enum: + - cirrus,cs2000-cp + + clocks: + description: + Common clock binding for CLK_IN, XTI/REF_CLK + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: clk_in + - const: ref_clk + + '#clock-cells': + const: 0 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + +additionalProperties: false + +examples: + - | + i2c@0 { + reg = <0x0 0x100>; + #address-cells = <1>; + #size-cells = <0>; + + clock-controller@4f { + #clock-cells = <0>; + compatible = "cirrus,cs2000-cp"; + reg = <0x4f>; + clocks = <&rcar_sound 0>, <&x12_clk>; + clock-names = "clk_in", "ref_clk"; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/cs2000-cp.txt b/Documentation/devicetree/bindings/clock/cs2000-cp.txt deleted file mode 100644 index 54e6df0bee8a..000000000000 --- a/Documentation/devicetree/bindings/clock/cs2000-cp.txt +++ /dev/null @@ -1,22 +0,0 @@ -CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier - -Required properties: - -- compatible: "cirrus,cs2000-cp" -- reg: The chip select number on the I2C bus -- clocks: common clock binding for CLK_IN, XTI/REF_CLK -- clock-names: CLK_IN : clk_in, XTI/REF_CLK : ref_clk -- #clock-cells: must be <0> - -Example: - -&i2c2 { - ... - cs2000: clk_multiplier@4f { - #clock-cells = <0>; - compatible = "cirrus,cs2000-cp"; - reg = <0x4f>; - clocks = <&rcar_sound 0>, <&x12_clk>; - clock-names = "clk_in", "ref_clk"; - }; -}; -- cgit From 68643c3735102177139237fd6656085eac403b69 Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Tue, 25 Jan 2022 10:33:29 +0100 Subject: dt-bindings: clock: cs2000-cp: document aux-output-source This new optional property can be used to control the function of the auxiliary output pin. Introduce a new dt-bindings include file that contains the numerical values. Signed-off-by: Daniel Mack Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220125093336.226787-3-daniel@zonque.org Signed-off-by: Stephen Boyd --- .../devicetree/bindings/clock/cirrus,cs2000-cp.yaml | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml index 379a8bab49ca..79b90500f6ac 100644 --- a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml +++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml @@ -37,6 +37,17 @@ properties: reg: maxItems: 1 + cirrus,aux-output-source: + description: + Specifies the function of the auxiliary clock output pin + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # CS2000CP_AUX_OUTPUT_REF_CLK: ref_clk input + - 1 # CS2000CP_AUX_OUTPUT_CLK_IN: clk_in input + - 2 # CS2000CP_AUX_OUTPUT_CLK_OUT: clk_out output + - 3 # CS2000CP_AUX_OUTPUT_PLL_LOCK: pll lock status + default: 0 + required: - compatible - reg @@ -48,6 +59,8 @@ additionalProperties: false examples: - | + #include + i2c@0 { reg = <0x0 0x100>; #address-cells = <1>; @@ -59,5 +72,6 @@ examples: reg = <0x4f>; clocks = <&rcar_sound 0>, <&x12_clk>; clock-names = "clk_in", "ref_clk"; + cirrus,aux-output-source = ; }; }; -- cgit From 11dda11f00079cdf764b80211e948d48379c1e2e Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Tue, 25 Jan 2022 10:33:30 +0100 Subject: dt-bindings: clock: cs2000-cp: document cirrus,clock-skip flag This mode allows the PLL to maintain lock even when CLK_IN has missing pulses for up to 20 ms. Signed-off-by: Daniel Mack Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220125093336.226787-4-daniel@zonque.org Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml index 79b90500f6ac..9047d8a24a08 100644 --- a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml +++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml @@ -48,6 +48,12 @@ properties: - 3 # CS2000CP_AUX_OUTPUT_PLL_LOCK: pll lock status default: 0 + cirrus,clock-skip: + description: + This mode allows the PLL to maintain lock even when CLK_IN + has missing pulses for up to 20 ms. + $ref: /schemas/types.yaml#/definitions/flag + required: - compatible - reg -- cgit From 519ba32e34985fa3b79ab8163995e7a85568caa3 Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Tue, 25 Jan 2022 10:33:31 +0100 Subject: dt-bindings: clock: cs2000-cp: document cirrus,dynamic-mode This new flag exists to enable the dynamic mode of the hardware. When not given, the static mode is used. Signed-off-by: Daniel Mack Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220125093336.226787-5-daniel@zonque.org Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml index 9047d8a24a08..0abd6ba82dfd 100644 --- a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml +++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml @@ -54,6 +54,14 @@ properties: has missing pulses for up to 20 ms. $ref: /schemas/types.yaml#/definitions/flag + cirrus,dynamic-mode: + description: + In dynamic mode, the CLK_IN input is used to drive the + digital PLL of the silicon. + If not given, the static mode shall be used to derive the + output signal directly from the REF_CLK input. + $ref: /schemas/types.yaml#/definitions/flag + required: - compatible - reg -- cgit From ed68db7b7f2fd01e930fa3e6fbb75954dc25e41c Mon Sep 17 00:00:00 2001 From: Alim Akhtar Date: Mon, 24 Jan 2022 19:46:31 +0530 Subject: dt-bindings: clock: Document FSD CMU bindings Add dt-schema documentation for Tesla FSD SoC clock controller. Cc: linux-fsd@tesla.com Signed-off-by: Alim Akhtar Reviewed-by: Krzysztof Kozlowski Acked-by: Stephen Boyd Acked-by: Sylwester Nawrocki Link: https://lore.kernel.org/r/20220124141644.71052-4-alim.akhtar@samsung.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/clock/tesla,fsd-clock.yaml | 198 +++++++++++++++++++++ 1 file changed, 198 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml b/Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml new file mode 100644 index 000000000000..dc808e2f8327 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml @@ -0,0 +1,198 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/tesla,fsd-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tesla FSD (Full Self-Driving) SoC clock controller + +maintainers: + - Alim Akhtar + - linux-fsd@tesla.com + +description: | + FSD clock controller consist of several clock management unit + (CMU), which generates clocks for various inteernal SoC blocks. + The root clock comes from external OSC clock (24 MHz). + + All available clocks are defined as preprocessor macros in + 'dt-bindings/clock/fsd-clk.h' header. + +properties: + compatible: + enum: + - tesla,fsd-clock-cmu + - tesla,fsd-clock-imem + - tesla,fsd-clock-peric + - tesla,fsd-clock-fsys0 + - tesla,fsd-clock-fsys1 + - tesla,fsd-clock-mfc + - tesla,fsd-clock-cam_csi + + clocks: + minItems: 1 + maxItems: 6 + + clock-names: + minItems: 1 + maxItems: 6 + + "#clock-cells": + const: 1 + + reg: + maxItems: 1 + +allOf: + - if: + properties: + compatible: + contains: + const: tesla,fsd-clock-cmu + then: + properties: + clocks: + items: + - description: External reference clock (24 MHz) + clock-names: + items: + - const: fin_pll + + - if: + properties: + compatible: + contains: + const: tesla,fsd-clock-imem + then: + properties: + clocks: + items: + - description: External reference clock (24 MHz) + - description: IMEM TCU clock (from CMU_CMU) + - description: IMEM bus clock (from CMU_CMU) + - description: IMEM DMA clock (from CMU_CMU) + clock-names: + items: + - const: fin_pll + - const: dout_cmu_imem_tcuclk + - const: dout_cmu_imem_aclk + - const: dout_cmu_imem_dmaclk + + - if: + properties: + compatible: + contains: + const: tesla,fsd-clock-peric + then: + properties: + clocks: + items: + - description: External reference clock (24 MHz) + - description: Shared0 PLL div4 clock (from CMU_CMU) + - description: PERIC shared1 div36 clock (from CMU_CMU) + - description: PERIC shared0 div3 TBU clock (from CMU_CMU) + - description: PERIC shared0 div20 clock (from CMU_CMU) + - description: PERIC shared1 div4 DMAclock (from CMU_CMU) + clock-names: + items: + - const: fin_pll + - const: dout_cmu_pll_shared0_div4 + - const: dout_cmu_peric_shared1div36 + - const: dout_cmu_peric_shared0div3_tbuclk + - const: dout_cmu_peric_shared0div20 + - const: dout_cmu_peric_shared1div4_dmaclk + + - if: + properties: + compatible: + contains: + const: tesla,fsd-clock-fsys0 + then: + properties: + clocks: + items: + - description: External reference clock (24 MHz) + - description: Shared0 PLL div6 clock (from CMU_CMU) + - description: FSYS0 shared1 div4 clock (from CMU_CMU) + - description: FSYS0 shared0 div4 clock (from CMU_CMU) + clock-names: + items: + - const: fin_pll + - const: dout_cmu_pll_shared0_div6 + - const: dout_cmu_fsys0_shared1div4 + - const: dout_cmu_fsys0_shared0div4 + + - if: + properties: + compatible: + contains: + const: tesla,fsd-clock-fsys1 + then: + properties: + clocks: + items: + - description: External reference clock (24 MHz) + - description: FSYS1 shared0 div8 clock (from CMU_CMU) + - description: FSYS1 shared0 div4 clock (from CMU_CMU) + clock-names: + items: + - const: fin_pll + - const: dout_cmu_fsys1_shared0div8 + - const: dout_cmu_fsys1_shared0div4 + + - if: + properties: + compatible: + contains: + const: tesla,fsd-clock-mfc + then: + properties: + clocks: + items: + - description: External reference clock (24 MHz) + clock-names: + items: + - const: fin_pll + + - if: + properties: + compatible: + contains: + const: tesla,fsd-clock-cam_csi + then: + properties: + clocks: + items: + - description: External reference clock (24 MHz) + clock-names: + items: + - const: fin_pll + +required: + - compatible + - "#clock-cells" + - clocks + - clock-names + - reg + +additionalProperties: false + +examples: + # Clock controller node for CMU_FSYS1 + - | + #include + + clock_fsys1: clock-controller@16810000 { + compatible = "tesla,fsd-clock-fsys1"; + reg = <0x16810000 0x3000>; + #clock-cells = <1>; + + clocks = <&fin_pll>, + <&clock_cmu DOUT_CMU_FSYS1_SHARED0DIV8>, + <&clock_cmu DOUT_CMU_FSYS1_SHARED0DIV4>; + clock-names = "fin_pll", + "dout_cmu_fsys1_shared0div8", + "dout_cmu_fsys1_shared0div4"; + }; + +... -- cgit From 7efa98076b720c1f5b48c9295f79e4a9cabf7440 Mon Sep 17 00:00:00 2001 From: Conor Dooley Date: Mon, 17 Jan 2022 11:07:48 +0000 Subject: dt-bindings: usb: add bindings for microchip mpfs musb Add device tree bindings for the usb controller on the Microchip PolarFire SoC. Signed-off-by: Conor Dooley Link: https://lore.kernel.org/r/20220117110755.3433142-8-conor.dooley@microchip.com Reviewed-by: Rob Herring Signed-off-by: Greg Kroah-Hartman --- .../bindings/usb/microchip,mpfs-musb.yaml | 59 ++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml b/Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml new file mode 100644 index 000000000000..48c458c65848 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/microchip,mpfs-musb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip MPFS USB Controller Device Tree Bindings + +allOf: + - $ref: usb-drd.yaml# + +maintainers: + - Conor Dooley + +properties: + compatible: + enum: + - microchip,mpfs-musb + + dr_mode: true + + reg: + maxItems: 1 + + interrupts: + minItems: 2 + maxItems: 2 + + interrupt-names: + items: + - const: dma + - const: mc + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + +additionalProperties: false + +examples: + - | + #include "dt-bindings/clock/microchip,mpfs-clock.h" + usb@20201000 { + compatible = "microchip,mpfs-musb"; + reg = <0x20201000 0x1000>; + clocks = <&clkcfg CLK_USB>; + interrupt-parent = <&plic>; + interrupts = <86>, <87>; + interrupt-names = "dma", "mc"; + dr_mode = "host"; + }; + +... -- cgit From a7339e4f5788bd088bb0be1f96a6cce459676ed0 Mon Sep 17 00:00:00 2001 From: Julian Scheel Date: Fri, 21 Jan 2022 16:53:03 +0100 Subject: usb: gadget: f_uac2: Support multiple sampling rates A list of sampling rates can be specified via configfs. All enabled sampling rates are sent to the USB host on request. When the host selects a sampling rate, the internal active rate (stored in struct f_uac2) is updated. The gadget no longer supports only one frequency. Therefore USB strings corresponding to the clock sources are renamed from specific Hz value to general names Input clock/Output clock. Config strings with single value stay compatible with the previous version. Multiple samplerates passed as configuration arrays to g_audio module when built for f_uac2. Signed-off-by: Julian Scheel Signed-off-by: Pavel Hofman Link: https://lore.kernel.org/r/20220121155308.48794-6-pavel.hofman@ivitera.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/configfs-usb-gadget-uac2 | 4 ++-- Documentation/usb/gadget-testing.rst | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2 index 7fb3dbe26857..9d2f59ab9701 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2 @@ -6,7 +6,7 @@ Description: ===================== ======================================= c_chmask capture channel mask - c_srate capture sampling rate + c_srate list of capture sampling rates (comma-separated) c_ssize capture sample size (bytes) c_sync capture synchronization type (async/adaptive) @@ -20,7 +20,7 @@ Description: (in 1/256 dB) fb_max maximum extra bandwidth in async mode p_chmask playback channel mask - p_srate playback sampling rate + p_srate list of playback sampling rates (comma-separated) p_ssize playback sample size (bytes) p_mute_present playback mute control enable p_volume_present playback volume control enable diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index cbbd948c626f..419f6e5e890a 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -726,7 +726,7 @@ The uac2 function provides these attributes in its function directory: ================ ==================================================== c_chmask capture channel mask - c_srate capture sampling rate + c_srate list of capture sampling rates (comma-separated) c_ssize capture sample size (bytes) c_sync capture synchronization type (async/adaptive) c_mute_present capture mute control enable @@ -736,7 +736,7 @@ The uac2 function provides these attributes in its function directory: c_volume_res capture volume control resolution (in 1/256 dB) fb_max maximum extra bandwidth in async mode p_chmask playback channel mask - p_srate playback sampling rate + p_srate list of playback sampling rates (comma-separated) p_ssize playback sample size (bytes) p_mute_present playback mute control enable p_volume_present playback volume control enable -- cgit From 695d39ffc2b59b8333ff85724619514f98613205 Mon Sep 17 00:00:00 2001 From: Julian Scheel Date: Fri, 21 Jan 2022 16:53:04 +0100 Subject: usb: gadget: f_uac1: Support multiple sampling rates A list of sampling rates can be specified via configfs. All enabled sampling rates are sent to the USB host on request. When the host selects a sampling rate the internal active rate is updated. Config strings with single value stay compatible with the previous version. Multiple samplerates passed as configuration arrays to g_audio module when built for f_uac1. Signed-off-by: Julian Scheel Signed-off-by: Pavel Hofman Link: https://lore.kernel.org/r/20220121155308.48794-7-pavel.hofman@ivitera.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/configfs-usb-gadget-uac1 | 4 ++-- Documentation/usb/gadget-testing.rst | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac1 b/Documentation/ABI/testing/configfs-usb-gadget-uac1 index d4b8cf40a9e4..09725e273e9b 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac1 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac1 @@ -6,7 +6,7 @@ Description: ===================== ======================================= c_chmask capture channel mask - c_srate capture sampling rate + c_srate list of capture sampling rates (comma-separated) c_ssize capture sample size (bytes) c_mute_present capture mute control enable c_volume_present capture volume control enable @@ -17,7 +17,7 @@ Description: c_volume_res capture volume control resolution (in 1/256 dB) p_chmask playback channel mask - p_srate playback sampling rate + p_srate list of playback sampling rates (comma-separated) p_ssize playback sample size (bytes) p_mute_present playback mute control enable p_volume_present playback volume control enable diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index 419f6e5e890a..046842b00c89 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -916,7 +916,7 @@ The uac1 function provides these attributes in its function directory: ================ ==================================================== c_chmask capture channel mask - c_srate capture sampling rate + c_srate list of capture sampling rates (comma-separated) c_ssize capture sample size (bytes) c_mute_present capture mute control enable c_volume_present capture volume control enable @@ -924,7 +924,7 @@ The uac1 function provides these attributes in its function directory: c_volume_max capture volume control max value (in 1/256 dB) c_volume_res capture volume control resolution (in 1/256 dB) p_chmask playback channel mask - p_srate playback sampling rate + p_srate list of playback sampling rates (comma-separated) p_ssize playback sample size (bytes) p_mute_present playback mute control enable p_volume_present playback volume control enable -- cgit From dfb05b5dc3afd90e564b69b88ff6be6947a0f32f Mon Sep 17 00:00:00 2001 From: Yunhao Tian Date: Sat, 22 Jan 2022 19:24:40 +0800 Subject: usb: gadget: f_uac1: allow changing interface name via configfs This adds "function_name" configfs entry to change string value of the iInterface field. This field will be shown in Windows' audio settings panel, so being able to change it is useful. It will default to "AC Interface" just as before if unchanged. Signed-off-by: Yunhao Tian Link: https://lore.kernel.org/r/20220122112446.1415547-1-t123yh.xyz@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/configfs-usb-gadget-uac1 | 1 + Documentation/usb/gadget-testing.rst | 1 + 2 files changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac1 b/Documentation/ABI/testing/configfs-usb-gadget-uac1 index 09725e273e9b..c4ba92f004c3 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac1 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac1 @@ -29,4 +29,5 @@ Description: (in 1/256 dB) req_number the number of pre-allocated requests for both capture and playback + function_name name of the interface ===================== ======================================= diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index 046842b00c89..1792bd88f666 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -745,6 +745,7 @@ The uac2 function provides these attributes in its function directory: p_volume_res playback volume control resolution (in 1/256 dB) req_number the number of pre-allocated request for both capture and playback + function_name name of the interface ================ ==================================================== The attributes have sane default values. -- cgit From 993a44fa85c1ea5989fb5c46236ca2e3cfd71b78 Mon Sep 17 00:00:00 2001 From: Yunhao Tian Date: Sat, 22 Jan 2022 19:24:41 +0800 Subject: usb: gadget: f_uac2: allow changing interface name via configfs This adds "function_name" configfs entry to change string value of the iInterface field. This field will be shown in Windows' audio settings panel, so being able to change it is useful. It will default to "Source/Sink" just as before. Signed-off-by: Yunhao Tian Link: https://lore.kernel.org/r/20220122112446.1415547-2-t123yh.xyz@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/configfs-usb-gadget-uac2 | 1 + Documentation/usb/gadget-testing.rst | 1 + 2 files changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2 index 9d2f59ab9701..4c6bf63fcb22 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2 @@ -32,4 +32,5 @@ Description: (in 1/256 dB) req_number the number of pre-allocated requests for both capture and playback + function_name name of the interface ===================== ======================================= diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index 1792bd88f666..6e8fdfaf19e7 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -934,6 +934,7 @@ The uac1 function provides these attributes in its function directory: p_volume_res playback volume control resolution (in 1/256 dB) req_number the number of pre-allocated requests for both capture and playback + function_name name of the interface ================ ==================================================== The attributes have sane default values. -- cgit From 31b0488302c3f142f1e7f510b711ec40f625e493 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Mon, 3 Jan 2022 10:35:01 +0100 Subject: drm/panel: Extend ACX424AKP bindings to ACX424AKM The panel ACX424AKP seems to only be used in prototypes, whereas real products use the 10 pixels shorter ACX424AKM. Extend the ACX424AKP bindings to also cover the ACX424AKM. The ACX424AKM was used in a few different mobile phones from Sony Mobile. Cc: devicetree@vger.kernel.org Cc: phone-devel@vger.kernel.org Signed-off-by: Linus Walleij Acked-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20220103093501.637323-1-linus.walleij@linaro.org --- .../devicetree/bindings/display/panel/sony,acx424akp.yaml | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml b/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml index 78d060097052..059cc6dbcfca 100644 --- a/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml +++ b/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml @@ -4,7 +4,12 @@ $id: http://devicetree.org/schemas/display/panel/sony,acx424akp.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Sony ACX424AKP 4" 480x864 AMOLED panel +title: Sony ACX424AKP/ACX424AKM 4" 480x864/480x854 AMOLED panel + +description: The Sony ACX424AKP and ACX424AKM are panels built around + the Novatek NT35560 display controller. The only difference is that + the AKM is configured to use 10 pixels less in the Y axis than the + AKP. maintainers: - Linus Walleij @@ -14,7 +19,9 @@ allOf: properties: compatible: - const: sony,acx424akp + enum: + - sony,acx424akp + - sony,acx424akm reg: true reset-gpios: true vddi-supply: -- cgit From 873329354944f311b52c2dc701039db58d2f276a Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Wed, 12 Jan 2022 20:40:50 +0100 Subject: dt-bindings: phy: qcom,qusb2: Document msm8953 compatible Document the compatible string used for the qusb2 phy in msm8953. Signed-off-by: Luca Weiss Acked-by: Konrad Dybcio Link: https://lore.kernel.org/r/20220112194118.178026-2-luca@z3ntu.xyz Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index e651a63a4be3..0ab3dad3f121 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml @@ -19,6 +19,7 @@ properties: - items: - enum: - qcom,ipq8074-qusb2-phy + - qcom,msm8953-qusb2-phy - qcom,msm8996-qusb2-phy - qcom,msm8998-qusb2-phy - qcom,qcm2290-qusb2-phy -- cgit From e7393b60a14f460fbc5705f81c3383809f07dac5 Mon Sep 17 00:00:00 2001 From: David Heidelberg Date: Thu, 30 Dec 2021 01:07:40 +0100 Subject: dt-bindings: phy: convert Qualcomm USB HS phy to yaml Conversion of Qualcomm USB HS phy documentation to yaml. Signed-off-by: David Heidelberg Reviewed-by: Bjorn Andersson Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20211230000740.103869-1-david@ixit.cz Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/qcom,usb-hs-phy.txt | 84 ---------------- .../devicetree/bindings/phy/qcom,usb-hs-phy.yaml | 108 +++++++++++++++++++++ 2 files changed, 108 insertions(+), 84 deletions(-) delete mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt deleted file mode 100644 index b3b75c1e6285..000000000000 --- a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt +++ /dev/null @@ -1,84 +0,0 @@ -Qualcomm's USB HS PHY - -PROPERTIES - -- compatible: - Usage: required - Value type: - Definition: Should contain "qcom,usb-hs-phy" and more specifically one of the - following: - - "qcom,usb-hs-phy-apq8064" - "qcom,usb-hs-phy-msm8916" - "qcom,usb-hs-phy-msm8974" - -- #phy-cells: - Usage: required - Value type: - Definition: Should contain 0 - -- clocks: - Usage: required - Value type: - Definition: Should contain clock specifier for the reference and sleep - clocks - -- clock-names: - Usage: required - Value type: - Definition: Should contain "ref" and "sleep" for the reference and sleep - clocks respectively - -- resets: - Usage: required - Value type: - Definition: Should contain the phy and POR resets - -- reset-names: - Usage: required - Value type: - Definition: Should contain "phy" and "por" for the phy and POR resets - respectively - -- v3p3-supply: - Usage: required - Value type: - Definition: Should contain a reference to the 3.3V supply - -- v1p8-supply: - Usage: required - Value type: - Definition: Should contain a reference to the 1.8V supply - -- extcon: - Usage: optional - Value type: - Definition: Should contain the vbus extcon - -- qcom,init-seq: - Usage: optional - Value type: - Definition: Should contain a sequence of ULPI address and value pairs to - program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related - to Device Mode Eye Diagram test. The addresses are offsets - from the ULPI_EXT_VENDOR_SPECIFIC address, for example, - <0x1 0x53> would mean "write the value 0x53 to address 0x81". - -EXAMPLE - -otg: usb-controller { - ulpi { - phy { - compatible = "qcom,usb-hs-phy-msm8974", "qcom,usb-hs-phy"; - #phy-cells = <0>; - clocks = <&xo_board>, <&gcc GCC_USB2A_PHY_SLEEP_CLK>; - clock-names = "ref", "sleep"; - resets = <&gcc GCC_USB2A_PHY_BCR>, <&otg 0>; - reset-names = "phy", "por"; - v3p3-supply = <&pm8941_l24>; - v1p8-supply = <&pm8941_l6>; - extcon = <&smbb>; - qcom,init-seq = /bits/ 8 <0x1 0x63>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml new file mode 100644 index 000000000000..a60386bd19b2 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml @@ -0,0 +1,108 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/qcom,usb-hs-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm's USB HS PHY binding description + +maintainers: + - Bjorn Andersson + +if: + properties: + compatible: + contains: + const: qcom,usb-hs-phy-apq8064 + then: + properties: + resets: + maxItems: 1 + + reset-names: + const: por + + else: + properties: + resets: + minItems: 2 + maxItems: 2 + + reset-names: + items: + - const: phy + - const: por + +properties: + compatible: + items: + - enum: + - qcom,usb-hs-phy-apq8064 + - qcom,usb-hs-phy-msm8916 + - qcom,usb-hs-phy-msm8974 + - const: qcom,usb-hs-phy + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + maxItems: 2 + contains: + items: + - const: ref + - const: sleep + + resets: true + + reset-names: true + + v1p8-supply: true + + v3p3-supply: true + + extcon: true + + "#phy-cells": + const: 0 + + qcom,init-seq: + $ref: /schemas/types.yaml#/definitions/uint8-matrix + description: > + Sequence of ULPI address and value pairs to + program into the ULPI_EXT_VENDOR_SPECIFIC area. + This is related to Device Mode Eye Diagram test. + maxItems: 32 # no hard limit + items: + items: + - description: > + the address is offset from the ULPI_EXT_VENDOR_SPECIFIC address + - description: value + +required: + - clocks + - clock-names + - resets + - reset-names + - "#phy-cells" + +additionalProperties: false + +examples: + - | + otg: usb-controller { + ulpi { + phy { + compatible = "qcom,usb-hs-phy-msm8974", "qcom,usb-hs-phy"; + #phy-cells = <0>; + clocks = <&clk 0>, <&clk 258>; + clock-names = "ref", "sleep"; + resets = <&gcc 10>, <&otg 0>; + reset-names = "phy", "por"; + v3p3-supply = <&pm8941_l24>; + v1p8-supply = <&pm8941_l6>; + extcon = <&smbb>; + qcom,init-seq = /bits/ 8 <0x1 0x63>; + }; + }; + }; -- cgit From bb7eb3b19f198b704feb13cc38067db4104961a4 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Tue, 25 Jan 2022 10:12:22 +0100 Subject: drm: Add TODO item for requesting memory regions Add a TODO item about requesting memory regions for each driver. The current DRM drivers don't do this consistently. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Reviewed-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20220125091222.21457-6-tzimmermann@suse.de --- Documentation/gpu/todo.rst | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index da138dd39883..1b2372ef4131 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -467,6 +467,21 @@ Contact: Thomas Zimmermann Level: Intermediate +Request memory regions in all drivers +------------------------------------- + +Go through all drivers and add code to request the memory regions that the +driver uses. This requires adding calls to request_mem_region(), +pci_request_region() or similar functions. Use helpers for managed cleanup +where possible. + +Drivers are pretty bad at doing this and there used to be conflicts among +DRM and fbdev drivers. Still, it's the correct thing to do. + +Contact: Thomas Zimmermann + +Level: Starter + Core refactorings ================= -- cgit From 1d61d359c284e027fb086bceee42dbb34f06abb2 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Sat, 18 Dec 2021 16:23:09 +0100 Subject: dt-bindings: display: bridge: lvds-codec: Document TI DS90CF364A decoder Add compatible string for TI DS90CF364A, which is another LVDS to DPI decoder similar to DS90CF384A, except it is using smaller package and only provides 18bit DPI bus. Signed-off-by: Marek Vasut Cc: Laurent Pinchart Cc: Rob Herring Cc: Sam Ravnborg Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Reviewed-by: Laurent Pinchart Acked-by: Rob Herring Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20211218152309.256183-1-marex@denx.de --- Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index 708de84ac138..080c59f5118b 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml @@ -39,6 +39,7 @@ properties: - const: lvds-encoder # Generic LVDS encoder compatible fallback - items: - enum: + - ti,ds90cf364a # For the DS90CF364A FPD-Link LVDS Receiver - ti,ds90cf384a # For the DS90CF384A FPD-Link LVDS Receiver - const: lvds-decoder # Generic LVDS decoders compatible fallback - enum: -- cgit From 641e94c6b6bef902325050dab0e1cf40e60919d0 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Wed, 22 Dec 2021 14:32:00 +0100 Subject: dt-bindings: display: simple: Add Multi-Inno Technology MI0700S4T-6 panel Add Multi-Inno Technology MI0700S4T-6 7" 800x480 DPI panel compatible string. Signed-off-by: Marek Vasut Cc: Rob Herring Cc: Sam Ravnborg Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Acked-by: Rob Herring Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20211222133200.6586-1-marex@denx.de --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 62f5f050c1bc..9cf5588a09d8 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -222,6 +222,8 @@ properties: - logictechno,lttd800480070-l6wh-rt # Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel - mitsubishi,aa070mc01-ca1 + # Multi-Inno Technology Co.,Ltd MI0700S4T-6 7" 800x480 TFT Resistive Touch Module + - multi-inno,mi0700s4t-6 # Multi-Inno Technology Co.,Ltd MI1010AIT-1CP 10.1" 1280x800 LVDS IPS Cap Touch Mod. - multi-inno,mi1010ait-1cp # NEC LCD Technologies, Ltd. 12.1" WXGA (1280x800) LVDS TFT LCD panel -- cgit From 985ede63a045eabf3f9dbd7b52a10ae6f2272cb2 Mon Sep 17 00:00:00 2001 From: Li Yang Date: Tue, 16 Nov 2021 15:18:45 -0600 Subject: dt-bindings: memory: fsl: convert ifc binding to yaml schema Convert the txt binding to yaml format and add description. Drop the "simple-bus" compatible string from the example and not allowed by the binding any more. This will help to enforce the correct probe order between parent device and child devices, but will require the ifc driver to probe the child devices to work properly. Signed-off-by: Li Yang Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20211116211846.16335-2-leoyang.li@nxp.com Signed-off-by: Krzysztof Kozlowski --- .../bindings/memory-controllers/fsl/fsl,ifc.yaml | 113 +++++++++++++++++++++ .../bindings/memory-controllers/fsl/ifc.txt | 82 --------------- 2 files changed, 113 insertions(+), 82 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ifc.yaml delete mode 100644 Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ifc.yaml b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ifc.yaml new file mode 100644 index 000000000000..3be1db30bf41 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ifc.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/fsl/fsl,ifc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: FSL/NXP Integrated Flash Controller + +maintainers: + - Li Yang + +description: | + NXP's integrated flash controller (IFC) is an advanced version of the + enhanced local bus controller which includes similar programming and signal + interfaces with an extended feature set. The IFC provides access to multiple + external memory types, such as NAND flash (SLC and MLC), NOR flash, EPROM, + SRAM and other memories where address and data are shared on a bus. + +properties: + $nodename: + pattern: "^memory-controller@[0-9a-f]+$" + + compatible: + const: fsl,ifc + + "#address-cells": + enum: [2, 3] + description: | + Should be either two or three. The first cell is the chipselect + number, and the remaining cells are the offset into the chipselect. + + "#size-cells": + enum: [1, 2] + description: | + Either one or two, depending on how large each chipselect can be. + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + description: | + IFC may have one or two interrupts. If two interrupt specifiers are + present, the first is the "common" interrupt (CM_EVTER_STAT), and the + second is the NAND interrupt (NAND_EVTER_STAT). If there is only one, + that interrupt reports both types of event. + + little-endian: + type: boolean + description: | + If this property is absent, the big-endian mode will be in use as default + for registers. + + ranges: + description: | + Each range corresponds to a single chipselect, and covers the entire + access window as configured. + +patternProperties: + "^.*@[a-f0-9]+(,[a-f0-9]+)+$": + type: object + description: | + Child device nodes describe the devices connected to IFC such as NOR (e.g. + cfi-flash) and NAND (fsl,ifc-nand). There might be board specific devices + like FPGAs, CPLDs, etc. + + required: + - compatible + - reg + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + memory-controller@ffe1e000 { + compatible = "fsl,ifc"; + #address-cells = <2>; + #size-cells = <1>; + reg = <0x0 0xffe1e000 0 0x2000>; + interrupts = <16 2 19 2>; + little-endian; + + /* NOR, NAND Flashes and CPLD on board */ + ranges = <0x0 0x0 0x0 0xee000000 0x02000000>, + <0x1 0x0 0x0 0xffa00000 0x00010000>, + <0x3 0x0 0x0 0xffb00000 0x00020000>; + + flash@0,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "cfi-flash"; + reg = <0x0 0x0 0x2000000>; + bank-width = <2>; + device-width = <1>; + + partition@0 { + /* 32MB for user data */ + reg = <0x0 0x02000000>; + label = "NOR Data"; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt deleted file mode 100644 index 89427b018ba7..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt +++ /dev/null @@ -1,82 +0,0 @@ -Integrated Flash Controller - -Properties: -- name : Should be ifc -- compatible : should contain "fsl,ifc". The version of the integrated - flash controller can be found in the IFC_REV register at - offset zero. - -- #address-cells : Should be either two or three. The first cell is the - chipselect number, and the remaining cells are the - offset into the chipselect. -- #size-cells : Either one or two, depending on how large each chipselect - can be. -- reg : Offset and length of the register set for the device -- interrupts: IFC may have one or two interrupts. If two interrupt - specifiers are present, the first is the "common" - interrupt (CM_EVTER_STAT), and the second is the NAND - interrupt (NAND_EVTER_STAT). If there is only one, - that interrupt reports both types of event. - -- little-endian : If this property is absent, the big-endian mode will - be in use as default for registers. - -- ranges : Each range corresponds to a single chipselect, and covers - the entire access window as configured. - -Child device nodes describe the devices connected to IFC such as NOR (e.g. -cfi-flash) and NAND (fsl,ifc-nand). There might be board specific devices -like FPGAs, CPLDs, etc. - -Example: - - ifc@ffe1e000 { - compatible = "fsl,ifc", "simple-bus"; - #address-cells = <2>; - #size-cells = <1>; - reg = <0x0 0xffe1e000 0 0x2000>; - interrupts = <16 2 19 2>; - little-endian; - - /* NOR, NAND Flashes and CPLD on board */ - ranges = <0x0 0x0 0x0 0xee000000 0x02000000 - 0x1 0x0 0x0 0xffa00000 0x00010000 - 0x3 0x0 0x0 0xffb00000 0x00020000>; - - flash@0,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "cfi-flash"; - reg = <0x0 0x0 0x2000000>; - bank-width = <2>; - device-width = <1>; - - partition@0 { - /* 32MB for user data */ - reg = <0x0 0x02000000>; - label = "NOR Data"; - }; - }; - - flash@1,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "fsl,ifc-nand"; - reg = <0x1 0x0 0x10000>; - - partition@0 { - /* This location must not be altered */ - /* 1MB for u-boot Bootloader Image */ - reg = <0x0 0x00100000>; - label = "NAND U-Boot Image"; - read-only; - }; - }; - - cpld@3,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "fsl,p1010rdb-cpld"; - reg = <0x3 0x0 0x000001f>; - }; - }; -- cgit From 15ca0518c1b36b86c832de54417b9b61b5f6a4c9 Mon Sep 17 00:00:00 2001 From: Tobias Waldekranz Date: Wed, 26 Jan 2022 17:05:39 +0100 Subject: dt-bindings: net: xgmac_mdio: Remove unsupported "bus-frequency" This property has never been supported by the driver. The kernel has settled on "clock-frequency" as the standard name for this binding, so once that is supported we will document that instead. Fixes: 7f93c9d90f4d ("power/fsl: add MDIO dt binding for FMan") Signed-off-by: Tobias Waldekranz Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/fsl-fman.txt | 9 --------- 1 file changed, 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/fsl-fman.txt b/Documentation/devicetree/bindings/net/fsl-fman.txt index 020337f3c05f..cd5288fb4318 100644 --- a/Documentation/devicetree/bindings/net/fsl-fman.txt +++ b/Documentation/devicetree/bindings/net/fsl-fman.txt @@ -388,15 +388,6 @@ PROPERTIES Value type: Definition: A standard property. -- bus-frequency - Usage: optional - Value type: - Definition: Specifies the external MDIO bus clock speed to - be used, if different from the standard 2.5 MHz. - This may be due to the standard speed being unsupported (e.g. - due to a hardware problem), or to advertise that all relevant - components in the system support a faster speed. - - interrupts Usage: required for external MDIO Value type: -- cgit From f7af8fe85aacfeff5f3f61fd98889119a110ef18 Mon Sep 17 00:00:00 2001 From: Tobias Waldekranz Date: Wed, 26 Jan 2022 17:05:43 +0100 Subject: dt-bindings: net: xgmac_mdio: Add "clock-frequency" and "suppress-preamble" The driver now supports the standard "clock-frequency" and "suppress-preamble" properties, do document them in the binding description. Signed-off-by: Tobias Waldekranz Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/fsl-fman.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/fsl-fman.txt b/Documentation/devicetree/bindings/net/fsl-fman.txt index cd5288fb4318..801efc7d6818 100644 --- a/Documentation/devicetree/bindings/net/fsl-fman.txt +++ b/Documentation/devicetree/bindings/net/fsl-fman.txt @@ -388,6 +388,25 @@ PROPERTIES Value type: Definition: A standard property. +- clocks + Usage: optional + Value type: + Definition: A reference to the input clock of the controller + from which the MDC frequency is derived. + +- clock-frequency + Usage: optional + Value type: + Definition: Specifies the external MDC frequency, in Hertz, to + be used. Requires that the input clock is specified in the + "clocks" property. See also: mdio.yaml. + +- suppress-preamble + Usage: optional + Value type: + Definition: Disable generation of preamble bits. See also: + mdio.yaml. + - interrupts Usage: required for external MDIO Value type: -- cgit From c75c6a8add370cde88117901f21cf0d6eaf09a8f Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Wed, 29 Dec 2021 10:42:10 +0800 Subject: docs/zh_CN: Cleanup index.rst Many */index in the Chinese index.rst are not in the same order as the English version. Put them to where they should be. Signed-off-by: Tang Yizhou Reviewed-by: Yanteng Si Link: https://lore.kernel.org/r/20211229024212.32752-2-tangyizhou@huawei.com Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/index.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 46e14ec9963d..e7f5fa3e7502 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -104,13 +104,13 @@ TODOList: :maxdepth: 2 core-api/index + accounting/index cpu-freq/index iio/index + infiniband/index + virt/index sound/index filesystems/index - virt/index - infiniband/index - accounting/index scheduler/index TODOList: -- cgit From 30e61d38f01d77d6d1f76c7566e70d46eff3724d Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Wed, 29 Dec 2021 10:42:11 +0800 Subject: docs/zh_CN: Add power/index Chinese translation Translate power/index.rst into Chinese. Signed-off-by: Tang Yizhou Reviewed-by: Alex Shi Reviewed-by: Yanteng Si Link: https://lore.kernel.org/r/20211229024212.32752-3-tangyizhou@huawei.com Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/index.rst | 2 +- Documentation/translations/zh_CN/power/index.rst | 55 ++++++++++++++++++++++++ 2 files changed, 56 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/power/index.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index e7f5fa3e7502..08144252630c 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -108,6 +108,7 @@ TODOList: cpu-freq/index iio/index infiniband/index + power/index virt/index sound/index filesystems/index @@ -129,7 +130,6 @@ TODOList: * netlabel/index * networking/index * pcmcia/index -* power/index * target/index * timers/index * spi/index diff --git a/Documentation/translations/zh_CN/power/index.rst b/Documentation/translations/zh_CN/power/index.rst new file mode 100644 index 000000000000..fd379adfda8e --- /dev/null +++ b/Documentation/translations/zh_CN/power/index.rst @@ -0,0 +1,55 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/power/index.rst + +:翻译: + + 唐艺舟 Tang Yizhou + +======== +电源管理 +======== + +.. toctree:: + :maxdepth: 1 + +TODOList: + + * apm-acpi + * basic-pm-debugging + * charger-manager + * drivers-testing + * energy-model + * freezing-of-tasks + * opp + * pci + * pm_qos_interface + * power_supply_class + * runtime_pm + * s2ram + * suspend-and-cpuhotplug + * suspend-and-interrupts + * swsusp-and-swap-files + * swsusp-dmcrypt + * swsusp + * video + * tricks + + * userland-swsusp + + * powercap/powercap + * powercap/dtpm + + * regulator/consumer + * regulator/design + * regulator/machine + * regulator/overview + * regulator/regulator + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` -- cgit From dd774a07ddfcb4dfe15778ea30cd5bb592ffab29 Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Wed, 29 Dec 2021 10:42:12 +0800 Subject: docs/zh_CN: Add opp Chinese translation Translate power/opp.rst into Chinese. Signed-off-by: Tang Yizhou Reviewed-by: Alex Shi Reviewed-by: Yanteng Si Link: https://lore.kernel.org/r/20211229024212.32752-4-tangyizhou@huawei.com Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/power/index.rst | 3 +- Documentation/translations/zh_CN/power/opp.rst | 341 +++++++++++++++++++++++ 2 files changed, 343 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/power/opp.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/power/index.rst b/Documentation/translations/zh_CN/power/index.rst index fd379adfda8e..ad80a9e80b7c 100644 --- a/Documentation/translations/zh_CN/power/index.rst +++ b/Documentation/translations/zh_CN/power/index.rst @@ -14,6 +14,8 @@ .. toctree:: :maxdepth: 1 + opp + TODOList: * apm-acpi @@ -22,7 +24,6 @@ TODOList: * drivers-testing * energy-model * freezing-of-tasks - * opp * pci * pm_qos_interface * power_supply_class diff --git a/Documentation/translations/zh_CN/power/opp.rst b/Documentation/translations/zh_CN/power/opp.rst new file mode 100644 index 000000000000..8d6e3f6f6202 --- /dev/null +++ b/Documentation/translations/zh_CN/power/opp.rst @@ -0,0 +1,341 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/power/opp.rst + +:翻译: + + 唐艺舟 Tang Yizhou + +====================== +操作性能值（OPP）库 +====================== + +(C) 2009-2010 Nishanth Menon , 德州仪器公司 + +.. 目录 + + 1. 简介 + 2. OPP链表初始注册 + 3. OPP搜索函数 + 4. OPP可用性控制函数 + 5. OPP数据检索函数 + 6. 数据结构 + +1. 简介 +======= + +1.1 何为操作性能值（OPP）？ +------------------------------ + +当今复杂的单片系统（SoC）由多个子模块组成，这些子模块会联合工作。在一个执行不同用例 +的操作系统中，并不是SoC中的所有模块都需要一直以最高频率工作。为了促成这一点，SoC中 +的子模块被分组为不同域，允许一些域以较低的电压和频率运行，而其它域则以较高的“电压/ +频率对”运行。 + +设备按域支持的由频率电压对组成的离散的元组的集合，被称为操作性能值（组），或OPPs。 + +举例来说： + +让我们考虑一个支持下述频率、电压值的内存保护单元（MPU）设备： +{300MHz，最低电压为1V}, {800MHz，最低电压为1.2V}, {1GHz，最低电压为1.3V} + +我们能将它们表示为3个OPP，如下述{Hz, uV}元组（译注：频率的单位是赫兹，电压的单位是 +微伏）。 + +- {300000000, 1000000} +- {800000000, 1200000} +- {1000000000, 1300000} + +1.2 操作性能值库 +---------------- + +OPP库提供了一组辅助函数来组织和查询OPP信息。该库位于drivers/opp/目录下，其头文件 +位于include/linux/pm_opp.h中。OPP库可以通过开启CONFIG_PM_OPP来启用。某些SoC， +如德州仪器的OMAP框架允许在不需要cpufreq的情况下可选地在某一OPP下启动。 + +OPP库的典型用法如下:: + + （用户） -> 注册一个默认的OPP集合 -> （库） + （SoC框架） -> 在必要的情况下，对某些OPP进行修改 -> OPP layer + -> 搜索/检索信息的查询 -> + +OPP层期望每个域由一个唯一的设备指针来表示。SoC框架在OPP层为每个设备注册了一组初始 +OPP。这个链表的长度被期望是一个最优化的小数字，通常每个设备大约5个。初始链表包含了 +一个OPP集合，这个集合被期望能在系统中安全使能。 + +关于OPP可用性的说明 +^^^^^^^^^^^^^^^^^^^ + +随着系统的运行，SoC框架可能会基于各种外部因素选择让某些OPP在每个设备上可用或不可用， +示例：温度管理或其它异常场景中，SoC框架可能会选择禁用一个较高频率的OPP以安全地继续 +运行，直到该OPP被重新启用（如果可能）。 + +OPP库在它的实现中达成了这个概念。以下操作函数只能对可用的OPP使用： +dev_pm_opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, +dev_pm_opp_get_freq, dev_pm_opp_get_opp_count。 + +dev_pm_opp_find_freq_exact是用来查找OPP指针的，该指针可被用在dev_pm_opp_enable/ +disable函数，使一个OPP在被需要时变为可用。 + +警告：如果对一个设备调用dev_pm_opp_enable/disable函数，OPP库的用户应该使用 +dev_pm_opp_get_opp_count来刷新OPP的可用性计数。触发这些的具体机制，或者对有依赖的 +子系统（比如cpufreq）的通知机制，都是由使用OPP库的SoC特定框架酌情处理的。在这些操作 +中，同样需要注意刷新cpufreq表。 + +2. OPP链表初始注册 +================== +SoC的实现会迭代调用dev_pm_opp_add函数来增加每个设备的OPP。预期SoC框架将以最优的 +方式注册OPP条目 - 典型的数字范围小于5。通过注册OPP生成的OPP链表，在整个设备运行过程 +中由OPP库维护。SoC框架随后可以使用dev_pm_opp_enable / disable函数动态地 +控制OPP的可用性。 + +dev_pm_opp_add + 为设备指针所指向的特定域添加一个新的OPP。OPP是用频率和电压定义的。一旦完成 + 添加，OPP被认为是可用的，可以用dev_pm_opp_enable/disable函数来控制其可用性。 + OPP库内部用dev_pm_opp结构体存储并管理这些信息。这个函数可以被SoC框架根据SoC + 的使用环境的需求来定义一个最优链表。 + + 警告： + 不要在中断上下文使用这个函数。 + + 示例:: + + soc_pm_init() + { + /* 做一些事情 */ + r = dev_pm_opp_add(mpu_dev, 1000000, 900000); + if (!r) { + pr_err("%s: unable to register mpu opp(%d)\n", r); + goto no_cpufreq; + } + /* 做一些和cpufreq相关的事情 */ + no_cpufreq: + /* 做剩余的事情 */ + } + +3. OPP搜索函数 +============== +cpufreq等高层框架对频率进行操作，为了将频率映射到相应的OPP，OPP库提供了便利的函数 +来搜索OPP库内部管理的OPP链表。这些搜索函数如果找到匹配的OPP，将返回指向该OPP的指针， +否则返回错误。这些错误预计由标准的错误检查，如IS_ERR()来处理，并由调用者采取适当的 +行动。 + +这些函数的调用者应在使用完OPP后调用dev_pm_opp_put()。否则，OPP的内存将永远不会 +被释放，并导致内存泄露。 + +dev_pm_opp_find_freq_exact + 根据 *精确的* 频率和可用性来搜索OPP。这个函数对默认不可用的OPP特别有用。 + 例子：在SoC框架检测到更高频率可用的情况下，它可以使用这个函数在调用 + dev_pm_opp_enable之前找到OPP:: + + opp = dev_pm_opp_find_freq_exact(dev, 1000000000, false); + dev_pm_opp_put(opp); + /* 不要操作指针.. 只是做有效性检查.. */ + if (IS_ERR(opp)) { + pr_err("frequency not disabled!\n"); + /* 触发合适的操作.. */ + } else { + dev_pm_opp_enable(dev,1000000000); + } + + 注意： + 这是唯一一个可以搜索不可用OPP的函数。 + +dev_pm_opp_find_freq_floor + 搜索一个 *最多* 提供指定频率的可用OPP。这个函数在搜索较小的匹配或按频率 + 递减的顺序操作OPP信息时很有用。 + 例子：要找的一个设备的最高OPP:: + + freq = ULONG_MAX; + opp = dev_pm_opp_find_freq_floor(dev, &freq); + dev_pm_opp_put(opp); + +dev_pm_opp_find_freq_ceil + 搜索一个 *最少* 提供指定频率的可用OPP。这个函数在搜索较大的匹配或按频率 + 递增的顺序操作OPP信息时很有用。 + 例1：找到一个设备最小的OPP:: + + freq = 0; + opp = dev_pm_opp_find_freq_ceil(dev, &freq); + dev_pm_opp_put(opp); + + 例: 一个SoC的cpufreq_driver->target的简易实现:: + + soc_cpufreq_target(..) + { + /* 做策略检查等操作 */ + /* 找到和请求最接近的频率 */ + opp = dev_pm_opp_find_freq_ceil(dev, &freq); + dev_pm_opp_put(opp); + if (!IS_ERR(opp)) + soc_switch_to_freq_voltage(freq); + else + /* 当不能满足请求时，要做的事 */ + /* 做其它事 */ + } + +4. OPP可用性控制函数 +==================== +在OPP库中注册的默认OPP链表也许无法满足所有可能的场景。OPP库提供了一套函数来修改 +OPP链表中的某个OPP的可用性。这使得SoC框架能够精细地动态控制哪一组OPP是可用于操作 +的。设计这些函数的目的是在诸如考虑温度时 *暂时地* 删除某个OPP（例如，在温度下降 +之前不要使用某OPP）。 + +警告： + 不要在中断上下文使用这些函数。 + +dev_pm_opp_enable + 使一个OPP可用于操作。 + 例子：假设1GHz的OPP只有在SoC温度低于某个阈值时才可用。SoC框架的实现可能 + 会选择做以下事情:: + + if (cur_temp < temp_low_thresh) { + /* 若1GHz未使能，则使能 */ + opp = dev_pm_opp_find_freq_exact(dev, 1000000000, false); + dev_pm_opp_put(opp); + /* 仅仅是错误检查 */ + if (!IS_ERR(opp)) + ret = dev_pm_opp_enable(dev, 1000000000); + else + goto try_something_else; + } + +dev_pm_opp_disable + 使一个OPP不可用于操作。 + 例子：假设1GHz的OPP只有在SoC温度高于某个阈值时才可用。SoC框架的实现可能 + 会选择做以下事情:: + + if (cur_temp > temp_high_thresh) { + /* 若1GHz已使能，则关闭 */ + opp = dev_pm_opp_find_freq_exact(dev, 1000000000, true); + dev_pm_opp_put(opp); + /* 仅仅是错误检查 */ + if (!IS_ERR(opp)) + ret = dev_pm_opp_disable(dev, 1000000000); + else + goto try_something_else; + } + +5. OPP数据检索函数 +================== +由于OPP库对OPP信息进行了抽象化处理，因此需要一组函数来从dev_pm_opp结构体中提取 +信息。一旦使用搜索函数检索到一个OPP指针，以下函数就可以被SoC框架用来检索OPP层 +内部描述的信息。 + +dev_pm_opp_get_voltage + 检索OPP指针描述的电压。 + 例子: 当cpufreq切换到到不同频率时，SoC框架需要用稳压器框架将OPP描述 + 的电压设置到提供电压的电源管理芯片中:: + + soc_switch_to_freq_voltage(freq) + { + /* 做一些事情 */ + opp = dev_pm_opp_find_freq_ceil(dev, &freq); + v = dev_pm_opp_get_voltage(opp); + dev_pm_opp_put(opp); + if (v) + regulator_set_voltage(.., v); + /* 做其它事 */ + } + +dev_pm_opp_get_freq + 检索OPP指针描述的频率。 + 例子：比方说，SoC框架使用了几个辅助函数，通过这些函数，我们可以将OPP + 指针传入，而不是传入额外的参数，用来处理一系列数据参数:: + + soc_cpufreq_target(..) + { + /* 做一些事情.. */ + max_freq = ULONG_MAX; + max_opp = dev_pm_opp_find_freq_floor(dev,&max_freq); + requested_opp = dev_pm_opp_find_freq_ceil(dev,&freq); + if (!IS_ERR(max_opp) && !IS_ERR(requested_opp)) + r = soc_test_validity(max_opp, requested_opp); + dev_pm_opp_put(max_opp); + dev_pm_opp_put(requested_opp); + /* 做其它事 */ + } + soc_test_validity(..) + { + if(dev_pm_opp_get_voltage(max_opp) < dev_pm_opp_get_voltage(requested_opp)) + return -EINVAL; + if(dev_pm_opp_get_freq(max_opp) < dev_pm_opp_get_freq(requested_opp)) + return -EINVAL; + /* 做一些事情.. */ + } + +dev_pm_opp_get_opp_count + 检索某个设备可用的OPP数量。 + 例子：假设SoC中的一个协处理器需要知道某个表中的可用频率，主处理器可以 + 按如下方式发出通知:: + + soc_notify_coproc_available_frequencies() + { + /* 做一些事情 */ + num_available = dev_pm_opp_get_opp_count(dev); + speeds = kzalloc(sizeof(u32) * num_available, GFP_KERNEL); + /* 按升序填充表 */ + freq = 0; + while (!IS_ERR(opp = dev_pm_opp_find_freq_ceil(dev, &freq))) { + speeds[i] = freq; + freq++; + i++; + dev_pm_opp_put(opp); + } + + soc_notify_coproc(AVAILABLE_FREQs, speeds, num_available); + /* 做其它事 */ + } + +6. 数据结构 +=========== +通常，一个SoC包含多个可变电压域。每个域由一个设备指针描述。和OPP之间的关系可以 +按以下方式描述:: + + SoC + |- device 1 + | |- opp 1 (availability, freq, voltage) + | |- opp 2 .. + ... ... + | `- opp n .. + |- device 2 + ... + `- device m + +OPP库维护着一个内部链表，SoC框架使用上文描述的各个函数来填充和访问。然而，描述 +真实OPP和域的结构体是OPP库自身的内部组成，以允许合适的抽象在不同系统中得到复用。 + +struct dev_pm_opp + OPP库的内部数据结构，用于表示一个OPP。除了频率、电压、可用性信息外， + 它还包含OPP库运行所需的内部统计信息。指向这个结构体的指针被提供给 + 用户（比如SoC框架）使用，在与OPP层的交互中作为OPP的标识符。 + + 警告： + 结构体dev_pm_opp的指针不应该由用户解析或修改。一个实例的默认值由 + dev_pm_opp_add填充，但OPP的可用性由dev_pm_opp_enable/disable函数 + 修改。 + +struct device + 这用于向OPP层标识一个域。设备的性质和它的实现是由OPP库的用户决定的， + 如SoC框架。 + +总体来说，以一个简化的视角看，对数据结构的操作可以描述为下面各图:: + + 初始化 / 修改: + +-----+ /- dev_pm_opp_enable + dev_pm_opp_add --> | opp | <------- + | +-----+ \- dev_pm_opp_disable + \-------> domain_info(device) + + 搜索函数: + /-- dev_pm_opp_find_freq_ceil ---\ +-----+ + domain_info<---- dev_pm_opp_find_freq_exact -----> | opp | + \-- dev_pm_opp_find_freq_floor ---/ +-----+ + + 检索函数: + +-----+ /- dev_pm_opp_get_voltage + | opp | <--- + +-----+ \- dev_pm_opp_get_freq + + domain_info <- dev_pm_opp_get_opp_count -- cgit From bf026e2e316ba57135b70e8ce591276239c7b2cf Mon Sep 17 00:00:00 2001 From: Thomas Gleixner Date: Mon, 10 Jan 2022 11:50:43 +0100 Subject: Documentation: Fill the gaps about entry/noinstr constraints The entry/exit handling for exceptions, interrupts, syscalls and KVM is not really documented except for some comments. Fill the gaps. Signed-off-by: Thomas Gleixner Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Mark Rutland Reviewed-by: Paul E. McKenney ---- Changes since v3: - s/nointr/noinstr/ Changes since v2: - No big content changes, just style corrections, so it should be pretty clean at this stage. In the light of this, I kept Mark's Reviewed-by. - Paul's style and paragraph re-writes - Randy's style comments - Add links to transition type sections Documentation/core-api/entry.rst | 261 +++++++++++++++++++++++++++++++ Documentation/core-api/index.rst | 8 + 2 files changed, 269 insertions(+) create mode 100644 Documentation/core-api/entry.rst Reviewed-by: Frederic Weisbecker Link: https://lore.kernel.org/r/20220110105044.94423-1-nsaenzju@redhat.com Signed-off-by: Jonathan Corbet --- Documentation/core-api/entry.rst | 261 +++++++++++++++++++++++++++++++++++++++ Documentation/core-api/index.rst | 8 ++ 2 files changed, 269 insertions(+) create mode 100644 Documentation/core-api/entry.rst (limited to 'Documentation') diff --git a/Documentation/core-api/entry.rst b/Documentation/core-api/entry.rst new file mode 100644 index 000000000000..c6f8e22c88fe --- /dev/null +++ b/Documentation/core-api/entry.rst @@ -0,0 +1,261 @@ +Entry/exit handling for exceptions, interrupts, syscalls and KVM +================================================================ + +All transitions between execution domains require state updates which are +subject to strict ordering constraints. State updates are required for the +following: + + * Lockdep + * RCU / Context tracking + * Preemption counter + * Tracing + * Time accounting + +The update order depends on the transition type and is explained below in +the transition type sections: `Syscalls`_, `KVM`_, `Interrupts and regular +exceptions`_, `NMI and NMI-like exceptions`_. + +Non-instrumentable code - noinstr +--------------------------------- + +Most instrumentation facilities depend on RCU, so intrumentation is prohibited +for entry code before RCU starts watching and exit code after RCU stops +watching. In addition, many architectures must save and restore register state, +which means that (for example) a breakpoint in the breakpoint entry code would +overwrite the debug registers of the initial breakpoint. + +Such code must be marked with the 'noinstr' attribute, placing that code into a +special section inaccessible to instrumentation and debug facilities. Some +functions are partially instrumentable, which is handled by marking them +noinstr and using instrumentation_begin() and instrumentation_end() to flag the +instrumentable ranges of code: + +.. code-block:: c + + noinstr void entry(void) + { + handle_entry(); // <-- must be 'noinstr' or '__always_inline' + ... + + instrumentation_begin(); + handle_context(); // <-- instrumentable code + instrumentation_end(); + + ... + handle_exit(); // <-- must be 'noinstr' or '__always_inline' + } + +This allows verification of the 'noinstr' restrictions via objtool on +supported architectures. + +Invoking non-instrumentable functions from instrumentable context has no +restrictions and is useful to protect e.g. state switching which would +cause malfunction if instrumented. + +All non-instrumentable entry/exit code sections before and after the RCU +state transitions must run with interrupts disabled. + +Syscalls +-------- + +Syscall-entry code starts in assembly code and calls out into low-level C code +after establishing low-level architecture-specific state and stack frames. This +low-level C code must not be instrumented. A typical syscall handling function +invoked from low-level assembly code looks like this: + +.. code-block:: c + + noinstr void syscall(struct pt_regs *regs, int nr) + { + arch_syscall_enter(regs); + nr = syscall_enter_from_user_mode(regs, nr); + + instrumentation_begin(); + if (!invoke_syscall(regs, nr) && nr != -1) + result_reg(regs) = __sys_ni_syscall(regs); + instrumentation_end(); + + syscall_exit_to_user_mode(regs); + } + +syscall_enter_from_user_mode() first invokes enter_from_user_mode() which +establishes state in the following order: + + * Lockdep + * RCU / Context tracking + * Tracing + +and then invokes the various entry work functions like ptrace, seccomp, audit, +syscall tracing, etc. After all that is done, the instrumentable invoke_syscall +function can be invoked. The instrumentable code section then ends, after which +syscall_exit_to_user_mode() is invoked. + +syscall_exit_to_user_mode() handles all work which needs to be done before +returning to user space like tracing, audit, signals, task work etc. After +that it invokes exit_to_user_mode() which again handles the state +transition in the reverse order: + + * Tracing + * RCU / Context tracking + * Lockdep + +syscall_enter_from_user_mode() and syscall_exit_to_user_mode() are also +available as fine grained subfunctions in cases where the architecture code +has to do extra work between the various steps. In such cases it has to +ensure that enter_from_user_mode() is called first on entry and +exit_to_user_mode() is called last on exit. + + +KVM +--- + +Entering or exiting guest mode is very similar to syscalls. From the host +kernel point of view the CPU goes off into user space when entering the +guest and returns to the kernel on exit. + +kvm_guest_enter_irqoff() is a KVM-specific variant of exit_to_user_mode() +and kvm_guest_exit_irqoff() is the KVM variant of enter_from_user_mode(). +The state operations have the same ordering. + +Task work handling is done separately for guest at the boundary of the +vcpu_run() loop via xfer_to_guest_mode_handle_work() which is a subset of +the work handled on return to user space. + +Interrupts and regular exceptions +--------------------------------- + +Interrupts entry and exit handling is slightly more complex than syscalls +and KVM transitions. + +If an interrupt is raised while the CPU executes in user space, the entry +and exit handling is exactly the same as for syscalls. + +If the interrupt is raised while the CPU executes in kernel space the entry and +exit handling is slightly different. RCU state is only updated when the +interrupt is raised in the context of the CPU's idle task. Otherwise, RCU will +already be watching. Lockdep and tracing have to be updated unconditionally. + +irqentry_enter() and irqentry_exit() provide the implementation for this. + +The architecture-specific part looks similar to syscall handling: + +.. code-block:: c + + noinstr void interrupt(struct pt_regs *regs, int nr) + { + arch_interrupt_enter(regs); + state = irqentry_enter(regs); + + instrumentation_begin(); + + irq_enter_rcu(); + invoke_irq_handler(regs, nr); + irq_exit_rcu(); + + instrumentation_end(); + + irqentry_exit(regs, state); + } + +Note that the invocation of the actual interrupt handler is within a +irq_enter_rcu() and irq_exit_rcu() pair. + +irq_enter_rcu() updates the preemption count which makes in_hardirq() +return true, handles NOHZ tick state and interrupt time accounting. This +means that up to the point where irq_enter_rcu() is invoked in_hardirq() +returns false. + +irq_exit_rcu() handles interrupt time accounting, undoes the preemption +count update and eventually handles soft interrupts and NOHZ tick state. + +In theory, the preemption count could be updated in irqentry_enter(). In +practice, deferring this update to irq_enter_rcu() allows the preemption-count +code to be traced, while also maintaining symmetry with irq_exit_rcu() and +irqentry_exit(), which are described in the next paragraph. The only downside +is that the early entry code up to irq_enter_rcu() must be aware that the +preemption count has not yet been updated with the HARDIRQ_OFFSET state. + +Note that irq_exit_rcu() must remove HARDIRQ_OFFSET from the preemption count +before it handles soft interrupts, whose handlers must run in BH context rather +than irq-disabled context. In addition, irqentry_exit() might schedule, which +also requires that HARDIRQ_OFFSET has been removed from the preemption count. + +NMI and NMI-like exceptions +--------------------------- + +NMIs and NMI-like exceptions (machine checks, double faults, debug +interrupts, etc.) can hit any context and must be extra careful with +the state. + +State changes for debug exceptions and machine-check exceptions depend on +whether these exceptions happened in user-space (breakpoints or watchpoints) or +in kernel mode (code patching). From user-space, they are treated like +interrupts, while from kernel mode they are treated like NMIs. + +NMIs and other NMI-like exceptions handle state transitions without +distinguishing between user-mode and kernel-mode origin. + +The state update on entry is handled in irqentry_nmi_enter() which updates +state in the following order: + + * Preemption counter + * Lockdep + * RCU / Context tracking + * Tracing + +The exit counterpart irqentry_nmi_exit() does the reverse operation in the +reverse order. + +Note that the update of the preemption counter has to be the first +operation on enter and the last operation on exit. The reason is that both +lockdep and RCU rely on in_nmi() returning true in this case. The +preemption count modification in the NMI entry/exit case must not be +traced. + +Architecture-specific code looks like this: + +.. code-block:: c + + noinstr void nmi(struct pt_regs *regs) + { + arch_nmi_enter(regs); + state = irqentry_nmi_enter(regs); + + instrumentation_begin(); + nmi_handler(regs); + instrumentation_end(); + + irqentry_nmi_exit(regs); + } + +and for e.g. a debug exception it can look like this: + +.. code-block:: c + + noinstr void debug(struct pt_regs *regs) + { + arch_nmi_enter(regs); + + debug_regs = save_debug_regs(); + + if (user_mode(regs)) { + state = irqentry_enter(regs); + + instrumentation_begin(); + user_mode_debug_handler(regs, debug_regs); + instrumentation_end(); + + irqentry_exit(regs, state); + } else { + state = irqentry_nmi_enter(regs); + + instrumentation_begin(); + kernel_mode_debug_handler(regs, debug_regs); + instrumentation_end(); + + irqentry_nmi_exit(regs, state); + } + } + +There is no combined irqentry_nmi_if_kernel() function available as the +above cannot be handled in an exception-agnostic way. diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index 5de2c7a4b1b3..972d46a5ddf6 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -44,6 +44,14 @@ Library functionality that is used throughout the kernel. timekeeping errseq +Low level entry and exit +======================== + +.. toctree:: + :maxdepth: 1 + + entry + Concurrency primitives ====================== -- cgit From e3aa43e936d854373d9a75372aefcefebfca208f Mon Sep 17 00:00:00 2001 From: Nicolas Saenz Julienne Date: Mon, 10 Jan 2022 11:50:44 +0100 Subject: Documentation: core-api: entry: Add comments about nesting The topic of nesting and reentrancy in the context of early entry code hasn't been addressed so far. So do it. Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Frederic Weisbecker Reviewed-by: Paul E. McKenney Link: https://lore.kernel.org/r/20220110105044.94423-2-nsaenzju@redhat.com Signed-off-by: Jonathan Corbet --- Documentation/core-api/entry.rst | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/core-api/entry.rst b/Documentation/core-api/entry.rst index c6f8e22c88fe..e12f22ab33c7 100644 --- a/Documentation/core-api/entry.rst +++ b/Documentation/core-api/entry.rst @@ -105,6 +105,8 @@ has to do extra work between the various steps. In such cases it has to ensure that enter_from_user_mode() is called first on entry and exit_to_user_mode() is called last on exit. +Do not nest syscalls. Nested systcalls will cause RCU and/or context tracking +to print a warning. KVM --- @@ -121,6 +123,8 @@ Task work handling is done separately for guest at the boundary of the vcpu_run() loop via xfer_to_guest_mode_handle_work() which is a subset of the work handled on return to user space. +Do not nest KVM entry/exit transitions because doing so is nonsensical. + Interrupts and regular exceptions --------------------------------- @@ -180,6 +184,16 @@ before it handles soft interrupts, whose handlers must run in BH context rather than irq-disabled context. In addition, irqentry_exit() might schedule, which also requires that HARDIRQ_OFFSET has been removed from the preemption count. +Even though interrupt handlers are expected to run with local interrupts +disabled, interrupt nesting is common from an entry/exit perspective. For +example, softirq handling happens within an irqentry_{enter,exit}() block with +local interrupts enabled. Also, although uncommon, nothing prevents an +interrupt handler from re-enabling interrupts. + +Interrupt entry/exit code doesn't strictly need to handle reentrancy, since it +runs with local interrupts disabled. But NMIs can happen anytime, and a lot of +the entry code is shared between the two. + NMI and NMI-like exceptions --------------------------- @@ -259,3 +273,7 @@ and for e.g. a debug exception it can look like this: There is no combined irqentry_nmi_if_kernel() function available as the above cannot be handled in an exception-agnostic way. + +NMIs can happen in any context. For example, an NMI-like exception triggered +while handling an NMI. So NMI entry code has to be reentrant and state updates +need to handle nesting. -- cgit From 9c3519d2b50968ded1373e872fcc34ca3d748007 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Tue, 11 Jan 2022 10:13:14 +0800 Subject: docs/zh_CN: add vm/index translation Translate ../vm/index.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Tang Yizhou Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/60c579b34792c4c76194c4843a695263a982b37d.1641866889.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/index.rst | 2 +- Documentation/translations/zh_CN/vm/index.rst | 52 +++++++++++++++++++++++++++ 2 files changed, 53 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/index.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 08144252630c..f831887eacfb 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -113,6 +113,7 @@ TODOList: sound/index filesystems/index scheduler/index + vm/index TODOList: @@ -140,7 +141,6 @@ TODOList: * gpu/index * security/index * crypto/index -* vm/index * bpf/index * usb/index * PCI/index diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst new file mode 100644 index 000000000000..0fda40c602ac --- /dev/null +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -0,0 +1,52 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/vm/index.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + +================= +Linux内存管理文档 +================= + +这是一个关于Linux内存管理（mm）子系统内部的文档集，其中有不同层次的细节，包括注释 +和邮件列表的回复，用于阐述数据结构和算法的基本情况。如果你正在寻找关于简单分配内存的建 +议，请参阅(Documentation/translations/zh_CN/core-api/memory-allocation.rst)。 +对于控制和调整指南，请参阅(Documentation/admin-guide/mm/index)。 +TODO:待引用文档集被翻译完毕后请及时修改此处） + +.. toctree:: + :maxdepth: 1 + + +TODOLIST: +* active_mm +* arch_pgtable_helpers +* balance +* damon/index +* free_page_reporting +* frontswap +* highmem +* hmm +* hwpoison +* hugetlbfs_reserv +* ksm +* memory-model +* mmu_notifier +* numa +* overcommit-accounting +* page_migration +* page_frags +* page_owner +* page_table_check +* remap_file_pages +* slub +* split_page_table_lock +* transhuge +* unevictable-lru +* vmalloced-kernel-stacks +* z3fold +* zsmalloc -- cgit From 6f5dbb213c140f04fc6d49b70b178ee11333c5f3 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Tue, 11 Jan 2022 10:13:15 +0800 Subject: docs_zh_CN: add active_mm translation Translatr .../vm/active_mm.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Reviewed-by: Tang Yizhou Link: https://lore.kernel.org/r/99ba014bdd9550bad57db6c21653cb7314d7c2d8.1641866889.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/active_mm.rst | 85 +++++++++++++++++++++++ Documentation/translations/zh_CN/vm/index.rst | 2 +- 2 files changed, 86 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/active_mm.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/active_mm.rst b/Documentation/translations/zh_CN/vm/active_mm.rst new file mode 100644 index 000000000000..366609ea4f37 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/active_mm.rst @@ -0,0 +1,85 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/vm/active_mm.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +========= +Active MM +========= + +这是一封linux之父回复开发者的一封邮件，所以翻译时我尽量保持邮件格式的完整。 + +:: + + List: linux-kernel + Subject: Re: active_mm + From: Linus Torvalds + Date: 1999-07-30 21:36:24 + + 因为我并不经常写解释，所以已经抄送到linux-kernel邮件列表，而当我做这些， + 且更多的人在阅读它们时，我觉得棒极了。 + + 1999年7月30日 星期五， David Mosberger 写道： + > + > 是否有一个简短的描述，说明task_struct中的 + > "mm" 和 "active_mm"应该如何使用？ (如果 + > 这个问题在邮件列表中讨论过，我表示歉意--我刚 + > 刚度假回来，有一段时间没能关注linux-kernel了）。 + + 基本上，新的设定是： + + - 我们有“真实地址空间”和“匿名地址空间”。区别在于，匿名地址空间根本不关心用 + 户级页表，所以当我们做上下文切换到匿名地址空间时，我们只是让以前的地址空间 + 处于活动状态。 + + 一个“匿名地址空间”的明显用途是任何不需要任何用户映射的线程--所有的内核线 + 程基本上都属于这一类，但即使是“真正的”线程也可以暂时说在一定时间内它们不 + 会对用户空间感兴趣，调度器不妨试着避免在切换VM状态上浪费时间。目前只有老 + 式的bdflush sync能做到这一点。 + + - “tsk->mm” 指向 “真实地址空间”。对于一个匿名进程来说，tsk->mm将是NULL， + 其逻辑原因是匿名进程实际上根本就 “没有” 真正的地址空间。 + + - 然而，我们显然需要跟踪我们为这样的匿名用户“偷用”了哪个地址空间。为此，我们 + 有 “tsk->active_mm”，它显示了当前活动的地址空间是什么。 + + 规则是，对于一个有真实地址空间的进程（即tsk->mm是 non-NULL），active_mm + 显然必须与真实的mm相同。 + + 对于一个匿名进程，tsk->mm == NULL，而tsk->active_mm是匿名进程运行时 + “借用”的mm。当匿名进程被调度走时，借用的地址空间被返回并清除。 + + 为了支持所有这些，“struct mm_struct”现在有两个计数器：一个是 “mm_users” + 计数器，即有多少 “真正的地址空间用户”，另一个是 “mm_count”计数器，即 “lazy” + 用户（即匿名用户）的数量，如果有任何真正的用户，则加1。 + + 通常情况下，至少有一个真正的用户，但也可能是真正的用户在另一个CPU上退出，而 + 一个lazy的用户仍在活动，所以你实际上得到的情况是，你有一个地址空间 **只** + 被lazy的用户使用。这通常是一个短暂的生命周期状态，因为一旦这个线程被安排给一 + 个真正的线程，这个 “僵尸” mm就会被释放，因为 “mm_count”变成了零。 + + 另外，一个新的规则是，**没有人** 再把 “init_mm” 作为一个真正的MM了。 + “init_mm”应该被认为只是一个 “没有其他上下文时的lazy上下文”，事实上，它主 + 要是在启动时使用，当时还没有真正的VM被创建。因此，用来检查的代码 + + if (current->mm == &init_mm) + + 一般来说，应该用 + + if (!current->mm) + + 取代上面的写法（这更有意义--测试基本上是 “我们是否有一个用户环境”，并且通常 + 由缺页异常处理程序和类似的东西来完成）。 + + 总之，我刚才在ftp.kernel.org上放了一个pre-patch-2.3.13-1，因为它稍微改 + 变了接口以适配alpha（谁会想到呢，但alpha体系结构上下文切换代码实际上最终是 + 最丑陋的之一--不像其他架构的MM和寄存器状态是分开的，alpha的PALcode将两者 + 连接起来，你需要同时切换两者）。 + + (文档来源 http://marc.info/?l=linux-kernel&m=93337278602211&w=2) diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index 0fda40c602ac..5fcdb75d8682 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -21,9 +21,9 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） .. toctree:: :maxdepth: 1 + active_mm TODOLIST: -* active_mm * arch_pgtable_helpers * balance * damon/index -- cgit From 88ba790d84e98b6f030c8efc8d3e9f042c0ab777 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Tue, 11 Jan 2022 10:13:16 +0800 Subject: docs/zh_CN: add balance translation Translate .../vm/balance.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Reviewed-by: Tang Yizhou Link: https://lore.kernel.org/r/f1e5a6bcbee3e34fe65a56ee185d9b44daf01cab.1641866889.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/balance.rst | 81 +++++++++++++++++++++++++ Documentation/translations/zh_CN/vm/index.rst | 2 +- 2 files changed, 82 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/balance.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/balance.rst b/Documentation/translations/zh_CN/vm/balance.rst new file mode 100644 index 000000000000..e98a47ef24a8 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/balance.rst @@ -0,0 +1,81 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/vm/balance.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +======== +内存平衡 +======== + +2000年1月开始，作者：Kanoj Sarcar + +对于 !__GFP_HIGH 和 !__GFP_KSWAPD_RECLAIM 以及非 __GFP_IO 的分配，需要进行 +内存平衡。 + +调用者避免回收的第一个原因是调用者由于持有自旋锁或处于中断环境中而无法睡眠。第二个 +原因可能是，调用者愿意在不产生页面回收开销的情况下分配失败。这可能发生在有0阶回退 +选项的机会主义高阶分配请求中。在这种情况下，调用者可能也希望避免唤醒kswapd。 + +__GFP_IO分配请求是为了防止文件系统死锁。 + +在没有非睡眠分配请求的情况下，做平衡似乎是有害的。页面回收可以被懒散地启动，也就是 +说，只有在需要的时候（也就是区域的空闲内存为0），而不是让它成为一个主动的过程。 + +也就是说，内核应该尝试从直接映射池中满足对直接映射页的请求，而不是回退到dma池中， +这样就可以保持dma池为dma请求（不管是不是原子的）所填充。类似的争论也适用于高内存 +和直接映射的页面。相反，如果有很多空闲的dma页，最好是通过从dma池中分配一个来满足 +常规的内存请求，而不是产生常规区域平衡的开销。 + +在2.2中，只有当空闲页总数低于总内存的1/64时，才会启动内存平衡/页面回收。如果dma +和常规内存的比例合适，即使dma区完全空了，也很可能不会进行平衡。2.2已经在不同内存 +大小的生产机器上运行，即使有这个问题存在，似乎也做得不错。在2.3中，由于HIGHMEM的 +存在，这个问题变得更加严重。 + +在2.3中，区域平衡可以用两种方式之一来完成：根据区域的大小（可能是低级区域的大小）， +我们可以在初始化阶段决定在平衡任何区域时应该争取多少空闲页。好的方面是，在平衡的时 +候，我们不需要看低级区的大小，坏的方面是，我们可能会因为忽略低级区可能较低的使用率 +而做过于频繁的平衡。另外，只要对分配程序稍作修改，就有可能将memclass()宏简化为一 +个简单的等式。 + +另一个可能的解决方案是，我们只在一个区 **和** 其所有低级区的空闲内存低于该区及其 +低级区总内存的1/64时进行平衡。这就解决了2.2的平衡问题，并尽可能地保持了与2.2行为 +的接近。另外，平衡算法在各种架构上的工作方式也是一样的，这些架构有不同数量和类型的 +内存区。如果我们想变得更花哨一点，我们可以在未来为不同区域的自由页面分配不同的权重。 + +请注意，如果普通区的大小与dma区相比是巨大的，那么在决定是否平衡普通区的时候，考虑 +空闲的dma页就变得不那么重要了。那么第一个解决方案就变得更有吸引力。 + +所附的补丁实现了第二个解决方案。它还 “修复”了两个问题：首先，在低内存条件下，kswapd +被唤醒，就像2.2中的非睡眠分配。第二，HIGHMEM区也被平衡了，以便给replace_with_highmem() +一个争取获得HIGHMEM页的机会，同时确保HIGHMEM分配不会落回普通区。这也确保了HIGHMEM +页不会被泄露（例如，在一个HIGHMEM页在交换缓存中但没有被任何人使用的情况下）。 + +kswapd还需要知道它应该平衡哪些区。kswapd主要是在无法进行平衡的情况下需要的，可能 +是因为所有的分配请求都来自中断上下文，而所有的进程上下文都在睡眠。对于2.3， +kswapd并不真正需要平衡高内存区，因为中断上下文并不请求高内存页。kswapd看zone +结构体中的zone_wake_kswapd字段来决定一个区是否需要平衡。 + +如果从进程内存和shm中偷取页面可以减轻该页面节点中任何区的内存压力，而该区的内存压力 +已经低于其水位，则会进行偷取。 + +watemark[WMARK_MIN/WMARK_LOW/WMARK_HIGH]/low_on_memory/zone_wake_kswapd： +这些是每个区的字段，用于确定一个区何时需要平衡。当页面数低于水位[WMARK_MIN]时， +hysteric 的字段low_on_memory被设置。这个字段会一直被设置，直到空闲页数变成水位 +[WMARK_HIGH]。当low_on_memory被设置时，页面分配请求将尝试释放该区域的一些页面（如果 +请求中设置了GFP_WAIT）。与此相反的是，决定唤醒kswapd以释放一些区的页。这个决定不是基于 +hysteresis 的，而是当空闲页的数量低于watermark[WMARK_LOW]时就会进行；在这种情况下， +zone_wake_kswapd也被设置。 + + +我所听到的（超棒的）想法： + +1. 动态经历应该影响平衡：可以跟踪一个区的失败请求的数量，并反馈到平衡方案中（jalvo@mbay.net）。 + +2. 实现一个类似于replace_with_highmem()的replace_with_regular()，以保留dma页面。 + (lkd@tantalophile.demon.co.uk) diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index 5fcdb75d8682..fc39f0d60318 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -22,10 +22,10 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） :maxdepth: 1 active_mm + balance TODOLIST: * arch_pgtable_helpers -* balance * damon/index * free_page_reporting * frontswap -- cgit From 2701b511e491f95d829a340c2540d602db5c63d8 Mon Sep 17 00:00:00 2001 From: wangyong Date: Wed, 12 Jan 2022 08:04:42 -0800 Subject: docs/zh_CN: Update zh_CN/accounting/delay-accounting.rst Update zh_CN/accounting/delay-accounting.rst. The document modification has been merged which refers to the following link: https://lore.kernel.org/all/1639583021-92977-1-git-send-email-wang.yong12@zte.com.cn/ Signed-off-by: wangyong Reviewed-by: Yang Yang Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/1642003482-48935-1-git-send-email-wang.yong12@zte.com.cn Signed-off-by: Jonathan Corbet --- .../zh_CN/accounting/delay-accounting.rst | 62 +++++++++++----------- 1 file changed, 30 insertions(+), 32 deletions(-) (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/accounting/delay-accounting.rst b/Documentation/translations/zh_CN/accounting/delay-accounting.rst index 67d5606e5401..f1849411018e 100644 --- a/Documentation/translations/zh_CN/accounting/delay-accounting.rst +++ b/Documentation/translations/zh_CN/accounting/delay-accounting.rst @@ -17,6 +17,8 @@ a) 等待一个CPU（任务为可运行） b) 完成由该任务发起的块I/O同步请求 c) 页面交换 d) 内存回收 +e) 页缓存抖动 +f) 直接规整 并将这些统计信息通过taskstats接口提供给用户空间。 @@ -37,10 +39,10 @@ d) 内存回收 向用户态返回一个通用数据结构，对应每pid或每tgid的统计信息。延时计数功能填写 该数据结构的特定字段。见 - include/linux/taskstats.h + include/uapi/linux/taskstats.h 其描述了延时计数相关字段。系统通常以计数器形式返回 CPU、同步块 I/O、交换、内存 -回收等的累积延时。 +回收、页缓存抖动、直接规整等的累积延时。 取任务某计数器两个连续读数的差值，将得到任务在该时间间隔内等待对应资源的总延时。 @@ -72,40 +74,36 @@ kernel.task_delayacct进行开关。注意，只有在启用延时计数后启 getdelays命令的一般格式:: - getdelays [-t tgid] [-p pid] [-c cmd...] + getdelays [-dilv] [-t tgid] [-p pid] 获取pid为10的任务从系统启动后的延时信息:: - # ./getdelays -p 10 + # ./getdelays -d -p 10 （输出信息和下例相似） 获取所有tgid为5的任务从系统启动后的总延时信息:: - # ./getdelays -t 5 - - - CPU count real total virtual total delay total - 7876 92005750 100000000 24001500 - IO count delay total - 0 0 - SWAP count delay total - 0 0 - RECLAIM count delay total - 0 0 - -获取指定简单命令运行时的延时信息:: - - # ./getdelays -c ls / - - bin data1 data3 data5 dev home media opt root srv sys usr - boot data2 data4 data6 etc lib mnt proc sbin subdomain tmp var - - - CPU count real total virtual total delay total - 6 4000250 4000000 0 - IO count delay total - 0 0 - SWAP count delay total - 0 0 - RECLAIM count delay total - 0 0 + # ./getdelays -d -t 5 + print delayacct stats ON + TGID 5 + + + CPU count real total virtual total delay total delay average + 8 7000000 6872122 3382277 0.423ms + IO count delay total delay average + 0 0 0ms + SWAP count delay total delay average + 0 0 0ms + RECLAIM count delay total delay average + 0 0 0ms + THRASHING count delay total delay average + 0 0 0ms + COMPACT count delay total delay average + 0 0 0ms + +获取pid为1的IO计数，它只和-p一起使用:: + # ./getdelays -i -p 1 + printing IO accounting + linuxrc: read=65536, write=0, cancelled_write=0 + +上面的命令与-v一起使用，可以获取更多调试信息。 -- cgit From e2d99027da08a816ba63d0b8335dbde0ec1152c6 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Sat, 15 Jan 2022 15:15:00 +0800 Subject: docs/zh_CN: add damon index tronslation 1) Translate .../vm/damon/index.rst into Chinese. 2) add damon into .../zh_CN/vm/index.rst Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/8e8c7651785f1ce20766bc1b3a4fc44faedb84bb.1642230669.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/vm/damon/index.rst | 33 ++++++++++++++++++++++ Documentation/translations/zh_CN/vm/index.rst | 2 +- 2 files changed, 34 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/damon/index.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/damon/index.rst b/Documentation/translations/zh_CN/vm/damon/index.rst new file mode 100644 index 000000000000..9a7b4ea91cb8 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/damon/index.rst @@ -0,0 +1,33 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:Original: Documentation/vm/damon/index.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +========================== +DAMON:数据访问监视器 +========================== + +DAMON是Linux内核的一个数据访问监控框架子系统。DAMON的核心机制使其成为 +（该核心机制详见(Documentation/translations/zh_CN/vm/damon/design.rst)） + + - *准确度* （监测输出对DRAM级别的内存管理足够有用；但可能不适合CPU Cache级别）， + - *轻量级* （监控开销低到可以在线应用），以及 + - *可扩展* （无论目标工作负载的大小，开销的上限值都在恒定范围内）。 + +因此，利用这个框架，内核的内存管理机制可以做出高级决策。会导致高数据访问监控开销的实 +验性内存管理优化工作可以再次进行。同时，在用户空间，有一些特殊工作负载的用户可以编写 +个性化的应用程序，以便更好地了解和优化他们的工作负载和系统。 + +.. toctree:: + :maxdepth: 2 + +TODOLIST: +* faq +* design +* api diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index fc39f0d60318..432bc3ef1c18 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -23,10 +23,10 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） active_mm balance + damon/index TODOLIST: * arch_pgtable_helpers -* damon/index * free_page_reporting * frontswap * highmem -- cgit From 3fd8816219311289eaec2eb9bc389146a553fe4e Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Sat, 15 Jan 2022 15:15:01 +0800 Subject: docs/zh_CN: add damon faq translation Translate .../vm/damon/faq.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/30507f807a835360f57bb9498c37f4c3644b33b7.1642230669.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/damon/faq.rst | 48 ++++++++++++++++++++++ .../translations/zh_CN/vm/damon/index.rst | 4 +- 2 files changed, 51 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/damon/faq.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/damon/faq.rst b/Documentation/translations/zh_CN/vm/damon/faq.rst new file mode 100644 index 000000000000..07b4ac19407d --- /dev/null +++ b/Documentation/translations/zh_CN/vm/damon/faq.rst @@ -0,0 +1,48 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:Original: Documentation/vm/damon/faq.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +======== +常见问题 +======== + +为什么是一个新的子系统，而不是扩展perf或其他用户空间工具？ +========================================================== + +首先，因为它需要尽可能的轻量级，以便可以在线使用，所以应该避免任何不必要的开销，如内核-用户 +空间的上下文切换成本。第二，DAMON的目标是被包括内核在内的其他程序所使用。因此，对特定工具 +（如perf）的依赖性是不可取的。这就是DAMON在内核空间实现的两个最大的原因。 + + +“闲置页面跟踪” 或 “perf mem” 可以替代DAMON吗？ +============================================== + +闲置页跟踪是物理地址空间访问检查的一个低层次的原始方法。“perf mem”也是类似的，尽管它可以 +使用采样来减少开销。另一方面，DAMON是一个更高层次的框架，用于监控各种地址空间。它专注于内 +存管理优化，并提供复杂的精度/开销处理机制。因此，“空闲页面跟踪” 和 “perf mem” 可以提供 +DAMON输出的一个子集，但不能替代DAMON。 + + +DAMON是否只支持虚拟内存？ +========================= + +不，DAMON的核心是独立于地址空间的。用户可以在DAMON核心上实现和配置特定地址空间的低级原始 +部分，包括监测目标区域的构造和实际的访问检查。通过这种方式，DAMON用户可以用任何访问检查技 +术来监测任何地址空间。 + +尽管如此，DAMON默认为虚拟内存和物理内存提供了基于vma/rmap跟踪和PTE访问位检查的地址空间 +相关功能的实现，以供参考和方便使用。 + + +我可以简单地监测页面的粒度吗？ +============================== + +是的，你可以通过设置 ``min_nr_regions`` 属性高于工作集大小除以页面大小的值来实现。 +因为监视目标区域的大小被强制为 ``>=page size`` ，所以区域分割不会产生任何影响。 diff --git a/Documentation/translations/zh_CN/vm/damon/index.rst b/Documentation/translations/zh_CN/vm/damon/index.rst index 9a7b4ea91cb8..dfa82244cbe8 100644 --- a/Documentation/translations/zh_CN/vm/damon/index.rst +++ b/Documentation/translations/zh_CN/vm/damon/index.rst @@ -27,7 +27,9 @@ DAMON是Linux内核的一个数据访问监控框架子系统。DAMON的核心 .. toctree:: :maxdepth: 2 + faq + TODOLIST: -* faq + * design * api -- cgit From 18e74934dc4a65ff1dfb24b83f9778ded0f247dd Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Sat, 15 Jan 2022 15:15:02 +0800 Subject: docs/zh_CN: add damon design translation Translate .../vm/damon/design.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/2685ed7d446620b260c20158685728c3adb5e0fe.1642230669.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/vm/damon/design.rst | 139 +++++++++++++++++++++ .../translations/zh_CN/vm/damon/index.rst | 2 +- 2 files changed, 140 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/damon/design.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/damon/design.rst b/Documentation/translations/zh_CN/vm/damon/design.rst new file mode 100644 index 000000000000..05f66c02740a --- /dev/null +++ b/Documentation/translations/zh_CN/vm/damon/design.rst @@ -0,0 +1,139 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:Original: Documentation/vm/damon/design.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +==== +设计 +==== + +可配置的层 +========== + +DAMON提供了数据访问监控功能，同时使其准确性和开销可控。基本的访问监控需要依赖于目标地址空间 +并为之优化的基元。另一方面，作为DAMON的核心，准确性和开销的权衡机制是在纯逻辑空间中。DAMON +将这两部分分离在不同的层中，并定义了它的接口，以允许各种低层次的基元实现与核心逻辑的配置。 + +由于这种分离的设计和可配置的接口，用户可以通过配置核心逻辑和适当的低级基元实现来扩展DAMON的 +任何地址空间。如果没有提供合适的，用户可以自己实现基元。 + +例如，物理内存、虚拟内存、交换空间、那些特定的进程、NUMA节点、文件和支持的内存设备将被支持。 +另外，如果某些架构或设备支持特殊的优化访问检查基元，这些基元将很容易被配置。 + + +特定地址空间基元的参考实现 +========================== + +基本访问监测的低级基元被定义为两部分。: + +1. 确定地址空间的监测目标地址范围 +2. 目标空间中特定地址范围的访问检查。 + +DAMON目前为物理和虚拟地址空间提供了基元的实现。下面两个小节描述了这些工作的方式。 + + +基于VMA的目标地址范围构造 +------------------------- + +这仅仅是针对虚拟地址空间基元的实现。对于物理地址空间，只是要求用户手动设置监控目标地址范围。 + +在进程的超级巨大的虚拟地址空间中，只有小部分被映射到物理内存并被访问。因此，跟踪未映射的地 +址区域只是一种浪费。然而，由于DAMON可以使用自适应区域调整机制来处理一定程度的噪声，所以严 +格来说，跟踪每一个映射并不是必须的，但在某些情况下甚至会产生很高的开销。也就是说，监测目标 +内部过于巨大的未映射区域应该被移除，以不占用自适应机制的时间。 + +出于这个原因，这个实现将复杂的映射转换为三个不同的区域，覆盖地址空间的每个映射区域。这三个 +区域之间的两个空隙是给定地址空间中两个最大的未映射区域。这两个最大的未映射区域是堆和最上面 +的mmap()区域之间的间隙，以及在大多数情况下最下面的mmap()区域和堆之间的间隙。因为这些间隙 +在通常的地址空间中是异常巨大的，排除这些间隙就足以做出合理的权衡。下面详细说明了这一点:: + + + + + (small mmap()-ed regions and munmap()-ed regions) + + + + + +基于PTE访问位的访问检查 +----------------------- + +物理和虚拟地址空间的实现都使用PTE Accessed-bit进行基本访问检查。唯一的区别在于从地址中 +找到相关的PTE访问位的方式。虚拟地址的实现是为该地址的目标任务查找页表，而物理地址的实现则 +是查找与该地址有映射关系的每一个页表。通过这种方式，实现者找到并清除下一个采样目标地址的位， +并检查该位是否在一个采样周期后再次设置。这可能会干扰其他使用访问位的内核子系统，即空闲页跟 +踪和回收逻辑。为了避免这种干扰，DAMON使其与空闲页面跟踪相互排斥，并使用 ``PG_idle`` 和 +``PG_young`` 页面标志来解决与回收逻辑的冲突，就像空闲页面跟踪那样。 + + +独立于地址空间的核心机制 +======================== + +下面四个部分分别描述了DAMON的核心机制和五个监测属性，即 ``采样间隔`` 、 ``聚集间隔`` 、 +``区域更新间隔`` 、 ``最小区域数`` 和 ``最大区域数`` 。 + + +访问频率监测 +------------ + +DAMON的输出显示了在给定的时间内哪些页面的访问频率是多少。访问频率的分辨率是通过设置 +``采样间隔`` 和 ``聚集间隔`` 来控制的。详细地说，DAMON检查每个 ``采样间隔`` 对每 +个页面的访问，并将结果汇总。换句话说，计算每个页面的访问次数。在每个 ``聚合间隔`` 过 +去后，DAMON调用先前由用户注册的回调函数，以便用户可以阅读聚合的结果，然后再清除这些结 +果。这可以用以下简单的伪代码来描述:: + + while monitoring_on: + for page in monitoring_target: + if accessed(page): + nr_accesses[page] += 1 + if time() % aggregation_interval == 0: + for callback in user_registered_callbacks: + callback(monitoring_target, nr_accesses) + for page in monitoring_target: + nr_accesses[page] = 0 + sleep(sampling interval) + +这种机制的监测开销将随着目标工作负载规模的增长而任意增加。 + + +基于区域的抽样调查 +------------------ + +为了避免开销的无限制增加，DAMON将假定具有相同访问频率的相邻页面归入一个区域。只要保持 +这个假设（一个区域内的页面具有相同的访问频率），该区域内就只需要检查一个页面。因此，对 +于每个 ``采样间隔`` ，DAMON在每个区域中随机挑选一个页面，等待一个 ``采样间隔`` ，检 +查该页面是否同时被访问，如果被访问则增加该区域的访问频率。因此，监测开销是可以通过设置 +区域的数量来控制的。DAMON允许用户设置最小和最大的区域数量来进行权衡。 + +然而，如果假设没有得到保证，这个方案就不能保持输出的质量。 + + +适应性区域调整 +-------------- + +即使最初的监测目标区域被很好地构建以满足假设（同一区域内的页面具有相似的访问频率），数 +据访问模式也会被动态地改变。这将导致监测质量下降。为了尽可能地保持假设，DAMON根据每个 +区域的访问频率自适应地进行合并和拆分。 + +对于每个 ``聚集区间`` ，它比较相邻区域的访问频率，如果频率差异较小，就合并这些区域。 +然后，在它报告并清除每个区域的聚合接入频率后，如果区域总数不超过用户指定的最大区域数， +它将每个区域拆分为两个或三个区域。 + +通过这种方式，DAMON提供了其最佳的质量和最小的开销，同时保持了用户为其权衡设定的界限。 + + +动态目标空间更新处理 +-------------------- + +监测目标地址范围可以动态改变。例如，虚拟内存可以动态地被映射和解映射。物理内存可以被 +热插拔。 + +由于在某些情况下变化可能相当频繁，DAMON检查动态内存映射的变化，并仅在用户指定的时间 +间隔（ ``区域更新间隔`` ）内将其应用于抽象的目标区域。 diff --git a/Documentation/translations/zh_CN/vm/damon/index.rst b/Documentation/translations/zh_CN/vm/damon/index.rst index dfa82244cbe8..077db7e4326f 100644 --- a/Documentation/translations/zh_CN/vm/damon/index.rst +++ b/Documentation/translations/zh_CN/vm/damon/index.rst @@ -28,8 +28,8 @@ DAMON是Linux内核的一个数据访问监控框架子系统。DAMON的核心 :maxdepth: 2 faq + design TODOLIST: -* design * api -- cgit From 722cc663d79c80051cbd57de0336582c8e3cbf93 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Sat, 15 Jan 2022 15:15:03 +0800 Subject: docs/zh_CN: add damon api translation Translate .../vm/damon/api.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/3d81dbc79e0f982edd68fb9dfee6f0ccb47f7710.1642230669.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/damon/api.rst | 32 ++++++++++++++++++++++ .../translations/zh_CN/vm/damon/index.rst | 4 +-- 2 files changed, 33 insertions(+), 3 deletions(-) create mode 100644 Documentation/translations/zh_CN/vm/damon/api.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/damon/api.rst b/Documentation/translations/zh_CN/vm/damon/api.rst new file mode 100644 index 000000000000..21143eea4ebe --- /dev/null +++ b/Documentation/translations/zh_CN/vm/damon/api.rst @@ -0,0 +1,32 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:Original: Documentation/vm/damon/api.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +======= +API参考 +======= + +内核空间的程序可以使用下面的API来使用DAMON的每个功能。你所需要做的就是引用 ``damon.h`` ， +它位于源代码树的include/linux/。 + +结构体 +====== + +该API在以下内核代码中: + +include/linux/damon.h + + +函数 +==== + +该API在以下内核代码中: + +mm/damon/core.c diff --git a/Documentation/translations/zh_CN/vm/damon/index.rst b/Documentation/translations/zh_CN/vm/damon/index.rst index 077db7e4326f..84d36d90c9b0 100644 --- a/Documentation/translations/zh_CN/vm/damon/index.rst +++ b/Documentation/translations/zh_CN/vm/damon/index.rst @@ -29,7 +29,5 @@ DAMON是Linux内核的一个数据访问监控框架子系统。DAMON的核心 faq design + api -TODOLIST: - -* api -- cgit From adeacecbd36cb820f65e93194baba17decdded32 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Thu, 27 Jan 2022 09:47:53 +0800 Subject: docs/zh_CN: add free_page_reporting translation Translate .../vm/free_page_reporting.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/4ef77c1be8319fc45b18e9f4c41986095d794562.1643246827.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/vm/free_page_reporting.rst | 38 ++++++++++++++++++++++ Documentation/translations/zh_CN/vm/index.rst | 2 +- 2 files changed, 39 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/free_page_reporting.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/free_page_reporting.rst b/Documentation/translations/zh_CN/vm/free_page_reporting.rst new file mode 100644 index 000000000000..31d6c34b956b --- /dev/null +++ b/Documentation/translations/zh_CN/vm/free_page_reporting.rst @@ -0,0 +1,38 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/vm/_free_page_reporting.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + +========== +空闲页报告 +========== + +空闲页报告是一个API，设备可以通过它来注册接收系统当前未使用的页面列表。这在虚拟 +化的情况下是很有用的，客户机能够使用这些数据来通知管理器它不再使用内存中的某些页 +面。 + +对于驱动，通常是气球驱动要使用这个功能，它将分配和初始化一个page_reporting_dev_info +结构体。它要填充的结构体中的字段是用于处理散点列表的 "report" 函数指针。它还必 +须保证每次调用该函数时能处理至少相当于PAGE_REPORTING_CAPACITY的散点列表条目。 +假设没有其他页面报告设备已经注册， 对page_reporting_register的调用将向报告框 +架注册页面报告接口。 + +一旦注册，页面报告API将开始向驱动报告成批的页面。API将在接口被注册后2秒开始报告 +页面，并在任何足够高的页面被释放之后2秒继续报告。 + +报告的页面将被存储在传递给报告函数的散列表中，最后一个条目的结束位被设置在条目 +nent-1中。 当页面被报告函数处理时，分配器将无法访问它们。一旦报告函数完成，这些 +页将被返回到它们所获得的自由区域。 + +在移除使用空闲页报告的驱动之前，有必要调用page_reporting_unregister，以移除 +目前被空闲页报告使用的page_reporting_dev_info结构体。这样做将阻止进一步的报 +告通过该接口发出。如果另一个驱动或同一驱动被注册，它就有可能恢复前一个驱动在报告 +空闲页方面的工作。 + + +Alexander Duyck, 2019年12月04日 diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index 432bc3ef1c18..13df8321f242 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -24,6 +24,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） active_mm balance damon/index + free_page_reporting TODOLIST: * arch_pgtable_helpers @@ -33,7 +34,6 @@ TODOLIST: * hmm * hwpoison * hugetlbfs_reserv -* ksm * memory-model * mmu_notifier * numa -- cgit From 4c97fdb06b9884da8682c869303b659a25c0b952 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Thu, 27 Jan 2022 09:47:54 +0800 Subject: docs/zh_CN: add highmem translation Translate .../vm/highmem.rst into Chenese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/51e088d1e8659b9411534a5a3ad03d88c79a5297.1643246827.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/highmem.rst | 128 ++++++++++++++++++++++++ Documentation/translations/zh_CN/vm/index.rst | 2 +- 2 files changed, 129 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/highmem.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/highmem.rst b/Documentation/translations/zh_CN/vm/highmem.rst new file mode 100644 index 000000000000..018838e58c3e --- /dev/null +++ b/Documentation/translations/zh_CN/vm/highmem.rst @@ -0,0 +1,128 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/vm/highmem.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + +========== +高内存处理 +========== + +作者: Peter Zijlstra + +.. contents:: :local: + +高内存是什么？ +============== + +当物理内存的大小接近或超过虚拟内存的最大大小时，就会使用高内存（highmem）。在这一点上，内 +核不可能在任何时候都保持所有可用的物理内存的映射。这意味着内核需要开始使用它想访问的物理内 +存的临时映射。 + +没有被永久映射覆盖的那部分（物理）内存就是我们所说的 "高内存"。对于这个边界的确切位置，有 +各种架构上的限制。 + +例如，在i386架构中，我们选择将内核映射到每个进程的虚拟空间，这样我们就不必为内核的进入/退 +出付出全部的TLB作废代价。这意味着可用的虚拟内存空间（i386上为4GiB）必须在用户和内核空间之 +间进行划分。 + +使用这种方法的架构的传统分配方式是3:1，3GiB用于用户空间，顶部的1GiB用于内核空间。:: + + +--------+ 0xffffffff + | Kernel | + +--------+ 0xc0000000 + | | + | User | + | | + +--------+ 0x00000000 + +这意味着内核在任何时候最多可以映射1GiB的物理内存，但是由于我们需要虚拟地址空间来做其他事 +情--包括访问其余物理内存的临时映射--实际的直接映射通常会更少（通常在~896MiB左右）。 + +其他有mm上下文标签的TLB的架构可以有独立的内核和用户映射。然而，一些硬件（如一些ARM）在使 +用mm上下文标签时，其虚拟空间有限。 + + +临时虚拟映射 +============ + +内核包含几种创建临时映射的方法。: + +* vmap(). 这可以用来将多个物理页长期映射到一个连续的虚拟空间。它需要synchronization + 来解除映射。 + +* kmap(). 这允许对单个页面进行短期映射。它需要synchronization，但在一定程度上被摊销。 + 当以嵌套方式使用时，它也很容易出现死锁，因此不建议在新代码中使用它。 + +* kmap_atomic(). 这允许对单个页面进行非常短的时间映射。由于映射被限制在发布它的CPU上， + 它表现得很好，但发布任务因此被要求留在该CPU上直到它完成，以免其他任务取代它的映射。 + + kmap_atomic() 也可以由中断上下文使用，因为它不睡眠，而且调用者可能在调用kunmap_atomic() + 之后才睡眠。 + + 可以假设k[un]map_atomic()不会失败。 + + +使用kmap_atomic +=============== + +何时何地使用 kmap_atomic() 是很直接的。当代码想要访问一个可能从高内存（见__GFP_HIGHMEM） +分配的页面的内容时，例如在页缓存中的页面，就会使用它。该API有两个函数，它们的使用方式与 +下面类似:: + + /* 找到感兴趣的页面。 */ + struct page *page = find_get_page(mapping, offset); + + /* 获得对该页内容的访问权。 */ + void *vaddr = kmap_atomic(page); + + /* 对该页的内容做一些处理。 */ + memset(vaddr, 0, PAGE_SIZE); + + /* 解除该页面的映射。 */ + kunmap_atomic(vaddr); + +注意，kunmap_atomic()调用的是kmap_atomic()调用的结果而不是参数。 + +如果你需要映射两个页面，因为你想从一个页面复制到另一个页面，你需要保持kmap_atomic调用严 +格嵌套，如:: + + vaddr1 = kmap_atomic(page1); + vaddr2 = kmap_atomic(page2); + + memcpy(vaddr1, vaddr2, PAGE_SIZE); + + kunmap_atomic(vaddr2); + kunmap_atomic(vaddr1); + + +临时映射的成本 +============== + +创建临时映射的代价可能相当高。体系架构必须操作内核的页表、数据TLB和/或MMU的寄存器。 + +如果CONFIG_HIGHMEM没有被设置，那么内核会尝试用一点计算来创建映射，将页面结构地址转换成 +指向页面内容的指针，而不是去捣鼓映射。在这种情况下，解映射操作可能是一个空操作。 + +如果CONFIG_MMU没有被设置，那么就不可能有临时映射和高内存。在这种情况下，也将使用计算方法。 + + +i386 PAE +======== + +在某些情况下，i386 架构将允许你在 32 位机器上安装多达 64GiB 的内存。但这有一些后果: + +* Linux需要为系统中的每个页面建立一个页帧结构，而且页帧需要驻在永久映射中，这意味着： + +* 你最多可以有896M/sizeof(struct page)页帧；由于页结构体是32字节的，所以最终会有 + 112G的页；然而，内核需要在内存中存储更多的页帧...... + +* PAE使你的页表变大--这使系统变慢，因为更多的数据需要在TLB填充等方面被访问。一个好处 + 是，PAE有更多的PTE位，可以提供像NX和PAT这样的高级功能。 + +一般的建议是，你不要在32位机器上使用超过8GiB的空间--尽管更多的空间可能对你和你的工作 +量有用，但你几乎是靠你自己--不要指望内核开发者真的会很关心事情的进展情况。 diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index 13df8321f242..2f9834eb9475 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -25,12 +25,12 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） balance damon/index free_page_reporting + highmem TODOLIST: * arch_pgtable_helpers * free_page_reporting * frontswap -* highmem * hmm * hwpoison * hugetlbfs_reserv -- cgit From 869f496e1aa6d2b9a8653d65aa7040970f76627a Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 27 Jan 2022 18:32:58 +0200 Subject: docs: process: submitting-patches: Clarify the Reported-by usage It's unclear from "Submitting Patches" documentation that Reported-by is not supposed to be used against new features. (It's more clear in the section 5.4 "Patch formatting and changelogs" of the "A guide to the Kernel Development Process", where it suggests that change should fix something existing in the kernel. Clarify the Reported-by usage in the "Submitting Patches". Reported-by: Florian Eckert Signed-off-by: Andy Shevchenko Acked-by: Randy Dunlap Link: https://lore.kernel.org/r/20220127163258.48482-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Corbet --- Documentation/process/submitting-patches.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 31ea120ce531..fb496b2ebfd3 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -495,7 +495,8 @@ Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes: The Reported-by tag gives credit to people who find bugs and report them and it hopefully inspires them to help us again in the future. Please note that if the bug was reported in private, then ask for permission first before using the -Reported-by tag. +Reported-by tag. The tag is intended for bugs; please do not use it to credit +feature requests. A Tested-by: tag indicates that the patch has been successfully tested (in some environment) by the person named. This tag informs maintainers that -- cgit From b72903847af014342e0a22d8b595ad09a7eb45a0 Mon Sep 17 00:00:00 2001 From: Yonghong Song Date: Thu, 27 Jan 2022 07:46:27 -0800 Subject: docs/bpf: clarify how btf_type_tag gets encoded in the type chain Clarify where the BTF_KIND_TYPE_TAG gets encoded in the type chain, so applications and kernel can properly parse them. Signed-off-by: Yonghong Song Link: https://lore.kernel.org/r/20220127154627.665163-1-yhs@fb.com Signed-off-by: Alexei Starovoitov --- Documentation/bpf/btf.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst index ab08852e53ae..7940da9bc6c1 100644 --- a/Documentation/bpf/btf.rst +++ b/Documentation/bpf/btf.rst @@ -503,6 +503,19 @@ valid index (starting from 0) pointing to a member or an argument. * ``info.vlen``: 0 * ``type``: the type with ``btf_type_tag`` attribute +Currently, ``BTF_KIND_TYPE_TAG`` is only emitted for pointer types. +It has the following btf type chain: +:: + + ptr -> [type_tag]* + -> [const | volatile | restrict | typedef]* + -> base_type + +Basically, a pointer type points to zero or more +type_tag, then zero or more const/volatile/restrict/typedef +and finally the base type. The base type is one of +int, ptr, array, struct, union, enum, func_proto and float types. + 3. BTF Kernel API ================= -- cgit From 660ff26080f587052c338094a187e8ecc758d6e9 Mon Sep 17 00:00:00 2001 From: Kai Ye Date: Tue, 4 Jan 2022 16:29:16 +0800 Subject: Documentation: use the tabs on all acc documentation Use the tabs on all Hisilicon Accelerator documentation. including hpre, sec, zip. Signed-off-by: Kai Ye Signed-off-by: Herbert Xu --- Documentation/ABI/testing/debugfs-hisi-hpre | 168 ++++++++++++++-------------- Documentation/ABI/testing/debugfs-hisi-sec | 136 +++++++++++----------- Documentation/ABI/testing/debugfs-hisi-zip | 136 +++++++++++----------- 3 files changed, 220 insertions(+), 220 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-hisi-hpre b/Documentation/ABI/testing/debugfs-hisi-hpre index b4be5f1db4b7..68d4dcb1538d 100644 --- a/Documentation/ABI/testing/debugfs-hisi-hpre +++ b/Documentation/ABI/testing/debugfs-hisi-hpre @@ -1,140 +1,140 @@ -What: /sys/kernel/debug/hisi_hpre//cluster[0-3]/regs -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: Dump debug registers from the HPRE cluster. +What: /sys/kernel/debug/hisi_hpre//cluster[0-3]/regs +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: Dump debug registers from the HPRE cluster. Only available for PF. -What: /sys/kernel/debug/hisi_hpre//cluster[0-3]/cluster_ctrl -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: Write the HPRE core selection in the cluster into this file, +What: /sys/kernel/debug/hisi_hpre//cluster[0-3]/cluster_ctrl +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: Write the HPRE core selection in the cluster into this file, and then we can read the debug information of the core. Only available for PF. -What: /sys/kernel/debug/hisi_hpre//rdclr_en -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: HPRE cores debug registers read clear control. 1 means enable +What: /sys/kernel/debug/hisi_hpre//rdclr_en +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: HPRE cores debug registers read clear control. 1 means enable register read clear, otherwise 0. Writing to this file has no functional effect, only enable or disable counters clear after reading of these registers. Only available for PF. -What: /sys/kernel/debug/hisi_hpre//current_qm -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: One HPRE controller has one PF and multiple VFs, each function +What: /sys/kernel/debug/hisi_hpre//current_qm +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: One HPRE controller has one PF and multiple VFs, each function has a QM. Select the QM which below qm refers to. Only available for PF. -What: /sys/kernel/debug/hisi_hpre//regs -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: Dump debug registers from the HPRE. +What: /sys/kernel/debug/hisi_hpre//regs +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: Dump debug registers from the HPRE. Only available for PF. -What: /sys/kernel/debug/hisi_hpre//qm/regs -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: Dump debug registers from the QM. +What: /sys/kernel/debug/hisi_hpre//qm/regs +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: Dump debug registers from the QM. Available for PF and VF in host. VF in guest currently only has one debug register. -What: /sys/kernel/debug/hisi_hpre//qm/current_q -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: One QM may contain multiple queues. Select specific queue to +What: /sys/kernel/debug/hisi_hpre//qm/current_q +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: One QM may contain multiple queues. Select specific queue to show its debug registers in above regs. Only available for PF. -What: /sys/kernel/debug/hisi_hpre//qm/clear_enable -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: QM debug registers(regs) read clear control. 1 means enable +What: /sys/kernel/debug/hisi_hpre//qm/clear_enable +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: QM debug registers(regs) read clear control. 1 means enable register read clear, otherwise 0. Writing to this file has no functional effect, only enable or disable counters clear after reading of these registers. Only available for PF. -What: /sys/kernel/debug/hisi_hpre//qm/err_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of invalid interrupts for +What: /sys/kernel/debug/hisi_hpre//qm/err_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of invalid interrupts for QM task completion. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre//qm/aeq_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of QM async event queue interrupts. +What: /sys/kernel/debug/hisi_hpre//qm/aeq_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of QM async event queue interrupts. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre//qm/abnormal_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of interrupts for QM abnormal event. +What: /sys/kernel/debug/hisi_hpre//qm/abnormal_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of interrupts for QM abnormal event. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre//qm/create_qp_err -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of queue allocation errors. +What: /sys/kernel/debug/hisi_hpre//qm/create_qp_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of queue allocation errors. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre//qm/mb_err -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of failed QM mailbox commands. +What: /sys/kernel/debug/hisi_hpre//qm/mb_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of failed QM mailbox commands. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre//qm/status -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the status of the QM. +What: /sys/kernel/debug/hisi_hpre//qm/status +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the status of the QM. Four states: initiated, started, stopped and closed. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre//hpre_dfx/send_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of sent requests. +What: /sys/kernel/debug/hisi_hpre//hpre_dfx/send_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of sent requests. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre//hpre_dfx/recv_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of received requests. +What: /sys/kernel/debug/hisi_hpre//hpre_dfx/recv_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of received requests. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre//hpre_dfx/send_busy_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of requests sent +What: /sys/kernel/debug/hisi_hpre//hpre_dfx/send_busy_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of requests sent with returning busy. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre//hpre_dfx/send_fail_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of completed but error requests. +What: /sys/kernel/debug/hisi_hpre//hpre_dfx/send_fail_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of completed but error requests. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre//hpre_dfx/invalid_req_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of invalid requests being received. +What: /sys/kernel/debug/hisi_hpre//hpre_dfx/invalid_req_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of invalid requests being received. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre//hpre_dfx/overtime_thrhld -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Set the threshold time for counting the request which is +What: /sys/kernel/debug/hisi_hpre//hpre_dfx/overtime_thrhld +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Set the threshold time for counting the request which is processed longer than the threshold. 0: disable(default), 1: 1 microsecond. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre//hpre_dfx/over_thrhld_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of time out requests. +What: /sys/kernel/debug/hisi_hpre//hpre_dfx/over_thrhld_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of time out requests. Available for both PF and VF, and take no other effect on HPRE. diff --git a/Documentation/ABI/testing/debugfs-hisi-sec b/Documentation/ABI/testing/debugfs-hisi-sec index 85feb4408e0f..58cfa354534c 100644 --- a/Documentation/ABI/testing/debugfs-hisi-sec +++ b/Documentation/ABI/testing/debugfs-hisi-sec @@ -1,113 +1,113 @@ -What: /sys/kernel/debug/hisi_sec2//clear_enable -Date: Oct 2019 -Contact: linux-crypto@vger.kernel.org -Description: Enabling/disabling of clear action after reading +What: /sys/kernel/debug/hisi_sec2//clear_enable +Date: Oct 2019 +Contact: linux-crypto@vger.kernel.org +Description: Enabling/disabling of clear action after reading the SEC debug registers. 0: disable, 1: enable. Only available for PF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2//current_qm -Date: Oct 2019 -Contact: linux-crypto@vger.kernel.org -Description: One SEC controller has one PF and multiple VFs, each function +What: /sys/kernel/debug/hisi_sec2//current_qm +Date: Oct 2019 +Contact: linux-crypto@vger.kernel.org +Description: One SEC controller has one PF and multiple VFs, each function has a QM. This file can be used to select the QM which below qm refers to. Only available for PF. -What: /sys/kernel/debug/hisi_sec2//qm/qm_regs -Date: Oct 2019 -Contact: linux-crypto@vger.kernel.org -Description: Dump of QM related debug registers. +What: /sys/kernel/debug/hisi_sec2//qm/qm_regs +Date: Oct 2019 +Contact: linux-crypto@vger.kernel.org +Description: Dump of QM related debug registers. Available for PF and VF in host. VF in guest currently only has one debug register. -What: /sys/kernel/debug/hisi_sec2//qm/current_q -Date: Oct 2019 -Contact: linux-crypto@vger.kernel.org -Description: One QM of SEC may contain multiple queues. Select specific +What: /sys/kernel/debug/hisi_sec2//qm/current_q +Date: Oct 2019 +Contact: linux-crypto@vger.kernel.org +Description: One QM of SEC may contain multiple queues. Select specific queue to show its debug registers in above 'regs'. Only available for PF. -What: /sys/kernel/debug/hisi_sec2//qm/clear_enable -Date: Oct 2019 -Contact: linux-crypto@vger.kernel.org -Description: Enabling/disabling of clear action after reading +What: /sys/kernel/debug/hisi_sec2//qm/clear_enable +Date: Oct 2019 +Contact: linux-crypto@vger.kernel.org +Description: Enabling/disabling of clear action after reading the SEC's QM debug registers. 0: disable, 1: enable. Only available for PF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2//qm/err_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of invalid interrupts for +What: /sys/kernel/debug/hisi_sec2//qm/err_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of invalid interrupts for QM task completion. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2//qm/aeq_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of QM async event queue interrupts. +What: /sys/kernel/debug/hisi_sec2//qm/aeq_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of QM async event queue interrupts. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2//qm/abnormal_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of interrupts for QM abnormal event. +What: /sys/kernel/debug/hisi_sec2//qm/abnormal_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of interrupts for QM abnormal event. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2//qm/create_qp_err -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of queue allocation errors. +What: /sys/kernel/debug/hisi_sec2//qm/create_qp_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of queue allocation errors. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2//qm/mb_err -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of failed QM mailbox commands. +What: /sys/kernel/debug/hisi_sec2//qm/mb_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of failed QM mailbox commands. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2//qm/status -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the status of the QM. +What: /sys/kernel/debug/hisi_sec2//qm/status +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the status of the QM. Four states: initiated, started, stopped and closed. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2//sec_dfx/send_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of sent requests. +What: /sys/kernel/debug/hisi_sec2//sec_dfx/send_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of sent requests. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2//sec_dfx/recv_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of received requests. +What: /sys/kernel/debug/hisi_sec2//sec_dfx/recv_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of received requests. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2//sec_dfx/send_busy_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of requests sent with returning busy. +What: /sys/kernel/debug/hisi_sec2//sec_dfx/send_busy_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of requests sent with returning busy. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2//sec_dfx/err_bd_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of BD type error requests +What: /sys/kernel/debug/hisi_sec2//sec_dfx/err_bd_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of BD type error requests to be received. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2//sec_dfx/invalid_req_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of invalid requests being received. +What: /sys/kernel/debug/hisi_sec2//sec_dfx/invalid_req_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of invalid requests being received. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2//sec_dfx/done_flag_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of completed but marked error requests +What: /sys/kernel/debug/hisi_sec2//sec_dfx/done_flag_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of completed but marked error requests to be received. Available for both PF and VF, and take no other effect on SEC. diff --git a/Documentation/ABI/testing/debugfs-hisi-zip b/Documentation/ABI/testing/debugfs-hisi-zip index 3034a2bf99ca..765e29203ef3 100644 --- a/Documentation/ABI/testing/debugfs-hisi-zip +++ b/Documentation/ABI/testing/debugfs-hisi-zip @@ -1,114 +1,114 @@ -What: /sys/kernel/debug/hisi_zip//comp_core[01]/regs -Date: Nov 2018 -Contact: linux-crypto@vger.kernel.org -Description: Dump of compression cores related debug registers. +What: /sys/kernel/debug/hisi_zip//comp_core[01]/regs +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: Dump of compression cores related debug registers. Only available for PF. -What: /sys/kernel/debug/hisi_zip//decomp_core[0-5]/regs -Date: Nov 2018 -Contact: linux-crypto@vger.kernel.org -Description: Dump of decompression cores related debug registers. +What: /sys/kernel/debug/hisi_zip//decomp_core[0-5]/regs +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: Dump of decompression cores related debug registers. Only available for PF. -What: /sys/kernel/debug/hisi_zip//clear_enable -Date: Nov 2018 -Contact: linux-crypto@vger.kernel.org -Description: Compression/decompression core debug registers read clear +What: /sys/kernel/debug/hisi_zip//clear_enable +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: Compression/decompression core debug registers read clear control. 1 means enable register read clear, otherwise 0. Writing to this file has no functional effect, only enable or disable counters clear after reading of these registers. Only available for PF. -What: /sys/kernel/debug/hisi_zip//current_qm -Date: Nov 2018 -Contact: linux-crypto@vger.kernel.org -Description: One ZIP controller has one PF and multiple VFs, each function +What: /sys/kernel/debug/hisi_zip//current_qm +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: One ZIP controller has one PF and multiple VFs, each function has a QM. Select the QM which below qm refers to. Only available for PF. -What: /sys/kernel/debug/hisi_zip//qm/regs -Date: Nov 2018 -Contact: linux-crypto@vger.kernel.org -Description: Dump of QM related debug registers. +What: /sys/kernel/debug/hisi_zip//qm/regs +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: Dump of QM related debug registers. Available for PF and VF in host. VF in guest currently only has one debug register. -What: /sys/kernel/debug/hisi_zip//qm/current_q -Date: Nov 2018 -Contact: linux-crypto@vger.kernel.org -Description: One QM may contain multiple queues. Select specific queue to +What: /sys/kernel/debug/hisi_zip//qm/current_q +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: One QM may contain multiple queues. Select specific queue to show its debug registers in above regs. Only available for PF. -What: /sys/kernel/debug/hisi_zip//qm/clear_enable -Date: Nov 2018 -Contact: linux-crypto@vger.kernel.org -Description: QM debug registers(regs) read clear control. 1 means enable +What: /sys/kernel/debug/hisi_zip//qm/clear_enable +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: QM debug registers(regs) read clear control. 1 means enable register read clear, otherwise 0. Writing to this file has no functional effect, only enable or disable counters clear after reading of these registers. Only available for PF. -What: /sys/kernel/debug/hisi_zip//qm/err_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of invalid interrupts for +What: /sys/kernel/debug/hisi_zip//qm/err_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of invalid interrupts for QM task completion. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip//qm/aeq_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of QM async event queue interrupts. +What: /sys/kernel/debug/hisi_zip//qm/aeq_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of QM async event queue interrupts. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip//qm/abnormal_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of interrupts for QM abnormal event. +What: /sys/kernel/debug/hisi_zip//qm/abnormal_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of interrupts for QM abnormal event. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip//qm/create_qp_err -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of queue allocation errors. +What: /sys/kernel/debug/hisi_zip//qm/create_qp_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of queue allocation errors. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip//qm/mb_err -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of failed QM mailbox commands. +What: /sys/kernel/debug/hisi_zip//qm/mb_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of failed QM mailbox commands. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip//qm/status -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the status of the QM. +What: /sys/kernel/debug/hisi_zip//qm/status +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the status of the QM. Four states: initiated, started, stopped and closed. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip//zip_dfx/send_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of sent requests. +What: /sys/kernel/debug/hisi_zip//zip_dfx/send_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of sent requests. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip//zip_dfx/recv_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of received requests. +What: /sys/kernel/debug/hisi_zip//zip_dfx/recv_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of received requests. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip//zip_dfx/send_busy_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of requests received +What: /sys/kernel/debug/hisi_zip//zip_dfx/send_busy_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of requests received with returning busy. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip//zip_dfx/err_bd_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of BD type error requests +What: /sys/kernel/debug/hisi_zip//zip_dfx/err_bd_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of BD type error requests to be received. Available for both PF and VF, and take no other effect on ZIP. -- cgit From 535761866ec36e85ef32b4d41e8757307506bd17 Mon Sep 17 00:00:00 2001 From: Kai Ye Date: Tue, 4 Jan 2022 16:29:17 +0800 Subject: Documentation: update debugfs doc for Hisilicon SEC Update documentation describing DebugFS for function's QoS limiting. Signed-off-by: Kai Ye Signed-off-by: Herbert Xu --- Documentation/ABI/testing/debugfs-hisi-sec | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-hisi-sec b/Documentation/ABI/testing/debugfs-hisi-sec index 58cfa354534c..2bf84ced484b 100644 --- a/Documentation/ABI/testing/debugfs-hisi-sec +++ b/Documentation/ABI/testing/debugfs-hisi-sec @@ -14,6 +14,16 @@ Description: One SEC controller has one PF and multiple VFs, each function qm refers to. Only available for PF. +What: /sys/kernel/debug/hisi_sec2//alg_qos +Date: Jun 2021 +Contact: linux-crypto@vger.kernel.org +Description: The is related the function for PF and VF. + SEC driver supports to configure each function's QoS, the driver + supports to write value to alg_qos in the host. Such as + "echo value > alg_qos". The qos value is 1~1000, means + 1/1000~1000/1000 of total QoS. The driver reading alg_qos to + get related QoS in the host and VM, Such as "cat alg_qos". + What: /sys/kernel/debug/hisi_sec2//qm/qm_regs Date: Oct 2019 Contact: linux-crypto@vger.kernel.org -- cgit From f6fb93ccc8c835efd15960181c768cd7c0d204a6 Mon Sep 17 00:00:00 2001 From: Kai Ye Date: Tue, 4 Jan 2022 16:29:18 +0800 Subject: Documentation: update debugfs doc for Hisilicon ZIP Update documentation describing DebugFS for function's QoS limiting. Signed-off-by: Kai Ye Signed-off-by: Herbert Xu --- Documentation/ABI/testing/debugfs-hisi-zip | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-hisi-zip b/Documentation/ABI/testing/debugfs-hisi-zip index 765e29203ef3..bf1258bc6495 100644 --- a/Documentation/ABI/testing/debugfs-hisi-zip +++ b/Documentation/ABI/testing/debugfs-hisi-zip @@ -26,6 +26,16 @@ Description: One ZIP controller has one PF and multiple VFs, each function has a QM. Select the QM which below qm refers to. Only available for PF. +What: /sys/kernel/debug/hisi_zip//alg_qos +Date: Jun 2021 +Contact: linux-crypto@vger.kernel.org +Description: The is related the function for PF and VF. + ZIP driver supports to configure each function's QoS, the driver + supports to write value to alg_qos in the host. Such as + "echo value > alg_qos". The qos value is 1~1000, means + 1/1000~1000/1000 of total QoS. The driver reading alg_qos to + get related QoS in the host and VM, Such as "cat alg_qos". + What: /sys/kernel/debug/hisi_zip//qm/regs Date: Nov 2018 Contact: linux-crypto@vger.kernel.org -- cgit From 68ce6126e11364dd5b3a5c5113b4285c56d8d249 Mon Sep 17 00:00:00 2001 From: Kai Ye Date: Tue, 4 Jan 2022 16:29:19 +0800 Subject: Documentation: update debugfs doc for Hisilicon HPRE Update documentation describing DebugFS for function's QoS limiting. Signed-off-by: Kai Ye Signed-off-by: Herbert Xu --- Documentation/ABI/testing/debugfs-hisi-hpre | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-hisi-hpre b/Documentation/ABI/testing/debugfs-hisi-hpre index 68d4dcb1538d..396de7bc735d 100644 --- a/Documentation/ABI/testing/debugfs-hisi-hpre +++ b/Documentation/ABI/testing/debugfs-hisi-hpre @@ -27,6 +27,16 @@ Description: One HPRE controller has one PF and multiple VFs, each function has a QM. Select the QM which below qm refers to. Only available for PF. +What: /sys/kernel/debug/hisi_hpre//alg_qos +Date: Jun 2021 +Contact: linux-crypto@vger.kernel.org +Description: The is related the function for PF and VF. + HPRE driver supports to configure each function's QoS, the driver + supports to write value to alg_qos in the host. Such as + "echo value > alg_qos". The qos value is 1~1000, means + 1/1000~1000/1000 of total QoS. The driver reading alg_qos to + get related QoS in the host and VM, Such as "cat alg_qos". + What: /sys/kernel/debug/hisi_hpre//regs Date: Sep 2019 Contact: linux-crypto@vger.kernel.org -- cgit From 882ded92cd3c45b3bcbd778afff962d211d20796 Mon Sep 17 00:00:00 2001 From: Jacopo Mondi Date: Thu, 16 Dec 2021 17:34:33 +0100 Subject: media: dt-bindings: media: max9286: Re-indent example The dt-bindings examples are usually indented with 4 spaces. The maxim,max9286 schema has the example indented with only 2 spaces, re-indent it. Cosmetic change only. Reviewed-by: Laurent Pinchart Acked-by: Rob Herring Signed-off-by: Jacopo Mondi Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../bindings/media/i2c/maxim,max9286.yaml | 214 ++++++++++----------- 1 file changed, 107 insertions(+), 107 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml index 02f656e78700..ab4e7a620362 100644 --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml @@ -174,140 +174,140 @@ examples: #include i2c@e66d8000 { - #address-cells = <1>; - #size-cells = <0>; + #address-cells = <1>; + #size-cells = <0>; - reg = <0 0xe66d8000>; + reg = <0 0xe66d8000>; - gmsl-deserializer@2c { - compatible = "maxim,max9286"; - reg = <0x2c>; - poc-supply = <&camera_poc_12v>; - enable-gpios = <&gpio 13 GPIO_ACTIVE_HIGH>; + gmsl-deserializer@2c { + compatible = "maxim,max9286"; + reg = <0x2c>; + poc-supply = <&camera_poc_12v>; + enable-gpios = <&gpio 13 GPIO_ACTIVE_HIGH>; - gpio-controller; - #gpio-cells = <2>; + gpio-controller; + #gpio-cells = <2>; - maxim,reverse-channel-microvolt = <170000>; + maxim,reverse-channel-microvolt = <170000>; - ports { - #address-cells = <1>; - #size-cells = <0>; + ports { + #address-cells = <1>; + #size-cells = <0>; - port@0 { - reg = <0>; + port@0 { + reg = <0>; - max9286_in0: endpoint { - remote-endpoint = <&rdacm20_out0>; - }; - }; - - port@1 { - reg = <1>; - - max9286_in1: endpoint { - remote-endpoint = <&rdacm20_out1>; - }; - }; - - port@2 { - reg = <2>; - - max9286_in2: endpoint { - remote-endpoint = <&rdacm20_out2>; - }; - }; + max9286_in0: endpoint { + remote-endpoint = <&rdacm20_out0>; + }; + }; - port@3 { - reg = <3>; + port@1 { + reg = <1>; - max9286_in3: endpoint { - remote-endpoint = <&rdacm20_out3>; - }; - }; + max9286_in1: endpoint { + remote-endpoint = <&rdacm20_out1>; + }; + }; - port@4 { - reg = <4>; + port@2 { + reg = <2>; - max9286_out: endpoint { - data-lanes = <1 2 3 4>; - remote-endpoint = <&csi40_in>; - }; - }; - }; + max9286_in2: endpoint { + remote-endpoint = <&rdacm20_out2>; + }; + }; - i2c-mux { - #address-cells = <1>; - #size-cells = <0>; + port@3 { + reg = <3>; - i2c@0 { - #address-cells = <1>; - #size-cells = <0>; - reg = <0>; + max9286_in3: endpoint { + remote-endpoint = <&rdacm20_out3>; + }; + }; - camera@51 { - compatible = "imi,rdacm20"; - reg = <0x51>, <0x61>; + port@4 { + reg = <4>; - port { - rdacm20_out0: endpoint { - remote-endpoint = <&max9286_in0>; + max9286_out: endpoint { + data-lanes = <1 2 3 4>; + remote-endpoint = <&csi40_in>; + }; }; - }; - }; - }; - - i2c@1 { - #address-cells = <1>; - #size-cells = <0>; - reg = <1>; - camera@52 { - compatible = "imi,rdacm20"; - reg = <0x52>, <0x62>; + i2c-mux { + #address-cells = <1>; + #size-cells = <0>; - port { - rdacm20_out1: endpoint { - remote-endpoint = <&max9286_in1>; - }; - }; - }; - }; + i2c@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; - i2c@2 { - #address-cells = <1>; - #size-cells = <0>; - reg = <2>; + camera@51 { + compatible = "imi,rdacm20"; + reg = <0x51>, <0x61>; - camera@53 { - compatible = "imi,rdacm20"; - reg = <0x53>, <0x63>; + port { + rdacm20_out0: endpoint { + remote-endpoint = <&max9286_in0>; + }; + }; - port { - rdacm20_out2: endpoint { - remote-endpoint = <&max9286_in2>; + }; }; - }; - }; - }; - i2c@3 { - #address-cells = <1>; - #size-cells = <0>; - reg = <3>; + i2c@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + + camera@52 { + compatible = "imi,rdacm20"; + reg = <0x52>, <0x62>; + + port { + rdacm20_out1: endpoint { + remote-endpoint = <&max9286_in1>; + }; + }; + }; + }; - camera@54 { - compatible = "imi,rdacm20"; - reg = <0x54>, <0x64>; + i2c@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <2>; + + camera@53 { + compatible = "imi,rdacm20"; + reg = <0x53>, <0x63>; + + port { + rdacm20_out2: endpoint { + remote-endpoint = <&max9286_in2>; + }; + }; + }; + }; - port { - rdacm20_out3: endpoint { - remote-endpoint = <&max9286_in3>; + i2c@3 { + #address-cells = <1>; + #size-cells = <0>; + reg = <3>; + + camera@54 { + compatible = "imi,rdacm20"; + reg = <0x54>, <0x64>; + + port { + rdacm20_out3: endpoint { + remote-endpoint = <&max9286_in3>; + }; + }; + }; }; - }; }; - }; }; - }; }; -- cgit From 48a0c73f94d34ae5e78f85dc9a25e420a1dd207e Mon Sep 17 00:00:00 2001 From: Jacopo Mondi Date: Thu, 16 Dec 2021 17:34:34 +0100 Subject: media: dt-bindings: media: max9286: Define 'maxim,gpio-poc' Define a new vendor property in the maxim,max9286 binding schema. The new property allows to declare that the remote camera power-over-coax is controlled by one of the MAX9286 gpio lines. As it is currently not possible to establish a regulator as consumer of the MAX9286 gpio controller for this purpose, the property allows to declare that the camera power is controlled by the MAX9286 directly. The property accepts a gpio-index (0 or 1) and one line polarity flag as defined by dt-bindings/gpio/gpio.h. Reviewed-by: Rob Herring Reviewed-by: Laurent Pinchart Signed-off-by: Jacopo Mondi Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../bindings/media/i2c/maxim,max9286.yaml | 67 +++++++++++++++++++++- 1 file changed, 66 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml index ab4e7a620362..90315e217003 100644 --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml @@ -70,6 +70,28 @@ properties: a remote serializer whose high-threshold noise immunity is not enabled is 100000 micro volts + maxim,gpio-poc: + $ref: '/schemas/types.yaml#/definitions/uint32-array' + minItems: 2 + maxItems: 2 + description: | + Index of the MAX9286 gpio output line (0 or 1) that controls Power over + Coax to the cameras and its associated polarity flag. + + The property accepts an array of two unsigned integers, the first being + the gpio line index (0 or 1) and the second being the gpio line polarity + flag (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW) as defined in + . + + When the remote cameras power is controlled by one of the MAX9286 gpio + lines, this property has to be used to specify which line among the two + available ones controls the remote camera power enablement. + + When this property is used it is not possible to register a gpio + controller as the gpio lines are controlled directly by the MAX9286 and + not available for consumers, nor the 'poc-supply' property should be + specified. + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -165,7 +187,16 @@ required: - reg - ports - i2c-mux - - gpio-controller + +# If 'maxim,gpio-poc' is present, then 'poc-supply' and 'gpio-controller' +# are not allowed. +if: + required: + - maxim,gpio-poc +then: + properties: + poc-supply: false + gpio-controller: false additionalProperties: false @@ -310,4 +341,38 @@ examples: }; }; }; + + /* + * Example of a deserializer that controls the camera Power over Coax + * through one of its gpio lines. + */ + gmsl-deserializer@6c { + compatible = "maxim,max9286"; + reg = <0x6c>; + enable-gpios = <&gpio 14 GPIO_ACTIVE_HIGH>; + + /* + * The remote camera power is controlled by MAX9286 GPIO line #0. + * No 'poc-supply' nor 'gpio-controller' are specified. + */ + maxim,gpio-poc = <0 GPIO_ACTIVE_LOW>; + + /* + * Do not describe connections as they're the same as in the previous + * example. + */ + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@4 { + reg = <4>; + }; + }; + + i2c-mux { + #address-cells = <1>; + #size-cells = <0>; + }; + }; }; -- cgit From db8397262ce61a3ec642cf74d86c3e1dc32850ad Mon Sep 17 00:00:00 2001 From: Daniel Lundberg Pedersen Date: Wed, 12 Jan 2022 13:28:09 +0100 Subject: media: docs: v4l2grab.c.rst: change unintended assignment Example should be comparing errno to EINTR instead of doing assignment. Signed-off-by: Daniel Lundberg Pedersen Reviewed-by: Kieran Bingham Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/v4l2grab.c.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/v4l2grab.c.rst b/Documentation/userspace-api/media/v4l/v4l2grab.c.rst index b38f661da733..1a55e3617ea8 100644 --- a/Documentation/userspace-api/media/v4l/v4l2grab.c.rst +++ b/Documentation/userspace-api/media/v4l/v4l2grab.c.rst @@ -134,7 +134,7 @@ file: media/v4l/v4l2grab.c tv.tv_usec = 0; r = select(fd + 1, &fds, NULL, NULL, &tv); - } while ((r == -1 && (errno = EINTR))); + } while ((r == -1 && (errno == EINTR))); if (r == -1) { perror("select"); return errno; -- cgit From a45bef62022799c2ff4fcbe06da412dc707912ad Mon Sep 17 00:00:00 2001 From: Jean-Michel Hautbois Date: Wed, 12 Jan 2022 17:10:12 +0100 Subject: media: doc: pixfmt-yuv: Fix V4L2-PIX-FMT-Y10P format This packed grey-scale image format has a depth of 10 bits per pixel. Every four consecutive pixels are packed into 5 bytes. Each of the first 4 bytes contain the 8 high order bits of the pixels, and the 5th byte contains the 2 least significants bits of each pixel, in the same order. The first two bytes are not corresponding to this description, fix it. Fixes: af4f45057695 ("media: doc: pixfmt-yuv: Move all luma-only YUV formats to common file") Signed-off-by: Jean-Michel Hautbois Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst index 91942c4f0967..8ebd58c3588f 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst @@ -75,8 +75,8 @@ are often referred to as greyscale formats. - ``V4L2_PIX_FMT_Y10P`` - 'Y10P' - - Y'\ :sub:`0`\ [7:0] - - Y'\ :sub:`1`\ [9:8] + - Y'\ :sub:`0`\ [9:2] + - Y'\ :sub:`1`\ [9:2] - Y'\ :sub:`2`\ [9:2] - Y'\ :sub:`3`\ [9:2] - Y'\ :sub:`3`\ [1:0] Y'\ :sub:`2`\ [1:0] Y'\ :sub:`1`\ [1:0] Y'\ :sub:`0`\ [1:0] -- cgit From 083d299a26c51675550909a16fcc5d64eb362b35 Mon Sep 17 00:00:00 2001 From: Martin Kepplinger Date: Mon, 22 Nov 2021 08:27:08 +0100 Subject: media: dt-bindings: media: document imx8mq support for imx7-csi Add the fsl,imx8mq-csi compatible string to the bindings for nxp,imx7-csi. The i.MX8MQ SoC contains the same CSI bridge controller as the i.MX7. Signed-off-by: Martin Kepplinger Reviewed-by: Laurent Pinchart Acked-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml index 5922a2795167..4f7b78265336 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml @@ -17,6 +17,7 @@ properties: compatible: oneOf: - enum: + - fsl,imx8mq-csi - fsl,imx7-csi - fsl,imx6ul-csi - items: -- cgit From a16ce2f33732d04945c45922b3edb018caffcc07 Mon Sep 17 00:00:00 2001 From: Hsin-Yi Wang Date: Mon, 6 Dec 2021 14:04:23 +0100 Subject: media: dt-bindings: mediatek: convert mtk jpeg decoder/encoder to yaml Convert mediatek jpeg decoder and encoder bindings to yaml. Signed-off-by: Hsin-Yi Wang Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../bindings/media/mediatek-jpeg-decoder.txt | 38 --------- .../bindings/media/mediatek-jpeg-decoder.yaml | 89 ++++++++++++++++++++++ .../bindings/media/mediatek-jpeg-encoder.txt | 35 --------- .../bindings/media/mediatek-jpeg-encoder.yaml | 80 +++++++++++++++++++ 4 files changed, 169 insertions(+), 73 deletions(-) delete mode 100644 Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt create mode 100644 Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml delete mode 100644 Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt create mode 100644 Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt deleted file mode 100644 index 39c1028b2dfb..000000000000 --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt +++ /dev/null @@ -1,38 +0,0 @@ -* Mediatek JPEG Decoder - -Mediatek JPEG Decoder is the JPEG decode hardware present in Mediatek SoCs - -Required properties: -- compatible : must be one of the following string: - "mediatek,mt8173-jpgdec" - "mediatek,mt7623-jpgdec", "mediatek,mt2701-jpgdec" - "mediatek,mt2701-jpgdec" -- reg : physical base address of the jpeg decoder registers and length of - memory mapped region. -- interrupts : interrupt number to the interrupt controller. -- clocks: device clocks, see - Documentation/devicetree/bindings/clock/clock-bindings.txt for details. -- clock-names: must contain "jpgdec-smi" and "jpgdec". -- power-domains: a phandle to the power domain, see - Documentation/devicetree/bindings/power/power_domain.txt for details. -- mediatek,larb: must contain the local arbiters in the current Socs, see - Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml - for details. -- iommus: should point to the respective IOMMU block with master port as - argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml - for details. - -Example: - jpegdec: jpegdec@15004000 { - compatible = "mediatek,mt2701-jpgdec"; - reg = <0 0x15004000 0 0x1000>; - interrupts = ; - clocks = <&imgsys CLK_IMG_JPGDEC_SMI>, - <&imgsys CLK_IMG_JPGDEC>; - clock-names = "jpgdec-smi", - "jpgdec"; - power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>; - mediatek,larb = <&larb2>; - iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>, - <&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>; - }; diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml new file mode 100644 index 000000000000..9b87f036f178 --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/mediatek-jpeg-decoder.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek JPEG Decoder Device Tree Bindings + +maintainers: + - Xia Jiang + +description: |- + Mediatek JPEG Decoder is the JPEG decode hardware present in Mediatek SoCs + +properties: + compatible: + oneOf: + - items: + - enum: + - mediatek,mt8173-jpgdec + - mediatek,mt2701-jpgdec + - items: + - enum: + - mediatek,mt7623-jpgdec + - const: mediatek,mt2701-jpgdec + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + minItems: 2 + + clock-names: + items: + - const: jpgdec-smi + - const: jpgdec + + power-domains: + maxItems: 1 + + mediatek,larb: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: | + Must contain the local arbiters in the current Socs, see + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml + for details. + + iommus: + maxItems: 2 + description: | + Points to the respective IOMMU block with master port as argument, see + Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. + Ports are according to the HW. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + - mediatek,larb + - iommus + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + jpegdec: jpegdec@15004000 { + compatible = "mediatek,mt2701-jpgdec"; + reg = <0x15004000 0x1000>; + interrupts = ; + clocks = <&imgsys CLK_IMG_JPGDEC_SMI>, + <&imgsys CLK_IMG_JPGDEC>; + clock-names = "jpgdec-smi", + "jpgdec"; + power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>; + mediatek,larb = <&larb2>; + iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>, + <&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>; + }; diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt deleted file mode 100644 index 5e53c6ab52d0..000000000000 --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt +++ /dev/null @@ -1,35 +0,0 @@ -* MediaTek JPEG Encoder - -MediaTek JPEG Encoder is the JPEG encode hardware present in MediaTek SoCs - -Required properties: -- compatible : "mediatek,mt2701-jpgenc" - followed by "mediatek,mtk-jpgenc" -- reg : physical base address of the JPEG encoder registers and length of - memory mapped region. -- interrupts : interrupt number to the interrupt controller. -- clocks: device clocks, see - Documentation/devicetree/bindings/clock/clock-bindings.txt for details. -- clock-names: must contain "jpgenc". It is the clock of JPEG encoder. -- power-domains: a phandle to the power domain, see - Documentation/devicetree/bindings/power/power_domain.txt for details. -- mediatek,larb: must contain the local arbiters in the current SoCs, see - Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml - for details. -- iommus: should point to the respective IOMMU block with master port as - argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml - for details. - -Example: - jpegenc: jpegenc@1500a000 { - compatible = "mediatek,mt2701-jpgenc", - "mediatek,mtk-jpgenc"; - reg = <0 0x1500a000 0 0x1000>; - interrupts = ; - clocks = <&imgsys CLK_IMG_VENC>; - clock-names = "jpgenc"; - power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>; - mediatek,larb = <&larb2>; - iommus = <&iommu MT2701_M4U_PORT_JPGENC_RDMA>, - <&iommu MT2701_M4U_PORT_JPGENC_BSDMA>; - }; diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml new file mode 100644 index 000000000000..5e35ecfd21f1 --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/mediatek-jpeg-encoder.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek JPEG Encoder Device Tree Bindings + +maintainers: + - Xia Jiang + +description: |- + MediaTek JPEG Encoder is the JPEG encode hardware present in MediaTek SoCs + +properties: + compatible: + items: + - enum: + - mediatek,mt2701-jpgenc + - const: mediatek,mtk-jpgenc + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: jpgenc + + power-domains: + maxItems: 1 + + mediatek,larb: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: | + Must contain the local arbiters in the current Socs, see + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml + for details. + + iommus: + maxItems: 2 + description: | + Points to the respective IOMMU block with master port as argument, see + Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. + Ports are according to the HW. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + - mediatek,larb + - iommus + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + jpegenc: jpegenc@1500a000 { + compatible = "mediatek,mt2701-jpgenc", + "mediatek,mtk-jpgenc"; + reg = <0x1500a000 0x1000>; + interrupts = ; + clocks = <&imgsys CLK_IMG_VENC>; + clock-names = "jpgenc"; + power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>; + mediatek,larb = <&larb2>; + iommus = <&iommu MT2701_M4U_PORT_JPGENC_RDMA>, + <&iommu MT2701_M4U_PORT_JPGENC_BSDMA>; + }; -- cgit From bd73292de823064881fa6dde730b7a2befd7036a Mon Sep 17 00:00:00 2001 From: Hsin-Yi Wang Date: Mon, 6 Dec 2021 14:04:24 +0100 Subject: media: dt-bindings: mediatek: Add mediatek, mt8183-jpgenc compatible Add mediatek,mt8183-jpgenc compatible to binding document. Signed-off-by: Hsin-Yi Wang Reviewed-by: Matthias Brugger Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml index 5e35ecfd21f1..fcd9b829e036 100644 --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml @@ -17,6 +17,7 @@ properties: items: - enum: - mediatek,mt2701-jpgenc + - mediatek,mt8183-jpgenc - const: mediatek,mtk-jpgenc reg: maxItems: 1 -- cgit From 6d0990e6e844cfa045b1a7348f58964caceb4de4 Mon Sep 17 00:00:00 2001 From: Yong Wu Date: Mon, 17 Jan 2022 08:04:58 +0100 Subject: media: dt-binding: mediatek: Get rid of mediatek,larb for multimedia HW After adding device_link between the consumer with the smi-larbs, if the consumer call its owner pm_runtime_get(_sync), the pm_runtime_get(_sync) of smi-larb and smi-common will be called automatically. Thus, the consumer don't need this property. And IOMMU also know which larb this consumer connects with from iommu id in the "iommus=" property. Signed-off-by: Yong Wu Reviewed-by: Rob Herring Reviewed-by: Evan Green Acked-by: AngeloGioacchino Del Regno Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/display/mediatek/mediatek,disp.txt | 9 --------- .../devicetree/bindings/media/mediatek,vcodec-decoder.yaml | 7 ------- .../devicetree/bindings/media/mediatek,vcodec-encoder.yaml | 8 -------- .../devicetree/bindings/media/mediatek-jpeg-decoder.yaml | 9 --------- .../devicetree/bindings/media/mediatek-jpeg-encoder.yaml | 9 --------- Documentation/devicetree/bindings/media/mediatek-mdp.txt | 8 -------- 6 files changed, 50 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index 78044c340e20..8b575e11bcec 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -61,8 +61,6 @@ Required properties (DMA function blocks): "mediatek,-disp-rdma" "mediatek,-disp-wdma" the supported chips are mt2701, mt8167 and mt8173. -- larb: Should contain a phandle pointing to the local arbiter device as defined - in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml - iommus: Should point to the respective IOMMU block with master port as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. @@ -91,7 +89,6 @@ ovl0: ovl@1400c000 { power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; clocks = <&mmsys CLK_MM_DISP_OVL0>; iommus = <&iommu M4U_PORT_DISP_OVL0>; - mediatek,larb = <&larb0>; }; ovl1: ovl@1400d000 { @@ -101,7 +98,6 @@ ovl1: ovl@1400d000 { power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; clocks = <&mmsys CLK_MM_DISP_OVL1>; iommus = <&iommu M4U_PORT_DISP_OVL1>; - mediatek,larb = <&larb4>; }; rdma0: rdma@1400e000 { @@ -111,7 +107,6 @@ rdma0: rdma@1400e000 { power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; clocks = <&mmsys CLK_MM_DISP_RDMA0>; iommus = <&iommu M4U_PORT_DISP_RDMA0>; - mediatek,larb = <&larb0>; mediatek,rdma-fifosize = <8192>; }; @@ -122,7 +117,6 @@ rdma1: rdma@1400f000 { power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; clocks = <&mmsys CLK_MM_DISP_RDMA1>; iommus = <&iommu M4U_PORT_DISP_RDMA1>; - mediatek,larb = <&larb4>; }; rdma2: rdma@14010000 { @@ -132,7 +126,6 @@ rdma2: rdma@14010000 { power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; clocks = <&mmsys CLK_MM_DISP_RDMA2>; iommus = <&iommu M4U_PORT_DISP_RDMA2>; - mediatek,larb = <&larb4>; }; wdma0: wdma@14011000 { @@ -142,7 +135,6 @@ wdma0: wdma@14011000 { power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; clocks = <&mmsys CLK_MM_DISP_WDMA0>; iommus = <&iommu M4U_PORT_DISP_WDMA0>; - mediatek,larb = <&larb0>; }; wdma1: wdma@14012000 { @@ -152,7 +144,6 @@ wdma1: wdma@14012000 { power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; clocks = <&mmsys CLK_MM_DISP_WDMA1>; iommus = <&iommu M4U_PORT_DISP_WDMA1>; - mediatek,larb = <&larb4>; }; color0: color@14013000 { diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml index df1d677098fd..9b179bb44dfb 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml @@ -61,12 +61,6 @@ properties: description: | Describes the physical address space of IOMMU maps to memory. - mediatek,larb: - $ref: /schemas/types.yaml#/definitions/phandle - maxItems: 1 - description: | - Must contain the local arbiters in the current Socs. - mediatek,vpu: $ref: /schemas/types.yaml#/definitions/phandle maxItems: 1 @@ -137,7 +131,6 @@ examples: <0x16027800 0x800>, /*VP8_VL*/ <0x16028400 0x400>; /*VP9_VD*/ interrupts = ; - mediatek,larb = <&larb1>; iommus = <&iommu M4U_PORT_HW_VDEC_MC_EXT>, <&iommu M4U_PORT_HW_VDEC_PP_EXT>, <&iommu M4U_PORT_HW_VDEC_AVC_MV_EXT>, diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml index b72c1a50e89e..e7b65a91c92c 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml @@ -53,12 +53,6 @@ properties: description: | Describes the physical address space of IOMMU maps to memory. - mediatek,larb: - $ref: /schemas/types.yaml#/definitions/phandle - maxItems: 1 - description: | - Must contain the local arbiters in the current Socs. - mediatek,vpu: $ref: /schemas/types.yaml#/definitions/phandle maxItems: 1 @@ -157,7 +151,6 @@ examples: <&iommu M4U_PORT_VENC_REF_CHROMA>, <&iommu M4U_PORT_VENC_NBM_RDMA>, <&iommu M4U_PORT_VENC_NBM_WDMA>; - mediatek,larb = <&larb3>; mediatek,vpu = <&vpu>; clocks = <&topckgen CLK_TOP_VENC_SEL>; clock-names = "venc_sel"; @@ -178,7 +171,6 @@ examples: <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>, <&iommu M4U_PORT_VENC_REF_LUMA_SET2>, <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>; - mediatek,larb = <&larb5>; mediatek,vpu = <&vpu>; clocks = <&topckgen CLK_TOP_VENC_LT_SEL>; clock-names = "venc_lt_sel"; diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml index 9b87f036f178..052e752157b4 100644 --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml @@ -42,13 +42,6 @@ properties: power-domains: maxItems: 1 - mediatek,larb: - $ref: '/schemas/types.yaml#/definitions/phandle' - description: | - Must contain the local arbiters in the current Socs, see - Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml - for details. - iommus: maxItems: 2 description: | @@ -63,7 +56,6 @@ required: - clocks - clock-names - power-domains - - mediatek,larb - iommus additionalProperties: false @@ -83,7 +75,6 @@ examples: clock-names = "jpgdec-smi", "jpgdec"; power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>; - mediatek,larb = <&larb2>; iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>, <&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>; }; diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml index fcd9b829e036..8bfdfdfaba59 100644 --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml @@ -35,13 +35,6 @@ properties: power-domains: maxItems: 1 - mediatek,larb: - $ref: '/schemas/types.yaml#/definitions/phandle' - description: | - Must contain the local arbiters in the current Socs, see - Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml - for details. - iommus: maxItems: 2 description: | @@ -56,7 +49,6 @@ required: - clocks - clock-names - power-domains - - mediatek,larb - iommus additionalProperties: false @@ -75,7 +67,6 @@ examples: clocks = <&imgsys CLK_IMG_VENC>; clock-names = "jpgenc"; power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>; - mediatek,larb = <&larb2>; iommus = <&iommu MT2701_M4U_PORT_JPGENC_RDMA>, <&iommu MT2701_M4U_PORT_JPGENC_BSDMA>; }; diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt index caa24943da33..53ef26e2c857 100644 --- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt @@ -27,9 +27,6 @@ Required properties (DMA function blocks, child node): - iommus: should point to the respective IOMMU block with master port as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. -- mediatek,larb: must contain the local arbiters in the current Socs, see - Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml - for details. Example: mdp_rdma0: rdma@14001000 { @@ -40,7 +37,6 @@ Example: <&mmsys CLK_MM_MUTEX_32K>; power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; iommus = <&iommu M4U_PORT_MDP_RDMA0>; - mediatek,larb = <&larb0>; mediatek,vpu = <&vpu>; }; @@ -51,7 +47,6 @@ Example: <&mmsys CLK_MM_MUTEX_32K>; power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; iommus = <&iommu M4U_PORT_MDP_RDMA1>; - mediatek,larb = <&larb4>; }; mdp_rsz0: rsz@14003000 { @@ -81,7 +76,6 @@ Example: clocks = <&mmsys CLK_MM_MDP_WDMA>; power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; iommus = <&iommu M4U_PORT_MDP_WDMA>; - mediatek,larb = <&larb0>; }; mdp_wrot0: wrot@14007000 { @@ -90,7 +84,6 @@ Example: clocks = <&mmsys CLK_MM_MDP_WROT0>; power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; iommus = <&iommu M4U_PORT_MDP_WROT0>; - mediatek,larb = <&larb0>; }; mdp_wrot1: wrot@14008000 { @@ -99,5 +92,4 @@ Example: clocks = <&mmsys CLK_MM_MDP_WROT1>; power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; iommus = <&iommu M4U_PORT_MDP_WROT1>; - mediatek,larb = <&larb4>; }; -- cgit From fed44d6c3bcdb11ed77bc681f1cf80cbe8cfd9a5 Mon Sep 17 00:00:00 2001 From: Sameer Pujar Date: Fri, 28 Jan 2022 18:07:54 +0530 Subject: ASoC: Document Tegra234 APE support Update binding docs for devices which are part of APE subsystem on Tegra234 chip. Signed-off-by: Sameer Pujar Link: https://lore.kernel.org/r/1643373476-8538-4-git-send-email-spujar@nvidia.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml | 1 + Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml | 4 +++- Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml | 1 + Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml | 4 +++- Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml | 4 +++- Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml | 1 + Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml | 1 + Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml | 3 +++ Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml | 1 + Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml | 1 + Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml | 1 + Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml | 1 + Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml | 1 + 13 files changed, 21 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml index 7b1a08c62aef..d3ed048c9521 100644 --- a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml +++ b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml @@ -21,6 +21,7 @@ properties: - const: nvidia,tegra210-aconnect - items: - enum: + - nvidia,tegra234-aconnect - nvidia,tegra186-aconnect - nvidia,tegra194-aconnect - const: nvidia,tegra210-aconnect diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml index 5c2e2f156e31..fef804565b88 100644 --- a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml @@ -23,7 +23,9 @@ properties: - nvidia,tegra210-adma - nvidia,tegra186-adma - items: - - const: nvidia,tegra194-adma + - enum: + - nvidia,tegra234-adma + - nvidia,tegra194-adma - const: nvidia,tegra186-adma reg: diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml index ba282f4c9fd0..62219a5c21c5 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml @@ -58,6 +58,7 @@ properties: - enum: - nvidia,tegra186-agic - nvidia,tegra194-agic + - nvidia,tegra234-agic - const: nvidia,tegra210-agic interrupt-controller: true diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml index 0912d3e3fd8e..73b98b2f3543 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml @@ -28,7 +28,9 @@ properties: oneOf: - const: nvidia,tegra186-dspk - items: - - const: nvidia,tegra194-dspk + - enum: + - nvidia,tegra234-dspk + - nvidia,tegra194-dspk - const: nvidia,tegra186-dspk reg: diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml index 19eaacc3f12a..372043edd98f 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml @@ -27,7 +27,9 @@ properties: - nvidia,tegra210-admaif - nvidia,tegra186-admaif - items: - - const: nvidia,tegra194-admaif + - enum: + - nvidia,tegra234-admaif + - nvidia,tegra194-admaif - const: nvidia,tegra186-admaif reg: diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml index c4ba12ea3611..8d8dc7fb3f0c 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml @@ -30,6 +30,7 @@ properties: - const: nvidia,tegra210-adx - items: - enum: + - nvidia,tegra234-adx - nvidia,tegra194-adx - nvidia,tegra186-adx - const: nvidia,tegra210-adx diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml index df81d208184a..4727f1e42c53 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml @@ -26,6 +26,7 @@ properties: - enum: - nvidia,tegra210-ahub - nvidia,tegra186-ahub + - nvidia,tegra234-ahub - items: - const: nvidia,tegra194-ahub - const: nvidia,tegra186-ahub diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml index bb2111afe5a8..f9e4fc6e0c47 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml @@ -31,6 +31,9 @@ properties: - const: nvidia,tegra186-amx - const: nvidia,tegra210-amx - const: nvidia,tegra194-amx + - items: + - const: nvidia,tegra234-amx + - const: nvidia,tegra194-amx reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml index 62db982bb01d..bcb496d3ace5 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml @@ -28,6 +28,7 @@ properties: - const: nvidia,tegra210-dmic - items: - enum: + - nvidia,tegra234-dmic - nvidia,tegra194-dmic - nvidia,tegra186-dmic - const: nvidia,tegra210-dmic diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml index f954be636697..6188f561f878 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml @@ -28,6 +28,7 @@ properties: - const: nvidia,tegra210-i2s - items: - enum: + - nvidia,tegra234-i2s - nvidia,tegra194-i2s - nvidia,tegra186-i2s - const: nvidia,tegra210-i2s diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml index 428f3c851941..ee1e1d2da79a 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml @@ -28,6 +28,7 @@ properties: - const: nvidia,tegra210-amixer - items: - enum: + - nvidia,tegra234-amixer - nvidia,tegra194-amixer - nvidia,tegra186-amixer - const: nvidia,tegra210-amixer diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml index e2f5a8591d8f..c9888c553e78 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml @@ -31,6 +31,7 @@ properties: - const: nvidia,tegra210-mvc - items: - enum: + - nvidia,tegra234-mvc - nvidia,tegra194-mvc - nvidia,tegra186-mvc - const: nvidia,tegra210-mvc diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml index 41ad65173548..8579306fc56f 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml @@ -28,6 +28,7 @@ properties: - const: nvidia,tegra210-sfc - items: - enum: + - nvidia,tegra234-sfc - nvidia,tegra194-sfc - nvidia,tegra186-sfc - const: nvidia,tegra210-sfc -- cgit From 0cfe76156cc1c7f8a707969c03ed2242db8f0292 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 26 Jan 2022 17:13:58 -0600 Subject: ASoC: dt-bindings: realtek,rt5682s: Drop Tegra specifics from example There's no need to complicate examples with a platform specific macro. It also complicates example parsing to figure out the number of interrupt cells in examples (based on bracketing). Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220126231358.1637174-1-robh@kernel.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml index d65c0ed5060c..ca5b8987b749 100644 --- a/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml +++ b/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml @@ -21,6 +21,7 @@ properties: description: I2C address of the device. interrupts: + maxItems: 1 description: The CODEC's interrupt output. realtek,dmic1-data-pin: @@ -94,7 +95,7 @@ required: examples: - | - #include + #include #include i2c { @@ -104,10 +105,9 @@ examples: codec@1a { compatible = "realtek,rt5682s"; reg = <0x1a>; - interrupt-parent = <&gpio>; - interrupts = ; + interrupts = <6 IRQ_TYPE_LEVEL_HIGH>; realtek,ldo1-en-gpios = - <&gpio TEGRA_GPIO(R, 2) GPIO_ACTIVE_HIGH>; + <&gpio 2 GPIO_ACTIVE_HIGH>; realtek,dmic1-data-pin = <1>; realtek,dmic1-clk-pin = <1>; realtek,jd-src = <1>; -- cgit From fa183433bf53ee092323005f05cb3491e4aaaa8b Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 26 Jan 2022 17:12:50 -0600 Subject: regulator: maxim,max8973: Drop Tegra specifics from example There's no need to complicate examples with a platform specific macro. It also complicates example parsing to figure out the number of interrupt cells in examples (based on the bracketing). Signed-off-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220126231250.1635021-1-robh@kernel.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/maxim,max8973.yaml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml b/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml index 35c53e27f78c..5898dcf10f06 100644 --- a/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml +++ b/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml @@ -113,7 +113,7 @@ examples: }; - | - #include + #include #include i2c { @@ -123,8 +123,7 @@ examples: regulator@1b { compatible = "maxim,max77621"; reg = <0x1b>; - interrupt-parent = <&gpio>; - interrupts = ; + interrupts = <1 IRQ_TYPE_LEVEL_LOW>; regulator-always-on; regulator-boot-on; -- cgit From eccfecfe587b49394ffee1c928bc484837016ac7 Mon Sep 17 00:00:00 2001 From: Robert Hancock Date: Thu, 27 Jan 2022 10:41:55 -0600 Subject: net: dsa: microchip: Document property to disable reference clock Document the new microchip,synclko-disable property which can be specified to disable the reference clock output from the device if not required by the board design. Signed-off-by: Robert Hancock Acked-by: Rob Herring Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml index 84985f53bffd..184152087b60 100644 --- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml +++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml @@ -42,6 +42,12 @@ properties: description: Set if the output SYNCLKO frequency should be set to 125MHz instead of 25MHz. + microchip,synclko-disable: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set if the output SYNCLKO clock should be disabled. Do not mix with + microchip,synclko-125. + required: - compatible - reg -- cgit From 9690ae60429020f38e4aa2540c306f27eb021bc0 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Thu, 27 Jan 2022 10:42:59 -0800 Subject: ethtool: add header/data split indication For applications running on a mix of platforms it's useful to have a clear indication whether host's NIC supports the geometry requirements of TCP zero-copy. TCP zero-copy Rx requires data to be neatly placed into memory pages. Most NICs can't do that. This patch is adding GET support only, since the NICs I work with either always have the feature enabled or enable it whenever MTU is set to jumbo. In other words I don't need SET. But adding set should be trivial. (The only note on SET is that we will likely want the setting to be "sticky" and use 0 / `unknown` to reset it back to driver default.) Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller --- Documentation/networking/ethtool-netlink.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 9d98e0511249..cae28af7a476 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -860,8 +860,16 @@ Kernel response contents: ``ETHTOOL_A_RINGS_RX_JUMBO`` u32 size of RX jumbo ring ``ETHTOOL_A_RINGS_TX`` u32 size of TX ring ``ETHTOOL_A_RINGS_RX_BUF_LEN`` u32 size of buffers on the ring + ``ETHTOOL_A_RINGS_TCP_DATA_SPLIT`` u8 TCP header / data split ==================================== ====== =========================== +``ETHTOOL_A_RINGS_TCP_DATA_SPLIT`` indicates whether the device is usable with +page-flipping TCP zero-copy receive (``getsockopt(TCP_ZEROCOPY_RECEIVE)``). +If enabled the device is configured to place frame headers and data into +separate buffers. The device configuration must make it possible to receive +full memory pages of data, for example because MTU is high enough or through +HW-GRO. + RINGS_SET ========= -- cgit From 336136e197e26032141f594d2a0381ba900fa627 Mon Sep 17 00:00:00 2001 From: Robert Foss Date: Mon, 6 Dec 2021 16:18:11 +0100 Subject: media: dt-bindings: media: camss: Remove clock-lane property The clock-lanes property is not programmable by the hardware, and as such it should not be exposed in the dt-binding. Signed-off-by: Robert Foss Reviewed-by: Bjorn Andersson Reviewed-by: Rob Herring Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- .../bindings/media/qcom,msm8916-camss.yaml | 10 ---------- .../bindings/media/qcom,msm8996-camss.yaml | 20 -------------------- .../devicetree/bindings/media/qcom,sdm660-camss.yaml | 20 -------------------- .../devicetree/bindings/media/qcom,sdm845-camss.yaml | 17 ----------------- 4 files changed, 67 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml index 304908072d72..12ec3e1ea869 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml @@ -83,10 +83,6 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 1 - data-lanes: description: An array of physical data lanes indexes. @@ -99,7 +95,6 @@ properties: maxItems: 4 required: - - clock-lanes - data-lanes port@1: @@ -114,16 +109,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 1 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes reg: diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml index 38be41e932f0..6aeb3d6d02d5 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml @@ -105,10 +105,6 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: description: An array of physical data lanes indexes. @@ -121,7 +117,6 @@ properties: maxItems: 4 required: - - clock-lanes - data-lanes port@1: @@ -136,16 +131,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@2: @@ -160,16 +150,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@3: @@ -184,16 +169,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes reg: diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml index 841a1aafdd13..338ab28d5f3b 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml @@ -111,16 +111,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@1: @@ -135,16 +130,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@2: @@ -159,16 +149,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@3: @@ -183,16 +168,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes reg: diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml index 9ca5dfa7f226..9404d6b9db54 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml @@ -105,15 +105,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - maxItems: 1 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@1: @@ -128,16 +124,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@2: @@ -152,15 +143,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - maxItems: 1 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@3: @@ -175,15 +162,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - maxItems: 1 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes reg: -- cgit From b2a90f4fcb146d0e033203ab646f0fd22cfa947f Mon Sep 17 00:00:00 2001 From: Sean Young Date: Thu, 13 Jan 2022 11:20:22 +0100 Subject: media: lirc: remove unused lirc features These features have never been implemented by any lirc driver, including staging or out of tree drivers. The ioctls for these feaures were removed in commit d55f09abe24b ("[media] lirc.h: remove several unused ioctls"). So, we can safely remove them. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/rc/lirc-get-features.rst | 18 ------------------ 1 file changed, 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/rc/lirc-get-features.rst b/Documentation/userspace-api/media/rc/lirc-get-features.rst index 4bf25860f932..545137620ead 100644 --- a/Documentation/userspace-api/media/rc/lirc-get-features.rst +++ b/Documentation/userspace-api/media/rc/lirc-get-features.rst @@ -102,12 +102,6 @@ LIRC features The driver supports setting the receive carrier frequency using :ref:`ioctl LIRC_SET_REC_CARRIER `. -.. _LIRC-CAN-SET-REC-DUTY-CYCLE-RANGE: - -``LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE`` - - Unused. Kept just to avoid breaking uAPI. - .. _LIRC-CAN-SET-REC-CARRIER-RANGE: ``LIRC_CAN_SET_REC_CARRIER_RANGE`` @@ -129,12 +123,6 @@ LIRC features The driver supports :ref:`ioctl LIRC_SET_REC_TIMEOUT `. -.. _LIRC-CAN-SET-REC-FILTER: - -``LIRC_CAN_SET_REC_FILTER`` - - Unused. Kept just to avoid breaking uAPI. - .. _LIRC-CAN-MEASURE-CARRIER: ``LIRC_CAN_MEASURE_CARRIER`` @@ -149,12 +137,6 @@ LIRC features The driver supports learning mode using :ref:`ioctl LIRC_SET_WIDEBAND_RECEIVER `. -.. _LIRC-CAN-NOTIFY-DECODE: - -``LIRC_CAN_NOTIFY_DECODE`` - - Unused. Kept just to avoid breaking uAPI. - .. _LIRC-CAN-SEND-RAW: ``LIRC_CAN_SEND_RAW`` -- cgit From 68a99f6a0ebfe9101ea79ba5af1c407a5ad4f629 Mon Sep 17 00:00:00 2001 From: Sean Young Date: Sat, 15 Jan 2022 11:19:11 +0100 Subject: media: lirc: report ir receiver overflow If the driver reports that the hardware had an overflow, report this to userspace. It would be nice to know when this happens, and not just get a long space. This change has been tested with lircd, ir-ctl, and ir-keytable. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/lirc.h.rst.exceptions | 3 +++ Documentation/userspace-api/media/rc/lirc-dev-intro.rst | 11 +++++++++-- 2 files changed, 12 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/lirc.h.rst.exceptions b/Documentation/userspace-api/media/lirc.h.rst.exceptions index ec86e82d026d..5f31e967bc50 100644 --- a/Documentation/userspace-api/media/lirc.h.rst.exceptions +++ b/Documentation/userspace-api/media/lirc.h.rst.exceptions @@ -11,12 +11,14 @@ ignore define LIRC_SPACE ignore define LIRC_PULSE ignore define LIRC_FREQUENCY ignore define LIRC_TIMEOUT +ignore define LIRC_OVERFLOW ignore define LIRC_VALUE ignore define LIRC_MODE2 ignore define LIRC_IS_SPACE ignore define LIRC_IS_PULSE ignore define LIRC_IS_FREQUENCY ignore define LIRC_IS_TIMEOUT +ignore define LIRC_IS_OVERFLOW ignore define LIRC_MODE2SEND ignore define LIRC_SEND2MODE @@ -75,6 +77,7 @@ ignore define PULSE_MASK ignore define LIRC_MODE2_SPACE ignore define LIRC_MODE2_PULSE ignore define LIRC_MODE2_TIMEOUT +ignore define LIRC_MODE2_OVERFLOW ignore define LIRC_VALUE_MASK ignore define LIRC_MODE2_MASK diff --git a/Documentation/userspace-api/media/rc/lirc-dev-intro.rst b/Documentation/userspace-api/media/rc/lirc-dev-intro.rst index 9a5e5f0aae11..d899331b943f 100644 --- a/Documentation/userspace-api/media/rc/lirc-dev-intro.rst +++ b/Documentation/userspace-api/media/rc/lirc-dev-intro.rst @@ -103,11 +103,11 @@ on the following table. ``LIRC_MODE2_PULSE`` - Signifies the presence of IR in microseconds. + Signifies the presence of IR in microseconds, also known as *flash*. ``LIRC_MODE2_SPACE`` - Signifies absence of IR in microseconds. + Signifies absence of IR in microseconds, also known as *gap*. ``LIRC_MODE2_FREQUENCY`` @@ -121,6 +121,13 @@ on the following table. to no IR being detected, this packet will be sent, with the number of microseconds with no IR. + ``LIRC_MODE2_OVERFLOW`` + + Signifies that the IR receiver encounter an overflow, and some IR + is missing. The IR data after this should be correct again. The + actual value is not important, but this is set to 0xffffff by the + kernel for compatibility with lircd. + .. _lirc-mode-pulse: ``LIRC_MODE_PULSE`` -- cgit From 20e8ef5c7ffaa4c1d5f65727c536ffaf37078d5f Mon Sep 17 00:00:00 2001 From: Akhil R Date: Fri, 28 Jan 2022 17:14:26 +0530 Subject: docs: firmware-guide: ACPI: Add named interrupt doc Add a detailed example of the named interrupts in the ACPI table. Signed-off-by: Akhil R Reviewed-by: Andy Shevchenko Acked-by: Rafael J. Wysocki Signed-off-by: Wolfram Sang --- Documentation/firmware-guide/acpi/enumeration.rst | 39 +++++++++++++++++++++++ 1 file changed, 39 insertions(+) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index 74b830b2fd59..d0022567c022 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -143,6 +143,45 @@ In robust cases the client unfortunately needs to call acpi_dma_request_slave_chan_by_index() directly and therefore choose the specific FixedDMA resource by its index. +Named Interrupts +================ + +Drivers enumerated via ACPI can have names to interrupts in the ACPI table +which can be used to get the IRQ number in the driver. + +The interrupt name can be listed in _DSD as 'interrupt-names'. The names +should be listed as an array of strings which will map to the Interrupt() +resource in the ACPI table corresponding to its index. + +The table below shows an example of its usage:: + + Device (DEV0) { + ... + Name (_CRS, ResourceTemplate() { + ... + Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { + 0x20, + 0x24 + } + }) + + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"interrupt-names", + Package (2) {"default", "alert"}}, + } + ... + }) + } + +The interrupt name 'default' will correspond to 0x20 in Interrupt() +resource and 'alert' to 0x24. Note that only the Interrupt() resource +is mapped and not GpioInt() or similar. + +The driver can call the function - fwnode_irq_get_byname() with the fwnode +and interrupt name as arguments to get the corresponding IRQ number. + SPI serial bus support ====================== -- cgit From f244cdce52de05711d3a0e9aaa7303ef28f43f82 Mon Sep 17 00:00:00 2001 From: Kewei Xu Date: Tue, 25 Jan 2022 19:04:12 +0800 Subject: dt-bindings: i2c: update bindings for MT8186 SoC Add a DT binding documentation for the MT8186 soc. Signed-off-by: Kewei Xu Acked-by: Rob Herring Reviewed-by: Qii Wang Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt index 5ea216ae7084..88f74a3c81ec 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt @@ -14,6 +14,7 @@ Required properties: "mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek MT7629 "mediatek,mt8173-i2c": for MediaTek MT8173 "mediatek,mt8183-i2c": for MediaTek MT8183 + "mediatek,mt8186-i2c": for MediaTek MT8186 "mediatek,mt8192-i2c": for MediaTek MT8192 "mediatek,mt8195-i2c", "mediatek,mt8192-i2c": for MediaTek MT8195 "mediatek,mt8516-i2c", "mediatek,mt2712-i2c": for MediaTek MT8516 -- cgit From d6e359305b4500c93af79765b5067cbc5898e973 Mon Sep 17 00:00:00 2001 From: Jesse Taube Date: Tue, 11 Jan 2022 16:54:12 -0500 Subject: dt-bindings: clock: imx: Add documentation for i.MXRT1050 clock Add DT binding documentation for i.MXRT1050 clock driver. Cc: Giulio Benetti Signed-off-by: Jesse Taube Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20220111215415.2075257-5-Mr.Bossman075@gmail.com Signed-off-by: Abel Vesa --- .../devicetree/bindings/clock/imxrt1050-clock.yaml | 67 ++++++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml b/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml new file mode 100644 index 000000000000..35fd08c143f4 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imxrt1050-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MXRT + +maintainers: + - Giulio Benetti + - Jesse Taube + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. See include/dt-bindings/clock/imxrt*-clock.h + for the full list of i.MXRT clock IDs. + +properties: + compatible: + const: fsl,imxrt1050-ccm + + reg: + maxItems: 1 + + interrupts: + maxItems: 2 + + clocks: + description: 24m osc + maxItems: 1 + + clock-names: + const: osc + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include + + clks: clock-controller@400fc000 { + compatible = "fsl,imxrt1050-ccm"; + reg = <0x400fc000 0x4000>; + interrupts = <95>, <96>; + clocks = <&osc>; + clock-names = "osc"; + #clock-cells = <1>; + }; + + lpuart1: serial@40184000 { + compatible = "fsl,imxrt1050-lpuart"; + reg = <0x40184000 0x4000>; + interrupts = <20>; + clocks = <&clks IMXRT1050_CLK_LPUART1>; + clock-names = "ipg"; + }; -- cgit From f4ea385a16c549753435601c8fb74e0ca12ad2d7 Mon Sep 17 00:00:00 2001 From: Robert Hancock Date: Thu, 27 Jan 2022 10:37:34 -0600 Subject: dt-bindings: net: cdns,macb: added generic PHY and reset mappings for ZynqMP Updated macb DT binding documentation to reflect the phy-names, phys, resets, reset-names properties which are now used with ZynqMP GEM devices, and added a ZynqMP-specific DT example. Signed-off-by: Robert Hancock Signed-off-by: David S. Miller --- .../devicetree/bindings/net/cdns,macb.yaml | 56 ++++++++++++++++++++++ 1 file changed, 56 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/cdns,macb.yaml b/Documentation/devicetree/bindings/net/cdns,macb.yaml index 8dd06db34169..6cd3d853dcba 100644 --- a/Documentation/devicetree/bindings/net/cdns,macb.yaml +++ b/Documentation/devicetree/bindings/net/cdns,macb.yaml @@ -81,6 +81,25 @@ properties: phy-handle: true + phys: + maxItems: 1 + + phy-names: + const: sgmii-phy + description: + Required with ZynqMP SoC when in SGMII mode. + Should reference PS-GTR generic PHY device for this controller + instance. See ZynqMP example. + + resets: + maxItems: 1 + description: + Recommended with ZynqMP, specify reset control for this + controller instance with zynqmp-reset driver. + + reset-names: + maxItems: 1 + fixed-link: true iommus: @@ -157,3 +176,40 @@ examples: reset-gpios = <&pioE 6 1>; }; }; + + - | + #include + #include + #include + #include + + bus { + #address-cells = <2>; + #size-cells = <2>; + gem1: ethernet@ff0c0000 { + compatible = "cdns,zynqmp-gem", "cdns,gem"; + interrupt-parent = <&gic>; + interrupts = <0 59 4>, <0 59 4>; + reg = <0x0 0xff0c0000 0x0 0x1000>; + clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM1_REF>, + <&zynqmp_clk GEM1_TX>, <&zynqmp_clk GEM1_RX>, + <&zynqmp_clk GEM_TSU>; + clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk"; + #address-cells = <1>; + #size-cells = <0>; + #stream-id-cells = <1>; + iommus = <&smmu 0x875>; + power-domains = <&zynqmp_firmware PD_ETH_1>; + resets = <&zynqmp_reset ZYNQMP_RESET_GEM1>; + reset-names = "gem1_rst"; + status = "okay"; + phy-mode = "sgmii"; + phy-names = "sgmii-phy"; + phys = <&psgtr 1 PHY_TYPE_SGMII 1 1>; + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + }; -- cgit From 136851694889a532ab17004d4c5f4e55304dc330 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Mon, 13 Dec 2021 09:26:10 +0100 Subject: dt-bindings: simple-framebuffer: allow standalone compatible Qualcomm platforms use "simple-framebuffer" without a more specific compatible. Allow that in the binding doc. Signed-off-by: Luca Weiss Acked-by: Rob Herring Signed-off-by: Helge Deller --- .../devicetree/bindings/display/simple-framebuffer.yaml | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml index 44a29d813f14..27ba4323d221 100644 --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml @@ -52,11 +52,13 @@ description: |+ properties: compatible: - items: - - enum: - - apple,simple-framebuffer - - allwinner,simple-framebuffer - - amlogic,simple-framebuffer + oneOf: + - items: + - enum: + - apple,simple-framebuffer + - allwinner,simple-framebuffer + - amlogic,simple-framebuffer + - const: simple-framebuffer - const: simple-framebuffer reg: -- cgit From 5cc25c129212b442bdcd2ae0e3afef595672a081 Mon Sep 17 00:00:00 2001 From: Qianggui Song Date: Thu, 13 Jan 2022 11:10:41 +0800 Subject: dt-bindings: pinctrl: meson: Add compatible for S4 Add new compatible for Amlogic's Meson-S4 pin controller Reviewed-by: Martin Blumenstingl Signed-off-by: Qianggui Song Link: https://lore.kernel.org/r/20220113031044.2665-2-qianggui.song@amlogic.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt index 0aff1f28495c..8146193bd8ac 100644 --- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt @@ -16,6 +16,7 @@ Required properties for the root node: "amlogic,meson-g12a-periphs-pinctrl" "amlogic,meson-g12a-aobus-pinctrl" "amlogic,meson-a1-periphs-pinctrl" + "amlogic,meson-s4-periphs-pinctrl" - reg: address and size of registers controlling irq functionality === GPIO sub-nodes === -- cgit From 340407d214e4566c8a5d6997b7ca5ec21c7077a8 Mon Sep 17 00:00:00 2001 From: Wells Lu Date: Sun, 16 Jan 2022 22:52:13 +0800 Subject: dt-bindings: pinctrl: Add dt-bindings for Sunplus SP7021 Add dt-bindings header files and documentation for Sunplus SP7021 SoC. Signed-off-by: Wells Lu Link: https://lore.kernel.org/r/1642344734-27229-2-git-send-email-wellslutw@gmail.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/sunplus,sp7021-pinctrl.yaml | 374 +++++++++++++++++++++ 1 file changed, 374 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml new file mode 100644 index 000000000000..d8e75b3e64f1 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml @@ -0,0 +1,374 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) Sunplus Co., Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/sunplus,sp7021-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sunplus SP7021 Pin Controller Device Tree Bindings + +maintainers: + - Dvorkin Dmitry + - Wells Lu + +description: | + The Sunplus SP7021 pin controller is used to control SoC pins. Please + refer to pinctrl-bindings.txt in this directory for details of the common + pinctrl bindings used by client devices. + + SP7021 has 99 digital GPIO pins which are numbered from GPIO 0 to 98. All + are multiplexed with some special function pins. SP7021 has 3 types of + special function pins: + + (1) function-group pins: + Ex 1 (SPI-NOR flash): + If control-field SPI_FLASH_SEL is set to 1, GPIO 83, 84, 86 and 87 + will be pins of SPI-NOR flash. If it is set to 2, GPIO 76, 78, 79 + and 81 will be pins of SPI-NOR flash. + + Ex 2 (UART_0): + If control-bit UA0_SEL is set to 1, GPIO 88 and 89 will be TX and + RX pins of UART_0 (UART channel 0). + + Ex 3 (eMMC): + If control-bit EMMC_SEL is set to 1, GPIO 72, 73, 74, 75, 76, 77, + 78, 79, 80, 81 will be pins of an eMMC device. + + Properties "function" and "groups" are used to select function-group + pins. + + (2) fully pin-mux (like phone exchange mux) pins: + GPIO 8 to 71 are 'fully pin-mux' pins. Any pins of peripherals of + SP7021 (ex: UART_1, UART_2, UART_3, UART_4, I2C_0, I2C_1, and etc.) + can be routed to any pins of fully pin-mux pins. + + Ex 1 (UART channel 1): + If control-field UA1_TX_SEL is set to 3, TX pin of UART_1 will be + routed to GPIO 10 (3 - 1 + 8 = 10). + If control-field UA1_RX_SEL is set to 4, RX pin of UART_1 will be + routed to GPIO 11 (4 - 1 + 8 = 11). + If control-field UA1_RTS_SEL is set to 5, RTS pin of UART_1 will + be routed to GPIO 12 (5 - 1 + 8 = 12). + If control-field UA1_CTS_SEL is set to 6, CTS pin of UART_1 will + be routed to GPIO 13 (6 - 1 + 8 = 13). + + Ex 2 (I2C channel 0): + If control-field I2C0_CLK_SEL is set to 20, CLK pin of I2C_0 will + be routed to GPIO 27 (20 - 1 + 8 = 27). + If control-field I2C0_DATA_SEL is set to 21, DATA pin of I2C_0 + will be routed to GPIO 28 (21 - 1 + 9 = 28). + + Totally, SP7021 has 120 peripheral pins. The peripheral pins can be + routed to any of 64 'fully pin-mux' pins. + + (3) I/O processor pins + SP7021 has a built-in I/O processor. + Any GPIO pins (GPIO 0 to 98) can be set to pins of I/O processor. + + Vendor property "sunplus,pins" is used to select "fully pin-mux" pins, + "I/O processor pins" and "digital GPIO" pins. + + The device node of pin controller of Sunplus SP7021 has following + properties. + +properties: + compatible: + const: sunplus,sp7021-pctl + + gpio-controller: true + + '#gpio-cells': + const: 2 + + reg: + items: + - description: the MOON2 registers + - description: the GPIOXT registers + - description: the FIRST registers + - description: the MOON1 registers + + reg-names: + items: + - const: moon2 + - const: gpioxt + - const: first + - const: moon1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +patternProperties: + '-pins$': + type: object + description: | + A pinctrl node should contain at least one subnodes representing the + pins or function-pins group available on the machine. Each subnode + will list the pins it needs, and how they should be configured. + + Pinctrl node's client devices use subnodes for desired pin + configuration. Client device subnodes use below standard properties. + $ref: pinmux-node.yaml# + + properties: + sunplus,pins: + description: | + Define 'sunplus,pins' which are used by pinctrl node's client + device. + + It consists of one or more integers which represents the config + setting for corresponding pin. Each integer defines a individual + pin in which: + + Bit 32~24: defines GPIO number. Its range is 0 ~ 98. + Bit 23~16: defines types: (1) fully pin-mux pins + (2) IO processor pins + (3) digital GPIO pins + Bit 15~8: defines pins of peripherals (which are defined in + 'include/dt-binging/pinctrl/sppctl.h'). + Bit 7~0: defines types or initial-state of digital GPIO pins. + + Please use macro SPPCTL_IOPAD to define the integers for pins. + + $ref: /schemas/types.yaml#/definitions/uint32-array + + function: + description: | + Define pin-function which is used by pinctrl node's client device. + The name should be one of string in the following enumeration. + $ref: "/schemas/types.yaml#/definitions/string" + enum: [ SPI_FLASH, SPI_FLASH_4BIT, SPI_NAND, CARD0_EMMC, SD_CARD, + UA0, FPGA_IFX, HDMI_TX, LCDIF, USB0_OTG, USB1_OTG ] + + groups: + description: | + Define pin-group in a specified pin-function. + The name should be one of string in the following enumeration. + $ref: "/schemas/types.yaml#/definitions/string" + enum: [ SPI_FLASH1, SPI_FLASH2, SPI_FLASH_4BIT1, SPI_FLASH_4BIT2, + SPI_NAND, CARD0_EMMC, SD_CARD, UA0, FPGA_IFX, HDMI_TX1, + HDMI_TX2, HDMI_TX3, LCDIF, USB0_OTG, USB1_OTG ] + + sunplus,zerofunc: + description: | + This is a vendor specific property. It is used to disable pins + which are not used by pinctrl node's client device. + Some pins may be enabled by boot-loader. We can use this + property to disable them. + $ref: /schemas/types.yaml#/definitions/uint32-array + + additionalProperties: false + + allOf: + - if: + properties: + function: + enum: + - SPI_FLASH + then: + properties: + groups: + enum: + - SPI_FLASH1 + - SPI_FLASH2 + - if: + properties: + function: + enum: + - SPI_FLASH_4BIT + then: + properties: + groups: + enum: + - SPI_FLASH_4BIT1 + - SPI_FLASH_4BIT2 + - if: + properties: + function: + enum: + - SPI_NAND + then: + properties: + groups: + enum: + - SPI_NAND + - if: + properties: + function: + enum: + - CARD0_EMMC + then: + properties: + groups: + enum: + - CARD0_EMMC + - if: + properties: + function: + enum: + - SD_CARD + then: + properties: + groups: + enum: + - SD_CARD + - if: + properties: + function: + enum: + - UA0 + then: + properties: + groups: + enum: + - UA0 + - if: + properties: + function: + enum: + - FPGA_IFX + then: + properties: + groups: + enum: + - FPGA_IFX + - if: + properties: + function: + enum: + - HDMI_TX + then: + properties: + groups: + enum: + - HDMI_TX1 + - HDMI_TX2 + - HDMI_TX3 + - if: + properties: + function: + enum: + - LCDIF + then: + properties: + groups: + enum: + - LCDIF + - if: + properties: + function: + enum: + - USB0_OTG + then: + properties: + groups: + enum: + - USB0_OTG + - if: + properties: + function: + enum: + - USB1_OTG + then: + properties: + groups: + enum: + - USB1_OTG + +required: + - compatible + - reg + - reg-names + - "#gpio-cells" + - gpio-controller + - clocks + - resets + +additionalProperties: false + +examples: + - | + #include + + pinctl@9c000100 { + compatible = "sunplus,sp7021-pctl"; + reg = <0x9c000100 0x100>, <0x9c000300 0x100>, + <0x9c0032e4 0x1c>, <0x9c000080 0x20>; + reg-names = "moon2", "gpioxt", "first", "moon1"; + gpio-controller; + #gpio-cells = <2>; + clocks = <&clkc 0x83>; + resets = <&rstc 0x73>; + + uart0-pins { + function = "UA0"; + groups = "UA0"; + }; + + spinand0-pins { + function = "SPI_NAND"; + groups = "SPI_NAND"; + }; + + uart1-pins { + sunplus,pins = < + SPPCTL_IOPAD(11, SPPCTL_PCTL_G_PMUX, MUXF_UA1_TX, 0) + SPPCTL_IOPAD(10, SPPCTL_PCTL_G_PMUX, MUXF_UA1_RX, 0) + >; + }; + + uart2-pins { + sunplus,pins = < + SPPCTL_IOPAD(20, SPPCTL_PCTL_G_PMUX, MUXF_UA1_TX, 0) + SPPCTL_IOPAD(21, SPPCTL_PCTL_G_PMUX, MUXF_UA1_RX, 0) + SPPCTL_IOPAD(22, SPPCTL_PCTL_G_PMUX, MUXF_UA1_RTS, 0) + SPPCTL_IOPAD(23, SPPCTL_PCTL_G_PMUX, MUXF_UA1_CTS, 0) + >; + }; + + emmc-pins { + function = "CARD0_EMMC"; + groups = "CARD0_EMMC"; + }; + + sdcard-pins { + function = "SD_CARD"; + groups = "SD_CARD"; + sunplus,pins = < SPPCTL_IOPAD(91, SPPCTL_PCTL_G_GPIO, 0, 0) >; + }; + + hdmi_A_tx1-pins { + function = "HDMI_TX"; + groups = "HDMI_TX1"; + }; + hdmi_A_tx2-pins { + function = "HDMI_TX"; + groups = "HDMI_TX2"; + }; + hdmi_A_tx3-pins { + function = "HDMI_TX"; + groups = "HDMI_TX3"; + }; + + ethernet-pins { + sunplus,pins = < + SPPCTL_IOPAD(49,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_CLK_OUT,0) + SPPCTL_IOPAD(44,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_MAC_SMI_MDC,0) + SPPCTL_IOPAD(43,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_MAC_SMI_MDIO,0) + SPPCTL_IOPAD(52,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_P0_MAC_RMII_TXEN,0) + SPPCTL_IOPAD(50,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_P0_MAC_RMII_TXD0,0) + SPPCTL_IOPAD(51,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_P0_MAC_RMII_TXD1,0) + SPPCTL_IOPAD(46,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_P0_MAC_RMII_CRSDV,0) + SPPCTL_IOPAD(47,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_P0_MAC_RMII_RXD0,0) + SPPCTL_IOPAD(48,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_P0_MAC_RMII_RXD1,0) + >; + sunplus,zerofunc = < + MUXF_L2SW_LED_FLASH0 + MUXF_L2SW_LED_ON0 + MUXF_L2SW_P0_MAC_RMII_RXER + >; + }; + }; +... -- cgit From de645b279144b7d036ef672227af76739365f3ae Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 26 Jan 2022 17:12:17 -0600 Subject: dt-bindings: iio/adc: qcom,spmi-iadc: Fix 'reg' property in example The QCom SPMI PMIC child nodes are defined to have a single address cell, but the example has an erroneous size cell. Remove it. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220126231217.1633935-1-robh@kernel.org Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml index 27e3108661c0..2a94db688830 100644 --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml @@ -51,7 +51,7 @@ examples: #size-cells = <0>; pmic_iadc: adc@3600 { compatible = "qcom,spmi-iadc"; - reg = <0x3600 0x100>; + reg = <0x3600>; interrupts = <0x0 0x36 0x0 IRQ_TYPE_EDGE_RISING>; qcom,external-resistor-micro-ohms = <10000>; #io-channel-cells = <1>; -- cgit From f89ff2b356f01e6789d48f1f58cf537d670303b7 Mon Sep 17 00:00:00 2001 From: Eugen Hristev Date: Fri, 17 Dec 2021 11:54:01 +0200 Subject: dt-bindings: iio: adc: atmel,sama5d2-adc: make atmel,trigger-edge-type non-mandatory The atmel,trigger-edge-type was never imposed by the driver. Make things right and remove this property from the mandatory list. This will not break existing nodes because according to the binding they should have this property. However, the driver does not impose it and it works without it, the property selects the trigger type, and without it, the driver will have no trigger available, which is the case on some boards which do not have access to the trigger pin. This will avoid generating this warning for example: */arch/arm/boot/dts/at91-sama7g5ek.dt.yaml: adc@e1000000: 'atmel,trigger-edge-type' is a required property From schema: */Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml Signed-off-by: Eugen Hristev Acked-by: Rob Herring Link: https://lore.kernel.org/r/20211217095401.583821-1-eugen.hristev@microchip.com Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml index efed361215b4..482d80dd43b5 100644 --- a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml @@ -72,7 +72,6 @@ required: - atmel,min-sample-rate-hz - atmel,max-sample-rate-hz - atmel,startup-time-ms - - atmel,trigger-edge-type examples: - | -- cgit From 7b9c8e1a0ca18a62565ee0e28b23baf7b176e96f Mon Sep 17 00:00:00 2001 From: Nicolas Ferre Date: Sun, 30 Jan 2022 15:50:08 +0100 Subject: dt-bindings: iio: adc: at91-sama5d2: update maintainers entry Update the maintainers entry to match the changes made back in mid-2020 with 853fa48717c2 ("MAINTAINERS: adc: at91-sama5d2_adc: remove myself as co-maintainer"). Signed-off-by: Nicolas Ferre Link: https://lore.kernel.org/r/6acdb66592baf395a77a431c0cb9a37b0f178097.1643554065.git.nicolas.ferre@microchip.com Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml index 482d80dd43b5..31f840d59303 100644 --- a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml @@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: AT91 SAMA5D2 Analog to Digital Converter (ADC) maintainers: - - Ludovic Desroches - Eugen Hristev properties: -- cgit From 4ed941a99996ffeec4b4239df2db82d8b7b183dc Mon Sep 17 00:00:00 2001 From: Pavel Hofman Date: Thu, 27 Jan 2022 12:43:28 +0100 Subject: usb: gadget: f_uac2: Add HS/SS bInterval to configfs Allow configuring the HS/SS bInterval through configfs, via parameters p_hs_bint/c_hs_bint separately for playback/capture. The default param values are left at the original 4. Suggested-by: John Keeping Signed-off-by: Pavel Hofman Link: https://lore.kernel.org/r/20220127114331.41367-2-pavel.hofman@ivitera.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/configfs-usb-gadget-uac2 | 2 ++ Documentation/usb/gadget-testing.rst | 2 ++ 2 files changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2 index 4c6bf63fcb22..33fb237b3ca5 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2 @@ -8,6 +8,7 @@ Description: c_chmask capture channel mask c_srate list of capture sampling rates (comma-separated) c_ssize capture sample size (bytes) + c_hs_bint capture bInterval for HS/SS (1-4) c_sync capture synchronization type (async/adaptive) c_mute_present capture mute control enable @@ -22,6 +23,7 @@ Description: p_chmask playback channel mask p_srate list of playback sampling rates (comma-separated) p_ssize playback sample size (bytes) + p_hs_bint playback bInterval for HS/SS (1-4) p_mute_present playback mute control enable p_volume_present playback volume control enable p_volume_min playback volume control min value diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index 6e8fdfaf19e7..bd91191683be 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -734,6 +734,7 @@ The uac2 function provides these attributes in its function directory: c_volume_min capture volume control min value (in 1/256 dB) c_volume_max capture volume control max value (in 1/256 dB) c_volume_res capture volume control resolution (in 1/256 dB) + c_hs_bint capture bInterval for HS/SS (1-4) fb_max maximum extra bandwidth in async mode p_chmask playback channel mask p_srate list of playback sampling rates (comma-separated) @@ -743,6 +744,7 @@ The uac2 function provides these attributes in its function directory: p_volume_min playback volume control min value (in 1/256 dB) p_volume_max playback volume control max value (in 1/256 dB) p_volume_res playback volume control resolution (in 1/256 dB) + p_hs_bint playback bInterval for HS/SS (1-4) req_number the number of pre-allocated request for both capture and playback function_name name of the interface -- cgit From 355a05dc8367d7533e5925e08dadfc8604961bbc Mon Sep 17 00:00:00 2001 From: Pavel Hofman Date: Thu, 27 Jan 2022 12:43:30 +0100 Subject: usb: gadget: f_uac2: Optionally determine bInterval for HS and SS Allow setting configfs params p_hs_bint/c_hs_bint to 0. If they are set to 0, determine the largest bInterval (4 to 1) for which the required bandwidth of the max samplerate fits the max allowed packet size. If the required bandwidth exceeds max bandwidth for single-packet mode (ep->mc=1), keep bInterval at 1. The FS speed is left at fixed bInterval=1. If for any speed the required bandwidth exceeds the max bandwidth corresponding to the selected/determined bInterval, print a warning. Signed-off-by: Pavel Hofman Link: https://lore.kernel.org/r/20220127114331.41367-4-pavel.hofman@ivitera.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/configfs-usb-gadget-uac2 | 4 ++-- Documentation/usb/gadget-testing.rst | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2 index 33fb237b3ca5..3371c39f651d 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2 @@ -8,7 +8,7 @@ Description: c_chmask capture channel mask c_srate list of capture sampling rates (comma-separated) c_ssize capture sample size (bytes) - c_hs_bint capture bInterval for HS/SS (1-4) + c_hs_bint capture bInterval for HS/SS (1-4: fixed, 0: auto) c_sync capture synchronization type (async/adaptive) c_mute_present capture mute control enable @@ -23,7 +23,7 @@ Description: p_chmask playback channel mask p_srate list of playback sampling rates (comma-separated) p_ssize playback sample size (bytes) - p_hs_bint playback bInterval for HS/SS (1-4) + p_hs_bint playback bInterval for HS/SS (1-4: fixed, 0: auto) p_mute_present playback mute control enable p_volume_present playback volume control enable p_volume_min playback volume control min value diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index bd91191683be..c6d034abce3a 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -734,7 +734,7 @@ The uac2 function provides these attributes in its function directory: c_volume_min capture volume control min value (in 1/256 dB) c_volume_max capture volume control max value (in 1/256 dB) c_volume_res capture volume control resolution (in 1/256 dB) - c_hs_bint capture bInterval for HS/SS (1-4) + c_hs_bint capture bInterval for HS/SS (1-4: fixed, 0: auto) fb_max maximum extra bandwidth in async mode p_chmask playback channel mask p_srate list of playback sampling rates (comma-separated) @@ -744,7 +744,7 @@ The uac2 function provides these attributes in its function directory: p_volume_min playback volume control min value (in 1/256 dB) p_volume_max playback volume control max value (in 1/256 dB) p_volume_res playback volume control resolution (in 1/256 dB) - p_hs_bint playback bInterval for HS/SS (1-4) + p_hs_bint playback bInterval for HS/SS (1-4: fixed, 0: auto) req_number the number of pre-allocated request for both capture and playback function_name name of the interface -- cgit From 1d22c270752ea2b29b9a484e150641f852a10a6d Mon Sep 17 00:00:00 2001 From: Allen-KH Cheng Date: Fri, 28 Jan 2022 14:20:45 +0800 Subject: dt-bindings: serial: Add compatible for Mediatek MT8186 This commit adds dt-binding documentation of uart for Mediatek MT8186 SoC Platform. Signed-off-by: Allen-KH Cheng Link: https://lore.kernel.org/r/20220128062050.23978-3-allen-kh.cheng@mediatek.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/mtk-uart.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt index b3a0bfef0d54..113b5d6a2245 100644 --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt +++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt @@ -20,6 +20,7 @@ Required properties: * "mediatek,mt8135-uart" for MT8135 compatible UARTS * "mediatek,mt8173-uart" for MT8173 compatible UARTS * "mediatek,mt8183-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS + * "mediatek,mt8186-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS * "mediatek,mt8192-uart", "mediatek,mt6577-uart" for MT8192 compatible UARTS * "mediatek,mt8195-uart", "mediatek,mt6577-uart" for MT8195 compatible UARTS * "mediatek,mt8516-uart" for MT8516 compatible UARTS -- cgit From 2127324a7d4a205ceb0452512a3b8c0999b4e86e Mon Sep 17 00:00:00 2001 From: Akhmat Karakotov Date: Mon, 31 Jan 2022 16:31:23 +0300 Subject: txhash: Add txrehash sysctl description Update Documentation/admin-guide/sysctl/net.rst with txrehash usage description. Signed-off-by: Akhmat Karakotov Signed-off-by: David S. Miller --- Documentation/admin-guide/sysctl/net.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst index 4150f74c521a..f86b5e1623c6 100644 --- a/Documentation/admin-guide/sysctl/net.rst +++ b/Documentation/admin-guide/sysctl/net.rst @@ -365,6 +365,15 @@ new netns has been created. Default : 0 (for compatibility reasons) +txrehash +-------- + +Controls default hash rethink behaviour on listening socket when SO_TXREHASH +option is set to SOCK_TXREHASH_DEFAULT (i. e. not overridden by setsockopt). + +If set to 1 (default), hash rethink is performed on listening socket. +If set to 0, hash rethink is not performed. + 2. /proc/sys/net/unix - Parameters for Unix domain sockets ---------------------------------------------------------- -- cgit From 31455bbda2081af83f72bb4636348b12b82c37c1 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Tue, 25 Jan 2022 01:58:36 +0100 Subject: spi: pxa2xx_spi: Convert to use GPIO descriptors This converts the PXA2xx SPI driver to use GPIO descriptors exclusively to retrieve GPIO chip select lines. The device tree and ACPI paths of the driver already use descriptors, hence ->use_gpio_descriptors is already set and this codepath is well tested. Convert all the PXA boards providing chip select GPIOs as platform data and drop the old GPIO chipselect handling in favor of the core managing it exclusively. Cc: Marek Vasut Cc: Daniel Mack Cc: Haojian Zhuang Cc: Robert Jarzmik Cc: linux-arm-kernel@lists.infradead.org Acked-by: Jonathan Cameron Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220125005836.494807-1-linus.walleij@linaro.org Signed-off-by: Mark Brown --- Documentation/spi/pxa2xx.rst | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/spi/pxa2xx.rst b/Documentation/spi/pxa2xx.rst index 6347580826be..716f65d87d04 100644 --- a/Documentation/spi/pxa2xx.rst +++ b/Documentation/spi/pxa2xx.rst @@ -101,7 +101,6 @@ device. All fields are optional. u8 rx_threshold; u8 dma_burst_size; u32 timeout; - int gpio_cs; }; The "pxa2xx_spi_chip.tx_threshold" and "pxa2xx_spi_chip.rx_threshold" fields are @@ -146,7 +145,6 @@ field. Below is a sample configuration using the PXA255 NSSP. .rx_threshold = 8, /* SSP hardward FIFO threshold */ .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */ .timeout = 235, /* See Intel documentation */ - .gpio_cs = 2, /* Use external chip select */ }; static struct pxa2xx_spi_chip cs8405a_chip_info = { @@ -154,7 +152,6 @@ field. Below is a sample configuration using the PXA255 NSSP. .rx_threshold = 8, /* SSP hardward FIFO threshold */ .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */ .timeout = 235, /* See Intel documentation */ - .gpio_cs = 3, /* Use external chip select */ }; static struct spi_board_info streetracer_spi_board_info[] __initdata = { -- cgit From 2f92512e1c52b2670b77f5bf8f16674a48073fc3 Mon Sep 17 00:00:00 2001 From: Horatiu Vultur Date: Mon, 31 Jan 2022 11:01:16 +0100 Subject: dt-bindings: net: lan966x: Extend with the ptp interrupt Extend dt-bindings for lan966x with ptp interrupt. This is generated when doing 2-step timestamping and the timestamp can be read from the FIFO. Signed-off-by: Horatiu Vultur Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml index e79e4e166ad8..13812768b923 100644 --- a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml +++ b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml @@ -38,6 +38,7 @@ properties: - description: register based extraction - description: frame dma based extraction - description: analyzer interrupt + - description: ptp interrupt interrupt-names: minItems: 1 @@ -45,6 +46,7 @@ properties: - const: xtr - const: fdma - const: ana + - const: ptp resets: items: -- cgit From ab28e944197fa78e6af7c4a0ffd6bba9a5bbacf0 Mon Sep 17 00:00:00 2001 From: Tony Luck Date: Mon, 31 Jan 2022 15:01:11 -0800 Subject: topology/sysfs: Add PPIN in sysfs under cpu topology PPIN is the Protected Processor Identification Number. This is used to identify the socket as a Field Replaceable Unit (FRU). Existing code only displays this when reporting errors. But this makes it inconvenient for large clusters to use it for its intended purpose of inventory control. Add ppin to /sys/devices/system/cpu/cpu*/topology to make what is already available using RDMSR more easily accessible. Make the file read only for root in case there are still people concerned about making a unique system "serial number" available. Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Acked-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20220131230111.2004669-6-tony.luck@intel.com --- Documentation/ABI/stable/sysfs-devices-system-cpu | 4 ++++ Documentation/ABI/testing/sysfs-devices-system-cpu | 6 ++++++ 2 files changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu index 3965ce504484..902392d7eddf 100644 --- a/Documentation/ABI/stable/sysfs-devices-system-cpu +++ b/Documentation/ABI/stable/sysfs-devices-system-cpu @@ -86,6 +86,10 @@ What: /sys/devices/system/cpu/cpuX/topology/die_cpus Description: internal kernel map of CPUs within the same die. Values: hexadecimal bitmask. +What: /sys/devices/system/cpu/cpuX/topology/ppin +Description: per-socket protected processor inventory number +Values: hexadecimal. + What: /sys/devices/system/cpu/cpuX/topology/die_cpus_list Description: human-readable list of CPUs within the same die. The format is like 0-3, 8-11, 14,17. diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 61f5676a7429..74962c200790 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -73,6 +73,7 @@ What: /sys/devices/system/cpu/cpuX/topology/core_id /sys/devices/system/cpu/cpuX/topology/physical_package_id /sys/devices/system/cpu/cpuX/topology/thread_siblings /sys/devices/system/cpu/cpuX/topology/thread_siblings_list + /sys/devices/system/cpu/cpuX/topology/ppin Date: December 2008 Contact: Linux kernel mailing list Description: CPU topology files that describe a logical CPU's relationship @@ -103,6 +104,11 @@ Description: CPU topology files that describe a logical CPU's relationship thread_siblings_list: human-readable list of cpuX's hardware threads within the same core as cpuX + ppin: human-readable Protected Processor Identification + Number of the socket the cpu# belongs to. There should be + one per physical_package_id. File is readable only to + admin. + See Documentation/admin-guide/cputopology.rst for more information. -- cgit From dc6cdced47ce1edbca79bdc5a3cd4e435b5358dd Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Sat, 25 Dec 2021 09:51:46 +0800 Subject: docs/zh_CN: Add rbtree Chinese translation Translate core-api/rbtree.rst into Chinese. Signed-off-by: Tang Yizhou Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/20211225015146.1535-1-tangyizhou@huawei.com Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/core-api/index.rst | 2 +- .../translations/zh_CN/core-api/rbtree.rst | 391 +++++++++++++++++++++ 2 files changed, 392 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/core-api/rbtree.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index d10191c45cf1..26d9913fc8b6 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -42,6 +42,7 @@ kref assoc_array xarray + rbtree Todolist: @@ -49,7 +50,6 @@ Todolist: idr circular-buffers - rbtree generic-radix-tree packing bus-virt-phys-mapping diff --git a/Documentation/translations/zh_CN/core-api/rbtree.rst b/Documentation/translations/zh_CN/core-api/rbtree.rst new file mode 100644 index 000000000000..a3e1555cb974 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/rbtree.rst @@ -0,0 +1,391 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/rbtree.rst + +:翻译: + + 唐艺舟 Tang Yizhou + +========================= +Linux中的红黑树（rbtree） +========================= + + +:日期: 2007年1月18日 +:作者: Rob Landley + +何为红黑树，它们有什么用？ +-------------------------- + +红黑树是一种自平衡二叉搜索树，被用来存储可排序的键/值数据对。这与基数树（被用来高效 +存储稀疏数组，因此使用长整型下标来插入/访问/删除结点）和哈希表（没有保持排序因而无法 +容易地按序遍历，同时必须调节其大小和哈希函数，然而红黑树可以优雅地伸缩以便存储任意 +数量的键）不同。 + +红黑树和AVL树类似，但在插入和删除时提供了更快的实时有界的最坏情况性能（分别最多两次 +旋转和三次旋转，来平衡树），查询时间轻微变慢（但时间复杂度仍然是O(log n)）。 + +引用Linux每周新闻（Linux Weekly News）： + + 内核中有多处红黑树的使用案例。最后期限调度器和完全公平排队（CFQ）I/O调度器利用 + 红黑树跟踪请求；数据包CD/DVD驱动程序也是如此。高精度时钟代码使用一颗红黑树组织 + 未完成的定时器请求。ext3文件系统用红黑树跟踪目录项。虚拟内存区域（VMAs）、epoll + 文件描述符、密码学密钥和在“分层令牌桶”调度器中的网络数据包都由红黑树跟踪。 + +本文档涵盖了对Linux红黑树实现的使用方法。更多关于红黑树的性质和实现的信息，参见： + + Linux每周新闻关于红黑树的文章 + https://lwn.net/Articles/184495/ + + 维基百科红黑树词条 + https://en.wikipedia.org/wiki/Red-black_tree + +红黑树的Linux实现 +----------------- + +Linux的红黑树实现在文件“lib/rbtree.c”中。要使用它，需要“#include ”。 + +Linux的红黑树实现对速度进行了优化，因此比传统的实现少一个间接层（有更好的缓存局部性）。 +每个rb_node结构体的实例嵌入在它管理的数据结构中，因此不需要靠指针来分离rb_node和它 +管理的数据结构。用户应该编写他们自己的树搜索和插入函数，来调用已提供的红黑树函数， +而不是使用一个比较回调函数指针。加锁代码也留给红黑树的用户编写。 + +创建一颗红黑树 +-------------- + +红黑树中的数据结点是包含rb_node结构体成员的结构体:: + + struct mytype { + struct rb_node node; + char *keystring; + }; + +当处理一个指向内嵌rb_node结构体的指针时，包住rb_node的结构体可用标准的container_of() +宏访问。此外，个体成员可直接用rb_entry(node, type, member)访问。 + +每颗红黑树的根是一个rb_root数据结构，它由以下方式初始化为空: + + struct rb_root mytree = RB_ROOT; + +在一颗红黑树中搜索值 +-------------------- + +为你的树写一个搜索函数是相当简单的：从树根开始，比较每个值，然后根据需要继续前往左边或 +右边的分支。 + +示例:: + + struct mytype *my_search(struct rb_root *root, char *string) + { + struct rb_node *node = root->rb_node; + + while (node) { + struct mytype *data = container_of(node, struct mytype, node); + int result; + + result = strcmp(string, data->keystring); + + if (result < 0) + node = node->rb_left; + else if (result > 0) + node = node->rb_right; + else + return data; + } + return NULL; + } + +在一颗红黑树中插入数据 +---------------------- + +在树中插入数据的步骤包括：首先搜索插入新结点的位置，然后插入结点并对树再平衡 +（"recoloring"）。 + +插入的搜索和上文的搜索不同，它要找到嫁接新结点的位置。新结点也需要一个指向它的父节点 +的链接，以达到再平衡的目的。 + +示例:: + + int my_insert(struct rb_root *root, struct mytype *data) + { + struct rb_node **new = &(root->rb_node), *parent = NULL; + + /* Figure out where to put new node */ + while (*new) { + struct mytype *this = container_of(*new, struct mytype, node); + int result = strcmp(data->keystring, this->keystring); + + parent = *new; + if (result < 0) + new = &((*new)->rb_left); + else if (result > 0) + new = &((*new)->rb_right); + else + return FALSE; + } + + /* Add new node and rebalance tree. */ + rb_link_node(&data->node, parent, new); + rb_insert_color(&data->node, root); + + return TRUE; + } + +在一颗红黑树中删除或替换已经存在的数据 +-------------------------------------- + +若要从树中删除一个已经存在的结点，调用:: + + void rb_erase(struct rb_node *victim, struct rb_root *tree); + +示例:: + + struct mytype *data = mysearch(&mytree, "walrus"); + + if (data) { + rb_erase(&data->node, &mytree); + myfree(data); + } + +若要用一个新结点替换树中一个已经存在的键值相同的结点，调用:: + + void rb_replace_node(struct rb_node *old, struct rb_node *new, + struct rb_root *tree); + +通过这种方式替换结点不会对树做重排序：如果新结点的键值和旧结点不同，红黑树可能被 +破坏。 + +（按排序的顺序）遍历存储在红黑树中的元素 +---------------------------------------- + +我们提供了四个函数，用于以排序的方式遍历一颗红黑树的内容。这些函数可以在任意红黑树 +上工作，并且不需要被修改或包装（除非加锁的目的）:: + + struct rb_node *rb_first(struct rb_root *tree); + struct rb_node *rb_last(struct rb_root *tree); + struct rb_node *rb_next(struct rb_node *node); + struct rb_node *rb_prev(struct rb_node *node); + +要开始迭代，需要使用一个指向树根的指针调用rb_first()或rb_last()，它将返回一个指向 +树中第一个或最后一个元素所包含的节点结构的指针。要继续的话，可以在当前结点上调用 +rb_next()或rb_prev()来获取下一个或上一个结点。当没有剩余的结点时，将返回NULL。 + +迭代器函数返回一个指向被嵌入的rb_node结构体的指针，由此，包住rb_node的结构体可用 +标准的container_of()宏访问。此外，个体成员可直接用rb_entry(node, type, member) +访问。 + +示例:: + + struct rb_node *node; + for (node = rb_first(&mytree); node; node = rb_next(node)) + printk("key=%s\n", rb_entry(node, struct mytype, node)->keystring); + +带缓存的红黑树 +-------------- + +计算最左边（最小的）结点是二叉搜索树的一个相当常见的任务，例如用于遍历，或用户根据 +他们自己的逻辑依赖一个特定的顺序。为此，用户可以使用'struct rb_root_cached'来优化 +时间复杂度为O(logN)的rb_first()的调用，以简单地获取指针，避免了潜在的昂贵的树迭代。 +维护操作的额外运行时间开销可忽略，不过内存占用较大。 + +和rb_root结构体类似，带缓存的红黑树由以下方式初始化为空:: + + struct rb_root_cached mytree = RB_ROOT_CACHED; + +带缓存的红黑树只是一个常规的rb_root，加上一个额外的指针来缓存最左边的节点。这使得 +rb_root_cached可以存在于rb_root存在的任何地方，并且只需增加几个接口来支持带缓存的 +树:: + + struct rb_node *rb_first_cached(struct rb_root_cached *tree); + void rb_insert_color_cached(struct rb_node *, struct rb_root_cached *, bool); + void rb_erase_cached(struct rb_node *node, struct rb_root_cached *); + +操作和删除也有对应的带缓存的树的调用:: + + void rb_insert_augmented_cached(struct rb_node *node, struct rb_root_cached *, + bool, struct rb_augment_callbacks *); + void rb_erase_augmented_cached(struct rb_node *, struct rb_root_cached *, + struct rb_augment_callbacks *); + + +对增强型红黑树的支持 +-------------------- + +增强型红黑树是一种在每个结点里存储了“一些”附加数据的红黑树，其中结点N的附加数据 +必须是以N为根的子树中所有结点的内容的函数。它是建立在红黑树基础设施之上的可选特性。 +想要使用这个特性的红黑树用户，插入和删除结点时必须调用增强型接口并提供增强型回调函数。 + +实现增强型红黑树操作的C文件必须包含而不是。 +注意，linux/rbtree_augmented.h暴露了一些红黑树实现的细节而你不应依赖它们，请坚持 +使用文档记录的API，并且不要在头文件中包含，以最小化你的 +用户意外地依赖这些实现细节的可能。 + +插入时，用户必须更新通往被插入节点的路径上的增强信息，然后像往常一样调用rb_link_node()， +然后是rb_augment_inserted()而不是平时的rb_insert_color()调用。如果 +rb_augment_inserted()再平衡了红黑树，它将回调至一个用户提供的函数来更新受影响的 +子树上的增强信息。 + +删除一个结点时，用户必须调用rb_erase_augmented()而不是rb_erase()。 +rb_erase_augmented()回调至一个用户提供的函数来更新受影响的子树上的增强信息。 + +在两种情况下，回调都是通过rb_augment_callbacks结构体提供的。必须定义3个回调： + +- 一个传播回调，它更新一个给定结点和它的祖先们的增强数据，直到一个给定的停止点 + （如果是NULL，将更新一路更新到树根）。 + +- 一个复制回调，它将一颗给定子树的增强数据复制到一个新指定的子树树根。 + +- 一个树旋转回调，它将一颗给定的子树的增强值复制到新指定的子树树根上，并重新计算 + 先前的子树树根的增强值。 + +rb_erase_augmented()编译后的代码可能会内联传播、复制回调，这将导致函数体积更大， +因此每个增强型红黑树的用户应该只有一个rb_erase_augmented()的调用点，以限制编译后 +的代码大小。 + + +使用示例 +^^^^^^^^ + +区间树是增强型红黑树的一个例子。参考Cormen，Leiserson，Rivest和Stein写的 +《算法导论》。区间树的更多细节： + +经典的红黑树只有一个键，它不能直接用来存储像[lo:hi]这样的区间范围，也不能快速查找 +与新的lo:hi重叠的部分，或者查找是否有与新的lo:hi完全匹配的部分。 + +然而，红黑树可以被增强，以一种结构化的方式来存储这种区间范围，从而使高效的查找和 +精确匹配成为可能。 + +这个存储在每个节点中的“额外信息”是其所有后代结点中的最大hi（max_hi）值。这个信息 +可以保持在每个结点上，只需查看一下该结点和它的直系子结点们。这将被用于时间复杂度 +为O(log n)的最低匹配查找（所有可能的匹配中最低的起始地址），就像这样:: + + struct interval_tree_node * + interval_tree_first_match(struct rb_root *root, + unsigned long start, unsigned long last) + { + struct interval_tree_node *node; + + if (!root->rb_node) + return NULL; + node = rb_entry(root->rb_node, struct interval_tree_node, rb); + + while (true) { + if (node->rb.rb_left) { + struct interval_tree_node *left = + rb_entry(node->rb.rb_left, + struct interval_tree_node, rb); + if (left->__subtree_last >= start) { + /* + * Some nodes in left subtree satisfy Cond2. + * Iterate to find the leftmost such node N. + * If it also satisfies Cond1, that's the match + * we are looking for. Otherwise, there is no + * matching interval as nodes to the right of N + * can't satisfy Cond1 either. + */ + node = left; + continue; + } + } + if (node->start <= last) { /* Cond1 */ + if (node->last >= start) /* Cond2 */ + return node; /* node is leftmost match */ + if (node->rb.rb_right) { + node = rb_entry(node->rb.rb_right, + struct interval_tree_node, rb); + if (node->__subtree_last >= start) + continue; + } + } + return NULL; /* No match */ + } + } + +插入/删除是通过以下增强型回调来定义的:: + + static inline unsigned long + compute_subtree_last(struct interval_tree_node *node) + { + unsigned long max = node->last, subtree_last; + if (node->rb.rb_left) { + subtree_last = rb_entry(node->rb.rb_left, + struct interval_tree_node, rb)->__subtree_last; + if (max < subtree_last) + max = subtree_last; + } + if (node->rb.rb_right) { + subtree_last = rb_entry(node->rb.rb_right, + struct interval_tree_node, rb)->__subtree_last; + if (max < subtree_last) + max = subtree_last; + } + return max; + } + + static void augment_propagate(struct rb_node *rb, struct rb_node *stop) + { + while (rb != stop) { + struct interval_tree_node *node = + rb_entry(rb, struct interval_tree_node, rb); + unsigned long subtree_last = compute_subtree_last(node); + if (node->__subtree_last == subtree_last) + break; + node->__subtree_last = subtree_last; + rb = rb_parent(&node->rb); + } + } + + static void augment_copy(struct rb_node *rb_old, struct rb_node *rb_new) + { + struct interval_tree_node *old = + rb_entry(rb_old, struct interval_tree_node, rb); + struct interval_tree_node *new = + rb_entry(rb_new, struct interval_tree_node, rb); + + new->__subtree_last = old->__subtree_last; + } + + static void augment_rotate(struct rb_node *rb_old, struct rb_node *rb_new) + { + struct interval_tree_node *old = + rb_entry(rb_old, struct interval_tree_node, rb); + struct interval_tree_node *new = + rb_entry(rb_new, struct interval_tree_node, rb); + + new->__subtree_last = old->__subtree_last; + old->__subtree_last = compute_subtree_last(old); + } + + static const struct rb_augment_callbacks augment_callbacks = { + augment_propagate, augment_copy, augment_rotate + }; + + void interval_tree_insert(struct interval_tree_node *node, + struct rb_root *root) + { + struct rb_node **link = &root->rb_node, *rb_parent = NULL; + unsigned long start = node->start, last = node->last; + struct interval_tree_node *parent; + + while (*link) { + rb_parent = *link; + parent = rb_entry(rb_parent, struct interval_tree_node, rb); + if (parent->__subtree_last < last) + parent->__subtree_last = last; + if (start < parent->start) + link = &parent->rb.rb_left; + else + link = &parent->rb.rb_right; + } + + node->__subtree_last = last; + rb_link_node(&node->rb, rb_parent, link); + rb_insert_augmented(&node->rb, root, &augment_callbacks); + } + + void interval_tree_remove(struct interval_tree_node *node, + struct rb_root *root) + { + rb_erase_augmented(&node->rb, root, &augment_callbacks); + } -- cgit From 5dbbc145d24ac68fc481fc6fe0e4ec3d7a4b8007 Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Tue, 21 Dec 2021 11:18:18 +0800 Subject: docs: scheduler: Fix outdated parameter of rebalance_domains According to the function prototype of rebalance_domains(), its first parameter is *rq* and the document need to be updated. Signed-off-by: Tang Yizhou Link: https://lore.kernel.org/r/20211221031818.23186-1-tangyizhou@huawei.com Signed-off-by: Jonathan Corbet --- Documentation/scheduler/sched-domains.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scheduler/sched-domains.rst b/Documentation/scheduler/sched-domains.rst index 84dcdcd2911c..e57ad28301bd 100644 --- a/Documentation/scheduler/sched-domains.rst +++ b/Documentation/scheduler/sched-domains.rst @@ -37,10 +37,10 @@ rebalancing event for the current runqueue has arrived. The actual load balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run in softirq context (SCHED_SOFTIRQ). -The latter function takes two arguments: the current CPU and whether it was idle -at the time the scheduler_tick() happened and iterates over all sched domains -our CPU is on, starting from its base domain and going up the ->parent chain. -While doing that, it checks to see if the current domain has exhausted its +The latter function takes two arguments: the runqueue of current CPU and whether +the CPU was idle at the time the scheduler_tick() happened and iterates over all +sched domains our CPU is on, starting from its base domain and going up the ->parent +chain. While doing that, it checks to see if the current domain has exhausted its rebalance interval. If so, it runs load_balance() on that domain. It then checks the parent sched_domain (if it exists), and the parent of the parent and so forth. -- cgit From a469948b20ed9898f61e9906fd9b135ad853bb94 Mon Sep 17 00:00:00 2001 From: Alison Chaiken Date: Tue, 11 Jan 2022 15:32:53 -0800 Subject: rcu: Update documentation regarding kthread_prio cmdline parameter Inform readers that the priority of RCU no-callback threads will also be boosted. Signed-off-by: Alison Chaiken Signed-off-by: Paul E. McKenney --- Documentation/admin-guide/kernel-parameters.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index f5a27f067db9..8e2e65122b99 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4504,6 +4504,8 @@ (the least-favored priority). Otherwise, when RCU_BOOST is not set, valid values are 0-99 and the default is zero (non-realtime operation). + When RCU_NOCB_CPU is set, also adjust the + priority of NOCB callback kthreads. rcutree.rcu_nocb_gp_stride= [KNL] Set the number of NOCB callback kthreads in -- cgit From 678eb67513a963e5ce00a4ed6a07a5722bd1267e Mon Sep 17 00:00:00 2001 From: Biju Das Date: Mon, 10 Jan 2022 13:46:51 +0000 Subject: dt-bindings: clock: renesas: Document RZ/V2L SoC Document the device tree binding for the Renesas RZ/V2L SoC. Signed-off-by: Biju Das Signed-off-by: Lad Prabhakar Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220110134659.30424-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- .../devicetree/bindings/clock/renesas,rzg2l-cpg.yaml | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml index 30b2e3d0d25d..bd3af8fc616b 100644 --- a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml @@ -4,13 +4,13 @@ $id: "http://devicetree.org/schemas/clock/renesas,rzg2l-cpg.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" -title: Renesas RZ/G2L Clock Pulse Generator / Module Standby Mode +title: Renesas RZ/{G2L,V2L} Clock Pulse Generator / Module Standby Mode maintainers: - Geert Uytterhoeven description: | - On Renesas RZ/G2L SoC, the CPG (Clock Pulse Generator) and Module + On Renesas RZ/{G2L,V2L} SoC, the CPG (Clock Pulse Generator) and Module Standby Mode share the same register block. They provide the following functionalities: @@ -22,7 +22,9 @@ description: | properties: compatible: - const: renesas,r9a07g044-cpg # RZ/G2{L,LC} + enum: + - renesas,r9a07g044-cpg # RZ/G2{L,LC} + - renesas,r9a07g054-cpg # RZ/V2L reg: maxItems: 1 @@ -40,9 +42,9 @@ properties: description: | - For CPG core clocks, the two clock specifier cells must be "CPG_CORE" and a core clock reference, as defined in - + - For module clocks, the two clock specifier cells must be "CPG_MOD" and - a module number, as defined in the . + a module number, as defined in the . const: 2 '#power-domain-cells': @@ -56,7 +58,7 @@ properties: '#reset-cells': description: The single reset specifier cell must be the module number, as defined in - the . + the . const: 1 required: -- cgit From 4737499ca3dfefb86d70a5a3a9d4cef2bb3bdabc Mon Sep 17 00:00:00 2001 From: John Crispin Date: Sun, 30 Jan 2022 15:51:14 +0100 Subject: dt-bindings: arm: airoha: Add binding for Airoha GPIO controller Airoha's GPIO controller on their ARM EN7523 SoCs consists of two banks of 32 GPIOs Reviewed-by: Linus Walleij Reviewed-by: Rob Herring Signed-off-by: John Crispin Signed-off-by: Felix Fietkau [Bartosz: removed stray newline at the end of the file] Signed-off-by: Bartosz Golaszewski --- .../bindings/gpio/airoha,en7523-gpio.yaml | 66 ++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/airoha,en7523-gpio.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/airoha,en7523-gpio.yaml b/Documentation/devicetree/bindings/gpio/airoha,en7523-gpio.yaml new file mode 100644 index 000000000000..7c41d8e814cd --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/airoha,en7523-gpio.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/airoha,en7523-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Airoha EN7523 GPIO controller + +maintainers: + - John Crispin + +description: | + Airoha's GPIO controller on their ARM EN7523 SoCs consists of two banks of 32 + GPIOs. + +properties: + $nodename: + pattern: "^gpio@[0-9a-f]+$" + + compatible: + items: + - const: airoha,en7523-gpio + + reg: + description: | + The first tuple points to the input register. + The second and third tuple point to the direction registers + The fourth tuple points to the output register + maxItems: 4 + + "#gpio-cells": + const: 2 + + gpio-controller: true + +required: + - compatible + - reg + - "#gpio-cells" + - gpio-controller + +additionalProperties: false + +examples: + - | + gpio0: gpio@1fbf0200 { + compatible = "airoha,en7523-gpio"; + reg = <0x1fbf0204 0x4>, + <0x1fbf0200 0x4>, + <0x1fbf0220 0x4>, + <0x1fbf0214 0x4>; + gpio-controller; + #gpio-cells = <2>; + }; + + gpio1: gpio@1fbf0270 { + compatible = "airoha,en7523-gpio"; + reg = <0x1fbf0270 0x4>, + <0x1fbf0260 0x4>, + <0x1fbf0264 0x4>, + <0x1fbf0278 0x4>; + gpio-controller; + #gpio-cells = <2>; + }; + +... -- cgit From ea8a12e350e86aaa5fe7815db864b35fae2356f1 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Thu, 27 Jan 2022 15:30:44 +0100 Subject: dt-bindings: display: Turn lvds.yaml into a generic schema The lvds.yaml file so far was both defining the generic LVDS properties (such as data-mapping) that could be used for any LVDS sink, but also the panel-lvds binding. That last binding was to describe LVDS panels simple enough, and had a number of other bindings using it as a base to specialise it further. However, this situation makes it fairly hard to extend and reuse both the generic parts, and the panel-lvds itself. Let's remove the panel-lvds parts and leave only the generic LVDS properties. Reviewed-by: Laurent Pinchart Reviewed-by: Rob Herring Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20220127143045.310199-1-maxime@cerno.tech --- .../bindings/display/bridge/lvds-codec.yaml | 2 +- .../devicetree/bindings/display/lvds.yaml | 90 ++++++++++++++++ .../display/panel/advantech,idk-1110wr.yaml | 19 +++- .../display/panel/innolux,ee101ia-01d.yaml | 23 +++- .../devicetree/bindings/display/panel/lvds.yaml | 117 --------------------- .../display/panel/mitsubishi,aa104xd12.yaml | 19 +++- .../display/panel/mitsubishi,aa121td01.yaml | 19 +++- .../bindings/display/panel/sgd,gktw70sdae4se.yaml | 19 +++- 8 files changed, 180 insertions(+), 128 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/lvds.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/lvds.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index 080c59f5118b..e9617cece7cc 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml @@ -68,7 +68,7 @@ properties: - vesa-24 description: | The color signals mapping order. See details in - Documentation/devicetree/bindings/display/panel/lvds.yaml + Documentation/devicetree/bindings/display/lvds.yaml port@1: $ref: /schemas/graph.yaml#/properties/port diff --git a/Documentation/devicetree/bindings/display/lvds.yaml b/Documentation/devicetree/bindings/display/lvds.yaml new file mode 100644 index 000000000000..7cd2ce7e9c33 --- /dev/null +++ b/Documentation/devicetree/bindings/display/lvds.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/lvds.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LVDS Display Common Properties + +maintainers: + - Laurent Pinchart + - Thierry Reding + +description: |+ + LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple + incompatible data link layers have been used over time to transmit image data + to LVDS devices. This bindings supports devices compatible with the following + specifications. + + [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February + 1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA) + [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National + Semiconductor + [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video + Electronics Standards Association (VESA) + + Device compatible with those specifications have been marketed under the + FPD-Link and FlatLink brands. + +properties: + data-mapping: + enum: + - jeida-18 + - jeida-24 + - vesa-24 + description: | + The color signals mapping order. + + LVDS data mappings are defined as follows. + + - "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and + [VESA] specifications. Data are transferred as follows on 3 LVDS lanes. + + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< + DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< + + - "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI] + specifications. Data are transferred as follows on 4 LVDS lanes. + + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__>< + DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__>< + DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__>< + + - "vesa-24" - 24-bit data mapping compatible with the [VESA] specification. + Data are transferred as follows on 4 LVDS lanes. + + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< + DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< + DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__>< + + Control signals are mapped as follows. + + CTL0: HSync + CTL1: VSync + CTL2: Data Enable + CTL3: 0 + + data-mirror: + type: boolean + description: + If set, reverse the bit order described in the data mappings below on all + data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6. + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml index 93878c2cd370..3a8c2c11f9bd 100644 --- a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml +++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml @@ -11,13 +11,23 @@ maintainers: - Thierry Reding allOf: - - $ref: lvds.yaml# + - $ref: panel-common.yaml# + - $ref: /schemas/display/lvds.yaml/# + +select: + properties: + compatible: + contains: + const: advantech,idk-1110wr + + required: + - compatible properties: compatible: items: - const: advantech,idk-1110wr - - {} # panel-lvds, but not listed here to avoid false select + - const: panel-lvds data-mapping: const: jeida-24 @@ -35,6 +45,11 @@ additionalProperties: false required: - compatible + - data-mapping + - width-mm + - height-mm + - panel-timing + - port examples: - |+ diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml index a69681e724cb..566e11f6bfc0 100644 --- a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml +++ b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml @@ -11,15 +11,26 @@ maintainers: - Thierry Reding allOf: - - $ref: lvds.yaml# + - $ref: panel-common.yaml# + - $ref: /schemas/display/lvds.yaml/# + +select: + properties: + compatible: + contains: + const: innolux,ee101ia-01d + + required: + - compatible properties: compatible: items: - const: innolux,ee101ia-01d - - {} # panel-lvds, but not listed here to avoid false select + - const: panel-lvds backlight: true + data-mapping: true enable-gpios: true power-supply: true width-mm: true @@ -27,5 +38,13 @@ properties: panel-timing: true port: true +required: + - compatible + - data-mapping + - width-mm + - height-mm + - panel-timing + - port + additionalProperties: false ... diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml b/Documentation/devicetree/bindings/display/panel/lvds.yaml deleted file mode 100644 index 49460c9dceea..000000000000 --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml +++ /dev/null @@ -1,117 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/display/panel/lvds.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: LVDS Display Panel - -maintainers: - - Laurent Pinchart - - Thierry Reding - -description: |+ - LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple - incompatible data link layers have been used over time to transmit image data - to LVDS panels. This bindings supports display panels compatible with the - following specifications. - - [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February - 1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA) - [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National - Semiconductor - [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video - Electronics Standards Association (VESA) - - Device compatible with those specifications have been marketed under the - FPD-Link and FlatLink brands. - -allOf: - - $ref: panel-common.yaml# - -properties: - compatible: - contains: - const: panel-lvds - description: - Shall contain "panel-lvds" in addition to a mandatory panel-specific - compatible string defined in individual panel bindings. The "panel-lvds" - value shall never be used on its own. - - data-mapping: - enum: - - jeida-18 - - jeida-24 - - vesa-24 - description: | - The color signals mapping order. - - LVDS data mappings are defined as follows. - - - "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and - [VESA] specifications. Data are transferred as follows on 3 LVDS lanes. - - Slot 0 1 2 3 4 5 6 - ________________ _________________ - Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ - DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< - DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< - DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< - - - "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI] - specifications. Data are transferred as follows on 4 LVDS lanes. - - Slot 0 1 2 3 4 5 6 - ________________ _________________ - Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ - DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__>< - DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__>< - DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__>< - DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__>< - - - "vesa-24" - 24-bit data mapping compatible with the [VESA] specification. - Data are transferred as follows on 4 LVDS lanes. - - Slot 0 1 2 3 4 5 6 - ________________ _________________ - Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ - DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< - DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< - DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< - DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__>< - - Control signals are mapped as follows. - - CTL0: HSync - CTL1: VSync - CTL2: Data Enable - CTL3: 0 - - data-mirror: - type: boolean - description: - If set, reverse the bit order described in the data mappings below on all - data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6. - - port: true - ports: true - -required: - - compatible - - data-mapping - - width-mm - - height-mm - - panel-timing - -oneOf: - - required: - - port - - required: - - ports - -additionalProperties: true - -... diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml index b5e7ee230fa6..5cf3c588f46d 100644 --- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml +++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml @@ -11,13 +11,23 @@ maintainers: - Thierry Reding allOf: - - $ref: lvds.yaml# + - $ref: panel-common.yaml# + - $ref: /schemas/display/lvds.yaml/# + +select: + properties: + compatible: + contains: + const: mitsubishi,aa104xd12 + + required: + - compatible properties: compatible: items: - const: mitsubishi,aa104xd12 - - {} # panel-lvds, but not listed here to avoid false select + - const: panel-lvds vcc-supply: description: Reference to the regulator powering the panel VCC pins. @@ -39,6 +49,11 @@ additionalProperties: false required: - compatible - vcc-supply + - data-mapping + - width-mm + - height-mm + - panel-timing + - port examples: - |+ diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml index 977c50a85b67..54750cc5440d 100644 --- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml +++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml @@ -11,13 +11,23 @@ maintainers: - Thierry Reding allOf: - - $ref: lvds.yaml# + - $ref: panel-common.yaml# + - $ref: /schemas/display/lvds.yaml/# + +select: + properties: + compatible: + contains: + const: mitsubishi,aa121td01 + + required: + - compatible properties: compatible: items: - const: mitsubishi,aa121td01 - - {} # panel-lvds, but not listed here to avoid false select + - const: panel-lvds vcc-supply: description: Reference to the regulator powering the panel VCC pins. @@ -39,6 +49,11 @@ additionalProperties: false required: - compatible - vcc-supply + - data-mapping + - width-mm + - height-mm + - panel-timing + - port examples: - |+ diff --git a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml index e63a570ae59d..44e02decdf3a 100644 --- a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml +++ b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml @@ -11,13 +11,23 @@ maintainers: - Thierry Reding allOf: - - $ref: lvds.yaml# + - $ref: panel-common.yaml# + - $ref: /schemas/display/lvds.yaml/# + +select: + properties: + compatible: + contains: + const: sgd,gktw70sdae4se + + required: + - compatible properties: compatible: items: - const: sgd,gktw70sdae4se - - {} # panel-lvds, but not listed here to avoid false select + - const: panel-lvds data-mapping: const: jeida-18 @@ -35,6 +45,11 @@ additionalProperties: false required: - compatible + - port + - data-mapping + - width-mm + - height-mm + - panel-timing examples: - |+ -- cgit From 1b3cf0133fbdeac863510fc8899efdbed91c15c0 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Tue, 11 Jan 2022 12:06:35 +0100 Subject: dt-bindings: panel: Introduce a panel-lvds binding Following the previous patch, let's introduce a generic panel-lvds binding that documents the panels that don't have any particular constraint documented. Reviewed-by: Rob Herring Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20220111110635.804371-2-maxime@cerno.tech --- .../bindings/display/panel/panel-lvds.yaml | 57 ++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/panel-lvds.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml new file mode 100644 index 000000000000..fcc50db6a812 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-lvds.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic LVDS Display Panel Device Tree Bindings + +maintainers: + - Lad Prabhakar + - Thierry Reding + +allOf: + - $ref: panel-common.yaml# + - $ref: /schemas/display/lvds.yaml/# + +select: + properties: + compatible: + contains: + const: panel-lvds + + not: + properties: + compatible: + contains: + enum: + - advantech,idk-1110wr + - advantech,idk-2121wr + - innolux,ee101ia-01d + - mitsubishi,aa104xd12 + - mitsubishi,aa121td01 + - sgd,gktw70sdae4se + + required: + - compatible + +properties: + compatible: + items: + - enum: + - auo,b101ew05 + - tbs,a711-panel + + - const: panel-lvds + +unevaluatedProperties: false + +required: + - compatible + - data-mapping + - width-mm + - height-mm + - panel-timing + - port + +... -- cgit From 1f1b0c105b19ac0d90975e2569040da1216489b7 Mon Sep 17 00:00:00 2001 From: Allen-KH Cheng Date: Fri, 28 Jan 2022 14:20:48 +0800 Subject: dt-bindings: phy: Add compatible for Mediatek MT8186 This commit adds dt-binding documentation of T-Phy for Mediatek MT8186 SoC Platform. Signed-off-by: Allen-KH Cheng Link: https://lore.kernel.org/r/20220128062050.23978-6-allen-kh.cheng@mediatek.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index 05ee274b4b71..d279ba222316 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -80,6 +80,7 @@ properties: - mediatek,mt2712-tphy - mediatek,mt7629-tphy - mediatek,mt8183-tphy + - mediatek,mt8186-tphy - const: mediatek,generic-tphy-v2 - items: - enum: -- cgit From 322cbb50de711814c42fb088f6d31901502c711a Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Mon, 24 Jan 2022 10:39:13 +0100 Subject: block: remove genhd.h There is no good reason to keep genhd.h separate from the main blkdev.h header that includes it. So fold the contents of genhd.h into blkdev.h and remove genhd.h entirely. Signed-off-by: Christoph Hellwig Reviewed-by: Chaitanya Kulkarni Reviewed-by: Martin K. Petersen Link: https://lore.kernel.org/r/20220124093913.742411-4-hch@lst.de Signed-off-by: Jens Axboe --- Documentation/block/capability.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/block/capability.rst b/Documentation/block/capability.rst index 160a5148b915..2ae7f064736a 100644 --- a/Documentation/block/capability.rst +++ b/Documentation/block/capability.rst @@ -7,4 +7,4 @@ This file documents the sysfs file ``block//capability``. ``capability`` is a bitfield, printed in hexadecimal, indicating which capabilities a specific block device supports: -.. kernel-doc:: include/linux/genhd.h +.. kernel-doc:: include/linux/blkdev.h -- cgit From da9fcbf262bc5e41923b9051e382dc27fd4cc570 Mon Sep 17 00:00:00 2001 From: Horatiu Vultur Date: Tue, 25 Jan 2022 14:18:57 +0100 Subject: dt-bindings: pinctrl: ocelot: Add ServalT SoC support Add the documentation for the Microsemi ServalT pinmuxing and gpio controller. Signed-off-by: Horatiu Vultur Link: https://lore.kernel.org/r/20220125131858.309237-2-horatiu.vultur@microchip.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt index 3bb76487669f..5d84fd299ccf 100644 --- a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt @@ -4,8 +4,8 @@ Microsemi Ocelot pin controller Device Tree Bindings Required properties: - compatible : Should be "mscc,ocelot-pinctrl", "mscc,jaguar2-pinctrl", "microchip,sparx5-pinctrl", - "mscc,luton-pinctrl", "mscc,serval-pinctrl" or - "microchip,lan966x-pinctrl" + "mscc,luton-pinctrl", "mscc,serval-pinctrl", + "microchip,lan966x-pinctrl" or "mscc,servalt-pinctrl" - reg : Address and length of the register set for the device - gpio-controller : Indicates this device is a GPIO controller - #gpio-cells : Must be 2. -- cgit From b2e4a2b300e5e2042e8d92ec16fc124222b7ecc9 Mon Sep 17 00:00:00 2001 From: Konstantin Vyshetsky Date: Mon, 13 Dec 2021 17:12:43 -0800 Subject: f2fs: expose discard related parameters in sysfs This patch exposes max_discard_request, min_discard_issue_time, mid_discard_issue_time, and max_discard_issue_time in sysfs. This will allow the user to fine tune discard operations. Signed-off-by: Konstantin Vyshetsky Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/ABI/testing/sysfs-fs-f2fs | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 2416b03ff283..87d3884c90ea 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -98,6 +98,33 @@ Description: Controls the issue rate of discard commands that consist of small checkpoint is triggered, and issued during the checkpoint. By default, it is disabled with 0. +What: /sys/fs/f2fs//max_discard_request +Date: December 2021 +Contact: "Konstantin Vyshetsky" +Description: Controls the number of discards a thread will issue at a time. + Higher number will allow the discard thread to finish its work + faster, at the cost of higher latency for incomming I/O. + +What: /sys/fs/f2fs//min_discard_issue_time +Date: December 2021 +Contact: "Konstantin Vyshetsky" +Description: Controls the interval the discard thread will wait between + issuing discard requests when there are discards to be issued and + no I/O aware interruptions occur. + +What: /sys/fs/f2fs//mid_discard_issue_time +Date: December 2021 +Contact: "Konstantin Vyshetsky" +Description: Controls the interval the discard thread will wait between + issuing discard requests when there are discards to be issued and + an I/O aware interruption occurs. + +What: /sys/fs/f2fs//max_discard_issue_time +Date: December 2021 +Contact: "Konstantin Vyshetsky" +Description: Controls the interval the discard thread will wait when there are + no discard operations to be issued. + What: /sys/fs/f2fs//discard_granularity Date: July 2017 Contact: "Chao Yu" -- cgit From 7f97b2ad948343c3be543d12c2965f74bddc34c7 Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Wed, 2 Feb 2022 20:01:13 -0600 Subject: ASoC: dt-bindings: sun4i-i2s: Add compatibles for R329 and D1 R329 contains I2S controllers which are similar to, but are incompatible with, the H6 variant, because they change the layout of the RX channel mapping registers. The D1 contains I2S controllers which appear to be identical to those in the R329. Signed-off-by: Samuel Holland Acked-by: Maxime Ripard Link: https://lore.kernel.org/r/20220203020116.12279-2-samuel@sholland.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml index 7d48ea094c66..c21c807b667c 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml @@ -31,6 +31,10 @@ properties: - const: allwinner,sun50i-a64-i2s - const: allwinner,sun8i-h3-i2s - const: allwinner,sun50i-h6-i2s + - const: allwinner,sun50i-r329-i2s + - items: + - const: allwinner,sun20i-d1-i2s + - const: allwinner,sun50i-r329-i2s reg: maxItems: 1 @@ -67,6 +71,7 @@ allOf: - allwinner,sun8i-h3-i2s - allwinner,sun50i-a64-codec-i2s - allwinner,sun50i-h6-i2s + - allwinner,sun50i-r329-i2s then: required: -- cgit From 0214f6c700eb7a8a4370c2543cc427558e6c444c Mon Sep 17 00:00:00 2001 From: Lorenzo Bianconi Date: Wed, 12 Jan 2022 18:53:55 +0100 Subject: dt-bindings:net:wireless:mediatek,mt76: add disable-radar-offchan Add the capability to disable/enable radar/CAC detection running on a dedicated offchannel chain available on some hw. Offchannel radar/CAC detection allows to avoid CAC downtime switching on a different channel during CAC detection on the selected radar channel. Signed-off-by: Lorenzo Bianconi Acked-by: Rob Herring Signed-off-by: Felix Fietkau --- .../devicetree/bindings/net/wireless/mediatek,mt76.yaml | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml index 269cd63fb544..025f4242f8f7 100644 --- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml @@ -69,6 +69,15 @@ properties: calibration data is generic and specific calibration data should be pulled from the OTP ROM + mediatek,disable-radar-background: + type: boolean + description: + Disable/enable radar/CAC detection running on a dedicated offchannel + chain available on some hw. + Background radar/CAC detection allows to avoid the CAC downtime + switching on a different channel during CAC detection on the selected + radar channel. + led: type: object $ref: /schemas/leds/common.yaml# -- cgit From 4e28b22225e3a8b7f1bd3e093301802a2238071a Mon Sep 17 00:00:00 2001 From: David Heidelberg Date: Wed, 2 Feb 2022 11:47:15 +0100 Subject: spi: dt-bindings: add mising description type to reg property Added missing description type. Fixes warning: Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml: properties:reg:items: 'anyOf' conditional failed Fixes: a708078eeb99 ("spi: Add Sunplus SP7021 schema") Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20220202104715.27839-1-david@ixit.cz Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml b/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml index 24382cdda645..38589fdbc80d 100644 --- a/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml +++ b/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml @@ -20,8 +20,8 @@ properties: reg: items: - - the SPI master registers - - the SPI slave registers + - description: the SPI master registers + - description: the SPI slave registers reg-names: items: -- cgit From dd33fb571f5cd25c0d0f9d017dba783c85b70b82 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Mon, 31 Jan 2022 19:36:34 +0100 Subject: bpf, docs: Document the byte swapping instructions Add a section to document the byte swapping instructions. Signed-off-by: Christoph Hellwig Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20220131183638.3934982-2-hch@lst.de --- Documentation/bpf/instruction-set.rst | 44 +++++++++++++++++++++++++++++++---- 1 file changed, 40 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst index 3704836fe6df..87f6ad62633a 100644 --- a/Documentation/bpf/instruction-set.rst +++ b/Documentation/bpf/instruction-set.rst @@ -82,9 +82,9 @@ BPF_ALU uses 32-bit wide operands while BPF_ALU64 uses 64-bit wide operands for otherwise identical operations. The code field encodes the operation as below: - ======== ===== ========================== + ======== ===== ================================================= code value description - ======== ===== ========================== + ======== ===== ================================================= BPF_ADD 0x00 dst += src BPF_SUB 0x10 dst -= src BPF_MUL 0x20 dst \*= src @@ -98,8 +98,8 @@ The code field encodes the operation as below: BPF_XOR 0xa0 dst ^= src BPF_MOV 0xb0 dst = src BPF_ARSH 0xc0 sign extending shift right - BPF_END 0xd0 endianness conversion - ======== ===== ========================== + BPF_END 0xd0 byte swap operations (see separate section below) + ======== ===== ================================================= BPF_ADD | BPF_X | BPF_ALU means:: @@ -118,6 +118,42 @@ BPF_XOR | BPF_K | BPF_ALU64 means:: src_reg = src_reg ^ imm32 +Byte swap instructions +---------------------- + +The byte swap instructions use an instruction class of ``BFP_ALU`` and a 4-bit +code field of ``BPF_END``. + +The byte swap instructions instructions operate on the destination register +only and do not use a separate source register or immediate value. + +The 1-bit source operand field in the opcode is used to to select what byte +order the operation convert from or to: + + ========= ===== ================================================= + source value description + ========= ===== ================================================= + BPF_TO_LE 0x00 convert between host byte order and little endian + BPF_TO_BE 0x08 convert between host byte order and big endian + ========= ===== ================================================= + +The imm field encodes the width of the swap operations. The following widths +are supported: 16, 32 and 64. + +Examples: + +``BPF_ALU | BPF_TO_LE | BPF_END`` with imm = 16 means:: + + dst_reg = htole16(dst_reg) + +``BPF_ALU | BPF_TO_BE | BPF_END`` with imm = 64 means:: + + dst_reg = htobe64(dst_reg) + +``BPF_FROM_LE`` and ``BPF_FROM_BE`` exist as aliases for ``BPF_TO_LE`` and +``BPF_TO_LE`` respetively. + + Jump instructions ----------------- -- cgit From 63d8c242b9a502f1517b3e8c45d2125649dd5d7b Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Mon, 31 Jan 2022 19:36:35 +0100 Subject: bpf, docs: Better document the regular load and store instructions Add a separate section and a little intro blurb for the regular load and store instructions. Signed-off-by: Christoph Hellwig Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20220131183638.3934982-3-hch@lst.de --- Documentation/bpf/instruction-set.rst | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst index 87f6ad62633a..03da88530172 100644 --- a/Documentation/bpf/instruction-set.rst +++ b/Documentation/bpf/instruction-set.rst @@ -215,23 +215,30 @@ The mode modifier is one of: BPF_IMM 0x00 used for 64-bit mov BPF_ABS 0x20 legacy BPF packet access BPF_IND 0x40 legacy BPF packet access - BPF_MEM 0x60 all normal load and store operations + BPF_MEM 0x60 regular load and store operations BPF_ATOMIC 0xc0 atomic operations ============= ===== ==================================== -BPF_MEM | | BPF_STX means:: + +Regular load and store operations +--------------------------------- + +The ``BPF_MEM`` mode modifier is used to encode regular load and store +instructions that transfer data between a register and memory. + +``BPF_MEM | | BPF_STX`` means:: *(size *) (dst_reg + off) = src_reg -BPF_MEM | | BPF_ST means:: +``BPF_MEM | | BPF_ST`` means:: *(size *) (dst_reg + off) = imm32 -BPF_MEM | | BPF_LDX means:: +``BPF_MEM | | BPF_LDX`` means:: dst_reg = *(size *) (src_reg + off) -Where size is one of: BPF_B or BPF_H or BPF_W or BPF_DW. +Where size is one of: ``BPF_B``, ``BPF_H``, ``BPF_W``, or ``BPF_DW``. Atomic operations ----------------- -- cgit From 15175336270a76695412aedf68f3eab746d84b4b Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Mon, 31 Jan 2022 19:36:36 +0100 Subject: bpf, docs: Better document the legacy packet access instruction Use consistent terminology and structured RST elements to better document these two oddball instructions. Signed-off-by: Christoph Hellwig Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20220131183638.3934982-4-hch@lst.de --- Documentation/bpf/instruction-set.rst | 54 +++++++++++++++++++++-------------- 1 file changed, 32 insertions(+), 22 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst index 03da88530172..94682e23cd2f 100644 --- a/Documentation/bpf/instruction-set.rst +++ b/Documentation/bpf/instruction-set.rst @@ -213,8 +213,8 @@ The mode modifier is one of: mode modifier value description ============= ===== ==================================== BPF_IMM 0x00 used for 64-bit mov - BPF_ABS 0x20 legacy BPF packet access - BPF_IND 0x40 legacy BPF packet access + BPF_ABS 0x20 legacy BPF packet access (absolute) + BPF_IND 0x40 legacy BPF packet access (indirect) BPF_MEM 0x60 regular load and store operations BPF_ATOMIC 0xc0 atomic operations ============= ===== ==================================== @@ -294,29 +294,39 @@ eBPF has one 16-byte instruction: ``BPF_LD | BPF_DW | BPF_IMM`` which consists of two consecutive ``struct bpf_insn`` 8-byte blocks and interpreted as single instruction that loads 64-bit immediate value into a dst_reg. -Packet access instructions --------------------------- +Legacy BPF Packet access instructions +------------------------------------- -eBPF has two non-generic instructions: (BPF_ABS | | BPF_LD) and -(BPF_IND | | BPF_LD) which are used to access packet data. +eBPF has special instructions for access to packet data that have been +carried over from classic BPF to retain the performance of legacy socket +filters running in the eBPF interpreter. -They had to be carried over from classic BPF to have strong performance of -socket filters running in eBPF interpreter. These instructions can only -be used when interpreter context is a pointer to ``struct sk_buff`` and -have seven implicit operands. Register R6 is an implicit input that must -contain pointer to sk_buff. Register R0 is an implicit output which contains -the data fetched from the packet. Registers R1-R5 are scratch registers -and must not be used to store the data across BPF_ABS | BPF_LD or -BPF_IND | BPF_LD instructions. +The instructions come in two forms: ``BPF_ABS | | BPF_LD`` and +``BPF_IND | | BPF_LD``. -These instructions have implicit program exit condition as well. When -eBPF program is trying to access the data beyond the packet boundary, -the interpreter will abort the execution of the program. JIT compilers -therefore must preserve this property. src_reg and imm32 fields are -explicit inputs to these instructions. +These instructions are used to access packet data and can only be used when +the program context is a pointer to networking packet. ``BPF_ABS`` +accesses packet data at an absolute offset specified by the immediate data +and ``BPF_IND`` access packet data at an offset that includes the value of +a register in addition to the immediate data. -For example, BPF_IND | BPF_W | BPF_LD means:: +These instructions have seven implicit operands: - R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32)) + * Register R6 is an implicit input that must contain pointer to a + struct sk_buff. + * Register R0 is an implicit output which contains the data fetched from + the packet. + * Registers R1-R5 are scratch registers that are clobbered after a call to + ``BPF_ABS | BPF_LD`` or ``BPF_IND`` | BPF_LD instructions. + +These instructions have an implicit program exit condition as well. When an +eBPF program is trying to access the data beyond the packet boundary, the +program execution will be aborted. + +``BPF_ABS | BPF_W | BPF_LD`` means:: -and R1 - R5 are clobbered. + R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + imm32)) + +``BPF_IND | BPF_W | BPF_LD`` means:: + + R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32)) -- cgit From 5ca15b8a939ff59f3e9f957ad4af5658c016cf7e Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Mon, 31 Jan 2022 19:36:37 +0100 Subject: bpf, docs: Better document the extended instruction format In addition to the normal 64-bit instruction encoding, eBPF also has a single instruction that uses a second 64-bit bits for a second immediate value. Instead of only documenting this format deep down in the document mention it in the instruction encoding section. Signed-off-by: Christoph Hellwig Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20220131183638.3934982-5-hch@lst.de --- Documentation/bpf/instruction-set.rst | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst index 94682e23cd2f..a8e9fced39ad 100644 --- a/Documentation/bpf/instruction-set.rst +++ b/Documentation/bpf/instruction-set.rst @@ -22,7 +22,13 @@ necessary across calls. Instruction encoding ==================== -eBPF uses 64-bit instructions with the following encoding: +eBPF has two instruction encodings: + + * the basic instruction encoding, which uses 64 bits to encode an instruction + * the wide instruction encoding, which appends a second 64-bit immediate value + (imm64) after the basic instruction for a total of 128 bits. + +The basic instruction encoding looks as follows: ============= ======= =============== ==================== ============ 32 bits (MSB) 16 bits 4 bits 4 bits 8 bits (LSB) @@ -212,7 +218,7 @@ The mode modifier is one of: ============= ===== ==================================== mode modifier value description ============= ===== ==================================== - BPF_IMM 0x00 used for 64-bit mov + BPF_IMM 0x00 64-bit immediate instructions BPF_ABS 0x20 legacy BPF packet access (absolute) BPF_IND 0x40 legacy BPF packet access (indirect) BPF_MEM 0x60 regular load and store operations @@ -287,12 +293,18 @@ You may encounter ``BPF_XADD`` - this is a legacy name for ``BPF_ATOMIC``, referring to the exclusive-add operation encoded when the immediate field is zero. -16-byte instructions --------------------- +64-bit immediate instructions +----------------------------- + +Instructions with the ``BPF_IMM`` mode modifier use the wide instruction +encoding for an extra imm64 value. + +There is currently only one such instruction. + +``BPF_LD | BPF_DW | BPF_IMM`` means:: + + dst_reg = imm64 -eBPF has one 16-byte instruction: ``BPF_LD | BPF_DW | BPF_IMM`` which consists -of two consecutive ``struct bpf_insn`` 8-byte blocks and interpreted as single -instruction that loads 64-bit immediate value into a dst_reg. Legacy BPF Packet access instructions ------------------------------------- -- cgit From 594d323485567d36674a8ff4f344d81a830de5ac Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Mon, 31 Jan 2022 19:36:38 +0100 Subject: bpf, docs: Better document the atomic instructions Use proper tables and RST markup to document the atomic instructions in a structured way. Signed-off-by: Christoph Hellwig Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20220131183638.3934982-6-hch@lst.de --- Documentation/bpf/instruction-set.rst | 76 ++++++++++++++++++++++------------- 1 file changed, 49 insertions(+), 27 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst index a8e9fced39ad..5300837ac2c9 100644 --- a/Documentation/bpf/instruction-set.rst +++ b/Documentation/bpf/instruction-set.rst @@ -249,39 +249,65 @@ Where size is one of: ``BPF_B``, ``BPF_H``, ``BPF_W``, or ``BPF_DW``. Atomic operations ----------------- -eBPF includes atomic operations, which use the immediate field for extra -encoding:: +Atomic operations are operations that operate on memory and can not be +interrupted or corrupted by other access to the same memory region +by other eBPF programs or means outside of this specification. - .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_W | BPF_STX: lock xadd *(u32 *)(dst_reg + off16) += src_reg - .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_DW | BPF_STX: lock xadd *(u64 *)(dst_reg + off16) += src_reg +All atomic operations supported by eBPF are encoded as store operations +that use the ``BPF_ATOMIC`` mode modifier as follows: -The basic atomic operations supported are:: + * ``BPF_ATOMIC | BPF_W | BPF_STX`` for 32-bit operations + * ``BPF_ATOMIC | BPF_DW | BPF_STX`` for 64-bit operations + * 8-bit and 16-bit wide atomic operations are not supported. - BPF_ADD - BPF_AND - BPF_OR - BPF_XOR +The imm field is used to encode the actual atomic operation. +Simple atomic operation use a subset of the values defined to encode +arithmetic operations in the imm field to encode the atomic operation: -Each having equivalent semantics with the ``BPF_ADD`` example, that is: the -memory location addresed by ``dst_reg + off`` is atomically modified, with -``src_reg`` as the other operand. If the ``BPF_FETCH`` flag is set in the -immediate, then these operations also overwrite ``src_reg`` with the -value that was in memory before it was modified. + ======== ===== =========== + imm value description + ======== ===== =========== + BPF_ADD 0x00 atomic add + BPF_OR 0x40 atomic or + BPF_AND 0x50 atomic and + BPF_XOR 0xa0 atomic xor + ======== ===== =========== -The more special operations are:: - BPF_XCHG +``BPF_ATOMIC | BPF_W | BPF_STX`` with imm = BPF_ADD means:: -This atomically exchanges ``src_reg`` with the value addressed by ``dst_reg + -off``. :: + *(u32 *)(dst_reg + off16) += src_reg - BPF_CMPXCHG +``BPF_ATOMIC | BPF_DW | BPF_STX`` with imm = BPF ADD means:: -This atomically compares the value addressed by ``dst_reg + off`` with -``R0``. If they match it is replaced with ``src_reg``. In either case, the -value that was there before is zero-extended and loaded back to ``R0``. + *(u64 *)(dst_reg + off16) += src_reg -Note that 1 and 2 byte atomic operations are not supported. +``BPF_XADD`` is a deprecated name for ``BPF_ATOMIC | BPF_ADD``. + +In addition to the simple atomic operations, there also is a modifier and +two complex atomic operations: + + =========== ================ =========================== + imm value description + =========== ================ =========================== + BPF_FETCH 0x01 modifier: return old value + BPF_XCHG 0xe0 | BPF_FETCH atomic exchange + BPF_CMPXCHG 0xf0 | BPF_FETCH atomic compare and exchange + =========== ================ =========================== + +The ``BPF_FETCH`` modifier is optional for simple atomic operations, and +always set for the complex atomic operations. If the ``BPF_FETCH`` flag +is set, then the operation also overwrites ``src_reg`` with the value that +was in memory before it was modified. + +The ``BPF_XCHG`` operation atomically exchanges ``src_reg`` with the value +addressed by ``dst_reg + off``. + +The ``BPF_CMPXCHG`` operation atomically compares the value addressed by +``dst_reg + off`` with ``R0``. If they match, the value addressed by +``dst_reg + off`` is replaced with ``src_reg``. In either case, the +value that was at ``dst_reg + off`` before the operation is zero-extended +and loaded back to ``R0``. Clang can generate atomic instructions by default when ``-mcpu=v3`` is enabled. If a lower version for ``-mcpu`` is set, the only atomic instruction @@ -289,10 +315,6 @@ Clang can generate is ``BPF_ADD`` *without* ``BPF_FETCH``. If you need to enable the atomics features, while keeping a lower ``-mcpu`` version, you can use ``-Xclang -target-feature -Xclang +alu32``. -You may encounter ``BPF_XADD`` - this is a legacy name for ``BPF_ATOMIC``, -referring to the exclusive-add operation encoded when the immediate field is -zero. - 64-bit immediate instructions ----------------------------- -- cgit From 4a960e8941bd59fe20f8f774de371f40f222a0c7 Mon Sep 17 00:00:00 2001 From: Ricardo Neri Date: Thu, 27 Jan 2022 11:34:48 -0800 Subject: x86/Documentation: Describe the Intel Hardware Feedback Interface Start a documentation file to describe the purpose and operation of Intel's Hardware Feedback Interface. Describe how this interface is used in Linux to relay performance and energy efficiency updates to userspace. Reviewed-by: Len Brown Suggested-by: Srinivas Pandruvada Signed-off-by: Ricardo Neri Signed-off-by: Rafael J. Wysocki --- Documentation/x86/index.rst | 1 + Documentation/x86/intel-hfi.rst | 72 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 73 insertions(+) create mode 100644 Documentation/x86/intel-hfi.rst (limited to 'Documentation') diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index f498f1d36cd3..982c8af853b9 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -21,6 +21,7 @@ x86-specific Documentation tlb mtrr pat + intel-hfi intel-iommu intel_txt amd-memory-encryption diff --git a/Documentation/x86/intel-hfi.rst b/Documentation/x86/intel-hfi.rst new file mode 100644 index 000000000000..49dea58ea4fb --- /dev/null +++ b/Documentation/x86/intel-hfi.rst @@ -0,0 +1,72 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================================ +Hardware-Feedback Interface for scheduling on Intel Hardware +============================================================ + +Overview +-------- + +Intel has described the Hardware Feedback Interface (HFI) in the Intel 64 and +IA-32 Architectures Software Developer's Manual (Intel SDM) Volume 3 Section +14.6 [1]_. + +The HFI gives the operating system a performance and energy efficiency +capability data for each CPU in the system. Linux can use the information from +the HFI to influence task placement decisions. + +The Hardware Feedback Interface +------------------------------- + +The Hardware Feedback Interface provides to the operating system information +about the performance and energy efficiency of each CPU in the system. Each +capability is given as a unit-less quantity in the range [0-255]. Higher values +indicate higher capability. Energy efficiency and performance are reported in +separate capabilities. Even though on some systems these two metrics may be +related, they are specified as independent capabilities in the Intel SDM. + +These capabilities may change at runtime as a result of changes in the +operating conditions of the system or the action of external factors. The rate +at which these capabilities are updated is specific to each processor model. On +some models, capabilities are set at boot time and never change. On others, +capabilities may change every tens of milliseconds. For instance, a remote +mechanism may be used to lower Thermal Design Power. Such change can be +reflected in the HFI. Likewise, if the system needs to be throttled due to +excessive heat, the HFI may reflect reduced performance on specific CPUs. + +The kernel or a userspace policy daemon can use these capabilities to modify +task placement decisions. For instance, if either the performance or energy +capabilities of a given logical processor becomes zero, it is an indication that +the hardware recommends to the operating system to not schedule any tasks on +that processor for performance or energy efficiency reasons, respectively. + +Implementation details for Linux +-------------------------------- + +The infrastructure to handle thermal event interrupts has two parts. In the +Local Vector Table of a CPU's local APIC, there exists a register for the +Thermal Monitor Register. This register controls how interrupts are delivered +to a CPU when the thermal monitor generates and interrupt. Further details +can be found in the Intel SDM Vol. 3 Section 10.5 [1]_. + +The thermal monitor may generate interrupts per CPU or per package. The HFI +generates package-level interrupts. This monitor is configured and initialized +via a set of machine-specific registers. Specifically, the HFI interrupt and +status are controlled via designated bits in the IA32_PACKAGE_THERM_INTERRUPT +and IA32_PACKAGE_THERM_STATUS registers, respectively. There exists one HFI +table per package. Further details can be found in the Intel SDM Vol. 3 +Section 14.9 [1]_. + +The hardware issues an HFI interrupt after updating the HFI table and is ready +for the operating system to consume it. CPUs receive such interrupt via the +thermal entry in the Local APIC's Local Vector Table. + +When servicing such interrupt, the HFI driver parses the updated table and +relays the update to userspace using the thermal notification framework. Given +that there may be many HFI updates every second, the updates relayed to +userspace are throttled at a rate of CONFIG_HZ jiffies. + +References +---------- + +.. [1] https://www.intel.com/sdm -- cgit From ac23d1a964600bb9c14b5048bdf4f18ae13226f4 Mon Sep 17 00:00:00 2001 From: "Matthew Wilcox (Oracle)" Date: Mon, 13 Dec 2021 23:03:54 -0500 Subject: XArray: Document the locking requirement for the xa_state It wasn't obvious to all readers that it's unsafe to reuse an xa_state after dropping the xas_lock() or the rcu_read_lock(). Reported-by: Charan Teja Kalla Signed-off-by: Matthew Wilcox (Oracle) --- Documentation/core-api/xarray.rst | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/xarray.rst b/Documentation/core-api/xarray.rst index a137a0e6d068..77e0ece2b1d6 100644 --- a/Documentation/core-api/xarray.rst +++ b/Documentation/core-api/xarray.rst @@ -315,11 +315,15 @@ indeed the normal API is implemented in terms of the advanced API. The advanced API is only available to modules with a GPL-compatible license. The advanced API is based around the xa_state. This is an opaque data -structure which you declare on the stack using the XA_STATE() -macro. This macro initialises the xa_state ready to start walking -around the XArray. It is used as a cursor to maintain the position -in the XArray and let you compose various operations together without -having to restart from the top every time. +structure which you declare on the stack using the XA_STATE() macro. +This macro initialises the xa_state ready to start walking around the +XArray. It is used as a cursor to maintain the position in the XArray +and let you compose various operations together without having to restart +from the top every time. The contents of the xa_state are protected by +the rcu_read_lock() or the xas_lock(). If you need to drop whichever of +those locks is protecting your state and tree, you must call xas_pause() +so that future calls do not rely on the parts of the state which were +left unprotected. The xa_state is also used to store errors. You can call xas_error() to retrieve the error. All operations check whether -- cgit From dd72781b48a52de3e1fa0a3ab9be4020521a1bfd Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Thu, 27 Jan 2022 18:55:10 -0800 Subject: dt-bindings: remoteproc: qcom: pas: Add SM8450 PAS compatibles The Qualcomm SM8450 has the usual audio, compute, sensor and modem remoteprocs, add compatibles to the documentation for these. Signed-off-by: Bjorn Andersson Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20220128025513.97188-11-bjorn.andersson@linaro.org --- .../devicetree/bindings/remoteproc/qcom,adsp.yaml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index c635c181d2c2..64c182428e94 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -47,6 +47,10 @@ properties: - qcom,sm8350-cdsp-pas - qcom,sm8350-slpi-pas - qcom,sm8350-mpss-pas + - qcom,sm8450-adsp-pas + - qcom,sm8450-cdsp-pas + - qcom,sm8450-mpss-pas + - qcom,sm8450-slpi-pas reg: maxItems: 1 @@ -175,6 +179,10 @@ allOf: - qcom,sm8350-cdsp-pas - qcom,sm8350-slpi-pas - qcom,sm8350-mpss-pas + - qcom,sm8450-adsp-pas + - qcom,sm8450-cdsp-pas + - qcom,sm8450-slpi-pas + - qcom,sm8450-mpss-pas then: properties: clocks: @@ -283,6 +291,9 @@ allOf: - qcom,sm8350-adsp-pas - qcom,sm8350-cdsp-pas - qcom,sm8350-slpi-pas + - qcom,sm8450-adsp-pas + - qcom,sm8450-cdsp-pas + - qcom,sm8450-slpi-pas then: properties: interrupts: @@ -312,6 +323,7 @@ allOf: - qcom,sm6350-mpss-pas - qcom,sm8150-mpss-pas - qcom,sm8350-mpss-pas + - qcom,sm8450-mpss-pas then: properties: interrupts: @@ -434,6 +446,7 @@ allOf: - qcom,sm6350-mpss-pas - qcom,sm8150-mpss-pas - qcom,sm8350-mpss-pas + - qcom,sm8450-mpss-pas then: properties: power-domains: @@ -458,6 +471,8 @@ allOf: - qcom,sm8250-slpi-pas - qcom,sm8350-adsp-pas - qcom,sm8350-slpi-pas + - qcom,sm8450-adsp-pas + - qcom,sm8450-slpi-pas then: properties: power-domains: @@ -475,6 +490,7 @@ allOf: contains: enum: - qcom,sm8350-cdsp-pas + - qcom,sm8450-cdsp-pas then: properties: power-domains: -- cgit From 0fc58931207445312987028936121b4eaf075d09 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 2 Feb 2022 16:13:08 +0100 Subject: dt-bindings: serial: samsung_uart: Document Exynos5433 compatible Document the Exynos5433 UART compatible, supported since commit 31ec77aca72e ("serial: samsung: Add the support for Exynos5433 SoC"). Signed-off-by: Krzysztof Kozlowski Reviewed-by: Alim Akhtar Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220202151310.285561-2-krzysztof.kozlowski@canonical.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml index 2940afb874b3..6aceba4a5f79 100644 --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml @@ -26,6 +26,7 @@ properties: - samsung,s3c6400-uart - samsung,s5pv210-uart - samsung,exynos4210-uart + - samsung,exynos5433-uart - samsung,exynos850-uart reg: @@ -111,6 +112,7 @@ allOf: enum: - apple,s5l-uart - samsung,exynos4210-uart + - samsung,exynos5433-uart then: properties: clocks: -- cgit From abfc426d1b2fb2176df59851a64223b58ddae7e7 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Wed, 2 Feb 2022 17:01:09 +0100 Subject: block: pass a block_device to bio_clone_fast Pass a block_device to bio_clone_fast and __bio_clone_fast and give the functions more suitable names. Signed-off-by: Christoph Hellwig Reviewed-by: Mike Snitzer Link: https://lore.kernel.org/r/20220202160109.108149-14-hch@lst.de Signed-off-by: Jens Axboe --- Documentation/block/biodoc.rst | 5 ----- 1 file changed, 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/biodoc.rst b/Documentation/block/biodoc.rst index 2098477851a4..4fbc367e62f9 100644 --- a/Documentation/block/biodoc.rst +++ b/Documentation/block/biodoc.rst @@ -663,11 +663,6 @@ to i/o submission, if the bio fields are likely to be accessed after the i/o is issued (since the bio may otherwise get freed in case i/o completion happens in the meantime). -The bio_clone_fast() routine may be used to duplicate a bio, where the clone -shares the bio_vec_list with the original bio (i.e. both point to the -same bio_vec_list). This would typically be used for splitting i/o requests -in lvm or md. - 3.2 Generic bio helper Routines ------------------------------- -- cgit From 84564481bc4520c47e7fe9c594c0523d81e6a97a Mon Sep 17 00:00:00 2001 From: Aswath Govindraju Date: Fri, 7 Jan 2022 08:44:25 +0100 Subject: mux: Add support for reading mux state from consumer DT node In some cases, we might need to provide the state of the mux to be set for the operation of a given peripheral. Therefore, pass this information using mux-states property. Link: https://lore.kernel.org/lkml/20211123081222.27979-1-a-govindraju@ti.com Signed-off-by: Aswath Govindraju Signed-off-by: Peter Rosin (minor edits) Link: https://lore.kernel.org/r/aac25be8-9515-a980-f7cb-709938c84822@axentia.se Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/driver-model/devres.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index 148e19381b79..5018403fe82f 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -368,6 +368,7 @@ MUX devm_mux_chip_alloc() devm_mux_chip_register() devm_mux_control_get() + devm_mux_state_get() NET devm_alloc_etherdev() -- cgit From 39bd2b6a3783b8990d97494ec4c8698ba5bb6740 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 18 Jan 2022 19:50:38 -0600 Subject: dt-bindings: Improve phandle-array schemas The 'phandle-array' type is a bit ambiguous. It can be either just an array of phandles or an array of phandles plus args. Many schemas for phandle-array properties aren't clear in the schema which case applies though the description usually describes it. The array of phandles case boils down to needing: items: maxItems: 1 The phandle plus args cases should typically take this form: items: - items: - description: A phandle - description: 1st arg cell - description: 2nd arg cell With this change, some examples need updating so that the bracketing of property values matches the schema. Signed-off-by: Rob Herring Acked-by: Viresh Kumar Acked-by: Vinod Koul Acked-by: Ulf Hansson Acked-by: Georgi Djakov Reviewed-by: Geert Uytterhoeven Acked-by: Mark Brown Acked-by: Krzysztof Kozlowski Acked-by: Stephen Boyd Acked-by: Greg Kroah-Hartman Acked-by: Marc Kleine-Budde Link: https://lore.kernel.org/r/20220119015038.2433585-1-robh@kernel.org --- Documentation/devicetree/bindings/arm/cpus.yaml | 2 + .../devicetree/bindings/arm/idle-states.yaml | 80 +++++++++++----------- Documentation/devicetree/bindings/arm/pmu.yaml | 2 + .../devicetree/bindings/ata/sata_highbank.yaml | 3 + .../bindings/bus/allwinner,sun50i-a64-de2.yaml | 5 +- .../bindings/crypto/intel,ixp4xx-crypto.yaml | 15 +++- .../allwinner,sun4i-a10-display-engine.yaml | 2 + .../bindings/display/mediatek/mediatek,hdmi.yaml | 5 +- .../devicetree/bindings/display/msm/gpu.yaml | 2 + .../devicetree/bindings/display/renesas,du.yaml | 10 ++- .../bindings/display/rockchip/rockchip-drm.yaml | 2 + .../display/sprd/sprd,display-subsystem.yaml | 2 + .../bindings/display/ti/ti,am65x-dss.yaml | 3 +- .../devicetree/bindings/dma/dma-router.yaml | 2 + .../devicetree/bindings/dma/st,stm32-dmamux.yaml | 2 +- .../bindings/dvfs/performance-domain.yaml | 1 - .../devicetree/bindings/firmware/arm,scmi.yaml | 2 +- .../devicetree/bindings/firmware/arm,scpi.yaml | 2 +- .../bindings/interconnect/qcom,rpmh.yaml | 2 + .../bindings/interrupt-controller/arm,gic-v3.yaml | 6 +- .../bindings/interrupt-controller/ti,sci-inta.yaml | 2 + .../devicetree/bindings/iommu/mediatek,iommu.yaml | 6 +- .../bindings/iommu/renesas,ipmmu-vmsa.yaml | 6 ++ .../bindings/leds/backlight/led-backlight.yaml | 2 + .../media/allwinner,sun4i-a10-video-engine.yaml | 4 ++ .../bindings/media/nxp,imx8mq-mipi-csi2.yaml | 10 +-- .../devicetree/bindings/media/ti,cal.yaml | 4 ++ .../memory-controllers/mediatek,smi-larb.yaml | 2 +- .../memory-controllers/samsung,exynos5422-dmc.yaml | 2 + .../bindings/net/allwinner,sun4i-a10-emac.yaml | 4 ++ .../devicetree/bindings/net/can/bosch,c_can.yaml | 8 +-- .../devicetree/bindings/net/can/fsl,flexcan.yaml | 12 ++-- .../devicetree/bindings/net/dsa/dsa-port.yaml | 2 + Documentation/devicetree/bindings/net/fsl,fec.yaml | 8 ++- .../bindings/net/intel,ixp4xx-ethernet.yaml | 15 +++- .../devicetree/bindings/net/intel,ixp4xx-hss.yaml | 33 +++++++-- .../devicetree/bindings/net/nxp,dwmac-imx.yaml | 4 ++ .../bindings/net/socionext,uniphier-ave4.yaml | 4 ++ .../devicetree/bindings/net/stm32-dwmac.yaml | 4 ++ .../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 5 ++ .../bindings/net/wireless/mediatek,mt76.yaml | 4 ++ .../devicetree/bindings/opp/opp-v2-base.yaml | 2 + .../devicetree/bindings/perf/arm,dsu-pmu.yaml | 2 + .../devicetree/bindings/phy/intel,combo-phy.yaml | 8 +++ .../devicetree/bindings/phy/ti,omap-usb2.yaml | 4 ++ .../bindings/pinctrl/aspeed,ast2500-pinctrl.yaml | 2 + .../bindings/pinctrl/canaan,k210-fpioa.yaml | 4 ++ .../bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml | 2 + .../bindings/pinctrl/st,stm32-pinctrl.yaml | 10 +-- .../devicetree/bindings/power/power-domain.yaml | 4 ++ .../devicetree/bindings/power/renesas,apmu.yaml | 2 + .../bindings/power/rockchip,power-controller.yaml | 2 + .../bindings/power/supply/cw2015_battery.yaml | 6 +- .../bindings/power/supply/power-supply.yaml | 2 + .../devicetree/bindings/regulator/regulator.yaml | 2 + .../bindings/regulator/st,stm32-booster.yaml | 2 +- .../devicetree/bindings/remoteproc/qcom,adsp.yaml | 6 ++ .../bindings/remoteproc/st,stm32-rproc.yaml | 33 ++++++--- .../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 2 + .../bindings/remoteproc/ti,k3-r5f-rproc.yaml | 2 + .../bindings/remoteproc/ti,omap-remoteproc.yaml | 19 +++-- .../bindings/soc/samsung/exynos-usi.yaml | 4 ++ .../bindings/sound/samsung,aries-wm8994.yaml | 2 + .../devicetree/bindings/sound/st,stm32-sai.yaml | 8 ++- .../bindings/thermal/thermal-cooling-devices.yaml | 6 +- .../devicetree/bindings/thermal/thermal-idle.yaml | 8 +-- .../devicetree/bindings/usb/nvidia,tegra-xudc.yaml | 2 +- 67 files changed, 318 insertions(+), 119 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index 0dcebc48ea22..916a5aebefff 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -243,6 +243,8 @@ properties: cpu-idle-states: $ref: '/schemas/types.yaml#/definitions/phandle-array' + items: + maxItems: 1 description: | List of phandles to idle state nodes supported by this cpu (see ./idle-states.yaml). diff --git a/Documentation/devicetree/bindings/arm/idle-states.yaml b/Documentation/devicetree/bindings/arm/idle-states.yaml index 52bce5dbb11f..4d381fa1ee57 100644 --- a/Documentation/devicetree/bindings/arm/idle-states.yaml +++ b/Documentation/devicetree/bindings/arm/idle-states.yaml @@ -337,8 +337,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x0>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@1 { @@ -346,8 +346,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x1>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@100 { @@ -355,8 +355,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x100>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@101 { @@ -364,8 +364,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x101>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@10000 { @@ -373,8 +373,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x10000>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@10001 { @@ -382,8 +382,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x10001>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@10100 { @@ -391,8 +391,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x10100>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@10101 { @@ -400,8 +400,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x10101>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@100000000 { @@ -409,8 +409,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x0>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; cpu@100000001 { @@ -418,8 +418,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x1>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; cpu@100000100 { @@ -427,8 +427,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x100>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; cpu@100000101 { @@ -436,8 +436,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x101>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; cpu@100010000 { @@ -445,8 +445,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x10000>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; cpu@100010001 { @@ -454,8 +454,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x10001>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; cpu@100010100 { @@ -463,8 +463,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x10100>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; cpu@100010101 { @@ -472,8 +472,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x10101>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; idle-states { @@ -567,56 +567,56 @@ examples: device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x0>; - cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; + cpu-idle-states = <&cpu_sleep_0_0>, <&cluster_sleep_0>; }; cpu@1 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x1>; - cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; + cpu-idle-states = <&cpu_sleep_0_0>, <&cluster_sleep_0>; }; cpu@2 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x2>; - cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; + cpu-idle-states = <&cpu_sleep_0_0>, <&cluster_sleep_0>; }; cpu@3 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x3>; - cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; + cpu-idle-states = <&cpu_sleep_0_0>, <&cluster_sleep_0>; }; cpu@100 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x100>; - cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; + cpu-idle-states = <&cpu_sleep_1_0>, <&cluster_sleep_1>; }; cpu@101 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x101>; - cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; + cpu-idle-states = <&cpu_sleep_1_0>, <&cluster_sleep_1>; }; cpu@102 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x102>; - cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; + cpu-idle-states = <&cpu_sleep_1_0>, <&cluster_sleep_1>; }; cpu@103 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x103>; - cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; + cpu-idle-states = <&cpu_sleep_1_0>, <&cluster_sleep_1>; }; idle-states { diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml b/Documentation/devicetree/bindings/arm/pmu.yaml index 981bac451698..2e2308d73408 100644 --- a/Documentation/devicetree/bindings/arm/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/pmu.yaml @@ -66,6 +66,8 @@ properties: interrupt-affinity: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: When using SPIs, specifies a list of phandles to CPU nodes corresponding directly to the affinity of diff --git a/Documentation/devicetree/bindings/ata/sata_highbank.yaml b/Documentation/devicetree/bindings/ata/sata_highbank.yaml index ce75d77e9289..49679b58041c 100644 --- a/Documentation/devicetree/bindings/ata/sata_highbank.yaml +++ b/Documentation/devicetree/bindings/ata/sata_highbank.yaml @@ -51,6 +51,9 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 8 + items: + minItems: 2 + maxItems: 2 calxeda,tx-atten: description: | diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml index 863a287ebc7e..ad313ccaaaef 100644 --- a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml +++ b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml @@ -35,7 +35,10 @@ properties: The SRAM that needs to be claimed to access the display engine bus. $ref: /schemas/types.yaml#/definitions/phandle-array - maxItems: 1 + items: + - items: + - description: phandle to SRAM + - description: register value for device ranges: true diff --git a/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml b/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml index 9c53c27bd20a..e0fe63957888 100644 --- a/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml +++ b/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml @@ -22,19 +22,28 @@ properties: intel,npe-handle: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the NPE this crypto engine + - description: the NPE instance number description: phandle to the NPE this crypto engine is using, the cell describing the NPE instance to be used. queue-rx: $ref: /schemas/types.yaml#/definitions/phandle-array - maxItems: 1 + items: + - items: + - description: phandle to the RX queue on the NPE + - description: the queue instance number description: phandle to the RX queue on the NPE, the cell describing the queue instance to be used. queue-txready: $ref: /schemas/types.yaml#/definitions/phandle-array - maxItems: 1 + items: + - items: + - description: phandle to the TX READY queue on the NPE + - description: the queue instance number description: phandle to the TX READY queue on the NPE, the cell describing the queue instance to be used. diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml index e77523b02fad..d4412aea7b73 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml @@ -69,6 +69,8 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 2 + items: + maxItems: 1 description: | Available display engine frontends (DE 1.0) or mixers (DE 2.0/3.0) available. diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml index 111967efa999..bdaf0b51e68c 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml @@ -51,7 +51,10 @@ properties: mediatek,syscon-hdmi: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to system configuration registers + - description: register offset in the system configuration registers description: | phandle link and register offset to the system configuration registers. diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml index 99a1ba3ada56..3397bc31d087 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml @@ -64,6 +64,8 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 4 + items: + maxItems: 1 description: | phandles to one or more reserved on-chip SRAM regions. phandle to the On Chip Memory (OCMEM) that's present on some a3xx and diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index 13efea574584..56cedcd6d576 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -76,17 +76,21 @@ properties: renesas,cmms: $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + maxItems: 1 description: A list of phandles to the CMM instances present in the SoC, one for each available DU channel. renesas,vsps: $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + items: + - description: phandle to VSP instance that serves the DU channel + - description: Channel index identifying the LIF instance in that VSP description: A list of phandle and channel index tuples to the VSPs that handle the - memory interfaces for the DU channels. The phandle identifies the VSP - instance that serves the DU channel, and the channel index identifies - the LIF instance in that VSP. + memory interfaces for the DU channels. required: - compatible diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml index 7204da5eb4c5..a8d18a37cb23 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml @@ -21,6 +21,8 @@ properties: ports: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: | Should contain a list of phandles pointing to display interface port of vop devices. vop definitions as defined in diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml index 3d107e9434be..d0a5592bd89d 100644 --- a/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml +++ b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml @@ -45,6 +45,8 @@ properties: ports: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: Should contain a list of phandles pointing to display interface port of DPU devices. diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index 781c1868b0b8..5c7d2cbc4aac 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -88,8 +88,7 @@ properties: The DSS DPI output port node from video port 2 ti,am65x-oldi-io-ctrl: - $ref: "/schemas/types.yaml#/definitions/phandle-array" - maxItems: 1 + $ref: "/schemas/types.yaml#/definitions/phandle" description: phandle to syscon device node mapping OLDI IO_CTRL registers. The mapped range should point to OLDI_DAT0_IO_CTRL, map it and diff --git a/Documentation/devicetree/bindings/dma/dma-router.yaml b/Documentation/devicetree/bindings/dma/dma-router.yaml index e72748496fd9..4b817f5dc30e 100644 --- a/Documentation/devicetree/bindings/dma/dma-router.yaml +++ b/Documentation/devicetree/bindings/dma/dma-router.yaml @@ -24,6 +24,8 @@ properties: dma-masters: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: Array of phandles to the DMA controllers the router can direct the signal to. diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml index f751796531c9..7b1833d6caa2 100644 --- a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml +++ b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml @@ -46,7 +46,7 @@ examples: #dma-cells = <3>; dma-requests = <128>; dma-channels = <16>; - dma-masters = <&dma1 &dma2>; + dma-masters = <&dma1>, <&dma2>; clocks = <&timer_clk>; }; diff --git a/Documentation/devicetree/bindings/dvfs/performance-domain.yaml b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml index c8b91207f34d..7959d40ded5a 100644 --- a/Documentation/devicetree/bindings/dvfs/performance-domain.yaml +++ b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml @@ -43,7 +43,6 @@ properties: performance-domains: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 description: A phandle and performance domain specifier as defined by bindings of the performance controller/provider specified by phandle. diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index 5c4c6782e052..ea2f6bc9a1d6 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -330,7 +330,7 @@ examples: firmware { scmi { compatible = "arm,scmi-smc"; - shmem = <&cpu_scp_lpri0 &cpu_scp_lpri1>; + shmem = <&cpu_scp_lpri0>, <&cpu_scp_lpri1>; arm,smc-id = <0xc3000001>; #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml index 23b346bd1252..800417a76bda 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml @@ -236,7 +236,7 @@ examples: scpi { compatible = "amlogic,meson-gxbb-scpi", "arm,scpi-pre-1.0"; mboxes = <&mailbox 1 &mailbox 2>; - shmem = <&cpu_scp_lpri &cpu_scp_hpri>; + shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>; scpi_sensors1: sensors { compatible = "amlogic,meson-gxbb-scpi-sensors", "arm,scpi-sensors"; diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index cbb24f9bb609..5a911be0c2ea 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -121,6 +121,8 @@ properties: qcom,bcm-voters: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: | List of phandles to qcom,bcm-voter nodes that are required by this interconnect to send RPMh commands. diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml index cfb3ec27bd2b..b7197f78e158 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml @@ -138,6 +138,8 @@ properties: properties: affinity: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: Should be a list of phandles to CPU nodes (as described in Documentation/devicetree/bindings/arm/cpus.yaml). @@ -273,11 +275,11 @@ examples: ppi-partitions { part0: interrupt-partition-0 { - affinity = <&cpu0 &cpu2>; + affinity = <&cpu0>, <&cpu2>; }; part1: interrupt-partition-1 { - affinity = <&cpu1 &cpu3>; + affinity = <&cpu1>, <&cpu3>; }; }; }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml index 3d89668573e8..88c46e61732e 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml @@ -77,6 +77,8 @@ properties: ti,unmapped-event-sources: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: Array of phandles to DMA controllers where the unmapped events originate. diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index 0f26fe14c8e2..97e8c471a5e8 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -101,6 +101,8 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 32 + items: + maxItems: 1 description: | List of phandle to the local arbiters in the current Socs. Refer to bindings/memory-controllers/mediatek,smi-larb.yaml. It must sort @@ -167,8 +169,8 @@ examples: interrupts = ; clocks = <&infracfg CLK_INFRA_M4U>; clock-names = "bclk"; - mediatek,larbs = <&larb0 &larb1 &larb2 - &larb3 &larb4 &larb5>; + mediatek,larbs = <&larb0>, <&larb1>, <&larb2>, + <&larb3>, <&larb4>, <&larb5>; #iommu-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml index ce0c715205c6..c18fe4825508 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml @@ -66,6 +66,12 @@ properties: renesas,ipmmu-main: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to main IPMMU + - description: the interrupt bit number associated with the particular + cache IPMMU device. The interrupt bit number needs to match the main + IPMMU IMSSTR register. Only used by cache IPMMU instances. description: Reference to the main IPMMU phandle plus 1 cell. The cell is the interrupt bit number associated with the particular cache IPMMU diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml index 625082bf3892..f5822f4ea667 100644 --- a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml @@ -23,6 +23,8 @@ properties: leds: description: A list of LED nodes $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 brightness-levels: description: diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml index c3de96d10396..ee7fc3515d89 100644 --- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml +++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml @@ -48,6 +48,10 @@ properties: allwinner,sram: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to SRAM + - description: register value for device description: Phandle to the device SRAM iommus: diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml index 1b3e1c4b99ed..2a14e3b0e004 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml @@ -58,11 +58,11 @@ properties: req_gpr is the gpr register offset of RX_ENABLE for the mipi phy. $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - - description: The 'gpr' is the phandle to general purpose register node. - - description: The 'req_gpr' is the gpr register offset containing - CSI2_1_RX_ENABLE or CSI2_2_RX_ENABLE respectively. - maximum: 0xff + - items: + - description: The 'gpr' is the phandle to general purpose register node. + - description: The 'req_gpr' is the gpr register offset containing + CSI2_1_RX_ENABLE or CSI2_2_RX_ENABLE respectively. + maximum: 0xff interconnects: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/ti,cal.yaml b/Documentation/devicetree/bindings/media/ti,cal.yaml index 66c5d392fa75..7e078424ca4d 100644 --- a/Documentation/devicetree/bindings/media/ti,cal.yaml +++ b/Documentation/devicetree/bindings/media/ti,cal.yaml @@ -48,6 +48,10 @@ properties: ti,camerrx-control: $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + - items: + - description: phandle to device control module + - description: offset to the control_camerarx_core register description: phandle to the device control module and offset to the control_camerarx_core register diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index eaeff1ada7f8..822ade9e9bab 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -52,7 +52,7 @@ properties: maxItems: 1 mediatek,smi: - $ref: /schemas/types.yaml#/definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle description: a phandle to the smi_common node. mediatek,larb-id: diff --git a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml index fe8639dcffab..895c3b5c9aaa 100644 --- a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml @@ -45,6 +45,8 @@ properties: $ref: '/schemas/types.yaml#/definitions/phandle-array' minItems: 1 maxItems: 16 + items: + maxItems: 1 description: phandles of the PPMU events used by the controller. device-handle: diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml index 8d8560a67abf..098b2bf7d976 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml +++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml @@ -29,6 +29,10 @@ properties: allwinner,sram: description: Phandle to the device SRAM $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to SRAM + - description: register value for device required: - compatible diff --git a/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml index 2cd145a642f1..8bad328b184d 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml @@ -56,10 +56,10 @@ properties: offset). $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - - description: The phandle to the system control region. - - description: The register offset. - - description: The CAN instance number. + - items: + - description: The phandle to the system control region. + - description: The register offset. + - description: The CAN instance number. resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml index 3f0ee17c1461..e52db841bb8c 100644 --- a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml +++ b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml @@ -84,12 +84,12 @@ properties: req_bit is the bit offset of CAN stop request. $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - - description: The 'gpr' is the phandle to general purpose register node. - - description: The 'req_gpr' is the gpr register offset of CAN stop request. - maximum: 0xff - - description: The 'req_bit' is the bit offset of CAN stop request. - maximum: 0x1f + - items: + - description: The 'gpr' is the phandle to general purpose register node. + - description: The 'req_gpr' is the gpr register offset of CAN stop request. + maximum: 0xff + - description: The 'req_bit' is the bit offset of CAN stop request. + maximum: 0x1f fsl,clk-source: description: | diff --git a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml index 702df848a71d..c504feeec6db 100644 --- a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml +++ b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml @@ -34,6 +34,8 @@ properties: full routing information must be given, not just the one hop routes to neighbouring switches $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 ethernet: description: diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml index fd8371e31867..daa2f79a294f 100644 --- a/Documentation/devicetree/bindings/net/fsl,fec.yaml +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml @@ -158,11 +158,13 @@ properties: fsl,stop-mode: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to general purpose register node + - description: the gpr register offset for ENET stop request + - description: the gpr bit offset for ENET stop request description: Register bits of stop mode control, the format is <&gpr req_gpr req_bit>. - gpr is the phandle to general purpose register node. - req_gpr is the gpr register offset for ENET stop request. - req_bit is the gpr bit offset for ENET stop request. mdio: $ref: mdio.yaml# diff --git a/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml b/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml index 67eaf02dda80..4e1b79818aff 100644 --- a/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml +++ b/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml @@ -29,12 +29,18 @@ properties: queue-rx: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the RX queue node + - description: RX queue instance to use description: phandle to the RX queue on the NPE queue-txready: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the TX READY queue node + - description: TX READY queue instance to use description: phandle to the TX READY queue on the NPE phy-mode: true @@ -43,7 +49,10 @@ properties: intel,npe-handle: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the NPE this ethernet instance is using + - description: the NPE instance to use description: phandle to the NPE this ethernet instance is using and the instance to use in the second cell diff --git a/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml b/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml index 4dcd53c3e0b4..e6329febb60c 100644 --- a/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml +++ b/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml @@ -25,39 +25,62 @@ properties: intel,npe-handle: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + items: + - description: phandle to the NPE this HSS instance is using + - description: the NPE instance number description: phandle to the NPE this HSS instance is using and the instance to use in the second cell intel,queue-chl-rxtrig: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the RX trigger queue on the NPE + - description: the queue instance number description: phandle to the RX trigger queue on the NPE intel,queue-chl-txready: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the TX ready queue on the NPE + - description: the queue instance number description: phandle to the TX ready queue on the NPE intel,queue-pkt-rx: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the RX queue on the NPE + - description: the queue instance number description: phandle to the packet RX queue on the NPE intel,queue-pkt-tx: $ref: '/schemas/types.yaml#/definitions/phandle-array' maxItems: 4 + items: + items: + - description: phandle to the TX queue on the NPE + - description: the queue instance number description: phandle to the packet TX0, TX1, TX2 and TX3 queues on the NPE intel,queue-pkt-rxfree: $ref: '/schemas/types.yaml#/definitions/phandle-array' maxItems: 4 + items: + items: + - description: phandle to the RXFREE queue on the NPE + - description: the queue instance number description: phandle to the packet RXFREE0, RXFREE1, RXFREE2 and RXFREE3 queues on the NPE intel,queue-pkt-txdone: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the TXDONE queue on the NPE + - description: the queue instance number description: phandle to the packet TXDONE queue on the NPE cts-gpios: diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml index ee4afe361fac..011363166789 100644 --- a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml +++ b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml @@ -54,6 +54,10 @@ properties: intf_mode: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to the GPR syscon + - description: the offset of the GPR register description: Should be phandle/offset pair. The phandle to the syscon node which encompases the GPR register, and the offset of the GPR register. diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml index aad5a9f3f962..e602761f7b14 100644 --- a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml @@ -66,6 +66,10 @@ properties: socionext,syscon-phy-mode: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to syscon that configures phy mode + - description: ID of MAC instance description: A phandle to syscon with one argument that configures phy mode. The argument is the ID of MAC instance. diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml index 3d8a3b763ae6..5c93167b3b41 100644 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml @@ -74,6 +74,10 @@ properties: st,syscon: $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + - items: + - description: phandle to the syscon node which encompases the glue register + - description: offset of the control register description: Should be phandle/offset pair. The phandle to the syscon node which encompases the glue register, and the offset of the control register diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml index 4b97a0f1175b..b8281d8be940 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml @@ -136,6 +136,11 @@ properties: ti,syscon-efuse: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: Phandle to the system control device node which + provides access to efuse + - description: offset to efuse registers??? description: Phandle to the system control device node which provides access to efuse IO range with MAC addresses diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml index 269cd63fb544..42e1f4dddca8 100644 --- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml @@ -54,6 +54,10 @@ properties: mediatek,mtd-eeprom: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to MTD partition + - description: offset containing EEPROM data description: Phandle to a MTD partition + offset containing EEPROM data diff --git a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml index 15a76bcd6d42..da0f09eedc0c 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml @@ -177,6 +177,8 @@ patternProperties: for the functioning of the current device at the current OPP (where this property is present). $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 patternProperties: '^opp-microvolt-': diff --git a/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml b/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml index aef63a542f34..c87821be158b 100644 --- a/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml +++ b/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml @@ -35,6 +35,8 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 12 + items: + maxItems: 1 description: List of phandles for the CPUs connected to this DSU instance. required: diff --git a/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml b/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml index 347d0cdfb80d..5d54b0a0e873 100644 --- a/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml +++ b/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml @@ -47,10 +47,18 @@ properties: intel,syscfg: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to Chip configuration registers + - description: ComboPhy instance id description: Chip configuration registers handle and ComboPhy instance id intel,hsio: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to HSIO registers + - description: ComboPhy instance id description: HSIO registers handle and ComboPhy instance id on NOC intel,aggregation: diff --git a/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml b/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml index cbbf5e8b1197..51c8a36e61f0 100644 --- a/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml +++ b/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml @@ -45,6 +45,10 @@ properties: syscon-phy-power: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to the system control module + - description: register offset to power on/off the PHY description: phandle/offset pair. Phandle to the system control module and register offset to power on/off the PHY. diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml index d316cc082107..acd60c85b4cc 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml @@ -29,6 +29,8 @@ properties: aspeed,external-nodes: minItems: 2 maxItems: 2 + items: + maxItems: 1 $ref: /schemas/types.yaml#/definitions/phandle-array description: | A cell of phandles to external controller nodes: diff --git a/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml b/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml index a44691d9c57d..53e963e090f2 100644 --- a/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml +++ b/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml @@ -39,6 +39,10 @@ properties: canaan,k210-sysctl-power: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle of the K210 system controller node + - description: offset of its power domain control register description: | phandle of the K210 system controller node and offset of its power domain control register. diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml index 6953c958ff7c..161088a8be33 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml @@ -44,6 +44,8 @@ properties: mediatek,pctl-regmap: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 minItems: 1 maxItems: 2 description: | diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml index 83a18d0331b1..335ffc1353b5 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml @@ -41,11 +41,13 @@ properties: maxItems: 1 st,syscfg: - description: Should be phandle/offset/mask - - Phandle to the syscon node which includes IRQ mux selection. - - The offset of the IRQ mux selection register. - - The field mask of IRQ mux, needed if different of 0xf. + description: Phandle+args to the syscon node which includes IRQ mux selection. $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + - items: + - description: syscon node which includes IRQ mux selection + - description: The offset of the IRQ mux selection register + - description: The field mask of IRQ mux, needed if different of 0xf st,package: description: diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml index 3143ed9a3313..889091b9814f 100644 --- a/Documentation/devicetree/bindings/power/power-domain.yaml +++ b/Documentation/devicetree/bindings/power/power-domain.yaml @@ -29,6 +29,8 @@ properties: domain-idle-states: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: | Phandles of idle states that defines the available states for the power-domain provider. The idle state definitions are compatible with the @@ -42,6 +44,8 @@ properties: operating-points-v2: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: Phandles to the OPP tables of power domains provided by a power domain provider. If the provider provides a single power domain only or all diff --git a/Documentation/devicetree/bindings/power/renesas,apmu.yaml b/Documentation/devicetree/bindings/power/renesas,apmu.yaml index 391897d897f2..4d293b2b2f84 100644 --- a/Documentation/devicetree/bindings/power/renesas,apmu.yaml +++ b/Documentation/devicetree/bindings/power/renesas,apmu.yaml @@ -35,6 +35,8 @@ properties: cpus: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: | Array of phandles pointing to CPU cores, which should match the order of CPU cores used by the WUPCR and PSTR registers in the Advanced Power diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml index 9b9d71087466..3deb0fc8dfd3 100644 --- a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml @@ -129,6 +129,8 @@ $defs: pm_qos: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: | A number of phandles to qos blocks which need to be saved and restored while power domain switches state. diff --git a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml index c73abb2ff513..2dda91587dc3 100644 --- a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml +++ b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml @@ -14,6 +14,9 @@ description: | phandle in monitored-battery. If specified the driver uses the charge-full-design-microamp-hours property of the battery. +allOf: + - $ref: power-supply.yaml# + properties: compatible: const: cellwise,cw2015 @@ -37,9 +40,6 @@ properties: minimum: 250 power-supplies: - description: - Specifies supplies used for charging the battery connected to this gauge - $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 8 # Should be enough diff --git a/Documentation/devicetree/bindings/power/supply/power-supply.yaml b/Documentation/devicetree/bindings/power/supply/power-supply.yaml index 259760167759..531b67225c74 100644 --- a/Documentation/devicetree/bindings/power/supply/power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/power-supply.yaml @@ -12,6 +12,8 @@ maintainers: properties: power-supplies: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: This property is added to a supply in order to list the devices which supply it power, referenced by their phandles. diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml index ed560ee8714e..a9b66ececccf 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/regulator.yaml @@ -213,6 +213,8 @@ properties: is 2-way - all coupled regulators should be linked with each other. A regulator should not be coupled with its supplier. $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + maxItems: 1 regulator-coupled-max-spread: description: Array of maximum spread between voltages of coupled regulators diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml index df0191b1ceba..38bdaef4fa39 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml @@ -23,7 +23,7 @@ properties: - st,stm32mp1-booster st,syscfg: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: "/schemas/types.yaml#/definitions/phandle" description: phandle to system configuration controller. vdda-supply: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index c635c181d2c2..bcad8f4080d4 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -115,6 +115,12 @@ properties: qcom,halt-regs: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: Phandle reference to a syscon representing TCSR + - description: offsets within syscon for q6 halt registers + - description: offsets within syscon for modem halt registers + - description: offsets within syscon for nc halt registers description: Phandle reference to a syscon representing TCSR followed by the three offsets within syscon for q6, modem and nc halt registers. diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index b587c97c282b..be3d9b0e876b 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml @@ -29,17 +29,22 @@ properties: st,syscfg-holdboot: description: remote processor reset hold boot - - Phandle of syscon block. - - The offset of the hold boot setting register. - - The field mask of the hold boot. $ref: "/schemas/types.yaml#/definitions/phandle-array" - maxItems: 1 + items: + - items: + - description: Phandle of syscon block + - description: The offset of the hold boot setting register + - description: The field mask of the hold boot st,syscfg-tz: description: Reference to the system configuration which holds the RCC trust zone mode $ref: "/schemas/types.yaml#/definitions/phandle-array" - maxItems: 1 + items: + - items: + - description: Phandle of syscon block + - description: FIXME + - description: FIXME interrupts: description: Should contain the WWDG1 watchdog reset interrupt @@ -93,20 +98,32 @@ properties: $ref: "/schemas/types.yaml#/definitions/phandle-array" description: | Reference to the system configuration which holds the remote - maxItems: 1 + items: + - items: + - description: Phandle of syscon block + - description: FIXME + - description: FIXME st,syscfg-m4-state: $ref: "/schemas/types.yaml#/definitions/phandle-array" description: | Reference to the tamp register which exposes the Cortex-M4 state. - maxItems: 1 + items: + - items: + - description: Phandle of syscon block with the tamp register + - description: FIXME + - description: FIXME st,syscfg-rsc-tbl: $ref: "/schemas/types.yaml#/definitions/phandle-array" description: | Reference to the tamp register which references the Cortex-M4 resource table address. - maxItems: 1 + items: + - items: + - description: Phandle of syscon block with the tamp register + - description: FIXME + - description: FIXME st,auto-boot: $ref: /schemas/types.yaml#/definitions/flag diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml index 7b56497eec4d..4323cefdf19b 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml @@ -79,6 +79,8 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 4 + items: + maxItems: 1 description: | phandles to one or more reserved on-chip SRAM regions. The regions should be defined as child nodes of the respective SRAM node, and diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml index d9c7e8c2b268..0f2bb06cb7b4 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml @@ -189,6 +189,8 @@ patternProperties: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 4 + items: + maxItems: 1 description: | phandles to one or more reserved on-chip SRAM regions. The regions should be defined as child nodes of the respective SRAM node, and diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml index c6c12129d6b7..1fdc2741c36e 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml @@ -123,13 +123,14 @@ properties: ti,bootreg: $ref: /schemas/types.yaml#/definitions/phandle-array - description: | - Should be a triple of the phandle to the System Control - Configuration region that contains the boot address - register, the register offset of the boot address - register within the System Control module, and the bit - shift within the register. This property is required for - all the DSP instances on OMAP4, OMAP5 and DRA7xx SoCs. + items: + - items: + - description: phandle to the System Control Configuration region + - description: register offset of the boot address register + - description: the bit shift within the register + description: + This property is required for all the DSP instances on OMAP4, OMAP5 + and DRA7xx SoCs. ti,autosuspend-delay-ms: description: | @@ -140,6 +141,8 @@ properties: ti,timers: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: | One or more phandles to OMAP DMTimer nodes, that serve as System/Tick timers for the OS running on the remote @@ -156,6 +159,8 @@ properties: ti,watchdog-timers: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: | One or more phandles to OMAP DMTimer nodes, used to serve as Watchdog timers for the processor cores. This diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml index 273f2d95a043..58f2e9d8bb0e 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml @@ -48,6 +48,10 @@ properties: samsung,sysreg: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to System Register syscon node + - description: offset of SW_CONF register for this USI controller description: Should be phandle/offset pair. The phandle to System Register syscon node (for the same domain where this USI controller resides) and the offset diff --git a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml index 5fff586dc802..eb487ed3ca3b 100644 --- a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml @@ -27,6 +27,8 @@ properties: sound-dai: minItems: 2 maxItems: 2 + items: + maxItems: 1 $ref: /schemas/types.yaml#/definitions/phandle-array description: | phandles to the I2S controller and bluetooth codec, diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml index 1538d11ce9a8..d4fc8fdcb72f 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -102,9 +102,11 @@ patternProperties: By default SAI sub-block is in asynchronous mode. Must contain the phandle and index of the SAI sub-block providing the synchronization. - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle-array - - maxItems: 1 + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle of the SAI sub-block + - description: index of the SAI sub-block st,iec60958: description: diff --git a/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml b/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml index f004779ba9b3..850a9841b110 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml @@ -66,9 +66,9 @@ examples: compatible = "qcom,kryo385"; reg = <0x0 0x0>; enable-method = "psci"; - cpu-idle-states = <&LITTLE_CPU_SLEEP_0 - &LITTLE_CPU_SLEEP_1 - &CLUSTER_SLEEP_0>; + cpu-idle-states = <&LITTLE_CPU_SLEEP_0>, + <&LITTLE_CPU_SLEEP_1>, + <&CLUSTER_SLEEP_0>; capacity-dmips-mhz = <607>; dynamic-power-coefficient = <100>; qcom,freq-domain = <&cpufreq_hw 0>; diff --git a/Documentation/devicetree/bindings/thermal/thermal-idle.yaml b/Documentation/devicetree/bindings/thermal/thermal-idle.yaml index 6278ccf16f3f..cc938d7ad1f3 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-idle.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-idle.yaml @@ -37,8 +37,8 @@ properties: exit-latency-us: description: | - The exit latency constraint in microsecond for the injected idle state - for the device. It is the latency constraint to apply when selecting an + The exit latency constraint in microsecond for the injected idle state + for the device. It is the latency constraint to apply when selecting an idle state from among all the present ones. required: @@ -65,7 +65,7 @@ examples: capacity-dmips-mhz = <1024>; dynamic-power-coefficient = <436>; #cooling-cells = <2>; /* min followed by max */ - cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>; + cpu-idle-states = <&CPU_SLEEP>, <&CLUSTER_SLEEP>; thermal-idle { #cooling-cells = <2>; duration-us = <10000>; @@ -81,7 +81,7 @@ examples: capacity-dmips-mhz = <1024>; dynamic-power-coefficient = <436>; #cooling-cells = <2>; /* min followed by max */ - cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>; + cpu-idle-states = <&CPU_SLEEP>, <&CLUSTER_SLEEP>; thermal-idle { #cooling-cells = <2>; duration-us = <10000>; diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml index a39c76b89484..fd6e7c81426e 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml @@ -83,7 +83,7 @@ properties: - const: ss nvidia,xusb-padctl: - $ref: /schemas/types.yaml#/definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle description: phandle to the XUSB pad controller that is used to configure the USB pads used by the XUDC controller. -- cgit From 58bcfe0a082d5b3bf53135c7ee812beb9404803e Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 18 Jan 2022 19:52:34 -0600 Subject: dt-bindings: i2c: mpc: Make each example a separate entry Each independent example should be a separate entry. This allows for 'interrupts' to have different cell sizes. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220119015234.2436754-1-robh@kernel.org --- Documentation/devicetree/bindings/i2c/i2c-mpc.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml index 98c6fcf7bf26..018e1b944424 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml @@ -73,6 +73,7 @@ examples: clock-frequency = <100000>; }; + - | /* MPC5200B based board */ i2c@3d00 { #address-cells = <1>; @@ -84,6 +85,7 @@ examples: fsl,preserve-clocking; }; + - | /* MPC8544 base board */ i2c@3100 { #address-cells = <1>; -- cgit From 8682016ca04371d13f3384b2e14de779286f8549 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 18 Jan 2022 19:52:53 -0600 Subject: dt-bindings: i2c: imx: Make each example a separate entry Each independent example should be a separate entry. This allows for 'interrupts' to have different cell sizes. Signed-off-by: Rob Herring Reviewed-by: Oleksij Rempel Link: https://lore.kernel.org/r/20220119015253.2437352-1-robh@kernel.org --- Documentation/devicetree/bindings/i2c/i2c-imx.yaml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml index c167958ae2a9..01720e338b4c 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml @@ -88,9 +88,7 @@ unevaluatedProperties: false examples: - | #include - #include - #include - #include + #include i2c@83fc4000 { compatible = "fsl,imx51-i2c", "fsl,imx21-i2c"; @@ -99,6 +97,9 @@ examples: clocks = <&clks IMX5_CLK_I2C2_GATE>; }; + - | + #include + i2c@40066000 { compatible = "fsl,vf610-i2c"; reg = <0x40066000 0x1000>; -- cgit From a1ba6ac48a9f707369e35b7305cf492714b7a277 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 19 Jan 2022 09:11:35 -0600 Subject: dt-bindings: nvmem: qcom,spmi-sdam: Drop child node schema Drop the child node schema. The schema for child nodes is already defined by nvmem.yaml and doesn't need to be duplicated in the qcom,spmi-sdam schema. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220119151135.3598392-1-robh@kernel.org --- .../devicetree/bindings/nvmem/qcom,spmi-sdam.yaml | 28 ---------------------- 1 file changed, 28 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml b/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml index a835e64bc6f5..ee79e13b5fe0 100644 --- a/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml +++ b/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml @@ -38,34 +38,6 @@ required: - reg - ranges -patternProperties: - "^.*@[0-9a-f]+$": - type: object - - properties: - reg: - maxItems: 1 - description: - Offset and size in bytes within the storage device. - - bits: - $ref: /schemas/types.yaml#/definitions/uint32-array - maxItems: 1 - items: - items: - - minimum: 0 - maximum: 7 - description: - Offset in bit within the address range specified by reg. - - minimum: 1 - description: - Size in bit within the address range specified by reg. - - required: - - reg - - additionalProperties: false - unevaluatedProperties: false examples: -- cgit From b588772a9cb3c151185a7cafb8c5f38d8ebeaf50 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 19 Jan 2022 11:43:49 -0600 Subject: dt-bindings: ingenic,i2c: Rework interrupts in example In order to determine the number of interrupt cells in examples, the examples will require all 'interrupts' properties to use the same number of cells or have explicit interrupt provider node(s). As the former is simpler, update the Ingenic example to use 2 interrupt cells everywhere. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220119174349.3809513-1-robh@kernel.org --- Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml b/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml index febde6cc5f69..af6d64a6da6e 100644 --- a/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml @@ -69,8 +69,7 @@ examples: #size-cells = <0>; reg = <0x10054000 0x1000>; - interrupt-parent = <&intc>; - interrupts = <56>; + interrupts = <56 IRQ_TYPE_LEVEL_LOW>; clocks = <&cgu JZ4780_CLK_SMB4>; pinctrl-names = "default"; @@ -86,7 +85,6 @@ examples: compatible = "nxp,pcf8563"; reg = <0x51>; - interrupt-parent = <&gpf>; interrupts = <30 IRQ_TYPE_LEVEL_LOW>; }; }; -- cgit From b1809ee932101dbf1b29e860b06d1c26310f2f91 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 19 Jan 2022 11:44:07 -0600 Subject: dt-bindings: i2c: stm32-i2c: Move st,syscfg-fmp definition to top level It is preferred to define all properties in the main schema and leave if/then/else schemas to just be further constraints on properties. Rework the schema to use be more specific for each cell. Previously, multiple entries of 3 cells each was allowed. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220119174407.3810088-1-robh@kernel.org --- .../devicetree/bindings/i2c/st,stm32-i2c.yaml | 24 ++++++++++++---------- 1 file changed, 13 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml index 46b62e1c9273..dccbb18b6dc0 100644 --- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml @@ -25,16 +25,9 @@ allOf: i2c-scl-falling-time-ns: default: 10 - - st,syscfg-fmp: - description: Use to set Fast Mode Plus bit within SYSCFG when - Fast Mode Plus speed is selected by slave. - Format is phandle to syscfg / register offset within - syscfg / register bitmask for FMP bit. - $ref: "/schemas/types.yaml#/definitions/phandle-array" - items: - minItems: 3 - maxItems: 3 + else: + properties: + st,syscfg-fmp: false - if: properties: @@ -87,6 +80,16 @@ properties: minimum: 1 maximum: 1000000 + st,syscfg-fmp: + description: Use to set Fast Mode Plus bit within SYSCFG when Fast Mode + Plus speed is selected by slave. + $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + - items: + - description: phandle to syscfg + - description: register offset within syscfg + - description: register bitmask for FMP bit + required: - compatible - reg @@ -147,4 +150,3 @@ examples: i2c-scl-falling-time-ns = <20>; st,syscfg-fmp = <&syscfg 0x4 0x2>; }; -... -- cgit From d7b0c4aae17100f5ab7d67a361d79165cb983f18 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Thu, 20 Jan 2022 11:23:18 -0600 Subject: dt-bindings: net: ti,k3-am654-cpts: Fix assigned-clock-parents The schema has a typo with 'assigned-clocks-parents'. As it is not required to list assigned clocks in bindings, just drop the assigned-clocks property definitions to fix this Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220120172319.1628500-1-robh@kernel.org --- Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml | 6 ------ 1 file changed, 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml index 1a81bf70c88c..a30419ef550a 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml @@ -103,12 +103,6 @@ properties: clocks: maxItems: 8 - assigned-clocks: - maxItems: 1 - - assigned-clocks-parents: - maxItems: 1 - required: - clocks -- cgit From b85c7d88ed87dcc86981118876160fc74ab2d1fb Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Thu, 20 Jan 2022 11:23:32 -0600 Subject: dt-bindings: watchdog: fsl-imx7ulp-wdt: Fix assigned-clock-parents The schema has a typo with 'assigned-clocks-parents'. As it is not required to list assigned clocks in bindings, just drop the assigned-clocks property definitions to fix this. Signed-off-by: Rob Herring Acked-by: Guenter Roeck Link: https://lore.kernel.org/r/20220120172333.1628990-1-robh@kernel.org --- Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml index fb603a20e396..4ca8a31359a5 100644 --- a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml @@ -29,12 +29,6 @@ properties: clocks: maxItems: 1 - assigned-clocks: - maxItems: 1 - - assigned-clocks-parents: - maxItems: 1 - timeout-sec: true required: @@ -56,7 +50,7 @@ examples: interrupts = ; clocks = <&pcc2 IMX7ULP_CLK_WDG1>; assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG1>; - assigned-clocks-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>; + assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>; timeout-sec = <40>; }; -- cgit From 24a4b57a3d014751ec8ba8b33f38390d5bda94c2 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 19 Jan 2022 12:10:54 -0600 Subject: dt-bindings: remoteproc: ti: Add mailbox provider nodes to example In order to make the 'mboxes' property in the TI remoteproc examples parseable, mailbox provider nodes are needed. Normally, the examples have a __fixup__ node which can be used for determining each phandle+arg entry. However, for this binding the arg cells contain a phandle, and the __fixups__ information can't be used. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220119181053.3846613-1-robh@kernel.org --- Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml | 8 ++++++++ Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml | 8 ++++++++ 2 files changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml index 4323cefdf19b..cedbc5efdc56 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml @@ -142,6 +142,14 @@ examples: #address-cells = <2>; #size-cells = <2>; + mailbox0_cluster3: mailbox-0 { + #mbox-cells = <1>; + }; + + mailbox0_cluster4: mailbox-1 { + #mbox-cells = <1>; + }; + bus@100000 { compatible = "simple-bus"; #address-cells = <2>; diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml index 0f2bb06cb7b4..0868154a0364 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml @@ -238,6 +238,14 @@ examples: #address-cells = <2>; #size-cells = <2>; + mailbox0: mailbox-0 { + #mbox-cells = <1>; + }; + + mailbox1: mailbox-1 { + #mbox-cells = <1>; + }; + bus@100000 { compatible = "simple-bus"; #address-cells = <2>; -- cgit From d7f17b661fe947719500f8b3296f7f02113e8951 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 26 Jan 2022 17:11:46 -0600 Subject: dt-bindings: arm,cci-400: Add interrupt controller to example In order to parse the 'interrupts' an interrupt provider node is needed. That is because the example is a full example (starting with root node) and on those we don't guess and generate a fake provider. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220126231146.1632819-1-robh@kernel.org --- Documentation/devicetree/bindings/arm/arm,cci-400.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/arm,cci-400.yaml b/Documentation/devicetree/bindings/arm/arm,cci-400.yaml index f8530a50863a..1706134b75a3 100644 --- a/Documentation/devicetree/bindings/arm/arm,cci-400.yaml +++ b/Documentation/devicetree/bindings/arm/arm,cci-400.yaml @@ -119,6 +119,11 @@ examples: arm,hbi = <0x249>; interrupt-parent = <&gic>; + gic: interrupt-controller { + interrupt-controller; + #interrupt-cells = <3>; + }; + /* * This CCI node corresponds to a CCI component whose control * registers sits at address 0x000000002c090000. -- cgit From 97709d365bbd68056ace43ef47ad8aaf40f44855 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 26 Jan 2022 17:14:27 -0600 Subject: ASoC: dt-bindings: Centralize the 'sound-dai' definition 'sound-dai' is a common property, but has duplicate type definitions. Create a new common definition to define the type and then update all the other occurrences to just define how many entries there are just like other phandle+arg properties. The constraints on the number of entries is based on the examples and could be wrong. Cc: Krzysztof Kozlowski Signed-off-by: Rob Herring Acked-by: Jerome Brunet Acked-by: Krzysztof Kozlowski Acked-by: Mark Brown Link: https://lore.kernel.org/r/20220126231427.1638089-1-robh@kernel.org --- .../bindings/sound/amlogic,gx-sound-card.yaml | 4 ++-- .../bindings/sound/google,sc7180-trogdor.yaml | 6 ++++-- .../devicetree/bindings/sound/imx-audio-card.yaml | 7 +++++-- .../devicetree/bindings/sound/qcom,sm8250.yaml | 10 +++++++--- .../bindings/sound/samsung,aries-wm8994.yaml | 5 +---- .../bindings/sound/samsung,midas-audio.yaml | 2 -- .../devicetree/bindings/sound/samsung,odroid.yaml | 9 +++------ .../devicetree/bindings/sound/sound-dai.yaml | 20 ++++++++++++++++++++ 8 files changed, 42 insertions(+), 21 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/sound-dai.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml index 2e35aeaa8781..8b5be4b92f35 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml @@ -57,7 +57,7 @@ patternProperties: rate sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 description: phandle of the CPU DAI patternProperties: @@ -71,7 +71,7 @@ patternProperties: properties: sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 description: phandle of the codec DAI required: diff --git a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml index 837e3faa63a9..233caa0ade87 100644 --- a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml +++ b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml @@ -62,13 +62,15 @@ patternProperties: description: Holds subnode which indicates cpu dai. type: object properties: - sound-dai: true + sound-dai: + maxItems: 1 codec: description: Holds subnode which indicates codec dai. type: object properties: - sound-dai: true + sound-dai: + maxItems: 1 required: - link-name diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml index d1816dd061cf..bb3a435722c7 100644 --- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml +++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml @@ -59,13 +59,16 @@ patternProperties: description: Holds subnode which indicates cpu dai. type: object properties: - sound-dai: true + sound-dai: + maxItems: 1 codec: description: Holds subnode which indicates codec dai. type: object properties: - sound-dai: true + sound-dai: + minItems: 1 + maxItems: 2 fsl,mclk-equal-bclk: description: Indicates mclk can be equal to bclk, especially for sai interface diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml index 4bfda04b4608..4ecd4080bb96 100644 --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml @@ -69,19 +69,23 @@ patternProperties: description: Holds subnode which indicates cpu dai. type: object properties: - sound-dai: true + sound-dai: + maxItems: 1 platform: description: Holds subnode which indicates platform dai. type: object properties: - sound-dai: true + sound-dai: + maxItems: 1 codec: description: Holds subnode which indicates codec dai. type: object properties: - sound-dai: true + sound-dai: + minItems: 1 + maxItems: 4 required: - link-name diff --git a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml index eb487ed3ca3b..4ffa275b3c49 100644 --- a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml @@ -27,9 +27,6 @@ properties: sound-dai: minItems: 2 maxItems: 2 - items: - maxItems: 1 - $ref: /schemas/types.yaml#/definitions/phandle-array description: | phandles to the I2S controller and bluetooth codec, in that order @@ -38,7 +35,7 @@ properties: type: object properties: sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 description: phandle to the WM8994 CODEC samsung,audio-routing: diff --git a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml index 095775c598fa..ec50bcb4af5f 100644 --- a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml @@ -21,7 +21,6 @@ properties: type: object properties: sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 1 description: phandle to the I2S controller required: @@ -31,7 +30,6 @@ properties: type: object properties: sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 1 description: phandle to the WM1811 CODEC required: diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml index e8122bc87362..db2513f3e168 100644 --- a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml @@ -37,18 +37,15 @@ properties: type: object properties: sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle-array description: phandles to the I2S controllers codec: type: object properties: sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle-array - description: | - List of phandles to the CODEC nodes, - first entry must be corresponding to the MAX98090 CODEC and - the second entry must be the phandle of the HDMI IP block node. + items: + - description: phandle of the MAX98090 CODEC + - description: phandle of the HDMI IP block node samsung,audio-routing: $ref: /schemas/types.yaml#/definitions/non-unique-string-array diff --git a/Documentation/devicetree/bindings/sound/sound-dai.yaml b/Documentation/devicetree/bindings/sound/sound-dai.yaml new file mode 100644 index 000000000000..61c6f7abc4e7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/sound-dai.yaml @@ -0,0 +1,20 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/sound-dai.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Digital Audio Interface consumer Device Tree Bindings + +maintainers: + - Rob Herring + +select: true + +properties: + sound-dai: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: A phandle plus args to digital audio interface provider(s) + +additionalProperties: true +... -- cgit From c194a38675eac13862ecb51d8a443a566fed97d4 Mon Sep 17 00:00:00 2001 From: David Brazdil Date: Wed, 26 Jan 2022 23:12:36 +0000 Subject: dt-bindings: reserved-memory: Open Profile for DICE Add DeviceTree bindings for Open Profile for DICE, an open protocol for measured boot. Firmware uses DICE to measure the hardware/software combination and generates Compound Device Identifier (CDI) certificates. These are stored in memory and the buffer is described in the DT as a reserved memory region compatible with 'google,open-dice'. 'no-map' is required to ensure the memory region is never treated by the kernel as system memory. Reviewed-by: Rob Herring Signed-off-by: David Brazdil Link: https://lore.kernel.org/r/20220126231237.529308-2-dbrazdil@google.com Signed-off-by: Greg Kroah-Hartman --- .../bindings/reserved-memory/google,open-dice.yaml | 46 ++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml b/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml new file mode 100644 index 000000000000..257a0b51994a --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reserved-memory/google,open-dice.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Open Profile for DICE Device Tree Bindings + +description: | + This binding represents a reserved memory region containing data + generated by the Open Profile for DICE protocol. + + See https://pigweed.googlesource.com/open-dice/ + +maintainers: + - David Brazdil + +allOf: + - $ref: "reserved-memory.yaml" + +properties: + compatible: + const: google,open-dice + + reg: + description: page-aligned region of memory containing DICE data + +required: + - compatible + - reg + - no-map + +unevaluatedProperties: false + +examples: + - | + reserved-memory { + #address-cells = <2>; + #size-cells = <1>; + + dice: dice@12340000 { + compatible = "google,open-dice"; + reg = <0x00 0x12340000 0x2000>; + no-map; + }; + }; -- cgit From 42d3ce71ebcee2233f8a21adb44cb707f2ea3a57 Mon Sep 17 00:00:00 2001 From: Vinod Koul Date: Thu, 3 Feb 2022 14:30:30 +0530 Subject: dt-bindings: arm: qcom: Document SM8450 HDK boards Document the SM8450 HDK board Signed-off-by: Vinod Koul Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220203090031.3128702-1-vkoul@kernel.org --- Documentation/devicetree/bindings/arm/qcom.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 370aab274cd1..9a75274f9ae4 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -268,6 +268,7 @@ properties: - items: - enum: + - qcom,sm8450-hdk - qcom,sm8450-qrd - const: qcom,sm8450 -- cgit From 7f25465e779d9eda845ec3d47151a2acd1d9e383 Mon Sep 17 00:00:00 2001 From: Reinhold Mueller Date: Thu, 9 Dec 2021 11:49:46 +0100 Subject: dt-binding: arm/stm32: Add emtrion hardware emSBC-Argon This patch presents the yaml patch for the emtrion GmbH Argon board series. Signed-off-by: Reinhold Mueller Acked-by: Rob Herring Signed-off-by: Alexandre Torgue --- Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index b07720ea9611..fa0a1b84122e 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -28,6 +28,12 @@ properties: - enum: - st,stm32mp153 - st,stm32mp157 + + - description: emtrion STM32MP1 Argon based Boards + items: + - const: emtrion,stm32mp157c-emsbc-argon + - const: emtrion,stm32mp157c-emstamp-argon + - const: st,stm32mp157 - items: - enum: - st,stm32f429i-disco -- cgit From 5a6bbd1d18cabf5a680e726f0ef8f6dda0105fe8 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Wed, 3 Nov 2021 14:14:53 +0000 Subject: dt-bindings: arm-pmu: Document Apple PMU compatible strings As we are about to add support fur the Apple PMUs, document the compatible strings associated with the two micro-architectures present in the Apple M1. Acked-by: Rob Herring Reviewed-by: Hector Martin Signed-off-by: Marc Zyngier --- Documentation/devicetree/bindings/arm/pmu.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml b/Documentation/devicetree/bindings/arm/pmu.yaml index 981bac451698..7a04b8aaaec3 100644 --- a/Documentation/devicetree/bindings/arm/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/pmu.yaml @@ -20,6 +20,8 @@ properties: items: - enum: - apm,potenza-pmu + - apple,firestorm-pmu + - apple,icestorm-pmu - arm,armv8-pmuv3 # Only for s/w models - arm,arm1136-pmu - arm,arm1176-pmu -- cgit From 74703b13f9d2ef286ef588f29295a2fd30b5f295 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Mon, 1 Nov 2021 19:58:42 +0000 Subject: dt-bindings: apple,aic: Add CPU PMU per-cpu pseudo-interrupts Advertise the two pseudo-interrupts that tied to the two PMU flavours present in the Apple M1 SoC. We choose the expose two different pseudo-interrupts to the OS as the e-core PMU is obviously different from the p-core one, effectively presenting two different devices. Acked-by: Rob Herring Reviewed-by: Hector Martin Signed-off-by: Marc Zyngier --- Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml b/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml index 97359024709a..c7577d401786 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml @@ -56,6 +56,8 @@ properties: - 1: virtual HV timer - 2: physical guest timer - 3: virtual guest timer + - 4: 'efficient' CPU PMU + - 5: 'performance' CPU PMU The 3rd cell contains the interrupt flags. This is normally IRQ_TYPE_LEVEL_HIGH (4). -- cgit From dba07ad11384d6a4ece4acda1fbe726222ca7ad0 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Tue, 14 Dec 2021 16:49:04 +0000 Subject: dt-bindings: apple,aic: Add affinity description for per-cpu pseudo-interrupts Some of the FIQ per-cpu pseudo-interrupts are better described with a specific affinity, the most obvious candidate being the CPU PMUs. Augment the AIC binding to be able to specify that affinity in the interrupt controller node. Reviewed-by: Rob Herring Signed-off-by: Marc Zyngier --- .../bindings/interrupt-controller/apple,aic.yaml | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml b/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml index c7577d401786..85c85b694217 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml @@ -70,6 +70,35 @@ properties: power-domains: maxItems: 1 + affinities: + type: object + additionalProperties: false + description: + FIQ affinity can be expressed as a single "affinities" node, + containing a set of sub-nodes, one per FIQ with a non-default + affinity. + patternProperties: + "^.+-affinity$": + type: object + additionalProperties: false + properties: + apple,fiq-index: + description: + The interrupt number specified as a FIQ, and for which + the affinity is not the default. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 5 + + cpus: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Should be a list of phandles to CPU nodes (as described in + Documentation/devicetree/bindings/arm/cpus.yaml). + + required: + - fiq-index + - cpus + required: - compatible - '#interrupt-cells' -- cgit From 056d38576abec08b6b2d3b2507d8f28b22aaa284 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 31 Jan 2022 18:27:13 +0100 Subject: dt-bindings: i2c: samsung,s3c2410-i2c: convert to dtschema Convert the Samsung S3C24xx/S3C64xx/S5PV210/Exynos SoC I2C Controller bindings to DT schema format. The conversion includes also changes/fixes to the bindings, matching the real hardware and existing Linux driver: 1. Do not require interrupts on samsung,exynos5-sata-phy-i2c, because there is no such. 2. Do not allow gpios on samsung,exynos5-sata-phy-i2c, because they are hard-wired just like for HDMI phy. 3. Do not require samsung,i2c-sda-delay and use default of 0. 4. Require clock, which was always required but missing in bindings. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220131172713.208976-1-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/i2c/i2c-s3c2410.txt | 58 -------- .../bindings/i2c/samsung,s3c2410-i2c.yaml | 164 +++++++++++++++++++++ 2 files changed, 164 insertions(+), 58 deletions(-) delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt create mode 100644 Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt deleted file mode 100644 index 66ae46d3bc2f..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt +++ /dev/null @@ -1,58 +0,0 @@ -* Samsung's I2C controller - -The Samsung's I2C controller is used to interface with I2C devices. - -Required properties: - - compatible: value should be either of the following. - (a) "samsung, s3c2410-i2c", for i2c compatible with s3c2410 i2c. - (b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c. - (c) "samsung, s3c2440-hdmiphy-i2c", for s3c2440-like i2c used - inside HDMIPHY block found on several samsung SoCs - (d) "samsung, exynos5-sata-phy-i2c", for s3c2440-like i2c used as - a host to SATA PHY controller on an internal bus. - - reg: physical base address of the controller and length of memory mapped - region. - - interrupts: interrupt number to the cpu. - - samsung,i2c-sda-delay: Delay (in ns) applied to data line (SDA) edges. - -Required for all cases except "samsung,s3c2440-hdmiphy-i2c": - - Samsung GPIO variant (deprecated): - - gpios: The order of the gpios should be the following: . - The gpio specifier depends on the gpio controller. Required in all - cases except for "samsung,s3c2440-hdmiphy-i2c" whose input/output - lines are permanently wired to the respective clienta - - Pinctrl variant (preferred, if available): - - pinctrl-0: Pin control group to be used for this controller. - - pinctrl-names: Should contain only one value - "default". - -Optional properties: - - samsung,i2c-slave-addr: Slave address in multi-master environment. If not - specified, default value is 0. - - samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not - specified, the default value in Hz is 100000. - - samsung,sysreg-phandle - handle to syscon used to control the system registers - -Example: - - i2c@13870000 { - compatible = "samsung,s3c2440-i2c"; - reg = <0x13870000 0x100>; - interrupts = <345>; - samsung,i2c-sda-delay = <100>; - samsung,i2c-max-bus-freq = <100000>; - /* Samsung GPIO variant begins here */ - gpios = <&gpd1 2 0 /* SDA */ - &gpd1 3 0 /* SCL */>; - /* Samsung GPIO variant ends here */ - /* Pinctrl variant begins here */ - pinctrl-0 = <&i2c3_bus>; - pinctrl-names = "default"; - /* Pinctrl variant ends here */ - #address-cells = <1>; - #size-cells = <0>; - - wm8994@1a { - compatible = "wlf,wm8994"; - reg = <0x1a>; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml new file mode 100644 index 000000000000..84051b0129c2 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml @@ -0,0 +1,164 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/samsung,s3c2410-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C/S5P/Exynos SoC I2C Controller + +maintainers: + - Krzysztof Kozlowski + +properties: + compatible: + enum: + - samsung,s3c2410-i2c + - samsung,s3c2440-i2c + # For s3c2440-like I2C used inside HDMIPHY block found on several SoCs: + - samsung,s3c2440-hdmiphy-i2c + # For s3c2440-like I2C used as a host to SATA PHY controller on an + # internal bus: + - samsung,exynos5-sata-phy-i2c + + '#address-cells': + const: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: i2c + + gpios: + description: | + The order of the GPIOs should be the following:: . The GPIO + specifier depends on the gpio controller. Required in all cases except + for "samsung,s3c2440-hdmiphy-i2c" whose input/output lines are + permanently wired to the respective client. + This property is deprecated. Use "pinctrl-0" and "pinctrl-names" instead. + deprecated: yes + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + samsung,i2c-max-bus-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Desired frequency in Hz of the bus. + default: 100000 + + samsung,i2c-sda-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Delay (in ns) applied to data line (SDA) edges. + default: 0 + + samsung,i2c-slave-addr: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Slave address in multi-master environment. + default: 0 + + samsung,sysreg-phandle: + $ref: /schemas/types.yaml#/definitions/phandle + description: Pandle to syscon used to control the system registers. + + '#size-cells': + const: 0 + +required: + - compatible + - reg + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + - if: + properties: + compatible: + contains: + enum: + - samsung,s3c2440-hdmiphy-i2c + - samsung,exynos5-sata-phy-i2c + then: + properties: + gpios: false + + - if: + properties: + compatible: + contains: + enum: + - samsung,s3c2410-i2c + - samsung,s3c2440-i2c + - samsung,s3c2440-hdmiphy-i2c + then: + required: + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include + #include + + i2c@12c60000 { + compatible = "samsung,s3c2440-i2c"; + reg = <0x12C60000 0x100>; + interrupts = ; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&clock CLK_I2C0>; + clock-names = "i2c"; + pinctrl-names = "default"; + pinctrl-0 = <&i2c0_bus>; + + samsung,sysreg-phandle = <&sysreg_system_controller>; + samsung,i2c-sda-delay = <100>; + samsung,i2c-max-bus-freq = <20000>; + samsung,i2c-slave-addr = <0x66>; + + eeprom@50 { + compatible = "samsung,s524ad0xd1"; + reg = <0x50>; + }; + }; + + i2c@12ce0000 { + compatible = "samsung,s3c2440-hdmiphy-i2c"; + reg = <0x12CE0000 0x1000>; + interrupts = ; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&clock CLK_I2C_HDMI>; + clock-names = "i2c"; + + samsung,i2c-sda-delay = <100>; + samsung,i2c-max-bus-freq = <66000>; + + phy-i2c@38 { + compatible = "samsung,exynos4212-hdmiphy"; + reg = <0x38>; + }; + }; + + i2c@121d0000 { + compatible = "samsung,exynos5-sata-phy-i2c"; + reg = <0x121D0000 0x100>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&clock CLK_SATA_PHYI2C>; + clock-names = "i2c"; + + samsung,i2c-sda-delay = <100>; + samsung,i2c-max-bus-freq = <40000>; + + phy-i2c@38 { + compatible = "samsung,exynos-sataphy-i2c"; + reg = <0x38>; + }; + }; -- cgit From 1018a5463a063715365784704c4e8cdf2eec4b04 Mon Sep 17 00:00:00 2001 From: Chao Yu Date: Fri, 4 Feb 2022 15:19:46 +0800 Subject: f2fs: introduce F2FS_IPU_HONOR_OPU_WRITE ipu policy Once F2FS_IPU_FORCE policy is enabled in some cases: a) f2fs forces to use F2FS_IPU_FORCE in a small-sized volume b) user sets F2FS_IPU_FORCE policy via sysfs Then we may fail to defragment file due to IPU policy check, it doesn't make sense, let's introduce a new IPU policy to allow OPU during file defragmentation. In small-sized volume, let's enable F2FS_IPU_HONOR_OPU_WRITE policy by default. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/ABI/testing/sysfs-fs-f2fs | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 87d3884c90ea..7b50bf82f14d 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -55,8 +55,9 @@ Description: Controls the in-place-update policy. 0x04 F2FS_IPU_UTIL 0x08 F2FS_IPU_SSR_UTIL 0x10 F2FS_IPU_FSYNC - 0x20 F2FS_IPU_ASYNC, + 0x20 F2FS_IPU_ASYNC 0x40 F2FS_IPU_NOCACHE + 0x80 F2FS_IPU_HONOR_OPU_WRITE ==== ================= Refer segment.h for details. -- cgit From 4ed545e7d10049b5492afc184e61a67e478a2cfd Mon Sep 17 00:00:00 2001 From: "jason-jh.lin" Date: Wed, 26 Jan 2022 15:19:23 +0800 Subject: dt-bindings: display: mediatek: disp: split each block to individual yaml 1. Remove mediatek,dislpay.txt 2. Split each display function block to individual yaml file. Signed-off-by: jason-jh.lin Signed-off-by: Chun-Kuang Hu --- .../bindings/display/mediatek/mediatek,aal.yaml | 76 +++++++ .../bindings/display/mediatek/mediatek,ccorr.yaml | 71 +++++++ .../bindings/display/mediatek/mediatek,color.yaml | 85 ++++++++ .../bindings/display/mediatek/mediatek,disp.txt | 219 --------------------- .../bindings/display/mediatek/mediatek,dither.yaml | 75 +++++++ .../bindings/display/mediatek/mediatek,gamma.yaml | 76 +++++++ .../bindings/display/mediatek/mediatek,merge.yaml | 66 +++++++ .../bindings/display/mediatek/mediatek,mutex.yaml | 82 ++++++++ .../bindings/display/mediatek/mediatek,od.yaml | 53 +++++ .../bindings/display/mediatek/mediatek,ovl-2l.yaml | 88 +++++++++ .../bindings/display/mediatek/mediatek,ovl.yaml | 98 +++++++++ .../display/mediatek/mediatek,postmask.yaml | 69 +++++++ .../bindings/display/mediatek/mediatek,rdma.yaml | 115 +++++++++++ .../bindings/display/mediatek/mediatek,split.yaml | 58 ++++++ .../bindings/display/mediatek/mediatek,ufoe.yaml | 61 ++++++ .../bindings/display/mediatek/mediatek,wdma.yaml | 86 ++++++++ 16 files changed, 1159 insertions(+), 219 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml new file mode 100644 index 000000000000..044331f5aacb --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,aal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display adaptive ambient light processor + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek display adaptive ambient light processor, namely AAL, + is responsible for backlight power saving and sunlight visibility improving. + AAL device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8173-disp-aal + - items: + - enum: + - mediatek,mt2712-disp-aal + - mediatek,mt8183-disp-aal + - mediatek,mt8192-disp-aal + - enum: + - mediatek,mt8173-disp-aal + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: AAL Clock + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + + aal@14015000 { + compatible = "mediatek,mt8173-disp-aal"; + reg = <0 0x14015000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_AAL>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml new file mode 100644 index 000000000000..ea45b40edee7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ccorr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display color correction + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek display color correction, namely CCORR, reproduces correct color + on panels with different color gamut. + CCORR device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8183-disp-ccorr + - items: + - const: mediatek,mt8192-disp-ccorr + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: CCORR Clock + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + + ccorr0: ccorr@1400f000 { + compatible = "mediatek,mt8183-disp-ccorr"; + reg = <0 0x1400f000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; + clocks = <&mmsys CLK_MM_DISP_CCORR0>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xf000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml new file mode 100644 index 000000000000..13628f346718 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,color.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display color processor + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek display color processor, namely COLOR, provides hue, luma and + saturation adjustments to get better picture quality and to have one panel + resemble the other in their output characteristics. + COLOR device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt2701-disp-color + - items: + - const: mediatek,mt8167-disp-color + - items: + - const: mediatek,mt8173-disp-color + - items: + - enum: + - mediatek,mt7623-disp-color + - mediatek,mt2712-disp-color + - enum: + - mediatek,mt2701-disp-color + - items: + - enum: + - mediatek,mt8183-disp-color + - mediatek,mt8192-disp-color + - enum: + - mediatek,mt8173-disp-color + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: COLOR Clock + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + + color0: color@14013000 { + compatible = "mediatek,mt8173-disp-color"; + reg = <0 0x14013000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_COLOR0>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x3000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt deleted file mode 100644 index 78044c340e20..000000000000 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ /dev/null @@ -1,219 +0,0 @@ -Mediatek display subsystem -========================== - -The Mediatek display subsystem consists of various DISP function blocks in the -MMSYS register space. The connections between them can be configured by output -and input selectors in the MMSYS_CONFIG register space. Pixel clock and start -of frame signal are distributed to the other function blocks by a DISP_MUTEX -function block. - -All DISP device tree nodes must be siblings to the central MMSYS_CONFIG node. -For a description of the MMSYS_CONFIG binding, see -Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml. - -DISP function blocks -==================== - -A display stream starts at a source function block that reads pixel data from -memory and ends with a sink function block that drives pixels on a display -interface, or writes pixels back to memory. All DISP function blocks have -their own register space, interrupt, and clock gate. The blocks that can -access memory additionally have to list the IOMMU and local arbiter they are -connected to. - -For a description of the display interface sink function blocks, see -Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt and -Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml. - -Required properties (all function blocks): -- compatible: "mediatek,-disp-", one of - "mediatek,-disp-ovl" - overlay (4 layers, blending, csc) - "mediatek,-disp-ovl-2l" - overlay (2 layers, blending, csc) - "mediatek,-disp-rdma" - read DMA / line buffer - "mediatek,-disp-wdma" - write DMA - "mediatek,-disp-ccorr" - color correction - "mediatek,-disp-color" - color processor - "mediatek,-disp-dither" - dither - "mediatek,-disp-aal" - adaptive ambient light controller - "mediatek,-disp-gamma" - gamma correction - "mediatek,-disp-merge" - merge streams from two RDMA sources - "mediatek,-disp-postmask" - control round corner for display frame - "mediatek,-disp-split" - split stream to two encoders - "mediatek,-disp-ufoe" - data compression engine - "mediatek,-dsi" - DSI controller, see mediatek,dsi.txt - "mediatek,-dpi" - DPI controller, see mediatek,dpi.txt - "mediatek,-disp-mutex" - display mutex - "mediatek,-disp-od" - overdrive - the supported chips are mt2701, mt7623, mt2712, mt8167, mt8173, mt8183 and mt8192. -- reg: Physical base address and length of the function block register space -- interrupts: The interrupt signal from the function block (required, except for - merge and split function blocks). -- clocks: device clocks - See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. - For most function blocks this is just a single clock input. Only the DSI and - DPI controller nodes have multiple clock inputs. These are documented in - mediatek,dsi.txt and mediatek,dpi.txt, respectively. - An exception is that the mt8183 mutex is always free running with no clocks property. - -Required properties (DMA function blocks): -- compatible: Should be one of - "mediatek,-disp-ovl" - "mediatek,-disp-rdma" - "mediatek,-disp-wdma" - the supported chips are mt2701, mt8167 and mt8173. -- larb: Should contain a phandle pointing to the local arbiter device as defined - in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml -- iommus: Should point to the respective IOMMU block with master port as - argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml - for details. - -Optional properties (RDMA function blocks): -- mediatek,rdma-fifo-size: rdma fifo size may be different even in same SOC, add this - property to the corresponding rdma - the value is the Max value which defined in hardware data sheet. - mediatek,rdma-fifo-size of mt8173-rdma0 is 8K - mediatek,rdma-fifo-size of mt8183-rdma0 is 5K - mediatek,rdma-fifo-size of mt8183-rdma1 is 2K - -Examples: - -mmsys: clock-controller@14000000 { - compatible = "mediatek,mt8173-mmsys", "syscon"; - reg = <0 0x14000000 0 0x1000>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - #clock-cells = <1>; -}; - -ovl0: ovl@1400c000 { - compatible = "mediatek,mt8173-disp-ovl"; - reg = <0 0x1400c000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_OVL0>; - iommus = <&iommu M4U_PORT_DISP_OVL0>; - mediatek,larb = <&larb0>; -}; - -ovl1: ovl@1400d000 { - compatible = "mediatek,mt8173-disp-ovl"; - reg = <0 0x1400d000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_OVL1>; - iommus = <&iommu M4U_PORT_DISP_OVL1>; - mediatek,larb = <&larb4>; -}; - -rdma0: rdma@1400e000 { - compatible = "mediatek,mt8173-disp-rdma"; - reg = <0 0x1400e000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_RDMA0>; - iommus = <&iommu M4U_PORT_DISP_RDMA0>; - mediatek,larb = <&larb0>; - mediatek,rdma-fifosize = <8192>; -}; - -rdma1: rdma@1400f000 { - compatible = "mediatek,mt8173-disp-rdma"; - reg = <0 0x1400f000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_RDMA1>; - iommus = <&iommu M4U_PORT_DISP_RDMA1>; - mediatek,larb = <&larb4>; -}; - -rdma2: rdma@14010000 { - compatible = "mediatek,mt8173-disp-rdma"; - reg = <0 0x14010000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_RDMA2>; - iommus = <&iommu M4U_PORT_DISP_RDMA2>; - mediatek,larb = <&larb4>; -}; - -wdma0: wdma@14011000 { - compatible = "mediatek,mt8173-disp-wdma"; - reg = <0 0x14011000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_WDMA0>; - iommus = <&iommu M4U_PORT_DISP_WDMA0>; - mediatek,larb = <&larb0>; -}; - -wdma1: wdma@14012000 { - compatible = "mediatek,mt8173-disp-wdma"; - reg = <0 0x14012000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_WDMA1>; - iommus = <&iommu M4U_PORT_DISP_WDMA1>; - mediatek,larb = <&larb4>; -}; - -color0: color@14013000 { - compatible = "mediatek,mt8173-disp-color"; - reg = <0 0x14013000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_COLOR0>; -}; - -color1: color@14014000 { - compatible = "mediatek,mt8173-disp-color"; - reg = <0 0x14014000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_COLOR1>; -}; - -aal@14015000 { - compatible = "mediatek,mt8173-disp-aal"; - reg = <0 0x14015000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_AAL>; -}; - -gamma@14016000 { - compatible = "mediatek,mt8173-disp-gamma"; - reg = <0 0x14016000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_GAMMA>; -}; - -ufoe@1401a000 { - compatible = "mediatek,mt8173-disp-ufoe"; - reg = <0 0x1401a000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_UFOE>; -}; - -dsi0: dsi@1401b000 { - /* See mediatek,dsi.txt for details */ -}; - -dpi0: dpi@1401d000 { - /* See mediatek,dpi.txt for details */ -}; - -mutex: mutex@14020000 { - compatible = "mediatek,mt8173-disp-mutex"; - reg = <0 0x14020000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_MUTEX_32K>; -}; - -od@14023000 { - compatible = "mediatek,mt8173-disp-od"; - reg = <0 0x14023000 0 0x1000>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_OD>; -}; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml new file mode 100644 index 000000000000..2c05e3019c75 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,dither.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display dither processor + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek display dither processor, namely DITHER, works by approximating + unavailable colors with available colors and by mixing and matching available + colors to mimic unavailable ones. + DITHER device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8183-disp-dither + - items: + - enum: + - mediatek,mt8192-disp-dither + - enum: + - mediatek,mt8183-disp-dither + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: DITHER Clock + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + + dither0: dither@14012000 { + compatible = "mediatek,mt8183-disp-dither"; + reg = <0 0x14012000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; + clocks = <&mmsys CLK_MM_DISP_DITHER0>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x2000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml new file mode 100644 index 000000000000..89ccb8dbadd7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,gamma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display gamma correction + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek display gamma correction, namely GAMMA, provides a nonlinear + operation used to adjust luminance in display system. + GAMMA device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8173-disp-gamma + - items: + - const: mediatek,mt8183-disp-gamma + - items: + - enum: + - mediatek,mt8192-disp-gamma + - enum: + - mediatek,mt8183-disp-gamma + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: GAMMA Clock + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + + gamma@14016000 { + compatible = "mediatek,mt8173-disp-gamma"; + reg = <0 0x14016000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_GAMMA>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x6000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml new file mode 100644 index 000000000000..7aa6974d509d --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,merge.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display merge + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek display merge, namely MERGE, is used to merge two slice-per-line + inputs into one side-by-side output. + MERGE device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8173-disp-merge + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: MERGE Clock + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + + merge@14017000 { + compatible = "mediatek,mt8173-disp-merge"; + reg = <0 0x14017000 0 0x1000>; + power-domains = <&spm MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_MERGE>; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml new file mode 100644 index 000000000000..90f11e12a55e --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,mutex.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display mutex + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek mutex, namely MUTEX, is used to send the triggers signals called + Start Of Frame (SOF) / End Of Frame (EOF) to each sub-modules on the display + data path or MDP data path. + In some SoC, such as mt2701, MUTEX could be a hardware mutex which protects + the shadow register. + MUTEX device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt2701-disp-mutex + - items: + - const: mediatek,mt2712-disp-mutex + - items: + - const: mediatek,mt8167-disp-mutex + - items: + - const: mediatek,mt8173-disp-mutex + - items: + - const: mediatek,mt8183-disp-mutex + - items: + - const: mediatek,mt8192-disp-mutex + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: MUTEX Clock + + mediatek,gce-events: + description: + The event id which is mapping to the specific hardware event signal + to gce. The event id is defined in the gce header + include/dt-bindings/gce/-gce.h of each chips. + $ref: /schemas/types.yaml#/definitions/phandle-array + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + + mutex: mutex@14020000 { + compatible = "mediatek,mt8173-disp-mutex"; + reg = <0 0x14020000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_MUTEX_32K>; + mediatek,gce-events = , + ; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml new file mode 100644 index 000000000000..7519db315217 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,od.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display overdirve + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek display overdrive, namely OD, increases the transition values + of pixels between consecutive frames to make LCD rotate faster. + OD device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt2712-disp-od + - items: + - const: mediatek,mt8173-disp-od + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: OD Clock + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + + od@14023000 { + compatible = "mediatek,mt8173-disp-od"; + reg = <0 0x14023000 0 0x1000>; + clocks = <&mmsys CLK_MM_DISP_OD>; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml new file mode 100644 index 000000000000..611a2dbdefa4 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ovl-2l.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display overlay 2 layer + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek display overlay 2 layer, namely OVL-2L, provides 2 more layer + for OVL. + OVL-2L device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8183-disp-ovl-2l + - items: + - const: mediatek,mt8192-disp-ovl-2l + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: OVL-2L Clock + + iommus: + description: + This property should point to the respective IOMMU block with master port as argument, + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. + + mediatek,larb: + description: + This property should contain a phandle pointing to the local arbiter devices defined in + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml. + It must sort according to the local arbiter index, like larb0, larb1, larb2... + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 32 + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + - iommus + +additionalProperties: false + +examples: + - | + + ovl_2l0: ovl@14009000 { + compatible = "mediatek,mt8183-disp-ovl-2l"; + reg = <0 0x14009000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; + clocks = <&mmsys CLK_MM_DISP_OVL0_2L>; + iommus = <&iommu M4U_PORT_DISP_2L_OVL0_LARB0>; + mediatek,larb = <&larb0>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x9000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml new file mode 100644 index 000000000000..8e4a62cb9c81 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ovl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display overlay + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek display overlay, namely OVL, can do alpha blending from + the memory. + OVL device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt2701-disp-ovl + - items: + - const: mediatek,mt8173-disp-ovl + - items: + - const: mediatek,mt8183-disp-ovl + - items: + - const: mediatek,mt8192-disp-ovl + - items: + - enum: + - mediatek,mt7623-disp-ovl + - mediatek,mt2712-disp-ovl + - enum: + - mediatek,mt2701-disp-ovl + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: OVL Clock + + iommus: + description: + This property should point to the respective IOMMU block with master port as argument, + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. + + mediatek,larb: + description: + This property should contain a phandle pointing to the local arbiter devices defined in + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml. + It must sort according to the local arbiter index, like larb0, larb1, larb2... + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 32 + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + - iommu + +additionalProperties: false + +examples: + - | + + ovl0: ovl@1400c000 { + compatible = "mediatek,mt8173-disp-ovl"; + reg = <0 0x1400c000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_OVL0>; + iommus = <&iommu M4U_PORT_DISP_OVL0>; + mediatek,larb = <&larb0>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xc000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml new file mode 100644 index 000000000000..6ac1da2e8871 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,postmask.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display postmask + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek display postmask, namely POSTMASK, provides round corner pattern + generation. + POSTMASK device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8192-disp-postmask + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: POSTMASK Clock + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + + postmask0: postmask@1400d000 { + compatible = "mediatek,mt8192-disp-postmask"; + reg = <0 0x1400d000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8192_POWER_DOMAIN_DISP>; + clocks = <&mmsys CLK_MM_DISP_POSTMASK0>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xd000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml new file mode 100644 index 000000000000..a3c5f4c9fbcd --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml @@ -0,0 +1,115 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,rdma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek Read Direct Memory Access + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek Read Direct Memory Access(RDMA) component used to read the + data into DMA. It provides real time data to the back-end panel + driver, such as DSI, DPI and DP_INTF. + It contains one line buffer to store the sufficient pixel data. + RDMA device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt2701-disp-rdma + - items: + - const: mediatek,mt8173-disp-rdma + - items: + - const: mediatek,mt8183-disp-rdma + - items: + - enum: + - mediatek,mt7623-disp-rdma + - mediatek,mt2712-disp-rdma + - enum: + - mediatek,mt2701-disp-rdma + - items: + - enum: + - mediatek,mt8192-disp-rdma + - enum: + - mediatek,mt8183-disp-rdma + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: RDMA Clock + + iommus: + description: + This property should point to the respective IOMMU block with master port as argument, + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. + + mediatek,larb: + description: + This property should contain a phandle pointing to the local arbiter devices defined in + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml. + It must sort according to the local arbiter index, like larb0, larb1, larb2... + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 32 + + mediatek,rdma-fifo-size: + description: + rdma fifo size may be different even in same SOC, add this property to the + corresponding rdma. + The value below is the Max value which defined in hardware data sheet + mediatek,rdma-fifo-size of mt8173-rdma0 is 8K + mediatek,rdma-fifo-size of mt8183-rdma0 is 5K + mediatek,rdma-fifo-size of mt8183-rdma1 is 2K + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8192, 5120, 2048] + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + - iommus + +additionalProperties: false + +examples: + - | + + rdma0: rdma@1400e000 { + compatible = "mediatek,mt8173-disp-rdma"; + reg = <0 0x1400e000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_RDMA0>; + iommus = <&iommu M4U_PORT_DISP_RDMA0>; + mediatek,larb = <&larb0>; + mediatek,rdma-fifosize = <8192>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xe000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml new file mode 100644 index 000000000000..4f08e89c1067 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,split.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display split + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek display split, namely SPLIT, is used to split stream to two + encoders. + SPLIT device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8173-disp-split + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: SPLIT Clock + +required: + - compatible + - reg + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + + split0: split@14018000 { + compatible = "mediatek,mt8173-disp-split"; + reg = <0 0x14018000 0 0x1000>; + power-domains = <&spm MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_SPLIT0>; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml new file mode 100644 index 000000000000..6e8748529e73 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ufoe.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display UFOe + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek display UFOe stands for Unified Frame Optimization engine. + UFOe can cut the data rate for DSI port which may lead to reduce power + consumption. + UFOe device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8173-disp-ufoe + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: UFOe Clock + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + + ufoe@1401a000 { + compatible = "mediatek,mt8173-disp-ufoe"; + reg = <0 0x1401a000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_UFOE>; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml new file mode 100644 index 000000000000..aaf5649b6413 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,wdma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek Write Direct Memory Access + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + Mediatek Write Direct Memory Access(WDMA) component used to write + the data into DMA. + WDMA device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8173-disp-wdma + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: WDMA Clock + + iommus: + description: + This property should point to the respective IOMMU block with master port as argument, + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. + + mediatek,larb: + description: + This property should contain a phandle pointing to the local arbiter devices defined in + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml. + It must sort according to the local arbiter index, like larb0, larb1, larb2... + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 32 + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + - iommus + +additionalProperties: false + +examples: + - | + + wdma0: wdma@14011000 { + compatible = "mediatek,mt8173-disp-wdma"; + reg = <0 0x14011000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_WDMA0>; + iommus = <&iommu M4U_PORT_DISP_WDMA0>; + mediatek,larb = <&larb0>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x1000 0x1000>; + }; -- cgit From b9c15721b32c1f150b42b8a3ca291d205af544a7 Mon Sep 17 00:00:00 2001 From: "jason-jh.lin" Date: Wed, 26 Jan 2022 15:19:24 +0800 Subject: dt-bindings: display: mediatek: dsc: add yaml for mt8195 SoC binding 1. Add mediatek,dsc.yaml to describe DSC module in details. 2. Add mt8195 SoC binding to mediatek,dsc.yaml. Signed-off-by: jason-jh.lin Signed-off-by: Chun-Kuang Hu --- .../bindings/display/mediatek/mediatek,dsc.yaml | 71 ++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml new file mode 100644 index 000000000000..1ec083eff824 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,dsc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: mediatek display DSC controller + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + The DSC standard is a specification of the algorithms used for + compressing and decompressing image display streams, including + the specification of the syntax and semantics of the compressed + video bit stream. DSC is designed for real-time systems with + real-time compression, transmission, decompression and Display. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8195-disp-dsc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: DSC Wrapper Clock + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + mediatek,gce-client-reg: + description: + The register of client driver can be configured by gce with 4 arguments + defined in this property, such as phandle of gce, subsys id, + register offset and size. + Each subsys id is mapping to a base address of display function blocks + register which is defined in the gce header + include/dt-bindings/gce/-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + + dsc0: disp_dsc_wrap@1c009000 { + compatible = "mediatek,mt8195-disp-dsc"; + reg = <0 0x1c009000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; + clocks = <&vdosys0 CLK_VDO0_DSC_WRAP0>; + mediatek,gce-client-reg = <&gce1 SUBSYS_1c00XXXX 0x9000 0x1000>; + }; -- cgit From 1cffdf6057a21eedb6340f6f5bb075ce13094ae2 Mon Sep 17 00:00:00 2001 From: "jason-jh.lin" Date: Wed, 26 Jan 2022 15:19:25 +0800 Subject: dt-bindings: display: mediatek: merge: add additional prop for mt8195 add MERGE additional properties description for mt8195: 1. async clock 2. fifo setting enable 3. reset controller Signed-off-by: jason-jh.lin Signed-off-by: Chun-Kuang Hu --- .../bindings/display/mediatek/mediatek,merge.yaml | 38 ++++++++++++++++++++++ 1 file changed, 38 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml index 7aa6974d509d..fae106cf1753 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml @@ -36,8 +36,28 @@ properties: Documentation/devicetree/bindings/power/power-domain.yaml for details. clocks: + maxItems: 2 items: - description: MERGE Clock + - description: MERGE Async Clock + Controlling the synchronous process between MERGE and other display + function blocks cross clock domain. + + clock-names: + maxItems: 2 + items: + - const: merge + - const: merge_async + + mediatek,merge-fifo-en: + description: + The setting of merge fifo is mainly provided for the display latency + buffer to ensure that the back-end panel display data will not be + underrun, a little more data is needed in the fifo. + According to the merge fifo settings, when the water level is detected + to be insufficient, it will trigger RDMA sending ultra and preulra + command to SMI to speed up the data rate. + type: boolean mediatek,gce-client-reg: description: The register of client driver can be configured by gce with @@ -47,6 +67,11 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 1 + resets: + description: reset controller + See Documentation/devicetree/bindings/reset/reset.txt for details. + maxItems: 1 + required: - compatible - reg @@ -64,3 +89,16 @@ examples: power-domains = <&spm MT8173_POWER_DOMAIN_MM>; clocks = <&mmsys CLK_MM_DISP_MERGE>; }; + + merge5: disp_vpp_merge5@1c110000 { + compatible = "mediatek,mt8195-disp-merge"; + reg = <0 0x1c110000 0 0x1000>; + interrupts = ; + clocks = <&vdosys1 CLK_VDO1_VPP_MERGE4>, + <&vdosys1 CLK_VDO1_MERGE4_DL_ASYNC>; + clock-names = "merge","merge_async"; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; + mediatek,gce-client-reg = <&gce1 SUBSYS_1c11XXXX 0x0000 0x1000>; + mediatek,merge-fifo-en = <1>; + resets = <&vdosys1 MT8195_VDOSYS1_SW0_RST_B_MERGE4_DL_ASYNC>; + }; -- cgit From a79257bae9bfe7fa4d38f9ba3f7c6746b2029f88 Mon Sep 17 00:00:00 2001 From: "jason-jh.lin" Date: Wed, 26 Jan 2022 15:19:26 +0800 Subject: dt-bindings: display: mediatek: add mt8195 SoC binding for vdosys0 Add mt8195 SoC binding to AAL, CCORR, COLOR, DITHER, GAMMA, MERGE, MUTEX, OVL and RDMA yaml schema for vdosys0. Signed-off-by: jason-jh.lin Signed-off-by: Chun-Kuang Hu --- Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 + .../devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 5 +++++ .../devicetree/bindings/display/mediatek/mediatek,color.yaml | 1 + .../devicetree/bindings/display/mediatek/mediatek,dither.yaml | 1 + .../devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 1 + .../devicetree/bindings/display/mediatek/mediatek,merge.yaml | 2 ++ .../devicetree/bindings/display/mediatek/mediatek,mutex.yaml | 5 +++-- Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 5 +++++ .../devicetree/bindings/display/mediatek/mediatek,rdma.yaml | 2 ++ 9 files changed, 21 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index 044331f5aacb..225f9dd726d2 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -28,6 +28,7 @@ properties: - mediatek,mt2712-disp-aal - mediatek,mt8183-disp-aal - mediatek,mt8192-disp-aal + - mediatek,mt8195-disp-aal - enum: - mediatek,mt8173-disp-aal diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml index ea45b40edee7..6894b6999412 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -25,6 +25,11 @@ properties: - const: mediatek,mt8183-disp-ccorr - items: - const: mediatek,mt8192-disp-ccorr + - items: + - enum: + - mediatek,mt8195-disp-ccorr + - enum: + - mediatek,mt8192-disp-ccorr reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index 13628f346718..bc83155b3b4c 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -38,6 +38,7 @@ properties: - enum: - mediatek,mt8183-disp-color - mediatek,mt8192-disp-color + - mediatek,mt8195-disp-color - enum: - mediatek,mt8173-disp-color reg: diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml index 2c05e3019c75..9d89297f5f1d 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml @@ -27,6 +27,7 @@ properties: - items: - enum: - mediatek,mt8192-disp-dither + - mediatek,mt8195-disp-dither - enum: - mediatek,mt8183-disp-dither diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml index 89ccb8dbadd7..247baad147b3 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -28,6 +28,7 @@ properties: - items: - enum: - mediatek,mt8192-disp-gamma + - mediatek,mt8195-disp-gamma - enum: - mediatek,mt8183-disp-gamma diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml index fae106cf1753..60b21ef5549b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml @@ -23,6 +23,8 @@ properties: oneOf: - items: - const: mediatek,mt8173-disp-merge + - items: + - const: mediatek,mt8195-disp-merge reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml index 90f11e12a55e..6eca525eced0 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/display/mediatek/mediatek,mutex.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Mediatek display mutex +title: Mediatek mutex maintainers: - Chun-Kuang Hu @@ -36,7 +36,8 @@ properties: - const: mediatek,mt8183-disp-mutex - items: - const: mediatek,mt8192-disp-mutex - + - items: + - const: mediatek,mt8195-disp-mutex reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml index 8e4a62cb9c81..e71f79bc2dee 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -35,6 +35,11 @@ properties: - mediatek,mt2712-disp-ovl - enum: - mediatek,mt2701-disp-ovl + - items: + - enum: + - mediatek,mt8195-disp-ovl + - enum: + - mediatek,mt8183-disp-ovl reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml index a3c5f4c9fbcd..8ef821641672 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml @@ -29,6 +29,8 @@ properties: - const: mediatek,mt8173-disp-rdma - items: - const: mediatek,mt8183-disp-rdma + - items: + - const: mediatek,mt8195-disp-rdma - items: - enum: - mediatek,mt7623-disp-rdma -- cgit From 7938f4218168ae9fc4bdddb15976f9ebbae41999 Mon Sep 17 00:00:00 2001 From: Lucas De Marchi Date: Fri, 4 Feb 2022 09:05:41 -0800 Subject: dma-buf-map: Rename to iosys-map MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Rename struct dma_buf_map to struct iosys_map and corresponding APIs. Over time dma-buf-map grew up to more functionality than the one used by dma-buf: in fact it's just a shim layer to abstract system memory, that can be accessed via regular load and store, from IO memory that needs to be acessed via arch helpers. The idea is to extend this API so it can fulfill other needs, internal to a single driver. Example: in the i915 driver it's desired to share the implementation for integrated graphics, which uses mostly system memory, with discrete graphics, which may need to access IO memory. The conversion was mostly done with the following semantic patch: @r1@ @@ - struct dma_buf_map + struct iosys_map @r2@ @@ ( - DMA_BUF_MAP_INIT_VADDR + IOSYS_MAP_INIT_VADDR | - dma_buf_map_set_vaddr + iosys_map_set_vaddr | - dma_buf_map_set_vaddr_iomem + iosys_map_set_vaddr_iomem | - dma_buf_map_is_equal + iosys_map_is_equal | - dma_buf_map_is_null + iosys_map_is_null | - dma_buf_map_is_set + iosys_map_is_set | - dma_buf_map_clear + iosys_map_clear | - dma_buf_map_memcpy_to + iosys_map_memcpy_to | - dma_buf_map_incr + iosys_map_incr ) @@ @@ - #include + #include Then some files had their includes adjusted and some comments were update to remove mentions to dma-buf-map. Since this is not specific to dma-buf anymore, move the documentation to the "Bus-Independent Device Accesses" section. v2: - Squash patches v3: - Fix wrong removal of dma-buf.h from MAINTAINERS - Move documentation from dma-buf.rst to device-io.rst v4: - Change documentation title and level Signed-off-by: Lucas De Marchi Acked-by: Christian König Acked-by: Sumit Semwal Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20220204170541.829227-1-lucas.demarchi@intel.com --- Documentation/driver-api/device-io.rst | 9 +++++++++ Documentation/driver-api/dma-buf.rst | 9 --------- Documentation/gpu/todo.rst | 20 ++++++++++---------- 3 files changed, 19 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/device-io.rst b/Documentation/driver-api/device-io.rst index e9f04b1815d1..4d2baac0311c 100644 --- a/Documentation/driver-api/device-io.rst +++ b/Documentation/driver-api/device-io.rst @@ -502,6 +502,15 @@ pcim_iomap() Not using these wrappers may make drivers unusable on certain platforms with stricter rules for mapping I/O memory. +Generalizing Access to System and I/O Memory +============================================ + +.. kernel-doc:: include/linux/iosys-map.h + :doc: overview + +.. kernel-doc:: include/linux/iosys-map.h + :internal: + Public Functions Provided ========================= diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 2cd7db82d9fe..55006678394a 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -128,15 +128,6 @@ Kernel Functions and Structures Reference .. kernel-doc:: include/linux/dma-buf.h :internal: -Buffer Mapping Helpers -~~~~~~~~~~~~~~~~~~~~~~ - -.. kernel-doc:: include/linux/dma-buf-map.h - :doc: overview - -.. kernel-doc:: include/linux/dma-buf-map.h - :internal: - Reservation Objects ------------------- diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index da138dd39883..c8f39c1ef1ee 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -222,7 +222,7 @@ Convert drivers to use drm_fbdev_generic_setup() Most drivers can use drm_fbdev_generic_setup(). Driver have to implement atomic modesetting and GEM vmap support. Historically, generic fbdev emulation expected the framebuffer in system memory or system-like memory. By employing -struct dma_buf_map, drivers with frambuffers in I/O memory can be supported +struct iosys_map, drivers with frambuffers in I/O memory can be supported as well. Contact: Maintainer of the driver you plan to convert @@ -234,7 +234,7 @@ Reimplement functions in drm_fbdev_fb_ops without fbdev A number of callback functions in drm_fbdev_fb_ops could benefit from being rewritten without dependencies on the fbdev module. Some of the -helpers could further benefit from using struct dma_buf_map instead of +helpers could further benefit from using struct iosys_map instead of raw pointers. Contact: Thomas Zimmermann , Daniel Vetter @@ -434,19 +434,19 @@ Contact: Emil Velikov, respective driver maintainers Level: Intermediate -Use struct dma_buf_map throughout codebase ------------------------------------------- +Use struct iosys_map throughout codebase +---------------------------------------- -Pointers to shared device memory are stored in struct dma_buf_map. Each +Pointers to shared device memory are stored in struct iosys_map. Each instance knows whether it refers to system or I/O memory. Most of the DRM-wide -interface have been converted to use struct dma_buf_map, but implementations +interface have been converted to use struct iosys_map, but implementations often still use raw pointers. -The task is to use struct dma_buf_map where it makes sense. +The task is to use struct iosys_map where it makes sense. -* Memory managers should use struct dma_buf_map for dma-buf-imported buffers. -* TTM might benefit from using struct dma_buf_map internally. -* Framebuffer copying and blitting helpers should operate on struct dma_buf_map. +* Memory managers should use struct iosys_map for dma-buf-imported buffers. +* TTM might benefit from using struct iosys_map internally. +* Framebuffer copying and blitting helpers should operate on struct iosys_map. Contact: Thomas Zimmermann , Christian König, Daniel Vetter -- cgit From d39f99568da815b63268671d2744fe9bd64e36fe Mon Sep 17 00:00:00 2001 From: Sankeerth Billakanti Date: Mon, 7 Feb 2022 16:17:02 -0800 Subject: dt-bindings: phy: Add eDP PHY compatible for sc7280 Add compatible string for the supported eDP PHY on sc7280 platform. Signed-off-by: Sankeerth Billakanti Reviewed-by: Stephen Boyd Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20220207161612.REPOST.v1.1.Iee1d505f0a35c2805f0468625b117d2e0f0ad339@changeid Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml index 9076e19b6417..a5850ff529f8 100644 --- a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml @@ -16,7 +16,9 @@ description: properties: compatible: - const: qcom,sc8180x-edp-phy + enum: + - qcom,sc7280-edp-phy + - qcom,sc8180x-edp-phy reg: items: -- cgit From cec6647a00e25105ade1a4574d8c3a657acddf57 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Wed, 29 Dec 2021 18:03:55 +0100 Subject: dt-bindings: backlight: qcom-wled: Add PM6150L compatible Document the compatible for the wled block found in PM6150L. Signed-off-by: Luca Weiss Acked-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20211229170358.2457006-2-luca.weiss@fairphone.com --- Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml index d839e75d9788..1c24b333c6e2 100644 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml @@ -22,6 +22,7 @@ properties: - qcom,pmi8994-wled - qcom,pmi8998-wled - qcom,pm660l-wled + - qcom,pm6150l-wled - qcom,pm8150l-wled reg: -- cgit From 90c3e3b8140d833a737085abd1ac133d14a32390 Mon Sep 17 00:00:00 2001 From: Alistair Francis Date: Mon, 24 Jan 2022 22:10:02 +1000 Subject: dt-bindings: mfd: Initial commit of silergy,sy7636a.yaml Initial support for the Silergy SY7636A Power Management chip and regulator. Signed-off-by: Alistair Francis Reviewed-by: Rob Herring Signed-off-by: Lee Jones --- .../devicetree/bindings/mfd/silergy,sy7636a.yaml | 82 ++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml b/Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml new file mode 100644 index 000000000000..6de74c701635 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/silergy,sy7636a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: silergy sy7636a PMIC + +maintainers: + - Alistair Francis + +properties: + compatible: + const: silergy,sy7636a + + reg: + description: + I2C device address. + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + '#thermal-sensor-cells': + const: 0 + + epd-pwr-good-gpios: + description: + Specifying the power good GPIOs. + maxItems: 1 + + regulators: + type: object + + properties: + compatible: + const: silergy,sy7636a-regulator + + vcom: + type: object + $ref: /schemas/regulator/regulator.yaml# + description: + The regulator for the compenstation voltage. Enabling/disabling this + enables/disables the entire device. + properties: + regulator-name: + const: vcom + + additionalProperties: false + +required: + - compatible + - reg + - '#thermal-sensor-cells' + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@62 { + compatible = "silergy,sy7636a"; + reg = <0x62>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_epdpmic>; + #thermal-sensor-cells = <0>; + + regulators { + reg_epdpmic: vcom { + regulator-name = "vcom"; + regulator-boot-on; + }; + }; + }; + }; +... -- cgit From de34a4053250781404779b567b58dd97af689ce0 Mon Sep 17 00:00:00 2001 From: Alistair Francis Date: Mon, 24 Jan 2022 22:10:06 +1000 Subject: hwmon: sy7636a: Add temperature driver for sy7636a This is a multi-function device to interface with the sy7636a EPD PMIC chip from Silergy. Signed-off-by: Alistair Francis Acked-by: Guenter Roeck Signed-off-by: Lee Jones --- Documentation/hwmon/index.rst | 1 + Documentation/hwmon/sy7636a-hwmon.rst | 26 ++++++++++++++++++++++++++ 2 files changed, 27 insertions(+) create mode 100644 Documentation/hwmon/sy7636a-hwmon.rst (limited to 'Documentation') diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index df20022c741f..6e0906ef5d25 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -185,6 +185,7 @@ Hardware Monitoring Kernel Drivers smsc47m1 sparx5-temp stpddc60 + sy7636a-hwmon tc654 tc74 thmc50 diff --git a/Documentation/hwmon/sy7636a-hwmon.rst b/Documentation/hwmon/sy7636a-hwmon.rst new file mode 100644 index 000000000000..5612079397d5 --- /dev/null +++ b/Documentation/hwmon/sy7636a-hwmon.rst @@ -0,0 +1,26 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver sy7636a-hwmon +========================= + +Supported chips: + + * Silergy SY7636A PMIC + + +Description +----------- + +This driver adds hardware temperature reading support for +the Silergy SY7636A PMIC. + +The following sensors are supported + + * Temperature + - SoC on-die temperature in milli-degree C + +sysfs-Interface +--------------- + +temp0_input + - SoC on-die temperature (milli-degree C) -- cgit From 4f351edd26758702b0707aaa4c0aa277e4b52f07 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Mon, 7 Feb 2022 20:25:30 +0800 Subject: dt-bindings: gpio: gpio-vf610: Add imx93 compatible string Add the compatible string for i.MX93 Signed-off-by: Peng Fan Signed-off-by: Bartosz Golaszewski --- Documentation/devicetree/bindings/gpio/gpio-vf610.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml index e1359391d3a4..d2c39dba56ad 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml @@ -25,7 +25,9 @@ properties: - const: fsl,imx7ulp-gpio - const: fsl,vf610-gpio - items: - - const: fsl,imx8ulp-gpio + - enum: + - fsl,imx93-gpio + - fsl,imx8ulp-gpio - const: fsl,imx7ulp-gpio reg: -- cgit From 330582535eb293fc6d72db95342196f98ac11c99 Mon Sep 17 00:00:00 2001 From: Abel Vesa Date: Tue, 18 Jan 2022 15:17:15 +0200 Subject: dt-bindings: serial: fsl-lpuart: Add i.MX8DXL compatible Add i.MX8DXL lpuart compatible to the bindings documentation. Reviewed-by: Peng Fan Acked-by: Rob Herring Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20220118131715.2051965-1-abel.vesa@nxp.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml index 6e04e3848261..c33e3af1b5ea 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml @@ -28,7 +28,9 @@ properties: - fsl,imx8ulp-lpuart - const: fsl,imx7ulp-lpuart - items: - - const: fsl,imx8qm-lpuart + - enum: + - fsl,imx8qm-lpuart + - fsl,imx8dxl-lpuart - const: fsl,imx8qxp-lpuart reg: -- cgit From 93fc5f2fba94ca227f5073150f8d74421eadb395 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Mon, 7 Feb 2022 14:22:11 +0000 Subject: dt-bindings: serial: renesas,scif: Remove redundant renesas,scif-r9a07g054 This patch removes redundant "renesas,scif-r9a07g054" from binding documentation as it uses renesas,scif-r9a07g044 fallback. Whilst remove the additional renesas,scif-r9a07g054 from Items. Reviewed-by: Geert Uytterhoeven Signed-off-by: Biju Das Link: https://lore.kernel.org/r/20220207142213.19552-1-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/renesas,scif.yaml | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml index ba5d3e0acc63..461392091579 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml @@ -73,7 +73,6 @@ properties: - items: - enum: - renesas,scif-r9a07g044 # RZ/G2{L,LC} - - renesas,scif-r9a07g054 # RZ/V2L - items: - enum: @@ -167,7 +166,6 @@ if: - renesas,rcar-gen3-scif - renesas,rcar-gen4-scif - renesas,scif-r9a07g044 - - renesas,scif-r9a07g054 then: required: - resets -- cgit From ed265bc955cfa46490d07db0bf5de985b31367da Mon Sep 17 00:00:00 2001 From: Biju Das Date: Mon, 7 Feb 2022 14:22:12 +0000 Subject: dt-bindings: serial: renesas,scif: Document RZ/G2UL SoC Add SCIF binding documentation for Renesas RZ/G2UL SoC. SCIF block on RZ/G2UL is identical to one found on the RZ/G2L SoC. No driver changes are required as RZ/G2L compatible string "renesas,scif-r9a07g044" will be used as a fallback. Whilst dropped the comments after RZ/G2{L,LC} fallback as to avoid updating the comment over and over again when a new IP is added Reviewed-by: Geert Uytterhoeven Signed-off-by: Biju Das Link: https://lore.kernel.org/r/20220207142213.19552-2-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/renesas,scif.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml index 461392091579..5d37f8f189fb 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml @@ -76,8 +76,9 @@ properties: - items: - enum: + - renesas,scif-r9a07g043 # RZ/G2UL - renesas,scif-r9a07g054 # RZ/V2L - - const: renesas,scif-r9a07g044 # RZ/G2{L,LC} fallback for RZ/V2L + - const: renesas,scif-r9a07g044 # RZ/G2{L,LC} fallback reg: maxItems: 1 -- cgit From 5cfb02ced7e0928b5ae39b0320c2de408bb210ac Mon Sep 17 00:00:00 2001 From: Biju Das Date: Mon, 7 Feb 2022 14:22:13 +0000 Subject: dt-bindings: serial: renesas,sci: Document RZ/G2UL SoC Add SCI binding documentation for Renesas RZ/G2UL SoC. No driver changes are required as generic compatible string "renesas,sci" will be used as a fallback. Reviewed-by: Geert Uytterhoeven Signed-off-by: Biju Das Link: https://lore.kernel.org/r/20220207142213.19552-3-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/renesas,sci.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/renesas,sci.yaml b/Documentation/devicetree/bindings/serial/renesas,sci.yaml index 8dda4e10e09d..bf7708a7a2c0 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,sci.yaml @@ -17,6 +17,7 @@ properties: oneOf: - items: - enum: + - renesas,r9a07g043-sci # RZ/G2UL - renesas,r9a07g044-sci # RZ/G2{L,LC} - renesas,r9a07g054-sci # RZ/V2L - const: renesas,sci # generic SCI compatible UART @@ -67,6 +68,7 @@ if: compatible: contains: enum: + - renesas,r9a07g043-sci - renesas,r9a07g044-sci - renesas,r9a07g054-sci then: -- cgit From 97ecbfb30dca36843d7a456def55e4d19007c3d2 Mon Sep 17 00:00:00 2001 From: Sean Anderson Date: Thu, 27 Jan 2022 15:06:30 -0500 Subject: dt-bindings: usb: dwc3: Deprecate snps,ref-clock-period-ns This property is redundant because we can determine the correct value for REFCLKPER based on the "ref" clock. Deprecate it, and encourage users to provide a clock instead. This also restricts the minimum and maximum to the values documented in the register reference [1]. [1] https://www.xilinx.com/html_docs/registers/ug1087/usb3_xhci___guctl.html Reviewed-by: Rob Herring Signed-off-by: Sean Anderson Link: https://lore.kernel.org/r/20220127200636.1456175-2-sean.anderson@seco.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index d29ffcd27472..4f2b0913ad9f 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -263,8 +263,11 @@ properties: Value for REFCLKPER field of GUCTL register for reference clock period in nanoseconds, when the hardware set default does not match the actual clock. - minimum: 1 - maximum: 0x3ff + + This binding is deprecated. Instead, provide an appropriate reference clock. + minimum: 8 + maximum: 62 + deprecated: true snps,rx-thr-num-pkt-prd: description: -- cgit From 2f04aa69ab5c5c40d2e3e51fd73ce2ecb651e9ba Mon Sep 17 00:00:00 2001 From: Vincent Whitchurch Date: Fri, 4 Feb 2022 16:52:40 +0100 Subject: regulator: Add bindings for TPS62864x Add bindings for the TPS62864/TPS6286/TPS62868/TPS62869 voltage regulators. Signed-off-by: Vincent Whitchurch Link: https://lore.kernel.org/r/20220204155241.576342-2-vincent.whitchurch@axis.com Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/ti,tps62864.yaml | 62 ++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/ti,tps62864.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/ti,tps62864.yaml b/Documentation/devicetree/bindings/regulator/ti,tps62864.yaml new file mode 100644 index 000000000000..e3d739a37ab0 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/ti,tps62864.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/ti,tps62864.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI TPS62864/TPS6286/TPS62868/TPS62869 voltage regulator + +maintainers: + - Vincent Whitchurch + +properties: + compatible: + enum: + - ti,tps62864 + - ti,tps62866 + - ti,tps62868 + - ti,tps62869 + + reg: + maxItems: 1 + + regulators: + type: object + + patternProperties: + "SW": + type: object + $ref: regulator.yaml# + + additionalProperties: false + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@48 { + compatible = "ti,tps62864"; + reg = <0x48>; + + regulators { + SW { + regulator-name = "+0.85V"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <890000>; + regulator-initial-mode = ; + }; + }; + }; + }; + +... -- cgit From 60edd652005fe2931565f658f23f86d094f4c1f0 Mon Sep 17 00:00:00 2001 From: Leilk Liu Date: Tue, 25 Jan 2022 09:23:28 +0800 Subject: spi: Convert spi-slave-mt27xx to json-schema Convert Mediatek ARM SOC's SPI Slave controller binding to json-schema format. Signed-off-by: Leilk Liu Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220125012330.13449-2-leilk.liu@mediatek.com Signed-off-by: Mark Brown --- .../bindings/spi/mediatek,spi-slave-mt27xx.yaml | 58 ++++++++++++++++++++++ .../devicetree/bindings/spi/spi-slave-mt27xx.txt | 33 ------------ 2 files changed, 58 insertions(+), 33 deletions(-) create mode 100644 Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml delete mode 100644 Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml new file mode 100644 index 000000000000..7977799a8ee1 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/mediatek,spi-slave-mt27xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SPI Slave controller for MediaTek ARM SoCs + +maintainers: + - Leilk Liu + +allOf: + - $ref: "/schemas/spi/spi-controller.yaml#" + +properties: + compatible: + enum: + - mediatek,mt2712-spi-slave + - mediatek,mt8195-spi-slave + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: spi + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + #include + + spi@10013000 { + compatible = "mediatek,mt2712-spi-slave"; + reg = <0x10013000 0x100>; + interrupts = ; + clocks = <&infracfg CLK_INFRA_AO_SPI1>; + clock-names = "spi"; + assigned-clocks = <&topckgen CLK_TOP_SPISLV_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL1_D2>; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt b/Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt deleted file mode 100644 index 9192724540fd..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt +++ /dev/null @@ -1,33 +0,0 @@ -Binding for MTK SPI Slave controller - -Required properties: -- compatible: should be one of the following. - - mediatek,mt2712-spi-slave: for mt2712 platforms - - mediatek,mt8195-spi-slave: for mt8195 platforms -- reg: Address and length of the register set for the device. -- interrupts: Should contain spi interrupt. -- clocks: phandles to input clocks. - It's clock gate, and should be <&infracfg CLK_INFRA_AO_SPI1>. -- clock-names: should be "spi" for the clock gate. - -Optional properties: -- assigned-clocks: it's mux clock, should be <&topckgen CLK_TOP_SPISLV_SEL>. -- assigned-clock-parents: parent of mux clock. - It's PLL, and should be one of the following. - - <&topckgen CLK_TOP_UNIVPLL1_D2>: specify parent clock 312MHZ. - It's the default one. - - <&topckgen CLK_TOP_UNIVPLL1_D4>: specify parent clock 156MHZ. - - <&topckgen CLK_TOP_UNIVPLL2_D4>: specify parent clock 104MHZ. - - <&topckgen CLK_TOP_UNIVPLL1_D8>: specify parent clock 78MHZ. - -Example: -- SoC Specific Portion: -spis1: spi@10013000 { - compatible = "mediatek,mt2712-spi-slave"; - reg = <0 0x10013000 0 0x100>; - interrupts = ; - clocks = <&infracfg CLK_INFRA_AO_SPI1>; - clock-names = "spi"; - assigned-clocks = <&topckgen CLK_TOP_SPISLV_SEL>; - assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL1_D2>; -}; -- cgit From 08727dd751234bc878be64e60ea6f0d8ea0d54c0 Mon Sep 17 00:00:00 2001 From: Leilk Liu Date: Tue, 25 Jan 2022 09:23:29 +0800 Subject: spi: Convert spi-mt65xx to json-schema Convert Mediatek ARM SOC's SPI Master controller binding to json-schema format. Signed-off-by: Leilk Liu Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220125012330.13449-3-leilk.liu@mediatek.com Signed-off-by: Mark Brown --- .../bindings/spi/mediatek,spi-mt65xx.yaml | 101 +++++++++++++++++++++ .../devicetree/bindings/spi/spi-mt65xx.txt | 68 -------------- 2 files changed, 101 insertions(+), 68 deletions(-) create mode 100644 Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml delete mode 100644 Documentation/devicetree/bindings/spi/spi-mt65xx.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml new file mode 100644 index 000000000000..ea977fba49a7 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/mediatek,spi-mt65xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SPI Bus controller for MediaTek ARM SoCs + +maintainers: + - Leilk Liu + +allOf: + - $ref: "/schemas/spi/spi-controller.yaml#" + +properties: + compatible: + oneOf: + - items: + - enum: + - mediatek,mt7629-spi + - const: mediatek,mt7622-spi + - items: + - enum: + - mediatek,mt8516-spi + - const: mediatek,mt2712-spi + - items: + - enum: + - mediatek,mt6779-spi + - mediatek,mt8192-spi + - mediatek,mt8195-spi + - const: mediatek,mt6765-spi + - items: + - enum: + - mediatek,mt2701-spi + - mediatek,mt2712-spi + - mediatek,mt6589-spi + - mediatek,mt6765-spi + - mediatek,mt6893-spi + - mediatek,mt7622-spi + - mediatek,mt8135-spi + - mediatek,mt8173-spi + - mediatek,mt8183-spi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: clock used for the parent clock + - description: clock used for the muxes clock + - description: clock used for the clock gate + + clock-names: + items: + - const: parent-clk + - const: sel-clk + - const: spi-clk + + mediatek,pad-select: + $ref: /schemas/types.yaml#/definitions/uint32-array + maxItems: 4 + items: + enum: [0, 1, 2, 3] + description: + specify which pins group(ck/mi/mo/cs) spi controller used. + This is an array. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - '#address-cells' + - '#size-cells' + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + #include + + spi@1100a000 { + compatible = "mediatek,mt8173-spi"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x1100a000 0x1000>; + interrupts = ; + clocks = <&topckgen CLK_TOP_SYSPLL3_D2>, + <&topckgen CLK_TOP_SPI_SEL>, + <&pericfg CLK_PERI_SPI0>; + clock-names = "parent-clk", "sel-clk", "spi-clk"; + cs-gpios = <&pio 105 GPIO_ACTIVE_LOW>, <&pio 72 GPIO_ACTIVE_LOW>; + mediatek,pad-select = <1>, <0>; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt deleted file mode 100644 index 2a24969159cc..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt +++ /dev/null @@ -1,68 +0,0 @@ -Binding for MTK SPI controller - -Required properties: -- compatible: should be one of the following. - - mediatek,mt2701-spi: for mt2701 platforms - - mediatek,mt2712-spi: for mt2712 platforms - - mediatek,mt6589-spi: for mt6589 platforms - - mediatek,mt6765-spi: for mt6765 platforms - - mediatek,mt7622-spi: for mt7622 platforms - - "mediatek,mt7629-spi", "mediatek,mt7622-spi": for mt7629 platforms - - mediatek,mt8135-spi: for mt8135 platforms - - mediatek,mt8173-spi: for mt8173 platforms - - mediatek,mt8183-spi: for mt8183 platforms - - mediatek,mt6893-spi: for mt6893 platforms - - "mediatek,mt8192-spi", "mediatek,mt6765-spi": for mt8192 platforms - - "mediatek,mt8195-spi", "mediatek,mt6765-spi": for mt8195 platforms - - "mediatek,mt8516-spi", "mediatek,mt2712-spi": for mt8516 platforms - - "mediatek,mt6779-spi", "mediatek,mt6765-spi": for mt6779 platforms - -- #address-cells: should be 1. - -- #size-cells: should be 0. - -- reg: Address and length of the register set for the device - -- interrupts: Should contain spi interrupt - -- clocks: phandles to input clocks. - The first should be one of the following. It's PLL. - - <&clk26m>: specify parent clock 26MHZ. - - <&topckgen CLK_TOP_SYSPLL3_D2>: specify parent clock 109MHZ. - It's the default one. - - <&topckgen CLK_TOP_SYSPLL4_D2>: specify parent clock 78MHZ. - - <&topckgen CLK_TOP_UNIVPLL2_D4>: specify parent clock 104MHZ. - - <&topckgen CLK_TOP_UNIVPLL1_D8>: specify parent clock 78MHZ. - The second should be <&topckgen CLK_TOP_SPI_SEL>. It's clock mux. - The third is <&pericfg CLK_PERI_SPI0>. It's clock gate. - -- clock-names: shall be "parent-clk" for the parent clock, "sel-clk" for the - muxes clock, and "spi-clk" for the clock gate. - -Optional properties: --cs-gpios: see spi-bus.txt. - -- mediatek,pad-select: specify which pins group(ck/mi/mo/cs) spi - controller used. This is an array, the element value should be 0~3, - only required for MT8173. - 0: specify GPIO69,70,71,72 for spi pins. - 1: specify GPIO102,103,104,105 for spi pins. - 2: specify GPIO128,129,130,131 for spi pins. - 3: specify GPIO5,6,7,8 for spi pins. - -Example: - -- SoC Specific Portion: -spi: spi@1100a000 { - compatible = "mediatek,mt8173-spi"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0 0x1100a000 0 0x1000>; - interrupts = ; - clocks = <&topckgen CLK_TOP_SYSPLL3_D2>, - <&topckgen CLK_TOP_SPI_SEL>, - <&pericfg CLK_PERI_SPI0>; - clock-names = "parent-clk", "sel-clk", "spi-clk"; - cs-gpios = <&pio 105 GPIO_ACTIVE_LOW>, <&pio 72 GPIO_ACTIVE_LOW>; - mediatek,pad-select = <1>, <0>; -}; -- cgit From ccbc5d0a92c5f1d42d1a1635b53f1987821e9cdd Mon Sep 17 00:00:00 2001 From: Leilk Liu Date: Tue, 25 Jan 2022 09:23:30 +0800 Subject: spi: Add compatible for Mediatek MT8186 This commit adds dt-binding documentation of spi bus for Mediatek MT8186 SoC Platform. Signed-off-by: Leilk Liu Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220125012330.13449-4-leilk.liu@mediatek.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml index ea977fba49a7..bfa44acb1bdd 100644 --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml @@ -26,6 +26,7 @@ properties: - items: - enum: - mediatek,mt6779-spi + - mediatek,mt8186-spi - mediatek,mt8192-spi - mediatek,mt8195-spi - const: mediatek,mt6765-spi -- cgit From 3b8ab4da3405d07ddfe434f17f9014740b30a19c Mon Sep 17 00:00:00 2001 From: Li-hao Kuo Date: Mon, 7 Feb 2022 09:46:34 +0800 Subject: spi: Fix test error for sp7021. Remove the include path and modify parameters for fix error for bt binding test Fixes: a708078eeb99 ("spi: Add Sunplus SP7021 schema") Signed-off-by: Li-hao Kuo Link: https://lore.kernel.org/r/b8a94fbfcab68b1279b09b6297099310c209927b.1644198244.git.lhjeff911@gmail.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml b/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml index 38589fdbc80d..298eac28c40f 100644 --- a/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml +++ b/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml @@ -59,8 +59,6 @@ unevaluatedProperties: false examples: - | - #include - #include #include spi@9C002D80 { compatible = "sunplus,sp7021-spi"; @@ -73,8 +71,8 @@ examples: interrupts = <144 IRQ_TYPE_LEVEL_HIGH>, <146 IRQ_TYPE_LEVEL_HIGH>, <145 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clkc SPI_COMBO_0>; - resets = <&rstc RST_SPI_COMBO_0>; + clocks = <&clkc 0x32>; + resets = <&rstc 0x22>; pinctrl-names = "default"; pinctrl-0 = <&pins_spi0>; }; -- cgit From 8ad885126daadba5dc388c7f06d5cb93206e40b1 Mon Sep 17 00:00:00 2001 From: Frank Wunderlich Date: Sun, 23 Jan 2022 14:51:15 +0100 Subject: dt-bindings: rockchip: Add BananaPi R2 Pro Board Add Devicetree Binding for Bananapi R2 Pro Board based on rk3568 SoC Co-developed-by: Peter Geis Signed-off-by: Peter Geis Signed-off-by: Frank Wunderlich Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220123135116.136846-2-linux@fw-web.de Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 4aed16176434..33d6423fe6c3 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -651,6 +651,11 @@ properties: - const: rockchip,rk3568-evb1-v10 - const: rockchip,rk3568 + - description: Rockchip RK3568 Banana Pi R2 Pro + items: + - const: rockchip,rk3568-bpi-r2pro + - const: rockchip,rk3568 + additionalProperties: true ... -- cgit From 5177fe91e4cf78a659aada2c9cf712db4d788481 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Thu, 27 Jan 2022 16:17:54 +0000 Subject: KVM: arm64: Do not change the PMU event filter after a VCPU has run Userspace can specify which events a guest is allowed to use with the KVM_ARM_VCPU_PMU_V3_FILTER attribute. The list of allowed events can be identified by a guest from reading the PMCEID{0,1}_EL0 registers. Changing the PMU event filter after a VCPU has run can cause reads of the registers performed before the filter is changed to return different values than reads performed with the new event filter in place. The architecture defines the two registers as read-only, and this behaviour contradicts that. Keep track when the first VCPU has run and deny changes to the PMU event filter to prevent this from happening. Signed-off-by: Marc Zyngier [ Alexandru E: Added commit message, updated ioctl documentation ] Signed-off-by: Alexandru Elisei Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220127161759.53553-2-alexandru.elisei@arm.com --- Documentation/virt/kvm/devices/vcpu.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst index 60a29972d3f1..d063aaee5bb7 100644 --- a/Documentation/virt/kvm/devices/vcpu.rst +++ b/Documentation/virt/kvm/devices/vcpu.rst @@ -70,7 +70,7 @@ irqchip. -ENODEV PMUv3 not supported or GIC not initialized -ENXIO PMUv3 not properly configured or in-kernel irqchip not configured as required prior to calling this attribute - -EBUSY PMUv3 already initialized + -EBUSY PMUv3 already initialized or a VCPU has already run -EINVAL Invalid filter range ======= ====================================================== -- cgit From 6ee7fca2a4a023b14aa1f1f3c4f6c833116116ef Mon Sep 17 00:00:00 2001 From: Alexandru Elisei Date: Thu, 27 Jan 2022 16:17:58 +0000 Subject: KVM: arm64: Add KVM_ARM_VCPU_PMU_V3_SET_PMU attribute When KVM creates an event and there are more than one PMUs present on the system, perf_init_event() will go through the list of available PMUs and will choose the first one that can create the event. The order of the PMUs in this list depends on the probe order, which can change under various circumstances, for example if the order of the PMU nodes change in the DTB or if asynchronous driver probing is enabled on the kernel command line (with the driver_async_probe=armv8-pmu option). Another consequence of this approach is that on heteregeneous systems all virtual machines that KVM creates will use the same PMU. This might cause unexpected behaviour for userspace: when a VCPU is executing on the physical CPU that uses this default PMU, PMU events in the guest work correctly; but when the same VCPU executes on another CPU, PMU events in the guest will suddenly stop counting. Fortunately, perf core allows user to specify on which PMU to create an event by using the perf_event_attr->type field, which is used by perf_init_event() as an index in the radix tree of available PMUs. Add the KVM_ARM_VCPU_PMU_V3_CTRL(KVM_ARM_VCPU_PMU_V3_SET_PMU) VCPU attribute to allow userspace to specify the arm_pmu that KVM will use when creating events for that VCPU. KVM will make no attempt to run the VCPU on the physical CPUs that share the PMU, leaving it up to userspace to manage the VCPU threads' affinity accordingly. To ensure that KVM doesn't expose an asymmetric system to the guest, the PMU set for one VCPU will be used by all other VCPUs. Once a VCPU has run, the PMU cannot be changed in order to avoid changing the list of available events for a VCPU, or to change the semantics of existing events. Signed-off-by: Alexandru Elisei Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220127161759.53553-6-alexandru.elisei@arm.com --- Documentation/virt/kvm/devices/vcpu.rst | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst index d063aaee5bb7..e8c5770590a2 100644 --- a/Documentation/virt/kvm/devices/vcpu.rst +++ b/Documentation/virt/kvm/devices/vcpu.rst @@ -104,6 +104,34 @@ hardware event. Filtering event 0x1E (CHAIN) has no effect either, as it isn't strictly speaking an event. Filtering the cycle counter is possible using event 0x11 (CPU_CYCLES). +1.4 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_SET_PMU +------------------------------------------ + +:Parameters: in kvm_device_attr.addr the address to an int representing the PMU + identifier. + +:Returns: + + ======= ==================================================== + -EBUSY PMUv3 already initialized, a VCPU has already run or + an event filter has already been set + -EFAULT Error accessing the PMU identifier + -ENXIO PMU not found + -ENODEV PMUv3 not supported or GIC not initialized + -ENOMEM Could not allocate memory + ======= ==================================================== + +Request that the VCPU uses the specified hardware PMU when creating guest events +for the purpose of PMU emulation. The PMU identifier can be read from the "type" +file for the desired PMU instance under /sys/devices (or, equivalent, +/sys/bus/even_source). This attribute is particularly useful on heterogeneous +systems where there are at least two CPU PMUs on the system. The PMU that is set +for one VCPU will be used by all the other VCPUs. It isn't possible to set a PMU +if a PMU event filter is already present. + +Note that KVM will not make any attempts to run the VCPU on the physical CPUs +associated with the PMU specified by this attribute. This is entirely left to +userspace. 2. GROUP: KVM_ARM_VCPU_TIMER_CTRL ================================= -- cgit From 583cda1b0e7d5d49db5fc15db623166310e36bf6 Mon Sep 17 00:00:00 2001 From: Alexandru Elisei Date: Thu, 27 Jan 2022 16:17:59 +0000 Subject: KVM: arm64: Refuse to run VCPU if the PMU doesn't match the physical CPU Userspace can assign a PMU to a VCPU with the KVM_ARM_VCPU_PMU_V3_SET_PMU device ioctl. If the VCPU is scheduled on a physical CPU which has a different PMU, the perf events needed to emulate a guest PMU won't be scheduled in and the guest performance counters will stop counting. Treat it as an userspace error and refuse to run the VCPU in this situation. Suggested-by: Marc Zyngier Signed-off-by: Alexandru Elisei Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220127161759.53553-7-alexandru.elisei@arm.com --- Documentation/virt/kvm/devices/vcpu.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst index e8c5770590a2..260db203a1e2 100644 --- a/Documentation/virt/kvm/devices/vcpu.rst +++ b/Documentation/virt/kvm/devices/vcpu.rst @@ -131,7 +131,11 @@ if a PMU event filter is already present. Note that KVM will not make any attempts to run the VCPU on the physical CPUs associated with the PMU specified by this attribute. This is entirely left to -userspace. +userspace. However, attempting to run the VCPU on a physical CPU not supported +by the PMU will fail and KVM_RUN will return with +exit_reason = KVM_EXIT_FAIL_ENTRY and populate the fail_entry struct by setting +hardare_entry_failure_reason field to KVM_EXIT_FAIL_ENTRY_CPU_UNSUPPORTED and +the cpu field to the processor id. 2. GROUP: KVM_ARM_VCPU_TIMER_CTRL ================================= -- cgit From cdaa1b1941f667814300799ddb74f3079517cd5a Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Fri, 28 Jan 2022 15:39:40 -0800 Subject: fscrypt: update documentation for direct I/O support Now that direct I/O is supported on encrypted files in some cases, document what these cases are. Link: https://lore.kernel.org/r/20220128233940.79464-6-ebiggers@kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Eric Biggers --- Documentation/filesystems/fscrypt.rst | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 4d5d50dca65c..6ccd5efb25b7 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -1047,8 +1047,8 @@ astute users may notice some differences in behavior: may be used to overwrite the source files but isn't guaranteed to be effective on all filesystems and storage devices. -- Direct I/O is not supported on encrypted files. Attempts to use - direct I/O on such files will fall back to buffered I/O. +- Direct I/O is supported on encrypted files only under some + circumstances. For details, see `Direct I/O support`_. - The fallocate operations FALLOC_FL_COLLAPSE_RANGE and FALLOC_FL_INSERT_RANGE are not supported on encrypted files and will @@ -1179,6 +1179,27 @@ Inline encryption doesn't affect the ciphertext or other aspects of the on-disk format, so users may freely switch back and forth between using "inlinecrypt" and not using "inlinecrypt". +Direct I/O support +================== + +For direct I/O on an encrypted file to work, the following conditions +must be met (in addition to the conditions for direct I/O on an +unencrypted file): + +* The file must be using inline encryption. Usually this means that + the filesystem must be mounted with ``-o inlinecrypt`` and inline + encryption hardware must be present. However, a software fallback + is also available. For details, see `Inline encryption support`_. + +* The I/O request must be fully aligned to the filesystem block size. + This means that the file position the I/O is targeting, the lengths + of all I/O segments, and the memory addresses of all I/O buffers + must be multiples of this value. Note that the filesystem block + size may be greater than the logical block size of the block device. + +If either of the above conditions is not met, then direct I/O on the +encrypted file will fall back to buffered I/O. + Implementation details ====================== -- cgit From e84d3a45cce1a3653230955562828c998db9e765 Mon Sep 17 00:00:00 2001 From: Stanislav Jakubek Date: Fri, 14 Jan 2022 18:21:55 +0100 Subject: dt-bindings: trivial-devices: make comment indentation consistent Makes the comment indentation consistent across the board. Signed-off-by: Stanislav Jakubek Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220114172155.GA3677@standask-GA-A55M-S2HP --- Documentation/devicetree/bindings/trivial-devices.yaml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 091792ba993e..2855581eef40 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -77,7 +77,7 @@ properties: - delta,ahe50dc-fan # Delta Electronics DPS-650-AB power supply - delta,dps650ab - # Delta Electronics DPS920AB 920W 54V Power Supply + # Delta Electronics DPS920AB 920W 54V Power Supply - delta,dps920ab # 1/4 Brick DC/DC Regulated Power Module - delta,q54sj108a2 @@ -123,13 +123,13 @@ properties: - ibm,cffps2 # Infineon IR36021 digital POL buck controller - infineon,ir36021 - # Infineon IR38060 Voltage Regulator + # Infineon IR38060 Voltage Regulator - infineon,ir38060 # Infineon IR38064 Voltage Regulator - infineon,ir38064 - # Infineon IR38164 Voltage Regulator + # Infineon IR38164 Voltage Regulator - infineon,ir38164 - # Infineon IR38263 Voltage Regulator + # Infineon IR38263 Voltage Regulator - infineon,ir38263 # Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz) - infineon,slb9635tt -- cgit From d71ea591223e0ffc39ebca4a0f98244fc208a267 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 27 Jan 2022 08:52:29 +0100 Subject: dt-bindings: vendor-prefixes: clarify HP prefix There are two independent companies: "HP Inc." and "Hewlett Packard Enterprise". Clarify that "hp" prefix is about the first one. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220127075229.10299-1-krzysztof.kozlowski@canonical.com --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 294093d45a23..6136dafe4853 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -514,7 +514,7 @@ patternProperties: "^hoperun,.*": description: Jiangsu HopeRun Software Co., Ltd. "^hp,.*": - description: Hewlett Packard + description: Hewlett Packard Inc. "^hsg,.*": description: HannStar Display Co. "^holtek,.*": -- cgit From 0ff0af18216436d0151af4e410400c7a19ca9437 Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Sun, 23 Jan 2022 16:29:21 -0800 Subject: cxl/core/port: Rename bus.c to port.c Given it is dominated by port infrastructure, and will only acquire more, rename bus.c to port.c. Reviewed-by: Ben Widawsky Link: https://lore.kernel.org/r/164298416136.3018233.15442880970000855425.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/driver-api/cxl/memory-devices.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index 3b8f41395f6b..c8f7a16cd0e3 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -36,10 +36,10 @@ CXL Core .. kernel-doc:: drivers/cxl/cxl.h :internal: -.. kernel-doc:: drivers/cxl/core/bus.c +.. kernel-doc:: drivers/cxl/core/port.c :doc: cxl core -.. kernel-doc:: drivers/cxl/core/bus.c +.. kernel-doc:: drivers/cxl/core/port.c :identifiers: .. kernel-doc:: drivers/cxl/core/pmem.c -- cgit From 83fbdbe4c18678eebe63fc49913f149a5afde057 Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Sun, 23 Jan 2022 16:30:41 -0800 Subject: cxl/core: Emit modalias for CXL devices In order to enable libkmod lookups for CXL device objects to their corresponding module, add 'modalias' to the base attribute of CXL devices. Reviewed-by: Jonathan Cameron Reviewed-by: Ben Widawsky Link: https://lore.kernel.org/r/164298424120.3018233.15611905873808708542.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/ABI/testing/sysfs-bus-cxl | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 0b6a2e6e8fbb..6d8cbf3355b5 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -34,6 +34,15 @@ Description: the same value communicated in the DEVTYPE environment variable for uevents for devices on the "cxl" bus. +What: /sys/bus/cxl/devices/*/modalias +Date: December, 2021 +KernelVersion: v5.18 +Contact: linux-cxl@vger.kernel.org +Description: + CXL device objects export the modalias attribute which mirrors + the same value communicated in the MODALIAS environment variable + for uevents for devices on the "cxl" bus. + What: /sys/bus/cxl/devices/portX/uport Date: June, 2021 KernelVersion: v5.14 -- cgit From 54cdbf845cf719c09b45ae588cba469aabb3159c Mon Sep 17 00:00:00 2001 From: Ben Widawsky Date: Tue, 1 Feb 2022 13:07:51 -0800 Subject: cxl/port: Add a driver for 'struct cxl_port' objects The need for a CXL port driver and a dedicated cxl_bus_type is driven by a need to simultaneously support 2 independent physical memory decode domains (cache coherent CXL.mem and uncached PCI.mmio) that also intersect at a single PCIe device node. A CXL Port is a device that advertises a CXL Component Register block with an "HDM Decoder Capability Structure". >From Documentation/driver-api/cxl/memory-devices.rst: Similar to how a RAID driver takes disk objects and assembles them into a new logical device, the CXL subsystem is tasked to take PCIe and ACPI objects and assemble them into a CXL.mem decode topology. The need for runtime configuration of the CXL.mem topology is also similar to RAID in that different environments with the same hardware configuration may decide to assemble the topology in contrasting ways. One may choose performance (RAID0) striping memory across multiple Host Bridges and endpoints while another may opt for fault tolerance and disable any striping in the CXL.mem topology. The port driver identifies whether an endpoint Memory Expander is connected to a CXL topology. If an active (bound to the 'cxl_port' driver) CXL Port is not found at every PCIe Switch Upstream port and an active "root" CXL Port then the device is just a plain PCIe endpoint only capable of participating in PCI.mmio and DMA cycles, not CXL.mem coherent interleave sets. The 'cxl_port' driver lets the CXL subsystem leverage driver-core infrastructure for setup and teardown of register resources and communicating device activation status to userspace. The cxl_bus_type can rendezvous the async arrival of platform level CXL resources (via the 'cxl_acpi' driver) with the asynchronous enumeration of Memory Expander endpoints, while also implementing a hierarchical locking model independent of the associated 'struct pci_dev' locking model. The locking for dport and decoder enumeration is now handled in the core rather than callers. For now the port driver only enumerates and registers CXL resources (downstream port metadata and decoder resources) later it will be used to take action on its decoders in response to CXL.mem region provisioning requests. Note1: cxlpci.h has long depended on pci.h, but port.c was the first to not include pci.h. Carry that dependency in cxlpci.h. Note2: cxl port enumeration and probing complicates CXL subsystem init to the point that it helps to have centralized debug logging of probe events in cxl_bus_probe(). Reported-by: kernel test robot Signed-off-by: Ben Widawsky Reviewed-by: Jonathan Cameron Co-developed-by: Dan Williams Link: https://lore.kernel.org/r/164374948116.464348.1772618057599155408.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/driver-api/cxl/memory-devices.rst | 302 ++++++++++++++++++++++++ 1 file changed, 302 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index c8f7a16cd0e3..3498d38d7cbd 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -14,6 +14,303 @@ that optionally define a device's contribution to an interleaved address range across multiple devices underneath a host-bridge or interleaved across host-bridges. +CXL Bus: Theory of Operation +============================ +Similar to how a RAID driver takes disk objects and assembles them into a new +logical device, the CXL subsystem is tasked to take PCIe and ACPI objects and +assemble them into a CXL.mem decode topology. The need for runtime configuration +of the CXL.mem topology is also similar to RAID in that different environments +with the same hardware configuration may decide to assemble the topology in +contrasting ways. One may choose performance (RAID0) striping memory across +multiple Host Bridges and endpoints while another may opt for fault tolerance +and disable any striping in the CXL.mem topology. + +Platform firmware enumerates a menu of interleave options at the "CXL root port" +(Linux term for the top of the CXL decode topology). From there, PCIe topology +dictates which endpoints can participate in which Host Bridge decode regimes. +Each PCIe Switch in the path between the root and an endpoint introduces a point +at which the interleave can be split. For example platform firmware may say at a +given range only decodes to 1 one Host Bridge, but that Host Bridge may in turn +interleave cycles across multiple Root Ports. An intervening Switch between a +port and an endpoint may interleave cycles across multiple Downstream Switch +Ports, etc. + +Here is a sample listing of a CXL topology defined by 'cxl_test'. The 'cxl_test' +module generates an emulated CXL topology of 2 Host Bridges each with 2 Root +Ports. Each of those Root Ports are connected to 2-way switches with endpoints +connected to those downstream ports for a total of 8 endpoints:: + + # cxl list -BEMPu -b cxl_test + { + "bus":"root3", + "provider":"cxl_test", + "ports:root3":[ + { + "port":"port5", + "host":"cxl_host_bridge.1", + "ports:port5":[ + { + "port":"port8", + "host":"cxl_switch_uport.1", + "endpoints:port8":[ + { + "endpoint":"endpoint9", + "host":"mem2", + "memdev":{ + "memdev":"mem2", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x1", + "numa_node":1, + "host":"cxl_mem.1" + } + }, + { + "endpoint":"endpoint15", + "host":"mem6", + "memdev":{ + "memdev":"mem6", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x5", + "numa_node":1, + "host":"cxl_mem.5" + } + } + ] + }, + { + "port":"port12", + "host":"cxl_switch_uport.3", + "endpoints:port12":[ + { + "endpoint":"endpoint17", + "host":"mem8", + "memdev":{ + "memdev":"mem8", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x7", + "numa_node":1, + "host":"cxl_mem.7" + } + }, + { + "endpoint":"endpoint13", + "host":"mem4", + "memdev":{ + "memdev":"mem4", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x3", + "numa_node":1, + "host":"cxl_mem.3" + } + } + ] + } + ] + }, + { + "port":"port4", + "host":"cxl_host_bridge.0", + "ports:port4":[ + { + "port":"port6", + "host":"cxl_switch_uport.0", + "endpoints:port6":[ + { + "endpoint":"endpoint7", + "host":"mem1", + "memdev":{ + "memdev":"mem1", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0", + "numa_node":0, + "host":"cxl_mem.0" + } + }, + { + "endpoint":"endpoint14", + "host":"mem5", + "memdev":{ + "memdev":"mem5", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x4", + "numa_node":0, + "host":"cxl_mem.4" + } + } + ] + }, + { + "port":"port10", + "host":"cxl_switch_uport.2", + "endpoints:port10":[ + { + "endpoint":"endpoint16", + "host":"mem7", + "memdev":{ + "memdev":"mem7", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x6", + "numa_node":0, + "host":"cxl_mem.6" + } + }, + { + "endpoint":"endpoint11", + "host":"mem3", + "memdev":{ + "memdev":"mem3", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x2", + "numa_node":0, + "host":"cxl_mem.2" + } + } + ] + } + ] + } + ] + } + +In that listing each "root", "port", and "endpoint" object correspond a kernel +'struct cxl_port' object. A 'cxl_port' is a device that can decode CXL.mem to +its descendants. So "root" claims non-PCIe enumerable platform decode ranges and +decodes them to "ports", "ports" decode to "endpoints", and "endpoints" +represent the decode from SPA (System Physical Address) to DPA (Device Physical +Address). + +Continuing the RAID analogy, disks have both topology metadata and on device +metadata that determine RAID set assembly. CXL Port topology and CXL Port link +status is metadata for CXL.mem set assembly. The CXL Port topology is enumerated +by the arrival of a CXL.mem device. I.e. unless and until the PCIe core attaches +the cxl_pci driver to a CXL Memory Expander there is no role for CXL Port +objects. Conversely for hot-unplug / removal scenarios, there is no need for +the Linux PCI core to tear down switch-level CXL resources because the endpoint +->remove() event cleans up the port data that was established to support that +Memory Expander. + +The port metadata and potential decode schemes that a give memory device may +participate can be determined via a command like:: + + # cxl list -BDMu -d root -m mem3 + { + "bus":"root3", + "provider":"cxl_test", + "decoders:root3":[ + { + "decoder":"decoder3.1", + "resource":"0x8030000000", + "size":"512.00 MiB (536.87 MB)", + "volatile_capable":true, + "nr_targets":2 + }, + { + "decoder":"decoder3.3", + "resource":"0x8060000000", + "size":"512.00 MiB (536.87 MB)", + "pmem_capable":true, + "nr_targets":2 + }, + { + "decoder":"decoder3.0", + "resource":"0x8020000000", + "size":"256.00 MiB (268.44 MB)", + "volatile_capable":true, + "nr_targets":1 + }, + { + "decoder":"decoder3.2", + "resource":"0x8050000000", + "size":"256.00 MiB (268.44 MB)", + "pmem_capable":true, + "nr_targets":1 + } + ], + "memdevs:root3":[ + { + "memdev":"mem3", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x2", + "numa_node":0, + "host":"cxl_mem.2" + } + ] + } + +...which queries the CXL topology to ask "given CXL Memory Expander with a kernel +device name of 'mem3' which platform level decode ranges may this device +participate". A given expander can participate in multiple CXL.mem interleave +sets simultaneously depending on how many decoder resource it has. In this +example mem3 can participate in one or more of a PMEM interleave that spans to +Host Bridges, a PMEM interleave that targets a single Host Bridge, a Volatile +memory interleave that spans 2 Host Bridges, and a Volatile memory interleave +that only targets a single Host Bridge. + +Conversely the memory devices that can participate in a given platform level +decode scheme can be determined via a command like the following:: + + # cxl list -MDu -d 3.2 + [ + { + "memdevs":[ + { + "memdev":"mem1", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0", + "numa_node":0, + "host":"cxl_mem.0" + }, + { + "memdev":"mem5", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x4", + "numa_node":0, + "host":"cxl_mem.4" + }, + { + "memdev":"mem7", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x6", + "numa_node":0, + "host":"cxl_mem.6" + }, + { + "memdev":"mem3", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x2", + "numa_node":0, + "host":"cxl_mem.2" + } + ] + }, + { + "root decoders":[ + { + "decoder":"decoder3.2", + "resource":"0x8050000000", + "size":"256.00 MiB (268.44 MB)", + "pmem_capable":true, + "nr_targets":1 + } + ] + } + ] + +...where the naming scheme for decoders is "decoder.". + Driver Infrastructure ===================== @@ -28,6 +325,11 @@ CXL Memory Device .. kernel-doc:: drivers/cxl/pci.c :internal: +CXL Port +-------- +.. kernel-doc:: drivers/cxl/port.c + :doc: cxl port + CXL Core -------- .. kernel-doc:: drivers/cxl/cxl.h -- cgit From bcc79ea34398845d814170ddc06a457b35ae1975 Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Mon, 31 Jan 2022 13:56:11 -0800 Subject: cxl/pci: Emit device serial number Per the CXL specification (8.1.12.2 Memory Device PCIe Capabilities and Extended Capabilities) the Device Serial Number capability is mandatory. Emit it for user tooling to identify devices. It is reasonable to ask whether the attribute should be added to the list of PCI sysfs device attributes. The PCI layer can optionally emit it too, but the CXL subsystem is aiming to preserve its independence and the possibility of CXL topologies with non-PCI devices in it. To date that has only proven useful for the 'cxl_test' model, but as can be seen with seen with ACPI0016 devices, sometimes all that is needed is a platform firmware table to point to CXL Component Registers in MMIO space to define a "CXL" device. Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/164366608838.196598.16856227191534267098.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/ABI/testing/sysfs-bus-cxl | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 6d8cbf3355b5..87c0e5e65322 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -25,6 +25,15 @@ Description: identically named field in the Identify Memory Device Output Payload in the CXL-2.0 specification. +What: /sys/bus/cxl/devices/memX/serial +Date: January, 2022 +KernelVersion: v5.18 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) 64-bit serial number per the PCIe Device Serial Number + capability. Mandatory for CXL devices, see CXL 2.0 8.1.12.2 + Memory Device PCIe Capabilities and Extended Capabilities. + What: /sys/bus/cxl/devices/*/devtype Date: June, 2021 KernelVersion: v5.14 -- cgit From cf1f6877b088cd9ddeb5f3db8ade3a61e3a3f9eb Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Sun, 23 Jan 2022 16:31:24 -0800 Subject: cxl/memdev: Add numa_node attribute While CXL memory targets will have their own memory target node, individual memory devices may be affinitized like other PCI devices. Emit that attribute for memdevs. Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/164298428430.3018233.16409089892707993289.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/ABI/testing/sysfs-bus-cxl | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 87c0e5e65322..0b51cfec0c66 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -34,6 +34,15 @@ Description: capability. Mandatory for CXL devices, see CXL 2.0 8.1.12.2 Memory Device PCIe Capabilities and Extended Capabilities. +What: /sys/bus/cxl/devices/memX/numa_node +Date: January, 2022 +KernelVersion: v5.18 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) If NUMA is enabled and the platform has affinitized the + host PCI device for this memory device, emit the CPU node + affinity for this device. + What: /sys/bus/cxl/devices/*/devtype Date: June, 2021 KernelVersion: v5.14 -- cgit From 8dd2bc0f8e02d39bd80851ca787bcbdb7d495e69 Mon Sep 17 00:00:00 2001 From: Ben Widawsky Date: Fri, 4 Feb 2022 07:18:31 -0800 Subject: cxl/mem: Add the cxl_mem driver At this point the subsystem can enumerate all CXL ports (CXL.mem decode resources in upstream switch ports and host bridges) in a system. The last mile is connecting those ports to endpoints. The cxl_mem driver connects an endpoint device to the platform CXL.mem protoctol decode-topology. At ->probe() time it walks its device-topology-ancestry and adds a CXL Port object at every Upstream Port hop until it gets to CXL root. The CXL root object is only present after a platform firmware driver registers platform CXL resources. For ACPI based platform this is managed by the ACPI0017 device and the cxl_acpi driver. The ports are registered such that disabling a given port automatically unregisters all descendant ports, and the chain can only be registered after the root is established. Given ACPI device scanning may run asynchronously compared to PCI device scanning the root driver is tasked with rescanning the bus after the root successfully probes. Conversely if any ports in a chain between the root and an endpoint becomes disconnected it subsequently triggers the endpoint to unregister. Given lock depenedencies the endpoint unregistration happens in a workqueue asynchronously. If userspace cares about synchronizing delayed work after port events the /sys/bus/cxl/flush attribute is available for that purpose. Reported-by: Randy Dunlap Signed-off-by: Ben Widawsky Reviewed-by: Jonathan Cameron [djbw: clarify changelog, rework hotplug support] Link: https://lore.kernel.org/r/164398782997.903003.9725273241627693186.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/ABI/testing/sysfs-bus-cxl | 9 +++++++++ Documentation/driver-api/cxl/memory-devices.rst | 9 +++++++++ 2 files changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 0b51cfec0c66..7c2b846521f3 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -1,3 +1,12 @@ +What: /sys/bus/cxl/flush +Date: Januarry, 2022 +KernelVersion: v5.18 +Contact: linux-cxl@vger.kernel.org +Description: + (WO) If userspace manually unbinds a port the kernel schedules + all descendant memdevs for unbind. Writing '1' to this attribute + flushes that work. + What: /sys/bus/cxl/devices/memX/firmware_version Date: December, 2020 KernelVersion: v5.12 diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index 3498d38d7cbd..db476bb170b6 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -325,6 +325,9 @@ CXL Memory Device .. kernel-doc:: drivers/cxl/pci.c :internal: +.. kernel-doc:: drivers/cxl/mem.c + :doc: cxl mem + CXL Port -------- .. kernel-doc:: drivers/cxl/port.c @@ -344,6 +347,12 @@ CXL Core .. kernel-doc:: drivers/cxl/core/port.c :identifiers: +.. kernel-doc:: drivers/cxl/core/pci.c + :doc: cxl core pci + +.. kernel-doc:: drivers/cxl/core/pci.c + :identifiers: + .. kernel-doc:: drivers/cxl/core/pmem.c :doc: cxl pmem -- cgit From 612e5d847f7dd1743e04f7a92d26d7c79e3151e2 Mon Sep 17 00:00:00 2001 From: Iwona Winiarska Date: Tue, 8 Feb 2022 16:36:27 +0100 Subject: dt-bindings: Add generic bindings for PECI Add device tree bindings for the PECI controller. Reviewed-by: Rob Herring Reviewed-by: Joel Stanley Acked-by: Joel Stanley Signed-off-by: Iwona Winiarska Link: https://lore.kernel.org/r/20220208153639.255278-2-iwona.winiarska@intel.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/peci/peci-controller.yaml | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/peci/peci-controller.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/peci/peci-controller.yaml b/Documentation/devicetree/bindings/peci/peci-controller.yaml new file mode 100644 index 000000000000..bbc3d3f3a929 --- /dev/null +++ b/Documentation/devicetree/bindings/peci/peci-controller.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/peci/peci-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic Device Tree Bindings for PECI + +maintainers: + - Iwona Winiarska + +description: + PECI (Platform Environment Control Interface) is an interface that provides a + communication channel from Intel processors and chipset components to external + monitoring or control devices. + +properties: + $nodename: + pattern: "^peci-controller(@.*)?$" + + cmd-timeout-ms: + description: + Command timeout in units of ms. + +additionalProperties: true + +examples: + - | + peci-controller@1e78b000 { + reg = <0x1e78b000 0x100>; + cmd-timeout-ms = <500>; + }; +... -- cgit From 0af618d68d6a7771a7c2b3a9de13d11ee34e8b5f Mon Sep 17 00:00:00 2001 From: Iwona Winiarska Date: Tue, 8 Feb 2022 16:36:28 +0100 Subject: dt-bindings: Add bindings for peci-aspeed Add device tree bindings for the peci-aspeed controller driver. Co-developed-by: Jae Hyun Yoo Reviewed-by: Joel Stanley Reviewed-by: Rob Herring Acked-by: Joel Stanley Signed-off-by: Jae Hyun Yoo Signed-off-by: Iwona Winiarska Link: https://lore.kernel.org/r/20220208153639.255278-3-iwona.winiarska@intel.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/peci/peci-aspeed.yaml | 72 ++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 Documentation/devicetree/bindings/peci/peci-aspeed.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/peci/peci-aspeed.yaml b/Documentation/devicetree/bindings/peci/peci-aspeed.yaml new file mode 100644 index 000000000000..1e68a801a92a --- /dev/null +++ b/Documentation/devicetree/bindings/peci/peci-aspeed.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/peci/peci-aspeed.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Aspeed PECI Bus Device Tree Bindings + +maintainers: + - Iwona Winiarska + - Jae Hyun Yoo + +allOf: + - $ref: peci-controller.yaml# + +properties: + compatible: + enum: + - aspeed,ast2400-peci + - aspeed,ast2500-peci + - aspeed,ast2600-peci + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + description: + Clock source for PECI controller. Should reference the external + oscillator clock. + maxItems: 1 + + resets: + maxItems: 1 + + cmd-timeout-ms: + minimum: 1 + maximum: 1000 + default: 1000 + + clock-frequency: + description: + The desired operation frequency of PECI controller in Hz. + minimum: 2000 + maximum: 2000000 + default: 1000000 + +required: + - compatible + - reg + - interrupts + - clocks + - resets + +additionalProperties: false + +examples: + - | + #include + #include + peci-controller@1e78b000 { + compatible = "aspeed,ast2600-peci"; + reg = <0x1e78b000 0x100>; + interrupts = ; + clocks = <&syscon ASPEED_CLK_GATE_REF0CLK>; + resets = <&syscon ASPEED_RESET_PECI>; + cmd-timeout-ms = <1000>; + clock-frequency = <1000000>; + }; +... -- cgit From 42bed52b2e9cda0d5e2de50f10478c0bcedcdb95 Mon Sep 17 00:00:00 2001 From: Iwona Winiarska Date: Tue, 8 Feb 2022 16:36:33 +0100 Subject: peci: Add sysfs interface for PECI bus PECI devices may not be discoverable at the time when PECI controller is being added (e.g. BMC can boot up when the Host system is still in S5). Since we currently don't have the capabilities to figure out the Host system state inside the PECI subsystem itself, we have to rely on userspace to do it for us. In the future, PECI subsystem may be expanded with mechanisms that allow us to avoid depending on userspace interaction (e.g. CPU presence could be detected using GPIO, and the information on whether it's discoverable could be obtained over IPMI). Unfortunately, those methods may ultimately not be available (support will vary from platform to platform), which means that we still need platform independent method triggered by userspace. Acked-by: Joel Stanley Signed-off-by: Iwona Winiarska Link: https://lore.kernel.org/r/20220208153639.255278-8-iwona.winiarska@intel.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-bus-peci | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-peci (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-peci b/Documentation/ABI/testing/sysfs-bus-peci new file mode 100644 index 000000000000..87454ec5d981 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-peci @@ -0,0 +1,16 @@ +What: /sys/bus/peci/rescan +Date: July 2021 +KernelVersion: 5.18 +Contact: Iwona Winiarska +Description: + Writing a non-zero value to this attribute will + initiate scan for PECI devices on all PECI controllers + in the system. + +What: /sys/bus/peci/devices/-/remove +Date: July 2021 +KernelVersion: 5.18 +Contact: Iwona Winiarska +Description: + Writing a non-zero value to this attribute will + remove the PECI device and any of its children. -- cgit From bdcfb955acc94a367b4dc6fbb19acc87ecda8dd6 Mon Sep 17 00:00:00 2001 From: Jae Hyun Yoo Date: Tue, 8 Feb 2022 16:36:38 +0100 Subject: docs: hwmon: Document PECI drivers Add documentation for peci-cputemp driver that provides DTS thermal readings for CPU packages and CPU cores, and peci-dimmtemp driver that provides Temperature Sensor on DIMM readings. Co-developed-by: Iwona Winiarska Reviewed-by: Pierre-Louis Bossart Acked-by: Guenter Roeck Acked-by: Joel Stanley Signed-off-by: Jae Hyun Yoo Signed-off-by: Iwona Winiarska Link: https://lore.kernel.org/r/20220208153639.255278-13-iwona.winiarska@intel.com Signed-off-by: Greg Kroah-Hartman --- Documentation/hwmon/index.rst | 2 + Documentation/hwmon/peci-cputemp.rst | 90 +++++++++++++++++++++++++++++++++++ Documentation/hwmon/peci-dimmtemp.rst | 57 ++++++++++++++++++++++ 3 files changed, 149 insertions(+) create mode 100644 Documentation/hwmon/peci-cputemp.rst create mode 100644 Documentation/hwmon/peci-dimmtemp.rst (limited to 'Documentation') diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index df20022c741f..f387f661e1d7 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -161,6 +161,8 @@ Hardware Monitoring Kernel Drivers pcf8591 pim4328 pm6764tr + peci-cputemp + peci-dimmtemp pmbus powr1220 pxe1610 diff --git a/Documentation/hwmon/peci-cputemp.rst b/Documentation/hwmon/peci-cputemp.rst new file mode 100644 index 000000000000..fe0422248dc5 --- /dev/null +++ b/Documentation/hwmon/peci-cputemp.rst @@ -0,0 +1,90 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +Kernel driver peci-cputemp +========================== + +Supported chips: + One of Intel server CPUs listed below which is connected to a PECI bus. + * Intel Xeon E5/E7 v3 server processors + Intel Xeon E5-14xx v3 family + Intel Xeon E5-24xx v3 family + Intel Xeon E5-16xx v3 family + Intel Xeon E5-26xx v3 family + Intel Xeon E5-46xx v3 family + Intel Xeon E7-48xx v3 family + Intel Xeon E7-88xx v3 family + * Intel Xeon E5/E7 v4 server processors + Intel Xeon E5-16xx v4 family + Intel Xeon E5-26xx v4 family + Intel Xeon E5-46xx v4 family + Intel Xeon E7-48xx v4 family + Intel Xeon E7-88xx v4 family + * Intel Xeon Scalable server processors + Intel Xeon D family + Intel Xeon Bronze family + Intel Xeon Silver family + Intel Xeon Gold family + Intel Xeon Platinum family + + Datasheet: Available from http://www.intel.com/design/literature.htm + +Author: Jae Hyun Yoo + +Description +----------- + +This driver implements a generic PECI hwmon feature which provides Digital +Thermal Sensor (DTS) thermal readings of the CPU package and CPU cores that are +accessible via the processor PECI interface. + +All temperature values are given in millidegree Celsius and will be measurable +only when the target CPU is powered on. + +Sysfs interface +------------------- + +======================= ======================================================= +temp1_label "Die" +temp1_input Provides current die temperature of the CPU package. +temp1_max Provides thermal control temperature of the CPU package + which is also known as Tcontrol. +temp1_crit Provides shutdown temperature of the CPU package which + is also known as the maximum processor junction + temperature, Tjmax or Tprochot. +temp1_crit_hyst Provides the hysteresis value from Tcontrol to Tjmax of + the CPU package. + +temp2_label "DTS" +temp2_input Provides current temperature of the CPU package scaled + to match DTS thermal profile. +temp2_max Provides thermal control temperature of the CPU package + which is also known as Tcontrol. +temp2_crit Provides shutdown temperature of the CPU package which + is also known as the maximum processor junction + temperature, Tjmax or Tprochot. +temp2_crit_hyst Provides the hysteresis value from Tcontrol to Tjmax of + the CPU package. + +temp3_label "Tcontrol" +temp3_input Provides current Tcontrol temperature of the CPU + package which is also known as Fan Temperature target. + Indicates the relative value from thermal monitor trip + temperature at which fans should be engaged. +temp3_crit Provides Tcontrol critical value of the CPU package + which is same to Tjmax. + +temp4_label "Tthrottle" +temp4_input Provides current Tthrottle temperature of the CPU + package. Used for throttling temperature. If this value + is allowed and lower than Tjmax - the throttle will + occur and reported at lower than Tjmax. + +temp5_label "Tjmax" +temp5_input Provides the maximum junction temperature, Tjmax of the + CPU package. + +temp[6-N]_label Provides string "Core X", where X is resolved core + number. +temp[6-N]_input Provides current temperature of each core. + +======================= ======================================================= diff --git a/Documentation/hwmon/peci-dimmtemp.rst b/Documentation/hwmon/peci-dimmtemp.rst new file mode 100644 index 000000000000..e562aed620de --- /dev/null +++ b/Documentation/hwmon/peci-dimmtemp.rst @@ -0,0 +1,57 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver peci-dimmtemp +=========================== + +Supported chips: + One of Intel server CPUs listed below which is connected to a PECI bus. + * Intel Xeon E5/E7 v3 server processors + Intel Xeon E5-14xx v3 family + Intel Xeon E5-24xx v3 family + Intel Xeon E5-16xx v3 family + Intel Xeon E5-26xx v3 family + Intel Xeon E5-46xx v3 family + Intel Xeon E7-48xx v3 family + Intel Xeon E7-88xx v3 family + * Intel Xeon E5/E7 v4 server processors + Intel Xeon E5-16xx v4 family + Intel Xeon E5-26xx v4 family + Intel Xeon E5-46xx v4 family + Intel Xeon E7-48xx v4 family + Intel Xeon E7-88xx v4 family + * Intel Xeon Scalable server processors + Intel Xeon D family + Intel Xeon Bronze family + Intel Xeon Silver family + Intel Xeon Gold family + Intel Xeon Platinum family + + Datasheet: Available from http://www.intel.com/design/literature.htm + +Author: Jae Hyun Yoo + +Description +----------- + +This driver implements a generic PECI hwmon feature which provides +Temperature sensor on DIMM readings that are accessible via the processor PECI interface. + +All temperature values are given in millidegree Celsius and will be measurable +only when the target CPU is powered on. + +Sysfs interface +------------------- + +======================= ======================================================= + +temp[N]_label Provides string "DIMM CI", where C is DIMM channel and + I is DIMM index of the populated DIMM. +temp[N]_input Provides current temperature of the populated DIMM. +temp[N]_max Provides thermal control temperature of the DIMM. +temp[N]_crit Provides shutdown temperature of the DIMM. + +======================= ======================================================= + +Note: + DIMM temperature attributes will appear when the client CPU's BIOS + completes memory training and testing. -- cgit From 0580565dd717cb135633ebdbc1d84fe6b0a3fa78 Mon Sep 17 00:00:00 2001 From: Iwona Winiarska Date: Tue, 8 Feb 2022 16:36:39 +0100 Subject: docs: Add PECI documentation Add a brief overview of PECI and PECI wire interface. The documentation also contains kernel-doc for PECI subsystem internals and PECI CPU Driver API. Reviewed-by: Pierre-Louis Bossart Acked-by: Joel Stanley Signed-off-by: Iwona Winiarska Link: https://lore.kernel.org/r/20220208153639.255278-14-iwona.winiarska@intel.com Signed-off-by: Greg Kroah-Hartman --- Documentation/index.rst | 1 + Documentation/peci/index.rst | 16 ++++++++++++++ Documentation/peci/peci.rst | 51 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 68 insertions(+) create mode 100644 Documentation/peci/index.rst create mode 100644 Documentation/peci/peci.rst (limited to 'Documentation') diff --git a/Documentation/index.rst b/Documentation/index.rst index b58692d687f6..1988c19d9daf 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -138,6 +138,7 @@ needed). scheduler/index mhi/index tty/index + peci/index Architecture-agnostic documentation ----------------------------------- diff --git a/Documentation/peci/index.rst b/Documentation/peci/index.rst new file mode 100644 index 000000000000..989de10416e7 --- /dev/null +++ b/Documentation/peci/index.rst @@ -0,0 +1,16 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +==================== +Linux PECI Subsystem +==================== + +.. toctree:: + + peci + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/peci/peci.rst b/Documentation/peci/peci.rst new file mode 100644 index 000000000000..331b1ec00e22 --- /dev/null +++ b/Documentation/peci/peci.rst @@ -0,0 +1,51 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +======== +Overview +======== + +The Platform Environment Control Interface (PECI) is a communication +interface between Intel processor and management controllers +(e.g. Baseboard Management Controller, BMC). +PECI provides services that allow the management controller to +configure, monitor and debug platform by accessing various registers. +It defines a dedicated command protocol, where the management +controller is acting as a PECI originator and the processor - as +a PECI responder. +PECI can be used in both single processor and multiple-processor based +systems. + +NOTE: +Intel PECI specification is not released as a dedicated document, +instead it is a part of External Design Specification (EDS) for given +Intel CPU. External Design Specifications are usually not publicly +available. + +PECI Wire +--------- + +PECI Wire interface uses a single wire for self-clocking and data +transfer. It does not require any additional control lines - the +physical layer is a self-clocked one-wire bus signal that begins each +bit with a driven, rising edge from an idle near zero volts. The +duration of the signal driven high allows to determine whether the bit +value is logic '0' or logic '1'. PECI Wire also includes variable data +rate established with every message. + +For PECI Wire, each processor package will utilize unique, fixed +addresses within a defined range and that address should +have a fixed relationship with the processor socket ID - if one of the +processors is removed, it does not affect addresses of remaining +processors. + +PECI subsystem internals +------------------------ + +.. kernel-doc:: include/linux/peci.h +.. kernel-doc:: drivers/peci/internal.h +.. kernel-doc:: drivers/peci/core.c +.. kernel-doc:: drivers/peci/request.c + +PECI CPU Driver API +------------------- +.. kernel-doc:: drivers/peci/cpu.c -- cgit From dec09a4dc165bb034830337f7fb4ed489d418b35 Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Wed, 9 Feb 2022 08:52:58 +0000 Subject: dt-bindings: gpio: convert faraday,ftgpio01 to yaml Converts gpio/faraday,ftgpio010.txt to yaml. Reviewed-by: Linus Walleij Reviewed-by: Rob Herring Signed-off-by: Corentin Labbe Signed-off-by: Bartosz Golaszewski --- .../devicetree/bindings/gpio/faraday,ftgpio010.txt | 27 --------- .../bindings/gpio/faraday,ftgpio010.yaml | 65 ++++++++++++++++++++++ 2 files changed, 65 insertions(+), 27 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/faraday,ftgpio010.txt create mode 100644 Documentation/devicetree/bindings/gpio/faraday,ftgpio010.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.txt b/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.txt deleted file mode 100644 index d04236558619..000000000000 --- a/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.txt +++ /dev/null @@ -1,27 +0,0 @@ -Faraday Technology FTGPIO010 GPIO Controller - -Required properties: - -- compatible : Should be one of - "cortina,gemini-gpio", "faraday,ftgpio010" - "moxa,moxart-gpio", "faraday,ftgpio010" - "faraday,ftgpio010" -- reg : Should contain registers location and length -- interrupts : Should contain the interrupt line for the GPIO block -- gpio-controller : marks this as a GPIO controller -- #gpio-cells : Should be 2, see gpio/gpio.txt -- interrupt-controller : marks this as an interrupt controller -- #interrupt-cells : a standard two-cell interrupt flag, see - interrupt-controller/interrupts.txt - -Example: - -gpio@4d000000 { - compatible = "cortina,gemini-gpio", "faraday,ftgpio010"; - reg = <0x4d000000 0x100>; - interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; -}; diff --git a/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.yaml b/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.yaml new file mode 100644 index 000000000000..640da5b9b0cc --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/faraday,ftgpio010.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Faraday Technology FTGPIO010 GPIO Controller + +maintainers: + - Linus Walleij + +properties: + compatible: + oneOf: + - items: + - const: cortina,gemini-gpio + - const: faraday,ftgpio010 + - items: + - const: moxa,moxart-gpio + - const: faraday,ftgpio010 + - const: faraday,ftgpio010 + + reg: + maxItems: 1 + + resets: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + description: Should contain the interrupt line for the GPIO block + + gpio-controller: true + "#gpio-cells": + const: 2 + + interrupt-controller: true + "#interrupt-cells": + const: 2 + +required: + - compatible + - reg + - interrupts + - "#gpio-cells" + - interrupt-controller + - "#interrupt-cells" + +additionalProperties: false + +examples: + - | + #include + gpio@4d000000 { + compatible = "cortina,gemini-gpio", "faraday,ftgpio010"; + reg = <0x4d000000 0x100>; + interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; -- cgit From 654f89f9496db716c4e9a79c3c6193d57cfaa963 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Sun, 6 Feb 2022 20:24:24 +0000 Subject: dt-bindings: net: renesas,etheravb: Document RZ/V2L SoC Document Gigabit Ethernet IP found on RZ/V2L SoC. Gigabit Ethernet Interface is identical to one found on the RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,rzg2l-gbeth" will be used as a fallback. Signed-off-by: Biju Das Signed-off-by: Lad Prabhakar Acked-by: Rob Herring Reviewed-by: Geert Uytterhoeven Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/renesas,etheravb.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml index bda821065a2b..db0ad6fbad89 100644 --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml @@ -46,7 +46,8 @@ properties: - items: - enum: - renesas,r9a07g044-gbeth # RZ/G2{L,LC} - - const: renesas,rzg2l-gbeth # RZ/G2L + - renesas,r9a07g054-gbeth # RZ/V2L + - const: renesas,rzg2l-gbeth # RZ/{G2L,V2L} family reg: true -- cgit From 5e2e8cc9dd3314e2cf2814d19d0aaa4c983b1d3d Mon Sep 17 00:00:00 2001 From: Biju Das Date: Sun, 6 Feb 2022 20:24:25 +0000 Subject: dt-bindings: net: renesas,etheravb: Document RZ/G2UL SoC Document Gigabit Ethernet IP found on RZ/G2UL SoC. Gigabit Ethernet Interface is identical to one found on the RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,rzg2l-gbeth" will be used as a fallback. Signed-off-by: Biju Das Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/renesas,etheravb.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml index db0ad6fbad89..ee2ccacc39ff 100644 --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml @@ -45,9 +45,10 @@ properties: - items: - enum: + - renesas,r9a07g043-gbeth # RZ/G2UL - renesas,r9a07g044-gbeth # RZ/G2{L,LC} - renesas,r9a07g054-gbeth # RZ/V2L - - const: renesas,rzg2l-gbeth # RZ/{G2L,V2L} family + - const: renesas,rzg2l-gbeth # RZ/{G2L,G2UL,V2L} family reg: true -- cgit From 63ed1aab3d40aa61aaa66819bdce9377ac7f40fa Mon Sep 17 00:00:00 2001 From: Matt Johnston Date: Wed, 9 Feb 2022 12:05:57 +0800 Subject: mctp: Add SIOCMCTP{ALLOC,DROP}TAG ioctls for tag control This change adds a couple of new ioctls for mctp sockets: SIOCMCTPALLOCTAG and SIOCMCTPDROPTAG. These ioctls provide facilities for explicit allocation / release of tags, overriding the automatic allocate-on-send/release-on-reply and timeout behaviours. This allows userspace more control over messages that may not fit a simple request/response model. In order to indicate a pre-allocated tag to the sendmsg() syscall, we introduce a new flag to the struct sockaddr_mctp.smctp_tag value: MCTP_TAG_PREALLOC. Additional changes from Jeremy Kerr . Contains a fix that was: Reported-by: kernel test robot Signed-off-by: Matt Johnston Signed-off-by: Jeremy Kerr Signed-off-by: David S. Miller --- Documentation/networking/mctp.rst | 48 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/mctp.rst b/Documentation/networking/mctp.rst index 46f74bffce0f..c628cb5406d2 100644 --- a/Documentation/networking/mctp.rst +++ b/Documentation/networking/mctp.rst @@ -212,6 +212,54 @@ remote address is already known, or the message does not require a reply. Like the send calls, sockets will only receive responses to requests they have sent (TO=1) and may only respond (TO=0) to requests they have received. +``ioctl(SIOCMCTPALLOCTAG)`` and ``ioctl(SIOCMCTPDROPTAG)`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +These tags give applications more control over MCTP message tags, by allocating +(and dropping) tag values explicitly, rather than the kernel automatically +allocating a per-message tag at ``sendmsg()`` time. + +In general, you will only need to use these ioctls if your MCTP protocol does +not fit the usual request/response model. For example, if you need to persist +tags across multiple requests, or a request may generate more than one response. +In these cases, the ioctls allow you to decouple the tag allocation (and +release) from individual message send and receive operations. + +Both ioctls are passed a pointer to a ``struct mctp_ioc_tag_ctl``: + +.. code-block:: C + + struct mctp_ioc_tag_ctl { + mctp_eid_t peer_addr; + __u8 tag; + __u16 flags; + }; + +``SIOCMCTPALLOCTAG`` allocates a tag for a specific peer, which an application +can use in future ``sendmsg()`` calls. The application populates the +``peer_addr`` member with the remote EID. Other fields must be zero. + +On return, the ``tag`` member will be populated with the allocated tag value. +The allocated tag will have the following tag bits set: + + - ``MCTP_TAG_OWNER``: it only makes sense to allocate tags if you're the tag + owner + + - ``MCTP_TAG_PREALLOC``: to indicate to ``sendmsg()`` that this is a + preallocated tag. + + - ... and the actual tag value, within the least-significant three bits + (``MCTP_TAG_MASK``). Note that zero is a valid tag value. + +The tag value should be used as-is for the ``smctp_tag`` member of ``struct +sockaddr_mctp``. + +``SIOCMCTPDROPTAG`` releases a tag that has been previously allocated by a +``SIOCMCTPALLOCTAG`` ioctl. The ``peer_addr`` must be the same as used for the +allocation, and the ``tag`` value must match exactly the tag returned from the +allocation (including the ``MCTP_TAG_OWNER`` and ``MCTP_TAG_PREALLOC`` bits). +The ``flags`` field must be zero. + Kernel internals ================ -- cgit From d335092933079e0a48c61ea5791906d040105a4d Mon Sep 17 00:00:00 2001 From: Alexandre Torgue Date: Wed, 2 Feb 2022 15:00:03 +0100 Subject: dt-bindings: interrupt-controller: stm32-exti: document st,stm32mp13-exti Support of STM32MP13 SoC implies to create a new compatible in order to manage EXTI/GIC mapping changes. Signed-off-by: Alexandre Torgue Acked-by: Rob Herring Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220202140005.860-2-alexandre.torgue@foss.st.com --- .../devicetree/bindings/interrupt-controller/st,stm32-exti.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml index d19c881b4abc..e44daa09b137 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml @@ -20,6 +20,7 @@ properties: - items: - enum: - st,stm32mp1-exti + - st,stm32mp13-exti - const: syscon "#interrupt-cells": -- cgit From 425fd283e4a2b929a88483525fda3f90dde8a2d0 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 6 Feb 2022 14:58:00 +0100 Subject: dt-bindings: memory: lpddr2-timings: convert to dtschema Convert the LPDDR2 memory timings bindings to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Dmitry Osipenko Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220206135807.211767-2-krzysztof.kozlowski@canonical.com --- .../ddr/jedec,lpddr2-timings.yaml | 135 +++++++++++++++++++++ .../memory-controllers/ddr/jedec,lpddr2.yaml | 6 +- .../memory-controllers/ddr/lpddr2-timings.txt | 52 -------- 3 files changed, 137 insertions(+), 56 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2-timings.yaml delete mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2-timings.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2-timings.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2-timings.yaml new file mode 100644 index 000000000000..f3e62ee07126 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2-timings.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr2-timings.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LPDDR2 SDRAM AC timing parameters for a given speed-bin + +maintainers: + - Krzysztof Kozlowski + +properties: + compatible: + const: jedec,lpddr2-timings + + max-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Maximum DDR clock frequency for the speed-bin, in Hz. + + min-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Minimum DDR clock frequency for the speed-bin, in Hz. + + tCKESR: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + CKE minimum pulse width during SELF REFRESH (low pulse width during + SELF REFRESH) in pico seconds. + + tDQSCK-max: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + DQS output data access time from CK_t/CK_c in pico seconds. + + tDQSCK-max-derated: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + DQS output data access time from CK_t/CK_c, temperature de-rated, in pico + seconds. + + tFAW: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Four-bank activate window in pico seconds. + + tRAS-max-ns: + description: | + Row active time in nano seconds. + + tRAS-min: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Row active time in pico seconds. + + tRCD: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + RAS-to-CAS delay in pico seconds. + + tRPab: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Row precharge time (all banks) in pico seconds. + + tRRD: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Active bank A to active bank B in pico seconds. + + tRTP: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Internal READ to PRECHARGE command delay in pico seconds. + + tWR: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + WRITE recovery time in pico seconds. + + tWTR: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Internal WRITE-to-READ command delay in pico seconds. + + tXP: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Exit power-down to next valid command delay in pico seconds. + + tZQCL: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Long calibration time in pico seconds. + + tZQCS: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Short calibration time in pico seconds. + + tZQinit: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Initialization calibration time in pico seconds. + +required: + - compatible + - min-freq + - max-freq + +additionalProperties: false + +examples: + - | + timings { + compatible = "jedec,lpddr2-timings"; + min-freq = <10000000>; + max-freq = <400000000>; + tCKESR = <15000>; + tDQSCK-max = <5500>; + tFAW = <50000>; + tRAS-max-ns = <70000>; + tRAS-min = <42000>; + tRPab = <21000>; + tRCD = <18000>; + tRRD = <10000>; + tRTP = <7500>; + tWR = <15000>; + tWTR = <7500>; + tXP = <7500>; + tZQCL = <360000>; + tZQCS = <90000>; + tZQinit = <1000000>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml index 25ed0266f6dd..2d8a701e2a05 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml @@ -142,14 +142,12 @@ properties: patternProperties: "^lpddr2-timings": - type: object + $ref: jedec,lpddr2-timings.yaml description: | The lpddr2 node may have one or more child nodes of type "lpddr2-timings". "lpddr2-timings" provides AC timing parameters of the device for a given speed-bin. The user may provide the timings for as many - speed-bins as is required. Please see Documentation/devicetree/ - bindings/memory-controllers/ddr/lpddr2-timings.txt for more information - on "lpddr2-timings". + speed-bins as is required. required: - compatible diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2-timings.txt b/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2-timings.txt deleted file mode 100644 index 9ceb19e0c7fd..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2-timings.txt +++ /dev/null @@ -1,52 +0,0 @@ -* AC timing parameters of LPDDR2(JESD209-2) memories for a given speed-bin - -Required properties: -- compatible : Should be "jedec,lpddr2-timings" -- min-freq : minimum DDR clock frequency for the speed-bin. Type is -- max-freq : maximum DDR clock frequency for the speed-bin. Type is - -Optional properties: - -The following properties represent AC timing parameters from the memory -data-sheet of the device for a given speed-bin. All these properties are -of type and the default unit is ps (pico seconds). Parameters with -a different unit have a suffix indicating the unit such as 'tRAS-max-ns' -- tRCD -- tWR -- tRAS-min -- tRRD -- tWTR -- tXP -- tRTP -- tDQSCK-max -- tFAW -- tZQCS -- tZQinit -- tRPab -- tZQCL -- tCKESR -- tRAS-max-ns -- tDQSCK-max-derated - -Example: - -timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 { - compatible = "jedec,lpddr2-timings"; - min-freq = <10000000>; - max-freq = <400000000>; - tRPab = <21000>; - tRCD = <18000>; - tWR = <15000>; - tRAS-min = <42000>; - tRRD = <10000>; - tWTR = <7500>; - tXP = <7500>; - tRTP = <7500>; - tCKESR = <15000>; - tDQSCK-max = <5500>; - tFAW = <50000>; - tZQCS = <90000>; - tZQCL = <360000>; - tZQinit = <1000000>; - tRAS-max-ns = <70000>; -}; -- cgit From 180a276c99bb861742c5c423d679b0277d4b1c26 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 6 Feb 2022 14:58:01 +0100 Subject: dt-bindings: memory: lpddr3-timings: convert to dtschema Convert the LPDDR3 memory timings bindings to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Dmitry Osipenko Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220206135807.211767-3-krzysztof.kozlowski@canonical.com --- .../ddr/jedec,lpddr3-timings.yaml | 153 +++++++++++++++++++++ .../memory-controllers/ddr/lpddr3-timings.txt | 58 -------- 2 files changed, 153 insertions(+), 58 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml delete mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3-timings.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml new file mode 100644 index 000000000000..98bc219e8a25 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml @@ -0,0 +1,153 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr3-timings.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LPDDR3 SDRAM AC timing parameters for a given speed-bin + +maintainers: + - Krzysztof Kozlowski + +properties: + compatible: + const: jedec,lpddr3-timings + + reg: + maxItems: 1 + description: | + Maximum DDR clock frequency for the speed-bin, in Hz. + + min-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Minimum DDR clock frequency for the speed-bin, in Hz. + + tCKE: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + CKE minimum pulse width (HIGH and LOW pulse width) in pico seconds. + + tCKESR: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + CKE minimum pulse width during SELF REFRESH (low pulse width during + SELF REFRESH) in pico seconds. + + tFAW: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Four-bank activate window in pico seconds. + + tMRD: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Mode register set command delay in pico seconds. + + tR2R-C2C: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Additional READ-to-READ delay in chip-to-chip cases in pico seconds. + + tRAS: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Row active time in pico seconds. + + tRC: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + ACTIVATE-to-ACTIVATE command period in pico seconds. + + tRCD: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + RAS-to-CAS delay in pico seconds. + + tRFC: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Refresh Cycle time in pico seconds. + + tRPab: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Row precharge time (all banks) in pico seconds. + + tRPpb: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Row precharge time (single banks) in pico seconds. + + tRRD: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Active bank A to active bank B in pico seconds. + + tRTP: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Internal READ to PRECHARGE command delay in pico seconds. + + tW2W-C2C: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Additional WRITE-to-WRITE delay in chip-to-chip cases in pico seconds. + + tWR: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + WRITE recovery time in pico seconds. + + tWTR: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Internal WRITE-to-READ command delay in pico seconds. + + tXP: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Exit power-down to next valid command delay in pico seconds. + + tXSR: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + SELF REFRESH exit to next valid command delay in pico seconds. + +required: + - compatible + - min-freq + - reg + +additionalProperties: false + +examples: + - | + lpddr3 { + #address-cells = <1>; + #size-cells = <0>; + + timings@800000000 { + compatible = "jedec,lpddr3-timings"; + reg = <800000000>; + min-freq = <100000000>; + tCKE = <3750>; + tCKESR = <3750>; + tFAW = <25000>; + tMRD = <7000>; + tR2R-C2C = <0>; + tRAS = <23000>; + tRC = <33750>; + tRCD = <10000>; + tRFC = <65000>; + tRPab = <12000>; + tRPpb = <12000>; + tRRD = <6000>; + tRTP = <3750>; + tW2W-C2C = <0>; + tWR = <7500>; + tWTR = <3750>; + tXP = <3750>; + tXSR = <70000>; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3-timings.txt b/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3-timings.txt deleted file mode 100644 index 84705e50a3fd..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3-timings.txt +++ /dev/null @@ -1,58 +0,0 @@ -* AC timing parameters of LPDDR3 memories for a given speed-bin. - -The structures are based on LPDDR2 and extended where needed. - -Required properties: -- compatible : Should be "jedec,lpddr3-timings" -- min-freq : minimum DDR clock frequency for the speed-bin. Type is -- reg : maximum DDR clock frequency for the speed-bin. Type is - -Optional properties: - -The following properties represent AC timing parameters from the memory -data-sheet of the device for a given speed-bin. All these properties are -of type and the default unit is ps (pico seconds). -- tRFC -- tRRD -- tRPab -- tRPpb -- tRCD -- tRC -- tRAS -- tWTR -- tWR -- tRTP -- tW2W-C2C -- tR2R-C2C -- tFAW -- tXSR -- tXP -- tCKE -- tCKESR -- tMRD - -Example: - -timings_samsung_K3QF2F20DB_800mhz: lpddr3-timings@800000000 { - compatible = "jedec,lpddr3-timings"; - reg = <800000000>; /* workaround: it shows max-freq */ - min-freq = <100000000>; - tRFC = <65000>; - tRRD = <6000>; - tRPab = <12000>; - tRPpb = <12000>; - tRCD = <10000>; - tRC = <33750>; - tRAS = <23000>; - tWTR = <3750>; - tWR = <7500>; - tRTP = <3750>; - tW2W-C2C = <0>; - tR2R-C2C = <0>; - tFAW = <25000>; - tXSR = <70000>; - tXP = <3750>; - tCKE = <3750>; - tCKESR = <3750>; - tMRD = <7000>; -}; -- cgit From 28f818580e49a97876de5c33231fc0e4c3cde2d9 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 6 Feb 2022 14:58:02 +0100 Subject: dt-bindings: memory: lpddr3: convert to dtschema Convert the LPDDR3 memory bindings to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Dmitry Osipenko Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220206135807.211767-4-krzysztof.kozlowski@canonical.com --- .../memory-controllers/ddr/jedec,lpddr3.yaml | 265 +++++++++++++++++++++ .../bindings/memory-controllers/ddr/lpddr3.txt | 107 --------- .../memory-controllers/samsung,exynos5422-dmc.yaml | 3 +- 3 files changed, 266 insertions(+), 109 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml delete mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml new file mode 100644 index 000000000000..e36f3607e25a --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml @@ -0,0 +1,265 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LPDDR3 SDRAM compliant to JEDEC JESD209-3 + +maintainers: + - Krzysztof Kozlowski + +properties: + compatible: + items: + - enum: + - samsung,K3QF2F20DB + - const: jedec,lpddr3 + + '#address-cells': + const: 1 + + density: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Density in megabits of SDRAM chip. + enum: + - 4096 + - 8192 + - 16384 + - 32768 + + io-width: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + IO bus width in bits of SDRAM chip. + enum: + - 64 + - 32 + - 16 + - 8 + + manufacturer-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Manufacturer ID value read from Mode Register 5. + + revision-id: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + items: + maximum: 255 + description: | + Revision value of SDRAM chip read from Mode Registers 6 and 7. + + '#size-cells': + const: 0 + + tCKE-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + CKE minimum pulse width (HIGH and LOW pulse width) in terms of number + of clock cycles. + + tCKESR-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + CKE minimum pulse width during SELF REFRESH (low pulse width during + SELF REFRESH) in terms of number of clock cycles. + + tDQSCK-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + DQS output data access time from CK_t/CK_c in terms of number of clock + cycles. + + tFAW-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 63 + description: | + Four-bank activate window in terms of number of clock cycles. + + tMRD-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + Mode register set command delay in terms of number of clock cycles. + + tR2R-C2C-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: | + Additional READ-to-READ delay in chip-to-chip cases in terms of number + of clock cycles. + + tRAS-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 63 + description: | + Row active time in terms of number of clock cycles. + + tRC-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 63 + description: | + ACTIVATE-to-ACTIVATE command period in terms of number of clock cycles. + + tRCD-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + RAS-to-CAS delay in terms of number of clock cycles. + + tRFC-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 255 + description: | + Refresh Cycle time in terms of number of clock cycles. + + tRL-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + READ data latency in terms of number of clock cycles. + + tRPab-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + Row precharge time (all banks) in terms of number of clock cycles. + + tRPpb-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + Row precharge time (single banks) in terms of number of clock cycles. + + tRRD-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + Active bank A to active bank B in terms of number of clock cycles. + + tRTP-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + Internal READ to PRECHARGE command delay in terms of number of clock + cycles. + + tW2W-C2C-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: | + Additional WRITE-to-WRITE delay in chip-to-chip cases in terms of number + of clock cycles. + + tWL-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + WRITE data latency in terms of number of clock cycles. + + tWR-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + WRITE recovery time in terms of number of clock cycles. + + tWTR-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + Internal WRITE-to-READ command delay in terms of number of clock cycles. + + tXP-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 255 + description: | + Exit power-down to next valid command delay in terms of number of clock + cycles. + + tXSR-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 1023 + description: | + SELF REFRESH exit to next valid command delay in terms of number of clock + cycles. + +patternProperties: + "^timings@[0-9a-f]+$": + $ref: jedec,lpddr3-timings.yaml + description: | + The lpddr3 node may have one or more child nodes with timings. + Each timing node provides AC timing parameters of the device for a given + speed-bin. The user may provide the timings for as many speed-bins as is + required. + +required: + - compatible + - '#address-cells' + - density + - io-width + - '#size-cells' + +additionalProperties: false + +examples: + - | + lpddr3 { + compatible = "samsung,K3QF2F20DB", "jedec,lpddr3"; + density = <16384>; + io-width = <32>; + #address-cells = <1>; + #size-cells = <0>; + + tCKE-min-tck = <2>; + tCKESR-min-tck = <2>; + tDQSCK-min-tck = <5>; + tFAW-min-tck = <5>; + tMRD-min-tck = <5>; + tR2R-C2C-min-tck = <0>; + tRAS-min-tck = <5>; + tRC-min-tck = <6>; + tRCD-min-tck = <3>; + tRFC-min-tck = <17>; + tRL-min-tck = <14>; + tRPab-min-tck = <2>; + tRPpb-min-tck = <2>; + tRRD-min-tck = <2>; + tRTP-min-tck = <2>; + tW2W-C2C-min-tck = <0>; + tWL-min-tck = <8>; + tWR-min-tck = <7>; + tWTR-min-tck = <2>; + tXP-min-tck = <2>; + tXSR-min-tck = <12>; + + timings@800000000 { + compatible = "jedec,lpddr3-timings"; + reg = <800000000>; + min-freq = <100000000>; + tCKE = <3750>; + tCKESR = <3750>; + tFAW = <25000>; + tMRD = <7000>; + tR2R-C2C = <0>; + tRAS = <23000>; + tRC = <33750>; + tRCD = <10000>; + tRFC = <65000>; + tRPab = <12000>; + tRPpb = <12000>; + tRRD = <6000>; + tRTP = <3750>; + tW2W-C2C = <0>; + tWR = <7500>; + tWTR = <3750>; + tXP = <3750>; + tXSR = <70000>; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3.txt b/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3.txt deleted file mode 100644 index 031af5fb0379..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3.txt +++ /dev/null @@ -1,107 +0,0 @@ -* LPDDR3 SDRAM memories compliant to JEDEC JESD209-3C - -Required properties: -- compatible : Should be ",", and generic value "jedec,lpddr3". - Example "," values: - "samsung,K3QF2F20DB" - -- density : representing density in Mb (Mega bits) -- io-width : representing bus width. Possible values are 8, 16, 32, 64 -- #address-cells: Must be set to 1 -- #size-cells: Must be set to 0 - -Optional properties: - -- manufacturer-id : Manufacturer ID value read from Mode Register 5 -- revision-id : Revision IDs read from Mode Registers 6 and 7 - -The following optional properties represent the minimum value of some AC -timing parameters of the DDR device in terms of number of clock cycles. -These values shall be obtained from the device data-sheet. -- tRFC-min-tck -- tRRD-min-tck -- tRPab-min-tck -- tRPpb-min-tck -- tRCD-min-tck -- tRC-min-tck -- tRAS-min-tck -- tWTR-min-tck -- tWR-min-tck -- tRTP-min-tck -- tW2W-C2C-min-tck -- tR2R-C2C-min-tck -- tWL-min-tck -- tDQSCK-min-tck -- tRL-min-tck -- tFAW-min-tck -- tXSR-min-tck -- tXP-min-tck -- tCKE-min-tck -- tCKESR-min-tck -- tMRD-min-tck - -Child nodes: -- The lpddr3 node may have one or more child nodes of type "lpddr3-timings". - "lpddr3-timings" provides AC timing parameters of the device for - a given speed-bin. Please see - Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3-timings.txt - for more information on "lpddr3-timings" - -Example: - -samsung_K3QF2F20DB: lpddr3 { - compatible = "samsung,K3QF2F20DB", "jedec,lpddr3"; - density = <16384>; - io-width = <32>; - manufacturer-id = <1>; - revision-id = <123 234>; - #address-cells = <1>; - #size-cells = <0>; - - tRFC-min-tck = <17>; - tRRD-min-tck = <2>; - tRPab-min-tck = <2>; - tRPpb-min-tck = <2>; - tRCD-min-tck = <3>; - tRC-min-tck = <6>; - tRAS-min-tck = <5>; - tWTR-min-tck = <2>; - tWR-min-tck = <7>; - tRTP-min-tck = <2>; - tW2W-C2C-min-tck = <0>; - tR2R-C2C-min-tck = <0>; - tWL-min-tck = <8>; - tDQSCK-min-tck = <5>; - tRL-min-tck = <14>; - tFAW-min-tck = <5>; - tXSR-min-tck = <12>; - tXP-min-tck = <2>; - tCKE-min-tck = <2>; - tCKESR-min-tck = <2>; - tMRD-min-tck = <5>; - - timings_samsung_K3QF2F20DB_800mhz: lpddr3-timings@800000000 { - compatible = "jedec,lpddr3-timings"; - /* workaround: 'reg' shows max-freq */ - reg = <800000000>; - min-freq = <100000000>; - tRFC = <65000>; - tRRD = <6000>; - tRPab = <12000>; - tRPpb = <12000>; - tRCD = <10000>; - tRC = <33750>; - tRAS = <23000>; - tWTR = <3750>; - tWR = <7500>; - tRTP = <3750>; - tW2W-C2C = <0>; - tR2R-C2C = <0>; - tFAW = <25000>; - tXSR = <70000>; - tXP = <3750>; - tCKE = <3750>; - tCKESR = <3750>; - tMRD = <7000>; - }; -} diff --git a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml index fe8639dcffab..044127788695 100644 --- a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml @@ -51,8 +51,7 @@ properties: $ref: '/schemas/types.yaml#/definitions/phandle' description: | phandle of the connected DRAM memory device. For more information please - refer to documentation file: - Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3.txt + refer to jedec,lpddr3.yaml. operating-points-v2: true -- cgit From d98e72b6f9b078c57f9d46dc64a669d02ff2ffcc Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 6 Feb 2022 14:58:03 +0100 Subject: dt-bindings: memory: lpddr3: adjust IO width to spec According to JEDEC Standard No. 209-3 (table 3.4.1 "Mode Register Assignment and Definition in LPDDR3 SDRAM"), the LPDDR3 supports only 16- and 32-bit IO width. Drop the unsupported others. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220206135807.211767-5-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml index e36f3607e25a..d6787b5190ee 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml @@ -34,10 +34,8 @@ properties: description: | IO bus width in bits of SDRAM chip. enum: - - 64 - 32 - 16 - - 8 manufacturer-id: $ref: /schemas/types.yaml#/definitions/uint32 -- cgit From e531932c7185b86eccb3688002730950d49eba1a Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 6 Feb 2022 14:58:04 +0100 Subject: dt-bindings: memory: lpddr3: deprecate manufacturer ID The memory manufacturer should be described in vendor part of compatible, so there is no need to duplicate it in a separate property. Similarly is done in LPDDR2 bindings. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Alim Akhtar Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220206135807.211767-6-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml index d6787b5190ee..3bcba15098ea 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml @@ -40,7 +40,9 @@ properties: manufacturer-id: $ref: /schemas/types.yaml#/definitions/uint32 description: | - Manufacturer ID value read from Mode Register 5. + Manufacturer ID value read from Mode Register 5. The property is + deprecated, manufacturer should be derived from the compatible. + deprecated: true revision-id: $ref: /schemas/types.yaml#/definitions/uint32-array -- cgit From 42f94bb962cd1b15dc57c90aca7e48848ca6c6c3 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 6 Feb 2022 14:58:05 +0100 Subject: dt-bindings: memory: lpddr3: deprecate passing timings frequency as unit address The timings node maximum frequency was passed as an unit address, which is actually a workaround. Such workaround and unit address are not needed at all, because the device memory node (parent) can contain multiple timing nodes without unit addresses but with suffix used for nodenames, e.g. timings-1. LPDDR2 bindings already use such version, so unify the LPDDR3 with them. Suggested-by: Dmitry Osipenko Signed-off-by: Krzysztof Kozlowski Reviewed-by: Dmitry Osipenko Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220206135807.211767-7-krzysztof.kozlowski@canonical.com --- .../memory-controllers/ddr/jedec,lpddr3-timings.yaml | 16 ++++++++++------ .../bindings/memory-controllers/ddr/jedec,lpddr3.yaml | 12 +++++------- 2 files changed, 15 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml index 98bc219e8a25..97c3e988af5f 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml @@ -17,6 +17,13 @@ properties: maxItems: 1 description: | Maximum DDR clock frequency for the speed-bin, in Hz. + Property is deprecated, use max-freq. + deprecated: true + + max-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Maximum DDR clock frequency for the speed-bin, in Hz. min-freq: $ref: /schemas/types.yaml#/definitions/uint32 @@ -117,19 +124,16 @@ properties: required: - compatible - min-freq - - reg + - max-freq additionalProperties: false examples: - | lpddr3 { - #address-cells = <1>; - #size-cells = <0>; - - timings@800000000 { + timings { compatible = "jedec,lpddr3-timings"; - reg = <800000000>; + max-freq = <800000000>; min-freq = <100000000>; tCKE = <3750>; tCKESR = <3750>; diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml index 3bcba15098ea..c542f32c39fa 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml @@ -18,6 +18,7 @@ properties: '#address-cells': const: 1 + deprecated: true density: $ref: /schemas/types.yaml#/definitions/uint32 @@ -55,6 +56,7 @@ properties: '#size-cells': const: 0 + deprecated: true tCKE-min-tck: $ref: /schemas/types.yaml#/definitions/uint32 @@ -191,7 +193,7 @@ properties: cycles. patternProperties: - "^timings@[0-9a-f]+$": + "^timings((-[0-9])+|(@[0-9a-f]+))?$": $ref: jedec,lpddr3-timings.yaml description: | The lpddr3 node may have one or more child nodes with timings. @@ -201,10 +203,8 @@ patternProperties: required: - compatible - - '#address-cells' - density - io-width - - '#size-cells' additionalProperties: false @@ -214,8 +214,6 @@ examples: compatible = "samsung,K3QF2F20DB", "jedec,lpddr3"; density = <16384>; io-width = <32>; - #address-cells = <1>; - #size-cells = <0>; tCKE-min-tck = <2>; tCKESR-min-tck = <2>; @@ -239,9 +237,9 @@ examples: tXP-min-tck = <2>; tXSR-min-tck = <12>; - timings@800000000 { + timings { compatible = "jedec,lpddr3-timings"; - reg = <800000000>; + max-freq = <800000000>; min-freq = <100000000>; tCKE = <3750>; tCKESR = <3750>; -- cgit From 8be90641a0bbd9a3606547aa6a0f70b020e74c8f Mon Sep 17 00:00:00 2001 From: Jayesh Choudhary Date: Wed, 9 Feb 2022 12:00:08 +0530 Subject: ASoC: dt-bindings: davinci-mcasp: convert McASP bindings to yaml schema Convert the bindings for McASP controllers for TI SoCs from txt to YAML schema. Adds additional properties 'clocks', 'clock-names', 'power-domains', '#sound-dai-cells' and 'port' which were missing from the txt file. Removes properties 'sram-size-playback' and 'sram-size-capture' since they are not used. Adds 'dmas' and 'dma-names' in the example which were missing from the txt file. Changes 'interrupts' and 'interrupt-names' from optional to required properties. Changes 'op-modes', 'serial-dir' to optional properties as they are not needed if the McASP is used only as GPIO. Changes 'tdm-slots' to required property only for I2S operation mode. Adds the yaml file in the 'MAINTAINERS' under the heading 'TEXAS INSTRUMENTS ASoC DRIVERS' Signed-off-by: Jayesh Choudhary Reviewed-by: Rob Herring Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20220209063008.2928-1-j-choudhary@ti.com Signed-off-by: Mark Brown --- .../bindings/sound/davinci-mcasp-audio.txt | 86 --------- .../bindings/sound/davinci-mcasp-audio.yaml | 201 +++++++++++++++++++++ 2 files changed, 201 insertions(+), 86 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt create mode 100644 Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt deleted file mode 100644 index bd863bd69501..000000000000 --- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt +++ /dev/null @@ -1,86 +0,0 @@ -Texas Instruments McASP controller - -Required properties: -- compatible : - "ti,dm646x-mcasp-audio" : for DM646x platforms - "ti,da830-mcasp-audio" : for both DA830 & DA850 platforms - "ti,am33xx-mcasp-audio" : for AM33xx platforms (AM33xx, AM43xx, TI81xx) - "ti,dra7-mcasp-audio" : for DRA7xx platforms - "ti,omap4-mcasp-audio" : for OMAP4 - -- reg : Should contain reg specifiers for the entries in the reg-names property. -- reg-names : Should contain: - * "mpu" for the main registers (required). For compatibility with - existing software, it is recommended this is the first entry. - * "dat" for separate data port register access (optional). -- op-mode : I2S/DIT ops mode. 0 for I2S mode. 1 for DIT mode used for S/PDIF, - IEC60958-1, and AES-3 formats. -- tdm-slots : Slots for TDM operation. Indicates number of channels transmitted - or received over one serializer. -- serial-dir : A list of serializer configuration. Each entry is a number - indication for serializer pin direction. - (0 - INACTIVE, 1 - TX, 2 - RX) -- dmas: two element list of DMA controller phandles and DMA request line - ordered pairs. -- dma-names: identifier string for each DMA request line in the dmas property. - These strings correspond 1:1 with the ordered pairs in dmas. The dma - identifiers must be "rx" and "tx". - -Optional properties: - -- ti,hwmods : Must be "mcasp", n is controller instance starting 0 -- tx-num-evt : FIFO levels. -- rx-num-evt : FIFO levels. -- dismod : Specify the drive on TX pin during inactive slots - 0 : 3-state - 2 : logic low - 3 : logic high - Defaults to 'logic low' when the property is not present -- sram-size-playback : size of sram to be allocated during playback -- sram-size-capture : size of sram to be allocated during capture -- interrupts : Interrupt numbers for McASP -- interrupt-names : Known interrupt names are "tx" and "rx" -- pinctrl-0: Should specify pin control group used for this controller. -- pinctrl-names: Should contain only one value - "default", for more details - please refer to pinctrl-bindings.txt -- fck_parent : Should contain a valid clock name which will be used as parent - for the McASP fck -- auxclk-fs-ratio: When McASP is bus master indicates the ratio between AUCLK - and FS rate if applicable: - AUCLK rate = auxclk-fs-ratio * FS rate - -Optional GPIO support: -If any McASP pin need to be used as GPIO then the McASP node must have: -... - gpio-controller - #gpio-cells = <2>; -... - -When requesting a GPIO, the first parameter is the PIN index in McASP_P* -registers. -For example to request the AXR2 pin of mcasp8: -function-gpios = <&mcasp8 2 0>; - -Or to request the ACLKR pin of mcasp8: -function-gpios = <&mcasp8 29 0>; - -For generic gpio information, please refer to bindings/gpio/gpio.txt - -Example: - -mcasp0: mcasp0@1d00000 { - compatible = "ti,da830-mcasp-audio"; - reg = <0x100000 0x3000>; - reg-names "mpu"; - interrupts = <82>, <83>; - interrupt-names = "tx", "rx"; - op-mode = <0>; /* MCASP_IIS_MODE */ - tdm-slots = <2>; - serial-dir = < - 0 0 0 0 /* 0: INACTIVE, 1: TX, 2: RX */ - 0 0 0 0 - 0 0 0 1 - 2 0 0 0 >; - tx-num-evt = <1>; - rx-num-evt = <1>; -}; diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml new file mode 100644 index 000000000000..f46c66bc6b2d --- /dev/null +++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml @@ -0,0 +1,201 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/davinci-mcasp-audio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: McASP Controller for TI SoCs + +maintainers: + - Jayesh Choudhary + +properties: + compatible: + enum: + - ti,dm646x-mcasp-audio + - ti,da830-mcasp-audio + - ti,am33xx-mcasp-audio + - ti,dra7-mcasp-audio + - ti,omap4-mcasp-audio + + reg: + minItems: 1 + items: + - description: CFG registers + - description: data registers + + reg-names: + minItems: 1 + items: + - const: mpu + - const: dat + + op-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + description: 0 - I2S or 1 - DIT operation mode + enum: + - 0 + - 1 + + tdm-slots: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + number of channels over one serializer + the property is ignored in DIT mode + minimum: 2 + maximum: 32 + + serial-dir: + description: + A list of serializer configuration + Entry is indication for serializer pin direction + 0 - Inactive, 1 - TX, 2 - RX + All AXR pins should be present in the array even if inactive + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 25 + items: + minimum: 0 + maximum: 2 + + dmas: + minItems: 1 + items: + - description: transmission DMA channel + - description: reception DMA channel + + dma-names: + minItems: 1 + items: + - const: tx + - const: rx + + ti,hwmods: + $ref: /schemas/types.yaml#/definitions/string + description: Name of hwmod associated with McASP + maxItems: 1 + deprecated: true + + tx-num-evt: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + configures WFIFO threshold + 0 disables the FIFO use + if property is missing, then also FIFO use is disabled + + rx-num-evt: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + configures RFIFO threshold + 0 disables the FIFO use + if property is missing, then also FIFO use is disabled + + dismod: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + specify the drive on TX pin during inactive time slots + 0 - 3-state, 2 - logic low, 3 - logic high + enum: + - 0 + - 2 + - 3 + default: 2 + + interrupts: + anyOf: + - minItems: 1 + items: + - description: TX interrupt + - description: RX interrupt + - items: + - description: common/combined interrupt + + interrupt-names: + oneOf: + - minItems: 1 + items: + - const: tx + - const: rx + - const: common + + fck_parent: + $ref: /schemas/types.yaml#/definitions/string + description: parent clock name for McASP fck + maxItems: 1 + + auxclk-fs-ratio: + $ref: /schemas/types.yaml#/definitions/uint32 + description: ratio of AUCLK and FS rate if applicable + + gpio-controller: true + + "#gpio-cells": + const: 2 + + clocks: + minItems: 1 + items: + - description: functional clock + - description: module specific optional ahclkx clock + - description: module specific optional ahclkr clock + + clock-names: + minItems: 1 + items: + - const: fck + - const: ahclkx + - const: ahclkr + + power-domains: + description: phandle to the corresponding power-domain + maxItems: 1 + + "#sound-dai-cells": + const: 0 + + port: + description: connection for when McASP is used via graph card + type: object + +required: + - compatible + - reg + - reg-names + - dmas + - dma-names + - interrupts + - interrupt-names + +allOf: + - if: + properties: + opmode: + enum: + - 0 + + then: + required: + - tdm-slots + +additionalProperties: false + +examples: + - | + mcasp0: mcasp0@1d00000 { + compatible = "ti,da830-mcasp-audio"; + reg = <0x100000 0x3000>; + reg-names = "mpu"; + interrupts = <82>, <83>; + interrupt-names = "tx", "rx"; + op-mode = <0>; /* MCASP_IIS_MODE */ + tdm-slots = <2>; + dmas = <&main_udmap 0xc400>, <&main_udmap 0x4400>; + dma-names = "tx", "rx"; + serial-dir = < + 0 0 0 0 /* 0: INACTIVE, 1: TX, 2: RX */ + 0 0 0 0 + 0 0 0 1 + 2 0 0 0 >; + tx-num-evt = <1>; + rx-num-evt = <1>; + }; -- cgit From 87e70353c3985c2882da4139c9a3c3fbfe49a65b Mon Sep 17 00:00:00 2001 From: "Nancy.Lin" Date: Mon, 10 Jan 2022 16:46:25 +0800 Subject: dt-bindings: display: mediatek: add vdosys1 MERGE property for mt8195 MT8195 vdosys1 merge1 to merge4 have HW mute function. Add MERGE additional mute property description. Signed-off-by: Nancy.Lin Acked-by: AngeloGioacchino Del Regno Signed-off-by: Chun-Kuang Hu --- .../devicetree/bindings/display/mediatek/mediatek,merge.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml index 60b21ef5549b..d5cd69b7f501 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml @@ -61,6 +61,10 @@ properties: command to SMI to speed up the data rate. type: boolean + mediatek,merge-mute: + description: Support mute function. Mute the content of merge output. + type: boolean + mediatek,gce-client-reg: description: The register of client driver can be configured by gce with 4 arguments defined in this property, such as phandle of gce, subsys id, -- cgit From e7dcfe64204a5cd9a74a9ca7d9c7a22434dc7fe5 Mon Sep 17 00:00:00 2001 From: "Nancy.Lin" Date: Mon, 10 Jan 2022 16:46:26 +0800 Subject: dt-bindings: display: mediatek: add ethdr definition for mt8195 Add vdosys1 ETHDR definition. Signed-off-by: Nancy.Lin Signed-off-by: Chun-Kuang Hu --- .../bindings/display/mediatek/mediatek,ethdr.yaml | 147 +++++++++++++++++++++ 1 file changed, 147 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml new file mode 100644 index 000000000000..131eed5eeeb7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml @@ -0,0 +1,147 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ethdr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek Ethdr Device Tree Bindings + +maintainers: + - Chun-Kuang Hu + - Philipp Zabel + +description: | + ETHDR is designed for HDR video and graphics conversion in the external display path. + It handles multiple HDR input types and performs tone mapping, color space/color + format conversion, and then combine different layers, output the required HDR or + SDR signal to the subsequent display path. This engine is composed of two video + frontends, two graphic frontends, one video backend and a mixer. ETHDR has two + DMA function blocks, DS and ADL. These two function blocks read the pre-programmed + registers from DRAM and set them to HW in the v-blanking period. + +properties: + compatible: + items: + - const: mediatek,mt8195-disp-ethdr + reg: + maxItems: 7 + reg-names: + items: + - const: mixer + - const: vdo_fe0 + - const: vdo_fe1 + - const: gfx_fe0 + - const: gfx_fe1 + - const: vdo_be + - const: adl_ds + interrupts: + minItems: 1 + iommus: + description: The compatible property is DMA function blocks. + Should point to the respective IOMMU block with master port as argument, + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for + details. + minItems: 1 + maxItems: 2 + clocks: + items: + - description: mixer clock + - description: video frontend 0 clock + - description: video frontend 1 clock + - description: graphic frontend 0 clock + - description: graphic frontend 1 clock + - description: video backend clock + - description: autodownload and menuload clock + - description: video frontend 0 async clock + - description: video frontend 1 async clock + - description: graphic frontend 0 async clock + - description: graphic frontend 1 async clock + - description: video backend async clock + - description: ethdr top clock + clock-names: + items: + - const: mixer + - const: vdo_fe0 + - const: vdo_fe1 + - const: gfx_fe0 + - const: gfx_fe1 + - const: vdo_be + - const: adl_ds + - const: vdo_fe0_async + - const: vdo_fe1_async + - const: gfx_fe0_async + - const: gfx_fe1_async + - const: vdo_be_async + - const: ethdr_top + power-domains: + maxItems: 1 + resets: + maxItems: 5 + mediatek,gce-client-reg: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: The register of display function block to be set by gce. + There are 4 arguments in this property, gce node, subsys id, offset and + register size. The subsys id is defined in the gce header of each chips + include/include/dt-bindings/gce/-gce.h, mapping to the register of + display function block. + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - power-domains + +additionalProperties: false + +examples: + - | + + disp_ethdr@1c114000 { + compatible = "mediatek,mt8195-disp-ethdr"; + reg = <0 0x1c114000 0 0x1000>, + <0 0x1c115000 0 0x1000>, + <0 0x1c117000 0 0x1000>, + <0 0x1c119000 0 0x1000>, + <0 0x1c11A000 0 0x1000>, + <0 0x1c11B000 0 0x1000>, + <0 0x1c11C000 0 0x1000>; + reg-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", + "vdo_be", "adl_ds"; + mediatek,gce-client-reg = <&gce0 SUBSYS_1c11XXXX 0x4000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x5000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x7000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x9000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xA000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xB000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xC000 0x1000>; + clocks = <&vdosys1 CLK_VDO1_DISP_MIXER>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE0>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE1>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE0>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE1>, + <&vdosys1 CLK_VDO1_HDR_VDO_BE>, + <&vdosys1 CLK_VDO1_26M_SLOW>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE0_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE1_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE0_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE1_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_VDO_BE_DL_ASYNC>, + <&topckgen CLK_TOP_ETHDR_SEL>; + clock-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", + "vdo_be", "adl_ds", "vdo_fe0_async", "vdo_fe1_async", + "gfx_fe0_async", "gfx_fe1_async","vdo_be_async", + "ethdr_top"; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; + iommus = <&iommu_vpp M4U_PORT_L3_HDR_DS>, + <&iommu_vpp M4U_PORT_L3_HDR_ADL>; + interrupts = ; /* disp mixer */ + resets = <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE_DL_ASYNC>; + }; + +... -- cgit From b08e569abc91f525834deda751d6ddd1ffe4ab5a Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 27 Dec 2021 14:31:14 +0100 Subject: dt-bindings: altera: document existing Cyclone 5 board compatibles Several Cyclone 5 SoCFPGA based boards have additional board compatibles which are not documented in the bindings. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Dinh Nguyen --- Documentation/devicetree/bindings/arm/altera.yaml | 30 ++++++++++++++++++----- 1 file changed, 24 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml index c15c92fdf2ed..0d62c2bde053 100644 --- a/Documentation/devicetree/bindings/arm/altera.yaml +++ b/Documentation/devicetree/bindings/arm/altera.yaml @@ -13,12 +13,30 @@ properties: $nodename: const: "/" compatible: - items: - - enum: - - altr,socfpga-cyclone5 - - altr,socfpga-arria5 - - altr,socfpga-arria10 - - const: altr,socfpga + oneOf: + - description: Arria 5 boards + items: + - const: altr,socfpga-arria5 + - const: altr,socfpga + + - description: Arria 10 boards + items: + - const: altr,socfpga-arria10 + - const: altr,socfpga + + - description: Cyclone 5 boards + items: + - enum: + - altr,socfpga-cyclone5-socdk + - denx,mcvevk + - ebv,socrates + - macnica,sodia + - novtech,chameleon96 + - samtec,vining + - terasic,de0-atlas + - terasic,socfpga-cyclone5-sockit + - const: altr,socfpga-cyclone5 + - const: altr,socfpga additionalProperties: true -- cgit From 8227e63ddf8d1b208f5d0fd58aeb5fec9ab57330 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 27 Dec 2021 14:31:15 +0100 Subject: dt-bindings: altera: document Arria 5 based board compatibles Add new compatible for Arria 5 based boards. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Dinh Nguyen --- Documentation/devicetree/bindings/arm/altera.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml index 0d62c2bde053..3d7a2f699279 100644 --- a/Documentation/devicetree/bindings/arm/altera.yaml +++ b/Documentation/devicetree/bindings/arm/altera.yaml @@ -16,6 +16,8 @@ properties: oneOf: - description: Arria 5 boards items: + - enum: + - altr,socfpga-arria5-socdk - const: altr,socfpga-arria5 - const: altr,socfpga -- cgit From 15dc346c7a1940cf438495162fedf29d86924fa4 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 27 Dec 2021 14:31:16 +0100 Subject: dt-bindings: altera: document Arria 10 based board compatibles Add new compatible for Arria 10 based boards. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Dinh Nguyen --- Documentation/devicetree/bindings/arm/altera.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml index 3d7a2f699279..963c83904010 100644 --- a/Documentation/devicetree/bindings/arm/altera.yaml +++ b/Documentation/devicetree/bindings/arm/altera.yaml @@ -23,6 +23,9 @@ properties: - description: Arria 10 boards items: + - enum: + - altr,socfpga-arria10-socdk + - enclustra,mercury-aa1 - const: altr,socfpga-arria10 - const: altr,socfpga -- cgit From 53d50b4f6fa8a6da4ff6fe6cf58a88a92fa15acb Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 27 Dec 2021 14:31:17 +0100 Subject: dt-bindings: altera: document VT compatibles Add new compatible for SoCFPGA VT boards/designs. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Dinh Nguyen --- Documentation/devicetree/bindings/arm/altera.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml index 963c83904010..f4e07a21aaf5 100644 --- a/Documentation/devicetree/bindings/arm/altera.yaml +++ b/Documentation/devicetree/bindings/arm/altera.yaml @@ -43,6 +43,11 @@ properties: - const: altr,socfpga-cyclone5 - const: altr,socfpga + - description: SoCFPGA VT + items: + - const: altr,socfpga-vt + - const: altr,socfpga + additionalProperties: true ... -- cgit From f8aa14dd365ab3f0608931503dab3e8665226b25 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 27 Dec 2021 14:35:32 +0100 Subject: dt-bindings: altera: document Stratix 10 based board compatibles Add new compatible for Stratix 10 based boards. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Dinh Nguyen --- Documentation/devicetree/bindings/arm/altera.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml index f4e07a21aaf5..5e2017c0a051 100644 --- a/Documentation/devicetree/bindings/arm/altera.yaml +++ b/Documentation/devicetree/bindings/arm/altera.yaml @@ -43,6 +43,12 @@ properties: - const: altr,socfpga-cyclone5 - const: altr,socfpga + - description: Stratix 10 boards + items: + - enum: + - altr,socfpga-stratix10-socdk + - const: altr,socfpga-stratix10 + - description: SoCFPGA VT items: - const: altr,socfpga-vt -- cgit From abca30aa14b1ec3d96547ec71d690aa1169cc4e6 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 27 Dec 2021 14:35:46 +0100 Subject: dt-bindings: intel: document Agilex based board compatibles Add new compatible for Agilex based boards. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Dinh Nguyen --- .../devicetree/bindings/arm/intel,socfpga.yaml | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/intel,socfpga.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/intel,socfpga.yaml b/Documentation/devicetree/bindings/arm/intel,socfpga.yaml new file mode 100644 index 000000000000..6e043459fcd5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/intel,socfpga.yaml @@ -0,0 +1,26 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/intel,socfpga.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel SoCFPGA platform device tree bindings + +maintainers: + - Dinh Nguyen + +properties: + $nodename: + const: "/" + compatible: + oneOf: + - description: AgileX boards + items: + - enum: + - intel,n5x-socdk + - intel,socfpga-agilex-socdk + - const: intel,socfpga-agilex + +additionalProperties: true + +... -- cgit From ad7f9f3ad1bc7403d0b6d655d92fa7b4b1899629 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 27 Dec 2021 14:35:47 +0100 Subject: dt-bindings: clock: intel,stratix10: convert to dtschema Convert the Intel Stratix 10 clock controller bindings to DT schema format. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Dinh Nguyen --- .../devicetree/bindings/clock/intc_stratix10.txt | 20 ------------- .../devicetree/bindings/clock/intel,stratix10.yaml | 35 ++++++++++++++++++++++ 2 files changed, 35 insertions(+), 20 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/intc_stratix10.txt create mode 100644 Documentation/devicetree/bindings/clock/intel,stratix10.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/intc_stratix10.txt b/Documentation/devicetree/bindings/clock/intc_stratix10.txt deleted file mode 100644 index 9f4ec5cb5c6b..000000000000 --- a/Documentation/devicetree/bindings/clock/intc_stratix10.txt +++ /dev/null @@ -1,20 +0,0 @@ -Device Tree Clock bindings for Intel's SoCFPGA Stratix10 platform - -This binding uses the common clock binding[1]. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt - -Required properties: -- compatible : shall be - "intel,stratix10-clkmgr" - -- reg : shall be the control register offset from CLOCK_MANAGER's base for the clock. - -- #clock-cells : from common clock binding, shall be set to 1. - -Example: - clkmgr: clock-controller@ffd10000 { - compatible = "intel,stratix10-clkmgr"; - reg = <0xffd10000 0x1000>; - #clock-cells = <1>; - }; diff --git a/Documentation/devicetree/bindings/clock/intel,stratix10.yaml b/Documentation/devicetree/bindings/clock/intel,stratix10.yaml new file mode 100644 index 000000000000..f506e3db9782 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/intel,stratix10.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/intel,stratix10.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel SoCFPGA Stratix10 platform clock controller binding + +maintainers: + - Dinh Nguyen + +properties: + compatible: + const: intel,stratix10-clkmgr + + '#clock-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller@ffd10000 { + compatible = "intel,stratix10-clkmgr"; + reg = <0xffd10000 0x1000>; + #clock-cells = <1>; + }; -- cgit From f4e82f190e793ed882b028044e90769acc4e55d7 Mon Sep 17 00:00:00 2001 From: Jonathan Neuschäfer Date: Sun, 30 Jan 2022 11:27:02 +0100 Subject: dt-bindings: timer: nuvoton,npcm7xx-timer: Convert to YAML MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Let's convert this devicetree binding to YAML, to make it easier to extend later. Signed-off-by: Jonathan Neuschäfer Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220130102704.2892072-1-j.neuschaefer@gmx.net --- .../bindings/timer/nuvoton,npcm7xx-timer.txt | 21 ---------- .../bindings/timer/nuvoton,npcm7xx-timer.yaml | 46 ++++++++++++++++++++++ 2 files changed, 46 insertions(+), 21 deletions(-) delete mode 100644 Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt create mode 100644 Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt deleted file mode 100644 index ac3a5e887455..000000000000 --- a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt +++ /dev/null @@ -1,21 +0,0 @@ -Nuvoton NPCM7xx timer - -Nuvoton NPCM7xx have three timer modules, each timer module provides five 24-bit -timer counters. - -Required properties: -- compatible : "nuvoton,npcm750-timer" for Poleg NPCM750, or - "nuvoton,wpcm450-timer" for Hermon WPCM450. -- reg : Offset and length of the register set for the device. -- interrupts : Contain the timer interrupt of timer 0. -- clocks : phandle of timer reference clock (usually a 25 MHz clock). - -Example: - -timer@f0008000 { - compatible = "nuvoton,npcm750-timer"; - interrupts = ; - reg = <0xf0008000 0x50>; - clocks = <&clk NPCM7XX_CLK_TIMER>; -}; - diff --git a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml new file mode 100644 index 000000000000..0cbc26a72151 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/nuvoton,npcm7xx-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton NPCM7xx timer + +maintainers: + - Jonathan Neuschäfer + +properties: + compatible: + enum: + - nuvoton,wpcm450-timer # for Hermon WPCM450 + - nuvoton,npcm750-timer # for Poleg NPCM750 + + reg: + maxItems: 1 + + interrupts: + items: + - description: The timer interrupt of timer 0 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include + #include + #include + timer@f0008000 { + compatible = "nuvoton,npcm750-timer"; + interrupts = ; + reg = <0xf0008000 0x50>; + clocks = <&clk NPCM7XX_CLK_TIMER>; + }; -- cgit From 208b65f7b5cccb7185ec7c1b11e788eddf9e075a Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Tue, 1 Feb 2022 14:49:40 +0000 Subject: dt-bindings: net: convert net/cortina,gemini-ethernet to yaml Converts net/cortina,gemini-ethernet.txt to yaml This permits to detect some missing properties like interrupts Signed-off-by: Corentin Labbe Reviewed-by: Linus Walleij Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220201144940.2488782-1-clabbe@baylibre.com --- .../bindings/net/cortina,gemini-ethernet.txt | 92 -------------- .../bindings/net/cortina,gemini-ethernet.yaml | 137 +++++++++++++++++++++ 2 files changed, 137 insertions(+), 92 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt create mode 100644 Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt b/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt deleted file mode 100644 index 6c559981d110..000000000000 --- a/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt +++ /dev/null @@ -1,92 +0,0 @@ -Cortina Systems Gemini Ethernet Controller -========================================== - -This ethernet controller is found in the Gemini SoC family: -StorLink SL3512 and SL3516, also known as Cortina Systems -CS3512 and CS3516. - -Required properties: -- compatible: must be "cortina,gemini-ethernet" -- reg: must contain the global registers and the V-bit and A-bit - memory areas, in total three register sets. -- syscon: a phandle to the system controller -- #address-cells: must be specified, must be <1> -- #size-cells: must be specified, must be <1> -- ranges: should be state like this giving a 1:1 address translation - for the subnodes - -The subnodes represents the two ethernet ports in this device. -They are not independent of each other since they share resources -in the parent node, and are thus children. - -Required subnodes: -- port0: contains the resources for ethernet port 0 -- port1: contains the resources for ethernet port 1 - -Required subnode properties: -- compatible: must be "cortina,gemini-ethernet-port" -- reg: must contain two register areas: the DMA/TOE memory and - the GMAC memory area of the port -- interrupts: should contain the interrupt line of the port. - this is nominally a level interrupt active high. -- resets: this must provide an SoC-integrated reset line for - the port. -- clocks: this should contain a handle to the PCLK clock for - clocking the silicon in this port -- clock-names: must be "PCLK" - -Optional subnode properties: -- phy-mode: see ethernet.txt -- phy-handle: see ethernet.txt - -Example: - -mdio-bus { - (...) - phy0: ethernet-phy@1 { - reg = <1>; - device_type = "ethernet-phy"; - }; - phy1: ethernet-phy@3 { - reg = <3>; - device_type = "ethernet-phy"; - }; -}; - - -ethernet@60000000 { - compatible = "cortina,gemini-ethernet"; - reg = <0x60000000 0x4000>, /* Global registers, queue */ - <0x60004000 0x2000>, /* V-bit */ - <0x60006000 0x2000>; /* A-bit */ - syscon = <&syscon>; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - gmac0: ethernet-port@0 { - compatible = "cortina,gemini-ethernet-port"; - reg = <0x60008000 0x2000>, /* Port 0 DMA/TOE */ - <0x6000a000 0x2000>; /* Port 0 GMAC */ - interrupt-parent = <&intcon>; - interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; - resets = <&syscon GEMINI_RESET_GMAC0>; - clocks = <&syscon GEMINI_CLK_GATE_GMAC0>; - clock-names = "PCLK"; - phy-mode = "rgmii"; - phy-handle = <&phy0>; - }; - - gmac1: ethernet-port@1 { - compatible = "cortina,gemini-ethernet-port"; - reg = <0x6000c000 0x2000>, /* Port 1 DMA/TOE */ - <0x6000e000 0x2000>; /* Port 1 GMAC */ - interrupt-parent = <&intcon>; - interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; - resets = <&syscon GEMINI_RESET_GMAC1>; - clocks = <&syscon GEMINI_CLK_GATE_GMAC1>; - clock-names = "PCLK"; - phy-mode = "rgmii"; - phy-handle = <&phy1>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml b/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml new file mode 100644 index 000000000000..cc01b9b5752a --- /dev/null +++ b/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/cortina,gemini-ethernet.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cortina Systems Gemini Ethernet Controller + +maintainers: + - Linus Walleij + +description: | + This ethernet controller is found in the Gemini SoC family: + StorLink SL3512 and SL3516, also known as Cortina Systems + CS3512 and CS3516. + +properties: + compatible: + const: cortina,gemini-ethernet + + reg: + minItems: 3 + description: must contain the global registers and the V-bit and A-bit + memory areas, in total three register sets. + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + +#The subnodes represents the two ethernet ports in this device. +#They are not independent of each other since they share resources +#in the parent node, and are thus children. +patternProperties: + "^ethernet-port@[0-9]+$": + type: object + description: contains the resources for ethernet port + allOf: + - $ref: ethernet-controller.yaml# + properties: + compatible: + const: cortina,gemini-ethernet-port + + reg: + items: + - description: DMA/TOE memory + - description: GMAC memory area of the port + + interrupts: + maxItems: 1 + description: should contain the interrupt line of the port. + this is nominally a level interrupt active high. + + resets: + maxItems: 1 + description: this must provide an SoC-integrated reset line for the port. + + clocks: + maxItems: 1 + description: this should contain a handle to the PCLK clock for + clocking the silicon in this port + + clock-names: + const: PCLK + + required: + - reg + - compatible + - interrupts + - resets + - clocks + - clock-names + +required: + - compatible + - reg + - ranges + +additionalProperties: false + +examples: + - | + #include + #include + #include + mdio0: mdio { + #address-cells = <1>; + #size-cells = <0>; + phy0: ethernet-phy@1 { + reg = <1>; + device_type = "ethernet-phy"; + }; + phy1: ethernet-phy@3 { + reg = <3>; + device_type = "ethernet-phy"; + }; + }; + + + ethernet@60000000 { + compatible = "cortina,gemini-ethernet"; + reg = <0x60000000 0x4000>, /* Global registers, queue */ + <0x60004000 0x2000>, /* V-bit */ + <0x60006000 0x2000>; /* A-bit */ + #address-cells = <1>; + #size-cells = <1>; + ranges; + + gmac0: ethernet-port@0 { + compatible = "cortina,gemini-ethernet-port"; + reg = <0x60008000 0x2000>, /* Port 0 DMA/TOE */ + <0x6000a000 0x2000>; /* Port 0 GMAC */ + interrupt-parent = <&intcon>; + interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; + resets = <&syscon GEMINI_RESET_GMAC0>; + clocks = <&syscon GEMINI_CLK_GATE_GMAC0>; + clock-names = "PCLK"; + phy-mode = "rgmii"; + phy-handle = <&phy0>; + }; + + gmac1: ethernet-port@1 { + compatible = "cortina,gemini-ethernet-port"; + reg = <0x6000c000 0x2000>, /* Port 1 DMA/TOE */ + <0x6000e000 0x2000>; /* Port 1 GMAC */ + interrupt-parent = <&intcon>; + interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; + resets = <&syscon GEMINI_RESET_GMAC1>; + clocks = <&syscon GEMINI_CLK_GATE_GMAC1>; + clock-names = "PCLK"; + phy-mode = "rgmii"; + phy-handle = <&phy1>; + }; + }; -- cgit From 31fc1c63c2ae4a542e3c7ac572a10a59ece45c24 Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Thu, 3 Feb 2022 09:39:29 +0200 Subject: dt-bindings: clock: Add binding for TI clksel In order to prepare for fixing lots of devicetree unique_unit_address warnings for the TI clock nodes, let's add a binding for the TI clksel clocks. This allows us to move the overlapping reg properties for the component clocks to be children of the related clksel nodes. And with that we need the reg property only for the parent clksel node making the reg property unique like it should be. We want to set #clock-cells = <2> in case we ever start parsing ranges of clkcsel instances directly using a clksel driver rather than using the existing component clock drivers and child nodes. And before the devicetree files can be updated, we need to update the TI clock drivers to get the IO address from the parent clksel node. Cc: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220203073929.59296-1-tony@atomide.com --- .../devicetree/bindings/clock/ti/ti,clksel.yaml | 51 ++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/ti/ti,clksel.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti/ti,clksel.yaml b/Documentation/devicetree/bindings/clock/ti/ti,clksel.yaml new file mode 100644 index 000000000000..c56f911fff47 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/ti,clksel.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/ti/ti,clksel.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for TI clksel clock + +maintainers: + - Tony Lindgren + +description: | + The TI CLKSEL clocks consist of consist of input clock mux bits, and in some + cases also has divider, multiplier and gate bits. + +properties: + compatible: + const: ti,clksel + + reg: + maxItems: 1 + description: The CLKSEL register range + + '#address-cells': + enum: [ 0, 1, 2 ] + + '#size-cells': + enum: [ 0, 1, 2 ] + + ranges: true + + "#clock-cells": + const: 2 + description: The CLKSEL register and bit offset + +required: + - compatible + - reg + - "#clock-cells" + +additionalProperties: + type: object + +examples: + - | + clksel_gfx_fclk: clock@52c { + compatible = "ti,clksel"; + reg = <0x25c 0x4>; + #clock-cells = <2>; + }; +... -- cgit From e87d05d85a149fce4ea7564525efbd2e66438036 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 8 Feb 2022 18:18:16 +0100 Subject: dt-bindings: phy: samsung,exynos-hdmi-phy: convert to dtschema Convert the Exynos HDMI PHY bindings to DT schema format and put them next to other PHYs. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220208171823.226211-4-krzysztof.kozlowski@canonical.com --- .../bindings/display/exynos/exynos_hdmiphy.txt | 15 -------- .../bindings/phy/samsung,exynos-hdmi-phy.yaml | 44 ++++++++++++++++++++++ 2 files changed, 44 insertions(+), 15 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_hdmiphy.txt create mode 100644 Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmiphy.txt b/Documentation/devicetree/bindings/display/exynos/exynos_hdmiphy.txt deleted file mode 100644 index 162f641f7639..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmiphy.txt +++ /dev/null @@ -1,15 +0,0 @@ -Device-Tree bindings for hdmiphy driver - -Required properties: -- compatible: value should be one of the following: - 1) "samsung,exynos5-hdmiphy" - 2) "samsung,exynos4210-hdmiphy". - 3) "samsung,exynos4212-hdmiphy". -- reg: I2C address of the hdmiphy device. - -Example: - - hdmiphy { - compatible = "samsung,exynos4210-hdmiphy"; - reg = <0x38>; - }; diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml new file mode 100644 index 000000000000..c61574e10b2a --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/samsung,exynos-hdmi-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC HDMI PHY + +maintainers: + - Inki Dae + - Joonyoung Shim + - Seung-Woo Kim + - Kyungmin Park + - Krzysztof Kozlowski + +properties: + compatible: + oneOf: + - enum: + - samsung,exynos4210-hdmiphy + - samsung,exynos4212-hdmiphy + - const: samsung,exynos5-hdmiphy + deprecated: true + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + hdmi-phy@38 { + compatible = "samsung,exynos4210-hdmiphy"; + reg = <0x38>; + }; + }; -- cgit From f16fe2d3b41fe284a06fe568beaab6a6a5bf7894 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 8 Feb 2022 18:18:17 +0100 Subject: dt-bindings: display: samsung,exynos5433-decon: convert to dtschema Convert the Exynos5433 DECON display controller bindings to DT schema format. The conversion includes also updates to the bindings, matching the current DTS and Linux driver: 1. Require "fifo" interrupt. 2. Add "dsd" as a last clock. 3. Document "power-domains" and "iommus" properties. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220208171823.226211-5-krzysztof.kozlowski@canonical.com --- .../bindings/display/exynos/exynos5433-decon.txt | 60 --------- .../display/samsung/samsung,exynos5433-decon.yaml | 148 +++++++++++++++++++++ 2 files changed, 148 insertions(+), 60 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt create mode 100644 Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt b/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt deleted file mode 100644 index 775193e1c641..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt +++ /dev/null @@ -1,60 +0,0 @@ -Device-Tree bindings for Samsung Exynos SoC display controller (DECON) - -DECON (Display and Enhancement Controller) is the Display Controller for the -Exynos series of SoCs which transfers the image data from a video memory -buffer to an external LCD interface. - -Required properties: -- compatible: value should be one of: - "samsung,exynos5433-decon", "samsung,exynos5433-decon-tv"; -- reg: physical base address and length of the DECON registers set. -- interrupt-names: should contain the interrupt names depending on mode of work: - video mode: "vsync", - command mode: "lcd_sys", - command mode with software trigger: "lcd_sys", "te". -- interrupts or interrupts-extended: list of interrupt specifiers corresponding - to names privided in interrupt-names, as described in - interrupt-controller/interrupts.txt -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. -- clock-names: list of clock names sorted in the same order as the clocks - property. Must contain "pclk", "aclk_decon", "aclk_smmu_decon0x", - "aclk_xiu_decon0x", "pclk_smmu_decon0x", "aclk_smmu_decon1x", - "aclk_xiu_decon1x", "pclk_smmu_decon1x", clk_decon_vclk", - "sclk_decon_eclk" -- ports: contains a port which is connected to mic node. address-cells and - size-cells must 1 and 0, respectively. -- port: contains an endpoint node which is connected to the endpoint in the mic - node. The reg value muset be 0. - -Example: -SoC specific DT entry: -decon: decon@13800000 { - compatible = "samsung,exynos5433-decon"; - reg = <0x13800000 0x2104>; - clocks = <&cmu_disp CLK_ACLK_DECON>, <&cmu_disp CLK_ACLK_SMMU_DECON0X>, - <&cmu_disp CLK_ACLK_XIU_DECON0X>, - <&cmu_disp CLK_PCLK_SMMU_DECON0X>, - <&cmu_disp CLK_ACLK_SMMU_DECON1X>, - <&cmu_disp CLK_ACLK_XIU_DECON1X>, - <&cmu_disp CLK_PCLK_SMMU_DECON1X>, - <&cmu_disp CLK_SCLK_DECON_VCLK>, - <&cmu_disp CLK_SCLK_DECON_ECLK>; - clock-names = "aclk_decon", "aclk_smmu_decon0x", "aclk_xiu_decon0x", - "pclk_smmu_decon0x", "aclk_smmu_decon1x", "aclk_xiu_decon1x", - "pclk_smmu_decon1x", "sclk_decon_vclk", "sclk_decon_eclk"; - interrupt-names = "vsync", "lcd_sys"; - interrupts = <0 202 0>, <0 203 0>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - decon_to_mic: endpoint { - remote-endpoint = <&mic_to_decon>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml new file mode 100644 index 000000000000..6f796835ea03 --- /dev/null +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml @@ -0,0 +1,148 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/samsung/samsung,exynos5433-decon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos5433 SoC Display and Enhancement Controller (DECON) + +maintainers: + - Inki Dae + - Joonyoung Shim + - Seung-Woo Kim + - Kyungmin Park + - Krzysztof Kozlowski + +description: | + DECON (Display and Enhancement Controller) is the Display Controller for the + Exynos5433 series of SoCs which transfers the image data from a video memory + buffer to an external LCD interface. + +properties: + compatible: + enum: + - samsung,exynos5433-decon + - samsung,exynos5433-decon-tv + + clocks: + minItems: 11 + maxItems: 11 + + clock-names: + items: + - const: pclk + - const: aclk_decon + - const: aclk_smmu_decon0x + - const: aclk_xiu_decon0x + - const: pclk_smmu_decon0x + - const: aclk_smmu_decon1x + - const: aclk_xiu_decon1x + - const: pclk_smmu_decon1x + - const: sclk_decon_vclk + - const: sclk_decon_eclk + - const: dsd + + interrupts: + minItems: 3 + maxItems: 4 + description: | + Interrupts depend on mode of work: + - video mode: vsync + - command mode: lcd_sys + - command mode with software trigger: lcd_sys, te + + interrupt-names: + minItems: 3 + items: + - const: fifo + - const: vsync + - const: lcd_sys + - const: te + + iommus: + minItems: 2 + maxItems: 2 + + iommu-names: + items: + - const: m0 + - const: m1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: + Contains a port which is connected to mic node. + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + + samsung,disp-sysreg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to DISP system controller interface. + +required: + - compatible + - clocks + - clock-names + - interrupts + - interrupt-names + - ports + - reg + +additionalProperties: false + +examples: + - | + #include + #include + + display-controller@13800000 { + compatible = "samsung,exynos5433-decon"; + reg = <0x13800000 0x2104>; + clocks = <&cmu_disp CLK_PCLK_DECON>, + <&cmu_disp CLK_ACLK_DECON>, + <&cmu_disp CLK_ACLK_SMMU_DECON0X>, + <&cmu_disp CLK_ACLK_XIU_DECON0X>, + <&cmu_disp CLK_PCLK_SMMU_DECON0X>, + <&cmu_disp CLK_ACLK_SMMU_DECON1X>, + <&cmu_disp CLK_ACLK_XIU_DECON1X>, + <&cmu_disp CLK_PCLK_SMMU_DECON1X>, + <&cmu_disp CLK_SCLK_DECON_VCLK>, + <&cmu_disp CLK_SCLK_DECON_ECLK>, + <&cmu_disp CLK_SCLK_DSD>; + clock-names = "pclk", + "aclk_decon", + "aclk_smmu_decon0x", + "aclk_xiu_decon0x", + "pclk_smmu_decon0x", + "aclk_smmu_decon1x", + "aclk_xiu_decon1x", + "pclk_smmu_decon1x", + "sclk_decon_vclk", + "sclk_decon_eclk", + "dsd"; + power-domains = <&pd_disp>; + interrupt-names = "fifo", "vsync", "lcd_sys"; + interrupts = , + , + ; + samsung,disp-sysreg = <&syscon_disp>; + iommus = <&sysmmu_decon0x>, <&sysmmu_decon1x>; + iommu-names = "m0", "m1"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + decon_to_mic: endpoint { + remote-endpoint = <&mic_to_decon>; + }; + }; + }; + }; -- cgit From 5c45a11b618eb58993930e69da9153e7ce5cd630 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 8 Feb 2022 18:18:18 +0100 Subject: dt-bindings: display: samsung,exynos7-decon: convert to dtschema Convert the Exynos7 DECON display controller bindings to DT schema format. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220208171823.226211-6-krzysztof.kozlowski@canonical.com --- .../bindings/display/exynos/exynos7-decon.txt | 65 ----------- .../display/samsung/samsung,exynos7-decon.yaml | 120 +++++++++++++++++++++ 2 files changed, 120 insertions(+), 65 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt create mode 100644 Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt b/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt deleted file mode 100644 index 53912c99ec38..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt +++ /dev/null @@ -1,65 +0,0 @@ -Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) - -DECON (Display and Enhancement Controller) is the Display Controller for the -Exynos7 series of SoCs which transfers the image data from a video memory -buffer to an external LCD interface. - -Required properties: -- compatible: value should be "samsung,exynos7-decon"; - -- reg: physical base address and length of the DECON registers set. - -- interrupts: should contain a list of all DECON IP block interrupts in the - order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier - format depends on the interrupt controller used. - -- interrupt-names: should contain the interrupt names: "fifo", "vsync", - "lcd_sys", in the same order as they were listed in the interrupts - property. - -- pinctrl-0: pin control group to be used for this controller. - -- pinctrl-names: must contain a "default" entry. - -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. - -- clock-names: list of clock names sorted in the same order as the clocks - property. Must contain "pclk_decon0", "aclk_decon0", - "decon0_eclk", "decon0_vclk". -- i80-if-timings: timing configuration for lcd i80 interface support. - -Optional Properties: -- power-domains: a phandle to DECON power domain node. -- display-timings: timing settings for DECON, as described in document [1]. - Can be used in case timings cannot be provided otherwise - or to override timings provided by the panel. - -[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt - -Example: - -SoC specific DT entry: - - decon@13930000 { - compatible = "samsung,exynos7-decon"; - interrupt-parent = <&combiner>; - reg = <0x13930000 0x1000>; - interrupt-names = "lcd_sys", "vsync", "fifo"; - interrupts = <0 188 0>, <0 189 0>, <0 190 0>; - clocks = <&clock_disp PCLK_DECON_INT>, - <&clock_disp ACLK_DECON_INT>, - <&clock_disp SCLK_DECON_INT_ECLK>, - <&clock_disp SCLK_DECON_INT_EXTCLKPLL>; - clock-names = "pclk_decon0", "aclk_decon0", "decon0_eclk", - "decon0_vclk"; - status = "disabled"; - }; - -Board specific DT entry: - - decon@13930000 { - pinctrl-0 = <&lcd_clk &pwm1_out>; - pinctrl-names = "default"; - status = "okay"; - }; diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml new file mode 100644 index 000000000000..afa137d47922 --- /dev/null +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/samsung/samsung,exynos7-decon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos7 SoC Display and Enhancement Controller (DECON) + +maintainers: + - Inki Dae + - Joonyoung Shim + - Seung-Woo Kim + - Kyungmin Park + - Krzysztof Kozlowski + +description: | + DECON (Display and Enhancement Controller) is the Display Controller for the + Exynos7 series of SoCs which transfers the image data from a video memory + buffer to an external LCD interface. + +properties: + compatible: + const: samsung,exynos7-decon + + clocks: + minItems: 4 + maxItems: 4 + + clock-names: + items: + - const: pclk_decon0 + - const: aclk_decon0 + - const: decon0_eclk + - const: decon0_vclk + + display-timings: + $ref: ../panel/display-timings.yaml# + + i80-if-timings: + type: object + description: timing configuration for lcd i80 interface support + properties: + cs-setup: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of address signal is enabled until + chip select is enabled. + default: 0 + + wr-active: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of CS is enabled. + default: 1 + + wr-hold: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of CS is disabled until write + signal is disabled. + default: 0 + + wr-setup: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of CS signal is enabled until + write signal is enabled. + default: 0 + + interrupts: + items: + - description: FIFO level + - description: VSYNC + - description: LCD system + + interrupt-names: + items: + - const: fifo + - const: vsync + - const: lcd_sys + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - interrupts + - interrupt-names + - reg + +additionalProperties: false + +examples: + - | + #include + #include + + display-controller@13930000 { + compatible = "samsung,exynos7-decon"; + reg = <0x13930000 0x1000>; + interrupt-names = "fifo", "vsync", "lcd_sys"; + interrupts = , + , + ; + clocks = <&clock_disp 100>, /* PCLK_DECON_INT */ + <&clock_disp 101>, /* ACLK_DECON_INT */ + <&clock_disp 102>, /* SCLK_DECON_INT_ECLK */ + <&clock_disp 103>; /* SCLK_DECON_INT_EXTCLKPLL */ + clock-names = "pclk_decon0", + "aclk_decon0", + "decon0_eclk", + "decon0_vclk"; + pinctrl-0 = <&lcd_clk &pwm1_out>; + pinctrl-names = "default"; + }; -- cgit From 6b15415e0303ad9647c9b882d2ebd18142504cbd Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 8 Feb 2022 18:18:19 +0100 Subject: dt-bindings: display: samsung,exynos-hdmi-ddc: convert to dtschema Convert the Exynos HDMI DDC bindings to DT schema format. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220208171823.226211-7-krzysztof.kozlowski@canonical.com --- .../bindings/display/exynos/exynos_hdmiddc.txt | 15 -------- .../display/samsung/samsung,exynos-hdmi-ddc.yaml | 42 ++++++++++++++++++++++ 2 files changed, 42 insertions(+), 15 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_hdmiddc.txt create mode 100644 Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmiddc.txt b/Documentation/devicetree/bindings/display/exynos/exynos_hdmiddc.txt deleted file mode 100644 index 41eee971562b..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmiddc.txt +++ /dev/null @@ -1,15 +0,0 @@ -Device-Tree bindings for hdmiddc driver - -Required properties: -- compatible: value should be one of the following - 1) "samsung,exynos5-hdmiddc" - 2) "samsung,exynos4210-hdmiddc" - -- reg: I2C address of the hdmiddc device. - -Example: - - hdmiddc { - compatible = "samsung,exynos4210-hdmiddc"; - reg = <0x50>; - }; diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml new file mode 100644 index 000000000000..f998a3a5b71f --- /dev/null +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/samsung/samsung,exynos-hdmi-ddc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC HDMI DDC + +maintainers: + - Inki Dae + - Joonyoung Shim + - Seung-Woo Kim + - Kyungmin Park + - Krzysztof Kozlowski + +properties: + compatible: + oneOf: + - const: samsung,exynos4210-hdmiddc + - const: samsung,exynos5-hdmiddc + deprecated: true + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ddc@50 { + compatible = "samsung,exynos4210-hdmiddc"; + reg = <0x50>; + }; + }; -- cgit From 68e89bb36d583ab06f2e21341dd99e57a88c7e81 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 8 Feb 2022 18:18:20 +0100 Subject: dt-bindings: display: samsung,exynos-mixer: convert to dtschema Convert the Exynos Mixer bindings to DT schema format. The conversion includes also updates to the bindings, matching the current DTS and Linux driver: 1. Add clocks required on Exynos4210 and Exynos4212 types of Mixer. 2. Add second memory range on Exynos4210 and Exynos4212. 3. Add interconnects, iommus and power-domains. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220208171823.226211-8-krzysztof.kozlowski@canonical.com --- .../bindings/display/exynos/exynos_mixer.txt | 26 ---- .../display/samsung/samsung,exynos-mixer.yaml | 143 +++++++++++++++++++++ 2 files changed, 143 insertions(+), 26 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_mixer.txt create mode 100644 Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_mixer.txt b/Documentation/devicetree/bindings/display/exynos/exynos_mixer.txt deleted file mode 100644 index 3e38128f866b..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos_mixer.txt +++ /dev/null @@ -1,26 +0,0 @@ -Device-Tree bindings for mixer driver - -Required properties: -- compatible: value should be one of the following: - 1) "samsung,exynos5-mixer" - 2) "samsung,exynos4210-mixer" - 3) "samsung,exynos4212-mixer" - 4) "samsung,exynos5250-mixer" - 5) "samsung,exynos5420-mixer" - -- reg: physical base address of the mixer and length of memory mapped - region. -- interrupts: interrupt number to the cpu. -- clocks: list of clock IDs from SoC clock driver. - a) mixer: Gate of Mixer IP bus clock. - b) sclk_hdmi: HDMI Special clock, one of the two possible inputs of - mixer mux. - c) hdmi: Gate of HDMI IP bus clock, needed together with sclk_hdmi. - -Example: - - mixer { - compatible = "samsung,exynos5250-mixer"; - reg = <0x14450000 0x10000>; - interrupts = <0 94 0>; - }; diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml new file mode 100644 index 000000000000..ba40284ac66f --- /dev/null +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml @@ -0,0 +1,143 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/samsung/samsung,exynos-mixer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC Mixer + +maintainers: + - Inki Dae + - Joonyoung Shim + - Seung-Woo Kim + - Kyungmin Park + - Krzysztof Kozlowski + +description: + Samsung Exynos SoC Mixer is responsible for mixing and blending multiple data + inputs before passing it to an output device. The output is passed to HDMI. + +properties: + compatible: + oneOf: + - enum: + - samsung,exynos4210-mixer + - samsung,exynos4212-mixer + - samsung,exynos5250-mixer + - samsung,exynos5420-mixer + - const: samsung,exynos5-mixer + deprecated: true + + clocks: + minItems: 3 + items: + - description: Gate of Mixer IP bus clock. + - description: Gate of HDMI IP bus clock, needed together with sclk_hdmi. + - description: HDMI Special clock, one of the two possible inputs of + mixer mux. + - description: Video Processor clock. + - description: Mixer mux clock. + - description: Mixer Special clock. + + clock-names: + minItems: 3 + items: + - const: mixer + - const: hdmi + - const: sclk_hdmi + - const: vp + - const: mout_mixer + - const: sclk_mixer + + interconnects: + maxItems: 1 + + interrupts: + maxItems: 1 + + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + + reg: + minItems: 1 + items: + - description: Mixer memory region. + - description: Video Processor memory region. + +required: + - compatible + - clocks + - clock-names + - interrupts + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos4210-mixer + - samsung,exynos4212-mixer + then: + properties: + clocks: + minItems: 6 + maxItems: 6 + regs: + minItems: 2 + maxItems: 2 + + - if: + properties: + compatible: + contains: + const: samsung,exynos4212-mixer + then: + properties: + clocks: + minItems: 4 + maxItems: 4 + regs: + minItems: 2 + maxItems: 2 + + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos5-mixer + - samsung,exynos5250-mixer + - samsung,exynos5420-mixer + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + regs: + minItems: 1 + maxItems: 1 + +additionalProperties: false + +examples: + - | + #include + #include + + mixer@14450000 { + compatible = "samsung,exynos5250-mixer"; + reg = <0x14450000 0x10000>; + interrupts = ; + clocks = <&clock CLK_MIXER>, + <&clock CLK_HDMI>, + <&clock CLK_SCLK_HDMI>; + clock-names = "mixer", + "hdmi", + "sclk_hdmi"; + iommus = <&sysmmu_tv>; + power-domains = <&pd_disp1>; + }; -- cgit From a5032991e108f88ac8a69452b24fa9c8b4621352 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 8 Feb 2022 18:18:21 +0100 Subject: dt-bindings: display: samsung,exynos-hdmi: convert to dtschema Convert the Exynos HDMI bindings to DT schema format. The conversion includes also updates to the bindings, matching the current DTS and Linux driver: 1. Add required properties: VDD supplies, power-domains. 2. Add optional properties: HDMI-EN supply, ports. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220208171823.226211-9-krzysztof.kozlowski@canonical.com --- .../bindings/display/exynos/exynos_hdmi.txt | 64 ------ .../display/samsung/samsung,exynos-hdmi.yaml | 227 +++++++++++++++++++++ 2 files changed, 227 insertions(+), 64 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt create mode 100644 Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt deleted file mode 100644 index 58b12e25bbb1..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt +++ /dev/null @@ -1,64 +0,0 @@ -Device-Tree bindings for drm hdmi driver - -Required properties: -- compatible: value should be one among the following: - 1) "samsung,exynos4210-hdmi" - 2) "samsung,exynos4212-hdmi" - 3) "samsung,exynos5420-hdmi" - 4) "samsung,exynos5433-hdmi" -- reg: physical base address of the hdmi and length of memory mapped - region. -- interrupts: interrupt number to the cpu. -- hpd-gpios: following information about the hotplug gpio pin. - a) phandle of the gpio controller node. - b) pin number within the gpio controller. - c) optional flags and pull up/down. -- ddc: phandle to the hdmi ddc node -- phy: phandle to the hdmi phy node -- samsung,syscon-phandle: phandle for system controller node for PMU. -- #sound-dai-cells: should be 0. - -Required properties for Exynos 4210, 4212, 5420 and 5433: -- clocks: list of clock IDs from SoC clock driver. - a) hdmi: Gate of HDMI IP bus clock. - b) sclk_hdmi: Gate of HDMI special clock. - c) sclk_pixel: Pixel special clock, one of the two possible inputs of - HDMI clock mux. - d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of - HDMI clock mux. - e) mout_hdmi: It is required by the driver to switch between the 2 - parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable - after configuration, parent is set to sclk_hdmiphy else - sclk_pixel. -- clock-names: aliases as per driver requirements for above clock IDs: - "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi". - -Required properties for Exynos 5433: -- clocks: list of clock specifiers according to common clock bindings. - a) hdmi_pclk: Gate of HDMI IP APB bus. - b) hdmi_i_pclk: Gate of HDMI-PHY IP APB bus. - d) i_tmds_clk: Gate of HDMI TMDS clock. - e) i_pixel_clk: Gate of HDMI pixel clock. - f) i_spdif_clk: Gate of HDMI SPDIF clock. - g) oscclk: Oscillator clock, used as parent of following *_user clocks - in case HDMI-PHY is not operational. - h) tmds_clko: TMDS clock generated by HDMI-PHY. - i) tmds_clko_user: MUX used to switch between oscclk and tmds_clko, - respectively if HDMI-PHY is off and operational. - j) pixel_clko: Pixel clock generated by HDMI-PHY. - k) pixel_clko_user: MUX used to switch between oscclk and pixel_clko, - respectively if HDMI-PHY is off and operational. -- clock-names: aliases for above clock specfiers. -- samsung,sysreg: handle to syscon used to control the system registers. - -Example: - - hdmi { - compatible = "samsung,exynos4212-hdmi"; - reg = <0x14530000 0x100000>; - interrupts = <0 95 0>; - hpd-gpios = <&gpx3 7 1>; - ddc = <&hdmi_ddc_node>; - phy = <&hdmi_phy_node>; - samsung,syscon-phandle = <&pmu_system_controller>; - }; diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml new file mode 100644 index 000000000000..cb8e735ce3bd --- /dev/null +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml @@ -0,0 +1,227 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/samsung/samsung,exynos-hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC HDMI + +maintainers: + - Inki Dae + - Joonyoung Shim + - Seung-Woo Kim + - Kyungmin Park + - Krzysztof Kozlowski + +properties: + compatible: + enum: + - samsung,exynos4210-hdmi + - samsung,exynos4212-hdmi + - samsung,exynos5420-hdmi + - samsung,exynos5433-hdmi + + clocks: + minItems: 5 + maxItems: 10 + + clock-names: + minItems: 5 + maxItems: 10 + + ddc: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the HDMI DDC node. + + hdmi-en-supply: + description: + Provides voltage source for DCC lines available on HDMI connector. When + there is no power provided for DDC epprom, some TV-sets do not pulls up + HPD (hot plug detect) line, what causes HDMI block to stay turned off. + When provided, the regulator allows TV-set correctly signal HPD event. + + hpd-gpios: + maxItems: 1 + description: + A GPIO line connected to HPD + + interrupts: + maxItems: 1 + + phy: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to the HDMI PHY node. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: + Contains a port which is connected to mic node. + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + + samsung,syscon-phandle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the PMU system controller node. + + samsung,sysreg-phandle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to DISP system controller interface. + + '#sound-dai-cells': + const: 0 + + vdd-supply: + description: + VDD 1.0V HDMI TX. + + vdd_osc-supply: + description: + VDD 1.8V HDMI OSC. + + vdd_pll-supply: + description: + VDD 1.0V HDMI PLL. + +required: + - compatible + - clocks + - clock-names + - ddc + - hpd-gpios + - interrupts + - phy + - reg + - samsung,syscon-phandle + - '#sound-dai-cells' + - vdd-supply + - vdd_osc-supply + - vdd_pll-supply + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos5433-hdmi + then: + properties: + clocks: + items: + - description: Gate of HDMI IP APB bus. + - description: Gate of HDMI-PHY IP APB bus. + - description: Gate of HDMI TMDS clock. + - description: Gate of HDMI pixel clock. + - description: TMDS clock generated by HDMI-PHY. + - description: MUX used to switch between oscclk and tmds_clko, + respectively if HDMI-PHY is off and operational. + - description: Pixel clock generated by HDMI-PHY. + - description: MUX used to switch between oscclk and pixel_clko, + respectively if HDMI-PHY is off and operational. + - description: Oscillator clock, used as parent of following *_user + clocks in case HDMI-PHY is not operational. + - description: Gate of HDMI SPDIF clock. + clock-names: + items: + - const: hdmi_pclk + - const: hdmi_i_pclk + - const: i_tmds_clk + - const: i_pixel_clk + - const: tmds_clko + - const: tmds_clko_user + - const: pixel_clko + - const: pixel_clko_user + - const: oscclk + - const: i_spdif_clk + required: + - samsung,sysreg-phandle + else: + properties: + clocks: + items: + - description: Gate of HDMI IP bus clock. + - description: Gate of HDMI special clock. + - description: Pixel special clock, one of the two possible inputs + of HDMI clock mux. + - description: HDMI PHY clock output, one of two possible inputs of + HDMI clock mux. + - description: It is required by the driver to switch between the 2 + parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable + after configuration, parent is set to sclk_hdmiphy else + sclk_pixel. + clock-names: + items: + - const: hdmi + - const: sclk_hdmi + - const: sclk_pixel + - const: sclk_hdmiphy + - const: mout_hdmi + +additionalProperties: false + +examples: + - | + #include + #include + #include + + hdmi@13970000 { + compatible = "samsung,exynos5433-hdmi"; + reg = <0x13970000 0x70000>; + interrupts = ; + clocks = <&cmu_disp CLK_PCLK_HDMI>, + <&cmu_disp CLK_PCLK_HDMIPHY>, + <&cmu_disp CLK_PHYCLK_HDMIPHY_TMDS_CLKO>, + <&cmu_disp CLK_PHYCLK_HDMI_PIXEL>, + <&cmu_disp CLK_PHYCLK_HDMIPHY_TMDS_CLKO_PHY>, + <&cmu_disp CLK_MOUT_PHYCLK_HDMIPHY_TMDS_CLKO_USER>, + <&cmu_disp CLK_PHYCLK_HDMIPHY_PIXEL_CLKO_PHY>, + <&cmu_disp CLK_MOUT_PHYCLK_HDMIPHY_PIXEL_CLKO_USER>, + <&xxti>, + <&cmu_disp CLK_SCLK_HDMI_SPDIF>; + clock-names = "hdmi_pclk", + "hdmi_i_pclk", + "i_tmds_clk", + "i_pixel_clk", + "tmds_clko", + "tmds_clko_user", + "pixel_clko", + "pixel_clko_user", + "oscclk", + "i_spdif_clk"; + phy = <&hdmiphy>; + ddc = <&hsi2c_11>; + samsung,syscon-phandle = <&pmu_system_controller>; + samsung,sysreg-phandle = <&syscon_disp>; + #sound-dai-cells = <0>; + + hpd-gpios = <&gpa3 0 GPIO_ACTIVE_HIGH>; + vdd-supply = <&ldo6_reg>; + vdd_osc-supply = <&ldo7_reg>; + vdd_pll-supply = <&ldo6_reg>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + hdmi_to_tv: endpoint { + remote-endpoint = <&tv_to_hdmi>; + }; + }; + + port@1 { + reg = <1>; + hdmi_to_mhl: endpoint { + remote-endpoint = <&mhl_to_hdmi>; + }; + }; + }; + }; -- cgit From 4c5e180b83edbd1199e948050fe8f5fc17fc26d5 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 8 Feb 2022 18:18:22 +0100 Subject: dt-bindings: display: samsung,exynos5433-mic: convert to dtschema Convert the Exynos5433 MIC bindings to DT schema format. The conversion includes also updates to the bindings, matching the current DTS and Linux driver: adding optional power-domains. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220208171823.226211-10-krzysztof.kozlowski@canonical.com --- .../bindings/display/exynos/exynos-mic.txt | 51 ------------ .../display/samsung/samsung,exynos5433-mic.yaml | 95 ++++++++++++++++++++++ 2 files changed, 95 insertions(+), 51 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/exynos/exynos-mic.txt create mode 100644 Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/exynos/exynos-mic.txt b/Documentation/devicetree/bindings/display/exynos/exynos-mic.txt deleted file mode 100644 index 0fba2ee6440a..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos-mic.txt +++ /dev/null @@ -1,51 +0,0 @@ -Device-Tree bindings for Samsung Exynos SoC mobile image compressor (MIC) - -MIC (mobile image compressor) resides between decon and mipi dsi. Mipi dsi is -not capable to transfer high resoltuion frame data as decon can send. MIC -solves this problem by compressing the frame data by 1/2 before it is -transferred through mipi dsi. The compressed frame data must be uncompressed in -the panel PCB. - -Required properties: -- compatible: value should be "samsung,exynos5433-mic". -- reg: physical base address and length of the MIC registers set and system - register of mic. -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. -- clock-names: list of clock names sorted in the same order as the clocks - property. Must contain "pclk_mic0", "sclk_rgb_vclk_to_mic0". -- samsung,disp-syscon: the reference node for syscon for DISP block. -- ports: contains a port which is connected to decon node and dsi node. - address-cells and size-cells must 1 and 0, respectively. -- port: contains an endpoint node which is connected to the endpoint in the - decon node or dsi node. The reg value must be 0 and 1 respectively. - -Example: -SoC specific DT entry: -mic: mic@13930000 { - compatible = "samsung,exynos5433-mic"; - reg = <0x13930000 0x48>; - clocks = <&cmu_disp CLK_PCLK_MIC0>, - <&cmu_disp CLK_SCLK_RGB_VCLK_TO_MIC0>; - clock-names = "pclk_mic0", "sclk_rgb_vclk_to_mic0"; - samsung,disp-syscon = <&syscon_disp>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - mic_to_decon: endpoint { - remote-endpoint = <&decon_to_mic>; - }; - }; - - port@1 { - reg = <1>; - mic_to_dsi: endpoint { - remote-endpoint = <&dsi_to_mic>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml new file mode 100644 index 000000000000..01fccb138ebd --- /dev/null +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/samsung/samsung,exynos5433-mic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos5433 SoC Mobile Image Compressor (MIC) + +maintainers: + - Inki Dae + - Joonyoung Shim + - Seung-Woo Kim + - Kyungmin Park + - Krzysztof Kozlowski + +description: | + MIC (Mobile Image Compressor) resides between DECON and MIPI DSI. MIPI DSI is + not capable of transferring high resoltuion frame data as DECON can send. MIC + solves this problem by compressing the frame data by 1/2 before it is + transferred through MIPI DSI. The compressed frame data must be uncompressed + in the panel PCB. + +properties: + compatible: + const: samsung,exynos5433-mic + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: pclk_mic0 + - const: sclk_rgb_vclk_to_mic0 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: + Contains a port which is connected to mic node. + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + + samsung,disp-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to DISP system controller interface. + +required: + - compatible + - clocks + - clock-names + - ports + - reg + - samsung,disp-syscon + +additionalProperties: false + +examples: + - | + #include + #include + + image-processor@13930000 { + compatible = "samsung,exynos5433-mic"; + reg = <0x13930000 0x48>; + clocks = <&cmu_disp CLK_PCLK_MIC0>, + <&cmu_disp CLK_SCLK_RGB_VCLK_TO_MIC0>; + clock-names = "pclk_mic0", + "sclk_rgb_vclk_to_mic0"; + power-domains = <&pd_disp>; + samsung,disp-syscon = <&syscon_disp>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + mic_to_decon: endpoint { + remote-endpoint = <&decon_to_mic>; + }; + }; + + port@1 { + reg = <1>; + mic_to_dsi: endpoint { + remote-endpoint = <&dsi_to_mic>; + }; + }; + }; + }; -- cgit From e4fc20d74a1809067304556bc2ba860683bbf4a6 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 8 Feb 2022 18:18:23 +0100 Subject: dt-bindings: display: samsung,exynos-fimd: convert to dtschema Convert the S3C/S5P/Exynos FIMD bindings to DT schema format. The conversion includes also updates to the bindings, matching the current DTS and Linux driver: adding optional iommus and power-domains. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220208171823.226211-11-krzysztof.kozlowski@canonical.com --- .../bindings/display/exynos/samsung-fimd.txt | 107 ----------- .../bindings/display/samsung/samsung,fimd.yaml | 198 +++++++++++++++++++++ 2 files changed, 198 insertions(+), 107 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt create mode 100644 Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt b/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt deleted file mode 100644 index b3096421d42b..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt +++ /dev/null @@ -1,107 +0,0 @@ -Device-Tree bindings for Samsung SoC display controller (FIMD) - -FIMD (Fully Interactive Mobile Display) is the Display Controller for the -Samsung series of SoCs which transfers the image data from a video memory -buffer to an external LCD interface. - -Required properties: -- compatible: value should be one of the following - "samsung,s3c2443-fimd"; /* for S3C24XX SoCs */ - "samsung,s3c6400-fimd"; /* for S3C64XX SoCs */ - "samsung,s5pv210-fimd"; /* for S5PV210 SoC */ - "samsung,exynos3250-fimd"; /* for Exynos3250/3472 SoCs */ - "samsung,exynos4210-fimd"; /* for Exynos4 SoCs */ - "samsung,exynos5250-fimd"; /* for Exynos5250 SoCs */ - "samsung,exynos5420-fimd"; /* for Exynos5420/5422/5800 SoCs */ - -- reg: physical base address and length of the FIMD registers set. - -- interrupts: should contain a list of all FIMD IP block interrupts in the - order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier - format depends on the interrupt controller used. - -- interrupt-names: should contain the interrupt names: "fifo", "vsync", - "lcd_sys", in the same order as they were listed in the interrupts - property. - -- pinctrl-0: pin control group to be used for this controller. - -- pinctrl-names: must contain a "default" entry. - -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. - -- clock-names: list of clock names sorted in the same order as the clocks - property. Must contain "sclk_fimd" and "fimd". - -Optional Properties: -- power-domains: a phandle to FIMD power domain node. -- samsung,invert-vden: video enable signal is inverted -- samsung,invert-vclk: video clock signal is inverted -- display-timings: timing settings for FIMD, as described in document [1]. - Can be used in case timings cannot be provided otherwise - or to override timings provided by the panel. -- samsung,sysreg: handle to syscon used to control the system registers -- i80-if-timings: timing configuration for lcd i80 interface support. - - cs-setup: clock cycles for the active period of address signal is enabled - until chip select is enabled. - If not specified, the default value(0) will be used. - - wr-setup: clock cycles for the active period of CS signal is enabled until - write signal is enabled. - If not specified, the default value(0) will be used. - - wr-active: clock cycles for the active period of CS is enabled. - If not specified, the default value(1) will be used. - - wr-hold: clock cycles for the active period of CS is disabled until write - signal is disabled. - If not specified, the default value(0) will be used. - - The parameters are defined as: - - VCLK(internal) __|??????|_____|??????|_____|??????|_____|??????|_____|?? - : : : : : - Address Output --:| : : : - Chip Select ???????????????|____________:____________:____________|?? - | wr-setup+1 | | wr-hold+1 | - |<---------->| |<---------->| - Write Enable ????????????????????????????|____________|??????????????? - | wr-active+1| - |<---------->| - Video Data ------------------------------ - -The device node can contain 'port' child nodes according to the bindings defined -in [2]. The following are properties specific to those nodes: -- reg: (required) port index, can be: - 0 - for CAMIF0 input, - 1 - for CAMIF1 input, - 2 - for CAMIF2 input, - 3 - for parallel output, - 4 - for write-back interface - -[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt -[2]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - -SoC specific DT entry: - - fimd@11c00000 { - compatible = "samsung,exynos4210-fimd"; - interrupt-parent = <&combiner>; - reg = <0x11c00000 0x20000>; - interrupt-names = "fifo", "vsync", "lcd_sys"; - interrupts = <11 0>, <11 1>, <11 2>; - clocks = <&clock 140>, <&clock 283>; - clock-names = "sclk_fimd", "fimd"; - power-domains = <&pd_lcd0>; - status = "disabled"; - }; - -Board specific DT entry: - - fimd@11c00000 { - pinctrl-0 = <&lcd_clk &lcd_data24 &pwm1_out>; - pinctrl-names = "default"; - status = "okay"; - }; diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml new file mode 100644 index 000000000000..9cf5f120d516 --- /dev/null +++ b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml @@ -0,0 +1,198 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/samsung/samsung,fimd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C/S5P/Exynos SoC Fully Interactive Mobile Display (FIMD) + +maintainers: + - Inki Dae + - Joonyoung Shim + - Seung-Woo Kim + - Kyungmin Park + - Krzysztof Kozlowski + +properties: + compatible: + enum: + - samsung,s3c2443-fimd + - samsung,s3c6400-fimd + - samsung,s5pv210-fimd + - samsung,exynos3250-fimd + - samsung,exynos4210-fimd + - samsung,exynos5250-fimd + - samsung,exynos5420-fimd + + '#address-cells': + const: 1 + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: sclk_fimd + - const: fimd + + display-timings: + $ref: ../panel/display-timings.yaml# + + i80-if-timings: + type: object + description: | + Timing configuration for lcd i80 interface support. + The parameters are defined as:: + VCLK(internal) __|??????|_____|??????|_____|??????|_____|??????|_____|?? + : : : : : + Address Output --:| : : : + Chip Select ???????????????|____________:____________:____________|?? + | wr-setup+1 | | wr-hold+1 | + |<---------->| |<---------->| + Write Enable ????????????????????????????|____________|??????????????? + | wr-active+1| + |<---------->| + Video Data ------------------------------ + + properties: + cs-setup: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of address signal is enabled until + chip select is enabled. + default: 0 + + wr-active: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of CS is enabled. + default: 1 + + wr-hold: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of CS is disabled until write + signal is disabled. + default: 0 + + wr-setup: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of CS signal is enabled until + write signal is enabled. + default: 0 + + iommus: + minItems: 1 + maxItems: 2 + + iommu-names: + items: + - const: m0 + - const: m1 + + interrupts: + items: + - description: FIFO level + - description: VSYNC + - description: LCD system + + interrupt-names: + items: + - const: fifo + - const: vsync + - const: lcd_sys + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + + samsung,invert-vden: + type: boolean + description: + Video enable signal is inverted. + + samsung,invert-vclk: + type: boolean + description: + Video clock signal is inverted. + + samsung,sysreg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to System Register syscon. + + '#size-cells': + const: 0 + +patternProperties: + "^port@[0-4]+$": + $ref: /schemas/graph.yaml#/properties/port + description: | + Contains ports with port with index:: + 0 - for CAMIF0 input, + 1 - for CAMIF1 input, + 2 - for CAMIF2 input, + 3 - for parallel output, + 4 - for write-back interface + +required: + - compatible + - clocks + - clock-names + - interrupts + - interrupt-names + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos5420-fimd + then: + properties: + iommus: + minItems: 2 + maxItems: 2 + +additionalProperties: false + +examples: + - | + #include + + fimd@11c00000 { + compatible = "samsung,exynos4210-fimd"; + interrupt-parent = <&combiner>; + reg = <0x11c00000 0x20000>; + interrupt-names = "fifo", "vsync", "lcd_sys"; + interrupts = <11 0>, <11 1>, <11 2>; + clocks = <&clock CLK_SCLK_FIMD0>, <&clock CLK_FIMD0>; + clock-names = "sclk_fimd", "fimd"; + power-domains = <&pd_lcd0>; + iommus = <&sysmmu_fimd0>; + samsung,sysreg = <&sys_reg>; + + #address-cells = <1>; + #size-cells = <0>; + + samsung,invert-vden; + samsung,invert-vclk; + + pinctrl-0 = <&lcd_clk>, <&lcd_data24>; + pinctrl-names = "default"; + + port@3 { + reg = <3>; + + fimd_dpi_ep: endpoint { + remote-endpoint = <&lcd_ep>; + }; + }; + }; -- cgit From c9edbe1eb98248c290d93aa2ffdc30cab5e2e62c Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Wed, 29 Dec 2021 20:44:19 +0900 Subject: docs: sphinx/kfigure.py: Use rsvg-convert(1) for DOT -> PDF conversion On openSUSE, dot(1) command does not support direct PDF output. On other distros, generated PDF images have unnecessarily wide margins, especially for small graphs. By using dot(1) for DOT -> SVG, then rsvg-convert(1) for SVG -> PDF, more optimal PDF images can be obtained, with the bonus of improved portability across various distros. Add rules in kfigure.py so that the above mentioned route is taken when rsvg-convert(1) is available. Note that rsvg-convert(1) is recommended by sphinx_pre_install. So it is most likely that existing systems for building pdfdocs have rsvg-convert(1) installed. Note: SVG features supported by rsvg-convert(1) vary depending on its version and distro config. For example, the one found on Ubuntu Bionic (version 2.40.20) does poor job in rendering some of SVG files drawn by Inkscape. SVG files generated by dot(1) are converted nicely even with such old versions of rsvg-convert. So this change does not affect the quality of such figures in any way. Signed-off-by: Akira Yokosawa Cc: Jonathan Corbet Cc: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/15b56dd3-081a-2469-c3a4-dfc1ca4c6c2d@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/sphinx/kfigure.py | 46 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 44 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sphinx/kfigure.py b/Documentation/sphinx/kfigure.py index 3c78828330be..955e3ec5de5a 100644 --- a/Documentation/sphinx/kfigure.py +++ b/Documentation/sphinx/kfigure.py @@ -31,6 +31,8 @@ u""" * ``dot(1)``: Graphviz (https://www.graphviz.org). If Graphviz is not available, the DOT language is inserted as literal-block. + For conversion to PDF, ``rsvg-convert(1)`` of librsvg + (https://gitlab.gnome.org/GNOME/librsvg) is used when available. * SVG to PDF: To generate PDF, you need at least one of this tools: @@ -113,6 +115,9 @@ dot_cmd = None # ImageMagick' convert(1) support convert_cmd = None +# librsvg's rsvg-convert(1) support +rsvg_convert_cmd = None + def setup(app): # check toolchain first @@ -160,11 +165,12 @@ def setupTools(app): This function is called once, when the builder is initiated. """ - global dot_cmd, convert_cmd # pylint: disable=W0603 + global dot_cmd, convert_cmd, rsvg_convert_cmd # pylint: disable=W0603 kernellog.verbose(app, "kfigure: check installed tools ...") dot_cmd = which('dot') convert_cmd = which('convert') + rsvg_convert_cmd = which('rsvg-convert') if dot_cmd: kernellog.verbose(app, "use dot(1) from: " + dot_cmd) @@ -177,6 +183,11 @@ def setupTools(app): kernellog.warn(app, "convert(1) not found, for SVG to PDF conversion install " "ImageMagick (https://www.imagemagick.org)") + if rsvg_convert_cmd: + kernellog.verbose(app, "use rsvg-convert(1) from: " + rsvg_convert_cmd) + else: + kernellog.verbose(app, "rsvg-convert(1) not found, " + "falling back to raster image conversion") # integrate conversion tools @@ -266,7 +277,13 @@ def convert_image(img_node, translator, src_fname=None): if in_ext == '.dot': kernellog.verbose(app, 'convert DOT to: {out}/' + _name) - ok = dot2format(app, src_fname, dst_fname) + if translator.builder.format == 'latex': + svg_fname = path.join(translator.builder.outdir, fname + '.svg') + ok1 = dot2format(app, src_fname, svg_fname) + ok2 = svg2pdf_by_rsvg(app, svg_fname, dst_fname) + ok = ok1 and ok2 + else: + ok = dot2format(app, src_fname, dst_fname) elif in_ext == '.svg': kernellog.verbose(app, 'convert SVG to: {out}/' + _name) @@ -319,6 +336,31 @@ def svg2pdf(app, svg_fname, pdf_fname): kernellog.warn(app, "Error #%d when calling: %s" % (exit_code, " ".join(cmd))) return bool(exit_code == 0) +def svg2pdf_by_rsvg(app, svg_fname, pdf_fname): + """Convert SVG to PDF with ``rsvg-convert(1)`` command. + + * ``svg_fname`` pathname of input SVG file, including extension ``.svg`` + * ``pdf_fname`` pathname of output PDF file, including extension ``.pdf`` + + Input SVG file should be the one generated by ``dot2format()``. + SVG -> PDF conversion is done by ``rsvg-convert(1)``. + + If ``rsvg-convert(1)`` is unavailable, fall back to ``svg2pdf()``. + + """ + + if rsvg_convert_cmd is None: + ok = svg2pdf(app, svg_fname, pdf_fname) + else: + cmd = [rsvg_convert_cmd, '--format=pdf', '-o', pdf_fname, svg_fname] + # use stdout and stderr from parent + exit_code = subprocess.call(cmd) + if exit_code != 0: + kernellog.warn(app, "Error #%d when calling: %s" % (exit_code, " ".join(cmd))) + ok = bool(exit_code == 0) + + return ok + # image handling # --------------------- -- cgit From ecf5fb58cdcd93b9cf555b95da4ef73b1297de4c Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Wed, 29 Dec 2021 20:45:29 +0900 Subject: docs: sphinx/kfigure.py: Add check of 'dot -Tpdf' To prevent any regression on existing build systems, limit the fallback of converting DOT -> raster PDF only when both of the following conditions are met. o dot(1) doesn't support -Tpdf o rsvg-convert(1) is not found While we are here, add kernellog.verbose messages related to rsvg-convert, 'dot -Tpdf', and 'dot -Tsvg' commands. Suggested-by: Mauro Carvalho Chehab Signed-off-by: Akira Yokosawa Cc: Jonathan Corbet Link: https://lore.kernel.org/r/e76f61e1-7366-ba00-b119-8ea6a2499861@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/sphinx/kfigure.py | 30 ++++++++++++++++++++++++++---- 1 file changed, 26 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sphinx/kfigure.py b/Documentation/sphinx/kfigure.py index 955e3ec5de5a..77b0d15dba31 100644 --- a/Documentation/sphinx/kfigure.py +++ b/Documentation/sphinx/kfigure.py @@ -51,6 +51,7 @@ import os from os import path import subprocess from hashlib import sha1 +import re from docutils import nodes from docutils.statemachine import ViewList from docutils.parsers.rst import directives @@ -111,6 +112,8 @@ def pass_handle(self, node): # pylint: disable=W0613 # Graphviz's dot(1) support dot_cmd = None +# dot(1) -Tpdf should be used +dot_Tpdf = False # ImageMagick' convert(1) support convert_cmd = None @@ -165,7 +168,7 @@ def setupTools(app): This function is called once, when the builder is initiated. """ - global dot_cmd, convert_cmd, rsvg_convert_cmd # pylint: disable=W0603 + global dot_cmd, dot_Tpdf, convert_cmd, rsvg_convert_cmd # pylint: disable=W0603 kernellog.verbose(app, "kfigure: check installed tools ...") dot_cmd = which('dot') @@ -174,6 +177,16 @@ def setupTools(app): if dot_cmd: kernellog.verbose(app, "use dot(1) from: " + dot_cmd) + + try: + dot_Thelp_list = subprocess.check_output([dot_cmd, '-Thelp'], + stderr=subprocess.STDOUT) + except subprocess.CalledProcessError as err: + dot_Thelp_list = err.output + pass + + dot_Tpdf_ptn = b'pdf' + dot_Tpdf = re.search(dot_Tpdf_ptn, dot_Thelp_list) else: kernellog.warn(app, "dot(1) not found, for better output quality install " "graphviz from https://www.graphviz.org") @@ -185,9 +198,17 @@ def setupTools(app): "ImageMagick (https://www.imagemagick.org)") if rsvg_convert_cmd: kernellog.verbose(app, "use rsvg-convert(1) from: " + rsvg_convert_cmd) + kernellog.verbose(app, "use 'dot -Tsvg' and rsvg-convert(1) for DOT -> PDF conversion") + dot_Tpdf = False else: - kernellog.verbose(app, "rsvg-convert(1) not found, " - "falling back to raster image conversion") + kernellog.verbose(app, + "rsvg-convert(1) not found.\n" + " SVG -> PDF conversion by convert() can be poor quality.\n" + " Install librsvg (https://gitlab.gnome.org/GNOME/librsvg)") + if dot_Tpdf: + kernellog.verbose(app, "use 'dot -Tpdf' for DOT -> PDF conversion") + else: + kernellog.verbose(app, "use 'dot -Tsvg' and convert(1) for DOT -> PDF conversion") # integrate conversion tools @@ -277,11 +298,12 @@ def convert_image(img_node, translator, src_fname=None): if in_ext == '.dot': kernellog.verbose(app, 'convert DOT to: {out}/' + _name) - if translator.builder.format == 'latex': + if translator.builder.format == 'latex' and not dot_Tpdf: svg_fname = path.join(translator.builder.outdir, fname + '.svg') ok1 = dot2format(app, src_fname, svg_fname) ok2 = svg2pdf_by_rsvg(app, svg_fname, dst_fname) ok = ok1 and ok2 + else: ok = dot2format(app, src_fname, dst_fname) -- cgit From 8ccd05697a9d2f837f77a858e81ba13cdb50adac Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Wed, 29 Dec 2021 20:46:58 +0900 Subject: docs: sphinx/kfigure.py: Use inkscape(1) for SVG -> PDF conversion Using convert(1) of ImageMagick for SVG -> PDF conversion results in PDFs containing raster (bitmap) images which sometimes look blurry. Ideally speaking, SVG to PDF conversion should retain vector graphics in SVG. rsvg-convert(1) can do such conversions with regard to SVG files generated by dot(1). Unfortunately, rsvg-convert(1) does not cover some of SVG features specific to Inkscape. inkscape(1) of Inkscape naturally covers such SVG features. So add a route in svg2pdf() so that inkscape(1) is used when it is available. Note: After this change, if you have Inkscape installed, ImageMagick nor librsvg are not required. Signed-off-by: Akira Yokosawa Cc: Jonathan Corbet Cc: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/3eea2a8d-c52d-ee07-cf7b-83784c6f6e4b@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/sphinx/kfigure.py | 68 +++++++++++++++++++++++++++++------------ 1 file changed, 48 insertions(+), 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sphinx/kfigure.py b/Documentation/sphinx/kfigure.py index 77b0d15dba31..e616e49669eb 100644 --- a/Documentation/sphinx/kfigure.py +++ b/Documentation/sphinx/kfigure.py @@ -37,6 +37,7 @@ u""" * SVG to PDF: To generate PDF, you need at least one of this tools: - ``convert(1)``: ImageMagick (https://www.imagemagick.org) + - ``inkscape(1)``: Inkscape (https://inkscape.org/) List of customizations: @@ -121,6 +122,11 @@ convert_cmd = None # librsvg's rsvg-convert(1) support rsvg_convert_cmd = None +# Inkscape's inkscape(1) support +inkscape_cmd = None +# Inkscape prior to 1.0 uses different command options +inkscape_ver_one = False + def setup(app): # check toolchain first @@ -169,11 +175,13 @@ def setupTools(app): This function is called once, when the builder is initiated. """ global dot_cmd, dot_Tpdf, convert_cmd, rsvg_convert_cmd # pylint: disable=W0603 + global inkscape_cmd, inkscape_ver_one # pylint: disable=W0603 kernellog.verbose(app, "kfigure: check installed tools ...") dot_cmd = which('dot') convert_cmd = which('convert') rsvg_convert_cmd = which('rsvg-convert') + inkscape_cmd = which('inkscape') if dot_cmd: kernellog.verbose(app, "use dot(1) from: " + dot_cmd) @@ -190,25 +198,37 @@ def setupTools(app): else: kernellog.warn(app, "dot(1) not found, for better output quality install " "graphviz from https://www.graphviz.org") - if convert_cmd: - kernellog.verbose(app, "use convert(1) from: " + convert_cmd) - else: - kernellog.warn(app, - "convert(1) not found, for SVG to PDF conversion install " - "ImageMagick (https://www.imagemagick.org)") - if rsvg_convert_cmd: - kernellog.verbose(app, "use rsvg-convert(1) from: " + rsvg_convert_cmd) - kernellog.verbose(app, "use 'dot -Tsvg' and rsvg-convert(1) for DOT -> PDF conversion") + if inkscape_cmd: + kernellog.verbose(app, "use inkscape(1) from: " + inkscape_cmd) + inkscape_ver = subprocess.check_output([inkscape_cmd, '--version']) + ver_one_ptn = b'Inkscape 1' + inkscape_ver_one = re.search(ver_one_ptn, inkscape_ver) + convert_cmd = None + rsvg_convert_cmd = None dot_Tpdf = False + else: - kernellog.verbose(app, - "rsvg-convert(1) not found.\n" - " SVG -> PDF conversion by convert() can be poor quality.\n" - " Install librsvg (https://gitlab.gnome.org/GNOME/librsvg)") - if dot_Tpdf: - kernellog.verbose(app, "use 'dot -Tpdf' for DOT -> PDF conversion") + if convert_cmd: + kernellog.verbose(app, "use convert(1) from: " + convert_cmd) + else: + kernellog.warn(app, + "Neither inkscape(1) nor convert(1) found.\n" + "For SVG to PDF conversion, " + "install either Inkscape (https://inkscape.org/) (preferred) or\n" + "ImageMagick (https://www.imagemagick.org)") + + if rsvg_convert_cmd: + kernellog.verbose(app, "use rsvg-convert(1) from: " + rsvg_convert_cmd) + kernellog.verbose(app, "use 'dot -Tsvg' and rsvg-convert(1) for DOT -> PDF conversion") + dot_Tpdf = False else: - kernellog.verbose(app, "use 'dot -Tsvg' and convert(1) for DOT -> PDF conversion") + kernellog.verbose(app, + "rsvg-convert(1) not found.\n" + " SVG rendering of convert(1) is done by ImageMagick-native renderer.") + if dot_Tpdf: + kernellog.verbose(app, "use 'dot -Tpdf' for DOT -> PDF conversion") + else: + kernellog.verbose(app, "use 'dot -Tsvg' and convert(1) for DOT -> PDF conversion") # integrate conversion tools @@ -274,7 +294,7 @@ def convert_image(img_node, translator, src_fname=None): elif in_ext == '.svg': if translator.builder.format == 'latex': - if convert_cmd is None: + if not inkscape_cmd and convert_cmd is None: kernellog.verbose(app, "no SVG to PDF conversion available / include SVG raw.") img_node.replace_self(file2literal(src_fname)) @@ -342,16 +362,24 @@ def dot2format(app, dot_fname, out_fname): return bool(exit_code == 0) def svg2pdf(app, svg_fname, pdf_fname): - """Converts SVG to PDF with ``convert(1)`` command. + """Converts SVG to PDF with ``inkscape(1)`` or ``convert(1)`` command. - Uses ``convert(1)`` from ImageMagick (https://www.imagemagick.org) for - conversion. Returns ``True`` on success and ``False`` if an error occurred. + Uses ``inkscape(1)`` from Inkscape (https://inkscape.org/) or ``convert(1)`` + from ImageMagick (https://www.imagemagick.org) for conversion. + Returns ``True`` on success and ``False`` if an error occurred. * ``svg_fname`` pathname of the input SVG file with extension (``.svg``) * ``pdf_name`` pathname of the output PDF file with extension (``.pdf``) """ cmd = [convert_cmd, svg_fname, pdf_fname] + + if inkscape_cmd: + if inkscape_ver_one: + cmd = [inkscape_cmd, '-o', pdf_fname, svg_fname] + else: + cmd = [inkscape_cmd, '-z', '--export-pdf=%s' % pdf_fname, svg_fname] + # use stdout and stderr from parent exit_code = subprocess.call(cmd) if exit_code != 0: -- cgit From f30a7ac8c6100e88dc416b675425541a337a46c8 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Wed, 29 Dec 2021 20:47:56 +0900 Subject: docs: sphinx/kfigure.py: Delegate inkscape msg to kernellog.verbose Depending on its version, distro config, and system-setup type, inkscape(1) emits various warning messages which are harmless in command-line uses. List of such warning messages (incomplete, long ones wrapped): - Gtk-Message: hh:mm:ss.nnn: Failed to load module "canberra-gtk-module" - Unable to init server: Could not connect: Connection refused - Failed to get connection - ** (inkscape:xxx): CRITICAL **: hh:mm:ss.nnn: dbus_g_proxy_new_for_name: assertion 'connection != NULL' failed - ** (inkscape:xxx): CRITICAL **: hh:mm:ss.nnn: dbus_g_proxy_call: assertion 'DBUS_IS_G_PROXY (proxy)' failed - ** (inkscape:xxx): CRITICAL **: hh:mm:ss.nnn: dbus_g_connection_register_g_object: assertion 'connection != NULL' failed - ** (inkscape:xxx): WARNING **: hh:mm:ss.nnn: Fonts dir '/usr/share/inkscape/fonts' does not exist and will be ignored. To avoid unnecessary anxiety, capture the message and output it via kernellog.verbose or kernellog.warn depending on the exit code. Signed-off-by: Akira Yokosawa Cc: Jonathan Corbet Cc: Mauro Carvalho Chehab Cc: Randy Dunlap Link: https://lore.kernel.org/r/e26a7b53-9155-8394-4a31-6006379b65a5@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/sphinx/kfigure.py | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sphinx/kfigure.py b/Documentation/sphinx/kfigure.py index e616e49669eb..24d2b2addcce 100644 --- a/Documentation/sphinx/kfigure.py +++ b/Documentation/sphinx/kfigure.py @@ -200,7 +200,8 @@ def setupTools(app): "graphviz from https://www.graphviz.org") if inkscape_cmd: kernellog.verbose(app, "use inkscape(1) from: " + inkscape_cmd) - inkscape_ver = subprocess.check_output([inkscape_cmd, '--version']) + inkscape_ver = subprocess.check_output([inkscape_cmd, '--version'], + stderr=subprocess.DEVNULL) ver_one_ptn = b'Inkscape 1' inkscape_ver_one = re.search(ver_one_ptn, inkscape_ver) convert_cmd = None @@ -373,17 +374,32 @@ def svg2pdf(app, svg_fname, pdf_fname): """ cmd = [convert_cmd, svg_fname, pdf_fname] + cmd_name = 'convert(1)' if inkscape_cmd: + cmd_name = 'inkscape(1)' if inkscape_ver_one: cmd = [inkscape_cmd, '-o', pdf_fname, svg_fname] else: cmd = [inkscape_cmd, '-z', '--export-pdf=%s' % pdf_fname, svg_fname] - # use stdout and stderr from parent - exit_code = subprocess.call(cmd) + try: + warning_msg = subprocess.check_output(cmd, stderr=subprocess.STDOUT) + exit_code = 0 + except subprocess.CalledProcessError as err: + warning_msg = err.output + exit_code = err.returncode + pass + if exit_code != 0: kernellog.warn(app, "Error #%d when calling: %s" % (exit_code, " ".join(cmd))) + if warning_msg: + kernellog.warn(app, "Warning msg from %s: %s" + % (cmd_name, str(warning_msg, 'utf-8'))) + elif warning_msg: + kernellog.verbose(app, "Warning msg from %s (likely harmless):\n%s" + % (cmd_name, str(warning_msg, 'utf-8'))) + return bool(exit_code == 0) def svg2pdf_by_rsvg(app, svg_fname, pdf_fname): -- cgit From 59dfdc13ca226682f927f9c1f8ed888450a4e8b3 Mon Sep 17 00:00:00 2001 From: Dinh Nguyen Date: Fri, 28 Jan 2022 07:31:42 -0600 Subject: dt-bindings: net: can: fix dtbs warning Mute the warning from "make dtbs_check": Documentation/devicetree/bindings/net/can/bosch,m_can.example.dt.yaml: can@20e8000: bosch,mram-cfg: [[0, 0, 0, 32, 0, 0, 0, 1]] is too short Signed-off-by: Dinh Nguyen Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220128133142.2135718-1-dinguyen@kernel.org --- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 401ab7cdb379..035964a8609c 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -101,6 +101,7 @@ properties: - description: Tx Buffers 0-32 elements / 0-576 words minimum: 0 maximum: 32 + minItems: 1 power-domains: description: -- cgit From 3a36eb031b6fe8e134d3f706f90211331e950951 Mon Sep 17 00:00:00 2001 From: Nicolas Ferre Date: Sun, 30 Jan 2022 15:47:08 +0100 Subject: dt-bindings: rng: atmel,at91-trng: update maintainers entry Update according to new MAINTAINERS entry. Signed-off-by: Nicolas Ferre Acked-by: Ludovic Desroches Acked-by: Claudiu Beznea Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/d84760e0b81c338e01f7856e1ce3c5b600b08f23.1643553619.git.nicolas.ferre@microchip.com --- Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml b/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml index c1527637eb74..3ce45456d867 100644 --- a/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml +++ b/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml @@ -9,7 +9,7 @@ title: Atmel AT91 True Random Number Generator maintainers: - Nicolas Ferre - Alexandre Belloni - - Ludovic Desroches + - Claudiu Beznea properties: compatible: -- cgit From b4ba994f2622b6a261a6b30933f32893d2d78294 Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Mon, 31 Jan 2022 17:54:39 +0100 Subject: dt-bindings: ltk050h3146w: replace Heiko Stuebner by myself as maintainer Heiko does not work at Theobroma Systems anymore and the boards using those panels are downstream, maintained internally by the company, so let's relieve Heiko of maintainership duties. Cc: Heiko Stuebner Cc: Quentin Schulz Signed-off-by: Quentin Schulz Acked-by: Heiko Stuebner Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220131165439.717713-1-quentin.schulz@theobroma-systems.com --- .../devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml index 3715882b63b6..3f6efbb942da 100644 --- a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml +++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Leadtek LTK050H3146W 5.0in 720x1280 DSI panel maintainers: - - Heiko Stuebner + - Quentin Schulz allOf: - $ref: panel-common.yaml# -- cgit From dfeef93fe3eee6b7b5cbe209be3dbad59426f189 Mon Sep 17 00:00:00 2001 From: Bryan O'Donoghue Date: Sat, 29 Jan 2022 03:27:34 +0000 Subject: dt-bindings: interconnect: Convert snoc-mm to a sub-node of snoc snoc and snoc-mm in downstream use the same address space a mistake which we have carried over into upstream. In silicon terms snoc-mm has been tacked on to the original snoc which came from msm8916. Convert to a better description where snoc-mm is a sub-node of snoc, thus avoiding a mmio remap collision when using the RPM interconnect driver. Cc: Rob Herring Cc: devicetree@vger.kernel.org Signed-off-by: Bryan O'Donoghue Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220129032735.2410936-2-bryan.odonoghue@linaro.org Signed-off-by: Georgi Djakov --- .../devicetree/bindings/interconnect/qcom,rpm.yaml | 33 ++++++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml index e4c3c2818119..89853b482513 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml @@ -26,7 +26,6 @@ properties: - qcom,msm8939-bimc - qcom,msm8939-pcnoc - qcom,msm8939-snoc - - qcom,msm8939-snoc-mm - qcom,msm8996-a0noc - qcom,msm8996-a1noc - qcom,msm8996-a2noc @@ -80,7 +79,6 @@ allOf: - qcom,msm8939-bimc - qcom,msm8939-pcnoc - qcom,msm8939-snoc - - qcom,msm8939-snoc-mm - qcom,msm8996-a1noc - qcom,msm8996-a2noc - qcom,msm8996-bimc @@ -107,6 +105,37 @@ allOf: - description: Bus Clock - description: Bus A Clock + # Child node's properties + patternProperties: + '^interconnect-[a-z0-9]+$': + type: object + description: + snoc-mm is a child of snoc, sharing snoc's register address space. + + properties: + compatible: + enum: + - qcom,msm8939-snoc-mm + + '#interconnect-cells': + const: 1 + + clock-names: + items: + - const: bus + - const: bus_a + + clocks: + items: + - description: Bus Clock + - description: Bus A Clock + + required: + - compatible + - '#interconnect-cells' + - clock-names + - clocks + - if: properties: compatible: -- cgit From 7bd431486511482b6e789dd69d07654a1d8c5eba Mon Sep 17 00:00:00 2001 From: Srinivasa Rao Mandadapu Date: Thu, 10 Feb 2022 18:20:13 +0530 Subject: ASoC: google: dt-bindings: Add sc7280-herobrine machine bindings Add devicetree bindings documentation file for sc7280 sound card registration. Signed-off-by: Srinivasa Rao Mandadapu Co-developed-by: Venkata Prasad Potturu Signed-off-by: Venkata Prasad Potturu Link: https://lore.kernel.org/r/1644497415-25291-2-git-send-email-quic_srivasam@quicinc.com Signed-off-by: Mark Brown --- .../bindings/sound/google,sc7280-herobrine.yaml | 180 +++++++++++++++++++++ 1 file changed, 180 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml b/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml new file mode 100644 index 000000000000..869b40363af8 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml @@ -0,0 +1,180 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/google,sc7280-herobrine.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Google SC7280-Herobrine ASoC sound card driver + +maintainers: + - Srinivasa Rao Mandadapu + - Judy Hsiao + +description: + This binding describes the SC7280 sound card which uses LPASS for audio. + +properties: + compatible: + enum: + - google,sc7280-herobrine + + audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^dai-link@[0-9a-f]$": + description: + Each subnode represents a dai link. Subnodes of each dai links would be + cpu/codec dais. + + type: object + + properties: + link-name: + description: Indicates dai-link name and PCM stream name. + $ref: /schemas/types.yaml#/definitions/string + maxItems: 1 + + reg: + maxItems: 1 + description: dai link address. + + cpu: + description: Holds subnode which indicates cpu dai. + type: object + properties: + sound-dai: true + + required: + - sound-dai + + additionalProperties: false + + codec: + description: Holds subnode which indicates codec dai. + type: object + properties: + sound-dai: true + + required: + - sound-dai + + additionalProperties: false + + required: + - link-name + - cpu + - codec + - reg + + additionalProperties: false + +required: + - compatible + - model + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + + - | + #include + sound { + compatible = "google,sc7280-herobrine"; + model = "sc7280-wcd938x-max98360a-4dmic"; + + audio-routing = + "IN1_HPHL", "HPHL_OUT", + "IN2_HPHR", "HPHR_OUT", + "AMIC1", "MIC BIAS1", + "AMIC2", "MIC BIAS2", + "VA DMIC0", "MIC BIAS3", + "VA DMIC1", "MIC BIAS3", + "VA DMIC2", "MIC BIAS4", + "VA DMIC3", "MIC BIAS4", + "TX SWR_ADC0", "ADC1_OUTPUT", + "TX SWR_ADC1", "ADC2_OUTPUT", + "TX SWR_ADC2", "ADC3_OUTPUT", + "TX SWR_DMIC0", "DMIC1_OUTPUT", + "TX SWR_DMIC1", "DMIC2_OUTPUT", + "TX SWR_DMIC2", "DMIC3_OUTPUT", + "TX SWR_DMIC3", "DMIC4_OUTPUT"; + + #address-cells = <1>; + #size-cells = <0>; + + dai-link@0 { + link-name = "WCD Playback"; + reg = ; + cpu { + sound-dai = <&lpass_cpu LPASS_CDC_DMA_RX0>; + }; + + codec { + sound-dai = <&wcd938x 0>, <&swr0 0>, <&rxmacro 0>; + }; + }; + dai-link@1 { + link-name = "WCD Capture"; + reg = ; + cpu { + sound-dai = <&lpass_cpu LPASS_CDC_DMA_TX3>; + }; + + codec { + sound-dai = <&wcd938x 1>, <&swr1 0>, <&txmacro 0>; + }; + }; + + dai-link@2 { + link-name = "MI2S Playback"; + reg = ; + cpu { + sound-dai = <&lpass_cpu MI2S_SECONDARY>; + }; + + codec { + sound-dai = <&max98360a>; + }; + }; + + dai-link@3 { + link-name = "DMIC Capture"; + reg = ; + cpu { + sound-dai = <&lpass_cpu LPASS_CDC_DMA_VA_TX0>; + }; + + codec { + sound-dai = <&vamacro 0>; + }; + }; + + dai-link@5 { + link-name = "DP Playback"; + reg = ; + cpu { + sound-dai = <&lpass_cpu LPASS_DP_RX>; + }; + + codec { + sound-dai = <&mdss_dp>; + }; + }; + }; -- cgit From 7f021b723ea51ae94329e6d76f68189e1696deca Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 29 Jan 2022 13:23:52 +0100 Subject: ASoC: dt-bindings: samsung,aries-wm8994: require sound-dai property The cpu and codec nodes must provide sound-dai property. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220129122357.45545-2-krzysztof.kozlowski@canonical.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml index 5fff586dc802..afdacffc9a7a 100644 --- a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml @@ -31,6 +31,8 @@ properties: description: | phandles to the I2S controller and bluetooth codec, in that order + required: + - sound-dai codec: type: object @@ -38,6 +40,8 @@ properties: sound-dai: $ref: /schemas/types.yaml#/definitions/phandle-array description: phandle to the WM8994 CODEC + required: + - sound-dai samsung,audio-routing: $ref: /schemas/types.yaml#/definitions/non-unique-string-array -- cgit From 0412539614a223817646150d910ab6fedbb80507 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 29 Jan 2022 13:24:26 +0100 Subject: ASoC: dt-bindings: samsung,arndale: convert to dtschema Convert the audio complex on Arndale boards with Samsung Exynos SoC to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220129122430.45694-1-krzysztof.kozlowski@canonical.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/arndale.txt | 25 ------------ .../devicetree/bindings/sound/samsung,arndale.yaml | 44 ++++++++++++++++++++++ 2 files changed, 44 insertions(+), 25 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/arndale.txt create mode 100644 Documentation/devicetree/bindings/sound/samsung,arndale.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/arndale.txt b/Documentation/devicetree/bindings/sound/arndale.txt deleted file mode 100644 index 17530120ccfc..000000000000 --- a/Documentation/devicetree/bindings/sound/arndale.txt +++ /dev/null @@ -1,25 +0,0 @@ -Audio Binding for Arndale boards - -Required properties: -- compatible : Can be one of the following: - "samsung,arndale-rt5631", - "samsung,arndale-wm1811" - -- samsung,audio-cpu: The phandle of the Samsung I2S controller -- samsung,audio-codec: The phandle of the audio codec - -Optional: -- samsung,model: The name of the sound-card - -Arndale Boards has many audio daughter cards, one of them is -rt5631/alc5631. Below example shows audio bindings for rt5631/ -alc5631 based codec. - -Example: - -sound { - compatible = "samsung,arndale-rt5631"; - - samsung,audio-cpu = <&i2s0> - samsung,audio-codec = <&rt5631>; -}; diff --git a/Documentation/devicetree/bindings/sound/samsung,arndale.yaml b/Documentation/devicetree/bindings/sound/samsung,arndale.yaml new file mode 100644 index 000000000000..e7dc65637f02 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/samsung,arndale.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/samsung,arndale.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Insignal Arndale boards audio complex + +maintainers: + - Krzysztof Kozlowski + - Sylwester Nawrocki + +properties: + compatible: + enum: + - samsung,arndale-rt5631 + - samsung,arndale-wm1811 + + samsung,audio-codec: + description: Phandle to the audio codec. + $ref: /schemas/types.yaml#/definitions/phandle + + samsung,audio-cpu: + description: Phandle to the Samsung I2S controller. + $ref: /schemas/types.yaml#/definitions/phandle + + samsung,model: + description: The user-visible name of this sound complex. + $ref: /schemas/types.yaml#/definitions/string + +required: + - compatible + - samsung,audio-codec + - samsung,audio-cpu + +additionalProperties: false + +examples: + - | + sound { + compatible = "samsung,arndale-rt5631"; + samsung,audio-cpu = <&i2s0>; + samsung,audio-codec = <&rt5631>; + }; -- cgit From b6145d8f0d6436a83a31024d4f9953d7088710b4 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 29 Jan 2022 13:24:27 +0100 Subject: ASoC: dt-bindings: samsung,arndale: document ALC5631 The Arndale audio complex might come with ALC5631 which is compatible with RT5631. Document the compatible since it is used in Linux kernel sources. Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220129122430.45694-2-krzysztof.kozlowski@canonical.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/samsung,arndale.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/samsung,arndale.yaml b/Documentation/devicetree/bindings/sound/samsung,arndale.yaml index e7dc65637f02..cea2bf3544f0 100644 --- a/Documentation/devicetree/bindings/sound/samsung,arndale.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,arndale.yaml @@ -13,6 +13,7 @@ maintainers: properties: compatible: enum: + - samsung,arndale-alc5631 - samsung,arndale-rt5631 - samsung,arndale-wm1811 -- cgit From 6752770d590594ff42fc19e74c30059d34f133af Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 29 Jan 2022 13:24:28 +0100 Subject: ASoC: dt-bindings: samsung,smdk5250: convert to dtschema Convert the audio complex on SMDK5250 boards with Samsung Exynos SoC to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220129122430.45694-3-krzysztof.kozlowski@canonical.com Signed-off-by: Mark Brown --- .../bindings/sound/samsung,smdk-wm8994.txt | 14 -------- .../bindings/sound/samsung,smdk5250.yaml | 38 ++++++++++++++++++++++ 2 files changed, 38 insertions(+), 14 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/samsung,smdk-wm8994.txt create mode 100644 Documentation/devicetree/bindings/sound/samsung,smdk5250.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/samsung,smdk-wm8994.txt b/Documentation/devicetree/bindings/sound/samsung,smdk-wm8994.txt deleted file mode 100644 index 4686646fb122..000000000000 --- a/Documentation/devicetree/bindings/sound/samsung,smdk-wm8994.txt +++ /dev/null @@ -1,14 +0,0 @@ -Samsung SMDK audio complex - -Required properties: -- compatible : "samsung,smdk-wm8994" -- samsung,i2s-controller: The phandle of the Samsung I2S0 controller -- samsung,audio-codec: The phandle of the WM8994 audio codec -Example: - -sound { - compatible = "samsung,smdk-wm8994"; - - samsung,i2s-controller = <&i2s0>; - samsung,audio-codec = <&wm8994>; -}; diff --git a/Documentation/devicetree/bindings/sound/samsung,smdk5250.yaml b/Documentation/devicetree/bindings/sound/samsung,smdk5250.yaml new file mode 100644 index 000000000000..cb51af90435e --- /dev/null +++ b/Documentation/devicetree/bindings/sound/samsung,smdk5250.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/samsung,smdk5250.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung SMDK5250 audio complex with WM8994 codec + +maintainers: + - Krzysztof Kozlowski + - Sylwester Nawrocki + +properties: + compatible: + const: samsung,smdk-wm8994 + + samsung,audio-codec: + description: Phandle to the audio codec. + $ref: /schemas/types.yaml#/definitions/phandle + + samsung,i2s-controller: + description: Phandle to the Samsung I2S controller. + $ref: /schemas/types.yaml#/definitions/phandle + +required: + - compatible + - samsung,audio-codec + - samsung,i2s-controller + +additionalProperties: false + +examples: + - | + sound { + compatible = "samsung,smdk-wm8994"; + samsung,i2s-controller = <&i2s0>; + samsung,audio-codec = <&wm8994>; + }; -- cgit From a7e5305f7ab03cf3ae19ddd3f29919a7a2da0e5d Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 29 Jan 2022 13:24:29 +0100 Subject: ASoC: dt-bindings: samsung,snow: convert to dtschema Convert the audio complex on Google Snow boards with Samsung Exynos SoC to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220129122430.45694-4-krzysztof.kozlowski@canonical.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/samsung,snow.yaml | 74 ++++++++++++++++++++++ Documentation/devicetree/bindings/sound/snow.txt | 31 --------- 2 files changed, 74 insertions(+), 31 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/samsung,snow.yaml delete mode 100644 Documentation/devicetree/bindings/sound/snow.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/samsung,snow.yaml b/Documentation/devicetree/bindings/sound/samsung,snow.yaml new file mode 100644 index 000000000000..0c3b3302b842 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/samsung,snow.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/samsung,snow.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Google Snow audio complex with MAX9809x codec + +maintainers: + - Krzysztof Kozlowski + - Sylwester Nawrocki + +properties: + compatible: + enum: + - google,snow-audio-max98090 + - google,snow-audio-max98091 + - google,snow-audio-max98095 + + codec: + type: object + properties: + sound-dai: + description: List of phandles to the CODEC and HDMI IP nodes. + items: + - description: Phandle to the MAX98090, MAX98091 or MAX98095 CODEC. + - description: Phandle to the HDMI IP block node. + required: + - sound-dai + + cpu: + type: object + properties: + sound-dai: + description: Phandle to the Samsung I2S controller. + maxItems: 1 + required: + - sound-dai + + samsung,audio-codec: + description: Phandle to the audio codec. + $ref: /schemas/types.yaml#/definitions/phandle + deprecated: true + + samsung,i2s-controller: + description: Phandle to the Samsung I2S controller. + $ref: /schemas/types.yaml#/definitions/phandle + deprecated: true + + samsung,model: + description: The user-visible name of this sound complex. + $ref: /schemas/types.yaml#/definitions/string + +required: + - compatible + - codec + - cpu + +additionalProperties: false + +examples: + - | + sound { + compatible = "google,snow-audio-max98095"; + samsung,model = "Snow-I2S-MAX98095"; + + cpu { + sound-dai = <&i2s0 0>; + }; + + codec { + sound-dai = <&max98095 0>, <&hdmi>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/snow.txt b/Documentation/devicetree/bindings/sound/snow.txt deleted file mode 100644 index 80fd9a87bb3f..000000000000 --- a/Documentation/devicetree/bindings/sound/snow.txt +++ /dev/null @@ -1,31 +0,0 @@ -Audio Binding for Snow boards - -Required properties: -- compatible : Can be one of the following, - "google,snow-audio-max98090" or - "google,snow-audio-max98091" or - "google,snow-audio-max98095" -- samsung,i2s-controller (deprecated): The phandle of the Samsung I2S controller -- samsung,audio-codec (deprecated): The phandle of the audio codec - -Required sub-nodes: - - - 'cpu' subnode with a 'sound-dai' property containing the phandle of the I2S - controller - - 'codec' subnode with a 'sound-dai' property containing list of phandles - to the CODEC nodes, first entry must be the phandle of the MAX98090, - MAX98091 or MAX98095 CODEC (exact device type is indicated by the compatible - string) and the second entry must be the phandle of the HDMI IP block node - -Optional: -- samsung,model: The name of the sound-card - -Example: - -sound { - compatible = "google,snow-audio-max98095"; - - samsung,model = "Snow-I2S-MAX98095"; - samsung,i2s-controller = <&i2s0>; - samsung,audio-codec = <&max98095>; -}; -- cgit From c1fc51ebb098cd43a68ebc82fde51364c207de32 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 29 Jan 2022 13:24:30 +0100 Subject: ASoC: dt-bindings: samsung,tm2: convert to dtschema Convert the audio complex on Samsung TM2 boards with Samsung Exynos SoC to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220129122430.45694-5-krzysztof.kozlowski@canonical.com Signed-off-by: Mark Brown --- .../bindings/sound/samsung,tm2-audio.txt | 42 ------------ .../devicetree/bindings/sound/samsung,tm2.yaml | 80 ++++++++++++++++++++++ 2 files changed, 80 insertions(+), 42 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt create mode 100644 Documentation/devicetree/bindings/sound/samsung,tm2.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt b/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt deleted file mode 100644 index f5ccc12ddc00..000000000000 --- a/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt +++ /dev/null @@ -1,42 +0,0 @@ -Samsung Exynos5433 TM2(E) audio complex with WM5110 codec - -Required properties: - - - compatible : "samsung,tm2-audio" - - model : the user-visible name of this sound complex - - audio-codec : the first entry should be phandle of the wm5110 audio - codec node, as described in ../mfd/arizona.txt; - the second entry should be phandle of the HDMI - transmitter node - - i2s-controller : the list of phandle and argument tuples pointing to - I2S controllers, the first entry should be I2S0 and - the second one I2S1 - - audio-amplifier : the phandle of the MAX98504 amplifier - - samsung,audio-routing : a list of the connections between audio components; - each entry is a pair of strings, the first being the - connection's sink, the second being the connection's - source; valid names for sources and sinks are the - WM5110's and MAX98504's pins and the jacks on the - board: HP, SPK, Main Mic, Sub Mic, Third Mic, - Headset Mic - - mic-bias-gpios : GPIO pin that enables the Main Mic bias regulator - - -Example: - -sound { - compatible = "samsung,tm2-audio"; - audio-codec = <&wm5110>, <&hdmi>; - i2s-controller = <&i2s0 0>, <&i2s1 0>; - audio-amplifier = <&max98504>; - mic-bias-gpios = <&gpr3 2 0>; - model = "wm5110"; - samsung,audio-routing = - "HP", "HPOUT1L", - "HP", "HPOUT1R", - "SPK", "SPKOUT", - "SPKOUT", "HPOUT2L", - "SPKOUT", "HPOUT2R", - "Main Mic", "MICBIAS2", - "IN1R", "Main Mic"; -}; diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml new file mode 100644 index 000000000000..74712d6f3ef4 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/samsung,tm2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos5433 TM2(E) audio complex with WM5110 codec + +maintainers: + - Krzysztof Kozlowski + - Sylwester Nawrocki + +properties: + compatible: + const: samsung,tm2-audio + + audio-amplifier: + description: Phandle to the MAX98504 amplifier. + $ref: /schemas/types.yaml#/definitions/phandle + + audio-codec: + description: Phandles to the codecs. + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - description: Phandle to the WM5110 audio codec. + - description: Phandle to the HDMI transmitter node. + + samsung,audio-routing: + description: | + List of the connections between audio components; each entry is + a pair of strings, the first being the connection's sink, the second + being the connection's source; valid names for sources and sinks are the + WM5110's and MAX98504's pins and the jacks on the board: HP, SPK, Main + Mic, Sub Mic, Third Mic, Headset Mic. + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + + i2s-controller: + description: Phandles to the I2S controllers. + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - description: Phandle to I2S0. + - description: Phandle to I2S1. + + mic-bias-gpios: + description: GPIO pin that enables the Main Mic bias regulator. + + model: + description: The user-visible name of this sound complex. + $ref: /schemas/types.yaml#/definitions/string + +required: + - compatible + - audio-amplifier + - audio-codec + - samsung,audio-routing + - i2s-controller + - mic-bias-gpios + - model + +additionalProperties: false + +examples: + - | + #include + + sound { + compatible = "samsung,tm2-audio"; + audio-codec = <&wm5110>, <&hdmi>; + i2s-controller = <&i2s0 0>, <&i2s1 0>; + audio-amplifier = <&max98504>; + mic-bias-gpios = <&gpr3 2 GPIO_ACTIVE_HIGH>; + model = "wm5110"; + samsung,audio-routing = "HP", "HPOUT1L", + "HP", "HPOUT1R", + "SPK", "SPKOUT", + "SPKOUT", "HPOUT2L", + "SPKOUT", "HPOUT2R", + "RCV", "HPOUT3L", + "RCV", "HPOUT3R"; + }; -- cgit From 23c2f1392f2f3a1c7a82c5d18f02d1a055ad6f16 Mon Sep 17 00:00:00 2001 From: Ariel D'Alessandro Date: Thu, 10 Feb 2022 10:40:48 -0300 Subject: ASoC: bindings: fsl-asoc-card: Add compatible for tlv320aic31xx codec Commit 8c9b9cfb7724 ("ASoC: fsl-asoc-card: Support fsl,imx-audio-tlv320aic31xx codec")' added support for tlv320aic31xx codec to fsl-asoc-card, but missed the related device-tree compatible string documentation. Fix this. Signed-off-by: Ariel D'Alessandro Link: https://lore.kernel.org/r/20220210134049.32576-1-ariel.dalessandro@collabora.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl-asoc-card.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt index b219626a5403..8b4f4015cfe4 100644 --- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt +++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt @@ -40,6 +40,8 @@ The compatible list for this generic sound card currently: "fsl,imx-audio-tlv320aic32x4" + "fsl,imx-audio-tlv320aic31xx" + "fsl,imx-audio-si476x" "fsl,imx-audio-wm8958" -- cgit From a3fe5dbda0a4bb7759dcd5a0ad713d347e020401 Mon Sep 17 00:00:00 2001 From: David Matlack Date: Wed, 19 Jan 2022 23:07:36 +0000 Subject: KVM: x86/mmu: Split huge pages mapped by the TDP MMU when dirty logging is enabled When dirty logging is enabled without initially-all-set, try to split all huge pages in the memslot down to 4KB pages so that vCPUs do not have to take expensive write-protection faults to split huge pages. Eager page splitting is best-effort only. This commit only adds the support for the TDP MMU, and even there splitting may fail due to out of memory conditions. Failures to split a huge page is fine from a correctness standpoint because KVM will always follow up splitting by write-protecting any remaining huge pages. Eager page splitting moves the cost of splitting huge pages off of the vCPU threads and onto the thread enabling dirty logging on the memslot. This is useful because: 1. Splitting on the vCPU thread interrupts vCPUs execution and is disruptive to customers whereas splitting on VM ioctl threads can run in parallel with vCPU execution. 2. Splitting all huge pages at once is more efficient because it does not require performing VM-exit handling or walking the page table for every 4KiB page in the memslot, and greatly reduces the amount of contention on the mmu_lock. For example, when running dirty_log_perf_test with 96 virtual CPUs, 1GiB per vCPU, and 1GiB HugeTLB memory, the time it takes vCPUs to write to all of their memory after dirty logging is enabled decreased by 95% from 2.94s to 0.14s. Eager Page Splitting is over 100x more efficient than the current implementation of splitting on fault under the read lock. For example, taking the same workload as above, Eager Page Splitting reduced the CPU required to split all huge pages from ~270 CPU-seconds ((2.94s - 0.14s) * 96 vCPU threads) to only 1.55 CPU-seconds. Eager page splitting does increase the amount of time it takes to enable dirty logging since it has split all huge pages. For example, the time it took to enable dirty logging in the 96GiB region of the aforementioned test increased from 0.001s to 1.55s. Reviewed-by: Peter Xu Signed-off-by: David Matlack Message-Id: <20220119230739.2234394-16-dmatlack@google.com> Signed-off-by: Paolo Bonzini --- Documentation/admin-guide/kernel-parameters.txt | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index f5a27f067db9..5d80a0faa096 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2339,6 +2339,30 @@ kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs. Default is 0 (don't ignore, but inject #GP) + kvm.eager_page_split= + [KVM,X86] Controls whether or not KVM will try to + proactively split all huge pages during dirty logging. + Eager page splitting reduces interruptions to vCPU + execution by eliminating the write-protection faults + and MMU lock contention that would otherwise be + required to split huge pages lazily. + + VM workloads that rarely perform writes or that write + only to a small region of VM memory may benefit from + disabling eager page splitting to allow huge pages to + still be used for reads. + + The behavior of eager page splitting depends on whether + KVM_DIRTY_LOG_INITIALLY_SET is enabled or disabled. If + disabled, all huge pages in a memslot will be eagerly + split when dirty logging is enabled on that memslot. If + enabled, huge pages will not be eagerly split. + + Eager page splitting currently only supports splitting + huge pages mapped by the TDP MMU. + + Default is Y (on). + kvm.enable_vmware_backdoor=[KVM] Support VMware backdoor PV interface. Default is false (don't support). -- cgit From cb00a70bd4b7e42dcbd6cd80b3f1697b10cdb44e Mon Sep 17 00:00:00 2001 From: David Matlack Date: Wed, 19 Jan 2022 23:07:37 +0000 Subject: KVM: x86/mmu: Split huge pages mapped by the TDP MMU during KVM_CLEAR_DIRTY_LOG When using KVM_DIRTY_LOG_INITIALLY_SET, huge pages are not write-protected when dirty logging is enabled on the memslot. Instead they are write-protected once userspace invokes KVM_CLEAR_DIRTY_LOG for the first time and only for the specific sub-region being cleared. Enhance KVM_CLEAR_DIRTY_LOG to also try to split huge pages prior to write-protecting to avoid causing write-protection faults on vCPU threads. This also allows userspace to smear the cost of huge page splitting across multiple ioctls, rather than splitting the entire memslot as is the case when initially-all-set is not used. Signed-off-by: David Matlack Message-Id: <20220119230739.2234394-17-dmatlack@google.com> Signed-off-by: Paolo Bonzini --- Documentation/admin-guide/kernel-parameters.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 5d80a0faa096..2a9746fe6c4a 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2356,7 +2356,9 @@ KVM_DIRTY_LOG_INITIALLY_SET is enabled or disabled. If disabled, all huge pages in a memslot will be eagerly split when dirty logging is enabled on that memslot. If - enabled, huge pages will not be eagerly split. + enabled, eager page splitting will be performed during + the KVM_CLEAR_DIRTY ioctl, and only for the pages being + cleared. Eager page splitting currently only supports splitting huge pages mapped by the TDP MMU. -- cgit From 85cedb4e0c9d3b08c28e164e592b3a329e3dd5fa Mon Sep 17 00:00:00 2001 From: Loic Poulain Date: Wed, 9 Feb 2022 19:45:07 +0100 Subject: dt-bindings: clock: Add qualcomm QCM2290 DISPCC bindings Add device tree bindings for display clock controller on QCM2290 SoCs. Signed-off-by: Loic Poulain Reviewed-by: Bjorn Andersson Reviewed-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/1644432308-21099-1-git-send-email-loic.poulain@linaro.org --- .../bindings/clock/qcom,qcm2290-dispcc.yaml | 87 ++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,qcm2290-dispcc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,qcm2290-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcm2290-dispcc.yaml new file mode 100644 index 000000000000..973e408c6268 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,qcm2290-dispcc.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,qcm2290-dispcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display Clock & Reset Controller Binding for qcm2290 + +maintainers: + - Loic Poulain + +description: | + Qualcomm display clock control module which supports the clocks, resets and + power domains on qcm2290. + + See also dt-bindings/clock/qcom,dispcc-qcm2290.h. + +properties: + compatible: + const: qcom,qcm2290-dispcc + + clocks: + items: + - description: Board XO source + - description: Board active-only XO source + - description: GPLL0 source from GCC + - description: GPLL0 div source from GCC + - description: Byte clock from DSI PHY + - description: Pixel clock from DSI PHY + + clock-names: + items: + - const: bi_tcxo + - const: bi_tcxo_ao + - const: gcc_disp_gpll0_clk_src + - const: gcc_disp_gpll0_div_clk_src + - const: dsi0_phy_pll_out_byteclk + - const: dsi0_phy_pll_out_dsiclk + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include + #include + #include + clock-controller@5f00000 { + compatible = "qcom,qcm2290-dispcc"; + reg = <0x5f00000 0x20000>; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, + <&rpmcc RPM_SMD_XO_A_CLK_SRC>, + <&gcc GCC_DISP_GPLL0_CLK_SRC>, + <&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>, + <&dsi0_phy 0>, + <&dsi0_phy 1>; + clock-names = "bi_tcxo", + "bi_tcxo_ao", + "gcc_disp_gpll0_clk_src", + "gcc_disp_gpll0_div_clk_src", + "dsi0_phy_pll_out_byteclk", + "dsi0_phy_pll_out_dsiclk"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... -- cgit From 72cbd73099cb9f7a22c2b6f3ad706ee91ee16f83 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Wed, 12 Jan 2022 20:40:57 +0100 Subject: dt-bindings: pinctrl: qcom: msm8953: allow gpio-reserved-ranges Allow the gpio-reserved-ranges property to be used in dts. Signed-off-by: Luca Weiss Acked-by: Konrad Dybcio Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220112194118.178026-9-luca@z3ntu.xyz Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml index 64c0a41ca0c3..d4da558cde54 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml @@ -34,6 +34,8 @@ properties: gpio-controller: true + gpio-reserved-ranges: true + '#gpio-cells': description: Specifying the pin number and flags, as defined in include/dt-bindings/gpio/gpio.h -- cgit From 620d940073ef4ff3eefb401c3377b18092316ba1 Mon Sep 17 00:00:00 2001 From: Rayyan Ansari Date: Mon, 24 Jan 2022 17:15:36 +0000 Subject: dt-bindings: pinctrl: qcom,pmic-mpp: Document PM8226 compatible Document the Device Tree binding for PM8226 MPPs. Signed-off-by: Rayyan Ansari Acked-by: Rob Herring Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220124171538.18088-1-rayyan@ansari.sh Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml index 35c846f59979..df79274d0ec3 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml @@ -21,6 +21,7 @@ properties: - qcom,pm8019-mpp - qcom,pm8038-mpp - qcom,pm8058-mpp + - qcom,pm8226-mpp - qcom,pm8821-mpp - qcom,pm8841-mpp - qcom,pm8916-mpp -- cgit From 134cfc5565d3b9abf9c406791bbc96008e80f0d5 Mon Sep 17 00:00:00 2001 From: Yassine Oudjana Date: Thu, 3 Feb 2022 07:25:13 +0000 Subject: dt-bindings: arm: qcom: Add msm8996 and apq8096 compatibles Add compatibles for MSM8996 and APQ8096 and all supported devices that have them. Signed-off-by: Yassine Oudjana Reviewed-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220203072226.51482-2-y.oudjana@protonmail.com --- Documentation/devicetree/bindings/arm/qcom.yaml | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 9a75274f9ae4..298d7129f907 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -173,7 +173,21 @@ properties: - const: qcom,apq8094 - items: - - const: qcom,msm8996-mtp + - enum: + - arrow,apq8096-db820c + - inforce,ifc6640 + - const: qcom,apq8096-sbc + - const: qcom,apq8096 + + - items: + - enum: + - qcom,msm8996-mtp + - sony,dora-row + - sony,kagura-row + - sony,keyaki-row + - xiaomi,gemini + - xiaomi,scorpio + - const: qcom,msm8996 - items: - enum: -- cgit From c4bfcb73b6096dfc4826079b8ade24db5c998628 Mon Sep 17 00:00:00 2001 From: Sai Prakash Ranjan Date: Fri, 28 Jan 2022 13:17:14 +0530 Subject: dt-bindings: arm: msm: Add LLCC compatible for SM8350 Add LLCC compatible for SM8350 SoC. Cc: Rob Herring Signed-off-by: Sai Prakash Ranjan Reviewed-by: Krzysztof Kozlowski Tested-by: Vinod Koul Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/e3d200eb06949f7e216b7f82f5811b7addb7fdc8.1643355594.git.quic_saipraka@quicinc.com --- Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml index 03882aac8d2d..c1eded3a3257 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml +++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml @@ -27,6 +27,7 @@ properties: - qcom,sm6350-llcc - qcom,sm8150-llcc - qcom,sm8250-llcc + - qcom,sm8350-llcc reg: items: -- cgit From c9413e3e1e59045348f253b127df4684fff7cb9d Mon Sep 17 00:00:00 2001 From: Sai Prakash Ranjan Date: Fri, 28 Jan 2022 13:17:15 +0530 Subject: dt-bindings: arm: msm: Add LLCC compatible for SM8450 Add LLCC compatible for SM8450 SoC. Cc: Rob Herring Signed-off-by: Sai Prakash Ranjan Reviewed-by: Krzysztof Kozlowski Tested-by: Vinod Koul Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/f5235371f07ac0ce367c6ea84ed49937fb751a07.1643355594.git.quic_saipraka@quicinc.com --- Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml index c1eded3a3257..30fcbe2ad8a3 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml +++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml @@ -28,6 +28,7 @@ properties: - qcom,sm8150-llcc - qcom,sm8250-llcc - qcom,sm8350-llcc + - qcom,sm8450-llcc reg: items: -- cgit From ef36263aa03b252786a816caf4840ceda3f15d38 Mon Sep 17 00:00:00 2001 From: Bartosz Dudziak Date: Mon, 7 Feb 2022 19:54:10 +0100 Subject: dt-bindings: clock: Add support for the MSM8226 mmcc Document the multimedia clock controller found on MSM8226. Signed-off-by: Bartosz Dudziak Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220207185411.19118-2-bartosz.dudziak@snejp.pl --- Documentation/devicetree/bindings/clock/qcom,mmcc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml index 68fdc3d4982a..4b79e89fd174 100644 --- a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml @@ -19,6 +19,7 @@ properties: enum: - qcom,mmcc-apq8064 - qcom,mmcc-apq8084 + - qcom,mmcc-msm8226 - qcom,mmcc-msm8660 - qcom,mmcc-msm8960 - qcom,mmcc-msm8974 -- cgit From a6ff90f3fbd4d902aad8777f0329cef3a2768bde Mon Sep 17 00:00:00 2001 From: Horatiu Vultur Date: Fri, 4 Feb 2022 16:35:34 +0100 Subject: dt-bindings: pinctrl: pinctrl-microchip-sgpio: Fix example The blamed commit adds support for irq, but the reqisters for irq are outside of the memory size. They are at address 0x108. Therefore update the memory size to cover all the registers used by the device. Fixes: 01a9350bdd49fb ("dt-bindings: pinctrl: pinctrl-microchip-sgpio: Add irq support") Signed-off-by: Horatiu Vultur Link: https://lore.kernel.org/r/20220204153535.465827-2-horatiu.vultur@microchip.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml b/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml index cb554084bdf1..0df4e114fdd6 100644 --- a/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml @@ -145,7 +145,7 @@ examples: clocks = <&sys_clk>; pinctrl-0 = <&sgpio2_pins>; pinctrl-names = "default"; - reg = <0x1101059c 0x100>; + reg = <0x1101059c 0x118>; microchip,sgpio-port-ranges = <0 0>, <16 18>, <28 31>; bus-frequency = <25000000>; sgpio_in2: gpio@0 { -- cgit From c76eeb14ec4e645a23ed8d627c7e38eca048c527 Mon Sep 17 00:00:00 2001 From: Chen-Yu Tsai Date: Wed, 2 Feb 2022 23:35:28 +0800 Subject: dt-bindings: pinctrl: mt8195: fix bias-pull-{up,down} checks When the constraints and description for bias-pull-{up,down} were added, the constraints were not indented correctly, resulting in them being parsed as part of the description. This effectively nullified their purpose. Move the constraints out of the description block, make each description part of the same associative array as the enum its describing, and reindent them correctly so they take effect. Also add "type: boolean" to the list of valid values. This corresponds to having bias-pull-{up,down} without any arguments. Fixes: 91e7edceda96 ("dt-bindings: pinctrl: mt8195: change pull up/down description") Signed-off-by: Chen-Yu Tsai Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220202153528.707185-1-wenst@chromium.org Signed-off-by: Linus Walleij --- .../bindings/pinctrl/pinctrl-mt8195.yaml | 30 ++++++++++++---------- 1 file changed, 16 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml index 328ea59c5466..8299662c2c09 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml @@ -99,6 +99,14 @@ patternProperties: enum: [2, 4, 6, 8, 10, 12, 14, 16] bias-pull-down: + oneOf: + - type: boolean + - enum: [100, 101, 102, 103] + description: mt8195 pull down PUPD/R0/R1 type define value. + - enum: [200, 201, 202, 203, 204, 205, 206, 207] + description: mt8195 pull down RSEL type define value. + - enum: [75000, 5000] + description: mt8195 pull down RSEL type si unit value(ohm). description: | For pull down type is normal, it don't need add RSEL & R1R0 define and resistance value. @@ -115,13 +123,6 @@ patternProperties: & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" define in mt8195. It can also support resistance value(ohm) "75000" & "5000" in mt8195. - oneOf: - - enum: [100, 101, 102, 103] - - description: mt8195 pull down PUPD/R0/R1 type define value. - - enum: [200, 201, 202, 203, 204, 205, 206, 207] - - description: mt8195 pull down RSEL type define value. - - enum: [75000, 5000] - - description: mt8195 pull down RSEL type si unit value(ohm). An example of using RSEL define: pincontroller { @@ -146,6 +147,14 @@ patternProperties: }; bias-pull-up: + oneOf: + - type: boolean + - enum: [100, 101, 102, 103] + description: mt8195 pull up PUPD/R0/R1 type define value. + - enum: [200, 201, 202, 203, 204, 205, 206, 207] + description: mt8195 pull up RSEL type define value. + - enum: [1000, 1500, 2000, 3000, 4000, 5000, 10000, 75000] + description: mt8195 pull up RSEL type si unit value(ohm). description: | For pull up type is normal, it don't need add RSEL & R1R0 define and resistance value. @@ -163,13 +172,6 @@ patternProperties: define in mt8195. It can also support resistance value(ohm) "1000" & "1500" & "2000" & "3000" & "4000" & "5000" & "10000" & "75000" in mt8195. - oneOf: - - enum: [100, 101, 102, 103] - - description: mt8195 pull up PUPD/R0/R1 type define value. - - enum: [200, 201, 202, 203, 204, 205, 206, 207] - - description: mt8195 pull up RSEL type define value. - - enum: [1000, 1500, 2000, 3000, 4000, 5000, 10000, 75000] - - description: mt8195 pull up RSEL type si unit value(ohm). An example of using RSEL define: pincontroller { i2c0-pins { -- cgit From b8f79acc752e9895caffd89016c42bd926815d70 Mon Sep 17 00:00:00 2001 From: Colin Ian King Date: Wed, 2 Feb 2022 09:15:51 +0000 Subject: pinctl: doc: Fix spelling mistake "resisitors" -> "resistors" There is a spelling mistake in the documentation. Fix it. Signed-off-by: Colin Ian King Reviewed-by: Florian Fainelli Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220202091551.580372-1-colin.i.king@gmail.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt index 4eaae32821ae..e047a198db38 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt @@ -85,7 +85,7 @@ Optional Properties (for I2C pins): - function: String. Specifies the pin mux selection. Values must be one of: "alt1", "alt2", "alt3", "alt4" - bias-pull-up: Integer. Pull up strength in Ohm. There are 3 - pull-up resisitors (1.2k, 1.8k, 2.7k) available + pull-up resistors (1.2k, 1.8k, 2.7k) available in parallel for I2C pins, so the valid values are: 568, 720, 831, 1080, 1200, 1800, 2700 Ohm. - bias-disable: No arguments. Disable pin bias. -- cgit From 182c4e1f92c1f1c1c6d14e2409aa85a11d8136ba Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Tue, 25 Jan 2022 11:11:20 -0600 Subject: dt-bindings: soc: add binding for i.MX8MQ VPU blk-ctrl This adds the DT binding for the i.MX8MQ VPU blk-ctrl. Signed-off-by: Lucas Stach Signed-off-by: Adam Ford Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- .../bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml | 71 ++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml new file mode 100644 index 000000000000..7263ebedf09f --- /dev/null +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8MQ VPU blk-ctrl + +maintainers: + - Lucas Stach + +description: + The i.MX8MQ VPU blk-ctrl is a top-level peripheral providing access to + the NoC and ensuring proper power sequencing of the VPU peripherals + located in the VPU domain of the SoC. + +properties: + compatible: + items: + - const: fsl,imx8mq-vpu-blk-ctrl + + reg: + maxItems: 1 + + '#power-domain-cells': + const: 1 + + power-domains: + minItems: 3 + maxItems: 3 + + power-domain-names: + items: + - const: bus + - const: g1 + - const: g2 + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: g1 + - const: g2 + +required: + - compatible + - reg + - power-domains + - power-domain-names + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + #include + + vpu_blk_ctrl: blk-ctrl@38320000 { + compatible = "fsl,imx8mq-vpu-blk-ctrl"; + reg = <0x38320000 0x100>; + power-domains = <&pgc_vpu>, <&pgc_vpu>, <&pgc_vpu>; + power-domain-names = "bus", "g1", "g2"; + clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>, + <&clk IMX8MQ_CLK_VPU_G2_ROOT>; + clock-names = "g1", "g2"; + #power-domain-cells = <1>; + }; -- cgit From 5f558b6dbf21c782a4c8f2f5f01d5bfb6792f818 Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Fri, 17 Dec 2021 22:36:16 +0100 Subject: dt-bindings: arm: imx: add Protonic PRT8MM board compatible Add the compatible string for the Protonic PRT8MM board, which is a reference design for a low-cost agricultural terminal. Signed-off-by: Lucas Stach Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 97f6eebad76a..5075fd8c1b42 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -771,6 +771,7 @@ properties: - gw,imx8mm-gw7902 # i.MX8MM Gateworks Board - kontron,imx8mm-n801x-som # i.MX8MM Kontron SL (N801X) SOM - variscite,var-som-mx8mm # i.MX8MM Variscite VAR-SOM-MX8MM module + - prt,prt8mm # i.MX8MM Protonic PRT8MM Board - const: fsl,imx8mm - description: Engicam i.Core MX8M Mini SoM based boards -- cgit From 864ea0e10cc90416a01b46f0d47a6f26dc020820 Mon Sep 17 00:00:00 2001 From: Beau Belgrave Date: Tue, 18 Jan 2022 12:43:26 -0800 Subject: user_events: Add documentation file Add a documentation file about user_events with example code, etc. explaining how it may be used. Link: https://lkml.kernel.org/r/20220118204326.2169-13-beaub@linux.microsoft.com Acked-by: Masami Hiramatsu Signed-off-by: Beau Belgrave Signed-off-by: Steven Rostedt (Google) --- Documentation/trace/index.rst | 1 + Documentation/trace/user_events.rst | 216 ++++++++++++++++++++++++++++++++++++ 2 files changed, 217 insertions(+) create mode 100644 Documentation/trace/user_events.rst (limited to 'Documentation') diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst index 3769b9b7aed8..3a47aa8341c6 100644 --- a/Documentation/trace/index.rst +++ b/Documentation/trace/index.rst @@ -30,3 +30,4 @@ Linux Tracing Technologies stm sys-t coresight/index + user_events diff --git a/Documentation/trace/user_events.rst b/Documentation/trace/user_events.rst new file mode 100644 index 000000000000..bddedabaca80 --- /dev/null +++ b/Documentation/trace/user_events.rst @@ -0,0 +1,216 @@ +========================================= +user_events: User-based Event Tracing +========================================= + +:Author: Beau Belgrave + +Overview +-------- +User based trace events allow user processes to create events and trace data +that can be viewed via existing tools, such as ftrace, perf and eBPF. +To enable this feature, build your kernel with CONFIG_USER_EVENTS=y. + +Programs can view status of the events via +/sys/kernel/debug/tracing/user_events_status and can both register and write +data out via /sys/kernel/debug/tracing/user_events_data. + +Programs can also use /sys/kernel/debug/tracing/dynamic_events to register and +delete user based events via the u: prefix. The format of the command to +dynamic_events is the same as the ioctl with the u: prefix applied. + +Typically programs will register a set of events that they wish to expose to +tools that can read trace_events (such as ftrace and perf). The registration +process gives back two ints to the program for each event. The first int is the +status index. This index describes which byte in the +/sys/kernel/debug/tracing/user_events_status file represents this event. The +second int is the write index. This index describes the data when a write() or +writev() is called on the /sys/kernel/debug/tracing/user_events_data file. + +The structures referenced in this document are contained with the +/include/uap/linux/user_events.h file in the source tree. + +**NOTE:** *Both user_events_status and user_events_data are under the tracefs +filesystem and may be mounted at different paths than above.* + +Registering +----------- +Registering within a user process is done via ioctl() out to the +/sys/kernel/debug/tracing/user_events_data file. The command to issue is +DIAG_IOCSREG. + +This command takes a struct user_reg as an argument:: + + struct user_reg { + u32 size; + u64 name_args; + u32 status_index; + u32 write_index; + }; + +The struct user_reg requires two inputs, the first is the size of the structure +to ensure forward and backward compatibility. The second is the command string +to issue for registering. Upon success two outputs are set, the status index +and the write index. + +User based events show up under tracefs like any other event under the +subsystem named "user_events". This means tools that wish to attach to the +events need to use /sys/kernel/debug/tracing/events/user_events/[name]/enable +or perf record -e user_events:[name] when attaching/recording. + +**NOTE:** *The write_index returned is only valid for the FD that was used* + +Command Format +^^^^^^^^^^^^^^ +The command string format is as follows:: + + name[:FLAG1[,FLAG2...]] [Field1[;Field2...]] + +Supported Flags +^^^^^^^^^^^^^^^ +**BPF_ITER** - EBPF programs attached to this event will get the raw iovec +struct instead of any data copies for max performance. + +Field Format +^^^^^^^^^^^^ +:: + + type name [size] + +Basic types are supported (__data_loc, u32, u64, int, char, char[20], etc). +User programs are encouraged to use clearly sized types like u32. + +**NOTE:** *Long is not supported since size can vary between user and kernel.* + +The size is only valid for types that start with a struct prefix. +This allows user programs to describe custom structs out to tools, if required. + +For example, a struct in C that looks like this:: + + struct mytype { + char data[20]; + }; + +Would be represented by the following field:: + + struct mytype myname 20 + +Deleting +----------- +Deleting an event from within a user process is done via ioctl() out to the +/sys/kernel/debug/tracing/user_events_data file. The command to issue is +DIAG_IOCSDEL. + +This command only requires a single string specifying the event to delete by +its name. Delete will only succeed if there are no references left to the +event (in both user and kernel space). User programs should use a separate file +to request deletes than the one used for registration due to this. + +Status +------ +When tools attach/record user based events the status of the event is updated +in realtime. This allows user programs to only incur the cost of the write() or +writev() calls when something is actively attached to the event. + +User programs call mmap() on /sys/kernel/debug/tracing/user_events_status to +check the status for each event that is registered. The byte to check in the +file is given back after the register ioctl() via user_reg.status_index. +Currently the size of user_events_status is a single page, however, custom +kernel configurations can change this size to allow more user based events. In +all cases the size of the file is a multiple of a page size. + +For example, if the register ioctl() gives back a status_index of 3 you would +check byte 3 of the returned mmap data to see if anything is attached to that +event. + +Administrators can easily check the status of all registered events by reading +the user_events_status file directly via a terminal. The output is as follows:: + + Byte:Name [# Comments] + ... + + Active: ActiveCount + Busy: BusyCount + Max: MaxCount + +For example, on a system that has a single event the output looks like this:: + + 1:test + + Active: 1 + Busy: 0 + Max: 4096 + +If a user enables the user event via ftrace, the output would change to this:: + + 1:test # Used by ftrace + + Active: 1 + Busy: 1 + Max: 4096 + +**NOTE:** *A status index of 0 will never be returned. This allows user +programs to have an index that can be used on error cases.* + +Status Bits +^^^^^^^^^^^ +The byte being checked will be non-zero if anything is attached. Programs can +check specific bits in the byte to see what mechanism has been attached. + +The following values are defined to aid in checking what has been attached: + +**EVENT_STATUS_FTRACE** - Bit set if ftrace has been attached (Bit 0). + +**EVENT_STATUS_PERF** - Bit set if perf/eBPF has been attached (Bit 1). + +Writing Data +------------ +After registering an event the same fd that was used to register can be used +to write an entry for that event. The write_index returned must be at the start +of the data, then the remaining data is treated as the payload of the event. + +For example, if write_index returned was 1 and I wanted to write out an int +payload of the event. Then the data would have to be 8 bytes (2 ints) in size, +with the first 4 bytes being equal to 1 and the last 4 bytes being equal to the +value I want as the payload. + +In memory this would look like this:: + + int index; + int payload; + +User programs might have well known structs that they wish to use to emit out +as payloads. In those cases writev() can be used, with the first vector being +the index and the following vector(s) being the actual event payload. + +For example, if I have a struct like this:: + + struct payload { + int src; + int dst; + int flags; + }; + +It's advised for user programs to do the following:: + + struct iovec io[2]; + struct payload e; + + io[0].iov_base = &write_index; + io[0].iov_len = sizeof(write_index); + io[1].iov_base = &e; + io[1].iov_len = sizeof(e); + + writev(fd, (const struct iovec*)io, 2); + +**NOTE:** *The write_index is not emitted out into the trace being recorded.* + +EBPF +---- +EBPF programs that attach to a user-based event tracepoint are given a pointer +to a struct user_bpf_context. The bpf context contains the data type (which can +be a user or kernel buffer, or can be a pointer to the iovec) and the data +length that was emitted (minus the write_index). + +Example Code +------------ +See sample code in samples/user_events. -- cgit From 00ffe9e0833cb6c28454ccb22bd3dc818bb84ace Mon Sep 17 00:00:00 2001 From: Reinhold Mueller Date: Thu, 27 Jan 2022 16:34:59 +0100 Subject: dt-bindings: arm: Add emtrion hardware emCON-MX8M Mini This patch presents the yaml patch for the emtrion GmbH emCON-MX8M Mini. Signed-off-by: Reinhold Mueller Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 5075fd8c1b42..e58e21efdf0b 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -762,6 +762,7 @@ properties: - enum: - beacon,imx8mm-beacon-kit # i.MX8MM Beacon Development Kit - boundary,imx8mm-nitrogen8mm # i.MX8MM Nitrogen Board + - emtrion,emcon-mx8mm-avari # emCON-MX8MM SoM on Avari Base - fsl,imx8mm-ddr4-evk # i.MX8MM DDR4 EVK Board - fsl,imx8mm-evk # i.MX8MM EVK Board - gw,imx8mm-gw71xx-0x # i.MX8MM Gateworks Development Kit -- cgit From 0cc525901fe9062dbd3c7a42dba254244a229072 Mon Sep 17 00:00:00 2001 From: Yassine Oudjana Date: Thu, 3 Feb 2022 07:25:13 +0000 Subject: dt-bindings: arm: qcom: Add msm8996 and apq8096 compatibles Add compatibles for MSM8996 and APQ8096 and all supported devices that have them. Signed-off-by: Yassine Oudjana Reviewed-by: Rob Herring Signed-off-by: Viresh Kumar --- Documentation/devicetree/bindings/arm/qcom.yaml | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 370aab274cd1..fd8410d26c99 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -173,7 +173,21 @@ properties: - const: qcom,apq8094 - items: - - const: qcom,msm8996-mtp + - enum: + - arrow,apq8096-db820c + - inforce,ifc6640 + - const: qcom,apq8096-sbc + - const: qcom,apq8096 + + - items: + - enum: + - qcom,msm8996-mtp + - sony,dora-row + - sony,kagura-row + - sony,keyaki-row + - xiaomi,gemini + - xiaomi,scorpio + - const: qcom,msm8996 - items: - enum: -- cgit From 784adeb3a37c2cfbcb24a5707ef751d164cac454 Mon Sep 17 00:00:00 2001 From: Yassine Oudjana Date: Thu, 3 Feb 2022 07:25:49 +0000 Subject: dt-bindings: opp: qcom-opp: Convert to DT schema Convert qcom-opp.txt to DT schema format. Signed-off-by: Yassine Oudjana Reviewed-by: Rob Herring Signed-off-by: Viresh Kumar --- .../devicetree/bindings/opp/opp-v2-qcom-level.yaml | 60 ++++++++++++++++++++++ Documentation/devicetree/bindings/opp/qcom-opp.txt | 19 ------- 2 files changed, 60 insertions(+), 19 deletions(-) create mode 100644 Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml delete mode 100644 Documentation/devicetree/bindings/opp/qcom-opp.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml new file mode 100644 index 000000000000..14a7a689ad6d --- /dev/null +++ b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/opp/opp-v2-qcom-level.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm OPP bindings to describe OPP nodes. + +maintainers: + - Niklas Cassel + +allOf: + - $ref: opp-v2-base.yaml# + +properties: + compatible: + const: operating-points-v2-qcom-level + +patternProperties: + '^opp-?[0-9]+$': + type: object + + properties: + opp-level: true + + qcom,opp-fuse-level: + description: | + A positive value representing the fuse corner/level associated with + this OPP node. Sometimes several corners/levels shares a certain fuse + corner/level. A fuse corner/level contains e.g. ref uV, min uV, + and max uV. + $ref: /schemas/types.yaml#/definitions/uint32 + + required: + - opp-level + - qcom,opp-fuse-level + +required: + - compatible + +additionalProperties: false + +examples: + - | + cpr_opp_table: opp-table-cpr { + compatible = "operating-points-v2-qcom-level"; + + cpr_opp1: opp1 { + opp-level = <1>; + qcom,opp-fuse-level = <1>; + }; + cpr_opp2: opp2 { + opp-level = <2>; + qcom,opp-fuse-level = <2>; + }; + cpr_opp3: opp3 { + opp-level = <3>; + qcom,opp-fuse-level = <3>; + }; + }; diff --git a/Documentation/devicetree/bindings/opp/qcom-opp.txt b/Documentation/devicetree/bindings/opp/qcom-opp.txt deleted file mode 100644 index 41d3e4ff2dc3..000000000000 --- a/Documentation/devicetree/bindings/opp/qcom-opp.txt +++ /dev/null @@ -1,19 +0,0 @@ -Qualcomm OPP bindings to describe OPP nodes - -The bindings are based on top of the operating-points-v2 bindings -described in Documentation/devicetree/bindings/opp/opp-v2-base.yaml -Additional properties are described below. - -* OPP Table Node - -Required properties: -- compatible: Allow OPPs to express their compatibility. It should be: - "operating-points-v2-qcom-level" - -* OPP Node - -Required properties: -- qcom,opp-fuse-level: A positive value representing the fuse corner/level - associated with this OPP node. Sometimes several corners/levels shares - a certain fuse corner/level. A fuse corner/level contains e.g. ref uV, - min uV, and max uV. -- cgit From ec24d1d55469b66f5d4393dc8cebc5ac8f4fc683 Mon Sep 17 00:00:00 2001 From: Yassine Oudjana Date: Thu, 3 Feb 2022 07:26:08 +0000 Subject: dt-bindings: opp: Convert qcom-nvmem-cpufreq to DT schema Convert qcom-nvmem-cpufreq to DT schema format, splitting it into an OPP schema and a CPUFreq schema in the process. Signed-off-by: Yassine Oudjana Reviewed-by: Rob Herring Signed-off-by: Viresh Kumar --- .../bindings/cpufreq/qcom-cpufreq-nvmem.yaml | 166 +++++ .../devicetree/bindings/opp/opp-v2-kryo-cpu.yaml | 257 +++++++ .../devicetree/bindings/opp/qcom-nvmem-cpufreq.txt | 796 --------------------- 3 files changed, 423 insertions(+), 796 deletions(-) create mode 100644 Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml create mode 100644 Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml delete mode 100644 Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml new file mode 100644 index 000000000000..a9a776da5505 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml @@ -0,0 +1,166 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/cpufreq/qcom-cpufreq-nvmem.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. NVMEM CPUFreq bindings + +maintainers: + - Ilia Lin + +description: | + In certain Qualcomm Technologies, Inc. SoCs such as QCS404, The CPU supply + voltage is dynamically configured by Core Power Reduction (CPR) depending on + current CPU frequency and efuse values. + CPR provides a power domain with multiple levels that are selected depending + on the CPU OPP in use. The CPUFreq driver sets the CPR power domain level + according to the required OPPs defined in the CPU OPP tables. + +select: + properties: + compatible: + contains: + enum: + - qcom,qcs404 + required: + - compatible + +properties: + cpus: + type: object + + patternProperties: + 'cpu@[0-9a-f]+': + type: object + + properties: + power-domains: + maxItems: 1 + + power-domain-names: + items: + - const: cpr + + required: + - power-domains + - power-domain-names + +patternProperties: + '^opp-table(-[a-z0-9]+)?$': + if: + properties: + compatible: + const: operating-points-v2-kryo-cpu + then: + patternProperties: + '^opp-?[0-9]+$': + required: + - required-opps + +additionalProperties: true + +examples: + - | + / { + model = "Qualcomm Technologies, Inc. QCS404"; + compatible = "qcom,qcs404"; + #address-cells = <2>; + #size-cells = <2>; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + CPU0: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + next-level-cache = <&L2_0>; + #cooling-cells = <2>; + clocks = <&apcs_glb>; + operating-points-v2 = <&cpu_opp_table>; + power-domains = <&cpr>; + power-domain-names = "cpr"; + }; + + CPU1: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + next-level-cache = <&L2_0>; + #cooling-cells = <2>; + clocks = <&apcs_glb>; + operating-points-v2 = <&cpu_opp_table>; + power-domains = <&cpr>; + power-domain-names = "cpr"; + }; + + CPU2: cpu@102 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x102>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + next-level-cache = <&L2_0>; + #cooling-cells = <2>; + clocks = <&apcs_glb>; + operating-points-v2 = <&cpu_opp_table>; + power-domains = <&cpr>; + power-domain-names = "cpr"; + }; + + CPU3: cpu@103 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x103>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + next-level-cache = <&L2_0>; + #cooling-cells = <2>; + clocks = <&apcs_glb>; + operating-points-v2 = <&cpu_opp_table>; + power-domains = <&cpr>; + power-domain-names = "cpr"; + }; + }; + + cpu_opp_table: opp-table-cpu { + compatible = "operating-points-v2-kryo-cpu"; + opp-shared; + + opp-1094400000 { + opp-hz = /bits/ 64 <1094400000>; + required-opps = <&cpr_opp1>; + }; + opp-1248000000 { + opp-hz = /bits/ 64 <1248000000>; + required-opps = <&cpr_opp2>; + }; + opp-1401600000 { + opp-hz = /bits/ 64 <1401600000>; + required-opps = <&cpr_opp3>; + }; + }; + + cpr_opp_table: opp-table-cpr { + compatible = "operating-points-v2-qcom-level"; + + cpr_opp1: opp1 { + opp-level = <1>; + qcom,opp-fuse-level = <1>; + }; + cpr_opp2: opp2 { + opp-level = <2>; + qcom,opp-fuse-level = <2>; + }; + cpr_opp3: opp3 { + opp-level = <3>; + qcom,opp-fuse-level = <3>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml new file mode 100644 index 000000000000..8c2e9ac5f68d --- /dev/null +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml @@ -0,0 +1,257 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/opp/opp-v2-kryo-cpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. NVMEM OPP bindings + +maintainers: + - Ilia Lin + +allOf: + - $ref: opp-v2-base.yaml# + +description: | + In certain Qualcomm Technologies, Inc. SoCs like APQ8096 and MSM8996, + the CPU frequencies subset and voltage value of each OPP varies based on + the silicon variant in use. + Qualcomm Technologies, Inc. Process Voltage Scaling Tables + defines the voltage and frequency value based on the msm-id in SMEM + and speedbin blown in the efuse combination. + The qcom-cpufreq-nvmem driver reads the msm-id and efuse value from the SoC + to provide the OPP framework with required information (existing HW bitmap). + This is used to determine the voltage and frequency value for each OPP of + operating-points-v2 table when it is parsed by the OPP framework. + +properties: + compatible: + const: operating-points-v2-kryo-cpu + + nvmem-cells: + description: | + A phandle pointing to a nvmem-cells node representing the + efuse registers that has information about the + speedbin that is used to select the right frequency/voltage + value pair. + + opp-shared: true + +patternProperties: + '^opp-?[0-9]+$': + type: object + + properties: + opp-hz: true + + opp-microvolt: true + + opp-supported-hw: + description: | + A single 32 bit bitmap value, representing compatible HW. + Bitmap: + 0: MSM8996 V3, speedbin 0 + 1: MSM8996 V3, speedbin 1 + 2: MSM8996 V3, speedbin 2 + 3: unused + 4: MSM8996 SG, speedbin 0 + 5: MSM8996 SG, speedbin 1 + 6: MSM8996 SG, speedbin 2 + 7-31: unused + maximum: 0x77 + + clock-latency-ns: true + + required-opps: true + + required: + - opp-hz + +required: + - compatible + +if: + required: + - nvmem-cells +then: + patternProperties: + '^opp-?[0-9]+$': + required: + - opp-supported-hw + +additionalProperties: false + +examples: + - | + / { + model = "Qualcomm Technologies, Inc. DB820c"; + compatible = "arrow,apq8096-db820c", "qcom,apq8096-sbc", "qcom,apq8096"; + #address-cells = <2>; + #size-cells = <2>; + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x0>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + capacity-dmips-mhz = <1024>; + clocks = <&kryocc 0>; + operating-points-v2 = <&cluster0_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_0>; + L2_0: l2-cache { + compatible = "cache"; + cache-level = <2>; + }; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x1>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + capacity-dmips-mhz = <1024>; + clocks = <&kryocc 0>; + operating-points-v2 = <&cluster0_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_0>; + }; + + CPU2: cpu@100 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + capacity-dmips-mhz = <1024>; + clocks = <&kryocc 1>; + operating-points-v2 = <&cluster1_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_1>; + L2_1: l2-cache { + compatible = "cache"; + cache-level = <2>; + }; + }; + + CPU3: cpu@101 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + capacity-dmips-mhz = <1024>; + clocks = <&kryocc 1>; + operating-points-v2 = <&cluster1_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_1>; + }; + + cpu-map { + cluster0 { + core0 { + cpu = <&CPU0>; + }; + + core1 { + cpu = <&CPU1>; + }; + }; + + cluster1 { + core0 { + cpu = <&CPU2>; + }; + + core1 { + cpu = <&CPU3>; + }; + }; + }; + }; + + cluster0_opp: opp-table-0 { + compatible = "operating-points-v2-kryo-cpu"; + nvmem-cells = <&speedbin_efuse>; + opp-shared; + + opp-307200000 { + opp-hz = /bits/ 64 <307200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x77>; + clock-latency-ns = <200000>; + }; + opp-1593600000 { + opp-hz = /bits/ 64 <1593600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x71>; + clock-latency-ns = <200000>; + }; + opp-2188800000 { + opp-hz = /bits/ 64 <2188800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x10>; + clock-latency-ns = <200000>; + }; + }; + + cluster1_opp: opp-table-1 { + compatible = "operating-points-v2-kryo-cpu"; + nvmem-cells = <&speedbin_efuse>; + opp-shared; + + opp-307200000 { + opp-hz = /bits/ 64 <307200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x77>; + clock-latency-ns = <200000>; + }; + opp-1593600000 { + opp-hz = /bits/ 64 <1593600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-2150400000 { + opp-hz = /bits/ 64 <2150400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x31>; + clock-latency-ns = <200000>; + }; + opp-2342400000 { + opp-hz = /bits/ 64 <2342400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x10>; + clock-latency-ns = <200000>; + }; + }; + + smem { + compatible = "qcom,smem"; + memory-region = <&smem_mem>; + hwlocks = <&tcsr_mutex 3>; + }; + + soc { + #address-cells = <1>; + #size-cells = <1>; + + qfprom: qfprom@74000 { + compatible = "qcom,msm8996-qfprom", "qcom,qfprom"; + reg = <0x00074000 0x8ff>; + #address-cells = <1>; + #size-cells = <1>; + + speedbin_efuse: speedbin@133 { + reg = <0x133 0x1>; + bits = <5 3>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt deleted file mode 100644 index 64f07417ecfb..000000000000 --- a/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt +++ /dev/null @@ -1,796 +0,0 @@ -Qualcomm Technologies, Inc. NVMEM CPUFreq and OPP bindings -=================================== - -In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996, -the CPU frequencies subset and voltage value of each OPP varies based on -the silicon variant in use. -Qualcomm Technologies, Inc. Process Voltage Scaling Tables -defines the voltage and frequency value based on the msm-id in SMEM -and speedbin blown in the efuse combination. -The qcom-cpufreq-nvmem driver reads the msm-id and efuse value from the SoC -to provide the OPP framework with required information (existing HW bitmap). -This is used to determine the voltage and frequency value for each OPP of -operating-points-v2 table when it is parsed by the OPP framework. - -Required properties: --------------------- -In 'cpu' nodes: -- operating-points-v2: Phandle to the operating-points-v2 table to use. - -In 'operating-points-v2' table: -- compatible: Should be - - 'operating-points-v2-kryo-cpu' for apq8096, msm8996, msm8974, - apq8064, ipq8064, msm8960 and ipq8074. - -Optional properties: --------------------- -In 'cpu' nodes: -- power-domains: A phandle pointing to the PM domain specifier which provides - the performance states available for active state management. - Please refer to the power-domains bindings - Documentation/devicetree/bindings/power/power_domain.txt - and also examples below. -- power-domain-names: Should be - - 'cpr' for qcs404. - -In 'operating-points-v2' table: -- nvmem-cells: A phandle pointing to a nvmem-cells node representing the - efuse registers that has information about the - speedbin that is used to select the right frequency/voltage - value pair. - Please refer the for nvmem-cells - bindings Documentation/devicetree/bindings/nvmem/nvmem.txt - and also examples below. - -In every OPP node: -- opp-supported-hw: A single 32 bit bitmap value, representing compatible HW. - Bitmap: - 0: MSM8996 V3, speedbin 0 - 1: MSM8996 V3, speedbin 1 - 2: MSM8996 V3, speedbin 2 - 3: unused - 4: MSM8996 SG, speedbin 0 - 5: MSM8996 SG, speedbin 1 - 6: MSM8996 SG, speedbin 2 - 7-31: unused - -Example 1: ---------- - - cpus { - #address-cells = <2>; - #size-cells = <0>; - - CPU0: cpu@0 { - device_type = "cpu"; - compatible = "qcom,kryo"; - reg = <0x0 0x0>; - enable-method = "psci"; - clocks = <&kryocc 0>; - cpu-supply = <&pm8994_s11_saw>; - operating-points-v2 = <&cluster0_opp>; - #cooling-cells = <2>; - next-level-cache = <&L2_0>; - L2_0: l2-cache { - compatible = "cache"; - cache-level = <2>; - }; - }; - - CPU1: cpu@1 { - device_type = "cpu"; - compatible = "qcom,kryo"; - reg = <0x0 0x1>; - enable-method = "psci"; - clocks = <&kryocc 0>; - cpu-supply = <&pm8994_s11_saw>; - operating-points-v2 = <&cluster0_opp>; - #cooling-cells = <2>; - next-level-cache = <&L2_0>; - }; - - CPU2: cpu@100 { - device_type = "cpu"; - compatible = "qcom,kryo"; - reg = <0x0 0x100>; - enable-method = "psci"; - clocks = <&kryocc 1>; - cpu-supply = <&pm8994_s11_saw>; - operating-points-v2 = <&cluster1_opp>; - #cooling-cells = <2>; - next-level-cache = <&L2_1>; - L2_1: l2-cache { - compatible = "cache"; - cache-level = <2>; - }; - }; - - CPU3: cpu@101 { - device_type = "cpu"; - compatible = "qcom,kryo"; - reg = <0x0 0x101>; - enable-method = "psci"; - clocks = <&kryocc 1>; - cpu-supply = <&pm8994_s11_saw>; - operating-points-v2 = <&cluster1_opp>; - #cooling-cells = <2>; - next-level-cache = <&L2_1>; - }; - - cpu-map { - cluster0 { - core0 { - cpu = <&CPU0>; - }; - - core1 { - cpu = <&CPU1>; - }; - }; - - cluster1 { - core0 { - cpu = <&CPU2>; - }; - - core1 { - cpu = <&CPU3>; - }; - }; - }; - }; - - cluster0_opp: opp_table0 { - compatible = "operating-points-v2-kryo-cpu"; - nvmem-cells = <&speedbin_efuse>; - opp-shared; - - opp-307200000 { - opp-hz = /bits/ 64 <307200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x77>; - clock-latency-ns = <200000>; - }; - opp-384000000 { - opp-hz = /bits/ 64 <384000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-422400000 { - opp-hz = /bits/ 64 <422400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-460800000 { - opp-hz = /bits/ 64 <460800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-480000000 { - opp-hz = /bits/ 64 <480000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-537600000 { - opp-hz = /bits/ 64 <537600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-556800000 { - opp-hz = /bits/ 64 <556800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-614400000 { - opp-hz = /bits/ 64 <614400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-652800000 { - opp-hz = /bits/ 64 <652800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-691200000 { - opp-hz = /bits/ 64 <691200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-729600000 { - opp-hz = /bits/ 64 <729600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-768000000 { - opp-hz = /bits/ 64 <768000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-844800000 { - opp-hz = /bits/ 64 <844800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x77>; - clock-latency-ns = <200000>; - }; - opp-902400000 { - opp-hz = /bits/ 64 <902400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-960000000 { - opp-hz = /bits/ 64 <960000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-979200000 { - opp-hz = /bits/ 64 <979200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1036800000 { - opp-hz = /bits/ 64 <1036800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1056000000 { - opp-hz = /bits/ 64 <1056000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1113600000 { - opp-hz = /bits/ 64 <1113600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1132800000 { - opp-hz = /bits/ 64 <1132800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1190400000 { - opp-hz = /bits/ 64 <1190400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1209600000 { - opp-hz = /bits/ 64 <1209600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1228800000 { - opp-hz = /bits/ 64 <1228800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1286400000 { - opp-hz = /bits/ 64 <1286400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1324800000 { - opp-hz = /bits/ 64 <1324800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x5>; - clock-latency-ns = <200000>; - }; - opp-1363200000 { - opp-hz = /bits/ 64 <1363200000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x72>; - clock-latency-ns = <200000>; - }; - opp-1401600000 { - opp-hz = /bits/ 64 <1401600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x5>; - clock-latency-ns = <200000>; - }; - opp-1440000000 { - opp-hz = /bits/ 64 <1440000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1478400000 { - opp-hz = /bits/ 64 <1478400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x1>; - clock-latency-ns = <200000>; - }; - opp-1497600000 { - opp-hz = /bits/ 64 <1497600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x4>; - clock-latency-ns = <200000>; - }; - opp-1516800000 { - opp-hz = /bits/ 64 <1516800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1593600000 { - opp-hz = /bits/ 64 <1593600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x71>; - clock-latency-ns = <200000>; - }; - opp-1996800000 { - opp-hz = /bits/ 64 <1996800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x20>; - clock-latency-ns = <200000>; - }; - opp-2188800000 { - opp-hz = /bits/ 64 <2188800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x10>; - clock-latency-ns = <200000>; - }; - }; - - cluster1_opp: opp_table1 { - compatible = "operating-points-v2-kryo-cpu"; - nvmem-cells = <&speedbin_efuse>; - opp-shared; - - opp-307200000 { - opp-hz = /bits/ 64 <307200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x77>; - clock-latency-ns = <200000>; - }; - opp-384000000 { - opp-hz = /bits/ 64 <384000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-403200000 { - opp-hz = /bits/ 64 <403200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-460800000 { - opp-hz = /bits/ 64 <460800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-480000000 { - opp-hz = /bits/ 64 <480000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-537600000 { - opp-hz = /bits/ 64 <537600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-556800000 { - opp-hz = /bits/ 64 <556800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-614400000 { - opp-hz = /bits/ 64 <614400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-652800000 { - opp-hz = /bits/ 64 <652800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-691200000 { - opp-hz = /bits/ 64 <691200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-729600000 { - opp-hz = /bits/ 64 <729600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-748800000 { - opp-hz = /bits/ 64 <748800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-806400000 { - opp-hz = /bits/ 64 <806400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-825600000 { - opp-hz = /bits/ 64 <825600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-883200000 { - opp-hz = /bits/ 64 <883200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-902400000 { - opp-hz = /bits/ 64 <902400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-940800000 { - opp-hz = /bits/ 64 <940800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-979200000 { - opp-hz = /bits/ 64 <979200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1036800000 { - opp-hz = /bits/ 64 <1036800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1056000000 { - opp-hz = /bits/ 64 <1056000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1113600000 { - opp-hz = /bits/ 64 <1113600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1132800000 { - opp-hz = /bits/ 64 <1132800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1190400000 { - opp-hz = /bits/ 64 <1190400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1209600000 { - opp-hz = /bits/ 64 <1209600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1248000000 { - opp-hz = /bits/ 64 <1248000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1286400000 { - opp-hz = /bits/ 64 <1286400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1324800000 { - opp-hz = /bits/ 64 <1324800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1363200000 { - opp-hz = /bits/ 64 <1363200000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1401600000 { - opp-hz = /bits/ 64 <1401600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1440000000 { - opp-hz = /bits/ 64 <1440000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1478400000 { - opp-hz = /bits/ 64 <1478400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1516800000 { - opp-hz = /bits/ 64 <1516800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1555200000 { - opp-hz = /bits/ 64 <1555200000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1593600000 { - opp-hz = /bits/ 64 <1593600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1632000000 { - opp-hz = /bits/ 64 <1632000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1670400000 { - opp-hz = /bits/ 64 <1670400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1708800000 { - opp-hz = /bits/ 64 <1708800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1747200000 { - opp-hz = /bits/ 64 <1747200000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1785600000 { - opp-hz = /bits/ 64 <1785600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1804800000 { - opp-hz = /bits/ 64 <1804800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x6>; - clock-latency-ns = <200000>; - }; - opp-1824000000 { - opp-hz = /bits/ 64 <1824000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x71>; - clock-latency-ns = <200000>; - }; - opp-1900800000 { - opp-hz = /bits/ 64 <1900800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x74>; - clock-latency-ns = <200000>; - }; - opp-1920000000 { - opp-hz = /bits/ 64 <1920000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x1>; - clock-latency-ns = <200000>; - }; - opp-1977600000 { - opp-hz = /bits/ 64 <1977600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x30>; - clock-latency-ns = <200000>; - }; - opp-1996800000 { - opp-hz = /bits/ 64 <1996800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x1>; - clock-latency-ns = <200000>; - }; - opp-2054400000 { - opp-hz = /bits/ 64 <2054400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x30>; - clock-latency-ns = <200000>; - }; - opp-2073600000 { - opp-hz = /bits/ 64 <2073600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x1>; - clock-latency-ns = <200000>; - }; - opp-2150400000 { - opp-hz = /bits/ 64 <2150400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x31>; - clock-latency-ns = <200000>; - }; - opp-2246400000 { - opp-hz = /bits/ 64 <2246400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x10>; - clock-latency-ns = <200000>; - }; - opp-2342400000 { - opp-hz = /bits/ 64 <2342400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x10>; - clock-latency-ns = <200000>; - }; - }; - -.... - -reserved-memory { - #address-cells = <2>; - #size-cells = <2>; - ranges; -.... - smem_mem: smem-mem@86000000 { - reg = <0x0 0x86000000 0x0 0x200000>; - no-map; - }; -.... -}; - -smem { - compatible = "qcom,smem"; - memory-region = <&smem_mem>; - hwlocks = <&tcsr_mutex 3>; -}; - -soc { -.... - qfprom: qfprom@74000 { - compatible = "qcom,qfprom"; - reg = <0x00074000 0x8ff>; - #address-cells = <1>; - #size-cells = <1>; - .... - speedbin_efuse: speedbin@133 { - reg = <0x133 0x1>; - bits = <5 3>; - }; - }; -}; - -Example 2: ---------- - - cpus { - #address-cells = <1>; - #size-cells = <0>; - - CPU0: cpu@100 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x100>; - .... - clocks = <&apcs_glb>; - operating-points-v2 = <&cpu_opp_table>; - power-domains = <&cpr>; - power-domain-names = "cpr"; - }; - - CPU1: cpu@101 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x101>; - .... - clocks = <&apcs_glb>; - operating-points-v2 = <&cpu_opp_table>; - power-domains = <&cpr>; - power-domain-names = "cpr"; - }; - - CPU2: cpu@102 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x102>; - .... - clocks = <&apcs_glb>; - operating-points-v2 = <&cpu_opp_table>; - power-domains = <&cpr>; - power-domain-names = "cpr"; - }; - - CPU3: cpu@103 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x103>; - .... - clocks = <&apcs_glb>; - operating-points-v2 = <&cpu_opp_table>; - power-domains = <&cpr>; - power-domain-names = "cpr"; - }; - }; - - cpu_opp_table: cpu-opp-table { - compatible = "operating-points-v2-kryo-cpu"; - opp-shared; - - opp-1094400000 { - opp-hz = /bits/ 64 <1094400000>; - required-opps = <&cpr_opp1>; - }; - opp-1248000000 { - opp-hz = /bits/ 64 <1248000000>; - required-opps = <&cpr_opp2>; - }; - opp-1401600000 { - opp-hz = /bits/ 64 <1401600000>; - required-opps = <&cpr_opp3>; - }; - }; - - cpr_opp_table: cpr-opp-table { - compatible = "operating-points-v2-qcom-level"; - - cpr_opp1: opp1 { - opp-level = <1>; - qcom,opp-fuse-level = <1>; - }; - cpr_opp2: opp2 { - opp-level = <2>; - qcom,opp-fuse-level = <2>; - }; - cpr_opp3: opp3 { - opp-level = <3>; - qcom,opp-fuse-level = <3>; - }; - }; - -.... - -soc { -.... - cpr: power-controller@b018000 { - compatible = "qcom,qcs404-cpr", "qcom,cpr"; - reg = <0x0b018000 0x1000>; - .... - vdd-apc-supply = <&pms405_s3>; - #power-domain-cells = <0>; - operating-points-v2 = <&cpr_opp_table>; - .... - }; -}; -- cgit From 8acf5cb92d9dc0a6eff7a22b01432d0379656e45 Mon Sep 17 00:00:00 2001 From: Yassine Oudjana Date: Thu, 3 Feb 2022 07:26:58 +0000 Subject: dt-bindings: power: avs: qcom,cpr: Convert to DT schema Convert qcom,cpr.txt to DT schema format. Signed-off-by: Yassine Oudjana Reviewed-by: Rob Herring Signed-off-by: Viresh Kumar --- .../devicetree/bindings/power/avs/qcom,cpr.txt | 130 ----------------- .../devicetree/bindings/power/avs/qcom,cpr.yaml | 160 +++++++++++++++++++++ 2 files changed, 160 insertions(+), 130 deletions(-) delete mode 100644 Documentation/devicetree/bindings/power/avs/qcom,cpr.txt create mode 100644 Documentation/devicetree/bindings/power/avs/qcom,cpr.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/avs/qcom,cpr.txt b/Documentation/devicetree/bindings/power/avs/qcom,cpr.txt deleted file mode 100644 index ab0d5ebbad4e..000000000000 --- a/Documentation/devicetree/bindings/power/avs/qcom,cpr.txt +++ /dev/null @@ -1,130 +0,0 @@ -QCOM CPR (Core Power Reduction) - -CPR (Core Power Reduction) is a technology to reduce core power on a CPU -or other device. Each OPP of a device corresponds to a "corner" that has -a range of valid voltages for a particular frequency. While the device is -running at a particular frequency, CPR monitors dynamic factors such as -temperature, etc. and suggests adjustments to the voltage to save power -and meet silicon characteristic requirements. - -- compatible: - Usage: required - Value type: - Definition: should be "qcom,qcs404-cpr", "qcom,cpr" for qcs404 - -- reg: - Usage: required - Value type: - Definition: base address and size of the rbcpr register region - -- interrupts: - Usage: required - Value type: - Definition: should specify the CPR interrupt - -- clocks: - Usage: required - Value type: - Definition: phandle to the reference clock - -- clock-names: - Usage: required - Value type: - Definition: must be "ref" - -- vdd-apc-supply: - Usage: required - Value type: - Definition: phandle to the vdd-apc-supply regulator - -- #power-domain-cells: - Usage: required - Value type: - Definition: should be 0 - -- operating-points-v2: - Usage: required - Value type: - Definition: A phandle to the OPP table containing the - performance states supported by the CPR - power domain - -- acc-syscon: - Usage: optional - Value type: - Definition: phandle to syscon for writing ACC settings - -- nvmem-cells: - Usage: required - Value type: - Definition: phandle to nvmem cells containing the data - that makes up a fuse corner, for each fuse corner. - As well as the CPR fuse revision. - -- nvmem-cell-names: - Usage: required - Value type: - Definition: should be "cpr_quotient_offset1", "cpr_quotient_offset2", - "cpr_quotient_offset3", "cpr_init_voltage1", - "cpr_init_voltage2", "cpr_init_voltage3", "cpr_quotient1", - "cpr_quotient2", "cpr_quotient3", "cpr_ring_osc1", - "cpr_ring_osc2", "cpr_ring_osc3", "cpr_fuse_revision" - for qcs404. - -Example: - - cpr_opp_table: cpr-opp-table { - compatible = "operating-points-v2-qcom-level"; - - cpr_opp1: opp1 { - opp-level = <1>; - qcom,opp-fuse-level = <1>; - }; - cpr_opp2: opp2 { - opp-level = <2>; - qcom,opp-fuse-level = <2>; - }; - cpr_opp3: opp3 { - opp-level = <3>; - qcom,opp-fuse-level = <3>; - }; - }; - - power-controller@b018000 { - compatible = "qcom,qcs404-cpr", "qcom,cpr"; - reg = <0x0b018000 0x1000>; - interrupts = <0 15 IRQ_TYPE_EDGE_RISING>; - clocks = <&xo_board>; - clock-names = "ref"; - vdd-apc-supply = <&pms405_s3>; - #power-domain-cells = <0>; - operating-points-v2 = <&cpr_opp_table>; - acc-syscon = <&tcsr>; - - nvmem-cells = <&cpr_efuse_quot_offset1>, - <&cpr_efuse_quot_offset2>, - <&cpr_efuse_quot_offset3>, - <&cpr_efuse_init_voltage1>, - <&cpr_efuse_init_voltage2>, - <&cpr_efuse_init_voltage3>, - <&cpr_efuse_quot1>, - <&cpr_efuse_quot2>, - <&cpr_efuse_quot3>, - <&cpr_efuse_ring1>, - <&cpr_efuse_ring2>, - <&cpr_efuse_ring3>, - <&cpr_efuse_revision>; - nvmem-cell-names = "cpr_quotient_offset1", - "cpr_quotient_offset2", - "cpr_quotient_offset3", - "cpr_init_voltage1", - "cpr_init_voltage2", - "cpr_init_voltage3", - "cpr_quotient1", - "cpr_quotient2", - "cpr_quotient3", - "cpr_ring_osc1", - "cpr_ring_osc2", - "cpr_ring_osc3", - "cpr_fuse_revision"; - }; diff --git a/Documentation/devicetree/bindings/power/avs/qcom,cpr.yaml b/Documentation/devicetree/bindings/power/avs/qcom,cpr.yaml new file mode 100644 index 000000000000..3301fa0c2653 --- /dev/null +++ b/Documentation/devicetree/bindings/power/avs/qcom,cpr.yaml @@ -0,0 +1,160 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/avs/qcom,cpr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Core Power Reduction (CPR) bindings + +maintainers: + - Niklas Cassel + +description: | + CPR (Core Power Reduction) is a technology to reduce core power on a CPU + or other device. Each OPP of a device corresponds to a "corner" that has + a range of valid voltages for a particular frequency. While the device is + running at a particular frequency, CPR monitors dynamic factors such as + temperature, etc. and suggests adjustments to the voltage to save power + and meet silicon characteristic requirements. + +properties: + compatible: + items: + - enum: + - qcom,qcs404-cpr + - const: qcom,cpr + + reg: + description: Base address and size of the RBCPR register region. + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Reference clock. + + clock-names: + items: + - const: ref + + vdd-apc-supply: + description: APC regulator supply. + + '#power-domain-cells': + const: 0 + + operating-points-v2: + description: | + A phandle to the OPP table containing the performance states + supported by the CPR power domain. + + acc-syscon: + description: A phandle to the syscon used for writing ACC settings. + + nvmem-cells: + items: + - description: Corner 1 quotient offset + - description: Corner 2 quotient offset + - description: Corner 3 quotient offset + - description: Corner 1 initial voltage + - description: Corner 2 initial voltage + - description: Corner 3 initial voltage + - description: Corner 1 quotient + - description: Corner 2 quotient + - description: Corner 3 quotient + - description: Corner 1 ring oscillator + - description: Corner 2 ring oscillator + - description: Corner 3 ring oscillator + - description: Fuse revision + + nvmem-cell-names: + items: + - const: cpr_quotient_offset1 + - const: cpr_quotient_offset2 + - const: cpr_quotient_offset3 + - const: cpr_init_voltage1 + - const: cpr_init_voltage2 + - const: cpr_init_voltage3 + - const: cpr_quotient1 + - const: cpr_quotient2 + - const: cpr_quotient3 + - const: cpr_ring_osc1 + - const: cpr_ring_osc2 + - const: cpr_ring_osc3 + - const: cpr_fuse_revision + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - vdd-apc-supply + - '#power-domain-cells' + - operating-points-v2 + - nvmem-cells + - nvmem-cell-names + +additionalProperties: false + +examples: + - | + #include + + cpr_opp_table: opp-table-cpr { + compatible = "operating-points-v2-qcom-level"; + + cpr_opp1: opp1 { + opp-level = <1>; + qcom,opp-fuse-level = <1>; + }; + cpr_opp2: opp2 { + opp-level = <2>; + qcom,opp-fuse-level = <2>; + }; + cpr_opp3: opp3 { + opp-level = <3>; + qcom,opp-fuse-level = <3>; + }; + }; + + power-controller@b018000 { + compatible = "qcom,qcs404-cpr", "qcom,cpr"; + reg = <0x0b018000 0x1000>; + interrupts = <0 15 IRQ_TYPE_EDGE_RISING>; + clocks = <&xo_board>; + clock-names = "ref"; + vdd-apc-supply = <&pms405_s3>; + #power-domain-cells = <0>; + operating-points-v2 = <&cpr_opp_table>; + acc-syscon = <&tcsr>; + + nvmem-cells = <&cpr_efuse_quot_offset1>, + <&cpr_efuse_quot_offset2>, + <&cpr_efuse_quot_offset3>, + <&cpr_efuse_init_voltage1>, + <&cpr_efuse_init_voltage2>, + <&cpr_efuse_init_voltage3>, + <&cpr_efuse_quot1>, + <&cpr_efuse_quot2>, + <&cpr_efuse_quot3>, + <&cpr_efuse_ring1>, + <&cpr_efuse_ring2>, + <&cpr_efuse_ring3>, + <&cpr_efuse_revision>; + nvmem-cell-names = "cpr_quotient_offset1", + "cpr_quotient_offset2", + "cpr_quotient_offset3", + "cpr_init_voltage1", + "cpr_init_voltage2", + "cpr_init_voltage3", + "cpr_quotient1", + "cpr_quotient2", + "cpr_quotient3", + "cpr_ring_osc1", + "cpr_ring_osc2", + "cpr_ring_osc3", + "cpr_fuse_revision"; + }; -- cgit From 56f26f177b26de041edef245562b68eb857093fc Mon Sep 17 00:00:00 2001 From: Dinh Nguyen Date: Tue, 25 Jan 2022 10:18:19 -0600 Subject: dt-bindings: usb: dwc2: add compatible "intel,socfpga-agilex-hsotg" Add the compatible "intel,socfpga-agilex-hsotg" to the DWC2 implementation, because the Agilex DWC2 implementation does not support clock gating. Acked-by: Rob Herring Signed-off-by: Dinh Nguyen Link: https://lore.kernel.org/r/20220125161821.1951906-1-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/dwc2.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index f00867ebc147..481aaa09f3f2 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -53,6 +53,7 @@ properties: - const: st,stm32mp15-hsotg - const: snps,dwc2 - const: samsung,s3c6400-hsotg + - const: intel,socfpga-agilex-hsotg reg: maxItems: 1 -- cgit From 8609e3e175041b00ac12c113039f3a995ea2d5b0 Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Fri, 28 Jan 2022 14:28:59 +0800 Subject: dt-bindings: usb: mtk-xhci: add support ip-sleep for mt8195 There are 4 USB controllers on MT8195, each controller's wakeup control is different, add some specific versions for them. Acked-by: AngeloGioacchino Del Regno Acked-by: Rob Herring Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/20220128062902.26273-1-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml index 11f7bacd4e2b..41efb51638d1 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml @@ -146,7 +146,11 @@ properties: 2 - used by mt2712 etc, revision 2 following IPM rule; 101 - used by mt8183, specific 1.01; 102 - used by mt8192, specific 1.02; - enum: [1, 2, 101, 102] + 103 - used by mt8195, IP0, specific 1.03; + 104 - used by mt8195, IP1, specific 1.04; + 105 - used by mt8195, IP2, specific 1.05; + 106 - used by mt8195, IP3, specific 1.06; + enum: [1, 2, 101, 102, 103, 104, 105, 106] mediatek,u3p-dis-msk: $ref: /schemas/types.yaml#/definitions/uint32 -- cgit From 3a0f60b5ea321e5071807a5c0c37656d5be810d6 Mon Sep 17 00:00:00 2001 From: ChiYuan Huang Date: Wed, 9 Feb 2022 23:42:41 +0800 Subject: dt-bindings: usb: rt1719: Add binding for Richtek RT1719 Add binding for Richtek RT1719. Reviewed-by: Rob Herring Signed-off-by: ChiYuan Huang Link: https://lore.kernel.org/r/1644421362-32104-2-git-send-email-u0084500@gmail.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/richtek,rt1719.yaml | 85 ++++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/richtek,rt1719.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml b/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml new file mode 100644 index 000000000000..65a93f7738d5 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/usb/richtek,rt1719.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Richtek RT1719 sink-only Type-C PD controller bindings + +maintainers: + - ChiYuan Huang + +description: | + The RT1719 is a sink-only USB Type-C contoller that complies with the latest + USB Type-C and PD standards. It does the USB Type-C detection including attach + and orientation. It integrates the physical layer of the USB BMC power + delivery protocol to allow up to 100W of power. The BMC PD block enables full + support for alternative interfaces of the Type-C specification. + +properties: + compatible: + enum: + - richtek,rt1719 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + wakeup-source: + description: enable IRQ remote wakeup, see power/wakeup-source.txt + type: boolean + + connector: + type: object + $ref: ../connector/usb-connector.yaml# + description: + Properties for usb c connector. + +additionalProperties: false + +required: + - compatible + - reg + - connector + - interrupts + +examples: + - | + #include + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + rt1719@43 { + compatible = "richtek,rt1719"; + reg = <0x43>; + interrupts-extended = <&gpio26 2 IRQ_TYPE_LEVEL_LOW>; + wakeup-source; + + connector { + compatible = "usb-c-connector"; + label = "USB-C"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&usb_hs>; + }; + }; + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&usb_ss>; + }; + }; + }; + }; + }; + }; +... -- cgit From 334daddbe6553b7cd73027154282242225ff984d Mon Sep 17 00:00:00 2001 From: Souradeep Chowdhury Date: Tue, 8 Feb 2022 23:24:24 +0530 Subject: dt-bindings: Add the yaml bindings for EUD Documentation for Embedded USB Debugger(EUD) device tree bindings in yaml format. Reviewed-by: Bjorn Andersson Reviewed-by: Rob Herring Signed-off-by: Souradeep Chowdhury Link: https://lore.kernel.org/r/e6a490c5eab9750decd5204d284b9b163b9be187.1644339918.git.quic_schowdhu@quicinc.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/soc/qcom/qcom,eud.yaml | 77 ++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml new file mode 100644 index 000000000000..c98aab209bc5 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/qcom/qcom,eud.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Embedded USB Debugger + +maintainers: + - Souradeep Chowdhury + +description: + This binding is used to describe the Qualcomm Embedded USB Debugger, which is + mini USB-hub implemented on chip to support USB-based debug capabilities. + +properties: + compatible: + items: + - enum: + - qcom,sc7280-eud + - const: qcom,eud + + reg: + items: + - description: EUD Base Register Region + - description: EUD Mode Manager Register + + interrupts: + description: EUD interrupt + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: + These ports is to be attached to the endpoint of the DWC3 controller node + and type C connector node. The controller has the "usb-role-switch" + property. + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: This port is to be attached to the DWC3 controller. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: This port is to be attached to the type C connector. + +required: + - compatible + - reg + - ports + +additionalProperties: false + +examples: + - | + eud@88e0000 { + compatible = "qcom,sc7280-eud","qcom,eud"; + reg = <0x88e0000 0x2000>, + <0x88e2000 0x1000>; + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + eud_ep: endpoint { + remote-endpoint = <&usb2_role_switch>; + }; + }; + port@1 { + reg = <1>; + eud_con: endpoint { + remote-endpoint = <&con_eud>; + }; + }; + }; + }; -- cgit From 306a20df822d5a6522aa4aa2029a858ed5fbd517 Mon Sep 17 00:00:00 2001 From: Souradeep Chowdhury Date: Tue, 8 Feb 2022 23:24:25 +0530 Subject: bindings: usb: dwc3: Update dwc3 properties for EUD connector Add the ports property for dwc3 node. This port can be used by the Embedded USB Debugger for role switching the controller from device to host mode and vice versa. Reviewed-by: Rob Herring Signed-off-by: Souradeep Chowdhury Link: https://lore.kernel.org/r/7308170ce13a96c2ff9cbb22316f46c814c42ef1.1644339918.git.quic_schowdhu@quicinc.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 4f2b0913ad9f..f4471f8bdbef 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -335,6 +335,12 @@ properties: items: enum: [1, 4, 8, 16, 32, 64, 128, 256] + port: + $ref: /schemas/graph.yaml#/properties/port + description: + This port is used with the 'usb-role-switch' property to connect the + dwc3 to type C connector. + unevaluatedProperties: false required: -- cgit From 9a1bf58ccd4432688cee28a8e77726d7962fed13 Mon Sep 17 00:00:00 2001 From: Souradeep Chowdhury Date: Tue, 8 Feb 2022 23:24:26 +0530 Subject: usb: misc: eud: Add driver support for Embedded USB Debugger(EUD) Add support for control peripheral of EUD (Embedded USB Debugger) to listen to events such as USB attach/detach, pet EUD to indicate software is functional.Reusing the platform device kobj, sysfs entry 'enable' is created to enable or disable EUD. To enable the eud the following needs to be done echo 1 > /sys/bus/platform/.../enable To disable eud, following is the command echo 0 > /sys/bus/platform/.../enable Signed-off-by: Souradeep Chowdhury Link: https://lore.kernel.org/r/0ac5c2b2c8e4ce4f4f342a08b48cfc61aeaf7ee8.1644339918.git.quic_schowdhu@quicinc.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-driver-eud | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-eud (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-eud b/Documentation/ABI/testing/sysfs-driver-eud new file mode 100644 index 000000000000..83f3872182a4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-eud @@ -0,0 +1,9 @@ +What: /sys/bus/platform/drivers/eud/.../enable +Date: February 2022 +Contact: Souradeep Chowdhury +Description: + The Enable/Disable sysfs interface for Embedded + USB Debugger(EUD). This enables and disables the + EUD based on a 1 or a 0 value. By enabling EUD, + the user is able to activate the mini-usb hub of + EUD for debug and trace capabilities. -- cgit From e67b9bc4d926de9d2e09e10325e64de69501531d Mon Sep 17 00:00:00 2001 From: Abel Vesa Date: Thu, 10 Feb 2022 22:14:06 +0200 Subject: dt-bindings: serial: fsl-lpuart: Drop i.MX8QXP backwards compatibility Drop the i.MX8QXP backwards compatibility with i.MX7ULP since they differ from clocks handling point of view. Acked-by: Rob Herring Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20220210201407.567860-1-abel.vesa@nxp.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml index c33e3af1b5ea..40dd25b72268 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml @@ -21,11 +21,10 @@ properties: - fsl,ls1028a-lpuart - fsl,imx7ulp-lpuart - fsl,imx8qm-lpuart + - fsl,imx8qxp-lpuart - fsl,imxrt1050-lpuart - items: - - enum: - - fsl,imx8qxp-lpuart - - fsl,imx8ulp-lpuart + - const: fsl,imx8ulp-lpuart - const: fsl,imx7ulp-lpuart - items: - enum: -- cgit From ad30d108a5135af584ff47f5ff81be971b6c26f1 Mon Sep 17 00:00:00 2001 From: Abel Vesa Date: Thu, 10 Feb 2022 22:14:07 +0200 Subject: dt-bindings: serial: fsl-lpuart: Remove i.MX8QM from enum i.MX8QM lpuart is backwards compatible with i.MX8QXP, so lets remove the single match from enum. This will force nodes to have both compatible strings, since there is already an 'items' entry for that. Reviewed-by: Peng Fan Acked-by: Rob Herring Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20220210201407.567860-2-abel.vesa@nxp.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml index 40dd25b72268..ff364bd0fbac 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml @@ -20,7 +20,6 @@ properties: - fsl,ls1021a-lpuart - fsl,ls1028a-lpuart - fsl,imx7ulp-lpuart - - fsl,imx8qm-lpuart - fsl,imx8qxp-lpuart - fsl,imxrt1050-lpuart - items: -- cgit From 429c83c78ab213d9656721cf46ae05366098485c Mon Sep 17 00:00:00 2001 From: Luiz Angelo Daros de Luca Date: Wed, 9 Feb 2022 15:41:16 -0300 Subject: dt-bindings: net: dsa: realtek: convert to YAML schema, add MDIO Schema changes: - support for mdio-connected switches (mdio driver), recognized by checking the presence of property "reg" - new compatible strings for rtl8367s and rtl8367rb - "interrupt-controller" was not added as a required property. It might still work polling the ports when missing. Examples changes: - renamed "switch_intc" to make it unique between examples - removed "dsa-mdio" from mdio compatible property - renamed phy@0 to ethernet-phy@0 (not tested with real HW) phy@ requires #phy-cells Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Linus Walleij Signed-off-by: David S. Miller --- .../devicetree/bindings/net/dsa/realtek-smi.txt | 240 ------------- .../devicetree/bindings/net/dsa/realtek.yaml | 394 +++++++++++++++++++++ 2 files changed, 394 insertions(+), 240 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/dsa/realtek-smi.txt create mode 100644 Documentation/devicetree/bindings/net/dsa/realtek.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt b/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt deleted file mode 100644 index 7959ec237983..000000000000 --- a/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt +++ /dev/null @@ -1,240 +0,0 @@ -Realtek SMI-based Switches -========================== - -The SMI "Simple Management Interface" is a two-wire protocol using -bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does -not use the MDIO protocol. This binding defines how to specify the -SMI-based Realtek devices. - -Required properties: - -- compatible: must be exactly one of: - "realtek,rtl8365mb" (4+1 ports) - "realtek,rtl8366" - "realtek,rtl8366rb" (4+1 ports) - "realtek,rtl8366s" (4+1 ports) - "realtek,rtl8367" - "realtek,rtl8367b" - "realtek,rtl8368s" (8 port) - "realtek,rtl8369" - "realtek,rtl8370" (8 port) - -Required properties: -- mdc-gpios: GPIO line for the MDC clock line. -- mdio-gpios: GPIO line for the MDIO data line. -- reset-gpios: GPIO line for the reset signal. - -Optional properties: -- realtek,disable-leds: if the LED drivers are not used in the - hardware design this will disable them so they are not turned on - and wasting power. - -Required subnodes: - -- interrupt-controller - - This defines an interrupt controller with an IRQ line (typically - a GPIO) that will demultiplex and handle the interrupt from the single - interrupt line coming out of one of the SMI-based chips. It most - importantly provides link up/down interrupts to the PHY blocks inside - the ASIC. - -Required properties of interrupt-controller: - -- interrupt: parent interrupt, see interrupt-controller/interrupts.txt -- interrupt-controller: see interrupt-controller/interrupts.txt -- #address-cells: should be <0> -- #interrupt-cells: should be <1> - -- mdio - - This defines the internal MDIO bus of the SMI device, mostly for the - purpose of being able to hook the interrupts to the right PHY and - the right PHY to the corresponding port. - -Required properties of mdio: - -- compatible: should be set to "realtek,smi-mdio" for all SMI devices - -See net/mdio.txt for additional MDIO bus properties. - -See net/dsa/dsa.txt for a list of additional required and optional properties -and subnodes of DSA switches. - -Examples: - -An example for the RTL8366RB: - -switch { - compatible = "realtek,rtl8366rb"; - /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */ - mdc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>; - mdio-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>; - - switch_intc: interrupt-controller { - /* GPIO 15 provides the interrupt */ - interrupt-parent = <&gpio0>; - interrupts = <15 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #address-cells = <0>; - #interrupt-cells = <1>; - }; - - ports { - #address-cells = <1>; - #size-cells = <0>; - reg = <0>; - port@0 { - reg = <0>; - label = "lan0"; - phy-handle = <&phy0>; - }; - port@1 { - reg = <1>; - label = "lan1"; - phy-handle = <&phy1>; - }; - port@2 { - reg = <2>; - label = "lan2"; - phy-handle = <&phy2>; - }; - port@3 { - reg = <3>; - label = "lan3"; - phy-handle = <&phy3>; - }; - port@4 { - reg = <4>; - label = "wan"; - phy-handle = <&phy4>; - }; - port@5 { - reg = <5>; - label = "cpu"; - ethernet = <&gmac0>; - phy-mode = "rgmii"; - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - }; - - mdio { - compatible = "realtek,smi-mdio", "dsa-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - phy0: phy@0 { - reg = <0>; - interrupt-parent = <&switch_intc>; - interrupts = <0>; - }; - phy1: phy@1 { - reg = <1>; - interrupt-parent = <&switch_intc>; - interrupts = <1>; - }; - phy2: phy@2 { - reg = <2>; - interrupt-parent = <&switch_intc>; - interrupts = <2>; - }; - phy3: phy@3 { - reg = <3>; - interrupt-parent = <&switch_intc>; - interrupts = <3>; - }; - phy4: phy@4 { - reg = <4>; - interrupt-parent = <&switch_intc>; - interrupts = <12>; - }; - }; -}; - -An example for the RTL8365MB-VC: - -switch { - compatible = "realtek,rtl8365mb"; - mdc-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>; - mdio-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>; - - switch_intc: interrupt-controller { - interrupt-parent = <&gpio5>; - interrupts = <1 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #address-cells = <0>; - #interrupt-cells = <1>; - }; - - ports { - #address-cells = <1>; - #size-cells = <0>; - reg = <0>; - port@0 { - reg = <0>; - label = "swp0"; - phy-handle = <ðphy0>; - }; - port@1 { - reg = <1>; - label = "swp1"; - phy-handle = <ðphy1>; - }; - port@2 { - reg = <2>; - label = "swp2"; - phy-handle = <ðphy2>; - }; - port@3 { - reg = <3>; - label = "swp3"; - phy-handle = <ðphy3>; - }; - port@6 { - reg = <6>; - label = "cpu"; - ethernet = <&fec1>; - phy-mode = "rgmii"; - tx-internal-delay-ps = <2000>; - rx-internal-delay-ps = <2000>; - - fixed-link { - speed = <1000>; - full-duplex; - pause; - }; - }; - }; - - mdio { - compatible = "realtek,smi-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - ethphy0: phy@0 { - reg = <0>; - interrupt-parent = <&switch_intc>; - interrupts = <0>; - }; - ethphy1: phy@1 { - reg = <1>; - interrupt-parent = <&switch_intc>; - interrupts = <1>; - }; - ethphy2: phy@2 { - reg = <2>; - interrupt-parent = <&switch_intc>; - interrupts = <2>; - }; - ethphy3: phy@3 { - reg = <3>; - interrupt-parent = <&switch_intc>; - interrupts = <3>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/net/dsa/realtek.yaml b/Documentation/devicetree/bindings/net/dsa/realtek.yaml new file mode 100644 index 000000000000..8756060895a8 --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/realtek.yaml @@ -0,0 +1,394 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/realtek.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek switches for unmanaged switches + +allOf: + - $ref: dsa.yaml# + +maintainers: + - Linus Walleij + +description: + Realtek advertises these chips as fast/gigabit switches or unmanaged + switches. They can be controlled using different interfaces, like SMI, + MDIO or SPI. + + The SMI "Simple Management Interface" is a two-wire protocol using + bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does + not use the MDIO protocol. This binding defines how to specify the + SMI-based Realtek devices. The realtek-smi driver is a platform driver + and it must be inserted inside a platform node. + + The MDIO-connected switches use MDIO protocol to access their registers. + The realtek-mdio driver is an MDIO driver and it must be inserted inside + an MDIO node. + +properties: + compatible: + enum: + - realtek,rtl8365mb + - realtek,rtl8366 + - realtek,rtl8366rb + - realtek,rtl8366s + - realtek,rtl8367 + - realtek,rtl8367b + - realtek,rtl8367rb + - realtek,rtl8367s + - realtek,rtl8368s + - realtek,rtl8369 + - realtek,rtl8370 + description: | + realtek,rtl8365mb: 4+1 ports + realtek,rtl8366: 5+1 ports + realtek,rtl8366rb: 5+1 ports + realtek,rtl8366s: 5+1 ports + realtek,rtl8367: + realtek,rtl8367b: + realtek,rtl8367rb: 5+2 ports + realtek,rtl8367s: 5+2 ports + realtek,rtl8368s: 8 ports + realtek,rtl8369: 8+1 ports + realtek,rtl8370: 8+2 ports + + mdc-gpios: + description: GPIO line for the MDC clock line. + maxItems: 1 + + mdio-gpios: + description: GPIO line for the MDIO data line. + maxItems: 1 + + reset-gpios: + description: GPIO to be used to reset the whole device + maxItems: 1 + + realtek,disable-leds: + type: boolean + description: | + if the LED drivers are not used in the hardware design, + this will disable them so they are not turned on + and wasting power. + + interrupt-controller: + type: object + description: | + This defines an interrupt controller with an IRQ line (typically + a GPIO) that will demultiplex and handle the interrupt from the single + interrupt line coming out of one of the Realtek switch chips. It most + importantly provides link up/down interrupts to the PHY blocks inside + the ASIC. + + properties: + + interrupt-controller: true + + interrupts: + maxItems: 1 + description: + A single IRQ line from the switch, either active LOW or HIGH + + '#address-cells': + const: 0 + + '#interrupt-cells': + const: 1 + + required: + - interrupt-controller + - '#address-cells' + - '#interrupt-cells' + + mdio: + $ref: /schemas/net/mdio.yaml# + unevaluatedProperties: false + + properties: + compatible: + const: realtek,smi-mdio + +if: + required: + - reg + +then: + not: + required: + - mdc-gpios + - mdio-gpios + - mdio + + properties: + mdc-gpios: false + mdio-gpios: false + mdio: false + +else: + required: + - mdc-gpios + - mdio-gpios + - mdio + - reset-gpios + +required: + - compatible + + # - mdc-gpios + # - mdio-gpios + # - reset-gpios + # - mdio + +unevaluatedProperties: false + +examples: + - | + #include + #include + + platform { + switch { + compatible = "realtek,rtl8366rb"; + /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */ + mdc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>; + mdio-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>; + + switch_intc1: interrupt-controller { + /* GPIO 15 provides the interrupt */ + interrupt-parent = <&gpio0>; + interrupts = <15 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + label = "lan0"; + phy-handle = <&phy0>; + }; + port@1 { + reg = <1>; + label = "lan1"; + phy-handle = <&phy1>; + }; + port@2 { + reg = <2>; + label = "lan2"; + phy-handle = <&phy2>; + }; + port@3 { + reg = <3>; + label = "lan3"; + phy-handle = <&phy3>; + }; + port@4 { + reg = <4>; + label = "wan"; + phy-handle = <&phy4>; + }; + port@5 { + reg = <5>; + label = "cpu"; + ethernet = <&gmac0>; + phy-mode = "rgmii"; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + + mdio { + compatible = "realtek,smi-mdio"; + #address-cells = <1>; + #size-cells = <0>; + + phy0: ethernet-phy@0 { + reg = <0>; + interrupt-parent = <&switch_intc1>; + interrupts = <0>; + }; + phy1: ethernet-phy@1 { + reg = <1>; + interrupt-parent = <&switch_intc1>; + interrupts = <1>; + }; + phy2: ethernet-phy@2 { + reg = <2>; + interrupt-parent = <&switch_intc1>; + interrupts = <2>; + }; + phy3: ethernet-phy@3 { + reg = <3>; + interrupt-parent = <&switch_intc1>; + interrupts = <3>; + }; + phy4: ethernet-phy@4 { + reg = <4>; + interrupt-parent = <&switch_intc1>; + interrupts = <12>; + }; + }; + }; + }; + + - | + #include + #include + + platform { + switch { + compatible = "realtek,rtl8365mb"; + mdc-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>; + mdio-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>; + + switch_intc2: interrupt-controller { + interrupt-parent = <&gpio5>; + interrupts = <1 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + label = "swp0"; + phy-handle = <ðphy0>; + }; + port@1 { + reg = <1>; + label = "swp1"; + phy-handle = <ðphy1>; + }; + port@2 { + reg = <2>; + label = "swp2"; + phy-handle = <ðphy2>; + }; + port@3 { + reg = <3>; + label = "swp3"; + phy-handle = <ðphy3>; + }; + port@6 { + reg = <6>; + label = "cpu"; + ethernet = <&fec1>; + phy-mode = "rgmii"; + tx-internal-delay-ps = <2000>; + rx-internal-delay-ps = <2000>; + + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + }; + + mdio { + compatible = "realtek,smi-mdio"; + #address-cells = <1>; + #size-cells = <0>; + + ethphy0: ethernet-phy@0 { + reg = <0>; + interrupt-parent = <&switch_intc2>; + interrupts = <0>; + }; + ethphy1: ethernet-phy@1 { + reg = <1>; + interrupt-parent = <&switch_intc2>; + interrupts = <1>; + }; + ethphy2: ethernet-phy@2 { + reg = <2>; + interrupt-parent = <&switch_intc2>; + interrupts = <2>; + }; + ethphy3: ethernet-phy@3 { + reg = <3>; + interrupt-parent = <&switch_intc2>; + interrupts = <3>; + }; + }; + }; + }; + + - | + #include + #include + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + switch@29 { + compatible = "realtek,rtl8367s"; + reg = <29>; + + reset-gpios = <&gpio2 20 GPIO_ACTIVE_LOW>; + + switch_intc3: interrupt-controller { + interrupt-parent = <&gpio0>; + interrupts = <11 IRQ_TYPE_EDGE_FALLING>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + label = "lan4"; + }; + + port@1 { + reg = <1>; + label = "lan3"; + }; + + port@2 { + reg = <2>; + label = "lan2"; + }; + + port@3 { + reg = <3>; + label = "lan1"; + }; + + port@4 { + reg = <4>; + label = "wan"; + }; + + port@7 { + reg = <7>; + ethernet = <ðernet>; + phy-mode = "rgmii"; + tx-internal-delay-ps = <2000>; + rx-internal-delay-ps = <0>; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + }; + }; -- cgit From 066c4b6ba06392e5929ea2ebd17622090b500b58 Mon Sep 17 00:00:00 2001 From: Marek Behún Date: Thu, 10 Feb 2022 18:48:22 +0100 Subject: dt-bindings: phy: Add `tx-p2p-microvolt` property binding MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Common PHYs and network PCSes often have the possibility to specify peak-to-peak voltage on the differential pair - the default voltage sometimes needs to be changed for a particular board. Add properties `tx-p2p-microvolt` and `tx-p2p-microvolt-names` for this purpose. The second property is needed to specify the mode for the corresponding voltage in the `tx-p2p-microvolt` property, if the voltage is to be used only for speficic mode. More voltage-mode pairs can be specified. Example usage with only one voltage (it will be used for all supported PHY modes, the `tx-p2p-microvolt-names` property is not needed in this case): tx-p2p-microvolt = <915000>; Example usage with voltages for multiple modes: tx-p2p-microvolt = <915000>, <1100000>, <1200000>; tx-p2p-microvolt-names = "2500base-x", "usb", "pcie"; Add these properties into a separate file phy/transmit-amplitude.yaml, which should be referenced by any binding that uses it. Signed-off-by: Marek Behún Reviewed-by: Rob Herring Signed-off-by: David S. Miller --- .../bindings/phy/transmit-amplitude.yaml | 103 +++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/transmit-amplitude.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/transmit-amplitude.yaml b/Documentation/devicetree/bindings/phy/transmit-amplitude.yaml new file mode 100644 index 000000000000..51492fe738ec --- /dev/null +++ b/Documentation/devicetree/bindings/phy/transmit-amplitude.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/transmit-amplitude.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common PHY and network PCS transmit amplitude property binding + +description: + Binding describing the peak-to-peak transmit amplitude for common PHYs + and network PCSes. + +maintainers: + - Marek Behún + +properties: + tx-p2p-microvolt: + description: + Transmit amplitude voltages in microvolts, peak-to-peak. If this property + contains multiple values for various PHY modes, the + 'tx-p2p-microvolt-names' property must be provided and contain + corresponding mode names. + + tx-p2p-microvolt-names: + description: | + Names of the modes corresponding to voltages in the 'tx-p2p-microvolt' + property. Required only if multiple voltages are provided. + + If a value of 'default' is provided, the system should use it for any PHY + mode that is otherwise not defined here. If 'default' is not provided, the + system should use manufacturer default value. + minItems: 1 + maxItems: 16 + items: + enum: + - default + + # ethernet modes + - sgmii + - qsgmii + - xgmii + - 1000base-x + - 2500base-x + - 5gbase-r + - rxaui + - xaui + - 10gbase-kr + - usxgmii + - 10gbase-r + - 25gbase-r + + # PCIe modes + - pcie + - pcie1 + - pcie2 + - pcie3 + - pcie4 + - pcie5 + - pcie6 + + # USB modes + - usb + - usb-ls + - usb-fs + - usb-hs + - usb-ss + - usb-ss+ + - usb-4 + + # storage modes + - sata + - ufs-hs + - ufs-hs-a + - ufs-hs-b + + # display modes + - lvds + - dp + - dp-rbr + - dp-hbr + - dp-hbr2 + - dp-hbr3 + - dp-uhbr-10 + - dp-uhbr-13.5 + - dp-uhbr-20 + + # camera modes + - mipi-dphy + - mipi-dphy-univ + - mipi-dphy-v2.5-univ + +dependencies: + tx-p2p-microvolt-names: [ tx-p2p-microvolt ] + +additionalProperties: true + +examples: + - | + phy: phy { + #phy-cells = <1>; + tx-p2p-microvolt = <915000>, <1100000>, <1200000>; + tx-p2p-microvolt-names = "2500base-x", "usb-hs", "usb-ss"; + }; -- cgit From 6ba8986b35ed2cafb573ad19c74e838d8b21cbab Mon Sep 17 00:00:00 2001 From: Marcel Ziswiler Date: Fri, 11 Feb 2022 10:23:21 +0100 Subject: dt-bindings: arm: fsl: add toradex,verdin-imx8mm et al. Add toradex,verdin-imx8mm for our new Verdin iMX8M Mini modules, its nonwifi and wifi variants and the carrier boards (both Dahlia and the Verdin Development Board) they may be mated in. Signed-off-by: Marcel Ziswiler Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index e58e21efdf0b..23e678232451 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -771,6 +771,9 @@ properties: - gw,imx8mm-gw7901 # i.MX8MM Gateworks Board - gw,imx8mm-gw7902 # i.MX8MM Gateworks Board - kontron,imx8mm-n801x-som # i.MX8MM Kontron SL (N801X) SOM + - toradex,verdin-imx8mm # Verdin iMX8M Mini Modules + - toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Modules without Wi-Fi / BT + - toradex,verdin-imx8mm-wifi # Verdin iMX8M Mini Wi-Fi / BT Modules - variscite,var-som-mx8mm # i.MX8MM Variscite VAR-SOM-MX8MM module - prt,prt8mm # i.MX8MM Protonic PRT8MM Board - const: fsl,imx8mm @@ -789,6 +792,24 @@ properties: - const: kontron,imx8mm-n801x-som - const: fsl,imx8mm + - description: Toradex Boards with Verdin iMX8M Mini Modules + items: + - enum: + - toradex,verdin-imx8mm-nonwifi-dahlia # Verdin iMX8M Mini Module on Dahlia + - toradex,verdin-imx8mm-nonwifi-dev # Verdin iMX8M Mini Module on Verdin Development Board + - const: toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Module without Wi-Fi / BT + - const: toradex,verdin-imx8mm # Verdin iMX8M Mini Module + - const: fsl,imx8mm + + - description: Toradex Boards with Verdin iMX8M Mini Wi-Fi / BT Modules + items: + - enum: + - toradex,verdin-imx8mm-wifi-dahlia # Verdin iMX8M Mini Wi-Fi / BT Module on Dahlia + - toradex,verdin-imx8mm-wifi-dev # Verdin iMX8M Mini Wi-Fi / BT M. on Verdin Development B. + - const: toradex,verdin-imx8mm-wifi # Verdin iMX8M Mini Wi-Fi / BT Module + - const: toradex,verdin-imx8mm # Verdin iMX8M Mini Module + - const: fsl,imx8mm + - description: Variscite VAR-SOM-MX8MM based boards items: - const: variscite,var-som-mx8mm-symphony -- cgit From 269923def7ab613f37269439ede7d4cbf9375058 Mon Sep 17 00:00:00 2001 From: Romain Perier Date: Thu, 23 Sep 2021 19:07:46 +0200 Subject: dt-bindings: add vendor prefix for Wireless Tag This adds a vendor prefix for wireless tag boards and SOMs. Signed-off-by: Romain Perier Acked-by: Rob Herring Signed-off-by: Daniel Palmer --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 294093d45a23..d9c0647e9d56 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1348,6 +1348,8 @@ patternProperties: description: WinLink Co., Ltd "^winstar,.*": description: Winstar Display Corp. + "^wirelesstag,.*": + description: Wireless Tag (qiming yunduan) "^wits,.*": description: Shenzhen Merrii Technology Co., Ltd. (WITS) "^wlf,.*": -- cgit From 42bd9c510b9ae91ba332b27cdc1edcfa78a64320 Mon Sep 17 00:00:00 2001 From: Romain Perier Date: Thu, 23 Sep 2021 19:07:47 +0200 Subject: ARM: dts: mstar: Add the Wireless Tag IDO-SBC2D06-V1B-22W The Wireless Tag IDO-SBC2D06-V1B-22W[1] is an SBC powered by SSD202D with a dual Ethernet and a connector for a 4-inch and 7-inch display. It embeds a System-On-Module IDO-SOM2D01[2] with an Mstar SSD202 SoC dual-core Cortex-A7 CPU @ 1.2Ghz , 2D GPU, 128 MB DDR3 (on-chip) and a 256MB SPI NAND flash. This commit adds basic definition for this board. 1. http://linux-chenxing.org/infinity2/ido-sbc2d06 2. http://www.wireless-tag.com/portfolio/ido-som2d01 Signed-off-by: Romain Perier Reviewed-by: Rob Herring Signed-off-by: Daniel Palmer --- Documentation/devicetree/bindings/arm/mstar/mstar.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml index a316eef1b728..10efd703717e 100644 --- a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml +++ b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml @@ -25,6 +25,8 @@ properties: - enum: - honestar,ssd201htv2 # Honestar SSD201_HT_V2 devkit - m5stack,unitv2 # M5Stack UnitV2 + - wirelesstag,ido-som2d01 # Wireless Tag IDO-SOM2D01 + - wirelesstag,ido-sbc2d06-v1b-22w # Wireless Tag IDO-SBC2D06-1VB-22W - const: mstar,infinity2m - description: infinity3 boards -- cgit From 365e7ecaaf8ed554729c9fc26e9734d027807f02 Mon Sep 17 00:00:00 2001 From: Daniel Palmer Date: Mon, 13 Dec 2021 18:54:03 +0900 Subject: dt-bindings: vendor-prefixes: Add prefix for Miyoo Add a prefix for "miyoo". The only details I can find about the company is their aliexpress store "miyoo global store": https://www.aliexpress.com/store/912663639 Signed-off-by: Daniel Palmer Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index d9c0647e9d56..b745cf748ff8 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -769,6 +769,8 @@ patternProperties: description: MiraMEMS Sensing Technology Co., Ltd. "^mitsubishi,.*": description: Mitsubishi Electric Corporation + "^miyoo,.*": + description: Miyoo "^mntre,.*": description: MNT Research GmbH "^modtronix,.*": -- cgit From 2c63dddadf381cfee8cc7a3b14eff7f289db944c Mon Sep 17 00:00:00 2001 From: Daniel Palmer Date: Mon, 13 Dec 2021 18:54:10 +0900 Subject: dt-bindings: arm: mstar: Add compatible for Miyoo Mini The Miyoo Mini is a SigmaStar SSD202D based retro emulation device. Add a compatible for it to the list of infinity2m devices. Link: http://linux-chenxing.org/infinity2/miyoomini/ Signed-off-by: Daniel Palmer Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/mstar/mstar.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml index 10efd703717e..4365efd9c36b 100644 --- a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml +++ b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml @@ -25,6 +25,7 @@ properties: - enum: - honestar,ssd201htv2 # Honestar SSD201_HT_V2 devkit - m5stack,unitv2 # M5Stack UnitV2 + - miyoo,miyoo-mini # Miyoo Mini - wirelesstag,ido-som2d01 # Wireless Tag IDO-SOM2D01 - wirelesstag,ido-sbc2d06-v1b-22w # Wireless Tag IDO-SBC2D06-1VB-22W - const: mstar,infinity2m -- cgit From 1eef31660001a996114b26cd2fc05551d77bd02e Mon Sep 17 00:00:00 2001 From: Daniel Palmer Date: Thu, 9 Dec 2021 19:39:07 +0900 Subject: dt-bindings: vendor-prefixes: Add prefix for 100ask 100ask is Linux SBC/module/training provider. Add a prefix for them. Link: https://www.100ask.net Signed-off-by: Daniel Palmer Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b745cf748ff8..44483d0de9c4 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -23,6 +23,8 @@ patternProperties: "^(simple-audio-card|st-plgpio|st-spics|ts),.*": true # Keep list in alphabetical order. + "^100ask,.*": + description: Baiwen.com (100ask). "^70mai,.*": description: 70mai Co., Ltd. "^8dev,.*": -- cgit From 79f1e65a94d77088efbbc78872564ed027c232e7 Mon Sep 17 00:00:00 2001 From: Daniel Palmer Date: Thu, 9 Dec 2021 19:44:31 +0900 Subject: dt-bindings: arm: mstar: Add compatible for 100ask DongShanPiOne The DongShanPiOne is a SigmaStar SSD202D based module. Add a compatible for it to the list of infinity2m boards. Link: http://linux-chenxing.org/infinity2/dongshanpione/ Signed-off-by: Daniel Palmer Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/mstar/mstar.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml index 4365efd9c36b..8892eb6bd3ef 100644 --- a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml +++ b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml @@ -23,6 +23,7 @@ properties: - description: infinity2m boards items: - enum: + - 100ask,dongshanpione # 100ask DongShanPiOne - honestar,ssd201htv2 # Honestar SSD201_HT_V2 devkit - m5stack,unitv2 # M5Stack UnitV2 - miyoo,miyoo-mini # Miyoo Mini -- cgit From f28b24042b525c9dd3d102d3152c0eb65e90b974 Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Thu, 10 Feb 2022 17:09:54 +0900 Subject: dt-bindings: PCI: uniphier-ep: Add bindings for NX1 SoC Update PCI endpoint binding document for UniPhier NX1 SoC. Add a compatible string, clock and reset lines for the SoC to the document. Link: https://lore.kernel.org/r/1644480596-20037-2-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Kunihiko Hayashi Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring --- .../bindings/pci/socionext,uniphier-pcie-ep.yaml | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml index 179ab0858482..437e61618d06 100644 --- a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml @@ -20,7 +20,9 @@ allOf: properties: compatible: - const: socionext,uniphier-pro5-pcie-ep + enum: + - socionext,uniphier-pro5-pcie-ep + - socionext,uniphier-nx1-pcie-ep reg: minItems: 4 @@ -41,20 +43,26 @@ properties: - const: atu clocks: + minItems: 1 maxItems: 2 clock-names: - items: - - const: gio - - const: link + oneOf: + - items: # for Pro5 + - const: gio + - const: link + - const: link # for NX1 resets: + minItems: 1 maxItems: 2 reset-names: - items: - - const: gio - - const: link + oneOf: + - items: # for Pro5 + - const: gio + - const: link + - const: link # for NX1 num-ib-windows: const: 16 -- cgit From e044e3e696b1c6b3bbb1ea536c590af169d3267b Mon Sep 17 00:00:00 2001 From: David Heidelberg Date: Mon, 7 Feb 2022 23:39:11 +0100 Subject: dt-bindings: display: bridge: document Toshiba TC358768 cells and panel node Inherit valid properties from the dsi-controller. Reviewed-by: Dmitry Osipenko Signed-off-by: David Heidelberg Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220207223911.97180-1-david@ixit.cz --- .../devicetree/bindings/display/bridge/toshiba,tc358768.yaml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml index eacfe7165083..3bd670b8e5cd 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml @@ -77,7 +77,10 @@ required: - vddio-supply - ports -additionalProperties: false +allOf: + - $ref: ../dsi-controller.yaml# + +unevaluatedProperties: false examples: - | @@ -87,7 +90,7 @@ examples: #address-cells = <1>; #size-cells = <0>; - dsi_bridge: dsi-bridge@e { + dsi_bridge: dsi@e { compatible = "toshiba,tc358768"; reg = <0xe>; -- cgit From c2687295df00ec7baf6a8c59b340264474e98183 Mon Sep 17 00:00:00 2001 From: Zenghui Yu Date: Tue, 8 Feb 2022 15:03:00 +0800 Subject: dt-bindings: arm: Trivial typo fixes in cpu-capacity.txt Correct the spelling of 'cluster1@max-freq' and fix the wrong capacity-dmips-mhz value 576 (which should be 578 instead). Signed-off-by: Zenghui Yu Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220208070300.1610-1-yuzenghui@huawei.com --- Documentation/devicetree/bindings/arm/cpu-capacity.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/cpu-capacity.txt b/Documentation/devicetree/bindings/arm/cpu-capacity.txt index 380e21c5fc7e..cc5e190390b7 100644 --- a/Documentation/devicetree/bindings/arm/cpu-capacity.txt +++ b/Documentation/devicetree/bindings/arm/cpu-capacity.txt @@ -62,8 +62,8 @@ Example 1 (ARM 64-bit, 6-cpu system, two clusters): The capacities-dmips-mhz or DMIPS/MHz values (scaled to 1024) are 1024 and 578 for cluster0 and cluster1. Further normalization is done by the operating system based on cluster0@max-freq=1100 and -custer1@max-freq=850, final capacities are 1024 for cluster0 and -446 for cluster1 (576*850/1100). +cluster1@max-freq=850, final capacities are 1024 for cluster0 and +446 for cluster1 (578*850/1100). cpus { #address-cells = <2>; -- cgit From bd79e84c6500db6ce069472e51c979764d88a024 Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Wed, 9 Feb 2022 09:28:20 +0100 Subject: dt-bindings: net: ethernet-controller: document label property "label" provides human readable name used on a box, board or schematic to identify Ethernet port. Signed-off-by: Oleksij Rempel Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220209082820.2210753-1-o.rempel@pengutronix.de --- Documentation/devicetree/bindings/net/ethernet-controller.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index 34c5463abcec..817794e56227 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -13,6 +13,10 @@ properties: $nodename: pattern: "^ethernet(@.*)?$" + label: + $ref: /schemas/types.yaml#/definitions/string + description: Human readable label on a port of a box. + local-mac-address: description: Specifies the MAC address that was assigned to the network device. -- cgit From 49364138080efb54434de086aef49353068285ef Mon Sep 17 00:00:00 2001 From: Fabrice Gasnier Date: Wed, 9 Feb 2022 14:52:27 +0100 Subject: dt-bindings: timer: armv7m-systick: convert to dtschema Convert the ARMv7-M system timer bindings to DT schema format. Signed-off-by: Fabrice Gasnier Cc: Alexandre Torgue Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/1644414747-22159-1-git-send-email-fabrice.gasnier@foss.st.com --- .../bindings/timer/arm,armv7m-systick.txt | 26 ----------- .../bindings/timer/arm,armv7m-systick.yaml | 54 ++++++++++++++++++++++ 2 files changed, 54 insertions(+), 26 deletions(-) delete mode 100644 Documentation/devicetree/bindings/timer/arm,armv7m-systick.txt create mode 100644 Documentation/devicetree/bindings/timer/arm,armv7m-systick.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/arm,armv7m-systick.txt b/Documentation/devicetree/bindings/timer/arm,armv7m-systick.txt deleted file mode 100644 index 7cf4a24601eb..000000000000 --- a/Documentation/devicetree/bindings/timer/arm,armv7m-systick.txt +++ /dev/null @@ -1,26 +0,0 @@ -* ARMv7M System Timer - -ARMv7-M includes a system timer, known as SysTick. Current driver only -implements the clocksource feature. - -Required properties: -- compatible : Should be "arm,armv7m-systick" -- reg : The address range of the timer - -Required clocking property, have to be one of: -- clocks : The input clock of the timer -- clock-frequency : The rate in HZ in input of the ARM SysTick - -Examples: - -systick: timer@e000e010 { - compatible = "arm,armv7m-systick"; - reg = <0xe000e010 0x10>; - clocks = <&clk_systick>; -}; - -systick: timer@e000e010 { - compatible = "arm,armv7m-systick"; - reg = <0xe000e010 0x10>; - clock-frequency = <90000000>; -}; diff --git a/Documentation/devicetree/bindings/timer/arm,armv7m-systick.yaml b/Documentation/devicetree/bindings/timer/arm,armv7m-systick.yaml new file mode 100644 index 000000000000..2bcade5d8ac6 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/arm,armv7m-systick.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/arm,armv7m-systick.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARMv7M System Timer + +maintainers: + - Alexandre Torgue + - Fabrice Gasnier + +description: ARMv7-M includes a system timer, known as SysTick. + +properties: + compatible: + const: arm,armv7m-systick + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-frequency: true + +oneOf: + - required: + - clocks + - required: + - clock-frequency + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + timer@e000e010 { + compatible = "arm,armv7m-systick"; + reg = <0xe000e010 0x10>; + clocks = <&clk_systick>; + }; + + - | + timer@e000e010 { + compatible = "arm,armv7m-systick"; + reg = <0xe000e010 0x10>; + clock-frequency = <90000000>; + }; + +... -- cgit From b36fc8181e3b31ba9e11c6a1938aa5bede10206f Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 3 Feb 2022 15:33:16 +0100 Subject: dt-bindings: i2c: renesas,rcar-i2c: Add r8a779f0 support Document support for the I2C Bus Interfaces in the Renesas R-Car S4-8 (R8A779F0) SoC, including a new family-specific compatible value for the R-Car Gen4 family. Signed-off-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Acked-by: Rob Herring Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml index 052aad44e781..c30107833a51 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml @@ -49,6 +49,11 @@ properties: - renesas,i2c-r8a779a0 # R-Car V3U - const: renesas,rcar-gen3-i2c # R-Car Gen3 and RZ/G2 + - items: + - enum: + - renesas,i2c-r8a779f0 # R-Car S4-8 + - const: renesas,rcar-gen4-i2c # R-Car Gen4 + reg: maxItems: 1 @@ -132,6 +137,7 @@ allOf: enum: - renesas,rcar-gen2-i2c - renesas,rcar-gen3-i2c + - renesas,rcar-gen4-i2c then: required: - resets -- cgit From f1bd6661946b20d1ea07de84a3c9a550e0367476 Mon Sep 17 00:00:00 2001 From: Conor Dooley Date: Mon, 7 Feb 2022 16:26:29 +0000 Subject: dt-bindings: i2c: add bindings for microchip mpfs i2c Add device tree bindings for the i2c controller on the Microchip PolarFire SoC. Signed-off-by: Daire McNamara Reviewed-by: Rob Herring Signed-off-by: Conor Dooley Acked-by: Palmer Dabbelt Signed-off-by: Wolfram Sang --- .../devicetree/bindings/i2c/microchip,corei2c.yaml | 56 ++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml b/Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml new file mode 100644 index 000000000000..c8e605fbb8a6 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/microchip,corei2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip MPFS I2C Controller Device Tree Bindings + +maintainers: + - Daire McNamara + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + oneOf: + - items: + - const: microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs + - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core + - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-frequency: + description: | + Desired I2C bus clock frequency in Hz. As only Standard and Fast + modes are supported, possible values are 100000 and 400000. + enum: [100000, 400000] + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + i2c@2010a000 { + compatible = "microchip,mpfs-i2c", "microchip,corei2c-rtl-v7"; + reg = <0x2010a000 0x1000>; + clocks = <&clkcfg 15>; + interrupt-parent = <&plic>; + interrupts = <58>; + clock-frequency = <100000>; + }; +... -- cgit From f1775c26e8b8809d922a29bb5e3df6ea503d2fa0 Mon Sep 17 00:00:00 2001 From: Alex Bee Date: Wed, 9 Feb 2022 22:55:45 +0100 Subject: dt-bindings: gpu: mali-bifrost: describe clocks for the rk356x gpu The Bifrost GPU in Rockchip RK356x SoCs has a core and a bus clock. Reflect this in the SoC specific part of the binding. Signed-off-by: Alex Bee [move the changes to the SoC section] Signed-off-by: Michael Riesch Reviewed-by: Rob Herring Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220209215549.94524-2-michael.riesch@wolfvision.net --- .../devicetree/bindings/gpu/arm,mali-bifrost.yaml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 63a08f3f321d..4d6bfae0653c 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -159,6 +159,21 @@ allOf: power-domains: maxItems: 1 sram-supply: false + - if: + properties: + compatible: + contains: + const: rockchip,rk3568-mali + then: + properties: + clocks: + minItems: 2 + clock-names: + items: + - const: gpu + - const: bus + required: + - clock-names examples: - | -- cgit From 2e2f0199a20780463945e1cbffb3a191fa84bd9d Mon Sep 17 00:00:00 2001 From: Barry Song <21cnbao@gmail.com> Date: Mon, 7 Feb 2022 15:49:31 +0800 Subject: docs: block: biodoc.rst: Drop the obsolete and incorrect content Since commit 7eaceaccab5f ("block: remove per-queue plugging"), kernel has removed blk_run_address_space(), blk_unplug() and sync_buffer(), and moved to on-stack plugging. The document has been obsolete for years. Given that there is no obvious counterparts in the new mechinism to replace old APIs, this patch drops the content directly. Signed-off-by: Barry Song Link: https://lore.kernel.org/r/20220207074931.20067-1-song.bao.hua@hisilicon.com Signed-off-by: Jens Axboe --- Documentation/block/biodoc.rst | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/biodoc.rst b/Documentation/block/biodoc.rst index 4fbc367e62f9..fdebc0fd8468 100644 --- a/Documentation/block/biodoc.rst +++ b/Documentation/block/biodoc.rst @@ -965,11 +965,7 @@ till it fills up with a few more requests, before starting to service the requests. This provides an opportunity to merge/sort the requests before passing them down to the device. There are various conditions when the queue is unplugged (to open up the flow again), either through a scheduled task or -could be on demand. For example wait_on_buffer sets the unplugging going -through sync_buffer() running blk_run_address_space(mapping). Or the caller -can do it explicity through blk_unplug(bdev). So in the read case, -the queue gets explicitly unplugged as part of waiting for completion on that -buffer. +could be on demand. Aside: This is kind of controversial territory, as it's not clear if plugging is -- cgit From e5eb80f0c076346d5e837dc09e3604f79a8c6814 Mon Sep 17 00:00:00 2001 From: Stefan Wahren Date: Tue, 1 Feb 2022 18:27:45 +0100 Subject: dt-bindings: arm: bcm2835: Add Raspberry Pi Zero 2 W Add the Raspberry Pi Zero 2 W to DT schema. Signed-off-by: Stefan Wahren Acked-by: Rob Herring Signed-off-by: Florian Fainelli --- Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml b/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml index 5dc48241efb3..8051a75c2c79 100644 --- a/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml @@ -51,6 +51,7 @@ properties: - raspberrypi,3-model-b-plus - raspberrypi,3-compute-module - raspberrypi,3-compute-module-lite + - raspberrypi,model-zero-2-w - const: brcm,bcm2837 additionalProperties: true -- cgit From 3624ba7b5e2acc02b01301ea5fd3534971eb9896 Mon Sep 17 00:00:00 2001 From: Huang Ying Date: Thu, 10 Feb 2022 13:25:14 +0800 Subject: sched/numa-balancing: Move some document to make it consistent with the code After commit 8a99b6833c88 ("sched: Move SCHED_DEBUG sysctl to debugfs"), some NUMA balancing sysctls enclosed with SCHED_DEBUG has been moved to debugfs. This patch move the document for these sysctls from Documentation/admin-guide/sysctl/kernel.rst to Documentation/scheduler/sched-debug.rst to make the document consistent with the code. Signed-off-by: "Huang, Ying" Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Acked-by: Mel Gorman Link: https://lkml.kernel.org/r/20220210052514.3038279-1-ying.huang@intel.com --- Documentation/admin-guide/sysctl/kernel.rst | 46 +----------------------- Documentation/scheduler/index.rst | 1 + Documentation/scheduler/sched-debug.rst | 54 +++++++++++++++++++++++++++++ 3 files changed, 56 insertions(+), 45 deletions(-) create mode 100644 Documentation/scheduler/sched-debug.rst (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index d359bcfadd39..8551aeca1574 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -609,51 +609,7 @@ be migrated to a local memory node. The unmapping of pages and trapping faults incur additional overhead that ideally is offset by improved memory locality but there is no universal guarantee. If the target workload is already bound to NUMA nodes then this -feature should be disabled. Otherwise, if the system overhead from the -feature is too high then the rate the kernel samples for NUMA hinting -faults may be controlled by the `numa_balancing_scan_period_min_ms, -numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms, -numa_balancing_scan_size_mb`_, and numa_balancing_settle_count sysctls. - - -numa_balancing_scan_period_min_ms, numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms, numa_balancing_scan_size_mb -=============================================================================================================================== - - -Automatic NUMA balancing scans tasks address space and unmaps pages to -detect if pages are properly placed or if the data should be migrated to a -memory node local to where the task is running. Every "scan delay" the task -scans the next "scan size" number of pages in its address space. When the -end of the address space is reached the scanner restarts from the beginning. - -In combination, the "scan delay" and "scan size" determine the scan rate. -When "scan delay" decreases, the scan rate increases. The scan delay and -hence the scan rate of every task is adaptive and depends on historical -behaviour. If pages are properly placed then the scan delay increases, -otherwise the scan delay decreases. The "scan size" is not adaptive but -the higher the "scan size", the higher the scan rate. - -Higher scan rates incur higher system overhead as page faults must be -trapped and potentially data must be migrated. However, the higher the scan -rate, the more quickly a tasks memory is migrated to a local node if the -workload pattern changes and minimises performance impact due to remote -memory accesses. These sysctls control the thresholds for scan delays and -the number of pages scanned. - -``numa_balancing_scan_period_min_ms`` is the minimum time in milliseconds to -scan a tasks virtual memory. It effectively controls the maximum scanning -rate for each task. - -``numa_balancing_scan_delay_ms`` is the starting "scan delay" used for a task -when it initially forks. - -``numa_balancing_scan_period_max_ms`` is the maximum time in milliseconds to -scan a tasks virtual memory. It effectively controls the minimum scanning -rate for each task. - -``numa_balancing_scan_size_mb`` is how many megabytes worth of pages are -scanned for a given scan. - +feature should be disabled. oops_all_cpu_backtrace ====================== diff --git a/Documentation/scheduler/index.rst b/Documentation/scheduler/index.rst index 88900aabdbf7..30cca8a37b3b 100644 --- a/Documentation/scheduler/index.rst +++ b/Documentation/scheduler/index.rst @@ -17,6 +17,7 @@ Linux Scheduler sched-nice-design sched-rt-group sched-stats + sched-debug text_files diff --git a/Documentation/scheduler/sched-debug.rst b/Documentation/scheduler/sched-debug.rst new file mode 100644 index 000000000000..4d3d24f2a439 --- /dev/null +++ b/Documentation/scheduler/sched-debug.rst @@ -0,0 +1,54 @@ +================= +Scheduler debugfs +================= + +Booting a kernel with CONFIG_SCHED_DEBUG=y will give access to +scheduler specific debug files under /sys/kernel/debug/sched. Some of +those files are described below. + +numa_balancing +============== + +`numa_balancing` directory is used to hold files to control NUMA +balancing feature. If the system overhead from the feature is too +high then the rate the kernel samples for NUMA hinting faults may be +controlled by the `scan_period_min_ms, scan_delay_ms, +scan_period_max_ms, scan_size_mb` files. + + +scan_period_min_ms, scan_delay_ms, scan_period_max_ms, scan_size_mb +------------------------------------------------------------------- + +Automatic NUMA balancing scans tasks address space and unmaps pages to +detect if pages are properly placed or if the data should be migrated to a +memory node local to where the task is running. Every "scan delay" the task +scans the next "scan size" number of pages in its address space. When the +end of the address space is reached the scanner restarts from the beginning. + +In combination, the "scan delay" and "scan size" determine the scan rate. +When "scan delay" decreases, the scan rate increases. The scan delay and +hence the scan rate of every task is adaptive and depends on historical +behaviour. If pages are properly placed then the scan delay increases, +otherwise the scan delay decreases. The "scan size" is not adaptive but +the higher the "scan size", the higher the scan rate. + +Higher scan rates incur higher system overhead as page faults must be +trapped and potentially data must be migrated. However, the higher the scan +rate, the more quickly a tasks memory is migrated to a local node if the +workload pattern changes and minimises performance impact due to remote +memory accesses. These files control the thresholds for scan delays and +the number of pages scanned. + +``scan_period_min_ms`` is the minimum time in milliseconds to scan a +tasks virtual memory. It effectively controls the maximum scanning +rate for each task. + +``scan_delay_ms`` is the starting "scan delay" used for a task when it +initially forks. + +``scan_period_max_ms`` is the maximum time in milliseconds to scan a +tasks virtual memory. It effectively controls the minimum scanning +rate for each task. + +``scan_size_mb`` is how many megabytes worth of pages are scanned for +a given scan. -- cgit From a7c9013216f399791ca354cc2e0f4a444837fe39 Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Sat, 29 Jan 2022 23:38:01 -0600 Subject: dt-bindings: arm: rockchip: Add Pine64 PineNote board The PineNote is a tablet from Pine64 based on the RK3566 SoC. There are two existing variants of the board. v1.1 was contained in some early samples, and v1.2 was sold as the "PineNote Developer Edition". Signed-off-by: Samuel Holland Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220130053803.43660-1-samuel@sholland.org Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 33d6423fe6c3..eece92f83a2d 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -481,6 +481,14 @@ properties: - const: pine64,pinebook-pro - const: rockchip,rk3399 + - description: Pine64 PineNote + items: + - enum: + - pine64,pinenote-v1.1 + - pine64,pinenote-v1.2 + - const: pine64,pinenote + - const: rockchip,rk3566 + - description: Pine64 Rock64 items: - const: pine64,rock64 -- cgit From 114fa138e41d8407da491da60e72e84fbb07889b Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 11 Jan 2022 18:54:30 +0100 Subject: dt-bindings: leds: common: fix unit address in max77693 example The max77693 LED device node should not take an unit address, because it is instantiated from a max77693 I2C parent device node. This also splits all examples to separate DTS examples because they are actually independent. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Reviewed-by: Javier Martinez Canillas Signed-off-by: Pavel Machek --- Documentation/devicetree/bindings/leds/common.yaml | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index 697102707703..328952d7acbb 100644 --- a/Documentation/devicetree/bindings/leds/common.yaml +++ b/Documentation/devicetree/bindings/leds/common.yaml @@ -185,9 +185,11 @@ examples: }; }; - led-controller@0 { + - | + #include + + led-controller { compatible = "maxim,max77693-led"; - reg = <0 0x100>; led { function = LED_FUNCTION_FLASH; @@ -199,6 +201,9 @@ examples: }; }; + - | + #include + i2c { #address-cells = <1>; #size-cells = <0>; -- cgit From 2f1b6bb66900ed3b54bda885ac87dcd5a7e122b4 Mon Sep 17 00:00:00 2001 From: André Apitzsch Date: Tue, 8 Feb 2022 00:06:36 +0100 Subject: dt-bindings: vendor-prefixes: Add ocs prefix MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the prefix for Orient Chip Technology. Signed-off-by: André Apitzsch Acked-by: Rob Herring Signed-off-by: Pavel Machek --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 294093d45a23..9ffffa9773ca 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -854,6 +854,8 @@ patternProperties: description: NXP Semiconductors "^oceanic,.*": description: Oceanic Systems (UK) Ltd. + "^ocs,.*": + description: Orient Chip Technology Co., Ltd. "^oct,.*": description: Octavo Systems LLC "^okaya,.*": -- cgit From 47c8ebcce85ed7113e9e3e3f1d8c6374fa87848e Mon Sep 17 00:00:00 2001 From: Jaegeuk Kim Date: Thu, 27 Jan 2022 13:31:43 -0800 Subject: f2fs: add a way to limit roll forward recovery time This adds a sysfs entry to call checkpoint during fsync() in order to avoid long elapsed time to run roll-forward recovery when booting the device. Default value doesn't enforce the limitation which is same as before. Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/ABI/testing/sysfs-fs-f2fs | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 7b50bf82f14d..58bf0dc83712 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -568,3 +568,9 @@ Contact: "Daeho Jeong" Description: You can set the trial count limit for GC urgent high mode with this value. If GC thread gets to the limit, the mode will turn back to GC normal mode. By default, the value is zero, which means there is no limit like before. + +What: /sys/fs/f2fs//max_roll_forward_node_blocks +Date: January 2022 +Contact: "Jaegeuk Kim" +Description: Controls max # of node block writes to be used for roll forward + recovery. This can limit the roll forward recovery time. -- cgit From 593504ba3ee36bb9e5c7e5cbcf13986817f4d8d8 Mon Sep 17 00:00:00 2001 From: Sam Ravnborg Date: Sat, 12 Feb 2022 15:19:20 +0100 Subject: dt-bindings: display: Add ingenic,jz4780-dw-hdmi DT Schema Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC. Based on .txt binding from Zubair Lutfullah Kakakhel Signed-off-by: Sam Ravnborg Signed-off-by: H. Nikolaus Schaller Cc: Rob Herring Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring Signed-off-by: Paul Cercueil Link: https://patchwork.freedesktop.org/patch/msgid/c806c6007f7bb090bf96ff6bd827f03e88bf4712.1644675566.git.hns@goldelico.com --- .../display/bridge/ingenic,jz4780-hdmi.yaml | 82 ++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml new file mode 100644 index 000000000000..b8219eab4475 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ingenic,jz4780-hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for Ingenic JZ4780 HDMI Transmitter + +maintainers: + - H. Nikolaus Schaller + +description: | + The HDMI Transmitter in the Ingenic JZ4780 is a Synopsys DesignWare HDMI 1.4 + TX controller IP with accompanying PHY IP. + +allOf: + - $ref: synopsys,dw-hdmi.yaml# + +properties: + compatible: + const: ingenic,jz4780-dw-hdmi + + reg-io-width: + const: 4 + + clocks: + maxItems: 2 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Input from LCD controller output. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Link to the HDMI connector. + +required: + - compatible + - clocks + - clock-names + - ports + - reg-io-width + +unevaluatedProperties: false + +examples: + - | + #include + + hdmi: hdmi@10180000 { + compatible = "ingenic,jz4780-dw-hdmi"; + reg = <0x10180000 0x8000>; + reg-io-width = <4>; + ddc-i2c-bus = <&i2c4>; + interrupt-parent = <&intc>; + interrupts = <3>; + clocks = <&cgu JZ4780_CLK_AHB0>, <&cgu JZ4780_CLK_HDMI>; + clock-names = "iahb", "isfr"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + hdmi_in: port@0 { + reg = <0>; + dw_hdmi_in: endpoint { + remote-endpoint = <&jz4780_lcd_out>; + }; + }; + hdmi_out: port@1 { + reg = <1>; + dw_hdmi_out: endpoint { + remote-endpoint = <&hdmi_con>; + }; + }; + }; + }; + +... -- cgit From e465ea5cc05d1d0b45c315fca0254bd2ee04b661 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 11 Feb 2022 17:47:16 +0100 Subject: dt-bindings: soc: samsung: usi: refer to dtschema for children Explicitly reference the dtschema for USI children implementing specific serial protocol (I2C, SPI, UART). The SPI schema is not yet accepted, so it will be provided later. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sam Protsenko Link: https://lore.kernel.org/r/20220211164716.120880-1-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/soc/samsung/exynos-usi.yaml | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml index 273f2d95a043..ea9c233052f3 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml @@ -17,13 +17,6 @@ description: | child nodes, each representing a serial sub-node device. The mode setting selects which particular function will be used. - Refer to next bindings documentation for information on protocol subnodes that - can exist under USI node: - - [1] Documentation/devicetree/bindings/serial/samsung_uart.yaml - [2] Documentation/devicetree/bindings/i2c/i2c-exynos5.txt - [3] Documentation/devicetree/bindings/spi/spi-samsung.txt - properties: $nodename: pattern: "^usi@[0-9a-f]+$" @@ -71,10 +64,17 @@ properties: This property is optional. patternProperties: - # All other properties should be child nodes - "^(serial|spi|i2c)@[0-9a-f]+$": + "^i2c@[0-9a-f]+$": + $ref: /schemas/i2c/i2c-exynos5.yaml + description: Child node describing underlying I2C + + "^serial@[0-9a-f]+$": + $ref: /schemas/serial/samsung_uart.yaml + description: Child node describing underlying UART/serial + + "^spi@[0-9a-f]+$": type: object - description: Child node describing underlying USI serial protocol + description: Child node describing underlying SPI required: - compatible -- cgit From 39d01d9c4522c4ac9e0f041eaaf7cee670a6a574 Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Mon, 7 Feb 2022 20:25:40 +0100 Subject: dt-bindings: power: add defines for i.MX8MP power domain This adds the DT defines for the GPC power domains found on the i.MX8MP SoC. Signed-off-by: Lucas Stach Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml index 01bdda167eef..747622bdc57b 100644 --- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml @@ -28,6 +28,7 @@ properties: - fsl,imx8mn-gpc - fsl,imx8mq-gpc - fsl,imx8mm-gpc + - fsl,imx8mp-gpc reg: maxItems: 1 @@ -57,6 +58,7 @@ properties: include/dt-bindings/power/imx7-power.h for fsl,imx7d-gpc and include/dt-bindings/power/imx8m-power.h for fsl,imx8mq-gpc include/dt-bindings/power/imx8mm-power.h for fsl,imx8mm-gpc + include/dt-bindings/power/imx8mp-power.h for fsl,imx8mp-gpc maxItems: 1 clocks: -- cgit From 8a473f456090d13c228c41623104a07db6d958ef Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Mon, 7 Feb 2022 20:25:43 +0100 Subject: dt-bindings: soc: add binding for i.MX8MP HSIO blk-ctrl This adds the binding for the HSIO blk-ctrl on the i.MX8MP SoC. Signed-off-by: Lucas Stach Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- .../bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml | 78 ++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml new file mode 100644 index 000000000000..c1e29d94f40e --- /dev/null +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8MP HSIO blk-ctrl + +maintainers: + - Lucas Stach + +description: + The i.MX8MP HSIO blk-ctrl is a top-level peripheral providing access to + the NoC and ensuring proper power sequencing of the high-speed IO + (USB an PCIe) peripherals located in the HSIO domain of the SoC. + +properties: + compatible: + items: + - const: fsl,imx8mp-hsio-blk-ctrl + - const: syscon + + reg: + maxItems: 1 + + '#power-domain-cells': + const: 1 + + power-domains: + minItems: 6 + maxItems: 6 + + power-domain-names: + items: + - const: bus + - const: usb + - const: usb-phy1 + - const: usb-phy2 + - const: pcie + - const: pcie-phy + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: usb + - const: pcie + +required: + - compatible + - reg + - power-domains + - power-domain-names + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + #include + + hsio_blk_ctrl: blk-ctrl@32f10000 { + compatible = "fsl,imx8mp-hsio-blk-ctrl", "syscon"; + reg = <0x32f10000 0x24>; + clocks = <&clk IMX8MP_CLK_USB_ROOT>, + <&clk IMX8MP_CLK_PCIE_ROOT>; + clock-names = "usb", "pcie"; + power-domains = <&pgc_hsiomix>, <&pgc_hsiomix>, + <&pgc_usb1_phy>, <&pgc_usb2_phy>, + <&pgc_hsiomix>, <&pgc_pcie_phy>; + power-domain-names = "bus", "usb", "usb-phy1", + "usb-phy2", "pcie", "pcie-phy"; + #power-domain-cells = <1>; + }; -- cgit From f67695c9962e5f444549b3437fb8d840ec6222c8 Mon Sep 17 00:00:00 2001 From: Elliot Berman Date: Tue, 1 Feb 2022 13:35:42 -0800 Subject: kbuild: Add environment variables for userprogs flags Allow additional arguments be passed to userprogs compilation. Reproducible clang builds need to provide a sysroot and gcc path to ensure the same toolchain is used across hosts. KCFLAGS is not currently used for any user programs compilation, so add new USERCFLAGS and USERLDFLAGS which serves similar purpose as HOSTCFLAGS/HOSTLDFLAGS. Clang might detect GCC installation on hosts which have it installed to a default location in /. With addition of these environment variables, you can specify flags such as: $ make USERCFLAGS=--sysroot=/path/to/sysroot This can also be used to specify different sysroots such as musl or bionic which may be installed on the host in paths that the compiler may not search by default. Signed-off-by: Elliot Berman Reviewed-by: Nick Desaulniers Reviewed-by: Fangrui Song Signed-off-by: Masahiro Yamada --- Documentation/kbuild/kbuild.rst | 11 +++++++++++ Documentation/kbuild/makefiles.rst | 2 ++ 2 files changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kbuild/kbuild.rst b/Documentation/kbuild/kbuild.rst index 2d1fc03d346e..ef19b9c13523 100644 --- a/Documentation/kbuild/kbuild.rst +++ b/Documentation/kbuild/kbuild.rst @@ -77,6 +77,17 @@ HOSTLDLIBS ---------- Additional libraries to link against when building host programs. +.. _userkbuildflags: + +USERCFLAGS +---------- +Additional options used for $(CC) when compiling userprogs. + +USERLDFLAGS +----------- +Additional options used for $(LD) when linking userprogs. userprogs are linked +with CC, so $(USERLDFLAGS) should include "-Wl," prefix as applicable. + KBUILD_KCONFIG -------------- Set the top-level Kconfig file to the value of this environment diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index b008b90b92c9..11a296e52d68 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -982,6 +982,8 @@ The syntax is quite similar. The difference is to use "userprogs" instead of When linking bpfilter_umh, it will be passed the extra option -static. + From command line, :ref:`USERCFLAGS and USERLDFLAGS ` will also be used. + 5.4 When userspace programs are actually built ---------------------------------------------- -- cgit From 2546c60004309ede8e2d1d5341e0decd90e057bf Mon Sep 17 00:00:00 2001 From: "David E. Box" Date: Fri, 11 Feb 2022 17:32:50 -0800 Subject: platform/x86: Add Intel Software Defined Silicon driver Intel Software Defined Silicon (SDSi) is a post manufacturing mechanism for activating additional silicon features. Features are enabled through a license activation process. The SDSi driver provides a per socket, sysfs attribute interface for applications to perform 3 main provisioning functions: 1. Provision an Authentication Key Certificate (AKC), a key written to internal NVRAM that is used to authenticate a capability specific activation payload. 2. Provision a Capability Activation Payload (CAP), a token authenticated using the AKC and applied to the CPU configuration to activate a new feature. 3. Read the SDSi State Certificate, containing the CPU configuration state. The operations perform function specific mailbox commands that forward the requests to SDSi hardware to perform authentication of the payloads and enable the silicon configuration (to be made available after power cycling). The SDSi device itself is enumerated as an auxiliary device from the intel_vsec driver and as such has a build dependency on CONFIG_INTEL_VSEC. Link: https://github.com/intel/intel-sdsi Signed-off-by: David E. Box Reviewed-by: Mark Gross Link: https://lore.kernel.org/r/20220212013252.1293396-2-david.e.box@linux.intel.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede --- Documentation/ABI/testing/sysfs-driver-intel_sdsi | 77 +++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel_sdsi (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-intel_sdsi b/Documentation/ABI/testing/sysfs-driver-intel_sdsi new file mode 100644 index 000000000000..ab122125ff9a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-intel_sdsi @@ -0,0 +1,77 @@ +What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "David E. Box" +Description: + This directory contains interface files for accessing Intel + Software Defined Silicon (SDSi) features on a CPU. X + represents the socket instance (though not the socket ID). + The socket ID is determined by reading the registers file + and decoding it per the specification. + + Some files communicate with SDSi hardware through a mailbox. + Should the operation fail, one of the following error codes + may be returned: + + Error Code Cause + ---------- ----- + EIO General mailbox failure. Log may indicate cause. + EBUSY Mailbox is owned by another agent. + EPERM SDSI capability is not enabled in hardware. + EPROTO Failure in mailbox protocol detected by driver. + See log for details. + EOVERFLOW For provision commands, the size of the data + exceeds what may be written. + ESPIPE Seeking is not allowed. + ETIMEDOUT Failure to complete mailbox transaction in time. + +What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/guid +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "David E. Box" +Description: + (RO) The GUID for the registers file. The GUID identifies + the layout of the registers file in this directory. + Information about the register layouts for a particular GUID + is available at http://github.com/intel/intel-sdsi + +What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/registers +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "David E. Box" +Description: + (RO) Contains information needed by applications to provision + a CPU and monitor status information. The layout of this file + is determined by the GUID in this directory. Information about + the layout for a particular GUID is available at + http://github.com/intel/intel-sdsi + +What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/provision_akc +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "David E. Box" +Description: + (WO) Used to write an Authentication Key Certificate (AKC) to + the SDSi NVRAM for the CPU. The AKC is used to authenticate a + Capability Activation Payload. Mailbox command. + +What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/provision_cap +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "David E. Box" +Description: + (WO) Used to write a Capability Activation Payload (CAP) to the + SDSi NVRAM for the CPU. CAPs are used to activate a given CPU + feature. A CAP is validated by SDSi hardware using a previously + provisioned AKC file. Upon successful authentication, the CPU + configuration is updated. A cold reboot is required to fully + activate the feature. Mailbox command. + +What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/state_certificate +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "David E. Box" +Description: + (RO) Used to read back the current State Certificate for the CPU + from SDSi hardware. The State Certificate contains information + about the current licenses on the CPU. Mailbox command. -- cgit From 759856e961e4ba7ecf6d40bff109a733e1a92a07 Mon Sep 17 00:00:00 2001 From: Joseph CHAMG Date: Fri, 11 Feb 2022 17:27:55 +0800 Subject: dt-bindings: net: Add Davicom dm9051 SPI ethernet controller This is a new yaml base data file for configure davicom dm9051 with device tree Signed-off-by: Joseph CHAMG Reviewed-by: Rob Herring Signed-off-by: David S. Miller --- .../devicetree/bindings/net/davicom,dm9051.yaml | 62 ++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/davicom,dm9051.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/davicom,dm9051.yaml b/Documentation/devicetree/bindings/net/davicom,dm9051.yaml new file mode 100644 index 000000000000..52e852fef753 --- /dev/null +++ b/Documentation/devicetree/bindings/net/davicom,dm9051.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/davicom,dm9051.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Davicom DM9051 SPI Ethernet Controller + +maintainers: + - Joseph CHANG + +description: | + The DM9051 is a fully integrated and cost-effective low pin count single + chip Fast Ethernet controller with a Serial Peripheral Interface (SPI). + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + const: davicom,dm9051 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 45000000 + + interrupts: + maxItems: 1 + + local-mac-address: true + + mac-address: true + +required: + - compatible + - reg + - spi-max-frequency + - interrupts + +additionalProperties: false + +examples: + # Raspberry Pi platform + - | + /* for Raspberry Pi with pin control stuff for GPIO irq */ + #include + #include + spi { + #address-cells = <1>; + #size-cells = <0>; + + ethernet@0 { + compatible = "davicom,dm9051"; + reg = <0>; /* spi chip select */ + local-mac-address = [00 00 00 00 00 00]; + interrupt-parent = <&gpio>; + interrupts = <26 IRQ_TYPE_LEVEL_LOW>; + spi-max-frequency = <31200000>; + }; + }; -- cgit From 8f8dbb35a6282f5fcedac48f3fea3eabbb6b3703 Mon Sep 17 00:00:00 2001 From: Hsin-Yi Wang Date: Sun, 13 Feb 2022 18:34:37 +0800 Subject: dt-bindings: drm/bridge: anx7625: Add aux-bus node List panel under aux-bus node if it's connected to anx7625's aux bus. Signed-off-by: Hsin-Yi Wang Reviewed-by: Rob Herring Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220213103437.3363848-4-hsinyi@chromium.org --- .../bindings/display/bridge/analogix,anx7625.yaml | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml index 1d3e88daca04..0d38d6fe3983 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -83,6 +83,9 @@ properties: type: boolean description: let the driver enable audio HDMI codec function or not. + aux-bus: + $ref: /schemas/display/dp-aux-bus.yaml# + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -167,5 +170,19 @@ examples: }; }; }; + + aux-bus { + panel { + compatible = "innolux,n125hce-gn1"; + power-supply = <&pp3300_disp_x>; + backlight = <&backlight_lcd0>; + + port { + panel_in: endpoint { + remote-endpoint = <&anx7625_out>; + }; + }; + }; + }; }; }; -- cgit From a94e5cd8457fb46866459562ef6c53f9dcc375f7 Mon Sep 17 00:00:00 2001 From: Vincent Whitchurch Date: Fri, 11 Feb 2022 14:24:49 +0100 Subject: regulator: tps62864: Fix bindings for SW property The property is not a pattern, so it should use 'properties' instead of 'patternProperties'. Also, unevaluatedProperties should be set to false like in the other regulator bindings. Reported-by: Rob Herring Signed-off-by: Vincent Whitchurch Link: https://lore.kernel.org/r/20220211132449.2899924-1-vincent.whitchurch@axis.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/ti,tps62864.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/ti,tps62864.yaml b/Documentation/devicetree/bindings/regulator/ti,tps62864.yaml index e3d739a37ab0..0f29c75f42ea 100644 --- a/Documentation/devicetree/bindings/regulator/ti,tps62864.yaml +++ b/Documentation/devicetree/bindings/regulator/ti,tps62864.yaml @@ -23,10 +23,11 @@ properties: regulators: type: object - patternProperties: + properties: "SW": type: object $ref: regulator.yaml# + unevaluatedProperties: false additionalProperties: false -- cgit From 4ab13489735d9b5b6e91634eab83922914a3310c Mon Sep 17 00:00:00 2001 From: Mika Westerberg Date: Wed, 9 Feb 2022 15:27:06 +0300 Subject: Documentation / MTD: Rename the intel-spi driver Since the driver is renamed (and moved) update the BIOS upgrade guide accordingly from intel-spi to spi-intel. Keep the guide under MTD documentation because this is pretty much still about MTD and SPI-NOR. Signed-off-by: Mika Westerberg Reviewed-by: Andy Shevchenko Reviewed-by: Mauro Lima Reviewed-by: Tudor Ambarus Link: https://lore.kernel.org/r/20220209122706.42439-4-mika.westerberg@linux.intel.com Signed-off-by: Mark Brown --- Documentation/driver-api/mtd/index.rst | 2 +- Documentation/driver-api/mtd/intel-spi.rst | 90 ------------------------------ Documentation/driver-api/mtd/spi-intel.rst | 90 ++++++++++++++++++++++++++++++ 3 files changed, 91 insertions(+), 91 deletions(-) delete mode 100644 Documentation/driver-api/mtd/intel-spi.rst create mode 100644 Documentation/driver-api/mtd/spi-intel.rst (limited to 'Documentation') diff --git a/Documentation/driver-api/mtd/index.rst b/Documentation/driver-api/mtd/index.rst index 436ba5a851d7..6a4278f409d7 100644 --- a/Documentation/driver-api/mtd/index.rst +++ b/Documentation/driver-api/mtd/index.rst @@ -7,6 +7,6 @@ Memory Technology Device (MTD) .. toctree:: :maxdepth: 1 - intel-spi + spi-intel nand_ecc spi-nor diff --git a/Documentation/driver-api/mtd/intel-spi.rst b/Documentation/driver-api/mtd/intel-spi.rst deleted file mode 100644 index 0465f6879262..000000000000 --- a/Documentation/driver-api/mtd/intel-spi.rst +++ /dev/null @@ -1,90 +0,0 @@ -============================== -Upgrading BIOS using intel-spi -============================== - -Many Intel CPUs like Baytrail and Braswell include SPI serial flash host -controller which is used to hold BIOS and other platform specific data. -Since contents of the SPI serial flash is crucial for machine to function, -it is typically protected by different hardware protection mechanisms to -avoid accidental (or on purpose) overwrite of the content. - -Not all manufacturers protect the SPI serial flash, mainly because it -allows upgrading the BIOS image directly from an OS. - -The intel-spi driver makes it possible to read and write the SPI serial -flash, if certain protection bits are not set and locked. If it finds -any of them set, the whole MTD device is made read-only to prevent -partial overwrites. By default the driver exposes SPI serial flash -contents as read-only but it can be changed from kernel command line, -passing "intel-spi.writeable=1". - -Please keep in mind that overwriting the BIOS image on SPI serial flash -might render the machine unbootable and requires special equipment like -Dediprog to revive. You have been warned! - -Below are the steps how to upgrade MinnowBoard MAX BIOS directly from -Linux. - - 1) Download and extract the latest Minnowboard MAX BIOS SPI image - [1]. At the time writing this the latest image is v92. - - 2) Install mtd-utils package [2]. We need this in order to erase the SPI - serial flash. Distros like Debian and Fedora have this prepackaged with - name "mtd-utils". - - 3) Add "intel-spi.writeable=1" to the kernel command line and reboot - the board (you can also reload the driver passing "writeable=1" as - module parameter to modprobe). - - 4) Once the board is up and running again, find the right MTD partition - (it is named as "BIOS"):: - - # cat /proc/mtd - dev: size erasesize name - mtd0: 00800000 00001000 "BIOS" - - So here it will be /dev/mtd0 but it may vary. - - 5) Make backup of the existing image first:: - - # dd if=/dev/mtd0ro of=bios.bak - 16384+0 records in - 16384+0 records out - 8388608 bytes (8.4 MB) copied, 10.0269 s, 837 kB/s - - 6) Verify the backup:: - - # sha1sum /dev/mtd0ro bios.bak - fdbb011920572ca6c991377c4b418a0502668b73 /dev/mtd0ro - fdbb011920572ca6c991377c4b418a0502668b73 bios.bak - - The SHA1 sums must match. Otherwise do not continue any further! - - 7) Erase the SPI serial flash. After this step, do not reboot the - board! Otherwise it will not start anymore:: - - # flash_erase /dev/mtd0 0 0 - Erasing 4 Kibyte @ 7ff000 -- 100 % complete - - 8) Once completed without errors you can write the new BIOS image:: - - # dd if=MNW2MAX1.X64.0092.R01.1605221712.bin of=/dev/mtd0 - - 9) Verify that the new content of the SPI serial flash matches the new - BIOS image:: - - # sha1sum /dev/mtd0ro MNW2MAX1.X64.0092.R01.1605221712.bin - 9b4df9e4be2057fceec3a5529ec3d950836c87a2 /dev/mtd0ro - 9b4df9e4be2057fceec3a5529ec3d950836c87a2 MNW2MAX1.X64.0092.R01.1605221712.bin - - The SHA1 sums should match. - - 10) Now you can reboot your board and observe the new BIOS starting up - properly. - -References ----------- - -[1] https://firmware.intel.com/sites/default/files/MinnowBoard%2EMAX_%2EX64%2E92%2ER01%2Ezip - -[2] http://www.linux-mtd.infradead.org/ diff --git a/Documentation/driver-api/mtd/spi-intel.rst b/Documentation/driver-api/mtd/spi-intel.rst new file mode 100644 index 000000000000..df854f20ead1 --- /dev/null +++ b/Documentation/driver-api/mtd/spi-intel.rst @@ -0,0 +1,90 @@ +============================== +Upgrading BIOS using spi-intel +============================== + +Many Intel CPUs like Baytrail and Braswell include SPI serial flash host +controller which is used to hold BIOS and other platform specific data. +Since contents of the SPI serial flash is crucial for machine to function, +it is typically protected by different hardware protection mechanisms to +avoid accidental (or on purpose) overwrite of the content. + +Not all manufacturers protect the SPI serial flash, mainly because it +allows upgrading the BIOS image directly from an OS. + +The spi-intel driver makes it possible to read and write the SPI serial +flash, if certain protection bits are not set and locked. If it finds +any of them set, the whole MTD device is made read-only to prevent +partial overwrites. By default the driver exposes SPI serial flash +contents as read-only but it can be changed from kernel command line, +passing "spi_intel.writeable=1". + +Please keep in mind that overwriting the BIOS image on SPI serial flash +might render the machine unbootable and requires special equipment like +Dediprog to revive. You have been warned! + +Below are the steps how to upgrade MinnowBoard MAX BIOS directly from +Linux. + + 1) Download and extract the latest Minnowboard MAX BIOS SPI image + [1]. At the time writing this the latest image is v92. + + 2) Install mtd-utils package [2]. We need this in order to erase the SPI + serial flash. Distros like Debian and Fedora have this prepackaged with + name "mtd-utils". + + 3) Add "spi_intel.writeable=1" to the kernel command line and reboot + the board (you can also reload the driver passing "writeable=1" as + module parameter to modprobe). + + 4) Once the board is up and running again, find the right MTD partition + (it is named as "BIOS"):: + + # cat /proc/mtd + dev: size erasesize name + mtd0: 00800000 00001000 "BIOS" + + So here it will be /dev/mtd0 but it may vary. + + 5) Make backup of the existing image first:: + + # dd if=/dev/mtd0ro of=bios.bak + 16384+0 records in + 16384+0 records out + 8388608 bytes (8.4 MB) copied, 10.0269 s, 837 kB/s + + 6) Verify the backup:: + + # sha1sum /dev/mtd0ro bios.bak + fdbb011920572ca6c991377c4b418a0502668b73 /dev/mtd0ro + fdbb011920572ca6c991377c4b418a0502668b73 bios.bak + + The SHA1 sums must match. Otherwise do not continue any further! + + 7) Erase the SPI serial flash. After this step, do not reboot the + board! Otherwise it will not start anymore:: + + # flash_erase /dev/mtd0 0 0 + Erasing 4 Kibyte @ 7ff000 -- 100 % complete + + 8) Once completed without errors you can write the new BIOS image:: + + # dd if=MNW2MAX1.X64.0092.R01.1605221712.bin of=/dev/mtd0 + + 9) Verify that the new content of the SPI serial flash matches the new + BIOS image:: + + # sha1sum /dev/mtd0ro MNW2MAX1.X64.0092.R01.1605221712.bin + 9b4df9e4be2057fceec3a5529ec3d950836c87a2 /dev/mtd0ro + 9b4df9e4be2057fceec3a5529ec3d950836c87a2 MNW2MAX1.X64.0092.R01.1605221712.bin + + The SHA1 sums should match. + + 10) Now you can reboot your board and observe the new BIOS starting up + properly. + +References +---------- + +[1] https://firmware.intel.com/sites/default/files/MinnowBoard%2EMAX_%2EX64%2E92%2ER01%2Ezip + +[2] http://www.linux-mtd.infradead.org/ -- cgit From da9f8386d6b7f2bb01098913c64b2b246f39cfce Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda Date: Tue, 8 Feb 2022 09:20:29 +0900 Subject: dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a779f0 support Document the compatible values for the IPMMU-VMSA blocks in the Renesas R-Car S4-8 (R8A779F0) SoC and R-Car Gen4. Signed-off-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220208002030.1319984-2-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Joerg Roedel --- Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml index ce0c715205c6..5159a87f3fa7 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml @@ -44,6 +44,10 @@ properties: - renesas,ipmmu-r8a77990 # R-Car E3 - renesas,ipmmu-r8a77995 # R-Car D3 - renesas,ipmmu-r8a779a0 # R-Car V3U + - items: + - enum: + - renesas,ipmmu-r8a779f0 # R-Car S4-8 + - const: renesas,rcar-gen4-ipmmu-vmsa # R-Car Gen4 reg: maxItems: 1 -- cgit From af31e2b729a215a1a1d40939bcfccdbab9971deb Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 11 Jan 2022 18:50:14 +0100 Subject: dt-bindings: leds: maxim,max77693: Convert to dtschema Convert the LEDs bindings of Maxim MAX77693 MUIC to DT schema format. The existing bindings were defined in ../bindings/mfd/max77693.txt. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Lee Jones --- .../devicetree/bindings/leds/maxim,max77693.yaml | 105 +++++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/maxim,max77693.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/maxim,max77693.yaml b/Documentation/devicetree/bindings/leds/maxim,max77693.yaml new file mode 100644 index 000000000000..86a0005cf156 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/maxim,max77693.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/maxim,max77693.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77693 MicroUSB and Companion Power Management IC LEDs + +maintainers: + - Krzysztof Kozlowski + +description: | + This is a part of device tree bindings for Maxim MAX77693 MicroUSB Integrated + Circuit (MUIC). + + There are two LED outputs available - FLED1 and FLED2. Each of them can + control a separate LED or they can be connected together to double the + maximum current for a single connected LED. One LED is represented by one + child node. + + See also Documentation/devicetree/bindings/mfd/maxim,max77693.yaml for + additional information and example. + +properties: + compatible: + const: maxim,max77693-led + + maxim,boost-mode: + description: + In boost mode the device can produce up to 1.2A of total current on both + outputs. The maximum current on each output is reduced to 625mA then. If + not enabled explicitly, boost setting defaults to LEDS_BOOST_FIXED in + case both current sources are used. + See LEDS_BOOST_* in include/dt-bindings/leds/common.h. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + + maxim,boost-mvout: + description: | + Output voltage of the boost module in millivolts. + Valid values: 3300 - 5500, step by 25 (rounded down) + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 3300 + maximum: 5500 + default: 3300 + + maxim,mvsys-min: + description: | + Low input voltage level in millivolts. Flash is not fired if chip + estimates that system voltage could drop below this level due to flash + power consumption. + Valid values: 2400 - 3400, step by 33 (rounded down) + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 2400 + maximum: 3400 + default: 2400 + +patternProperties: + "^([a-z]+-)?led[01]?$": + type: object + $ref: common.yaml# + unevaluatedProperties: false + + properties: + led-sources: + allOf: + - minItems: 1 + maxItems: 2 + items: + minimum: 0 + maximum: 1 + + led-max-microamp: + description: | + Valid values for a LED connected to one FLED output: + 15625 - 250000, step by 15625 (rounded down) + Valid values for a LED connected to both FLED outputs: + 15625 - 500000, step by 15625 (rounded down) + + flash-max-microamp: + description: | + Valid values for a single LED connected to one FLED output + (boost mode must be turned off): + 15625 - 1000000, step by 15625 (rounded down) + Valid values for a single LED connected to both FLED outputs: + 15625 - 1250000, step by 15625 (rounded down) + Valid values for two LEDs case: + 15625 - 625000, step by 15625 (rounded down) + + flash-max-timeout-us: + description: | + Valid values: 62500 - 1000000, step by 62500 (rounded down) + minimum: 62500 + maximum: 1000000 + + required: + - flash-max-microamp + - flash-max-timeout-us + - led-max-microamp + - led-sources + +required: + - compatible + +additionalProperties: false -- cgit From a400122b2a9685f6758be817f2a9043bd641af7b Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 11 Jan 2022 18:50:15 +0100 Subject: dt-bindings: power: supply: maxim,max77693: Convert to dtschema Convert the Charger bindings of Maxim MAX77693 MUIC to DT schema format. The existing bindings were defined in ../bindings/mfd/max77693.txt. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Lee Jones --- .../bindings/power/supply/maxim,max77693.yaml | 70 ++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml new file mode 100644 index 000000000000..a21dc1a8890f --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/maxim,max77693.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77693 MicroUSB and Companion Power Management IC Charger + +maintainers: + - Krzysztof Kozlowski + +description: | + This is a part of device tree bindings for Maxim MAX77693 MicroUSB Integrated + Circuit (MUIC). + + See also Documentation/devicetree/bindings/mfd/maxim,max77693.yaml for + additional information and example. + +properties: + compatible: + const: maxim,max77693-charger + + maxim,constant-microvolt: + description: | + Battery constant voltage in uV. The charger will operate in fast + charge constant current mode till battery voltage reaches this level. + Then the charger will switch to fast charge constant voltage mode. + Also vsys (system voltage) will be set to this value when DC power is + supplied but charger is not enabled. + Valid values: 3650000 - 4400000, step by 25000 (rounded down) + minimum: 3650000 + maximum: 4400000 + default: 4200000 + + maxim,min-system-microvolt: + description: | + Minimal system voltage in uV. + enum: [3000000, 3100000, 3200000, 3300000, 3400000, 3500000, + 3600000, 3700000] + default: 3600000 + + maxim,thermal-regulation-celsius: + description: | + Temperature in Celsius for entering high temperature charging mode. + If die temperature exceeds this value the charging current will be + reduced by 105 mA/Celsius. + enum: [70, 85, 100, 115] + default: 100 + + maxim,battery-overcurrent-microamp: + description: | + Overcurrent protection threshold in uA (current from battery to + system). + Valid values: 2000000 - 3500000, step by 250000 (rounded down) + minimum: 2000000 + maximum: 3500000 + default: 3500000 + + maxim,charge-input-threshold-microvolt: + description: | + Threshold voltage in uV for triggering input voltage regulation loop. + If input voltage decreases below this value, the input current will + be reduced to reach the threshold voltage. + enum: [4300000, 4700000, 4800000, 4900000] + default: 4300000 + +required: + - compatible + +additionalProperties: false -- cgit From 1a2c2cac2cae13cfd78904923eff0356f2d3f071 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 11 Jan 2022 18:50:16 +0100 Subject: regulator: dt-bindings: maxim,max77693: Convert to dtschema Convert the regulator bindings of Maxim MAX77693 MUIC to DT schema format. The existing bindings were defined in ../bindings/mfd/max77693.txt. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Lee Jones --- .../bindings/regulator/maxim,max77693.yaml | 60 ++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/maxim,max77693.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77693.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77693.yaml new file mode 100644 index 000000000000..20d8559bdc2b --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max77693.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max77693.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77693 MicroUSB and Companion Power Management IC regulators + +maintainers: + - Chanwoo Choi + - Krzysztof Kozlowski + +description: | + This is a part of device tree bindings for Maxim MAX77693 MicroUSB Integrated + Circuit (MUIC). + + See also Documentation/devicetree/bindings/mfd/maxim,max77693.yaml for + additional information and example. + +properties: + CHARGER: + type: object + $ref: regulator.yaml# + additionalProperties: false + description: | + Current regulator. + + properties: + regulator-name: true + regulator-always-on: true + regulator-boot-on: true + regulator-min-microamp: + minimum: 60000 + regulator-max-microamp: + maximum: 2580000 + + required: + - regulator-name + +patternProperties: + "^ESAFEOUT[12]$": + type: object + $ref: regulator.yaml# + additionalProperties: false + description: | + Safeout LDO regulator. + + properties: + regulator-name: true + regulator-always-on: true + regulator-boot-on: true + regulator-min-microvolt: + minimum: 3300000 + regulator-max-microvolt: + maximum: 4950000 + + required: + - regulator-name + +additionalProperties: false -- cgit From b38213c6118b6b3fe163bd9acb7f723c379dd833 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 11 Jan 2022 18:50:17 +0100 Subject: dt-bindings: mfd: maxim,max77693: Convert to dtschema Convert the MFD part of Maxim MAX77693 MUIC to DT schema format. The example DTS was copied from existing DTS (exynos4412-midas.dtsi), so keep the license as GPL-2.0-only. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/max77693.txt | 194 --------------------- .../devicetree/bindings/mfd/maxim,max77693.yaml | 143 +++++++++++++++ 2 files changed, 143 insertions(+), 194 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mfd/max77693.txt create mode 100644 Documentation/devicetree/bindings/mfd/maxim,max77693.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt deleted file mode 100644 index 1032df14498b..000000000000 --- a/Documentation/devicetree/bindings/mfd/max77693.txt +++ /dev/null @@ -1,194 +0,0 @@ -Maxim MAX77693 multi-function device - -MAX77693 is a Multifunction device with the following submodules: -- PMIC, -- CHARGER, -- LED, -- MUIC, -- HAPTIC - -It is interfaced to host controller using i2c. -This document describes the bindings for the mfd device. - -Required properties: -- compatible : Must be "maxim,max77693". -- reg : Specifies the i2c slave address of PMIC block. -- interrupts : This i2c device has an IRQ line connected to the main SoC. - -Optional properties: -- regulators : The regulators of max77693 have to be instantiated under subnode - named "regulators" using the following format. - - regulators { - regulator-compatible = ESAFEOUT1/ESAFEOUT2/CHARGER - standard regulator constraints[*]. - }; - - [*] refer Documentation/devicetree/bindings/regulator/regulator.txt - -- haptic : The MAX77693 haptic device utilises a PWM controlled motor to provide - users with tactile feedback. PWM period and duty-cycle are varied in - order to provide the appropriate level of feedback. - - Required properties: - - compatible : Must be "maxim,max77693-haptic" - - haptic-supply : power supply for the haptic motor - [*] refer Documentation/devicetree/bindings/regulator/regulator.txt - - pwms : phandle to the physical PWM(Pulse Width Modulation) device. - PWM properties should be named "pwms". And number of cell is different - for each pwm device. - To get more information, please refer to documentation. - [*] refer Documentation/devicetree/bindings/pwm/pwm.txt - -- charger : Node configuring the charger driver. - If present, required properties: - - compatible : Must be "maxim,max77693-charger". - - Optional properties (if not set, defaults will be used): - - maxim,constant-microvolt : Battery constant voltage in uV. The charger - will operate in fast charge constant current mode till battery voltage - reaches this level. Then the charger will switch to fast charge constant - voltage mode. Also vsys (system voltage) will be set to this value when - DC power is supplied but charger is not enabled. - Valid values: 3650000 - 4400000, step by 25000 (rounded down) - Default: 4200000 - - - maxim,min-system-microvolt : Minimal system voltage in uV. - Valid values: 3000000 - 3700000, step by 100000 (rounded down) - Default: 3600000 - - - maxim,thermal-regulation-celsius : Temperature in Celsius for entering - high temperature charging mode. If die temperature exceeds this value - the charging current will be reduced by 105 mA/Celsius. - Valid values: 70, 85, 100, 115 - Default: 100 - - - maxim,battery-overcurrent-microamp : Overcurrent protection threshold - in uA (current from battery to system). - Valid values: 2000000 - 3500000, step by 250000 (rounded down) - Default: 3500000 - - - maxim,charge-input-threshold-microvolt : Threshold voltage in uV for - triggering input voltage regulation loop. If input voltage decreases - below this value, the input current will be reduced to reach the - threshold voltage. - Valid values: 4300000, 4700000, 4800000, 4900000 - Default: 4300000 - -- led : the LED submodule device node - -There are two LED outputs available - FLED1 and FLED2. Each of them can -control a separate LED or they can be connected together to double -the maximum current for a single connected LED. One LED is represented -by one child node. - -Required properties: -- compatible : Must be "maxim,max77693-led". - -Optional properties: -- maxim,boost-mode : - In boost mode the device can produce up to 1.2A of total current - on both outputs. The maximum current on each output is reduced - to 625mA then. If not enabled explicitly, boost setting defaults to - LEDS_BOOST_FIXED in case both current sources are used. - Possible values: - LEDS_BOOST_OFF (0) - no boost, - LEDS_BOOST_ADAPTIVE (1) - adaptive mode, - LEDS_BOOST_FIXED (2) - fixed mode. -- maxim,boost-mvout : Output voltage of the boost module in millivolts. - Valid values: 3300 - 5500, step by 25 (rounded down) - Default: 3300 -- maxim,mvsys-min : Low input voltage level in millivolts. Flash is not fired - if chip estimates that system voltage could drop below this level due - to flash power consumption. - Valid values: 2400 - 3400, step by 33 (rounded down) - Default: 2400 - -Required properties for the LED child node: -- led-sources : see Documentation/devicetree/bindings/leds/common.txt; - device current output identifiers: 0 - FLED1, 1 - FLED2 -- led-max-microamp : see Documentation/devicetree/bindings/leds/common.txt - Valid values for a LED connected to one FLED output: - 15625 - 250000, step by 15625 (rounded down) - Valid values for a LED connected to both FLED outputs: - 15625 - 500000, step by 15625 (rounded down) -- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt - Valid values for a single LED connected to one FLED output - (boost mode must be turned off): - 15625 - 1000000, step by 15625 (rounded down) - Valid values for a single LED connected to both FLED outputs: - 15625 - 1250000, step by 15625 (rounded down) - Valid values for two LEDs case: - 15625 - 625000, step by 15625 (rounded down) -- flash-max-timeout-us : see Documentation/devicetree/bindings/leds/common.txt - Valid values: 62500 - 1000000, step by 62500 (rounded down) - -Optional properties for the LED child node: -- label : see Documentation/devicetree/bindings/leds/common.txt - -Optional nodes: -- max77693-muic : - Node used only by extcon consumers. - Required properties: - - compatible : "maxim,max77693-muic" - -Example: -#include - - max77693@66 { - compatible = "maxim,max77693"; - reg = <0x66>; - interrupt-parent = <&gpx1>; - interrupts = <5 IRQ_TYPE_LEVEL_LOW>; - - regulators { - esafeout@1 { - regulator-compatible = "ESAFEOUT1"; - regulator-name = "ESAFEOUT1"; - regulator-boot-on; - }; - esafeout@2 { - regulator-compatible = "ESAFEOUT2"; - regulator-name = "ESAFEOUT2"; - }; - charger@0 { - regulator-compatible = "CHARGER"; - regulator-name = "CHARGER"; - regulator-min-microamp = <60000>; - regulator-max-microamp = <2580000>; - regulator-boot-on; - }; - }; - - haptic { - compatible = "maxim,max77693-haptic"; - haptic-supply = <&haptic_supply>; - pwms = <&pwm 0 40000 0>; - pwm-names = "haptic"; - }; - - charger { - compatible = "maxim,max77693-charger"; - - maxim,constant-microvolt = <4200000>; - maxim,min-system-microvolt = <3600000>; - maxim,thermal-regulation-celsius = <75>; - maxim,battery-overcurrent-microamp = <3000000>; - maxim,charge-input-threshold-microvolt = <4300000>; - }; - - led { - compatible = "maxim,max77693-led"; - maxim,boost-mode = ; - maxim,boost-mvout = <5000>; - maxim,mvsys-min = <2400>; - - camera_flash: flash-led { - label = "max77693-flash"; - led-sources = <0>, <1>; - led-max-microamp = <500000>; - flash-max-microamp = <1250000>; - flash-max-timeout-us = <1000000>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml new file mode 100644 index 000000000000..906101197e11 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml @@ -0,0 +1,143 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/maxim,max77693.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77693 MicroUSB and Companion Power Management IC + +maintainers: + - Chanwoo Choi + - Krzysztof Kozlowski + +description: | + This is a part of device tree bindings for Maxim MAX77693 MicroUSB + Integrated Circuit (MUIC). + + The Maxim MAX77693 is a MicroUSB and Companion Power Management IC which + includes voltage current regulators, charger, LED/flash, haptic motor driver + and MicroUSB management IC. + +properties: + compatible: + const: maxim,max77693 + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + charger: + $ref: /schemas/power/supply/maxim,max77693.yaml + + led: + $ref: /schemas/leds/maxim,max77693.yaml + + max77693-muic: + type: object + additionalProperties: false + + properties: + compatible: + const: maxim,max77693-muic + + required: + - compatible + + motor-driver: + type: object + additionalProperties: false + + properties: + compatible: + const: maxim,max77693-haptic + + haptic-supply: + description: Power supply to the haptic motor + + pwms: + maxItems: 1 + + required: + - compatible + - haptic-supply + - pwms + + regulators: + $ref: ../regulator/maxim,max77693.yaml + description: + List of child nodes that specify the regulators. + +required: + - compatible + - interrupts + - reg + +additionalProperties: false + +examples: + - | + #include + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@66 { + compatible = "maxim,max77693"; + reg = <0x66>; + interrupt-parent = <&gpx1>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW>; + + regulators { + ESAFEOUT1 { + regulator-name = "ESAFEOUT1"; + }; + + ESAFEOUT2 { + regulator-name = "ESAFEOUT2"; + }; + + CHARGER { + regulator-name = "CHARGER"; + regulator-min-microamp = <60000>; + regulator-max-microamp = <2580000>; + }; + }; + + motor-driver { + compatible = "maxim,max77693-haptic"; + haptic-supply = <&ldo26_reg>; + pwms = <&pwm 0 38022 0>; + }; + + charger { + compatible = "maxim,max77693-charger"; + + maxim,constant-microvolt = <4350000>; + maxim,min-system-microvolt = <3600000>; + maxim,thermal-regulation-celsius = <100>; + maxim,battery-overcurrent-microamp = <3500000>; + maxim,charge-input-threshold-microvolt = <4300000>; + }; + + led { + compatible = "maxim,max77693-led"; + maxim,boost-mode = ; + maxim,boost-mvout = <5000>; + maxim,mvsys-min = <2400>; + + flash-led { + label = "max77693-flash"; + function = LED_FUNCTION_FLASH; + color = ; + led-sources = <0>, <1>; + led-max-microamp = <500000>; + flash-max-microamp = <1250000>; + flash-max-timeout-us = <1000000>; + }; + }; + }; + }; -- cgit From 20ea94bc5317475af70f003075e7988715457d66 Mon Sep 17 00:00:00 2001 From: Srinivasa Rao Mandadapu Date: Sat, 12 Feb 2022 17:54:32 +0530 Subject: ASoC: dt-bindings: wcd938x: Add gpio property for selecting CTIA/OMTP headset Add gpio property used for selecting CTIA/OMTP headset connected to wcd codec. Signed-off-by: Srinivasa Rao Mandadapu Co-developed-by: Venkata Prasad Potturu Signed-off-by: Venkata Prasad Potturu Link: https://lore.kernel.org/r/1644668672-29790-3-git-send-email-quic_srivasam@quicinc.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml index cb74ce40c2e6..7bf1a5fffcd2 100644 --- a/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml @@ -23,6 +23,10 @@ properties: description: GPIO spec for reset line to use maxItems: 1 + us-euro-gpios: + description: GPIO spec for swapping gnd and mic segments + maxItems: 1 + vdd-buck-supply: description: A reference to the 1.8V buck supply -- cgit From 5e35d0eb472b48ac9c8ef7017753b8a1f765aa01 Mon Sep 17 00:00:00 2001 From: Janis Schoetterl-Glausch Date: Fri, 11 Feb 2022 19:22:14 +0100 Subject: KVM: s390: Update api documentation for memop ioctl Document all currently existing operations, flags and explain under which circumstances they are available. Document the recently introduced absolute operations and the storage key protection flag, as well as the existing SIDA operations. Signed-off-by: Janis Schoetterl-Glausch Reviewed-by: Janosch Frank Link: https://lore.kernel.org/r/20220211182215.2730017-10-scgl@linux.ibm.com Signed-off-by: Christian Borntraeger --- Documentation/virt/kvm/api.rst | 112 +++++++++++++++++++++++++++++++++-------- 1 file changed, 90 insertions(+), 22 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index a4267104db50..48f23bb80d7f 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -3683,15 +3683,17 @@ The fields in each entry are defined as follows: 4.89 KVM_S390_MEM_OP -------------------- -:Capability: KVM_CAP_S390_MEM_OP +:Capability: KVM_CAP_S390_MEM_OP, KVM_CAP_S390_PROTECTED, KVM_CAP_S390_MEM_OP_EXTENSION :Architectures: s390 -:Type: vcpu ioctl +:Type: vm ioctl, vcpu ioctl :Parameters: struct kvm_s390_mem_op (in) :Returns: = 0 on success, < 0 on generic error (e.g. -EFAULT or -ENOMEM), > 0 if an exception occurred while walking the page tables -Read or write data from/to the logical (virtual) memory of a VCPU. +Read or write data from/to the VM's memory. +The KVM_CAP_S390_MEM_OP_EXTENSION capability specifies what functionality is +supported. Parameters are specified via the following structure:: @@ -3701,33 +3703,99 @@ Parameters are specified via the following structure:: __u32 size; /* amount of bytes */ __u32 op; /* type of operation */ __u64 buf; /* buffer in userspace */ - __u8 ar; /* the access register number */ - __u8 reserved[31]; /* should be set to 0 */ + union { + struct { + __u8 ar; /* the access register number */ + __u8 key; /* access key, ignored if flag unset */ + }; + __u32 sida_offset; /* offset into the sida */ + __u8 reserved[32]; /* ignored */ + }; }; -The type of operation is specified in the "op" field. It is either -KVM_S390_MEMOP_LOGICAL_READ for reading from logical memory space or -KVM_S390_MEMOP_LOGICAL_WRITE for writing to logical memory space. The -KVM_S390_MEMOP_F_CHECK_ONLY flag can be set in the "flags" field to check -whether the corresponding memory access would create an access exception -(without touching the data in the memory at the destination). In case an -access exception occurred while walking the MMU tables of the guest, the -ioctl returns a positive error number to indicate the type of exception. -This exception is also raised directly at the corresponding VCPU if the -flag KVM_S390_MEMOP_F_INJECT_EXCEPTION is set in the "flags" field. - The start address of the memory region has to be specified in the "gaddr" field, and the length of the region in the "size" field (which must not be 0). The maximum value for "size" can be obtained by checking the KVM_CAP_S390_MEM_OP capability. "buf" is the buffer supplied by the userspace application where the read data should be written to for -KVM_S390_MEMOP_LOGICAL_READ, or where the data that should be written is -stored for a KVM_S390_MEMOP_LOGICAL_WRITE. When KVM_S390_MEMOP_F_CHECK_ONLY -is specified, "buf" is unused and can be NULL. "ar" designates the access -register number to be used; the valid range is 0..15. +a read access, or where the data that should be written is stored for +a write access. The "reserved" field is meant for future extensions. +Reserved and unused values are ignored. Future extension that add members must +introduce new flags. + +The type of operation is specified in the "op" field. Flags modifying +their behavior can be set in the "flags" field. Undefined flag bits must +be set to 0. + +Possible operations are: + * ``KVM_S390_MEMOP_LOGICAL_READ`` + * ``KVM_S390_MEMOP_LOGICAL_WRITE`` + * ``KVM_S390_MEMOP_ABSOLUTE_READ`` + * ``KVM_S390_MEMOP_ABSOLUTE_WRITE`` + * ``KVM_S390_MEMOP_SIDA_READ`` + * ``KVM_S390_MEMOP_SIDA_WRITE`` + +Logical read/write: +^^^^^^^^^^^^^^^^^^^ + +Access logical memory, i.e. translate the given guest address to an absolute +address given the state of the VCPU and use the absolute address as target of +the access. "ar" designates the access register number to be used; the valid +range is 0..15. +Logical accesses are permitted for the VCPU ioctl only. +Logical accesses are permitted for non-protected guests only. + +Supported flags: + * ``KVM_S390_MEMOP_F_CHECK_ONLY`` + * ``KVM_S390_MEMOP_F_INJECT_EXCEPTION`` + * ``KVM_S390_MEMOP_F_SKEY_PROTECTION`` + +The KVM_S390_MEMOP_F_CHECK_ONLY flag can be set to check whether the +corresponding memory access would cause an access exception; however, +no actual access to the data in memory at the destination is performed. +In this case, "buf" is unused and can be NULL. + +In case an access exception occurred during the access (or would occur +in case of KVM_S390_MEMOP_F_CHECK_ONLY), the ioctl returns a positive +error number indicating the type of exception. This exception is also +raised directly at the corresponding VCPU if the flag +KVM_S390_MEMOP_F_INJECT_EXCEPTION is set. + +If the KVM_S390_MEMOP_F_SKEY_PROTECTION flag is set, storage key +protection is also in effect and may cause exceptions if accesses are +prohibited given the access key passed in "key". +KVM_S390_MEMOP_F_SKEY_PROTECTION is available if KVM_CAP_S390_MEM_OP_EXTENSION +is > 0. + +Absolute read/write: +^^^^^^^^^^^^^^^^^^^^ + +Access absolute memory. This operation is intended to be used with the +KVM_S390_MEMOP_F_SKEY_PROTECTION flag, to allow accessing memory and performing +the checks required for storage key protection as one operation (as opposed to +user space getting the storage keys, performing the checks, and accessing +memory thereafter, which could lead to a delay between check and access). +Absolute accesses are permitted for the VM ioctl if KVM_CAP_S390_MEM_OP_EXTENSION +is > 0. +Currently absolute accesses are not permitted for VCPU ioctls. +Absolute accesses are permitted for non-protected guests only. + +Supported flags: + * ``KVM_S390_MEMOP_F_CHECK_ONLY`` + * ``KVM_S390_MEMOP_F_SKEY_PROTECTION`` + +The semantics of the flags are as for logical accesses. + +SIDA read/write: +^^^^^^^^^^^^^^^^ + +Access the secure instruction data area which contains memory operands necessary +for instruction emulation for protected guests. +SIDA accesses are available if the KVM_CAP_S390_PROTECTED capability is available. +SIDA accesses are permitted for the VCPU ioctl only. +SIDA accesses are permitted for protected guests only. -The "reserved" field is meant for future extensions. It is not used by -KVM with the currently defined set of flags. +No flags are supported. 4.90 KVM_S390_GET_SKEYS ----------------------- -- cgit From 6b22ce002f755e34e9a92ce5a41ffda0b729b892 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Thu, 10 Feb 2022 10:26:53 +0900 Subject: docs: Makefile: Add -no-shell-escape option to LATEXOPTS It turns out that LaTeX enables \write18, which allows (some) shell commands to be executed from the document source, by default. This the often-seen warning during a pdfdocs build: restricted \write18 enabled That is a potential security problem and is entirely unnecessary; nothing in the kernel PDF docs build needs that capability. So disable \write18 explicitly. Signed-off-by: Akira Yokosawa Link: https://lore.kernel.org/r/519bd2d9-1bee-03e1-eeb4-d9883c18be0c@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/Makefile b/Documentation/Makefile index 9f4bd42cef18..64d44c1ecad3 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -26,7 +26,7 @@ SPHINX_CONF = conf.py PAPER = BUILDDIR = $(obj)/output PDFLATEX = xelatex -LATEXOPTS = -interaction=batchmode +LATEXOPTS = -interaction=batchmode -no-shell-escape ifeq ($(KBUILD_VERBOSE),0) SPHINXOPTS += "-q" -- cgit From 12bf2f9f7fdd3709b327fa1a62f63fa6100bc26f Mon Sep 17 00:00:00 2001 From: Biju Das Date: Mon, 10 Jan 2022 13:46:55 +0000 Subject: dt-bindings: dma: rz-dmac: Document RZ/V2L SoC Document RZ/V2L DMAC bindings. RZ/V2L DMAC is identical to one found on the RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,rz-dmac" will be used as a fallback. Signed-off-by: Biju Das Signed-off-by: Lad Prabhakar Acked-by: Rob Herring Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20220110134659.30424-9-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml index 7a4f415d74dc..e353377084aa 100644 --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/dma/renesas,rz-dmac.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas RZ/G2L DMA Controller +title: Renesas RZ/{G2L,V2L} DMA Controller maintainers: - Biju Das @@ -17,6 +17,7 @@ properties: items: - enum: - renesas,r9a07g044-dmac # RZ/G2{L,LC} + - renesas,r9a07g054-dmac # RZ/V2L - const: renesas,rz-dmac reg: -- cgit From 614c8beca7cd6e7093385c88da800e258b7eb0ca Mon Sep 17 00:00:00 2001 From: Biju Das Date: Sun, 6 Feb 2022 20:03:08 +0000 Subject: dt-bindings: dma: rz-dmac: Document RZ/G2UL SoC Document RZ/G2UL DMAC bindings. RZ/G2UL DMAC is identical to one found on the RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,rz-dmac" will be used as a fallback. Signed-off-by: Biju Das Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220206200308.14315-1-biju.das.jz@bp.renesas.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml index e353377084aa..1e25c5b0fb4d 100644 --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/dma/renesas,rz-dmac.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas RZ/{G2L,V2L} DMA Controller +title: Renesas RZ/{G2L,G2UL,V2L} DMA Controller maintainers: - Biju Das @@ -16,6 +16,7 @@ properties: compatible: items: - enum: + - renesas,r9a07g043-dmac # RZ/G2UL - renesas,r9a07g044-dmac # RZ/G2{L,LC} - renesas,r9a07g054-dmac # RZ/V2L - const: renesas,rz-dmac -- cgit From a268b155100b37cd280fcfd3ef72be536f33dfa0 Mon Sep 17 00:00:00 2001 From: Jonathan Neuschäfer Date: Sat, 29 Jan 2022 12:52:20 +0100 Subject: dt-bindings: arm/npcm: Add binding for global control registers (GCR) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A nuvoton,*-gcr node is present in nuvoton-common-npcm7xx.dtsi and will be added to nuvoton-wpcm450.dtsi. It is necessary for the NPCM7xx and WPCM450 pinctrl drivers, and may later be used to retrieve SoC model and version information. This patch adds a binding to describe this node. Signed-off-by: Jonathan Neuschäfer Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220129115228.2257310-2-j.neuschaefer@gmx.net Signed-off-by: Joel Stanley --- .../devicetree/bindings/arm/npcm/nuvoton,gcr.yaml | 48 ++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml b/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml new file mode 100644 index 000000000000..fcb211add7d3 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/npcm/nuvoton,gcr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Global Control Registers block in Nuvoton SoCs + +maintainers: + - Jonathan Neuschäfer + +description: + The Global Control Registers (GCR) are a block of registers in Nuvoton SoCs + that expose misc functionality such as chip model and version information or + pinmux settings. + +properties: + compatible: + items: + - enum: + - nuvoton,wpcm450-gcr + - nuvoton,npcm750-gcr + - const: syscon + - const: simple-mfd + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: + type: object + +examples: + - | + gcr: syscon@800000 { + compatible = "nuvoton,npcm750-gcr", "syscon", "simple-mfd"; + reg = <0x800000 0x1000>; + + mux-controller { + compatible = "mmio-mux"; + #mux-control-cells = <1>; + mux-reg-masks = <0x38 0x07>; + idle-states = <2>; + }; + }; -- cgit From 9c02d4011e92b92aa008d6907216a8e501b0443a Mon Sep 17 00:00:00 2001 From: Jarkko Nikula Date: Fri, 11 Feb 2022 17:00:01 +0200 Subject: i2c: i801: Add support for Intel Raptor Lake PCH-S Add SMBus PCI ID on Intel Raptor Lake PCH-S. Signed-off-by: Jarkko Nikula Reviewed-by: Jean Delvare Signed-off-by: Wolfram Sang --- Documentation/i2c/busses/i2c-i801.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-i801.rst b/Documentation/i2c/busses/i2c-i801.rst index 42bbdd6e7fd8..cad59170b2ad 100644 --- a/Documentation/i2c/busses/i2c-i801.rst +++ b/Documentation/i2c/busses/i2c-i801.rst @@ -45,6 +45,7 @@ Supported adapters: * Intel Jasper Lake (SOC) * Intel Emmitsburg (PCH) * Intel Alder Lake (PCH) + * Intel Raptor Lake (PCH) Datasheets: Publicly available at the Intel website -- cgit From 83aa52ffed5d35a08e24452d0471e1684075cdf8 Mon Sep 17 00:00:00 2001 From: Fenghua Yu Date: Mon, 7 Feb 2022 15:02:54 -0800 Subject: Documentation/x86: Update documentation for SVA (Shared Virtual Addressing) Adjust the documentation to the new way how a PASID is being allocated, freed and fixed up. Based on a patch by Ashok Raj [ bp: Massage commit message, fix htmldocs build warning ] Signed-off-by: Fenghua Yu Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Acked-by: Thomas Gleixner Link: https://lore.kernel.org/r/20220207230254.3342514-12-fenghua.yu@intel.com --- Documentation/x86/sva.rst | 53 ++++++++++++++++++++++++++++++++++++----------- 1 file changed, 41 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/x86/sva.rst b/Documentation/x86/sva.rst index 076efd51ef1f..2e9b8b0f9a0f 100644 --- a/Documentation/x86/sva.rst +++ b/Documentation/x86/sva.rst @@ -104,18 +104,47 @@ The MSR must be configured on each logical CPU before any application thread can interact with a device. Threads that belong to the same process share the same page tables, thus the same MSR value. -PASID is cleared when a process is created. The PASID allocation and MSR -programming may occur long after a process and its threads have been created. -One thread must call iommu_sva_bind_device() to allocate the PASID for the -process. If a thread uses ENQCMD without the MSR first being populated, a #GP -will be raised. The kernel will update the PASID MSR with the PASID for all -threads in the process. A single process PASID can be used simultaneously -with multiple devices since they all share the same address space. - -One thread can call iommu_sva_unbind_device() to free the allocated PASID. -The kernel will clear the PASID MSR for all threads belonging to the process. - -New threads inherit the MSR value from the parent. +PASID Life Cycle Management +=========================== + +PASID is initialized as INVALID_IOASID (-1) when a process is created. + +Only processes that access SVA-capable devices need to have a PASID +allocated. This allocation happens when a process opens/binds an SVA-capable +device but finds no PASID for this process. Subsequent binds of the same, or +other devices will share the same PASID. + +Although the PASID is allocated to the process by opening a device, +it is not active in any of the threads of that process. It's loaded to the +IA32_PASID MSR lazily when a thread tries to submit a work descriptor +to a device using the ENQCMD. + +That first access will trigger a #GP fault because the IA32_PASID MSR +has not been initialized with the PASID value assigned to the process +when the device was opened. The Linux #GP handler notes that a PASID has +been allocated for the process, and so initializes the IA32_PASID MSR +and returns so that the ENQCMD instruction is re-executed. + +On fork(2) or exec(2) the PASID is removed from the process as it no +longer has the same address space that it had when the device was opened. + +On clone(2) the new task shares the same address space, so will be +able to use the PASID allocated to the process. The IA32_PASID is not +preemptively initialized as the PASID value might not be allocated yet or +the kernel does not know whether this thread is going to access the device +and the cleared IA32_PASID MSR reduces context switch overhead by xstate +init optimization. Since #GP faults have to be handled on any threads that +were created before the PASID was assigned to the mm of the process, newly +created threads might as well be treated in a consistent way. + +Due to complexity of freeing the PASID and clearing all IA32_PASID MSRs in +all threads in unbind, free the PASID lazily only on mm exit. + +If a process does a close(2) of the device file descriptor and munmap(2) +of the device MMIO portal, then the driver will unbind the device. The +PASID is still marked VALID in the PASID_MSR for any threads in the +process that accessed the device. But this is harmless as without the +MMIO portal they cannot submit new work to the device. Relationships ============= -- cgit From 69591a402d18fd60c8c95b061279f17bf0b78129 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Tue, 15 Feb 2022 09:10:47 +0100 Subject: block: remove biodoc.rst This document is completely out of date and extremely misleading. In general the existing kerneldoc comment serve as a much better documentation of the still existing functionality, while the history blurbs are pretty much irrelevant today. Signed-off-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Link: https://lore.kernel.org/r/20220215081047.3693582-1-hch@lst.de Signed-off-by: Jens Axboe --- Documentation/block/biodoc.rst | 1155 ---------------------------------------- Documentation/block/index.rst | 1 - 2 files changed, 1156 deletions(-) delete mode 100644 Documentation/block/biodoc.rst (limited to 'Documentation') diff --git a/Documentation/block/biodoc.rst b/Documentation/block/biodoc.rst deleted file mode 100644 index fdebc0fd8468..000000000000 --- a/Documentation/block/biodoc.rst +++ /dev/null @@ -1,1155 +0,0 @@ -===================================================== -Notes on the Generic Block Layer Rewrite in Linux 2.5 -===================================================== - -.. note:: - - It seems that there are lot of outdated stuff here. This seems - to be written somewhat as a task list. Yet, eventually, something - here might still be useful. - -Notes Written on Jan 15, 2002: - - - Jens Axboe - - Suparna Bhattacharya - -Last Updated May 2, 2002 - -September 2003: Updated I/O Scheduler portions - - Nick Piggin - -Introduction -============ - -These are some notes describing some aspects of the 2.5 block layer in the -context of the bio rewrite. The idea is to bring out some of the key -changes and a glimpse of the rationale behind those changes. - -Please mail corrections & suggestions to suparna@in.ibm.com. - -Credits -======= - -2.5 bio rewrite: - - Jens Axboe - -Many aspects of the generic block layer redesign were driven by and evolved -over discussions, prior patches and the collective experience of several -people. See sections 8 and 9 for a list of some related references. - -The following people helped with review comments and inputs for this -document: - - - Christoph Hellwig - - Arjan van de Ven - - Randy Dunlap - - Andre Hedrick - -The following people helped with fixes/contributions to the bio patches -while it was still work-in-progress: - - - David S. Miller - - -.. Description of Contents: - - 1. Scope for tuning of logic to various needs - 1.1 Tuning based on device or low level driver capabilities - - Per-queue parameters - - Highmem I/O support - - I/O scheduler modularization - 1.2 Tuning based on high level requirements/capabilities - 1.2.1 Request Priority/Latency - 1.3 Direct access/bypass to lower layers for diagnostics and special - device operations - 1.3.1 Pre-built commands - 2. New flexible and generic but minimalist i/o structure or descriptor - (instead of using buffer heads at the i/o layer) - 2.1 Requirements/Goals addressed - 2.2 The bio struct in detail (multi-page io unit) - 2.3 Changes in the request structure - 3. Using bios - 3.1 Setup/teardown (allocation, splitting) - 3.2 Generic bio helper routines - 3.2.1 Traversing segments and completion units in a request - 3.2.2 Setting up DMA scatterlists - 3.2.3 I/O completion - 3.2.4 Implications for drivers that do not interpret bios (don't handle - multiple segments) - 3.3 I/O submission - 4. The I/O scheduler - 5. Scalability related changes - 5.1 Granular locking: Removal of io_request_lock - 5.2 Prepare for transition to 64 bit sector_t - 6. Other Changes/Implications - 6.1 Partition re-mapping handled by the generic block layer - 7. A few tips on migration of older drivers - 8. A list of prior/related/impacted patches/ideas - 9. Other References/Discussion Threads - - -Bio Notes -========= - -Let us discuss the changes in the context of how some overall goals for the -block layer are addressed. - -1. Scope for tuning the generic logic to satisfy various requirements -===================================================================== - -The block layer design supports adaptable abstractions to handle common -processing with the ability to tune the logic to an appropriate extent -depending on the nature of the device and the requirements of the caller. -One of the objectives of the rewrite was to increase the degree of tunability -and to enable higher level code to utilize underlying device/driver -capabilities to the maximum extent for better i/o performance. This is -important especially in the light of ever improving hardware capabilities -and application/middleware software designed to take advantage of these -capabilities. - -1.1 Tuning based on low level device / driver capabilities ----------------------------------------------------------- - -Sophisticated devices with large built-in caches, intelligent i/o scheduling -optimizations, high memory DMA support, etc may find some of the -generic processing an overhead, while for less capable devices the -generic functionality is essential for performance or correctness reasons. -Knowledge of some of the capabilities or parameters of the device should be -used at the generic block layer to take the right decisions on -behalf of the driver. - -How is this achieved ? - -Tuning at a per-queue level: - -i. Per-queue limits/values exported to the generic layer by the driver - -Various parameters that the generic i/o scheduler logic uses are set at -a per-queue level (e.g maximum request size, maximum number of segments in -a scatter-gather list, logical block size) - -Some parameters that were earlier available as global arrays indexed by -major/minor are now directly associated with the queue. Some of these may -move into the block device structure in the future. Some characteristics -have been incorporated into a queue flags field rather than separate fields -in themselves. There are blk_queue_xxx functions to set the parameters, -rather than update the fields directly - -Some new queue property settings: - - blk_queue_bounce_limit(q, u64 dma_address) - Enable I/O to highmem pages, dma_address being the - limit. No highmem default. - - blk_queue_max_sectors(q, max_sectors) - Sets two variables that limit the size of the request. - - - The request queue's max_sectors, which is a soft size in - units of 512 byte sectors, and could be dynamically varied - by the core kernel. - - - The request queue's max_hw_sectors, which is a hard limit - and reflects the maximum size request a driver can handle - in units of 512 byte sectors. - - The default for both max_sectors and max_hw_sectors is - 255. The upper limit of max_sectors is 1024. - - blk_queue_max_phys_segments(q, max_segments) - Maximum physical segments you can handle in a request. 128 - default (driver limit). (See 3.2.2) - - blk_queue_max_hw_segments(q, max_segments) - Maximum dma segments the hardware can handle in a request. 128 - default (host adapter limit, after dma remapping). - (See 3.2.2) - - blk_queue_max_segment_size(q, max_seg_size) - Maximum size of a clustered segment, 64kB default. - - blk_queue_logical_block_size(q, logical_block_size) - Lowest possible sector size that the hardware can operate - on, 512 bytes default. - -New queue flags: - - - QUEUE_FLAG_CLUSTER (see 3.2.2) - - QUEUE_FLAG_QUEUED (see 3.2.4) - - -ii. High-mem i/o capabilities are now considered the default - -The generic bounce buffer logic, present in 2.4, where the block layer would -by default copyin/out i/o requests on high-memory buffers to low-memory buffers -assuming that the driver wouldn't be able to handle it directly, has been -changed in 2.5. The bounce logic is now applied only for memory ranges -for which the device cannot handle i/o. A driver can specify this by -setting the queue bounce limit for the request queue for the device -(blk_queue_bounce_limit()). This avoids the inefficiencies of the copyin/out -where a device is capable of handling high memory i/o. - -In order to enable high-memory i/o where the device is capable of supporting -it, the pci dma mapping routines and associated data structures have now been -modified to accomplish a direct page -> bus translation, without requiring -a virtual address mapping (unlike the earlier scheme of virtual address --> bus translation). So this works uniformly for high-memory pages (which -do not have a corresponding kernel virtual address space mapping) and -low-memory pages. - -Note: Please refer to Documentation/core-api/dma-api-howto.rst for a discussion -on PCI high mem DMA aspects and mapping of scatter gather lists, and support -for 64 bit PCI. - -Special handling is required only for cases where i/o needs to happen on -pages at physical memory addresses beyond what the device can support. In these -cases, a bounce bio representing a buffer from the supported memory range -is used for performing the i/o with copyin/copyout as needed depending on -the type of the operation. For example, in case of a read operation, the -data read has to be copied to the original buffer on i/o completion, so a -callback routine is set up to do this, while for write, the data is copied -from the original buffer to the bounce buffer prior to issuing the -operation. Since an original buffer may be in a high memory area that's not -mapped in kernel virtual addr, a kmap operation may be required for -performing the copy, and special care may be needed in the completion path -as it may not be in irq context. Special care is also required (by way of -GFP flags) when allocating bounce buffers, to avoid certain highmem -deadlock possibilities. - -It is also possible that a bounce buffer may be allocated from high-memory -area that's not mapped in kernel virtual addr, but within the range that the -device can use directly; so the bounce page may need to be kmapped during -copy operations. [Note: This does not hold in the current implementation, -though] - -There are some situations when pages from high memory may need to -be kmapped, even if bounce buffers are not necessary. For example a device -may need to abort DMA operations and revert to PIO for the transfer, in -which case a virtual mapping of the page is required. For SCSI it is also -done in some scenarios where the low level driver cannot be trusted to -handle a single sg entry correctly. The driver is expected to perform the -kmaps as needed on such occasions as appropriate. A driver could also use -the blk_queue_bounce() routine on its own to bounce highmem i/o to low -memory for specific requests if so desired. - -iii. The i/o scheduler algorithm itself can be replaced/set as appropriate - -As in 2.4, it is possible to plugin a brand new i/o scheduler for a particular -queue or pick from (copy) existing generic schedulers and replace/override -certain portions of it. The 2.5 rewrite provides improved modularization -of the i/o scheduler. There are more pluggable callbacks, e.g for init, -add request, extract request, which makes it possible to abstract specific -i/o scheduling algorithm aspects and details outside of the generic loop. -It also makes it possible to completely hide the implementation details of -the i/o scheduler from block drivers. - -I/O scheduler wrappers are to be used instead of accessing the queue directly. -See section 4. The I/O scheduler for details. - -1.2 Tuning Based on High level code capabilities ------------------------------------------------- - -i. Application capabilities for raw i/o - -This comes from some of the high-performance database/middleware -requirements where an application prefers to make its own i/o scheduling -decisions based on an understanding of the access patterns and i/o -characteristics - -ii. High performance filesystems or other higher level kernel code's -capabilities - -Kernel components like filesystems could also take their own i/o scheduling -decisions for optimizing performance. Journalling filesystems may need -some control over i/o ordering. - -What kind of support exists at the generic block layer for this ? - -The flags and rw fields in the bio structure can be used for some tuning -from above e.g indicating that an i/o is just a readahead request, or priority -settings (currently unused). As far as user applications are concerned they -would need an additional mechanism either via open flags or ioctls, or some -other upper level mechanism to communicate such settings to block. - -1.2.1 Request Priority/Latency -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Todo/Under discussion:: - - Arjan's proposed request priority scheme allows higher levels some broad - control (high/med/low) over the priority of an i/o request vs other pending - requests in the queue. For example it allows reads for bringing in an - executable page on demand to be given a higher priority over pending write - requests which haven't aged too much on the queue. Potentially this priority - could even be exposed to applications in some manner, providing higher level - tunability. Time based aging avoids starvation of lower priority - requests. Some bits in the bi_opf flags field in the bio structure are - intended to be used for this priority information. - - -1.3 Direct Access to Low level Device/Driver Capabilities (Bypass mode) ------------------------------------------------------------------------ - -(e.g Diagnostics, Systems Management) - -There are situations where high-level code needs to have direct access to -the low level device capabilities or requires the ability to issue commands -to the device bypassing some of the intermediate i/o layers. -These could, for example, be special control commands issued through ioctl -interfaces, or could be raw read/write commands that stress the drive's -capabilities for certain kinds of fitness tests. Having direct interfaces at -multiple levels without having to pass through upper layers makes -it possible to perform bottom up validation of the i/o path, layer by -layer, starting from the media. - -The normal i/o submission interfaces, e.g submit_bio, could be bypassed -for specially crafted requests which such ioctl or diagnostics -interfaces would typically use, and the elevator add_request routine -can instead be used to directly insert such requests in the queue or preferably -the blk_do_rq routine can be used to place the request on the queue and -wait for completion. Alternatively, sometimes the caller might just -invoke a lower level driver specific interface with the request as a -parameter. - -If the request is a means for passing on special information associated with -the command, then such information is associated with the request->special -field (rather than misuse the request->buffer field which is meant for the -request data buffer's virtual mapping). - -For passing request data, the caller must build up a bio descriptor -representing the concerned memory buffer if the underlying driver interprets -bio segments or uses the block layer end*request* functions for i/o -completion. Alternatively one could directly use the request->buffer field to -specify the virtual address of the buffer, if the driver expects buffer -addresses passed in this way and ignores bio entries for the request type -involved. In the latter case, the driver would modify and manage the -request->buffer, request->sector and request->nr_sectors or -request->current_nr_sectors fields itself rather than using the block layer -end_request or end_that_request_first completion interfaces. -(See 2.3 or Documentation/block/request.rst for a brief explanation of -the request structure fields) - -:: - - [TBD: end_that_request_last should be usable even in this case; - Perhaps an end_that_direct_request_first routine could be implemented to make - handling direct requests easier for such drivers; Also for drivers that - expect bios, a helper function could be provided for setting up a bio - corresponding to a data buffer] - - - - - -1.3.1 Pre-built Commands -^^^^^^^^^^^^^^^^^^^^^^^^ - -A request can be created with a pre-built custom command to be sent directly -to the device. The cmd block in the request structure has room for filling -in the command bytes. (i.e rq->cmd is now 16 bytes in size, and meant for -command pre-building, and the type of the request is now indicated -through rq->flags instead of via rq->cmd) - -The request structure flags can be set up to indicate the type of request -in such cases (REQ_PC: direct packet command passed to driver, REQ_BLOCK_PC: -packet command issued via blk_do_rq, REQ_SPECIAL: special request). - -It can help to pre-build device commands for requests in advance. -Drivers can now specify a request prepare function (q->prep_rq_fn) that the -block layer would invoke to pre-build device commands for a given request, -or perform other preparatory processing for the request. This is routine is -called by elv_next_request(), i.e. typically just before servicing a request. -(The prepare function would not be called for requests that have RQF_DONTPREP -enabled) - -Aside: - Pre-building could possibly even be done early, i.e before placing the - request on the queue, rather than construct the command on the fly in the - driver while servicing the request queue when it may affect latencies in - interrupt context or responsiveness in general. One way to add early - pre-building would be to do it whenever we fail to merge on a request. - Now REQ_NOMERGE is set in the request flags to skip this one in the future, - which means that it will not change before we feed it to the device. So - the pre-builder hook can be invoked there. - - -2. Flexible and generic but minimalist i/o structure/descriptor -=============================================================== - -2.1 Reason for a new structure and requirements addressed ---------------------------------------------------------- - -Prior to 2.5, buffer heads were used as the unit of i/o at the generic block -layer, and the low level request structure was associated with a chain of -buffer heads for a contiguous i/o request. This led to certain inefficiencies -when it came to large i/o requests and readv/writev style operations, as it -forced such requests to be broken up into small chunks before being passed -on to the generic block layer, only to be merged by the i/o scheduler -when the underlying device was capable of handling the i/o in one shot. -Also, using the buffer head as an i/o structure for i/os that didn't originate -from the buffer cache unnecessarily added to the weight of the descriptors -which were generated for each such chunk. - -The following were some of the goals and expectations considered in the -redesign of the block i/o data structure in 2.5. - -1. Should be appropriate as a descriptor for both raw and buffered i/o - - avoid cache related fields which are irrelevant in the direct/page i/o path, - or filesystem block size alignment restrictions which may not be relevant - for raw i/o. -2. Ability to represent high-memory buffers (which do not have a virtual - address mapping in kernel address space). -3. Ability to represent large i/os w/o unnecessarily breaking them up (i.e - greater than PAGE_SIZE chunks in one shot) -4. At the same time, ability to retain independent identity of i/os from - different sources or i/o units requiring individual completion (e.g. for - latency reasons) -5. Ability to represent an i/o involving multiple physical memory segments - (including non-page aligned page fragments, as specified via readv/writev) - without unnecessarily breaking it up, if the underlying device is capable of - handling it. -6. Preferably should be based on a memory descriptor structure that can be - passed around different types of subsystems or layers, maybe even - networking, without duplication or extra copies of data/descriptor fields - themselves in the process -7. Ability to handle the possibility of splits/merges as the structure passes - through layered drivers (lvm, md, evms), with minimal overhead. - -The solution was to define a new structure (bio) for the block layer, -instead of using the buffer head structure (bh) directly, the idea being -avoidance of some associated baggage and limitations. The bio structure -is uniformly used for all i/o at the block layer ; it forms a part of the -bh structure for buffered i/o, and in the case of raw/direct i/o kiobufs are -mapped to bio structures. - -2.2 The bio struct ------------------- - -The bio structure uses a vector representation pointing to an array of tuples -of to describe the i/o buffer, and has various other -fields describing i/o parameters and state that needs to be maintained for -performing the i/o. - -Notice that this representation means that a bio has no virtual address -mapping at all (unlike buffer heads). - -:: - - struct bio_vec { - struct page *bv_page; - unsigned short bv_len; - unsigned short bv_offset; - }; - - /* - * main unit of I/O for the block layer and lower layers (ie drivers) - */ - struct bio { - struct bio *bi_next; /* request queue link */ - struct block_device *bi_bdev; /* target device */ - unsigned long bi_flags; /* status, command, etc */ - unsigned long bi_opf; /* low bits: r/w, high: priority */ - - unsigned int bi_vcnt; /* how may bio_vec's */ - struct bvec_iter bi_iter; /* current index into bio_vec array */ - - unsigned int bi_size; /* total size in bytes */ - unsigned short bi_hw_segments; /* segments after DMA remapping */ - unsigned int bi_max; /* max bio_vecs we can hold - used as index into pool */ - struct bio_vec *bi_io_vec; /* the actual vec list */ - bio_end_io_t *bi_end_io; /* bi_end_io (bio) */ - atomic_t bi_cnt; /* pin count: free when it hits zero */ - void *bi_private; - }; - -With this multipage bio design: - -- Large i/os can be sent down in one go using a bio_vec list consisting - of an array of fragments (similar to the way fragments - are represented in the zero-copy network code) -- Splitting of an i/o request across multiple devices (as in the case of - lvm or raid) is achieved by cloning the bio (where the clone points to - the same bi_io_vec array, but with the index and size accordingly modified) -- A linked list of bios is used as before for unrelated merges [#]_ - this - avoids reallocs and makes independent completions easier to handle. -- Code that traverses the req list can find all the segments of a bio - by using rq_for_each_segment. This handles the fact that a request - has multiple bios, each of which can have multiple segments. -- Drivers which can't process a large bio in one shot can use the bi_iter - field to keep track of the next bio_vec entry to process. - (e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE) - [TBD: Should preferably also have a bi_voffset and bi_vlen to avoid modifying - bi_offset an len fields] - -.. [#] - - unrelated merges -- a request ends up containing two or more bios that - didn't originate from the same place. - -bi_end_io() i/o callback gets called on i/o completion of the entire bio. - -At a lower level, drivers build a scatter gather list from the merged bios. -The scatter gather list is in the form of an array of -entries with their corresponding dma address mappings filled in at the -appropriate time. As an optimization, contiguous physical pages can be -covered by a single entry where refers to the first page and -covers the range of pages (up to 16 contiguous pages could be covered this -way). There is a helper routine (blk_rq_map_sg) which drivers can use to build -the sg list. - -Note: Right now the only user of bios with more than one page is ll_rw_kio, -which in turn means that only raw I/O uses it (direct i/o may not work -right now). The intent however is to enable clustering of pages etc to -become possible. The pagebuf abstraction layer from SGI also uses multi-page -bios, but that is currently not included in the stock development kernels. -The same is true of Andrew Morton's work-in-progress multipage bio writeout -and readahead patches. - -2.3 Changes in the Request Structure ------------------------------------- - -The request structure is the structure that gets passed down to low level -drivers. The block layer make_request function builds up a request structure, -places it on the queue and invokes the drivers request_fn. The driver makes -use of block layer helper routine elv_next_request to pull the next request -off the queue. Control or diagnostic functions might bypass block and directly -invoke underlying driver entry points passing in a specially constructed -request structure. - -Only some relevant fields (mainly those which changed or may be referred -to in some of the discussion here) are listed below, not necessarily in -the order in which they occur in the structure (see include/linux/blkdev.h) -Refer to Documentation/block/request.rst for details about all the request -structure fields and a quick reference about the layers which are -supposed to use or modify those fields:: - - struct request { - struct list_head queuelist; /* Not meant to be directly accessed by - the driver. - Used by q->elv_next_request_fn - rq->queue is gone - */ - . - . - unsigned char cmd[16]; /* prebuilt command data block */ - unsigned long flags; /* also includes earlier rq->cmd settings */ - . - . - sector_t sector; /* this field is now of type sector_t instead of int - preparation for 64 bit sectors */ - . - . - - /* Number of scatter-gather DMA addr+len pairs after - * physical address coalescing is performed. - */ - unsigned short nr_phys_segments; - - /* Number of scatter-gather addr+len pairs after - * physical and DMA remapping hardware coalescing is performed. - * This is the number of scatter-gather entries the driver - * will actually have to deal with after DMA mapping is done. - */ - unsigned short nr_hw_segments; - - /* Various sector counts */ - unsigned long nr_sectors; /* no. of sectors left: driver modifiable */ - unsigned long hard_nr_sectors; /* block internal copy of above */ - unsigned int current_nr_sectors; /* no. of sectors left in the - current segment:driver modifiable */ - unsigned long hard_cur_sectors; /* block internal copy of the above */ - . - . - int tag; /* command tag associated with request */ - void *special; /* same as before */ - char *buffer; /* valid only for low memory buffers up to - current_nr_sectors */ - . - . - struct bio *bio, *biotail; /* bio list instead of bh */ - struct request_list *rl; - } - -See the req_ops and req_flag_bits definitions for an explanation of the various -flags available. Some bits are used by the block layer or i/o scheduler. - -The behaviour of the various sector counts are almost the same as before, -except that since we have multi-segment bios, current_nr_sectors refers -to the numbers of sectors in the current segment being processed which could -be one of the many segments in the current bio (i.e i/o completion unit). -The nr_sectors value refers to the total number of sectors in the whole -request that remain to be transferred (no change). The purpose of the -hard_xxx values is for block to remember these counts every time it hands -over the request to the driver. These values are updated by block on -end_that_request_first, i.e. every time the driver completes a part of the -transfer and invokes block end*request helpers to mark this. The -driver should not modify these values. The block layer sets up the -nr_sectors and current_nr_sectors fields (based on the corresponding -hard_xxx values and the number of bytes transferred) and updates it on -every transfer that invokes end_that_request_first. It does the same for the -buffer, bio, bio->bi_iter fields too. - -The buffer field is just a virtual address mapping of the current segment -of the i/o buffer in cases where the buffer resides in low-memory. For high -memory i/o, this field is not valid and must not be used by drivers. - -Code that sets up its own request structures and passes them down to -a driver needs to be careful about interoperation with the block layer helper -functions which the driver uses. (Section 1.3) - -3. Using bios -============= - -3.1 Setup/Teardown ------------------- - -There are routines for managing the allocation, and reference counting, and -freeing of bios (bio_alloc, bio_get, bio_put). - -This makes use of Ingo Molnar's mempool implementation, which enables -subsystems like bio to maintain their own reserve memory pools for guaranteed -deadlock-free allocations during extreme VM load. For example, the VM -subsystem makes use of the block layer to writeout dirty pages in order to be -able to free up memory space, a case which needs careful handling. The -allocation logic draws from the preallocated emergency reserve in situations -where it cannot allocate through normal means. If the pool is empty and it -can wait, then it would trigger action that would help free up memory or -replenish the pool (without deadlocking) and wait for availability in the pool. -If it is in IRQ context, and hence not in a position to do this, allocation -could fail if the pool is empty. In general mempool always first tries to -perform allocation without having to wait, even if it means digging into the -pool as long it is not less that 50% full. - -On a free, memory is released to the pool or directly freed depending on -the current availability in the pool. The mempool interface lets the -subsystem specify the routines to be used for normal alloc and free. In the -case of bio, these routines make use of the standard slab allocator. - -The caller of bio_alloc is expected to taken certain steps to avoid -deadlocks, e.g. avoid trying to allocate more memory from the pool while -already holding memory obtained from the pool. - -:: - - [TBD: This is a potential issue, though a rare possibility - in the bounce bio allocation that happens in the current code, since - it ends up allocating a second bio from the same pool while - holding the original bio ] - -Memory allocated from the pool should be released back within a limited -amount of time (in the case of bio, that would be after the i/o is completed). -This ensures that if part of the pool has been used up, some work (in this -case i/o) must already be in progress and memory would be available when it -is over. If allocating from multiple pools in the same code path, the order -or hierarchy of allocation needs to be consistent, just the way one deals -with multiple locks. - -The bio_alloc routine also needs to allocate the bio_vec_list (bvec_alloc()) -for a non-clone bio. There are the 6 pools setup for different size biovecs, -so bio_alloc(gfp_mask, nr_iovecs) will allocate a vec_list of the -given size from these slabs. - -The bio_get() routine may be used to hold an extra reference on a bio prior -to i/o submission, if the bio fields are likely to be accessed after the -i/o is issued (since the bio may otherwise get freed in case i/o completion -happens in the meantime). - -3.2 Generic bio helper Routines -------------------------------- - -3.2.1 Traversing segments and completion units in a request -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The macro rq_for_each_segment() should be used for traversing the bios -in the request list (drivers should avoid directly trying to do it -themselves). Using these helpers should also make it easier to cope -with block changes in the future. - -:: - - struct req_iterator iter; - rq_for_each_segment(bio_vec, rq, iter) - /* bio_vec is now current segment */ - -I/O completion callbacks are per-bio rather than per-segment, so drivers -that traverse bio chains on completion need to keep that in mind. Drivers -which don't make a distinction between segments and completion units would -need to be reorganized to support multi-segment bios. - -3.2.2 Setting up DMA scatterlists -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The blk_rq_map_sg() helper routine would be used for setting up scatter -gather lists from a request, so a driver need not do it on its own. - - nr_segments = blk_rq_map_sg(q, rq, scatterlist); - -The helper routine provides a level of abstraction which makes it easier -to modify the internals of request to scatterlist conversion down the line -without breaking drivers. The blk_rq_map_sg routine takes care of several -things like collapsing physically contiguous segments (if QUEUE_FLAG_CLUSTER -is set) and correct segment accounting to avoid exceeding the limits which -the i/o hardware can handle, based on various queue properties. - -- Prevents a clustered segment from crossing a 4GB mem boundary -- Avoids building segments that would exceed the number of physical - memory segments that the driver can handle (phys_segments) and the - number that the underlying hardware can handle at once, accounting for - DMA remapping (hw_segments) (i.e. IOMMU aware limits). - -Routines which the low level driver can use to set up the segment limits: - -blk_queue_max_hw_segments() : Sets an upper limit of the maximum number of -hw data segments in a request (i.e. the maximum number of address/length -pairs the host adapter can actually hand to the device at once) - -blk_queue_max_phys_segments() : Sets an upper limit on the maximum number -of physical data segments in a request (i.e. the largest sized scatter list -a driver could handle) - -3.2.3 I/O completion -^^^^^^^^^^^^^^^^^^^^ - -The existing generic block layer helper routines end_request, -end_that_request_first and end_that_request_last can be used for i/o -completion (and setting things up so the rest of the i/o or the next -request can be kicked of) as before. With the introduction of multi-page -bio support, end_that_request_first requires an additional argument indicating -the number of sectors completed. - -3.2.4 Implications for drivers that do not interpret bios -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -(don't handle multiple segments) - -Drivers that do not interpret bios e.g those which do not handle multiple -segments and do not support i/o into high memory addresses (require bounce -buffers) and expect only virtually mapped buffers, can access the rq->buffer -field. As before the driver should use current_nr_sectors to determine the -size of remaining data in the current segment (that is the maximum it can -transfer in one go unless it interprets segments), and rely on the block layer -end_request, or end_that_request_first/last to take care of all accounting -and transparent mapping of the next bio segment when a segment boundary -is crossed on completion of a transfer. (The end*request* functions should -be used if only if the request has come down from block/bio path, not for -direct access requests which only specify rq->buffer without a valid rq->bio) - -3.3 I/O Submission ------------------- - -The routine submit_bio() is used to submit a single io. Higher level i/o -routines make use of this: - -(a) Buffered i/o: - -The routine submit_bh() invokes submit_bio() on a bio corresponding to the -bh, allocating the bio if required. ll_rw_block() uses submit_bh() as before. - -(b) Kiobuf i/o (for raw/direct i/o): - -The ll_rw_kio() routine breaks up the kiobuf into page sized chunks and -maps the array to one or more multi-page bios, issuing submit_bio() to -perform the i/o on each of these. - -The embedded bh array in the kiobuf structure has been removed and no -preallocation of bios is done for kiobufs. [The intent is to remove the -blocks array as well, but it's currently in there to kludge around direct i/o.] -Thus kiobuf allocation has switched back to using kmalloc rather than vmalloc. - -Todo/Observation: - - A single kiobuf structure is assumed to correspond to a contiguous range - of data, so brw_kiovec() invokes ll_rw_kio for each kiobuf in a kiovec. - So right now it wouldn't work for direct i/o on non-contiguous blocks. - This is to be resolved. The eventual direction is to replace kiobuf - by kvec's. - - Badari Pulavarty has a patch to implement direct i/o correctly using - bio and kvec. - - -(c) Page i/o: - -Todo/Under discussion: - - Andrew Morton's multi-page bio patches attempt to issue multi-page - writeouts (and reads) from the page cache, by directly building up - large bios for submission completely bypassing the usage of buffer - heads. This work is still in progress. - - Christoph Hellwig had some code that uses bios for page-io (rather than - bh). This isn't included in bio as yet. Christoph was also working on a - design for representing virtual/real extents as an entity and modifying - some of the address space ops interfaces to utilize this abstraction rather - than buffer_heads. (This is somewhat along the lines of the SGI XFS pagebuf - abstraction, but intended to be as lightweight as possible). - -(d) Direct access i/o: - -Direct access requests that do not contain bios would be submitted differently -as discussed earlier in section 1.3. - -Aside: - - Kvec i/o: - - Ben LaHaise's aio code uses a slightly different structure instead - of kiobufs, called a kvec_cb. This contains an array of - tuples (very much like the networking code), together with a callback function - and data pointer. This is embedded into a brw_cb structure when passed - to brw_kvec_async(). - - Now it should be possible to directly map these kvecs to a bio. Just as while - cloning, in this case rather than PRE_BUILT bio_vecs, we set the bi_io_vec - array pointer to point to the veclet array in kvecs. - - TBD: In order for this to work, some changes are needed in the way multi-page - bios are handled today. The values of the tuples in such a vector passed in - from higher level code should not be modified by the block layer in the course - of its request processing, since that would make it hard for the higher layer - to continue to use the vector descriptor (kvec) after i/o completes. Instead, - all such transient state should either be maintained in the request structure, - and passed on in some way to the endio completion routine. - - -4. The I/O scheduler -==================== - -I/O scheduler, a.k.a. elevator, is implemented in two layers. Generic dispatch -queue and specific I/O schedulers. Unless stated otherwise, elevator is used -to refer to both parts and I/O scheduler to specific I/O schedulers. - -Block layer implements generic dispatch queue in `block/*.c`. -The generic dispatch queue is responsible for requeueing, handling non-fs -requests and all other subtleties. - -Specific I/O schedulers are responsible for ordering normal filesystem -requests. They can also choose to delay certain requests to improve -throughput or whatever purpose. As the plural form indicates, there are -multiple I/O schedulers. They can be built as modules but at least one should -be built inside the kernel. Each queue can choose different one and can also -change to another one dynamically. - -A block layer call to the i/o scheduler follows the convention elv_xxx(). This -calls elevator_xxx_fn in the elevator switch (block/elevator.c). Oh, xxx -and xxx might not match exactly, but use your imagination. If an elevator -doesn't implement a function, the switch does nothing or some minimal house -keeping work. - -4.1. I/O scheduler API ----------------------- - -The functions an elevator may implement are: (* are mandatory) - -=============================== ================================================ -elevator_merge_fn called to query requests for merge with a bio - -elevator_merge_req_fn called when two requests get merged. the one - which gets merged into the other one will be - never seen by I/O scheduler again. IOW, after - being merged, the request is gone. - -elevator_merged_fn called when a request in the scheduler has been - involved in a merge. It is used in the deadline - scheduler for example, to reposition the request - if its sorting order has changed. - -elevator_allow_merge_fn called whenever the block layer determines - that a bio can be merged into an existing - request safely. The io scheduler may still - want to stop a merge at this point if it - results in some sort of conflict internally, - this hook allows it to do that. Note however - that two *requests* can still be merged at later - time. Currently the io scheduler has no way to - prevent that. It can only learn about the fact - from elevator_merge_req_fn callback. - -elevator_dispatch_fn* fills the dispatch queue with ready requests. - I/O schedulers are free to postpone requests by - not filling the dispatch queue unless @force - is non-zero. Once dispatched, I/O schedulers - are not allowed to manipulate the requests - - they belong to generic dispatch queue. - -elevator_add_req_fn* called to add a new request into the scheduler - -elevator_former_req_fn -elevator_latter_req_fn These return the request before or after the - one specified in disk sort order. Used by the - block layer to find merge possibilities. - -elevator_completed_req_fn called when a request is completed. - -elevator_set_req_fn -elevator_put_req_fn Must be used to allocate and free any elevator - specific storage for a request. - -elevator_activate_req_fn Called when device driver first sees a request. - I/O schedulers can use this callback to - determine when actual execution of a request - starts. -elevator_deactivate_req_fn Called when device driver decides to delay - a request by requeueing it. - -elevator_init_fn* -elevator_exit_fn Allocate and free any elevator specific storage - for a queue. -=============================== ================================================ - -4.2 Request flows seen by I/O schedulers ----------------------------------------- - -All requests seen by I/O schedulers strictly follow one of the following three -flows. - - set_req_fn -> - - i. add_req_fn -> (merged_fn ->)* -> dispatch_fn -> activate_req_fn -> - (deactivate_req_fn -> activate_req_fn ->)* -> completed_req_fn - ii. add_req_fn -> (merged_fn ->)* -> merge_req_fn - iii. [none] - - -> put_req_fn - -4.3 I/O scheduler implementation --------------------------------- - -The generic i/o scheduler algorithm attempts to sort/merge/batch requests for -optimal disk scan and request servicing performance (based on generic -principles and device capabilities), optimized for: - -i. improved throughput -ii. improved latency -iii. better utilization of h/w & CPU time - -Characteristics: - -i. Binary tree -AS and deadline i/o schedulers use red black binary trees for disk position -sorting and searching, and a fifo linked list for time-based searching. This -gives good scalability and good availability of information. Requests are -almost always dispatched in disk sort order, so a cache is kept of the next -request in sort order to prevent binary tree lookups. - -This arrangement is not a generic block layer characteristic however, so -elevators may implement queues as they please. - -ii. Merge hash -AS and deadline use a hash table indexed by the last sector of a request. This -enables merging code to quickly look up "back merge" candidates, even when -multiple I/O streams are being performed at once on one disk. - -"Front merges", a new request being merged at the front of an existing request, -are far less common than "back merges" due to the nature of most I/O patterns. -Front merges are handled by the binary trees in AS and deadline schedulers. - -iii. Plugging the queue to batch requests in anticipation of opportunities for - merge/sort optimizations - -Plugging is an approach that the current i/o scheduling algorithm resorts to so -that it collects up enough requests in the queue to be able to take -advantage of the sorting/merging logic in the elevator. If the -queue is empty when a request comes in, then it plugs the request queue -(sort of like plugging the bath tub of a vessel to get fluid to build up) -till it fills up with a few more requests, before starting to service -the requests. This provides an opportunity to merge/sort the requests before -passing them down to the device. There are various conditions when the queue is -unplugged (to open up the flow again), either through a scheduled task or -could be on demand. - -Aside: - This is kind of controversial territory, as it's not clear if plugging is - always the right thing to do. Devices typically have their own queues, - and allowing a big queue to build up in software, while letting the device be - idle for a while may not always make sense. The trick is to handle the fine - balance between when to plug and when to open up. Also now that we have - multi-page bios being queued in one shot, we may not need to wait to merge - a big request from the broken up pieces coming by. - -4.4 I/O contexts ----------------- - -I/O contexts provide a dynamically allocated per process data area. They may -be used in I/O schedulers, and in the block layer (could be used for IO statis, -priorities for example). See `*io_context` in block/ll_rw_blk.c, and as-iosched.c -for an example of usage in an i/o scheduler. - - -5. Scalability related changes -============================== - -5.1 Granular Locking: io_request_lock replaced by a per-queue lock ------------------------------------------------------------------- - -The global io_request_lock has been removed as of 2.5, to avoid -the scalability bottleneck it was causing, and has been replaced by more -granular locking. The request queue structure has a pointer to the -lock to be used for that queue. As a result, locking can now be -per-queue, with a provision for sharing a lock across queues if -necessary (e.g the scsi layer sets the queue lock pointers to the -corresponding adapter lock, which results in a per host locking -granularity). The locking semantics are the same, i.e. locking is -still imposed by the block layer, grabbing the lock before -request_fn execution which it means that lots of older drivers -should still be SMP safe. Drivers are free to drop the queue -lock themselves, if required. Drivers that explicitly used the -io_request_lock for serialization need to be modified accordingly. -Usually it's as easy as adding a global lock:: - - static DEFINE_SPINLOCK(my_driver_lock); - -and passing the address to that lock to blk_init_queue(). - -5.2 64 bit sector numbers (sector_t prepares for 64 bit support) ----------------------------------------------------------------- - -The sector number used in the bio structure has been changed to sector_t, -which could be defined as 64 bit in preparation for 64 bit sector support. - -6. Other Changes/Implications -============================= - -6.1 Partition re-mapping handled by the generic block layer ------------------------------------------------------------ - -In 2.5 some of the gendisk/partition related code has been reorganized. -Now the generic block layer performs partition-remapping early and thus -provides drivers with a sector number relative to whole device, rather than -having to take partition number into account in order to arrive at the true -sector number. The routine blk_partition_remap() is invoked by -submit_bio_noacct even before invoking the queue specific ->submit_bio, -so the i/o scheduler also gets to operate on whole disk sector numbers. This -should typically not require changes to block drivers, it just never gets -to invoke its own partition sector offset calculations since all bios -sent are offset from the beginning of the device. - - -7. A Few Tips on Migration of older drivers -=========================================== - -Old-style drivers that just use CURRENT and ignores clustered requests, -may not need much change. The generic layer will automatically handle -clustered requests, multi-page bios, etc for the driver. - -For a low performance driver or hardware that is PIO driven or just doesn't -support scatter-gather changes should be minimal too. - -The following are some points to keep in mind when converting old drivers -to bio. - -Drivers should use elv_next_request to pick up requests and are no longer -supposed to handle looping directly over the request list. -(struct request->queue has been removed) - -Now end_that_request_first takes an additional number_of_sectors argument. -It used to handle always just the first buffer_head in a request, now -it will loop and handle as many sectors (on a bio-segment granularity) -as specified. - -Now bh->b_end_io is replaced by bio->bi_end_io, but most of the time the -right thing to use is bio_endio(bio) instead. - -If the driver is dropping the io_request_lock from its request_fn strategy, -then it just needs to replace that with q->queue_lock instead. - -As described in Sec 1.1, drivers can set max sector size, max segment size -etc per queue now. Drivers that used to define their own merge functions i -to handle things like this can now just use the blk_queue_* functions at -blk_init_queue time. - -Drivers no longer have to map a {partition, sector offset} into the -correct absolute location anymore, this is done by the block layer, so -where a driver received a request ala this before:: - - rq->rq_dev = mk_kdev(3, 5); /* /dev/hda5 */ - rq->sector = 0; /* first sector on hda5 */ - -it will now see:: - - rq->rq_dev = mk_kdev(3, 0); /* /dev/hda */ - rq->sector = 123128; /* offset from start of disk */ - -As mentioned, there is no virtual mapping of a bio. For DMA, this is -not a problem as the driver probably never will need a virtual mapping. -Instead it needs a bus mapping (dma_map_page for a single segment or -use dma_map_sg for scatter gather) to be able to ship it to the driver. For -PIO drivers (or drivers that need to revert to PIO transfer once in a -while (IDE for example)), where the CPU is doing the actual data -transfer a virtual mapping is needed. If the driver supports highmem I/O, -(Sec 1.1, (ii) ) it needs to use kmap_atomic or similar to temporarily map -a bio into the virtual address space. - - -8. Prior/Related/Impacted patches -================================= - -8.1. Earlier kiobuf patches (sct/axboe/chait/hch/mkp) ------------------------------------------------------ - -- orig kiobuf & raw i/o patches (now in 2.4 tree) -- direct kiobuf based i/o to devices (no intermediate bh's) -- page i/o using kiobuf -- kiobuf splitting for lvm (mkp) -- elevator support for kiobuf request merging (axboe) - -8.2. Zero-copy networking (Dave Miller) ---------------------------------------- - -8.3. SGI XFS - pagebuf patches - use of kiobufs ------------------------------------------------ -8.4. Multi-page pioent patch for bio (Christoph Hellwig) --------------------------------------------------------- -8.5. Direct i/o implementation (Andrea Arcangeli) since 2.4.10-pre11 --------------------------------------------------------------------- -8.6. Async i/o implementation patch (Ben LaHaise) -------------------------------------------------- -8.7. EVMS layering design (IBM EVMS team) ------------------------------------------ -8.8. Larger page cache size patch (Ben LaHaise) and Large page size (Daniel Phillips) -------------------------------------------------------------------------------------- - - => larger contiguous physical memory buffers - -8.9. VM reservations patch (Ben LaHaise) ----------------------------------------- -8.10. Write clustering patches ? (Marcelo/Quintela/Riel ?) ----------------------------------------------------------- -8.11. Block device in page cache patch (Andrea Archangeli) - now in 2.4.10+ ---------------------------------------------------------------------------- -8.12. Multiple block-size transfers for faster raw i/o (Shailabh Nagar, Badari) -------------------------------------------------------------------------------- -8.13 Priority based i/o scheduler - prepatches (Arjan van de Ven) ------------------------------------------------------------------- -8.14 IDE Taskfile i/o patch (Andre Hedrick) --------------------------------------------- -8.15 Multi-page writeout and readahead patches (Andrew Morton) ---------------------------------------------------------------- -8.16 Direct i/o patches for 2.5 using kvec and bio (Badari Pulavarthy) ------------------------------------------------------------------------ - -9. Other References -=================== - -9.1 The Splice I/O Model ------------------------- - -Larry McVoy (and subsequent discussions on lkml, and Linus' comments - Jan 2001 - -9.2 Discussions about kiobuf and bh design ------------------------------------------- - -On lkml between sct, linus, alan et al - Feb-March 2001 (many of the -initial thoughts that led to bio were brought up in this discussion thread) - -9.3 Discussions on mempool on lkml - Dec 2001. ----------------------------------------------- diff --git a/Documentation/block/index.rst b/Documentation/block/index.rst index 3a41495dd77b..68f115f2b1c6 100644 --- a/Documentation/block/index.rst +++ b/Documentation/block/index.rst @@ -8,7 +8,6 @@ Block :maxdepth: 1 bfq-iosched - biodoc biovecs blk-mq capability -- cgit From b8ac4ee08d48d4bb46669a2deef10454313e1a00 Mon Sep 17 00:00:00 2001 From: Andre Przywara Date: Fri, 7 Jan 2022 16:00:55 +0000 Subject: arm64: booting.rst: Clarify on requiring non-secure EL2 The ARMv8.4 architecture revision introduced the EL2 exception level to the secure world. Clarify the existing wording to make sure that Linux relies on being executed in the non-secure state. Signed-off-by: Andre Przywara Reviewed-by: Mark Rutland Link: https://lore.kernel.org/r/20220107160056.322141-2-andre.przywara@arm.com Signed-off-by: Will Deacon --- Documentation/arm64/booting.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index 52d060caf8bb..29884b261aa9 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -10,9 +10,9 @@ This document is based on the ARM booting document by Russell King and is relevant to all public releases of the AArch64 Linux kernel. The AArch64 exception model is made up of a number of exception levels -(EL0 - EL3), with EL0 and EL1 having a secure and a non-secure -counterpart. EL2 is the hypervisor level and exists only in non-secure -mode. EL3 is the highest priority level and exists only in secure mode. +(EL0 - EL3), with EL0, EL1 and EL2 having a secure and a non-secure +counterpart. EL2 is the hypervisor level, EL3 is the highest priority +level and exists only in secure mode. Both are architecturally optional. For the purposes of this document, we will use the term `boot loader` simply to define all software that executes on the CPU(s) before control @@ -167,8 +167,8 @@ Before jumping into the kernel, the following conditions must be met: All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, IRQ and FIQ). - The CPU must be in either EL2 (RECOMMENDED in order to have access to - the virtualisation extensions) or non-secure EL1. + The CPU must be in non-secure state, either in EL2 (RECOMMENDED in order + to have access to the virtualisation extensions), or in EL1. - Caches, MMUs -- cgit From 4c022f57ad954e1ad6f838bd3b7d54e459745eeb Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Thu, 27 Jan 2022 19:03:23 +0000 Subject: arm64/mte: Clarify mode reported by PR_GET_TAGGED_ADDR_CTRL With the current wording readers might infer that PR_GET_TAGGED_ADDR_CTRL will report the mode currently active in the thread however this is not the actual behaviour, instead all modes currently selected by the process will be reported with the mode used depending on the combination of the requested modes and the default set for the current CPU. This has been the case since 433c38f40f6a81 ("arm64: mte: change ASYNC and SYNC TCF settings into bitfields"), before that we did not allow more than one mode to be requested simultaneously. Update the documentation to more clearly reflect current behaviour. Signed-off-by: Mark Brown Acked-by: Catalin Marinas Link: https://lore.kernel.org/r/20220127190324.660405-1-broonie@kernel.org Signed-off-by: Will Deacon --- Documentation/arm64/memory-tagging-extension.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arm64/memory-tagging-extension.rst index 7b99c8f428eb..a0ab2f65b235 100644 --- a/Documentation/arm64/memory-tagging-extension.rst +++ b/Documentation/arm64/memory-tagging-extension.rst @@ -91,8 +91,9 @@ mode is specified, the program will run in that mode. If multiple modes are specified, the mode is selected as described in the "Per-CPU preferred tag checking modes" section below. -The current tag check fault mode can be read using the -``prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0)`` system call. +The current tag check fault configuration can be read using the +``prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0)`` system call. If +multiple modes were requested then all will be reported. Tag checking can also be disabled for a user thread by setting the ``PSTATE.TCO`` bit with ``MSR TCO, #1``. -- cgit From 478b09fa2c00cbc40d25bc061befdf11f04a27ad Mon Sep 17 00:00:00 2001 From: Sergio Paracuellos Date: Thu, 10 Feb 2022 10:48:58 +0100 Subject: dt-bindings: clock: mediatek,mt7621-sysc: add '#reset-cells' property Make system controller a reset provider for all the peripherals in the MT7621 SoC adding '#reset-cells' property. Acked-by: Rob Herring Acked-by: Stephen Boyd Signed-off-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20220210094859.927868-2-sergio.paracuellos@gmail.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/clock/mediatek,mt7621-sysc.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml index 915f84efd763..0c0b0ae5e2ac 100644 --- a/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml @@ -22,6 +22,11 @@ description: | The clocks are provided inside a system controller node. + This node is also a reset provider for all the peripherals. + + Reset related bits are defined in: + [2]: . + properties: compatible: items: @@ -37,6 +42,12 @@ properties: clocks. const: 1 + "#reset-cells": + description: + The first cell indicates the reset bit within the register, see + [2] for available resets. + const: 1 + ralink,memctl: $ref: /schemas/types.yaml#/definitions/phandle description: @@ -61,6 +72,7 @@ examples: compatible = "mediatek,mt7621-sysc", "syscon"; reg = <0x0 0x100>; #clock-cells = <1>; + #reset-cells = <1>; ralink,memctl = <&memc>; clock-output-names = "xtal", "cpu", "bus", "50m", "125m", "150m", -- cgit From 5e50f5d4ff31e95599d695df1f0a4e7d2d6fef99 Mon Sep 17 00:00:00 2001 From: Ondrej Mosnacek Date: Sat, 12 Feb 2022 18:59:21 +0100 Subject: security: add sctp_assoc_established hook security_sctp_assoc_established() is added to replace security_inet_conn_established() called in sctp_sf_do_5_1E_ca(), so that asoc can be accessed in security subsystem and save the peer secid to asoc->peer_secid. Fixes: 72e89f50084c ("security: Add support for SCTP security hooks") Reported-by: Prashanth Prahlad Based-on-patch-by: Xin Long Reviewed-by: Xin Long Tested-by: Richard Haines Signed-off-by: Ondrej Mosnacek Signed-off-by: Paul Moore --- Documentation/security/SCTP.rst | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/security/SCTP.rst b/Documentation/security/SCTP.rst index d5fd6ccc3dcb..406cc68b8808 100644 --- a/Documentation/security/SCTP.rst +++ b/Documentation/security/SCTP.rst @@ -15,10 +15,7 @@ For security module support, three SCTP specific hooks have been implemented:: security_sctp_assoc_request() security_sctp_bind_connect() security_sctp_sk_clone() - -Also the following security hook has been utilised:: - - security_inet_conn_established() + security_sctp_assoc_established() The usage of these hooks are described below with the SELinux implementation described in the `SCTP SELinux Support`_ chapter. @@ -122,11 +119,12 @@ calls **sctp_peeloff**\(3). @newsk - pointer to new sock structure. -security_inet_conn_established() +security_sctp_assoc_established() ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Called when a COOKIE ACK is received:: +Called when a COOKIE ACK is received, and the peer secid will be +saved into ``@asoc->peer_secid`` for client:: - @sk - pointer to sock structure. + @asoc - pointer to sctp association structure. @skb - pointer to skbuff of the COOKIE ACK packet. @@ -134,7 +132,7 @@ Security Hooks used for Association Establishment ------------------------------------------------- The following diagram shows the use of ``security_sctp_bind_connect()``, -``security_sctp_assoc_request()``, ``security_inet_conn_established()`` when +``security_sctp_assoc_request()``, ``security_sctp_assoc_established()`` when establishing an association. :: @@ -172,7 +170,7 @@ establishing an association. <------------------------------------------- COOKIE ACK | | sctp_sf_do_5_1E_ca | - Call security_inet_conn_established() | + Call security_sctp_assoc_established() | to set the peer label. | | | | If SCTP_SOCKET_TCP or peeled off @@ -198,7 +196,7 @@ hooks with the SELinux specifics expanded below:: security_sctp_assoc_request() security_sctp_bind_connect() security_sctp_sk_clone() - security_inet_conn_established() + security_sctp_assoc_established() security_sctp_assoc_request() @@ -271,12 +269,12 @@ sockets sid and peer sid to that contained in the ``@asoc sid`` and @newsk - pointer to new sock structure. -security_inet_conn_established() +security_sctp_assoc_established() ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Called when a COOKIE ACK is received where it sets the connection's peer sid to that in ``@skb``:: - @sk - pointer to sock structure. + @asoc - pointer to sctp association structure. @skb - pointer to skbuff of the COOKIE ACK packet. -- cgit From f720002d8468f46c3cce8ab2b9f93aeedac4b602 Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Wed, 2 Feb 2022 20:17:31 -0600 Subject: dt-bindings: rtc: sun6i: Clean up repetition - Use "enum" for compatibles instead of several "const" alternatives. - Merge the H6 clock-output-names minItems/maxItems constraint into the identical block above. Reviewed-by: Rob Herring Signed-off-by: Samuel Holland Reviewed-by: Maxime Ripard Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220203021736.13434-2-samuel@sholland.org --- .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 28 +++++++--------------- 1 file changed, 9 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml index beeb90e55727..a88d46ffb457 100644 --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml @@ -16,16 +16,17 @@ properties: compatible: oneOf: - - const: allwinner,sun6i-a31-rtc - - const: allwinner,sun8i-a23-rtc - - const: allwinner,sun8i-h3-rtc - - const: allwinner,sun8i-r40-rtc - - const: allwinner,sun8i-v3-rtc - - const: allwinner,sun50i-h5-rtc + - enum: + - allwinner,sun6i-a31-rtc + - allwinner,sun8i-a23-rtc + - allwinner,sun8i-h3-rtc + - allwinner,sun8i-r40-rtc + - allwinner,sun8i-v3-rtc + - allwinner,sun50i-h5-rtc + - allwinner,sun50i-h6-rtc - items: - const: allwinner,sun50i-a64-rtc - const: allwinner,sun8i-h3-rtc - - const: allwinner,sun50i-h6-rtc reg: maxItems: 1 @@ -85,18 +86,7 @@ allOf: enum: - allwinner,sun8i-h3-rtc - allwinner,sun50i-h5-rtc - - then: - properties: - clock-output-names: - minItems: 3 - maxItems: 3 - - - if: - properties: - compatible: - contains: - const: allwinner,sun50i-h6-rtc + - allwinner,sun50i-h6-rtc then: properties: -- cgit From 8487614a8a8a70d44957a11693dbefd8350f402c Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Wed, 2 Feb 2022 20:17:32 -0600 Subject: dt-bindings: rtc: sun6i: Add H616, R329, and D1 support These new RTC variants all have a single alarm, like the R40 variant. For the new SoCs, start requiring a complete list of input clocks. The H616 has three required clocks. The R329 also has three required clocks (but one is different), plus an optional crystal oscillator input. The D1 RTC is identical to the one in the R329. And since these new SoCs will have a well-defined output clock order as well, they do not need the clock-output-names property. Signed-off-by: Samuel Holland Reviewed-by: Rob Herring Reviewed-by: Maxime Ripard Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220203021736.13434-3-samuel@sholland.org --- .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 76 +++++++++++++++++++++- 1 file changed, 73 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml index a88d46ffb457..0b767fec39d8 100644 --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml @@ -24,9 +24,14 @@ properties: - allwinner,sun8i-v3-rtc - allwinner,sun50i-h5-rtc - allwinner,sun50i-h6-rtc + - allwinner,sun50i-h616-rtc + - allwinner,sun50i-r329-rtc - items: - const: allwinner,sun50i-a64-rtc - const: allwinner,sun8i-h3-rtc + - items: + - const: allwinner,sun20i-d1-rtc + - const: allwinner,sun50i-r329-rtc reg: maxItems: 1 @@ -38,7 +43,12 @@ properties: - description: RTC Alarm 1 clocks: - maxItems: 1 + minItems: 1 + maxItems: 4 + + clock-names: + minItems: 1 + maxItems: 4 clock-output-names: minItems: 1 @@ -98,7 +108,68 @@ allOf: properties: compatible: contains: - const: allwinner,sun8i-r40-rtc + const: allwinner,sun50i-h616-rtc + + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + items: + - description: Bus clock for register access + - description: 24 MHz oscillator + - description: 32 kHz clock from the CCU + + clock-names: + minItems: 3 + maxItems: 3 + items: + - const: bus + - const: hosc + - const: pll-32k + + required: + - clocks + - clock-names + + - if: + properties: + compatible: + contains: + const: allwinner,sun50i-r329-rtc + + then: + properties: + clocks: + minItems: 3 + maxItems: 4 + items: + - description: Bus clock for register access + - description: 24 MHz oscillator + - description: AHB parent for internal SPI clock + - description: External 32768 Hz oscillator + + clock-names: + minItems: 3 + maxItems: 4 + items: + - const: bus + - const: hosc + - const: ahb + - const: ext-osc32k + + required: + - clocks + - clock-names + + - if: + properties: + compatible: + contains: + enum: + - allwinner,sun8i-r40-rtc + - allwinner,sun50i-h616-rtc + - allwinner,sun50i-r329-rtc then: properties: @@ -117,7 +188,6 @@ required: - compatible - reg - interrupts - - clock-output-names additionalProperties: false -- cgit From 731451ab3c0c6fe88142dbc73a74c71bd92a5cff Mon Sep 17 00:00:00 2001 From: Catalin Marinas Date: Mon, 31 Jan 2022 16:54:56 +0000 Subject: arm64: mte: Document the core dump file format Add the program header definition and data layout for the PT_ARM_MEMTAG_MTE segments. Signed-off-by: Catalin Marinas Acked-by: Luis Machado Link: https://lore.kernel.org/r/20220131165456.2160675-6-catalin.marinas@arm.com Signed-off-by: Will Deacon --- Documentation/arm64/memory-tagging-extension.rst | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arm64/memory-tagging-extension.rst index 7b99c8f428eb..5a70d7a3ca12 100644 --- a/Documentation/arm64/memory-tagging-extension.rst +++ b/Documentation/arm64/memory-tagging-extension.rst @@ -213,6 +213,29 @@ address ABI control and MTE configuration of a process as per the Documentation/arm64/tagged-address-abi.rst and above. The corresponding ``regset`` is 1 element of 8 bytes (``sizeof(long))``). +Core dump support +----------------- + +The allocation tags for user memory mapped with ``PROT_MTE`` are dumped +in the core file as additional ``PT_ARM_MEMTAG_MTE`` segments. The +program header for such segment is defined as: + +:``p_type``: ``PT_ARM_MEMTAG_MTE`` +:``p_flags``: 0 +:``p_offset``: segment file offset +:``p_vaddr``: segment virtual address, same as the corresponding + ``PT_LOAD`` segment +:``p_paddr``: 0 +:``p_filesz``: segment size in file, calculated as ``p_mem_sz / 32`` + (two 4-bit tags cover 32 bytes of memory) +:``p_memsz``: segment size in memory, same as the corresponding + ``PT_LOAD`` segment +:``p_align``: 0 + +The tags are stored in the core file at ``p_offset`` as two 4-bit tags +in a byte. With the tag granule of 16 bytes, a 4K page requires 128 +bytes in the core file. + Example of correct usage ======================== -- cgit From a693396fd569c0a33e4b0f82398fbd6410a7beec Mon Sep 17 00:00:00 2001 From: Frank Rowand Date: Thu, 10 Feb 2022 17:36:30 -0600 Subject: Documentation: dev-tools: clarify KTAP specification wording Add the spec version to the title line. Explain likely source of "Unknown lines". "Unknown lines" in nested tests are optionally indented. Add "Unknown lines" items to differences between TAP & KTAP list Convert "Major differences between TAP and KTAP" from a bullet list to a table. The bullet list was being formatted as a single paragraph. Reviewed-by: Tim Bird Reviewed-by: David Gow Reviewed-by: Shuah Khan Signed-off-by: Frank Rowand Reviewed-by: Brendan Higgins Link: https://lore.kernel.org/r/20220210233630.3304495-1-frowand.list@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/ktap.rst | 31 +++++++++++++++++++++++-------- 1 file changed, 23 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/ktap.rst b/Documentation/dev-tools/ktap.rst index 878530cb9c27..d7fe05de40b4 100644 --- a/Documentation/dev-tools/ktap.rst +++ b/Documentation/dev-tools/ktap.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -======================================== -The Kernel Test Anything Protocol (KTAP) -======================================== +=================================================== +The Kernel Test Anything Protocol (KTAP), version 1 +=================================================== TAP, or the Test Anything Protocol is a format for specifying test results used by a number of projects. It's website and specification are found at this `link @@ -174,6 +174,13 @@ There may be lines within KTAP output that do not follow the format of one of the four formats for lines described above. This is allowed, however, they will not influence the status of the tests. +This is an important difference from TAP. Kernel tests may print messages +to the system console or a log file. Both of these destinations may contain +messages either from unrelated kernel or userspace activity, or kernel +messages from non-test code that is invoked by the test. The kernel code +invoked by the test likely is not aware that a test is in progress and +thus can not print the message as a diagnostic message. + Nested tests ------------ @@ -186,10 +193,13 @@ starting with another KTAP version line and test plan, and end with the overall result. If one of the subtests fail, for example, the parent test should also fail. -Additionally, all result lines in a subtest should be indented. One level of +Additionally, all lines in a subtest should be indented. One level of indentation is two spaces: " ". The indentation should begin at the version line and should end before the parent test's result line. +"Unknown lines" are not considered to be lines in a subtest and thus are +allowed to be either indented or not indented. + An example of a test with two nested subtests: .. code-block:: @@ -224,10 +234,15 @@ An example format with multiple levels of nested testing: Major differences between TAP and KTAP -------------------------------------- -Note the major differences between the TAP and KTAP specification: -- yaml and json are not recommended in diagnostic messages -- TODO directive not recognized -- KTAP allows for an arbitrary number of tests to be nested +================================================== ========= =============== +Feature TAP KTAP +================================================== ========= =============== +yaml and json in diagnosic message ok not recommended +TODO directive ok not recognized +allows an arbitrary number of tests to be nested no yes +"Unknown lines" are in category of "Anything else" yes no +"Unknown lines" are incorrect allowed +================================================== ========= =============== The TAP14 specification does permit nested tests, but instead of using another nested version line, uses a line of the form -- cgit From 013ebb6d822a51ccc8ad162e7c8d02fbd7e90dd1 Mon Sep 17 00:00:00 2001 From: Pali Rohár Date: Thu, 10 Feb 2022 20:22:00 +0100 Subject: Documentation: Fix links for udftools project and pktcdvd tool MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Pali Rohár Link: https://lore.kernel.org/r/20220210192200.30828-1-pali@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/cdrom/packet-writing.rst | 4 ++-- Documentation/userspace-api/ioctl/ioctl-number.rst | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cdrom/packet-writing.rst b/Documentation/cdrom/packet-writing.rst index c5c957195a5a..43db58c50d29 100644 --- a/Documentation/cdrom/packet-writing.rst +++ b/Documentation/cdrom/packet-writing.rst @@ -11,7 +11,7 @@ Getting started quick - Compile and install kernel and modules, reboot. - You need the udftools package (pktsetup, mkudffs, cdrwtool). - Download from http://sourceforge.net/projects/linux-udf/ + Download from https://github.com/pali/udftools - Grab a new CD-RW disc and format it (assuming CD-RW is hdc, substitute as appropriate):: @@ -102,7 +102,7 @@ Using the pktcdvd sysfs interface Since Linux 2.6.20, the pktcdvd module has a sysfs interface and can be controlled by it. For example the "pktcdvd" tool uses -this interface. (see http://tom.ist-im-web.de/download/pktcdvd ) +this interface. (see http://tom.ist-im-web.de/linux/software/pktcdvd ) "pktcdvd" works similar to "pktsetup", e.g.:: diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 687efcf245c1..559c436276c6 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -253,7 +253,7 @@ Code Seq# Include File Comments 'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system 'l' 40-7F linux/udf_fs_i.h in development: - + 'm' 00-09 linux/mmtimer.h conflict! 'm' all linux/mtio.h conflict! 'm' all linux/soundcard.h conflict! -- cgit From 339cf5a2c6fb8559f30b9d4bd82c1dc4d7a16468 Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Tue, 8 Feb 2022 21:37:16 +0800 Subject: docs/zh_CN: Add energy-model Chinese translation Translate power/energy-model.rst into Chinese. Signed-off-by: Tang Yizhou Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/20220208133716.24070-1-tangyizhou@huawei.com Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/power/energy-model.rst | 190 +++++++++++++++++++++ Documentation/translations/zh_CN/power/index.rst | 2 +- 2 files changed, 191 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/power/energy-model.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/power/energy-model.rst b/Documentation/translations/zh_CN/power/energy-model.rst new file mode 100644 index 000000000000..c7da1b6aefee --- /dev/null +++ b/Documentation/translations/zh_CN/power/energy-model.rst @@ -0,0 +1,190 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/power/energy-model.rst + +:翻译: + + 唐艺舟 Tang Yizhou + +============ +设备能量模型 +============ + +1. 概述 +------- + +能量模型（EM）框架是一种驱动程序与内核子系统之间的接口。其中驱动程序了解不同 +性能层级的设备所消耗的功率，而内核子系统愿意使用该信息做出能量感知决策。 + +设备所消耗的功率的信息来源在不同的平台上可能有很大的不同。这些功率成本在某些 +情况下可以使用设备树数据来估算。在其它情况下，固件会更清楚。或者，用户空间可能 +是最清楚的。以此类推。为了避免每一个客户端子系统对每一种可能的信息源自己重新 +实现支持，EM框架作为一个抽象层介入，它在内核中对功率成本表的格式进行标准化， +因此能够避免多余的工作。 + +功率值可以用毫瓦或“抽象刻度”表示。多个子系统可能使用EM，由系统集成商来检查 +功率值刻度类型的要求是否满足。可以在能量感知调度器的文档中找到一个例子 +Documentation/scheduler/sched-energy.rst。对于一些子系统，比如热能或 +powercap，用“抽象刻度”描述功率值可能会导致问题。这些子系统对过去使用的功率的 +估算值更感兴趣，因此可能需要真实的毫瓦。这些要求的一个例子可以在智能功率分配 +Documentation/driver-api/thermal/power_allocator.rst文档中找到。 + +内核子系统可能（基于EM内部标志位）实现了对EM注册设备是否具有不一致刻度的自动 +检查。要记住的重要事情是，当功率值以“抽象刻度”表示时，从中推导以毫焦耳为单位 +的真实能量消耗是不可能的。 + +下图描述了一个驱动的例子（这里是针对Arm的，但该方法适用于任何体系结构），它 +向EM框架提供了功率成本，感兴趣的客户端可从中读取数据:: + + +---------------+ +-----------------+ +---------------+ + | Thermal (IPA) | | Scheduler (EAS) | | Other | + +---------------+ +-----------------+ +---------------+ + | | em_cpu_energy() | + | | em_cpu_get() | + +---------+ | +---------+ + | | | + v v v + +---------------------+ + | Energy Model | + | Framework | + +---------------------+ + ^ ^ ^ + | | | em_dev_register_perf_domain() + +----------+ | +---------+ + | | | + +---------------+ +---------------+ +--------------+ + | cpufreq-dt | | arm_scmi | | Other | + +---------------+ +---------------+ +--------------+ + ^ ^ ^ + | | | + +--------------+ +---------------+ +--------------+ + | Device Tree | | Firmware | | ? | + +--------------+ +---------------+ +--------------+ + +对于CPU设备，EM框架管理着系统中每个“性能域”的功率成本表。一个性能域是一组 +性能一起伸缩的CPU。性能域通常与CPUFreq策略具有1对1映射。一个性能域中的 +所有CPU要求具有相同的微架构。不同性能域中的CPU可以有不同的微架构。 + + +2. 核心API +---------- + +2.1 配置选项 +^^^^^^^^^^^^ + +必须使能CONFIG_ENERGY_MODEL才能使用EM框架。 + + +2.2 性能域的注册 +^^^^^^^^^^^^^^^^ + +“高级”EM的注册 +~~~~~~~~~~~~~~~~ + +“高级”EM因它允许驱动提供更精确的功率模型而得名。它并不受限于框架中的一些已 +实现的数学公式（就像“简单”EM那样）。它可以更好地反映每个性能状态的实际功率 +测量。因此，在EM静态功率（漏电流功率）是重要的情况下，应该首选这种注册方式。 + +驱动程序应通过以下API将性能域注册到EM框架中:: + + int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states, + struct em_data_callback *cb, cpumask_t *cpus, bool milliwatts); + +驱动程序必须提供一个回调函数，为每个性能状态返回<频率,功率>元组。驱动程序 +提供的回调函数可以自由地从任何相关位置（DT、固件......）以及以任何被认为是 +必要的方式获取数据。只有对于CPU设备，驱动程序必须使用cpumask指定性能域的CPU。 +对于CPU以外的其他设备，最后一个参数必须被设置为NULL。 + +最后一个参数“milliwatts”（毫瓦）设置成正确的值是很重要的，使用EM的内核 +子系统可能会依赖这个标志来检查所有的EM设备是否使用相同的刻度。如果有不同的 +刻度，这些子系统可能决定：返回警告/错误，停止工作或崩溃（panic）。 + +关于实现这个回调函数的驱动程序的例子，参见第3节。或者在第2.4节阅读这个API +的更多文档。 + + +“简单”EM的注册 +~~~~~~~~~~~~~~~~ + +“简单”EM是用框架的辅助函数cpufreq_register_em_with_opp()注册的。它实现了 +一个和以下数学公式紧密相关的功率模型:: + + Power = C * V^2 * f + +使用这种方法注册的EM可能无法正确反映真实设备的物理特性，例如当静态功率 +（漏电流功率）很重要时。 + + +2.3 访问性能域 +^^^^^^^^^^^^^^ + +有两个API函数提供对能量模型的访问。em_cpu_get()以CPU id为参数，em_pd_get() +以设备指针为参数。使用哪个接口取决于子系统，但对于CPU设备来说，这两个函数都返 +回相同的性能域。 + +对CPU的能量模型感兴趣的子系统可以通过em_cpu_get() API检索它。在创建性能域时 +分配一次能量模型表，它保存在内存中不被修改。 + +一个性能域所消耗的能量可以使用em_cpu_energy() API来估算。该估算假定CPU设备 +使用的CPUfreq监管器是schedutil。当前该计算不能提供给其它类型的设备。 + +关于上述API的更多细节可以在 ```` 或第2.4节中找到。 + + +2.4 API的细节描述 +^^^^^^^^^^^^^^^^^ +参见 include/linux/energy_model.h 和 kernel/power/energy_model.c 的kernel doc。 + +3. 驱动示例 +----------- + +CPUFreq框架支持专用的回调函数，用于为指定的CPU（们）注册EM： +cpufreq_driver::register_em()。这个回调必须为每个特定的驱动程序正确实现， +因为框架会在设置过程中适时地调用它。本节提供了一个简单的例子，展示CPUFreq驱动 +在能量模型框架中使用（假的）“foo”协议注册性能域。该驱动实现了一个est_power() +函数提供给EM框架:: + + -> drivers/cpufreq/foo_cpufreq.c + + 01 static int est_power(unsigned long *mW, unsigned long *KHz, + 02 struct device *dev) + 03 { + 04 long freq, power; + 05 + 06 /* 使用“foo”协议设置频率上限 */ + 07 freq = foo_get_freq_ceil(dev, *KHz); + 08 if (freq < 0); + 09 return freq; + 10 + 11 /* 估算相关频率下设备的功率成本 */ + 12 power = foo_estimate_power(dev, freq); + 13 if (power < 0); + 14 return power; + 15 + 16 /* 将这些值返回给EM框架 */ + 17 *mW = power; + 18 *KHz = freq; + 19 + 20 return 0; + 21 } + 22 + 23 static void foo_cpufreq_register_em(struct cpufreq_policy *policy) + 24 { + 25 struct em_data_callback em_cb = EM_DATA_CB(est_power); + 26 struct device *cpu_dev; + 27 int nr_opp; + 28 + 29 cpu_dev = get_cpu_device(cpumask_first(policy->cpus)); + 30 + 31 /* 查找该策略支持的OPP数量 */ + 32 nr_opp = foo_get_nr_opp(policy); + 33 + 34 /* 并注册新的性能域 */ + 35 em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus, + 36 true); + 37 } + 38 + 39 static struct cpufreq_driver foo_cpufreq_driver = { + 40 .register_em = foo_cpufreq_register_em, + 41 }; diff --git a/Documentation/translations/zh_CN/power/index.rst b/Documentation/translations/zh_CN/power/index.rst index ad80a9e80b7c..bc54983ba515 100644 --- a/Documentation/translations/zh_CN/power/index.rst +++ b/Documentation/translations/zh_CN/power/index.rst @@ -14,6 +14,7 @@ .. toctree:: :maxdepth: 1 + energy-model opp TODOList: @@ -22,7 +23,6 @@ TODOList: * basic-pm-debugging * charger-manager * drivers-testing - * energy-model * freezing-of-tasks * pci * pm_qos_interface -- cgit From d535e6c25a8131324aef4534e14d09b4d81c98a9 Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Tue, 8 Feb 2022 10:01:05 +0800 Subject: docs/zh_CN: Add sched-energy Chinese translation Translate scheduler/sched-energy.rst into Chinese. Signed-off-by: Tang Yizhou Reviewed-by: Alex Shi Reviewed-by: Yanteng Si Link: https://lore.kernel.org/r/20220208020105.14117-1-tangyizhou@huawei.com Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/scheduler/index.rst | 4 +- .../translations/zh_CN/scheduler/sched-energy.rst | 351 +++++++++++++++++++++ 2 files changed, 353 insertions(+), 2 deletions(-) create mode 100644 Documentation/translations/zh_CN/scheduler/sched-energy.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/scheduler/index.rst b/Documentation/translations/zh_CN/scheduler/index.rst index f8f8f35d53c7..ab7925980266 100644 --- a/Documentation/translations/zh_CN/scheduler/index.rst +++ b/Documentation/translations/zh_CN/scheduler/index.rst @@ -5,6 +5,7 @@ :翻译: 司延腾 Yanteng Si + 唐艺舟 Tang Yizhou :校译: @@ -23,13 +24,12 @@ Linux调度器 sched-design-CFS sched-domains sched-capacity + sched-energy TODOList: - sched-bwc sched-deadline - sched-energy sched-nice-design sched-rt-group sched-stats diff --git a/Documentation/translations/zh_CN/scheduler/sched-energy.rst b/Documentation/translations/zh_CN/scheduler/sched-energy.rst new file mode 100644 index 000000000000..fdbf6cfeea93 --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/sched-energy.rst @@ -0,0 +1,351 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/sched-energy.rst + +:翻译: + + 唐艺舟 Tang Yizhou + +============ +能量感知调度 +============ + +1. 简介 +------- + +能量感知调度（EAS）使调度器有能力预测其决策对CPU所消耗的能量的影响。EAS依靠 +一个能量模型（EM）来为每个任务选择一个节能的CPU，同时最小化对吞吐率的影响。 +本文档致力于介绍介绍EAS是如何工作的，它背后的主要设计决策是什么，以及使其运行 +所需的条件细节。 + +在进一步阅读之前，请注意，在撰写本文时:: + + /!\ EAS不支持对称CPU拓扑的平台 /!\ + +EAS只在异构CPU拓扑结构（如Arm大小核，big.LITTLE）上运行。因为在这种情况下， +通过调度来节约能量的潜力是最大的。 + +EAS实际使用的EM不是由调度器维护的，而是一个专门的框架。关于这个框架的细节和 +它提供的内容，请参考其文档（见Documentation/power/energy-model.rst）。 + + +2. 背景和术语 +------------- + +从一开始就说清楚定义: + - 能量 = [焦耳] （比如供电设备上的电池提供的资源） + - 功率 = 能量/时间 = [焦耳/秒] = [瓦特] + + EAS的目标是最小化能量消耗，同时仍能将工作完成。也就是说，我们要最大化:: + + 性能 [指令数/秒] + ---------------- + 功率 [瓦特] + +它等效于最小化:: + + 能量 [焦耳] + ----------- + 指令数 + +同时仍然获得“良好”的性能。当前调度器只考虑性能目标，因此该式子本质上是一个 +可选的优化目标，它同时考虑了两个目标：能量效率和性能。 + +引入EM的想法是为了让调度器评估其决策的影响，而不是盲目地应用可能仅在部分 +平台有正面效果的节能技术。同时，EM必须尽可能的简单，以最小化调度器的时延 +影响。 + +简而言之，EAS改变了CFS任务分配给CPU的方式。当调度器决定一个任务应该在哪里 +运行时（在唤醒期间），EM被用来在不损害系统吞吐率的情况下，从几个较好的候选 +CPU中挑选一个经预测能量消耗最优的CPU。EAS的预测依赖于对平台拓扑结构特定元素 +的了解，包括CPU的“算力”，以及它们各自的能量成本。 + + +3. 拓扑信息 +----------- + +EAS（以及调度器的剩余部分）使用“算力”的概念来区分不同计算吞吐率的CPU。一个 +CPU的“算力”代表了它在最高频率下运行时能完成的工作量，且这个值是相对系统中 +算力最大的CPU而言的。算力值被归一化为1024以内，并且可与由实体负载跟踪 +（PELT）机制算出的利用率信号做对比。由于有算力值和利用率值，EAS能够估计一个 +任务/CPU有多大/有多忙，并在评估性能与能量时将其考虑在内。CPU算力由特定体系 +结构实现的arch_scale_cpu_capacity()回调函数提供。 + +EAS使用的其余平台信息是直接从能量模型（EM）框架中读取的。一个平台的EM是一张 +表，表中每项代表系统中一个“性能域”的功率成本。（若要了解更多关于性能域的细节， +见Documentation/power/energy-model.rst） + +当调度域被建立或重新建立时，调度器管理对拓扑代码中EM对象的引用。对于每个根域 +（rd），调度器维护一个与当前rd->span相交的所有性能域的单向链表。链表中的每个 +节点都包含一个指向EM框架所提供的结构体em_perf_domain的指针。 + +链表被附加在根域上，以应对独占的cpuset的配置。由于独占的cpuset的边界不一定与 +性能域的边界一致，不同根域的链表可能包含重复的元素。 + +示例1 + 让我们考虑一个有12个CPU的平台，分成3个性能域，（pd0，pd4和pd8），按以下 + 方式组织:: + + CPUs: 0 1 2 3 4 5 6 7 8 9 10 11 + PDs: |--pd0--|--pd4--|---pd8---| + RDs: |----rd1----|-----rd2-----| + + 现在，考虑用户空间决定将系统分成两个独占的cpusets，因此创建了两个独立的根域， + 每个根域包含6个CPU。这两个根域在上图中被表示为rd1和rd2。由于pd4与rd1和rd2 + 都有交集，它将同时出现于附加在这两个根域的“->pd”链表中: + + * rd1->pd: pd0 -> pd4 + * rd2->pd: pd4 -> pd8 + + 请注意，调度器将为pd4创建两个重复的链表节点（每个链表中各一个）。然而这 + 两个节点持有指向同一个EM框架的共享数据结构的指针。 + +由于对这些链表的访问可能与热插拔及其它事件并发发生，因此它们受RCU锁保护，就像 +被调度器操控的拓扑结构体中剩下字段一样。 + +EAS同样维护了一个静态键（sched_energy_present），当至少有一个根域满足EAS +启动的所有条件时，这个键就会被启动。在第6节中总结了这些条件。 + + +4. 能量感知任务放置 +------------------- + +EAS覆盖了CFS的任务唤醒平衡代码。在唤醒平衡时，它使用平台的EM和PELT信号来选择节能 +的目标CPU。当EAS被启用时，select_task_rq_fair()调用find_energy_efficient_cpu() +来做任务放置决定。这个函数寻找在每个性能域中寻找具有最高剩余算力（CPU算力 - CPU +利用率）的CPU，因为它能让我们保持最低的频率。然后，该函数检查将任务放在新CPU相较 +依然放在之前活动的prev_cpu是否可以节省能量。 + +如果唤醒的任务被迁移，find_energy_efficient_cpu()使用compute_energy()来估算 +系统将消耗多少能量。compute_energy()检查各CPU当前的利用率情况，并尝试调整来 +“模拟”任务迁移。EM框架提供了API em_pd_energy()计算每个性能域在给定的利用率条件 +下的预期能量消耗。 + +下面详细介绍一个优化能量消耗的任务放置决策的例子。 + +示例2 + 让我们考虑一个有两个独立性能域的（伪）平台，每个性能域含有2个CPU。CPU0和CPU1 + 是小核，CPU2和CPU3是大核。 + + 调度器必须决定将任务P放在哪个CPU上，这个任务的util_avg = 200（平均利用率）， + prev_cpu = 0（上一次运行在CPU0）。 + + 目前CPU的利用率情况如下图所示。CPU 0-3的util_avg分别为400、100、600和500。 + 每个性能域有三个操作性能值（OPP）。与每个OPP相关的CPU算力和功率成本列在能量 + 模型表中。P的util_avg在图中显示为"PP":: + + CPU util. + 1024 - - - - - - - Energy Model + +-----------+-------------+ + | Little | Big | + 768 ============= +-----+-----+------+------+ + | Cap | Pwr | Cap | Pwr | + +-----+-----+------+------+ + 512 =========== - ##- - - - - | 170 | 50 | 512 | 400 | + ## ## | 341 | 150 | 768 | 800 | + 341 -PP - - - - ## ## | 512 | 300 | 1024 | 1700 | + PP ## ## +-----+-----+------+------+ + 170 -## - - - - ## ## + ## ## ## ## + ------------ ------------- + CPU0 CPU1 CPU2 CPU3 + + Current OPP: ===== Other OPP: - - - util_avg (100 each): ## + + + find_energy_efficient_cpu()将首先在两个性能域中寻找具有最大剩余算力的CPU。 + 在这个例子中是CPU1和CPU3。然后，它将估算，当P被放在它们中的任意一个时，系统的 + 能耗，并检查这样做是否会比把P放在CPU0上节省一些能量。EAS假定OPPs遵循利用率 + （这与CPUFreq监管器schedutil的行为一致。关于这个问题的更多细节，见第6节）。 + + **情况1. P被迁移到CPU1**:: + + 1024 - - - - - - - + + Energy calculation: + 768 ============= * CPU0: 200 / 341 * 150 = 88 + * CPU1: 300 / 341 * 150 = 131 + * CPU2: 600 / 768 * 800 = 625 + 512 - - - - - - - ##- - - - - * CPU3: 500 / 768 * 800 = 520 + ## ## => total_energy = 1364 + 341 =========== ## ## + PP ## ## + 170 -## - - PP- ## ## + ## ## ## ## + ------------ ------------- + CPU0 CPU1 CPU2 CPU3 + + + **情况2. P被迁移到CPU3**:: + + 1024 - - - - - - - + + Energy calculation: + 768 ============= * CPU0: 200 / 341 * 150 = 88 + * CPU1: 100 / 341 * 150 = 43 + PP * CPU2: 600 / 768 * 800 = 625 + 512 - - - - - - - ##- - -PP - * CPU3: 700 / 768 * 800 = 729 + ## ## => total_energy = 1485 + 341 =========== ## ## + ## ## + 170 -## - - - - ## ## + ## ## ## ## + ------------ ------------- + CPU0 CPU1 CPU2 CPU3 + + **情况3. P依旧留在prev_cpu/CPU0**:: + + 1024 - - - - - - - + + Energy calculation: + 768 ============= * CPU0: 400 / 512 * 300 = 234 + * CPU1: 100 / 512 * 300 = 58 + * CPU2: 600 / 768 * 800 = 625 + 512 =========== - ##- - - - - * CPU3: 500 / 768 * 800 = 520 + ## ## => total_energy = 1437 + 341 -PP - - - - ## ## + PP ## ## + 170 -## - - - - ## ## + ## ## ## ## + ------------ ------------- + CPU0 CPU1 CPU2 CPU3 + + 从这些计算结果来看，情况1的总能量最低。所以从节约能量的角度看，CPU1是最佳候选 + 者。 + +大核通常比小核更耗电，因此主要在任务不适合在小核运行时使用。然而，小核并不总是比 +大核节能。举例来说，对于某些系统，小核的高OPP可能比大核的低OPP能量消耗更高。因此， +如果小核在某一特定时间点刚好有足够的利用率，在此刻被唤醒的小任务放在大核执行可能 +会更节能，尽管它在小核上运行也是合适的。 + +即使在大核所有OPP都不如小核OPP节能的情况下，在某些特定条件下，令小任务运行在大核 +上依然可能节能。事实上，将一个任务放在一个小核上可能导致整个性能域的OPP提高，这将 +增加已经在该性能域运行的任务的能量成本。如果唤醒的任务被放在一个大核上，它的执行 +成本可能比放在小核上更高，但这不会影响小核上的其它任务，这些任务将继续以较低的OPP +运行。因此，当考虑CPU消耗的总能量时，在大核上运行一个任务的额外成本可能小于为所有 +其它运行在小核的任务提高OPP的成本。 + +上面的例子几乎不可能以一种通用的方式得到正确的结果；同时，对于所有平台，在不知道 +系统所有CPU每个不同OPP的运行成本时，也无法得到正确的结果。得益于基于EM的设计， +EAS应该能够正确处理这些问题而不会引发太多麻烦。然而，为了确保对高利用率场景的 +吞吐率造成的影响最小化，EAS同样实现了另外一种叫“过度利用率”的机制。 + + +5. 过度利用率 +------------- + +从一般的角度来看，EAS能提供最大帮助的是那些涉及低、中CPU利用率的使用场景。每当CPU +密集型的长任务运行，它们将需要所有的可用CPU算力，调度器将没有什么办法来节省能量同时 +又不损害吞吐率。为了避免EAS损害性能，一旦CPU被使用的算力超过80%，它将被标记为“过度 +利用”。只要根域中没有CPU是过度利用状态，负载均衡被禁用，而EAS将覆盖唤醒平衡代码。 +EAS很可能将负载放置在系统中能量效率最高的CPU而不是其它CPU上，只要不损害吞吐率。 +因此，负载均衡器被禁用以防止它打破EAS发现的节能任务放置。当系统未处于过度利用状态时， +这样做是安全的，因为低于80%的临界点意味着： + + a. 所有的CPU都有一些空闲时间，所以EAS使用的利用率信号很可能准确地代表各种任务 + 的“大小”。 + b. 所有任务，不管它们的nice值是多大，都应该被提供了足够多的CPU算力。 + c. 既然有多余的算力，那么所有的任务都必须定期阻塞/休眠，在唤醒时进行平衡就足够 + 了。 + +只要一个CPU利用率超过80%的临界点，上述三个假设中至少有一个是不正确的。在这种情况下， +整个根域的“过度利用”标志被设置，EAS被禁用，负载均衡器被重新启用。通过这样做，调度器 +又回到了在CPU密集的条件下基于负载的算法做负载均衡。这更好地尊重了任务的nice值。 + +由于过度利用率的概念在很大程度上依赖于检测系统中是否有一些空闲时间，所以必须考虑 +（比CFS）更高优先级的调度类（以及中断）“窃取”的CPU算力。像这样，对过度使用率的检测 +不仅要考虑CFS任务使用的算力，还需要考虑其它调度类和中断。 + + +6. EAS的依赖和要求 +------------------ + +能量感知调度依赖系统的CPU具有特定的硬件属性，以及内核中的其它特性被启用。本节列出 +了这些依赖，并对如何满足这些依赖提供了提示。 + + +6.1 - 非对称CPU拓扑 +^^^^^^^^^^^^^^^^^^^ + + +如简介所提，目前只有非对称CPU拓扑结构的平台支持EAS。通过在运行时查询 +SD_ASYM_CPUCAPACITY_FULL标志位是否在创建调度域时已设置来检查这一要求是否满足。 + +参阅Documentation/scheduler/sched-capacity.rst以了解在sched_domain层次结构 +中设置此标志位所需满足的要求。 + +请注意，EAS并非从根本上与SMP不兼容，但在SMP平台上还没有观察到明显的节能。这一 +限制可以在将来进行修改，如果被证明不是这样的话。 + + +6.2 - 当前的能量模型 +^^^^^^^^^^^^^^^^^^^^ + +EAS使用一个平台的EM来估算调度决策对能量的影响。因此，你的平台必须向EM框架提供 +能量成本表，以启动EAS。要做到这一点，请参阅文档 +Documentation/power/energy-model.rst中的独立EM框架部分。 + +另请注意，调度域需要在EM注册后重建，以便启动EAS。 + +EAS使用EM对能量使用率进行预测决策，因此它在检查任务放置的可能选项时更加注重 +差异。对于EAS来说，EM的功率值是以毫瓦还是以“抽象刻度”为单位表示并不重要。 + + + +6.3 - 能量模型复杂度 +^^^^^^^^^^^^^^^^^^^^ + +任务唤醒路径是时延敏感的。当一个平台的EM太复杂（太多CPU，太多性能域，太多状态 +等），在唤醒路径中使用它的成本就会升高到不可接受。能量感知唤醒算法的复杂度为： + + C = Nd * (Nc + Ns) + +其中：Nd是性能域的数量；Nc是CPU的数量；Ns是OPP的总数（例如：对于两个性能域， +每个域有4个OPP，则Ns = 8）。 + +当调度域建立时，复杂性检查是在根域上进行的。如果一个根域的复杂度C恰好高于完全 +主观设定的EM_MAX_COMPLEXITY阈值（在本文写作时，是2048），则EAS不会在此根域 +启动。 + +如果你的平台的能量模型的复杂度太高，EAS无法在这个根域上使用，但你真的想用， +那么你就只剩下两个可能的选择： + + 1. 将你的系统拆分成分离的、较小的、使用独占cpuset的根域，并在每个根域局部 + 启用EAS。这个方案的好处是开箱即用，但缺点是无法在根域之间实现负载均衡， + 这可能会导致总体系统负载不均衡。 + 2. 提交补丁以降低EAS唤醒算法的复杂度，从而使其能够在合理的时间内处理更大 + 的EM。 + + +6.4 - Schedutil监管器 +^^^^^^^^^^^^^^^^^^^^^ + +EAS试图预测CPU在不久的将来会在哪个OPP下运行，以估算它们的能量消耗。为了做到 +这一点，它假定CPU的OPP跟随CPU利用率变化而变化。 + +尽管在实践中很难对这一假设的准确性提供硬性保证（因为，举例来说硬件可能不会做 +它被要求做的事情），相对于其他CPUFreq监管器，schedutil至少_请求_使用利用率 +信号计算的频率。因此，与EAS一起使用的唯一合理的监管器是schedutil，因为它是 +唯一一个在频率请求和能量预测之间提供某种程度的一致性的监管器。 + +不支持将EAS与schedutil之外的任何其它监管器一起使用。 + + +6.5 刻度不变性使用率信号 +^^^^^^^^^^^^^^^^^^^^^^^^ + +为了对不同的CPU和所有的性能状态做出准确的预测，EAS需要频率不变的和CPU不变的 +PELT信号。这些信号可以通过每个体系结构定义的arch_scale{cpu,freq}_capacity() +回调函数获取。 + +不支持在没有实现这两个回调函数的平台上使用EAS。 + + +6.6 多线程（SMT） +^^^^^^^^^^^^^^^^^ + +当前实现的EAS是不感知SMT的，因此无法利用多线程硬件节约能量。EAS认为线程是独立的 +CPU，这实际上对性能和能量消耗都是不利的。 + +不支持在SMT上使用EAS。 -- cgit From 4fbe7b19a9485db0a53efc018fe88db25846c89f Mon Sep 17 00:00:00 2001 From: Ethan Dye Date: Mon, 7 Feb 2022 16:54:42 -0700 Subject: docs: Fix wording in optional zram feature docs This fixes some simple grammar errors in the documentation for zram, specifically errors in the optional feature section of the zram documentation. Signed-off-by: Ethan Dye Link: https://lore.kernel.org/r/20220207235442.95090-1-mrtops03@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/blockdev/zram.rst | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst index 3e11926a4df9..54fe63745ed8 100644 --- a/Documentation/admin-guide/blockdev/zram.rst +++ b/Documentation/admin-guide/blockdev/zram.rst @@ -315,8 +315,8 @@ To use the feature, admin should set up backing device via:: echo /dev/sda5 > /sys/block/zramX/backing_dev -before disksize setting. It supports only partition at this moment. -If admin wants to use incompressible page writeback, they could do via:: +before disksize setting. It supports only partitions at this moment. +If admin wants to use incompressible page writeback, they could do it via:: echo huge > /sys/block/zramX/writeback @@ -341,9 +341,9 @@ Admin can request writeback of those idle pages at right timing via:: echo idle > /sys/block/zramX/writeback -With the command, zram writeback idle pages from memory to the storage. +With the command, zram will writeback idle pages from memory to the storage. -If admin want to write a specific page in zram device to backing device, +If an admin wants to write a specific page in zram device to the backing device, they could write a page index into the interface. echo "page_index=1251" > /sys/block/zramX/writeback @@ -354,7 +354,7 @@ to guarantee storage health for entire product life. To overcome the concern, zram supports "writeback_limit" feature. The "writeback_limit_enable"'s default value is 0 so that it doesn't limit -any writeback. IOW, if admin wants to apply writeback budget, he should +any writeback. IOW, if admin wants to apply writeback budget, they should enable writeback_limit_enable via:: $ echo 1 > /sys/block/zramX/writeback_limit_enable @@ -365,7 +365,7 @@ until admin sets the budget via /sys/block/zramX/writeback_limit. (If admin doesn't enable writeback_limit_enable, writeback_limit's value assigned via /sys/block/zramX/writeback_limit is meaningless.) -If admin want to limit writeback as per-day 400M, he could do it +If admin wants to limit writeback as per-day 400M, they could do it like below:: $ MB_SHIFT=20 @@ -375,16 +375,16 @@ like below:: $ echo 1 > /sys/block/zram0/writeback_limit_enable If admins want to allow further write again once the budget is exhausted, -he could do it like below:: +they could do it like below:: $ echo $((400<>4K_SHIFT)) > \ /sys/block/zram0/writeback_limit -If admin wants to see remaining writeback budget since last set:: +If an admin wants to see the remaining writeback budget since last set:: $ cat /sys/block/zramX/writeback_limit -If admin want to disable writeback limit, he could do:: +If an admin wants to disable writeback limit, they could do:: $ echo 0 > /sys/block/zramX/writeback_limit_enable @@ -393,7 +393,7 @@ system reboot, echo 1 > /sys/block/zramX/reset) so keeping how many of writeback happened until you reset the zram to allocate extra writeback budget in next setting is user's job. -If admin wants to measure writeback count in a certain period, he could +If admin wants to measure writeback count in a certain period, they could know it via /sys/block/zram0/bd_stat's 3rd column. memory tracking -- cgit From 8716ef413aa55d9a25481f84eb54f9d571a1f421 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Tue, 1 Feb 2022 08:59:58 +0900 Subject: docs: pdfdocs: Tweak width params of TOC Sphinx has its own set of width parameters of Table of Contents (TOC) for LaTeX defined in its class definition of sphinxmanual.cls. It also inherits parameters for chapter entries from report.cls of original LaTeX base. However, they are optimized assuming small documents with tens of pages and chapters/sections of less than 10. To cope with some of kernel-doc documents with more than 1000 pages and several tens of chapters/sections, definitions of those parameters need to be adjusted. Unfortunately, those parameters are hard coded in the class definitions and need low-level LaTeX coding tricks to redefine. As Sphinx 1.7.9 does not have \sphinxtableofcontentshook, which defines those parameters in later Sphinx versions, for compatibility with both pre-1.8 and later Sphinx versions, empty the hook altogether and redefine \@pnumwidth, \l@chapter, \l@section, and \@subsection commands originally defined in report.cls. Summary of parameter changes: Width of page number (\@pnumwidth): 1.55em -> 2.7em Width of chapter number: 1.5em -> 1.8em Indent of section number: 1.5em -> 1.8em Width of section number: 2.6em -> 3.2em Indent of subsection number: 4.1em -> 5em Width of subsection number: 3.5em -> 4.3em Notes: 1. Parameters for subsection become relevant only when ":maxdepth: 3" is specified under "toctree::" (e.g., RCU/index.rst). They can hold subsection numbers up to 5 digits such as "18.7.13" (in RCU.pdf). 2. Number of chapters in driver-api.pdf is getting closer to 100. When it reaches 100, another set of tweaks will be necessary. 3. The low-level LaTeX trick is mentioned in "Unofficial LaTeX2e reference manual" at: http://latexref.xyz/Table-of-contents-etc_002e.html Signed-off-by: Akira Yokosawa Cc: Jonathan Corbet Link: https://lore.kernel.org/r/e52b4718-7909-25be-fbc1-76800aa62ae3@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/conf.py | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) (limited to 'Documentation') diff --git a/Documentation/conf.py b/Documentation/conf.py index f07f2e9b9f2c..e5c13dee2de8 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -409,6 +409,37 @@ latex_elements = { # Additional stuff for the LaTeX preamble. 'preamble': ''' + % Custom width parameters for TOC --- Redefine low-level commands + % defined in report.cls + \\makeatletter + %% Redefine \\@pnumwidth (page number width) + \\renewcommand*\\@pnumwidth{2.7em} + %% Redefine \\l@chapter (chapter list entry) + \\renewcommand*\\l@chapter[2]{% + \\ifnum \\c@tocdepth >\\m@ne + \\addpenalty{-\\@highpenalty}% + \\vskip 1.0em \\@plus\\p@ + \\setlength\\@tempdima{1.8em}% + \\begingroup + \\parindent \\z@ \\rightskip \\@pnumwidth + \\parfillskip -\\@pnumwidth + \\leavevmode \\bfseries + \\advance\\leftskip\\@tempdima + \\hskip -\\leftskip + #1\\nobreak\\hfil + \\nobreak\\hb@xt@\\@pnumwidth{\\hss #2% + \\kern-\\p@\\kern\\p@}\\par + \\penalty\\@highpenalty + \\endgroup + \\fi} + %% Redefine \\l@section and \\l@subsection + \\renewcommand*\\l@section{\\@dottedtocline{1}{1.8em}{3.2em}} + \\renewcommand*\\l@subsection{\\@dottedtocline{2}{5em}{4.3em}} + \\makeatother + %% Sphinx < 1.8 doesn't have \\sphinxtableofcontentshook + \\providecommand{\\sphinxtableofcontentshook}{} + %% Undefine it for compatibility with Sphinx 1.7.9 + \\renewcommand{\\sphinxtableofcontentshook}{} % Empty the hook % Prevent column squeezing of tabulary. \\setlength{\\tymin}{20em} % Use some font with UTF-8 support with XeLaTeX -- cgit From 66939df53948bbf66753100266076f6a3357b54c Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Tue, 1 Feb 2022 09:02:14 +0900 Subject: docs: pdfdocs: Switch default CJK font to KR variants xeCJK is enabled in Table of Contents (TOC) so that translations.pdf built by top-level "make pdfdocs" can have its TOC typeset properly. This causes quotation marks and apostrophe symbols appear too wide in Latin-script docs. This is because (1) Sphinx converts ASCII symbols into multi-byte UTF-8 ones in LaTeX and (2) in the SC variant of "Noto CJK" font families, those UTF-8 symbols have full-width glyph. The KR variant of the font families has half-width glyph for those symbols and TOC pages should look nicer when it is used instead. Switch the default CJK font families to the KR variant and teach xeCJK of those symbols' widths. To compensate the switch, teach xeCJK of the width in the SC and TC variants. Signed-off-by: Akira Yokosawa Cc: Jonathan Corbet Link: https://lore.kernel.org/r/0c8ea878-0a6f-ea01-ab45-4e66c5facee9@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/conf.py | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/conf.py b/Documentation/conf.py index e5c13dee2de8..e70aa5fd969f 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -460,13 +460,15 @@ latex_elements['preamble'] += ''' \\IfFontExistsTF{Noto Sans CJK SC}{ % This is needed for translations \\usepackage{xeCJK} - \\IfFontExistsTF{Noto Serif CJK SC}{ - \\setCJKmainfont{Noto Serif CJK SC}[AutoFakeSlant] + \\IfFontExistsTF{Noto Serif CJK KR}{ + \\setCJKmainfont{Noto Serif CJK KR}[AutoFakeSlant] }{ - \\setCJKmainfont{Noto Sans CJK SC}[AutoFakeSlant] + \\setCJKmainfont{Noto Sans CJK KR}[AutoFakeSlant] } - \\setCJKsansfont{Noto Sans CJK SC}[AutoFakeSlant] - \\setCJKmonofont{Noto Sans Mono CJK SC}[AutoFakeSlant] + \\setCJKsansfont{Noto Sans CJK KR}[AutoFakeSlant] + \\setCJKmonofont{Noto Sans Mono CJK KR}[AutoFakeSlant] + \\xeCJKDeclareCharClass{HalfLeft}{`“,`‘} + \\xeCJKDeclareCharClass{HalfRight}{`”,`’} % CJK Language-specific font choices \\IfFontExistsTF{Noto Serif CJK SC}{ \\newCJKfontfamily[SCmain]\\scmain{Noto Serif CJK SC}[AutoFakeSlant] @@ -513,11 +515,18 @@ latex_elements['preamble'] += ''' \\newcommand{\\kerneldocBeginSC}{% \\begingroup% \\scmain% + \\xeCJKDeclareCharClass{FullLeft}{`“,`‘}% + \\xeCJKDeclareCharClass{FullRight}{`”,`’}% + \\renewcommand{\\CJKrmdefault}{SCserif}% + \\renewcommand{\\CJKsfdefault}{SCsans}% + \\renewcommand{\\CJKttdefault}{SCmono}% } \\newcommand{\\kerneldocEndSC}{\\endgroup} \\newcommand{\\kerneldocBeginTC}{% \\begingroup% \\tcmain% + \\xeCJKDeclareCharClass{FullLeft}{`“,`‘}% + \\xeCJKDeclareCharClass{FullRight}{`”,`’}% \\renewcommand{\\CJKrmdefault}{TCserif}% \\renewcommand{\\CJKsfdefault}{TCsans}% \\renewcommand{\\CJKttdefault}{TCmono}% @@ -525,8 +534,6 @@ latex_elements['preamble'] += ''' \\newcommand{\\kerneldocEndTC}{\\endgroup} \\newcommand{\\kerneldocBeginKR}{% \\begingroup% - \\xeCJKDeclareCharClass{HalfLeft}{`“,`‘}% - \\xeCJKDeclareCharClass{HalfRight}{`”,`’}% \\krmain% \\renewcommand{\\CJKrmdefault}{KRserif}% \\renewcommand{\\CJKsfdefault}{KRsans}% @@ -536,8 +543,6 @@ latex_elements['preamble'] += ''' \\newcommand{\\kerneldocEndKR}{\\endgroup} \\newcommand{\\kerneldocBeginJP}{% \\begingroup% - \\xeCJKDeclareCharClass{HalfLeft}{`“,`‘}% - \\xeCJKDeclareCharClass{HalfRight}{`”,`’}% \\jpmain% \\renewcommand{\\CJKrmdefault}{JPserif}% \\renewcommand{\\CJKsfdefault}{JPsans}% -- cgit From 7b686a2ea1e41e75c35ff2ec333d68b2b8c032d6 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Tue, 1 Feb 2022 09:03:16 +0900 Subject: docs: pdfdocs: Enable CJKspace in TOC for Korean titles Korean (Hangul) titles in Table of Contents of translations.pdf don't have inter-phrase spaces. This is because the CJKspace option of xeCJK is disabled by default. Restore the spaces by enabling the option at the beginning of every document and disable it in the \kerneldocBegin{SC|TC|JP} commands. Signed-off-by: Akira Yokosawa Cc: Jonathan Corbet Link: https://lore.kernel.org/r/19141b3e-01d9-1f6d-5020-42fbda784831@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/conf.py | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/conf.py b/Documentation/conf.py index e70aa5fd969f..ded49b8e9bf6 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -520,6 +520,7 @@ latex_elements['preamble'] += ''' \\renewcommand{\\CJKrmdefault}{SCserif}% \\renewcommand{\\CJKsfdefault}{SCsans}% \\renewcommand{\\CJKttdefault}{SCmono}% + \\xeCJKsetup{CJKspace = false}% } \\newcommand{\\kerneldocEndSC}{\\endgroup} \\newcommand{\\kerneldocBeginTC}{% @@ -530,6 +531,7 @@ latex_elements['preamble'] += ''' \\renewcommand{\\CJKrmdefault}{TCserif}% \\renewcommand{\\CJKsfdefault}{TCsans}% \\renewcommand{\\CJKttdefault}{TCmono}% + \\xeCJKsetup{CJKspace = false}% } \\newcommand{\\kerneldocEndTC}{\\endgroup} \\newcommand{\\kerneldocBeginKR}{% @@ -538,7 +540,7 @@ latex_elements['preamble'] += ''' \\renewcommand{\\CJKrmdefault}{KRserif}% \\renewcommand{\\CJKsfdefault}{KRsans}% \\renewcommand{\\CJKttdefault}{KRmono}% - \\xeCJKsetup{CJKspace = true} % For inter-phrase space + % \\xeCJKsetup{CJKspace = true} % true by default } \\newcommand{\\kerneldocEndKR}{\\endgroup} \\newcommand{\\kerneldocBeginJP}{% @@ -547,6 +549,7 @@ latex_elements['preamble'] += ''' \\renewcommand{\\CJKrmdefault}{JPserif}% \\renewcommand{\\CJKsfdefault}{JPsans}% \\renewcommand{\\CJKttdefault}{JPmono}% + \\xeCJKsetup{CJKspace = false}% } \\newcommand{\\kerneldocEndJP}{\\endgroup} % Single spacing in literal blocks @@ -555,6 +558,7 @@ latex_elements['preamble'] += ''' \\usepackage{etoolbox} % Inactivate CJK after tableofcontents \\apptocmd{\\sphinxtableofcontents}{\\kerneldocCJKoff}{}{} + \\xeCJKsetup{CJKspace = true} % For inter-phrase space of Korean TOC }{ % No CJK font found % Custom macros to on/off CJK (Dummy) \\newcommand{\\kerneldocCJKon}{} -- cgit From 5d9158e3c762f0bf1753501d8e64eb6fe19dc437 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Tue, 1 Feb 2022 09:04:40 +0900 Subject: docs/translations: Skip CJK contents if suitable fonts not found On systems without "Noto Sans CJK" fonts, CJK chapters in translations.pdf are full of "TOFU" boxes, with a long build time and a large log file containing lots of missing-font warnings. Avoid such waste of time and resources by skipping CJK chapters when CJK fonts are not available. To skip whole chapters, change the definition of \kerneldocBegin{SC|TC|KR|JP} commands so that they can have an argument to be ignored. This works as far as the argument (#1) is not used in the command. In place of skipped contents, put a note on skipped contents at the beginning of the PDF. Change the call sites in index.rst of CJK translations accordingly. When CJK fonts are available, existing command definitions with no argument just work. LaTeX engine will see additional pairs of "{" and "}", which add a level of grouping without having any effect on typesetting. Signed-off-by: Akira Yokosawa Cc: Jonathan Corbet Link: https://lore.kernel.org/r/3359ca41-b81d-b2c7-e437-7618efbe241d@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/conf.py | 13 +++++++++---- Documentation/translations/ja_JP/index.rst | 4 ++-- Documentation/translations/ko_KR/index.rst | 5 ++--- Documentation/translations/zh_CN/index.rst | 4 ++-- Documentation/translations/zh_TW/index.rst | 4 ++-- 5 files changed, 17 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/conf.py b/Documentation/conf.py index ded49b8e9bf6..62cd0e472b3b 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -563,13 +563,18 @@ latex_elements['preamble'] += ''' % Custom macros to on/off CJK (Dummy) \\newcommand{\\kerneldocCJKon}{} \\newcommand{\\kerneldocCJKoff}{} - \\newcommand{\\kerneldocBeginSC}{} + \\newcommand{\\kerneldocBeginSC}[1]{% + \\begin{sphinxadmonition}{note}{Note:} + ``Noto Sans CJK'' fonts are not found while building this PDF\\@. + Translations of zh\\_CN, zh\\_TW, ko\\_KR, and ja\\_JP are + skipped. + \\end{sphinxadmonition}} \\newcommand{\\kerneldocEndSC}{} - \\newcommand{\\kerneldocBeginTC}{} + \\newcommand{\\kerneldocBeginTC}[1]{} \\newcommand{\\kerneldocEndTC}{} - \\newcommand{\\kerneldocBeginKR}{} + \\newcommand{\\kerneldocBeginKR}[1]{} \\newcommand{\\kerneldocEndKR}{} - \\newcommand{\\kerneldocBeginJP}{} + \\newcommand{\\kerneldocBeginJP}[1]{} \\newcommand{\\kerneldocEndJP}{} } ''' diff --git a/Documentation/translations/ja_JP/index.rst b/Documentation/translations/ja_JP/index.rst index 88d4d98eed15..20738c931d02 100644 --- a/Documentation/translations/ja_JP/index.rst +++ b/Documentation/translations/ja_JP/index.rst @@ -3,7 +3,7 @@ \renewcommand\thesection* \renewcommand\thesubsection* \kerneldocCJKon - \kerneldocBeginJP + \kerneldocBeginJP{ Japanese translations ===================== @@ -15,4 +15,4 @@ Japanese translations .. raw:: latex - \kerneldocEndJP + }\kerneldocEndJP diff --git a/Documentation/translations/ko_KR/index.rst b/Documentation/translations/ko_KR/index.rst index f636b482fb4c..4add6b2fe1f2 100644 --- a/Documentation/translations/ko_KR/index.rst +++ b/Documentation/translations/ko_KR/index.rst @@ -3,7 +3,7 @@ \renewcommand\thesection* \renewcommand\thesubsection* \kerneldocCJKon - \kerneldocBeginKR + \kerneldocBeginKR{ 한국어 번역 =========== @@ -26,5 +26,4 @@ .. raw:: latex - \normalsize - \kerneldocEndKR + }\kerneldocEndKR diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index f831887eacfb..23f8f4c68e83 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -5,7 +5,7 @@ \renewcommand\thesection* \renewcommand\thesubsection* \kerneldocCJKon - \kerneldocBeginSC + \kerneldocBeginSC{ .. _linux_doc_zh: @@ -198,4 +198,4 @@ TODOList: .. raw:: latex - \kerneldocEndSC + }\kerneldocEndSC diff --git a/Documentation/translations/zh_TW/index.rst b/Documentation/translations/zh_TW/index.rst index f56f78ba7860..e1ce9d8c06f8 100644 --- a/Documentation/translations/zh_TW/index.rst +++ b/Documentation/translations/zh_TW/index.rst @@ -5,7 +5,7 @@ \renewcommand\thesection* \renewcommand\thesubsection* \kerneldocCJKon - \kerneldocBeginTC + \kerneldocBeginTC{ .. _linux_doc_zh_tw: @@ -174,4 +174,4 @@ TODOList: .. raw:: latex - \kerneldocEndTC + }\kerneldocEndTC -- cgit From b774cc46313b3d7c9139f29df67818a8b858c558 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Tue, 1 Feb 2022 09:05:40 +0900 Subject: docs: pdfdocs: Move CJK monospace font setting to main conf.py As LaTeX macros for CJK font settings can have Latin-script font settings as well, settings under Documentation/translations/ can be moved to the main conf.py. By this change, translations.pdf built by top-level "make pdfdocs" can have properly aligned ascii-art diagrams except for Korean ones. For the reason of remaining misalignment in Korean diagrams, see changelog of commit a90dad8f610a ("docs: pdfdocs: Add conf.py local to translations for ascii-art alignment"). Signed-off-by: Akira Yokosawa Cc: Jonathan Corbet Link: https://lore.kernel.org/r/eb87790a-03f4-9f29-c8a3-ef2c3e78ca18@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/conf.py | 8 ++++++++ Documentation/translations/conf.py | 12 ------------ 2 files changed, 8 insertions(+), 12 deletions(-) delete mode 100644 Documentation/translations/conf.py (limited to 'Documentation') diff --git a/Documentation/conf.py b/Documentation/conf.py index 62cd0e472b3b..fb8f69fc4d38 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -521,6 +521,8 @@ latex_elements['preamble'] += ''' \\renewcommand{\\CJKsfdefault}{SCsans}% \\renewcommand{\\CJKttdefault}{SCmono}% \\xeCJKsetup{CJKspace = false}% + % For CJK ascii-art alignment + \\setmonofont{Noto Sans Mono CJK SC}[AutoFakeSlant]% } \\newcommand{\\kerneldocEndSC}{\\endgroup} \\newcommand{\\kerneldocBeginTC}{% @@ -532,6 +534,8 @@ latex_elements['preamble'] += ''' \\renewcommand{\\CJKsfdefault}{TCsans}% \\renewcommand{\\CJKttdefault}{TCmono}% \\xeCJKsetup{CJKspace = false}% + % For CJK ascii-art alignment + \\setmonofont{Noto Sans Mono CJK TC}[AutoFakeSlant]% } \\newcommand{\\kerneldocEndTC}{\\endgroup} \\newcommand{\\kerneldocBeginKR}{% @@ -541,6 +545,8 @@ latex_elements['preamble'] += ''' \\renewcommand{\\CJKsfdefault}{KRsans}% \\renewcommand{\\CJKttdefault}{KRmono}% % \\xeCJKsetup{CJKspace = true} % true by default + % For CJK ascii-art alignment (still misaligned for Hangul) + \\setmonofont{Noto Sans Mono CJK KR}[AutoFakeSlant]% } \\newcommand{\\kerneldocEndKR}{\\endgroup} \\newcommand{\\kerneldocBeginJP}{% @@ -550,6 +556,8 @@ latex_elements['preamble'] += ''' \\renewcommand{\\CJKsfdefault}{JPsans}% \\renewcommand{\\CJKttdefault}{JPmono}% \\xeCJKsetup{CJKspace = false}% + % For CJK ascii-art alignment + \\setmonofont{Noto Sans Mono CJK JP}[AutoFakeSlant]% } \\newcommand{\\kerneldocEndJP}{\\endgroup} % Single spacing in literal blocks diff --git a/Documentation/translations/conf.py b/Documentation/translations/conf.py deleted file mode 100644 index 92cdbba74229..000000000000 --- a/Documentation/translations/conf.py +++ /dev/null @@ -1,12 +0,0 @@ -# -*- coding: utf-8 -*- -# SPDX-License-Identifier: GPL-2.0 - -# -- Additinal options for LaTeX output ---------------------------------- -# font config for ascii-art alignment - -latex_elements['preamble'] += ''' - \\IfFontExistsTF{Noto Sans CJK SC}{ - % For CJK ascii-art alignment - \\setmonofont{Noto Sans Mono CJK SC}[AutoFakeSlant] - }{} -''' -- cgit From 4a2e0a806cb58a4d3106add079488e0b56a221b6 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Fri, 30 Jul 2021 15:18:29 +0200 Subject: media: vimc: Add support for contiguous DMA buffers The vimc driver is used for testing purpose, and some test use cases involve sharing buffers with a consumer device. Consumers often require DMA contiguous memory, which vimc doesn't currently support. This leads in the best case to usage of bounce buffers, which is very slow, and in the worst case in a complete failure. Add support for the dma-contig allocator in vimc to support those use cases properly. The allocator is selected through a new "allocator" module parameter, which defaults to vmalloc. [hverkuil: add missing 'select VIDEOBUF2_DMA_CONFIG' to Kconfig] Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/admin-guide/media/vimc.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/media/vimc.rst b/Documentation/admin-guide/media/vimc.rst index 180507d455f2..0b07f05dde25 100644 --- a/Documentation/admin-guide/media/vimc.rst +++ b/Documentation/admin-guide/media/vimc.rst @@ -76,3 +76,16 @@ vimc-capture: * 1 Pad sink * 1 Pad source + +Module options +-------------- + +Vimc has a module parameter to configure the driver. + +* ``allocator=`` + + memory allocator selection, default is 0. It specifies the way buffers + will be allocated. + + - 0: vmalloc + - 1: dma-contig -- cgit From bbbca72352bb9484bc057c91a408332b35ee8f4c Mon Sep 17 00:00:00 2001 From: Vaibhav Jain Date: Tue, 25 Jan 2022 01:52:04 +0530 Subject: powerpc/papr_scm: Implement initial support for injecting smart errors Presently PAPR doesn't support injecting smart errors on an NVDIMM. This makes testing the NVDIMM health reporting functionality difficult as simulating NVDIMM health related events need a hacked up qemu version. To solve this problem this patch proposes simulating certain set of NVDIMM health related events in papr_scm. Specifically 'fatal' health state and 'dirty' shutdown state. These error can be injected via the user-space 'ndctl-inject-smart(1)' command. With the proposed patch and corresponding ndctl patches following command flow is expected: $ sudo ndctl list -DH -d nmem0 ... "health_state":"ok", "shutdown_state":"clean", ... # inject unsafe shutdown and fatal health error $ sudo ndctl inject-smart nmem0 -Uf ... "health_state":"fatal", "shutdown_state":"dirty", ... # uninject all errors $ sudo ndctl inject-smart nmem0 -N ... "health_state":"ok", "shutdown_state":"clean", ... The patch adds a new member 'health_bitmap_inject_mask' inside struct papr_scm_priv which is then bitwise ANDed to the health bitmap fetched from the hypervisor. The value for 'health_bitmap_inject_mask' is accessible from sysfs at nmemX/papr/health_bitmap_inject. A new PDSM named 'SMART_INJECT' is proposed that accepts newly introduced 'struct nd_papr_pdsm_smart_inject' as payload thats exchanged between libndctl and papr_scm to indicate the requested smart-error states. When the processing the PDSM 'SMART_INJECT', papr_pdsm_smart_inject() constructs a pair or 'inject_mask' and 'clear_mask' bitmaps from the payload and bit-blt it to the 'health_bitmap_inject_mask'. This ensures the after being fetched from the hypervisor, the health_bitmap reflects requested smart-error states. Signed-off-by: Vaibhav Jain Signed-off-by: Shivaprasad G Bhat Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220124202204.1488346-1-vaibhav@linux.ibm.com --- Documentation/ABI/testing/sysfs-bus-papr-pmem | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem index 95254cec92bf..4ac0673901e7 100644 --- a/Documentation/ABI/testing/sysfs-bus-papr-pmem +++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem @@ -61,3 +61,15 @@ Description: * "CchRHCnt" : Cache Read Hit Count * "CchWHCnt" : Cache Write Hit Count * "FastWCnt" : Fast Write Count + +What: /sys/bus/nd/devices/nmemX/papr/health_bitmap_inject +Date: Jan, 2022 +KernelVersion: v5.17 +Contact: linuxppc-dev , nvdimm@lists.linux.dev, +Description: + (RO) Reports the health bitmap inject bitmap that is applied to + bitmap received from PowerVM via the H_SCM_HEALTH. This is used + to forcibly set specific bits returned from Hcall. These is then + used to simulate various health or shutdown states for an nvdimm + and are set by user-space tools like ndctl by issuing a PAPR DSM. + -- cgit From 21d26b3972532069f9315f73c0f3128a49d2e014 Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas Date: Mon, 14 Feb 2022 14:39:35 +0100 Subject: dt-bindings: display: ssd1307fb: Add myself as binding co-maintainer The ssd130x DRM driver also makes use of this Device Tree binding to allow existing users of the fbdev driver to migrate without the need to change their Device Trees. Add myself as another maintainer of the binding, to make sure that I will be on Cc when patches are proposed for it. Suggested-by: Sam Ravnborg Signed-off-by: Javier Martinez Canillas Acked-by: Rob Herring Reviewed-by: Andy Shevchenko Acked-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20220214133935.3278933-1-javierm@redhat.com --- Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index 2ed2a7d0ca2f..9baafd0c42dd 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -8,6 +8,7 @@ title: Solomon SSD1307 OLED Controller Framebuffer maintainers: - Maxime Ripard + - Javier Martinez Canillas properties: compatible: -- cgit From c952e5075de1f76e092bc780503ebc5cb8222a01 Mon Sep 17 00:00:00 2001 From: Daniel Palmer Date: Tue, 23 Feb 2021 15:18:23 +0900 Subject: dt-bindings: clk: mstar msc313 cpupll binding description Add a binding description for the MStar/SigmaStar CPU PLL block. Signed-off-by: Daniel Palmer Reviewed-by: Rob Herring --- .../bindings/clock/mstar,msc313-cpupll.yaml | 45 ++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml b/Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml new file mode 100644 index 000000000000..a9ad7ab5230c --- /dev/null +++ b/Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/mstar,msc313-cpupll.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MStar/Sigmastar MSC313 CPU PLL + +maintainers: + - Daniel Palmer + +description: | + The MStar/SigmaStar MSC313 and later ARMv7 chips have a scalable + PLL that can be used as the clock source for the CPU(s). + +properties: + compatible: + const: mstar,msc313-cpupll + + "#clock-cells": + const: 1 + + clocks: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - "#clock-cells" + - clocks + - reg + +additionalProperties: false + +examples: + - | + #include + cpupll: cpupll@206400 { + compatible = "mstar,msc313-cpupll"; + reg = <0x206400 0x200>; + #clock-cells = <1>; + clocks = <&mpll MSTAR_MSC313_MPLL_DIV2>; + }; -- cgit From 122365cfe9deadc14cd2d98c59f283b5021f4897 Mon Sep 17 00:00:00 2001 From: Sankeerth Billakanti Date: Thu, 10 Feb 2022 17:27:31 +0530 Subject: dt-bindings: display: simple: Add sharp LQ140M1JW46 panel Add support for sharp LQ140M1JW46 display panel. It is a 14" eDP panel with 1920x1080 display resolution. Signed-off-by: Sankeerth Billakanti Acked-by: Rob Herring Reviewed-by: Stephen Boyd Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/1644494255-6632-2-git-send-email-quic_sbillaka@quicinc.com --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 9cf5588a09d8..1eb9dd4f8f58 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -284,6 +284,8 @@ properties: - sharp,lq101k1ly04 # Sharp 12.3" (2400x1600 pixels) TFT LCD panel - sharp,lq123p1jx31 + # Sharp 14" (1920x1080 pixels) TFT LCD panel + - sharp,lq140m1jw46 # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel - sharp,ls020b1dd01d # Shelly SCA07010-BFN-LNN 7.0" WVGA TFT LCD panel -- cgit From e1be43d9b5d0d1310dbd90185a8e5c7145dde40f Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Sat, 18 Sep 2021 15:17:53 -0700 Subject: overflow: Implement size_t saturating arithmetic helpers In order to perform more open-coded replacements of common allocation size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for multiplication, addition, and subtraction. For example, it is common in allocators, especially on realloc, to add to an existing size: p = krealloc(map->patch, sizeof(struct reg_sequence) * (map->patch_regs + num_regs), GFP_KERNEL); There is no existing saturating replacement for this calculation, and just leaving the addition open coded inside array_size() could potentially overflow as well. For example, an overflow in an expression for a size_t argument might wrap to zero: array_size(anything, something_at_size_max + 1) == 0 Introduce size_mul(), size_add(), and size_sub() helpers that implicitly promote arguments to size_t and saturated calculations for use in allocations. With these helpers it is also possible to redefine array_size(), array3_size(), flex_array_size(), and struct_size() in terms of the new helpers. As with the check_*_overflow() helpers, the new helpers use __must_check, though what is really desired is a way to make sure that assignment is only to a size_t lvalue. Without this, it's still possible to introduce overflow/underflow via type conversion (i.e. from size_t to int). Enforcing this will currently need to be left to static analysis or future use of -Wconversion. Additionally update the overflow unit tests to force runtime evaluation for the pathological cases. Cc: Rasmus Villemoes Cc: Gustavo A. R. Silva Cc: Nathan Chancellor Cc: Jason Gunthorpe Cc: Nick Desaulniers Cc: Leon Romanovsky Cc: Keith Busch Cc: Len Baker Signed-off-by: Kees Cook --- Documentation/process/deprecated.rst | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst index 388cb19f5dbb..a6e36d9c3d14 100644 --- a/Documentation/process/deprecated.rst +++ b/Documentation/process/deprecated.rst @@ -71,6 +71,9 @@ Instead, the 2-factor form of the allocator should be used:: foo = kmalloc_array(count, size, GFP_KERNEL); +Specifically, kmalloc() can be replaced with kmalloc_array(), and +kzalloc() can be replaced with kcalloc(). + If no 2-factor form is available, the saturate-on-overflow helpers should be used:: @@ -91,9 +94,20 @@ Instead, use the helper:: array usage and switch to a `flexible array member <#zero-length-and-one-element-arrays>`_ instead. -See array_size(), array3_size(), and struct_size(), -for more details as well as the related check_add_overflow() and -check_mul_overflow() family of functions. +For other calculations, please compose the use of the size_mul(), +size_add(), and size_sub() helpers. For example, in the case of:: + + foo = krealloc(current_size + chunk_size * (count - 3), GFP_KERNEL); + +Instead, use the helpers:: + + foo = krealloc(size_add(current_size, + size_mul(chunk_size, + size_sub(count, 3))), GFP_KERNEL); + +For more details, also see array3_size() and flex_array_size(), +as well as the related check_mul_overflow(), check_add_overflow(), +check_sub_overflow(), and check_shl_overflow() family of functions. simple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull() ---------------------------------------------------------------------- -- cgit From 6492eba4fafb5a9715ecf78b7155e88f8f88909a Mon Sep 17 00:00:00 2001 From: Martin Kepplinger Date: Tue, 11 Jan 2022 14:39:36 +0100 Subject: media: dt-binding: media: hynix,hi846: use $defs/port-base port description This fixes "make dt_binding_check": Documentation/devicetree/bindings/media/i2c/hynix,hi846.example.dt.yaml: camera@20: port:endpoint: Unevaluated properties are not allowed ('link-frequencies', 'data-lanes' were unexpected) From schema: Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml [Sakari Ailus: Reword commit message] Fixes: f3ce7200ca18 ("media: dt-bindings: media: document SK Hynix Hi-846 MIPI CSI-2 8M pixel sensor") Reported-by: Geert Uytterhoeven Signed-off-by: Martin Kepplinger Reviewed-by: Laurent Pinchart Reviewed-by: Rob Herring Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml index 85a8877c2f38..5d0fc18a2ea2 100644 --- a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml +++ b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml @@ -49,7 +49,8 @@ properties: description: Definition of the regulator used for the VDDD power supply. port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false properties: endpoint: -- cgit From a44b8e8c9b2615ea7cf2361cbca3c1dff8119c87 Mon Sep 17 00:00:00 2001 From: Martin Kepplinger Date: Tue, 11 Jan 2022 14:39:37 +0100 Subject: media: dt-bindings: media: hynix,hi846: add link-frequencies description link-frequencies is required but only mentioned in the example. Add it to the description. Fixes: f3ce7200ca18 ("media: dt-bindings: media: document SK Hynix Hi-846 MIPI CSI-2 8M pixel sensor") Signed-off-by: Martin Kepplinger Reviewed-by: Laurent Pinchart Reviewed-by: Rob Herring Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml index 5d0fc18a2ea2..1e2df8cf2937 100644 --- a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml +++ b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml @@ -69,8 +69,11 @@ properties: - const: 1 - const: 2 + link-frequencies: true + required: - data-lanes + - link-frequencies required: - compatible -- cgit From 2da0d487781b2b27c1e114976257f455eb25def4 Mon Sep 17 00:00:00 2001 From: Jérôme Pouiller Date: Thu, 17 Feb 2022 11:32:48 +0100 Subject: staging: wfx: fix DT bindings location MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, the DT bindings the wfx driver cannot be processed by make dt_binding_check. We need to place it somewhere into Documentation/devicetree/bindings/. After that change, we are able to get warnings from dt_binding_check and fix them. Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20220217103248.183770-1-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman --- .../bindings/staging/net/wireless/silabs,wfx.yaml | 137 +++++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml b/Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml new file mode 100644 index 000000000000..105725a127ab --- /dev/null +++ b/Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020, Silicon Laboratories, Inc. +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/staging/net/wireless/silabs,wfx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silicon Labs WFxxx devicetree bindings + +maintainers: + - Jérôme Pouiller + +description: > + Support for the Wifi chip WFxxx from Silicon Labs. Currently, the only device + from the WFxxx series is the WF200 described here: + https://www.silabs.com/documents/public/data-sheets/wf200-datasheet.pdf + + The WF200 can be connected via SPI or via SDIO. + + For SDIO: + + Declaring the WFxxx chip in device tree is mandatory (usually, the VID/PID is + sufficient for the SDIO devices). + + It is recommended to declare a mmc-pwrseq on SDIO host above WFx. Without + it, you may encounter issues during reboot. The mmc-pwrseq should be + compatible with mmc-pwrseq-simple. Please consult + Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml for more + information. + + For SPI: + + In add of the properties below, please consult + Documentation/devicetree/bindings/spi/spi-controller.yaml for optional SPI + related properties. + +properties: + compatible: + items: + - enum: + - silabs,brd4001a # WGM160P Evaluation Board + - silabs,brd8022a # WF200 Evaluation Board + - silabs,brd8023a # WFM200 Evaluation Board + - const: silabs,wf200 # Chip alone without antenna + + reg: + description: + When used on SDIO bus, must be set to 1. When used on SPI bus, it is + the chip select address of the device as defined in the SPI devices + bindings. + maxItems: 1 + + spi-max-frequency: true + + interrupts: + description: The interrupt line. Should be IRQ_TYPE_EDGE_RISING. When SPI is + used, this property is required. When SDIO is used, the "in-band" + interrupt provided by the SDIO bus is used unless an interrupt is defined + in the Device Tree. + maxItems: 1 + + reset-gpios: + description: (SPI only) Phandle of gpio that will be used to reset chip + during probe. Without this property, you may encounter issues with warm + boot. + + For SDIO, the reset gpio should declared using a mmc-pwrseq. + maxItems: 1 + + wakeup-gpios: + description: Phandle of gpio that will be used to wake-up chip. Without this + property, driver will disable most of power saving features. + maxItems: 1 + + silabs,antenna-config-file: + $ref: /schemas/types.yaml#/definitions/string + description: Use an alternative file for antenna configuration (aka + "Platform Data Set" in Silabs jargon). Default depends of "compatible" + string. For "silabs,wf200", the default is 'wf200.pds'. + + local-mac-address: true + + mac-address: true + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + #include + #include + + spi { + #address-cells = <1>; + #size-cells = <0>; + + wifi@0 { + compatible = "silabs,brd8022a", "silabs,wf200"; + pinctrl-names = "default"; + pinctrl-0 = <&wfx_irq &wfx_gpios>; + reg = <0>; + interrupts-extended = <&gpio 16 IRQ_TYPE_EDGE_RISING>; + wakeup-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>; + spi-max-frequency = <42000000>; + }; + }; + + - | + #include + #include + + wfx_pwrseq: wfx_pwrseq { + compatible = "mmc-pwrseq-simple"; + pinctrl-names = "default"; + pinctrl-0 = <&wfx_reset>; + reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>; + }; + + mmc { + mmc-pwrseq = <&wfx_pwrseq>; + #address-cells = <1>; + #size-cells = <0>; + + wifi@1 { + compatible = "silabs,brd8022a", "silabs,wf200"; + pinctrl-names = "default"; + pinctrl-0 = <&wfx_wakeup>; + reg = <1>; + wakeup-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>; + }; + }; +... -- cgit From 3fa891093bd1f2b6d89e5bedabe81cc7503d392f Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Sun, 13 Feb 2022 23:01:14 -0600 Subject: dt-bindings: vendor-prefixes: Add willsemi Add prefix for Will Semiconductor Co. Ltd. (http://www.willsemi.com/) Acked-by: Rob Herring Signed-off-by: Samuel Holland Link: https://lore.kernel.org/r/20220214050118.61015-2-samuel@sholland.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 294093d45a23..a8ab97717a46 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1340,6 +1340,8 @@ patternProperties: description: Wi2Wi, Inc. "^wiligear,.*": description: Wiligear, Ltd. + "^willsemi,.*": + description: Will Semiconductor Ltd. "^winbond,.*": description: Winbond Electronics corp. "^wingtech,.*": -- cgit From 71c16066a53f6ac7e925476070c4dbecfbeceee0 Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Sun, 13 Feb 2022 23:01:15 -0600 Subject: dt-bindings: usb: Add WUSB3801 Type-C Port Controller Add devicetree support for the Will Semiconductor WUSB3801. This is a basic non-PD Type-C port controller. Reviewed-by: Rob Herring Signed-off-by: Samuel Holland Link: https://lore.kernel.org/r/20220214050118.61015-3-samuel@sholland.org Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/willsemi,wusb3801.yaml | 75 ++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/willsemi,wusb3801.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/willsemi,wusb3801.yaml b/Documentation/devicetree/bindings/usb/willsemi,wusb3801.yaml new file mode 100644 index 000000000000..c2b2243c7892 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/willsemi,wusb3801.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/willsemi,wusb3801.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WUSB3801 Type-C port controller DT bindings + +description: + The Will Semiconductor WUSB3801 is a USB Type-C port controller which + supports role and plug orientation detection using the CC pins. It is + compatible with the USB Type-C Cable and Connector Specification v1.2. + +maintainers: + - Samuel Holland + +properties: + compatible: + enum: + - willsemi,wusb3801 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + connector: + type: object + $ref: ../connector/usb-connector.yaml# + description: + The managed USB Type-C connector. Since WUSB3801 does not support + Power Delivery, the node should have the "pd-disable" property. + + properties: + compatible: + const: usb-c-connector + + required: + - pd-disable + +required: + - compatible + - reg + - interrupts + - connector + +additionalProperties: false + +examples: + - | + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + tcpc@60 { + compatible = "willsemi,wusb3801"; + reg = <0x60>; + interrupt-parent = <&gpio0>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + + connector { + compatible = "usb-c-connector"; + label = "USB-C"; + vbus-supply = <&otg_switch>; + power-role = "dual"; + try-power-role = "sink"; + data-role = "dual"; + typec-power-opmode = "default"; + pd-disable; + }; + }; + }; -- cgit From 2e8185fccd63f008987d55d1b4d69bf1e050bc02 Mon Sep 17 00:00:00 2001 From: Nick Hawkins Date: Thu, 10 Feb 2022 11:59:11 -0600 Subject: dt-bindings: vendor-prefixes: add HPE Prefix Description: This patch adds the Hewlett Packard Enterprise prefix that will be used for upcoming support in the HPE BMC GXP. Signed-off-by: Nick Hawkins Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220210175912.102159-1-nick.hawkins@hpe.com --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 6136dafe4853..913f722a6b8d 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -515,6 +515,8 @@ patternProperties: description: Jiangsu HopeRun Software Co., Ltd. "^hp,.*": description: Hewlett Packard Inc. + "^hpe,.*": + description: Hewlett Packard Enterprise "^hsg,.*": description: HannStar Display Co. "^holtek,.*": -- cgit From c8f2ad6869b56233ba4d00dc090e11bb41a55205 Mon Sep 17 00:00:00 2001 From: Tudor Ambarus Date: Fri, 11 Feb 2022 11:39:20 +0200 Subject: dt-bindings: crypto: Convert Atmel AES to yaml Convert Atmel AES documentation to yaml format. With the conversion the clock and clock-names properties are made mandatory. The driver returns -EINVAL if "aes_clk" is not found, reflect that in the bindings and make the clock and clock-names properties mandatory. Update the example to better describe how one should define the dt node. Signed-off-by: Tudor Ambarus Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220211093922.456634-2-tudor.ambarus@microchip.com --- .../bindings/crypto/atmel,at91sam9g46-aes.yaml | 66 ++++++++++++++++++++++ .../devicetree/bindings/crypto/atmel-crypto.txt | 20 ------- 2 files changed, 66 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml new file mode 100644 index 000000000000..0ccaab16dc61 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/atmel,at91sam9g46-aes.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel Advanced Encryption Standard (AES) HW cryptographic accelerator + +maintainers: + - Tudor Ambarus + +properties: + compatible: + const: atmel,at91sam9g46-aes + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: aes_clk + + dmas: + items: + - description: TX DMA Channel + - description: RX DMA Channel + + dma-names: + items: + - const: tx + - const: rx + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + + aes: crypto@e1810000 { + compatible = "atmel,at91sam9g46-aes"; + reg = <0xe1810000 0x100>; + interrupts = ; + clocks = <&pmc PMC_TYPE_PERIPHERAL 27>; + clock-names = "aes_clk"; + dmas = <&dma0 AT91_XDMAC_DT_PERID(1)>, + <&dma0 AT91_XDMAC_DT_PERID(2)>; + dma-names = "tx", "rx"; + }; diff --git a/Documentation/devicetree/bindings/crypto/atmel-crypto.txt b/Documentation/devicetree/bindings/crypto/atmel-crypto.txt index f2aab3dc2b52..1353ebd0dcaa 100644 --- a/Documentation/devicetree/bindings/crypto/atmel-crypto.txt +++ b/Documentation/devicetree/bindings/crypto/atmel-crypto.txt @@ -2,26 +2,6 @@ These are the HW cryptographic accelerators found on some Atmel products. -* Advanced Encryption Standard (AES) - -Required properties: -- compatible : Should be "atmel,at91sam9g46-aes". -- reg: Should contain AES registers location and length. -- interrupts: Should contain the IRQ line for the AES. -- dmas: List of two DMA specifiers as described in - atmel-dma.txt and dma.txt files. -- dma-names: Contains one identifier string for each DMA specifier - in the dmas property. - -Example: -aes@f8038000 { - compatible = "atmel,at91sam9g46-aes"; - reg = <0xf8038000 0x100>; - interrupts = <43 4 0>; - dmas = <&dma1 2 18>, - <&dma1 2 19>; - dma-names = "tx", "rx"; - * Triple Data Encryption Standard (Triple DES) Required properties: -- cgit From d63b583f681e7999fde293142f6cbc0f2a766b64 Mon Sep 17 00:00:00 2001 From: Tudor Ambarus Date: Fri, 11 Feb 2022 11:39:21 +0200 Subject: dt-bindings: crypto: Convert Atmel TDES to yaml Convert Atmel TDES documentation to yaml format. With the conversion the clock and clock-names properties are made mandatory. The driver returns -EINVAL if "tdes_clk" is not found, reflect that in the bindings and make the clock and clock-names properties mandatory. Update the example to better describe how one should define the dt node. Signed-off-by: Tudor Ambarus Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220211093922.456634-3-tudor.ambarus@microchip.com --- .../bindings/crypto/atmel,at91sam9g46-tdes.yaml | 64 ++++++++++++++++++++++ .../devicetree/bindings/crypto/atmel-crypto.txt | 23 -------- 2 files changed, 64 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml new file mode 100644 index 000000000000..fcc5adf03cad --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/atmel,at91sam9g46-tdes.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel Triple Data Encryption Standard (TDES) HW cryptographic accelerator + +maintainers: + - Tudor Ambarus + +properties: + compatible: + const: atmel,at91sam9g46-tdes + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: tdes_clk + + dmas: + items: + - description: TX DMA Channel + - description: RX DMA Channel + + dma-names: + items: + - const: tx + - const: rx + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + + tdes: crypto@e2014000 { + compatible = "atmel,at91sam9g46-tdes"; + reg = <0xe2014000 0x100>; + interrupts = ; + clocks = <&pmc PMC_TYPE_PERIPHERAL 96>; + clock-names = "tdes_clk"; + dmas = <&dma0 AT91_XDMAC_DT_PERID(54)>, + <&dma0 AT91_XDMAC_DT_PERID(53)>; + dma-names = "tx", "rx"; + }; diff --git a/Documentation/devicetree/bindings/crypto/atmel-crypto.txt b/Documentation/devicetree/bindings/crypto/atmel-crypto.txt index 1353ebd0dcaa..5c6541cfcc4a 100644 --- a/Documentation/devicetree/bindings/crypto/atmel-crypto.txt +++ b/Documentation/devicetree/bindings/crypto/atmel-crypto.txt @@ -2,29 +2,6 @@ These are the HW cryptographic accelerators found on some Atmel products. -* Triple Data Encryption Standard (Triple DES) - -Required properties: -- compatible : Should be "atmel,at91sam9g46-tdes". -- reg: Should contain TDES registers location and length. -- interrupts: Should contain the IRQ line for the TDES. - -Optional properties: -- dmas: List of two DMA specifiers as described in - atmel-dma.txt and dma.txt files. -- dma-names: Contains one identifier string for each DMA specifier - in the dmas property. - -Example: -tdes@f803c000 { - compatible = "atmel,at91sam9g46-tdes"; - reg = <0xf803c000 0x100>; - interrupts = <44 4 0>; - dmas = <&dma1 2 20>, - <&dma1 2 21>; - dma-names = "tx", "rx"; -}; - * Secure Hash Algorithm (SHA) Required properties: -- cgit From 44c75c9e3d08b430a9f002a087f2da255909b8ff Mon Sep 17 00:00:00 2001 From: Tudor Ambarus Date: Fri, 11 Feb 2022 11:39:22 +0200 Subject: dt-bindings: crypto: Convert Atmel SHA to yaml Convert Atmel SHA documentation to yaml format. With the conversion the clock and clock-names properties are made mandatory. The driver returns -EINVAL if "sha_clk" is not found, reflect that in the bindings and make the clock and clock-names properties mandatory. Update the example to better describe how one should define the dt node. Signed-off-by: Tudor Ambarus Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220211093922.456634-4-tudor.ambarus@microchip.com --- .../bindings/crypto/atmel,at91sam9g46-sha.yaml | 60 ++++++++++++++++++++++ .../devicetree/bindings/crypto/atmel-crypto.txt | 25 --------- 2 files changed, 60 insertions(+), 25 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml delete mode 100644 Documentation/devicetree/bindings/crypto/atmel-crypto.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml new file mode 100644 index 000000000000..5163c51b4547 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/atmel,at91sam9g46-sha.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel Secure Hash Algorithm (SHA) HW cryptographic accelerator + +maintainers: + - Tudor Ambarus + +properties: + compatible: + const: atmel,at91sam9g46-sha + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: sha_clk + + dmas: + maxItems: 1 + description: TX DMA Channel + + dma-names: + const: tx + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + + sha: crypto@e1814000 { + compatible = "atmel,at91sam9g46-sha"; + reg = <0xe1814000 0x100>; + interrupts = ; + clocks = <&pmc PMC_TYPE_PERIPHERAL 83>; + clock-names = "sha_clk"; + dmas = <&dma0 AT91_XDMAC_DT_PERID(48)>; + dma-names = "tx"; + }; diff --git a/Documentation/devicetree/bindings/crypto/atmel-crypto.txt b/Documentation/devicetree/bindings/crypto/atmel-crypto.txt deleted file mode 100644 index 5c6541cfcc4a..000000000000 --- a/Documentation/devicetree/bindings/crypto/atmel-crypto.txt +++ /dev/null @@ -1,25 +0,0 @@ -* Atmel HW cryptographic accelerators - -These are the HW cryptographic accelerators found on some Atmel products. - -* Secure Hash Algorithm (SHA) - -Required properties: -- compatible : Should be "atmel,at91sam9g46-sha". -- reg: Should contain SHA registers location and length. -- interrupts: Should contain the IRQ line for the SHA. - -Optional properties: -- dmas: One DMA specifiers as described in - atmel-dma.txt and dma.txt files. -- dma-names: Contains one identifier string for each DMA specifier - in the dmas property. Only one "tx" string needed. - -Example: -sha@f8034000 { - compatible = "atmel,at91sam9g46-sha"; - reg = <0xf8034000 0x100>; - interrupts = <42 4 0>; - dmas = <&dma1 2 17>; - dma-names = "tx"; -}; -- cgit From 5d16dcd252fd3f77d1579342b78d947033065d64 Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Fri, 11 Feb 2022 12:01:57 +0000 Subject: dt-bindings: convert ata/cortina,gemini-sata-bridge to yaml This patch converts ata/cortina,gemini-sata-bridge binding to yaml Reviewed-by: Krzysztof Kozlowski Reviewed-by: Linus Walleij Acked-by: Damien Le Moal Signed-off-by: Corentin Labbe Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220211120157.3385145-1-clabbe@baylibre.com --- .../bindings/ata/cortina,gemini-sata-bridge.txt | 55 ----------- .../bindings/ata/cortina,gemini-sata-bridge.yaml | 109 +++++++++++++++++++++ 2 files changed, 109 insertions(+), 55 deletions(-) delete mode 100644 Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt create mode 100644 Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt deleted file mode 100644 index 1c3d3cc70051..000000000000 --- a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt +++ /dev/null @@ -1,55 +0,0 @@ -* Cortina Systems Gemini SATA Bridge - -The Gemini SATA bridge in a SoC-internal PATA to SATA bridge that -takes two Faraday Technology FTIDE010 PATA controllers and bridges -them in different configurations to two SATA ports. - -Required properties: -- compatible: should be - "cortina,gemini-sata-bridge" -- reg: registers and size for the block -- resets: phandles to the reset lines for both SATA bridges -- reset-names: must be "sata0", "sata1" -- clocks: phandles to the compulsory peripheral clocks -- clock-names: must be "SATA0_PCLK", "SATA1_PCLK" -- syscon: a phandle to the global Gemini system controller -- cortina,gemini-ata-muxmode: tell the desired multiplexing mode for - the ATA controller and SATA bridges. Values 0..3: - Mode 0: ata0 master <-> sata0 - ata1 master <-> sata1 - ata0 slave interface brought out on IDE pads - Mode 1: ata0 master <-> sata0 - ata1 master <-> sata1 - ata1 slave interface brought out on IDE pads - Mode 2: ata1 master <-> sata1 - ata1 slave <-> sata0 - ata0 master and slave interfaces brought out - on IDE pads - Mode 3: ata0 master <-> sata0 - ata0 slave <-> sata1 - ata1 master and slave interfaces brought out - on IDE pads - -Optional boolean properties: -- cortina,gemini-enable-ide-pins: enables the PATA to IDE connection. - The muxmode setting decides whether ATA0 or ATA1 is brought out, - and whether master, slave or both interfaces get brought out. -- cortina,gemini-enable-sata-bridge: enables the PATA to SATA bridge - inside the Gemnini SoC. The Muxmode decides what PATA blocks will - be muxed out and how. - -Example: - -sata: sata@46000000 { - compatible = "cortina,gemini-sata-bridge"; - reg = <0x46000000 0x100>; - resets = <&rcon 26>, <&rcon 27>; - reset-names = "sata0", "sata1"; - clocks = <&gcc GEMINI_CLK_GATE_SATA0>, - <&gcc GEMINI_CLK_GATE_SATA1>; - clock-names = "SATA0_PCLK", "SATA1_PCLK"; - syscon = <&syscon>; - cortina,gemini-ata-muxmode = <3>; - cortina,gemini-enable-ide-pins; - cortina,gemini-enable-sata-bridge; -}; diff --git a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml new file mode 100644 index 000000000000..21a90975593b --- /dev/null +++ b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml @@ -0,0 +1,109 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/cortina,gemini-sata-bridge.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cortina Systems Gemini SATA Bridge + +maintainers: + - Linus Walleij + +description: | + The Gemini SATA bridge in a SoC-internal PATA to SATA bridge that + takes two Faraday Technology FTIDE010 PATA controllers and bridges + them in different configurations to two SATA ports. + +properties: + compatible: + const: cortina,gemini-sata-bridge + + reg: + maxItems: 1 + + resets: + minItems: 2 + maxItems: 2 + description: phandles to the reset lines for both SATA bridges + + reset-names: + items: + - const: sata0 + - const: sata1 + + clocks: + minItems: 2 + maxItems: 2 + description: phandles to the compulsory peripheral clocks + + clock-names: + items: + - const: SATA0_PCLK + - const: SATA1_PCLK + + syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: a phandle to the global Gemini system controller + + cortina,gemini-ata-muxmode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 + - 1 + - 2 + - 3 + description: | + Tell the desired multiplexing mode for the ATA controller and SATA + bridges. + Mode 0: ata0 master <-> sata0 + ata1 master <-> sata1 + ata0 slave interface brought out on IDE pads + Mode 1: ata0 master <-> sata0 + ata1 master <-> sata1 + ata1 slave interface brought out on IDE pads + Mode 2: ata1 master <-> sata1 + ata1 slave <-> sata0 + ata0 master and slave interfaces brought out on IDE pads + Mode 3: ata0 master <-> sata0 + ata0 slave <-> sata1 + ata1 master and slave interfaces brought out on IDE pads + + cortina,gemini-enable-ide-pins: + type: boolean + description: Enables the PATA to IDE connection. + The muxmode setting decides whether ATA0 or ATA1 is brought out, + and whether master, slave or both interfaces get brought out. + + cortina,gemini-enable-sata-bridge: + type: boolean + description: Enables the PATA to SATA bridge inside the Gemnini SoC. + The Muxmode decides what PATA blocks will be muxed out and how. + +required: + - clocks + - clock-names + - cortina,gemini-ata-muxmode + - resets + - reset-names + - compatible + - reg + - syscon + +additionalProperties: false + +examples: + - | + #include + sata@46000000 { + compatible = "cortina,gemini-sata-bridge"; + reg = <0x46000000 0x100>; + resets = <&rcon 26>, <&rcon 27>; + reset-names = "sata0", "sata1"; + clocks = <&gcc GEMINI_CLK_GATE_SATA0>, + <&gcc GEMINI_CLK_GATE_SATA1>; + clock-names = "SATA0_PCLK", "SATA1_PCLK"; + syscon = <&syscon>; + cortina,gemini-ata-muxmode = <3>; + cortina,gemini-enable-ide-pins; + cortina,gemini-enable-sata-bridge; + }; -- cgit From 9036ff626579b1d92edfd0881d6b283e9995c16d Mon Sep 17 00:00:00 2001 From: Vladimir Zapolskiy Date: Thu, 3 Feb 2022 18:46:28 +0200 Subject: dt-bindings: i2c: qcom-cci: add QCOM SM8450 compatible The change adds QCOM SM8450 compatible value to the list of QCOM CCI controller compatibles, the controller found on the SoC is equal to the ones found on previous SoC generations. Signed-off-by: Vladimir Zapolskiy Reviewed-by: Robert Foss Acked-by: Rob Herring Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt b/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt index 7b9fc0c22eaf..924ad8c03464 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt @@ -10,6 +10,7 @@ PROPERTIES: "qcom,msm8996-cci" "qcom,sdm845-cci" "qcom,sm8250-cci" + "qcom,sm8450-cci" - reg Usage: required @@ -43,7 +44,8 @@ PROPERTIES: SUBNODES: The CCI provides I2C masters for one (msm8916) or two i2c busses (msm8996, -sdm845 and sm8250), described as subdevices named "i2c-bus@0" and "i2c-bus@1". +sdm845, sm8250 and sm8450), described as subdevices named "i2c-bus@0" and +"i2c-bus@1". PROPERTIES: -- cgit From 3ee61082b4204b50391b2aa10bfc3ae3ceac09b1 Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Wed, 2 Feb 2022 17:50:46 -0600 Subject: dt-bindings: vendor-prefixes: Add silan vendor prefix Hangzhou Silan Microelectronics Co., Ltd. (http://www.silan.com.cn/) is a manufacturer of ICs, including MEMS sensors. Signed-off-by: Samuel Holland Acked-by: Rob Herring Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20220202235049.8051-2-samuel@sholland.org Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 294093d45a23..b923be2c8172 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1082,6 +1082,8 @@ patternProperties: description: Silicon Image "^silabs,.*": description: Silicon Laboratories + "^silan,.*": + description: Hangzhou Silan Microelectronics Co., Ltd. "^silead,.*": description: Silead Inc. "^silergy,.*": -- cgit From cb432e7dda793bd3e1821a3bacc23fe07630e80a Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Wed, 2 Feb 2022 17:50:47 -0600 Subject: dt-bindings: iio: st: Add Silan SC7A20 accelerometer This chip is not an ST part, but it appears to be register-compatible with the LIS2DH, so it can use the same binding. Signed-off-by: Samuel Holland Acked-by: Rob Herring Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20220202235049.8051-3-samuel@sholland.org Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/st,st-sensors.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml index 71de5631ebae..9735a2048255 100644 --- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml +++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml @@ -46,6 +46,9 @@ properties: - st,lsm330d-accel - st,lsm330dl-accel - st,lsm330dlc-accel + - description: Silan Accelerometers + enum: + - silan,sc7a20 - description: STMicroelectronics Gyroscopes enum: - st,l3g4200d-gyro -- cgit From 438356e5151b929af90e501b9c6dd1f3ea2fc7c4 Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Fri, 11 Feb 2022 12:08:42 +0000 Subject: dt-bindings: mtd: drop mtd/cortina,gemini-flash.txt Drop mtd/cortina,gemini-flash.txt since it is nearly already handled by Documentation/devicetree/bindings/mtd/mtd-physmap.yaml. We add jedec-flash to list of compatible because one board (gemini-dlink-dns-313.dts) needs it. See commit a10d862e585e ("ARM: dts: Fix the DNS-313 flash compatible") The flash on the DNS-313 needs to be probed as JEDEC, it does not conform to the common CFI standard. Reviewed-by: Linus Walleij Signed-off-by: Corentin Labbe Reviewed-by: Rob Herring Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220211120842.3388592-1-clabbe@baylibre.com --- .../bindings/mtd/cortina,gemini-flash.txt | 24 ---------------------- .../devicetree/bindings/mtd/mtd-physmap.yaml | 18 +++++++++++++++- 2 files changed, 17 insertions(+), 25 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt b/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt deleted file mode 100644 index efa5b2aba829..000000000000 --- a/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt +++ /dev/null @@ -1,24 +0,0 @@ -Flash device on Cortina Systems Gemini SoC - -This flash is regular CFI compatible (Intel or AMD extended) flash chips with -some special bits that can be controlled by the machine's system controller. - -Required properties: -- compatible : must be "cortina,gemini-flash", "cfi-flash"; -- reg : memory address for the flash chip -- syscon : must be a phandle to the system controller -- bank-width : width in bytes of flash interface, should be <2> - -For the rest of the properties, see mtd-physmap.yaml. - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Example: - -flash@30000000 { - compatible = "cortina,gemini-flash", "cfi-flash"; - reg = <0x30000000 0x01000000>; - syscon = <&syscon>; - bank-width = <2>; -}; diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml index f827984936f6..82eb4e0f453b 100644 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml @@ -44,7 +44,9 @@ properties: - numonyx,js28f128 - sst,sst39vf320 - xlnx,xps-mch-emc-2.00.a - - const: cfi-flash + - enum: + - cfi-flash + - jedec-flash - items: - enum: - cypress,cy7c1019dv33-10zsxi @@ -127,6 +129,20 @@ required: - compatible - reg +if: + properties: + compatible: + contains: + const: cortina,gemini-flash +then: + properties: + syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon controller + required: + - syscon + # FIXME: A parent bus may define timing properties additionalProperties: true -- cgit From cb57fae479be41d1233f5a49d4760de9a5692b6e Mon Sep 17 00:00:00 2001 From: Christophe Kerello Date: Thu, 17 Feb 2022 15:47:52 +0100 Subject: dt-binding: mtd: nand: Document the wp-gpios property A few drivers use this property to describe the GPIO pin used to protect the NAND during program/erase operations. Signed-off-by: Christophe Kerello Acked-by: Rob Herring Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220217144755.270679-2-christophe.kerello@foss.st.com --- Documentation/devicetree/bindings/mtd/nand-controller.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index bd217e6f5018..53b21aed0ac5 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -154,6 +154,13 @@ patternProperties: Ready/Busy pins. Active state refers to the NAND ready state and should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted. + wp-gpios: + description: + Contains one GPIO descriptor for the Write Protect pin. + Active state refers to the NAND Write Protect state and should be + set to GPIOD_ACTIVE_LOW unless the signal is inverted. + maxItems: 1 + secure-regions: $ref: /schemas/types.yaml#/definitions/uint64-matrix description: -- cgit From f5408b21e356f2b57efcb3e2dbb5a344a20d11ae Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Mon, 27 Dec 2021 20:59:34 -0800 Subject: drm/msm/dp: Add DisplayPort controller for SM8350 The Qualcomm SM8350 platform comes with a single DisplayPort controller, add support for this in the DisplayPort driver. Signed-off-by: Bjorn Andersson Acked-by: Rob Herring Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20211228045934.1524865-1-bjorn.andersson@linaro.org Signed-off-by: Dmitry Baryshkov --- Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index 5457612ab136..cd05cfd76536 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -21,6 +21,7 @@ properties: - qcom,sc7280-edp - qcom,sc8180x-dp - qcom,sc8180x-edp + - qcom,sm8350-dp reg: items: -- cgit From 3bcf3d8341080a7f79d8566aeadbd3c911391cfe Mon Sep 17 00:00:00 2001 From: Rajeev Nandan Date: Mon, 31 Jan 2022 01:45:17 +0530 Subject: dt-bindings: msm/dsi: Add 10nm dsi phy tuning properties In most cases, the default values of DSI PHY tuning registers should be sufficient as they are fully optimized. However, in some cases where extreme board parasitics cause the eye shape to degrade, the override bits can be used to improve the signal quality. The general guidelines for DSI PHY tuning include: - High and moderate data rates may benefit from the drive strength and drive level tuning. - Drive strength tuning will affect the output impedance and may be used for matching optimization. - Drive level tuning will affect the output levels without affecting the impedance. The clock and data lanes have a calibration circuitry feature. The drive strength tuning can be done by adjusting rescode offset for hstop/hsbot, and the drive level tuning can be done by adjusting the LDO output level for the HSTX drive. Signed-off-by: Rajeev Nandan Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1643573719-32095-2-git-send-email-quic_rajeevny@quicinc.com Signed-off-by: Dmitry Baryshkov --- .../bindings/display/msm/dsi-phy-10nm.yaml | 36 ++++++++++++++++++++++ 1 file changed, 36 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml index 4399715953e1..2d5a766d028f 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml @@ -35,6 +35,38 @@ properties: Connected to DSI0_MIPI_DSI_PLL_VDDA0P9 pin for sc7180 target and connected to VDDA_MIPI_DSI_0_PLL_0P9 pin for sdm845 target + qcom,phy-rescode-offset-top: + $ref: /schemas/types.yaml#/definitions/int8-array + minItems: 5 + maxItems: 5 + description: + Integer array of offset for pull-up legs rescode for all five lanes. + To offset the drive strength from the calibrated value in an increasing + manner, -32 is the weakest and +31 is the strongest. + items: + minimum: -32 + maximum: 31 + + qcom,phy-rescode-offset-bot: + $ref: /schemas/types.yaml#/definitions/int8-array + minItems: 5 + maxItems: 5 + description: + Integer array of offset for pull-down legs rescode for all five lanes. + To offset the drive strength from the calibrated value in a decreasing + manner, -32 is the weakest and +31 is the strongest. + items: + minimum: -32 + maximum: 31 + + qcom,phy-drive-ldo-level: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: + The PHY LDO has an amplitude tuning feature to adjust the LDO output + for the HSTX drive. Use supported levels (mV) to offset the drive level + from the default value. + enum: [ 375, 400, 425, 450, 475, 500 ] + required: - compatible - reg @@ -64,5 +96,9 @@ examples: clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, <&rpmhcc RPMH_CXO_CLK>; clock-names = "iface", "ref"; + + qcom,phy-rescode-offset-top = /bits/ 8 <0 0 0 0 0>; + qcom,phy-rescode-offset-bot = /bits/ 8 <0 0 0 0 0>; + qcom,phy-drive-ldo-level = <400>; }; ... -- cgit From 6e986a8f1cf15810be49e439acbc4a1499dd64b7 Mon Sep 17 00:00:00 2001 From: AngeloGioacchino Del Regno Date: Thu, 13 Jan 2022 16:51:11 +0200 Subject: dt-bindings: display: msm: Add binding for msm8998 dpu Add yaml binding for msm8998 dpu1 support. Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Jami Kettunen Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220113145111.29984-4-jami.kettunen@somainline.org Signed-off-by: Dmitry Baryshkov --- .../bindings/display/msm/dpu-msm8998.yaml | 219 +++++++++++++++++++++ 1 file changed, 219 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml new file mode 100644 index 000000000000..167bc48748d7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml @@ -0,0 +1,219 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dpu-msm8998.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DPU dt properties for MSM8998 target + +maintainers: + - AngeloGioacchino Del Regno + +description: | + Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree + bindings of MDSS and DPU are mentioned for MSM8998 target. + +properties: + compatible: + items: + - const: qcom,msm8998-mdss + + reg: + maxItems: 1 + + reg-names: + const: mdss + + power-domains: + maxItems: 1 + + clocks: + items: + - description: Display AHB clock + - description: Display AXI clock + - description: Display core clock + + clock-names: + items: + - const: iface + - const: bus + - const: core + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#address-cells": true + + "#size-cells": true + + "#interrupt-cells": + const: 1 + + iommus: + items: + - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0 + + ranges: true + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + description: Node containing the properties of DPU. + + properties: + compatible: + items: + - const: qcom,msm8998-dpu + + reg: + items: + - description: Address offset and size for mdp register set + - description: Address offset and size for regdma register set + - description: Address offset and size for vbif register set + - description: Address offset and size for non-realtime vbif register set + + reg-names: + items: + - const: mdp + - const: regdma + - const: vbif + - const: vbif_nrt + + clocks: + items: + - description: Display ahb clock + - description: Display axi clock + - description: Display mem-noc clock + - description: Display core clock + - description: Display vsync clock + + clock-names: + items: + - const: iface + - const: bus + - const: mnoc + - const: core + - const: vsync + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + + operating-points-v2: true + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + Contains the list of output ports from DPU device. These ports + connect to interfaces that are external to the DPU hardware, + such as DSI, DP etc. Each output port contains an endpoint that + describes how it is connected to an external interface. + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF1 (DSI1) + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF2 (DSI2) + + required: + - port@0 + - port@1 + + required: + - compatible + - reg + - reg-names + - clocks + - interrupts + - power-domains + - operating-points-v2 + - ports + +required: + - compatible + - reg + - reg-names + - power-domains + - clocks + - interrupts + - interrupt-controller + - iommus + - ranges + +additionalProperties: false + +examples: + - | + #include + #include + #include + + display-subsystem@c900000 { + compatible = "qcom,msm8998-mdss"; + reg = <0x0c900000 0x1000>; + reg-names = "mdss"; + + clocks = <&mmcc MDSS_AHB_CLK>, + <&mmcc MDSS_AXI_CLK>, + <&mmcc MDSS_MDP_CLK>; + clock-names = "iface", "bus", "core"; + + #address-cells = <1>; + #interrupt-cells = <1>; + #size-cells = <1>; + + interrupts = ; + interrupt-controller; + iommus = <&mmss_smmu 0>; + + power-domains = <&mmcc MDSS_GDSC>; + ranges; + + display-controller@c901000 { + compatible = "qcom,msm8998-dpu"; + reg = <0x0c901000 0x8f000>, + <0x0c9a8e00 0xf0>, + <0x0c9b0000 0x2008>, + <0x0c9b8000 0x1040>; + reg-names = "mdp", "regdma", "vbif", "vbif_nrt"; + + clocks = <&mmcc MDSS_AHB_CLK>, + <&mmcc MDSS_AXI_CLK>, + <&mmcc MNOC_AHB_CLK>, + <&mmcc MDSS_MDP_CLK>, + <&mmcc MDSS_VSYNC_CLK>; + clock-names = "iface", "bus", "mnoc", "core", "vsync"; + + interrupt-parent = <&mdss>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmpd MSM8998_VDDMX>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + + port@1 { + reg = <1>; + dpu_intf2_out: endpoint { + remote-endpoint = <&dsi1_in>; + }; + }; + }; + }; + }; +... -- cgit From 1bbc60d0c7e5728aced352e528ef936ebe2344c0 Mon Sep 17 00:00:00 2001 From: Sean Christopherson Date: Fri, 18 Feb 2022 09:43:05 -0800 Subject: KVM: x86/mmu: Remove MMU auditing Remove mmu_audit.c and all its collateral, the auditing code has suffered severe bitrot, ironically partly due to shadow paging being more stable and thus not benefiting as much from auditing, but mostly due to TDP supplanting shadow paging for non-nested guests and shadowing of nested TDP not heavily stressing the logic that is being audited. Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini --- Documentation/admin-guide/kernel-parameters.txt | 4 ---- 1 file changed, 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 2a9746fe6c4a..05161afd7642 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2368,10 +2368,6 @@ kvm.enable_vmware_backdoor=[KVM] Support VMware backdoor PV interface. Default is false (don't support). - kvm.mmu_audit= [KVM] This is a R/W parameter which allows audit - KVM MMU at runtime. - Default is 0 (off) - kvm.nx_huge_pages= [KVM] Controls the software workaround for the X86_BUG_ITLB_MULTIHIT bug. -- cgit From 6881e493b08fe1ab9dd132333c01e7581950e1c2 Mon Sep 17 00:00:00 2001 From: Matt Johnston Date: Fri, 18 Feb 2022 13:51:05 +0800 Subject: dt-bindings: net: New binding mctp-i2c-controller Used to define a local endpoint to communicate with MCTP peripherals attached to an I2C bus. This I2C endpoint can communicate with remote MCTP devices on the I2C bus. In the example I2C topology below (matching the second yaml example) we have MCTP devices on busses i2c1 and i2c6. MCTP-supporting busses are indicated by the 'mctp-controller' DT property on an I2C bus node. A mctp-i2c-controller I2C client DT node is placed at the top of the mux topology, since only the root I2C adapter will support I2C slave functionality. .-------. |eeprom | .------------. .------. /'-------' | adapter | | mux --@0,i2c5------' | i2c1 ----.*| --@1,i2c6--.--. |............| \'------' \ \ ......... | mctp-i2c- | \ \ \ .mctpB . | controller | \ \ '.0x30 . | | \ ......... \ '.......' | 0x50 | \ .mctpA . \ ......... '------------' '.0x1d . '.mctpC . '.......' '.0x31 . '.......' (mctpX boxes above are remote MCTP devices not included in the DT at present, they can be hotplugged/probed at runtime. A DT binding for specific fixed MCTP devices could be added later if required) Signed-off-by: Matt Johnston Reviewed-by: Rob Herring Acked-by: Wolfram Sang Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/i2c/i2c.txt | 4 + .../bindings/net/mctp-i2c-controller.yaml | 92 ++++++++++++++++++++++ 2 files changed, 96 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt index b864916e087f..fc3dd7ec0445 100644 --- a/Documentation/devicetree/bindings/i2c/i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c.txt @@ -95,6 +95,10 @@ wants to support one of the below features, it should adapt these bindings. - smbus-alert states that the optional SMBus-Alert feature apply to this bus. +- mctp-controller + indicates that the system is accessible via this bus as an endpoint for + MCTP over I2C transport. + Required properties (per child device) -------------------------------------- diff --git a/Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml b/Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml new file mode 100644 index 000000000000..afd11c9422fa --- /dev/null +++ b/Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mctp-i2c-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MCTP I2C transport binding + +maintainers: + - Matt Johnston + +description: | + An mctp-i2c-controller defines a local MCTP endpoint on an I2C controller. + MCTP I2C is specified by DMTF DSP0237. + + An mctp-i2c-controller must be attached to an I2C adapter which supports + slave functionality. I2C busses (either directly or as subordinate mux + busses) are attached to the mctp-i2c-controller with a 'mctp-controller' + property on each used bus. Each mctp-controller I2C bus will be presented + to the host system as a separate MCTP I2C instance. + +properties: + compatible: + const: mctp-i2c-controller + + reg: + minimum: 0x40000000 + maximum: 0x4000007f + description: | + 7 bit I2C address of the local endpoint. + I2C_OWN_SLAVE_ADDRESS (1<<30) flag must be set. + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + // Basic case of a single I2C bus + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + mctp-controller; + + mctp@30 { + compatible = "mctp-i2c-controller"; + reg = <(0x30 | I2C_OWN_SLAVE_ADDRESS)>; + }; + }; + + - | + // Mux topology with multiple MCTP-handling busses under + // a single mctp-i2c-controller. + // i2c1 and i2c6 can have MCTP devices, i2c5 does not. + #include + + i2c1: i2c { + #address-cells = <1>; + #size-cells = <0>; + mctp-controller; + + mctp@50 { + compatible = "mctp-i2c-controller"; + reg = <(0x50 | I2C_OWN_SLAVE_ADDRESS)>; + }; + }; + + i2c-mux { + #address-cells = <1>; + #size-cells = <0>; + i2c-parent = <&i2c1>; + + i2c5: i2c@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + eeprom@33 { + reg = <0x33>; + }; + }; + + i2c6: i2c@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + mctp-controller; + }; + }; -- cgit From 25882c82f850e3e972a973e0af310b3e58de38fd Mon Sep 17 00:00:00 2001 From: John Garry Date: Thu, 17 Feb 2022 23:42:31 +0800 Subject: scsi: libsas: Delete lldd_clear_aca callback This callback is never called, so remove support. Link: https://lore.kernel.org/r/1645112566-115804-4-git-send-email-john.garry@huawei.com Tested-by: Yihang Li Tested-by: Damien Le Moal Reviewed-by: Jack Wang Reviewed-by: Christoph Hellwig Reviewed-by: Xiang Chen Signed-off-by: John Garry Signed-off-by: Martin K. Petersen --- Documentation/scsi/libsas.rst | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scsi/libsas.rst b/Documentation/scsi/libsas.rst index 6589dfefbc02..305a253d5c3b 100644 --- a/Documentation/scsi/libsas.rst +++ b/Documentation/scsi/libsas.rst @@ -207,7 +207,6 @@ Management Functions (TMFs) described in SAM:: /* Task Management Functions. Must be called from process context. */ int (*lldd_abort_task)(struct sas_task *); int (*lldd_abort_task_set)(struct domain_device *, u8 *lun); - int (*lldd_clear_aca)(struct domain_device *, u8 *lun); int (*lldd_clear_task_set)(struct domain_device *, u8 *lun); int (*lldd_I_T_nexus_reset)(struct domain_device *); int (*lldd_lu_reset)(struct domain_device *, u8 *lun); @@ -262,7 +261,6 @@ can look like this (called last thing from probe()) my_ha->sas_ha.lldd_abort_task = my_abort_task; my_ha->sas_ha.lldd_abort_task_set = my_abort_task_set; - my_ha->sas_ha.lldd_clear_aca = my_clear_aca; my_ha->sas_ha.lldd_clear_task_set = my_clear_task_set; my_ha->sas_ha.lldd_I_T_nexus_reset= NULL; (2) my_ha->sas_ha.lldd_lu_reset = my_lu_reset; -- cgit From 039facb4323b9ff22e50c017c60f7020811a7229 Mon Sep 17 00:00:00 2001 From: Tim Harvey Date: Fri, 11 Feb 2022 11:04:17 -0800 Subject: dt-bindings: arm: imx: add imx8mm gw7903 support The GW7903 is based on the i.MX 8M Mini SoC featuring: - LPDDR4 DRAM - eMMC FLASH - microSD connector with UHS support - LIS2DE12 3-axis accelerometer - Gateworks System Controller - IMX8M FEC - software selectable RS232/RS485/RS422 serial transceiver - PMIC - 2x off-board bi-directional opto-isolated digital I/O - 1x M.2 A-E Key Socket and 1x MiniPCIe socket with USB2.0 and PCIe (resistor loading to route PCIe/USB2 between M.2 and MiniPCIe socket) Signed-off-by: Tim Harvey Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 23e678232451..08bdd30e511c 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -770,6 +770,7 @@ properties: - gw,imx8mm-gw73xx-0x # i.MX8MM Gateworks Development Kit - gw,imx8mm-gw7901 # i.MX8MM Gateworks Board - gw,imx8mm-gw7902 # i.MX8MM Gateworks Board + - gw,imx8mm-gw7903 # i.MX8MM Gateworks Board - kontron,imx8mm-n801x-som # i.MX8MM Kontron SL (N801X) SOM - toradex,verdin-imx8mm # Verdin iMX8M Mini Modules - toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Modules without Wi-Fi / BT -- cgit From 41654043226f517a8b37cab34f1eab5c6ef16947 Mon Sep 17 00:00:00 2001 From: Christian Hewitt Date: Fri, 11 Feb 2022 10:53:09 +0000 Subject: dt-bindings: vendor-prefixes: add osmc prefix Open Source Media Centre (Sam Nazarko Trading Ltd.) are a manufacturer of Linux Set-Top Box devices. Signed-off-by: Christian Hewitt Acked-by: Rob Herring Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20220211105311.30320-2-christianshewitt@gmail.com --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 52ff63248892..b97fd8dfe601 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -882,6 +882,8 @@ patternProperties: description: Ortus Technology Co., Ltd. "^osddisplays,.*": description: OSD Displays + "^osmc,.*": + description: Sam Nazarko Trading Ltd. (Open Source Media Centre) "^ouya,.*": description: Ouya Inc. "^overkiz,.*": -- cgit From 3f7dbd336f360a76103153b85ce616b86d85c6cd Mon Sep 17 00:00:00 2001 From: Christian Hewitt Date: Fri, 11 Feb 2022 10:53:10 +0000 Subject: dt-bindings: arm: amlogic: add Vero 4K+ bindings Add the board binding for the OSMC Vero 4K+ STB device Signed-off-by: Christian Hewitt Acked-by: Rob Herring Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20220211105311.30320-3-christianshewitt@gmail.com --- Documentation/devicetree/bindings/arm/amlogic.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index a073a959232c..61a6cabb375b 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -108,6 +108,7 @@ properties: - amlogic,p230 - amlogic,p231 - libretech,aml-s905d-pc + - osmc,vero4k-plus - phicomm,n1 - smartlabs,sml5442tw - videostrong,gxl-kii-pro -- cgit From d23c49562a887a8875b144d092034e14b0e279ff Mon Sep 17 00:00:00 2001 From: Mohan Kumar Date: Wed, 16 Feb 2022 14:52:39 +0530 Subject: dt-bindings: Document Tegra234 HDA support Update binding document for HDA support on Tegra234 chip. Tegra234 has max of 2 clocks and 2 resets which requires to add minItems and maxItems for clocks and resets as Tegra chips can now have minimum of 2 and maximum of 3 clocks and reset support. Signed-off-by: Mohan Kumar Link: https://lore.kernel.org/r/20220216092240.26464-6-mkumard@nvidia.com Signed-off-by: Takashi Iwai --- Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml index 2c913aa44fee..12c31b4b99e1 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml @@ -23,6 +23,7 @@ properties: - const: nvidia,tegra30-hda - items: - enum: + - nvidia,tegra234-hda - nvidia,tegra194-hda - nvidia,tegra186-hda - nvidia,tegra210-hda @@ -41,9 +42,11 @@ properties: maxItems: 1 clocks: + minItems: 2 maxItems: 3 clock-names: + minItems: 2 items: - const: hda - const: hda2hdmi -- cgit From 0539884ccc8ad4b94e78c8c7705058af1cf9307f Mon Sep 17 00:00:00 2001 From: Cristian Marussi Date: Thu, 17 Feb 2022 13:12:30 +0000 Subject: dt-bindings: firmware: arm,scmi: Add atomic-threshold-us optional property SCMI protocols in the platform can optionally signal to the OSPM agent the expected execution latency for a specific resource/operation pair. Introduce an SCMI system wide optional property to describe a global time threshold which can be configured on a per-platform base to determine the opportunity, or not, for an SCMI command advertised to have a higher latency than the threshold, to be considered for atomic operations: high-latency SCMI synchronous commands should be preferably issued in the usual non-atomic mode. Link: https://lore.kernel.org/r/20220217131234.50328-5-cristian.marussi@arm.com Cc: Rob Herring Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla --- Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index eae15df36eef..590743883802 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -81,6 +81,14 @@ properties: '#size-cells': const: 0 + atomic-threshold-us: + description: + An optional time value, expressed in microseconds, representing, on this + platform, the threshold above which any SCMI command, advertised to have + an higher-than-threshold execution latency, should not be considered for + atomic mode of operation, even if requested. + default: 0 + arm,smc-id: $ref: /schemas/types.yaml#/definitions/uint32 description: @@ -264,6 +272,8 @@ examples: #address-cells = <1>; #size-cells = <0>; + atomic-threshold-us = <10000>; + scmi_devpd: protocol@11 { reg = <0x11>; #power-domain-cells = <1>; -- cgit From 129e3c1bab24d27d0fa6e505a472345a92d7a2b0 Mon Sep 17 00:00:00 2001 From: Hangbin Liu Date: Mon, 21 Feb 2022 13:54:57 +0800 Subject: bonding: add new option ns_ip6_target This patch add a new bonding option ns_ip6_target, which correspond to the arp_ip_target. With this we set IPv6 targets and send IPv6 NS request to determine the health of the link. For other related options like the validation, we still use arp_validate, and will change to ns_validate later. Note: the sysfs configuration support was removed based on https://lore.kernel.org/netdev/8863.1645071997@famine Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller --- Documentation/networking/bonding.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/bonding.rst b/Documentation/networking/bonding.rst index ab98373535ea..525e6842dd33 100644 --- a/Documentation/networking/bonding.rst +++ b/Documentation/networking/bonding.rst @@ -313,6 +313,17 @@ arp_ip_target maximum number of targets that can be specified is 16. The default value is no IP addresses. +ns_ip6_target + + Specifies the IPv6 addresses to use as IPv6 monitoring peers when + arp_interval is > 0. These are the targets of the NS request + sent to determine the health of the link to the targets. + Specify these values in ffff:ffff::ffff:ffff format. Multiple IPv6 + addresses must be separated by a comma. At least one IPv6 + address must be given for NS/NA monitoring to function. The + maximum number of targets that can be specified is 16. The + default value is no IPv6 addresses. + arp_validate Specifies whether or not ARP probes and replies should be -- cgit From b252ada293d5d30566121c61fa7552e74396d533 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 26 Jan 2022 12:26:05 +0100 Subject: dt-bindings: mtd: spi-nor: Allow two CS per device The Xilinx QSPI controller has two advanced modes which allow the controller to behave differently and consider two flashes as one single storage. One of these two modes is quite complex to support from a binding point of view and is the dual parallel memories. In this mode, each byte of data is stored in both devices: the even bits in one, the odd bits in the other. The split is automatically handled by the QSPI controller and is transparent for the user. The other mode is simpler to support, it is called dual stacked memories. The controller shares the same SPI bus but each of the devices contain half of the data. Once in this mode, the controller does not follow CS requests but instead internally wires the two CS levels with the value of the most significant address bit. Supporting these two modes will involve core changes which include the possibility of providing two CS for a single SPI device Signed-off-by: Miquel Raynal Acked-by: Rob Herring Reviewed-by: Pratyush Yadav Link: https://lore.kernel.org/r/20220126112608.955728-2-miquel.raynal@bootlin.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml index 39421f7233e4..4abfb4cfc157 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml @@ -47,7 +47,8 @@ properties: identified by the JEDEC READ ID opcode (0x9F). reg: - maxItems: 1 + minItems: 1 + maxItems: 2 spi-max-frequency: true spi-rx-bus-width: true -- cgit From e2edd1b64f1c79e8abda365149ed62a2a9a494b4 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 26 Jan 2022 12:26:06 +0100 Subject: spi: dt-bindings: Describe stacked/parallel memories modes Describe two new memories modes: - A stacked mode when the bus is common but the address space extended with an additinals wires. - A parallel mode with parallel busses accessing parallel flashes where the data is spread. Signed-off-by: Miquel Raynal Acked-by: Pratyush Yadav Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220126112608.955728-3-miquel.raynal@bootlin.com Signed-off-by: Mark Brown --- .../bindings/spi/spi-peripheral-props.yaml | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml index 5dd209206e88..fedb7ae98ff6 100644 --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml @@ -82,6 +82,31 @@ properties: description: Delay, in microseconds, after a write transfer. + stacked-memories: + description: Several SPI memories can be wired in stacked mode. + This basically means that either a device features several chip + selects, or that different devices must be seen as a single + bigger chip. This basically doubles (or more) the total address + space with only a single additional wire, while still needing + to repeat the commands when crossing a chip boundary. The size of + each chip should be provided as members of the array. + $ref: /schemas/types.yaml#/definitions/uint64-array + minItems: 2 + maxItems: 4 + + parallel-memories: + description: Several SPI memories can be wired in parallel mode. + The devices are physically on a different buses but will always + act synchronously as each data word is spread across the + different memories (eg. even bits are stored in one memory, odd + bits in the other). This basically doubles the address space and + the throughput while greatly complexifying the wiring because as + many busses as devices must be wired. The size of each chip should + be provided as members of the array. + $ref: /schemas/types.yaml#/definitions/uint64-array + minItems: 2 + maxItems: 4 + # The controller specific properties go here. allOf: - $ref: cdns,qspi-nor-peripheral-props.yaml# -- cgit From eba5368503b4291db7819512600fa014ea17c5a8 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 26 Jan 2022 12:26:07 +0100 Subject: spi: dt-bindings: Add an example with two stacked flashes Provide an example of how to describe two flashes in eg. stacked mode. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220126112608.955728-4-miquel.raynal@bootlin.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-controller.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index 36b72518f565..0f4d40218400 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -139,4 +139,11 @@ examples: spi-max-frequency = <100000>; reg = <1>; }; + + flash@2 { + compatible = "jedec,spi-nor"; + spi-max-frequency = <50000000>; + reg = <2>, <3>; + stacked-memories = /bits/ 64 <0x10000000 0x10000000>; + }; }; -- cgit From 96b02f2fbde29a08ac7239fd9ba87ff870cf8a94 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Wed, 16 Feb 2022 12:37:45 -0800 Subject: Docs: printk: add 'console=null|""' to admin/kernel-parameters Tell about 'console=null|""' and how to use it. It can be helpful to set (enable) CONFIG_NULL_TTY so that the ttynull driver is available. This avoids problems with stdin/stdout/stderr of the init process. Howevere, CONFIG_NULL_TTY cannot be enabled by default because it can be used by mistake, see the commit a91bd6223ecd ("Revert "init/console: Use ttynull as a fallback when there is no console""). Signed-off-by: Randy Dunlap Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Steven Rostedt Cc: John Ogness Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org [pmladek@suse.com: Slightly update wording.] Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20220216203745.980-1-rdunlap@infradead.org --- Documentation/admin-guide/kernel-parameters.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 49f495c9a7f8..46bfadf02bc7 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -724,6 +724,12 @@ hvc Use the hypervisor console device . This is for both Xen and PowerPC hypervisors. + { null | "" } + Use to disable console output, i.e., to have kernel + console messages discarded. + This must be the only console= parameter used on the + kernel command line. + If the device connected to the port is not a TTY but a braille device, prepend "brl," before the device type, for instance console=brl,ttyS0 -- cgit From 489c7fc44b5740d377e8cfdbf0851036e493af00 Mon Sep 17 00:00:00 2001 From: "Jason A. Donenfeld" Date: Sat, 5 Feb 2022 14:00:58 +0100 Subject: random: always wake up entropy writers after extraction Now that POOL_BITS == POOL_MIN_BITS, we must unconditionally wake up entropy writers after every extraction. Therefore there's no point of write_wakeup_threshold, so we can move it to the dustbin of unused compatibility sysctls. While we're at it, we can fix a small comparison where we were waking up after <= min rather than < min. Cc: Theodore Ts'o Suggested-by: Eric Biggers Reviewed-by: Eric Biggers Reviewed-by: Dominik Brodowski Signed-off-by: Jason A. Donenfeld --- Documentation/admin-guide/sysctl/kernel.rst | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index d359bcfadd39..d3c6d9a501a9 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -1029,14 +1029,17 @@ This is a directory, with the following entries: * ``poolsize``: the entropy pool size, in bits; * ``urandom_min_reseed_secs``: obsolete (used to determine the minimum - number of seconds between urandom pool reseeding). + number of seconds between urandom pool reseeding). This file is + writable for compatibility purposes, but writing to it has no effect + on any RNG behavior. * ``uuid``: a UUID generated every time this is retrieved (this can thus be used to generate UUIDs at will); * ``write_wakeup_threshold``: when the entropy count drops below this (as a number of bits), processes waiting to write to ``/dev/random`` - are woken up. + are woken up. This file is writable for compatibility purposes, but + writing to it has no effect on any RNG behavior. If ``drivers/char/random.c`` is built with ``ADD_INTERRUPT_BENCH`` defined, these additional entries are present: -- cgit From 34739fd95fab3a5efb0422e4f012b685e33598dc Mon Sep 17 00:00:00 2001 From: Will Deacon Date: Mon, 21 Feb 2022 15:35:24 +0000 Subject: KVM: arm64: Indicate SYSTEM_RESET2 in kvm_run::system_event flags field When handling reset and power-off PSCI calls from the guest, we initialise X0 to PSCI_RET_INTERNAL_FAILURE in case the VMM tries to re-run the vCPU after issuing the call. Unfortunately, this also means that the VMM cannot see which PSCI call was issued and therefore cannot distinguish between PSCI SYSTEM_RESET and SYSTEM_RESET2 calls, which is necessary in order to determine the validity of the "reset_type" in X1. Allocate bit 0 of the previously unused 'flags' field of the system_event structure so that we can indicate the PSCI call used to initiate the reset. Cc: Marc Zyngier Cc: James Morse Cc: Alexandru Elisei Cc: Suzuki K Poulose Signed-off-by: Will Deacon Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220221153524.15397-4-will@kernel.org --- Documentation/virt/kvm/api.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index a4267104db50..8305ac9747b6 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -5939,6 +5939,11 @@ Valid values for 'type' are: to ignore the request, or to gather VM memory core dump and/or reset/shutdown of the VM. +Valid flags are: + + - KVM_SYSTEM_EVENT_RESET_FLAG_PSCI_RESET2 (arm64 only) -- the guest issued + a SYSTEM_RESET2 call according to v1.1 of the PSCI specification. + :: /* KVM_EXIT_IOAPIC_EOI */ -- cgit From aea875a9da8cd0365399081c551d1abe1f16939b Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Sun, 20 Feb 2022 15:15:19 +0000 Subject: dt-bindings: nvmem: SID: Add compatible for D1 D1 has a SID like other Allwinner SoCs, but with a unique eFuse layout. Add a new compatible string for it. Acked-by: Rob Herring Signed-off-by: Samuel Holland Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220220151527.17216-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml index 6687ab720304..e558587ff885 100644 --- a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml +++ b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml @@ -20,6 +20,7 @@ properties: - const: allwinner,sun7i-a20-sid - const: allwinner,sun8i-a83t-sid - const: allwinner,sun8i-h3-sid + - const: allwinner,sun20i-d1-sid - const: allwinner,sun50i-a64-sid - items: - const: allwinner,sun50i-a100-sid -- cgit From 6f9817cdcc82007812bbc0c33372c69c79e138cd Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Sun, 20 Feb 2022 15:15:22 +0000 Subject: dt-bindings: nvmem: add fsl,layerscape-sfp binding The Security Fuse Processor provides efuses and is responsible for reading it at SoC startup and configuring it accordingly. Reviewed-by: Rob Herring Signed-off-by: Michael Walle Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220220151527.17216-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman --- .../bindings/nvmem/fsl,layerscape-sfp.yaml | 38 ++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml new file mode 100644 index 000000000000..80914b93638e --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/fsl,layerscape-sfp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Layerscape Security Fuse Processor + +maintainers: + - Michael Walle + +description: | + SFP is the security fuse processor which among other things provide a + unique identifier per part. + +allOf: + - $ref: "nvmem.yaml#" + +properties: + compatible: + enum: + - fsl,ls1028a-sfp + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + efuse@1e80000 { + compatible = "fsl,ls1028a-sfp"; + reg = <0x1e80000 0x8000>; + }; -- cgit From 673d2cc5c1e7d31ee0597f6e18b45dcd257bc5d2 Mon Sep 17 00:00:00 2001 From: Sean Anderson Date: Sun, 20 Feb 2022 15:15:24 +0000 Subject: doc: nvmem: Remove references to regmap Since commit 795ddd18d38f ("nvmem: core: remove regmap dependency"), nvmem devices do not use the regmap API. Remove references to it from the documentation. Signed-off-by: Sean Anderson Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220220151527.17216-11-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/nvmem.rst | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/nvmem.rst b/Documentation/driver-api/nvmem.rst index 287e86819640..56352ad1b1b0 100644 --- a/Documentation/driver-api/nvmem.rst +++ b/Documentation/driver-api/nvmem.rst @@ -26,9 +26,7 @@ was a rather big abstraction leak. This framework aims at solve these problems. It also introduces DT representation for consumer devices to go get the data they require (MAC -Addresses, SoC/Revision ID, part numbers, and so on) from the NVMEMs. This -framework is based on regmap, so that most of the abstraction available in -regmap can be reused, across multiple types of buses. +Addresses, SoC/Revision ID, part numbers, and so on) from the NVMEMs. NVMEM Providers +++++++++++++++ @@ -60,9 +58,6 @@ For example, a simple qfprom case:: ... } -It is mandatory that the NVMEM provider has a regmap associated with its -struct device. Failure to do would return error code from nvmem_register(). - Users of board files can define and register nvmem cells using the nvmem_cell_table struct:: -- cgit From 671aa5a4d493f46ff9720bd2544bae00271be116 Mon Sep 17 00:00:00 2001 From: Sean Anderson Date: Sun, 20 Feb 2022 15:15:25 +0000 Subject: doc: nvmem: Update example Update the example to reflect the new API. I have chosen the brcm-nvram driver since it seems to be simpler than the qfprom driver. Signed-off-by: Sean Anderson Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220220151527.17216-12-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/nvmem.rst | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/nvmem.rst b/Documentation/driver-api/nvmem.rst index 56352ad1b1b0..e3366322d46c 100644 --- a/Documentation/driver-api/nvmem.rst +++ b/Documentation/driver-api/nvmem.rst @@ -43,19 +43,20 @@ nvmem_device pointer. nvmem_unregister(nvmem) is used to unregister a previously registered provider. -For example, a simple qfprom case:: +For example, a simple nvram case:: - static struct nvmem_config econfig = { - .name = "qfprom", - .owner = THIS_MODULE, - }; - - static int qfprom_probe(struct platform_device *pdev) + static int brcm_nvram_probe(struct platform_device *pdev) { + struct nvmem_config config = { + .name = "brcm-nvram", + .reg_read = brcm_nvram_read, + }; ... - econfig.dev = &pdev->dev; - nvmem = nvmem_register(&econfig); - ... + config.dev = &pdev->dev; + config.priv = priv; + config.size = resource_size(res); + + devm_nvmem_register(&config); } Users of board files can define and register nvmem cells using the -- cgit From aa1b784deff3cc700b8405d7211c879ed2654203 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 6 Feb 2022 19:03:24 +0000 Subject: dt-bindings:iio:adc:ad7280a: Add binding Add a binding for this Lithium Ion Battery monitoring chip/chain of chips as it is now clean and ready to move out of staging. Signed-off-by: Jonathan Cameron Reviewed-by: Rob Herring Reviewed-by: Marcelo Schmitt Link: https://lore.kernel.org/r/20220206190328.333093-17-jic23@kernel.org --- .../devicetree/bindings/iio/adc/adi,ad7280a.yaml | 77 ++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml new file mode 100644 index 000000000000..a694d5794d4a --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/adi,ad7280a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD7280a Lithium Ion Battery Monitoring System + +maintainers: + - Michael Hennerich + - Jonathan Cameron + +description: | + Bindings for the Analog Devices AD7280a Battery Monitoring System. + Used in devices such as hybrid electric cars, battery backup and power tools. + Multiple chips can be daisy chained and accessed via a single SPI interface. + Data sheet found here: + https://www.analog.com/media/en/technical-documentation/data-sheets/AD7280A.pdf + +properties: + compatible: + const: adi,ad7280a + + reg: + maxItems: 1 + + interrupts: + description: IRQ line for the ADC + maxItems: 1 + + spi-max-frequency: true + + adi,voltage-alert-last-chan: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Allows limiting of scope of which channels are considered for voltage + alerts, typically because not all are wired to anything. Only applies to + last device in the daisy chain. + default: 5 + enum: [3, 4, 5] + + adi,acquisition-time-ns: + description: + Additional time may be needed to charge the sampling capacitors depending + on external writing. + default: 400 + enum: [400, 800, 1200, 1600] + + adi,thermistor-termination: + type: boolean + description: + Enable the thermistor termination function. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "adi,ad7280a"; + reg = <0>; + spi-max-frequency = <700000>; + interrupt-parent = <&gpio>; + interrupts = <25 2>; + adi,thermistor-termination; + adi,acquisition-time-ns = <800>; + adi,voltage-alert-last-chan = <5>; + }; + }; +... -- cgit From bc6fbf11771932732361e386c98b1c9fcc6898fe Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 6 Feb 2022 19:03:25 +0000 Subject: iio:adc:ad7280a: Document ABI for cell balance switches Very minimal ABI docs. This is unusual enough that I'd expect anyone who actually wanted to touch them to go look at the datasheet. Signed-off-by: Jonathan Cameron Reviewed-by: Marcelo Schmitt Link: https://lore.kernel.org/r/20220206190328.333093-18-jic23@kernel.org --- Documentation/ABI/testing/sysfs-bus-iio-adc-ad7280a | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-ad7280a (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7280a b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7280a new file mode 100644 index 000000000000..83b7efe6aa07 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7280a @@ -0,0 +1,13 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_balance_switch_en +KernelVersion: 5.14 +Contact: linux-iio@vger.kernel.org +Description: + Used to enable an output for balancing cells for time + controlled via in_voltage_Y-voltageZ_balance_switch_timer. + +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_balance_switch_timer +KernelVersion: 5.14 +Contact: linux-iio@vger.kernel.org +Description: + Time in seconds for which balance switch will be turned on. + Multiple of 71.5 seconds. -- cgit From b38da7feefb4c8080753eb5bf4e4db5eba0e119b Mon Sep 17 00:00:00 2001 From: Jan Luebbe Date: Wed, 16 Feb 2022 17:23:12 +0100 Subject: dt-bindings: iio: adc: microchip,mcp3201: fix interface type (I2C -> SPI) This family of ADCs uses SPI, not I2C. Signed-off-by: Jan Luebbe Link: https://lore.kernel.org/r/20220216162312.4064-1-jlu@pengutronix.de Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/microchip,mcp3201.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3201.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3201.yaml index cbbac4ce56d6..fcc1ba53b20d 100644 --- a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3201.yaml +++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3201.yaml @@ -10,7 +10,7 @@ maintainers: - Oskar Andero description: | - Family of simple ADCs with an I2C inteface. + Family of simple ADCs with a SPI interface. properties: compatible: -- cgit From 89d185848633db2aa811131ac5db795d5366da78 Mon Sep 17 00:00:00 2001 From: Cosmin Tanislav Date: Mon, 14 Feb 2022 09:38:07 +0200 Subject: iio: ABI: document mag_referenced Some accelerometers that support activity and inactivity events also support a referenced mode, in which the gravitational acceleration is taken as a point of reference before comparing the acceleration to the specified activity and inactivity magnitude. For example, in the case of the ADXL367, for activity detection, the formula is: abs(acceleration - reference) > magnitude Add a new event type that makes this behavior clear. Signed-off-by: Cosmin Tanislav Link: https://lore.kernel.org/r/20220214073810.781016-3-cosmin.tanislav@analog.com Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index c551301b33f1..41c1e3e1bf30 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -1213,6 +1213,32 @@ Description: number or direction is not specified, applies to all channels of this type. +What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_en +What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_rising_en +What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_falling_en +What: /sys/.../iio:deviceX/events/in_accel_y_mag_referenced_en +What: /sys/.../iio:deviceX/events/in_accel_y_mag_referenced_rising_en +What: /sys/.../iio:deviceX/events/in_accel_y_mag_referenced_falling_en +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Similar to in_accel_mag[_y][_rising|_falling]_en, but the event + value is relative to a reference magnitude. The reference magnitude + includes the graviational acceleration. + +What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_value +What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_rising_value +What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_falling_value +What: /sys/.../iio:deviceX/events/in_accel_y_mag_referenced_value +What: /sys/.../iio:deviceX/events/in_accel_y_mag_referenced_rising_value +What: /sys/.../iio:deviceX/events/in_accel_y_mag_referenced_falling_value +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + The value to which the reference magnitude of the channel is + compared. If the axis is not specified, it applies to all channels + of this type. + What: /sys/.../events/in_steps_change_en KernelVersion: 4.0 Contact: linux-iio@vger.kernel.org -- cgit From 06a4a0cf698474ce5a19eb2854edcb6af51b8055 Mon Sep 17 00:00:00 2001 From: Cosmin Tanislav Date: Mon, 14 Feb 2022 09:38:08 +0200 Subject: iio: ABI: add note about configuring other attributes during buffer capture It might be impossible to configure other attributes (e.g.: events, scale, sampling rate) if they impact the currently active buffer capture session. On ADXL367, writing to register before 0x2E requires the device to be placed in standby mode, otherwise the changes might be effective for only part of a measurement. To ensure this requirement, the configuration attributes of the IIO device try to claim direct mode before switching to standby mode. During a buffer capture, direct mode cannot be claimed, and the attribute write callback returns -EBUSY. Describe this behavior in the buffer/enable attribute description. Signed-off-by: Cosmin Tanislav Link: https://lore.kernel.org/r/20220214073810.781016-4-cosmin.tanislav@analog.com Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 41c1e3e1bf30..bc98453bdade 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -1278,6 +1278,10 @@ Description: Actually start the buffer capture up. Will start trigger if first device and appropriate. + Note that it might be impossible to configure other attributes, + (e.g.: events, scale, sampling rate) if they impact the currently + active buffer capture session. + What: /sys/bus/iio/devices/iio:deviceX/bufferY KernelVersion: 5.11 Contact: linux-iio@vger.kernel.org -- cgit From 27ae7f9d923885b6380c60dbe45d3bb19e885c5f Mon Sep 17 00:00:00 2001 From: Cosmin Tanislav Date: Mon, 14 Feb 2022 09:38:09 +0200 Subject: dt-bindings: iio: accel: add ADXL367 The ADXL367 is an ultralow power, 3-axis MEMS accelerometer. The ADXL367 does not alias input signals to achieve ultralow power consumption, it samples the full bandwidth of the sensor at all data rates. Measurement ranges of +-2g, +-4g, and +-8g are available, with a resolution of 0.25mg/LSB on the +-2 g range. In addition to its ultralow power consumption, the ADXL367 has many features to enable true system level power reduction. It includes a deep multimode output FIFO, a built-in micropower temperature sensor, and an internal ADC for synchronous conversion of an additional analog input. Signed-off-by: Cosmin Tanislav Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220214073810.781016-5-cosmin.tanislav@analog.com Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/accel/adi,adxl367.yaml | 79 ++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/accel/adi,adxl367.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl367.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl367.yaml new file mode 100644 index 000000000000..d259e796c1d6 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl367.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/adi,adxl367.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADXL367 3-Axis Digital Accelerometer + +maintainers: + - Cosmin Tanislav + +description: | + The ADXL367 is an ultralow power, 3-axis MEMS accelerometer. + + The ADXL367 does not alias input signals by to achieve ultralow power + consumption, it samples the full bandwidth of the sensor at all + data rates. Measurement ranges of +-2g, +-4g, and +-8g are available, + with a resolution of 0.25mg/LSB on the +-2 g range. + + In addition to its ultralow power consumption, the ADXL367 + has many features to enable true system level power reduction. + It includes a deep multimode output FIFO, a built-in micropower + temperature sensor, and an internal ADC for synchronous conversion + of an additional analog input. + https://www.analog.com/en/products/adxl367.html + +properties: + compatible: + enum: + - adi,adxl367 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + spi-max-frequency: true + + vdd-supply: true + vddio-supply: true + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@53 { + compatible = "adi,adxl367"; + reg = <0x53>; + interrupt-parent = <&gpio>; + interrupts = <25 IRQ_TYPE_EDGE_RISING>; + }; + }; + - | + #include + + spi { + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@0 { + compatible = "adi,adxl367"; + reg = <0>; + spi-max-frequency = <1000000>; + interrupt-parent = <&gpio>; + interrupts = <25 IRQ_TYPE_EDGE_RISING>; + }; + }; -- cgit From b4112083b11bd67f0426d56bae9662e5d2571dec Mon Sep 17 00:00:00 2001 From: Antoniu Miclaus Date: Tue, 15 Feb 2022 10:12:14 +0200 Subject: dt-bindings: iio: frequency: add admv1014 binding Add device tree bindings for the ADMV1014 Upconverter. Signed-off-by: Antoniu Miclaus Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220215081216.67706-2-antoniu.miclaus@analog.com Signed-off-by: Jonathan Cameron --- .../bindings/iio/frequency/adi,admv1014.yaml | 134 +++++++++++++++++++++ 1 file changed, 134 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml new file mode 100644 index 000000000000..2716c1e8fe31 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml @@ -0,0 +1,134 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/frequency/adi,admv1014.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ADMV1014 Microwave Downconverter + +maintainers: + - Antoniu Miclaus + +description: | + Wideband, microwave downconverter optimized for point to point microwave + radio designs operating in the 24 GHz to 44 GHz frequency range. + + https://www.analog.com/en/products/admv1014.html + +properties: + compatible: + enum: + - adi,admv1014 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 1000000 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: lo_in + description: + External clock that provides the Local Oscilator input. + + vcm-supply: + description: + Common-mode voltage regulator. + + vcc-if-bb-supply: + description: + BB and IF supply voltage regulator. + + vcc-vga-supply: + description: + RF Amplifier supply voltage regulator. + + vcc-vva-supply: + description: + VVA Control Circuit supply voltage regulator. + + vcc-lna-3p3-supply: + description: + Low Noise Amplifier 3.3V supply voltage regulator. + + vcc-lna-1p5-supply: + description: + Low Noise Amplifier 1.5V supply voltage regulator. + + vcc-bg-supply: + description: + Band Gap Circuit supply voltage regulator. + + vcc-quad-supply: + description: + Quadruple supply voltage regulator. + + vcc-mixer-supply: + description: + Mixer supply voltage regulator. + + adi,input-mode: + description: + Select the input mode. + iq - in-phase quadrature (I/Q) input + if - complex intermediate frequency (IF) input + enum: [iq, if] + + adi,detector-enable: + description: + Digital Rx Detector Enable. The Square Law Detector output is + available at output pin VDET. + type: boolean + + adi,p1db-compensation-enable: + description: + Turn on bits to optimize P1dB. + type: boolean + + adi,quad-se-mode: + description: + Switch the LO path from differential to single-ended operation. + se-neg - Single-Ended Mode, Negative Side Disabled. + se-pos - Single-Ended Mode, Positive Side Disabled. + diff - Differential Mode. + enum: [se-neg, se-pos, diff] + +required: + - compatible + - reg + - clocks + - clock-names + - vcm-supply + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + converter@0 { + compatible = "adi,admv1014"; + reg = <0>; + spi-max-frequency = <1000000>; + clocks = <&admv1014_lo>; + clock-names = "lo_in"; + vcm-supply = <&vcm>; + vcc-if-bb-supply = <&vcc_if_bb>; + vcc-vga-supply = <&vcc_vga>; + vcc-vva-supply = <&vcc_vva>; + vcc-lna-3p3-supply = <&vcc_lna_3p3>; + vcc-lna-1p5-supply = <&vcc_lna_1p5>; + vcc-bg-supply = <&vcc_bg>; + vcc-quad-supply = <&vcc_quad>; + vcc-mixer-supply = <&vcc_mixer>; + adi,quad-se-mode = "diff"; + adi,detector-enable; + adi,p1db-compensation-enable; + }; + }; +... -- cgit From 0ac02bf5bd8e234f1dd44ca8c090e58b0b603d78 Mon Sep 17 00:00:00 2001 From: Antoniu Miclaus Date: Tue, 15 Feb 2022 10:12:15 +0200 Subject: Documentation: ABI: testing: admv1014: add ABI docs Add documentation for the use of the Digital Attenuator gain. Signed-off-by: Antoniu Miclaus Link: https://lore.kernel.org/r/20220215081216.67706-3-antoniu.miclaus@analog.com Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio | 1 + .../ABI/testing/sysfs-bus-iio-frequency-admv1014 | 23 ++++++++++++++++++++++ 2 files changed, 24 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1014 (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index bc98453bdade..d4ccc68fdcf0 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -476,6 +476,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_i_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_q_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_voltage_i_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_voltage_q_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_voltage_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibscale diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1014 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1014 new file mode 100644 index 000000000000..395010a0ef8b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1014 @@ -0,0 +1,23 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0_i_calibscale_coarse +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Read/write value for the digital attenuator gain (IF_I) with coarse steps. + +What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0_q_calibscale_coarse +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Read/write value for the digital attenuator gain (IF_Q) with coarse steps. + +What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0_i_calibscale_fine +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Read/write value for the digital attenuator gain (IF_I) with fine steps. + +What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0_q_calibscale_fine +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Read/write value for the digital attenuator gain (IF_Q) with fine steps. -- cgit From 95e6060c20a7f5db60163274c5222a725ac118f9 Mon Sep 17 00:00:00 2001 From: "Jason A. Donenfeld" Date: Thu, 10 Feb 2022 16:35:24 +0100 Subject: random: remove ifdef'd out interrupt bench With tools like kbench9000 giving more finegrained responses, and this basically never having been used ever since it was initially added, let's just get rid of this. There *is* still work to be done on the interrupt handler, but this really isn't the way it's being developed. Cc: Theodore Ts'o Reviewed-by: Eric Biggers Reviewed-by: Dominik Brodowski Signed-off-by: Jason A. Donenfeld --- Documentation/admin-guide/sysctl/kernel.rst | 9 --------- 1 file changed, 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index d3c6d9a501a9..5dd660aac0ae 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -1041,15 +1041,6 @@ This is a directory, with the following entries: are woken up. This file is writable for compatibility purposes, but writing to it has no effect on any RNG behavior. -If ``drivers/char/random.c`` is built with ``ADD_INTERRUPT_BENCH`` -defined, these additional entries are present: - -* ``add_interrupt_avg_cycles``: the average number of cycles between - interrupts used to feed the pool; - -* ``add_interrupt_avg_deviation``: the standard deviation seen on the - number of cycles between interrupts used to feed the pool. - randomize_va_space ================== -- cgit From cd3bc044af483422cc81a93f23c78c20c978b17c Mon Sep 17 00:00:00 2001 From: Yael Tzur Date: Tue, 15 Feb 2022 09:19:53 -0500 Subject: KEYS: encrypted: Instantiate key with user-provided decrypted data For availability and performance reasons master keys often need to be released outside of a Key Management Service (KMS) to clients. It would be beneficial to provide a mechanism where the wrapping/unwrapping of data encryption keys (DEKs) is not dependent on a remote call at runtime yet security is not (or only minimally) compromised. Master keys could be securely stored in the Kernel and be used to wrap/unwrap keys from Userspace. The encrypted.c class supports instantiation of encrypted keys with either an already-encrypted key material, or by generating new key material based on random numbers. This patch defines a new datablob format: [] that allows to inject and encrypt user-provided decrypted data. The decrypted data must be hex-ascii encoded. Signed-off-by: Yael Tzur Reviewed-by: Mimi Zohar Reviewed-by: Sumit Garg Reviewed-by: Jarkko Sakkinen Signed-off-by: Mimi Zohar --- Documentation/security/keys/trusted-encrypted.rst | 25 +++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst index 80d5a5af62a1..f614dad7de12 100644 --- a/Documentation/security/keys/trusted-encrypted.rst +++ b/Documentation/security/keys/trusted-encrypted.rst @@ -107,12 +107,13 @@ Encrypted Keys -------------- Encrypted keys do not depend on a trust source, and are faster, as they use AES -for encryption/decryption. New keys are created from kernel-generated random -numbers, and are encrypted/decrypted using a specified ‘master’ key. The -‘master’ key can either be a trusted-key or user-key type. The main disadvantage -of encrypted keys is that if they are not rooted in a trusted key, they are only -as secure as the user key encrypting them. The master user key should therefore -be loaded in as secure a way as possible, preferably early in boot. +for encryption/decryption. New keys are created either from kernel-generated +random numbers or user-provided decrypted data, and are encrypted/decrypted +using a specified ‘master’ key. The ‘master’ key can either be a trusted-key or +user-key type. The main disadvantage of encrypted keys is that if they are not +rooted in a trusted key, they are only as secure as the user key encrypting +them. The master user key should therefore be loaded in as secure a way as +possible, preferably early in boot. Usage @@ -199,6 +200,8 @@ Usage:: keyctl add encrypted name "new [format] key-type:master-key-name keylen" ring + keyctl add encrypted name "new [format] key-type:master-key-name keylen + decrypted-data" ring keyctl add encrypted name "load hex_blob" ring keyctl update keyid "update key-type:master-key-name" @@ -303,6 +306,16 @@ Load an encrypted key "evm" from saved blob:: 82dbbc55be2a44616e4959430436dc4f2a7a9659aa60bb4652aeb2120f149ed197c564e0 24717c64 5972dcb82ab2dde83376d82b2e3c09ffc +Instantiate an encrypted key "evm" using user-provided decrypted data:: + + $ keyctl add encrypted evm "new default user:kmk 32 `cat evm_decrypted_data.blob`" @u + 794890253 + + $ keyctl print 794890253 + default user:kmk 32 2375725ad57798846a9bbd240de8906f006e66c03af53b1b382d + bbc55be2a44616e4959430436dc4f2a7a9659aa60bb4652aeb2120f149ed197c564e0247 + 17c64 5972dcb82ab2dde83376d82b2e3c09ffc + Other uses for trusted and encrypted keys, such as for disk and file encryption are anticipated. In particular the new format 'ecryptfs' has been defined in order to use encrypted keys to mount an eCryptfs filesystem. More details -- cgit From cbf9b8109d32a53395369c0dabde005cb8fa3852 Mon Sep 17 00:00:00 2001 From: Janis Schoetterl-Glausch Date: Mon, 21 Feb 2022 15:36:57 +0100 Subject: KVM: s390: Clarify key argument for MEM_OP in api docs Clarify that the key argument represents the access key, not the whole storage key. Signed-off-by: Janis Schoetterl-Glausch Link: https://lore.kernel.org/r/20220221143657.3712481-1-scgl@linux.ibm.com Fixes: 5e35d0eb472b ("KVM: s390: Update api documentation for memop ioctl") Signed-off-by: Christian Borntraeger --- Documentation/virt/kvm/api.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 48f23bb80d7f..622667cc87ef 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -3763,7 +3763,7 @@ KVM_S390_MEMOP_F_INJECT_EXCEPTION is set. If the KVM_S390_MEMOP_F_SKEY_PROTECTION flag is set, storage key protection is also in effect and may cause exceptions if accesses are -prohibited given the access key passed in "key". +prohibited given the access key designated by "key"; the valid range is 0..15. KVM_S390_MEMOP_F_SKEY_PROTECTION is available if KVM_CAP_S390_MEM_OP_EXTENSION is > 0. -- cgit From 7f9cfb54998d57685d1c93056fc3d21153bd5c4a Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Tue, 1 Feb 2022 08:23:48 +0100 Subject: pixfmt-yuv-planar.rst: fix typo: 'Cr, Cr' -> 'Cr, Cb' Several NV formats incorrectly described the Chroma order as Cr, Cr when it actually is Cr, Cb. Signed-off-by: Hans Verkuil Reported-by: Frank Barchard --- Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst index 3a09d93d405b..85615981faaa 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst @@ -76,7 +76,7 @@ All components are stored with the same number of bits per component. - 'NV21' - 8 - 4:2:0 - - Cr, Cr + - Cr, Cb - Yes - Linear * - V4L2_PIX_FMT_NV12M @@ -90,7 +90,7 @@ All components are stored with the same number of bits per component. - 'NM21' - 8 - 4:2:0 - - Cr, Cr + - Cr, Cb - No - Linear * - V4L2_PIX_FMT_NV12MT @@ -120,7 +120,7 @@ All components are stored with the same number of bits per component. - 'NV61' - 8 - 4:2:2 - - Cr, Cr + - Cr, Cb - Yes - Linear * - V4L2_PIX_FMT_NV16M @@ -134,7 +134,7 @@ All components are stored with the same number of bits per component. - 'NM61' - 8 - 4:2:2 - - Cr, Cr + - Cr, Cb - No - Linear * - V4L2_PIX_FMT_NV24 @@ -148,7 +148,7 @@ All components are stored with the same number of bits per component. - 'NV42' - 8 - 4:4:4 - - Cr, Cr + - Cr, Cb - Yes - Linear -- cgit From 70c6bc427a4158363fe933c053d8480ac4a2670a Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 29 Jan 2022 20:36:40 +0100 Subject: dt-bindings: phy: samsung: drop old Eynos5440 PCIe phy The Exynos5440 PCIe phy support was removed in commit 496db029142f ("phy: samsung: phy-exynos-pcie: rework driver to support Exynos5433 PCIe PHY") (with its own bindings), so drop the old bindings. Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220129193646.372481-2-krzysztof.kozlowski@canonical.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/samsung-phy.txt | 17 ----------------- 1 file changed, 17 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 8f51aee91101..390065f49b62 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -191,20 +191,3 @@ Example: usbdrdphy0 = &usb3_phy0; usbdrdphy1 = &usb3_phy1; }; - -Samsung Exynos SoC series PCIe PHY controller --------------------------------------------------- -Required properties: -- compatible : Should be set to "samsung,exynos5440-pcie-phy" -- #phy-cells : Must be zero -- reg : a register used by phy driver. - - First is for phy register, second is for block register. -- reg-names : Must be set to "phy" and "block". - -Example: - pcie_phy0: pcie-phy@270000 { - #phy-cells = <0>; - compatible = "samsung,exynos5440-pcie-phy"; - reg = <0x270000 0x1000>, <0x271000 0x40>; - reg-names = "phy", "block"; - }; -- cgit From e8d1ea4e2181f84821c8a7e4f6445b771e7566c8 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 29 Jan 2022 20:36:41 +0100 Subject: dt-bindings: phy: samsung,mipi-video-phy: convert to dtschema Convert the Samsung SoC MIPI CSIS/DSIM DPHY bindings to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220129193646.372481-3-krzysztof.kozlowski@canonical.com Signed-off-by: Vinod Koul --- .../bindings/phy/samsung,mipi-video-phy.yaml | 113 +++++++++++++++++++++ .../devicetree/bindings/phy/samsung-phy.txt | 29 ------ 2 files changed, 113 insertions(+), 29 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml new file mode 100644 index 000000000000..54aa056b224d --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/samsung,mipi-video-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5P/Exynos SoC MIPI CSIS/DSIM DPHY + +maintainers: + - Krzysztof Kozlowski + - Marek Szyprowski + - Sylwester Nawrocki + +description: | + For samsung,s5pv210-mipi-video-phy compatible PHYs the second cell in the + PHY specifier identifies the PHY and its meaning is as follows:: + 0 - MIPI CSIS 0, + 1 - MIPI DSIM 0, + 2 - MIPI CSIS 1, + 3 - MIPI DSIM 1. + + samsung,exynos5420-mipi-video-phy and samsung,exynos5433-mipi-video-phy + support additional fifth PHY:: + 4 - MIPI CSIS 2. + +properties: + compatible: + enum: + - samsung,s5pv210-mipi-video-phy + - samsung,exynos5420-mipi-video-phy + - samsung,exynos5433-mipi-video-phy + + "#phy-cells": + const: 1 + + syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to PMU system controller interface, valid only for + samsung,s5pv210-mipi-video-phy and samsung,exynos5420-mipi-video-phy. + + samsung,pmu-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to PMU system controller interface, valid for + samsung,exynos5433-mipi-video-phy. + + samsung,disp-sysreg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to DISP system controller interface, valid for + samsung,exynos5433-mipi-video-phy. + + samsung,cam0-sysreg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to CAM0 system controller interface, valid for + samsung,exynos5433-mipi-video-phy. + + samsung,cam1-sysreg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to CAM1 system controller interface, valid for + samsung,exynos5433-mipi-video-phy. + +required: + - compatible + - "#phy-cells" + +allOf: + - if: + properties: + compatible: + contains: + enum: + - samsung,s5pv210-mipi-video-phy + - samsung,exynos5420-mipi-video-phy + then: + properties: + samsung,pmu-syscon: false + samsung,disp-sysreg: false + samsung,cam0-sysreg: false + samsung,cam1-sysreg: false + required: + - syscon + else: + properties: + syscon: false + required: + - samsung,pmu-syscon + - samsung,disp-sysreg + - samsung,cam0-sysreg + - samsung,cam1-sysreg + +additionalProperties: false + +examples: + - | + phy { + compatible = "samsung,exynos5433-mipi-video-phy"; + #phy-cells = <1>; + samsung,pmu-syscon = <&pmu_system_controller>; + samsung,cam0-sysreg = <&syscon_cam0>; + samsung,cam1-sysreg = <&syscon_cam1>; + samsung,disp-sysreg = <&syscon_disp>; + }; + + - | + phy { + compatible = "samsung,s5pv210-mipi-video-phy"; + syscon = <&pmu_system_controller>; + #phy-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 390065f49b62..6ab16734eb65 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -1,32 +1,3 @@ -Samsung S5P/Exynos SoC series MIPI CSIS/DSIM DPHY -------------------------------------------------- - -Required properties: -- compatible : should be one of the listed compatibles: - - "samsung,s5pv210-mipi-video-phy" - - "samsung,exynos5420-mipi-video-phy" - - "samsung,exynos5433-mipi-video-phy" -- #phy-cells : from the generic phy bindings, must be 1; - -In case of s5pv210 and exynos5420 compatible PHYs: -- syscon - phandle to the PMU system controller - -In case of exynos5433 compatible PHY: - - samsung,pmu-syscon - phandle to the PMU system controller - - samsung,disp-sysreg - phandle to the DISP system registers controller - - samsung,cam0-sysreg - phandle to the CAM0 system registers controller - - samsung,cam1-sysreg - phandle to the CAM1 system registers controller - -For "samsung,s5pv210-mipi-video-phy" compatible PHYs the second cell in -the PHY specifier identifies the PHY and its meaning is as follows: - 0 - MIPI CSIS 0, - 1 - MIPI DSIM 0, - 2 - MIPI CSIS 1, - 3 - MIPI DSIM 1. -"samsung,exynos5420-mipi-video-phy" and "samsung,exynos5433-mipi-video-phy" -supports additional fifth PHY: - 4 - MIPI CSIS 2. - Samsung Exynos SoC series Display Port PHY ------------------------------------------------- -- cgit From e15db37f6aff088747420cab36c95a4088290865 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 29 Jan 2022 20:36:42 +0100 Subject: dt-bindings: phy: samsung,dp-video-phy: convert to dtschema Convert the Samsung SoC DisplayPort PHY bindings to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220129193646.372481-4-krzysztof.kozlowski@canonical.com Signed-off-by: Vinod Koul --- .../bindings/phy/samsung,dp-video-phy.yaml | 41 ++++++++++++++++++++++ .../devicetree/bindings/phy/samsung-phy.txt | 11 ------ 2 files changed, 41 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml new file mode 100644 index 000000000000..838c6d480ce6 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/samsung,dp-video-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC DisplayPort PHY + +maintainers: + - Krzysztof Kozlowski + - Marek Szyprowski + - Sylwester Nawrocki + +properties: + compatible: + enum: + - samsung,exynos5250-dp-video-phy + - samsung,exynos5420-dp-video-phy + + "#phy-cells": + const: 0 + + samsung,pmu-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to PMU system controller interface. + +required: + - compatible + - "#phy-cells" + - samsung,pmu-syscon + +additionalProperties: false + +examples: + - | + phy { + compatible = "samsung,exynos5420-dp-video-phy"; + samsung,pmu-syscon = <&pmu_system_controller>; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 6ab16734eb65..839ffe2a2d05 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -1,14 +1,3 @@ -Samsung Exynos SoC series Display Port PHY -------------------------------------------------- - -Required properties: -- compatible : should be one of the following supported values: - - "samsung,exynos5250-dp-video-phy" - - "samsung,exynos5420-dp-video-phy" -- samsung,pmu-syscon: phandle for PMU system controller interface, used to - control pmu registers for power isolation. -- #phy-cells : from the generic PHY bindings, must be 0; - Samsung S5P/Exynos SoC series USB PHY ------------------------------------------------- -- cgit From 4bbb2b22075ded735a3c5eef971d59ebc32e305f Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 29 Jan 2022 20:36:43 +0100 Subject: dt-bindings: phy: samsung,usb2-phy: convert to dtschema Convert the Samsung SoC USB 2.0 PHY bindings to DT schema format. Except the conversion, add also vbus-supply property which was already used by the driver and DTS. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220129193646.372481-5-krzysztof.kozlowski@canonical.com Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/samsung,usb2-phy.yaml | 102 +++++++++++++++++++++ .../devicetree/bindings/phy/samsung-phy.txt | 60 ------------ 2 files changed, 102 insertions(+), 60 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml new file mode 100644 index 000000000000..056e270a4e88 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml @@ -0,0 +1,102 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/samsung,usb2-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5P/Exynos SoC USB 2.0 PHY + +maintainers: + - Krzysztof Kozlowski + - Marek Szyprowski + - Sylwester Nawrocki + +description: | + The first phandle argument in the PHY specifier identifies the PHY, its + meaning is compatible dependent. For the currently supported SoCs (Exynos4210 + and Exynos4212) it is as follows:: + 0 - USB device ("device"), + 1 - USB host ("host"), + 2 - HSIC0 ("hsic0"), + 3 - HSIC1 ("hsic1"), + Exynos3250 has only USB device phy available as phy 0. + + Exynos4210 and Exynos4212 use mode switching and require that mode switch + register is supplied. + +properties: + compatible: + enum: + - samsung,exynos3250-usb2-phy + - samsung,exynos4210-usb2-phy + - samsung,exynos4x12-usb2-phy + - samsung,exynos5250-usb2-phy + - samsung,exynos5420-usb2-phy + - samsung,s5pv210-usb2-phy + + clocks: + items: + - description: PHY module gate clock. + - description: Reference rate clock of PHY module. + + clock-names: + items: + - const: phy + - const: ref + + "#phy-cells": + const: 1 + + reg: + maxItems: 1 + + samsung,pmureg-phandle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to PMU system controller interface. + + samsung,sysreg-phandle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to system registers interface. + + vbus-supply: + description: + VBUS power source. + +required: + - compatible + - clocks + - clock-names + - "#phy-cells" + - reg + - samsung,pmureg-phandle + +allOf: + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos4x12-usb2-phy + - samsung,exynos5250-usb2-phy + - samsung,exynos5420-usb2-phy + then: + required: + - samsung,sysreg-phandle + +additionalProperties: false + +examples: + - | + #include + + phy@12130000 { + compatible = "samsung,exynos5420-usb2-phy"; + reg = <0x12130000 0x100>; + #phy-cells = <1>; + clocks = <&clock CLK_USBH20>, <&clock CLK_SCLK_USBPHY300>; + clock-names = "phy", "ref"; + samsung,sysreg-phandle = <&sysreg_system_controller>; + samsung,pmureg-phandle = <&pmu_system_controller>; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 839ffe2a2d05..d26ac7401258 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -1,63 +1,3 @@ -Samsung S5P/Exynos SoC series USB PHY -------------------------------------------------- - -Required properties: -- compatible : should be one of the listed compatibles: - - "samsung,exynos3250-usb2-phy" - - "samsung,exynos4210-usb2-phy" - - "samsung,exynos4x12-usb2-phy" - - "samsung,exynos5250-usb2-phy" - - "samsung,exynos5420-usb2-phy" - - "samsung,s5pv210-usb2-phy" -- reg : a list of registers used by phy driver - - first and obligatory is the location of phy modules registers -- samsung,sysreg-phandle - handle to syscon used to control the system registers -- samsung,pmureg-phandle - handle to syscon used to control PMU registers -- #phy-cells : from the generic phy bindings, must be 1; -- clocks and clock-names: - - the "phy" clock is required by the phy module, used as a gate - - the "ref" clock is used to get the rate of the clock provided to the - PHY module - -Optional properties: -- vbus-supply: power-supply phandle for vbus power source - -The first phandle argument in the PHY specifier identifies the PHY, its -meaning is compatible dependent. For the currently supported SoCs (Exynos 4210 -and Exynos 4212) it is as follows: - 0 - USB device ("device"), - 1 - USB host ("host"), - 2 - HSIC0 ("hsic0"), - 3 - HSIC1 ("hsic1"), -Exynos3250 has only USB device phy available as phy 0. - -Exynos 4210 and Exynos 4212 use mode switching and require that mode switch -register is supplied. - -Example: - -For Exynos 4412 (compatible with Exynos 4212): - -usbphy: phy@125b0000 { - compatible = "samsung,exynos4x12-usb2-phy"; - reg = <0x125b0000 0x100>; - clocks = <&clock 305>, <&clock 2>; - clock-names = "phy", "ref"; - #phy-cells = <1>; - samsung,sysreg-phandle = <&sys_reg>; - samsung,pmureg-phandle = <&pmu_reg>; -}; - -Then the PHY can be used in other nodes such as: - -phy-consumer@12340000 { - phys = <&usbphy 2>; - phy-names = "phy"; -}; - -Refer to DT bindings documentation of particular PHY consumer devices for more -information about required PHYs and the way of specification. - Samsung SATA PHY Controller --------------------------- -- cgit From 3ce97f25b75f5182f553a9ad76555c1ea7fd4fc3 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 29 Jan 2022 20:36:44 +0100 Subject: dt-bindings: phy: samsung,exynos5250-sata-phy: convert to dtschema Convert the Samsung Exynos5250 SoC SATA PHY bindings to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220129193646.372481-6-krzysztof.kozlowski@canonical.com Signed-off-by: Vinod Koul --- .../bindings/phy/samsung,exynos5250-sata-phy.yaml | 64 ++++++++++++++++++++++ .../devicetree/bindings/phy/samsung-phy.txt | 26 --------- 2 files changed, 64 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/samsung,exynos5250-sata-phy.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos5250-sata-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos5250-sata-phy.yaml new file mode 100644 index 000000000000..62b39bb46585 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung,exynos5250-sata-phy.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/samsung,exynos5250-sata-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos5250 SoC SATA PHY + +maintainers: + - Krzysztof Kozlowski + - Marek Szyprowski + - Sylwester Nawrocki + +properties: + compatible: + const: samsung,exynos5250-sata-phy + + clocks: + maxItems: 1 + + clock-names: + items: + - const: sata_phyctrl + + "#phy-cells": + const: 0 + + reg: + maxItems: 1 + + samsung,syscon-phandle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to PMU system controller interface. + + samsung,exynos-sataphy-i2c-phandle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to I2C SATA interface. + +required: + - compatible + - clocks + - clock-names + - "#phy-cells" + - reg + - samsung,syscon-phandle + - samsung,exynos-sataphy-i2c-phandle + +additionalProperties: false + +examples: + - | + #include + + phy@12170000 { + compatible = "samsung,exynos5250-sata-phy"; + reg = <0x12170000 0x1ff>; + clocks = <&clock CLK_SATA_PHYCTRL>; + clock-names = "sata_phyctrl"; + #phy-cells = <0>; + samsung,syscon-phandle = <&pmu_system_controller>; + samsung,exynos-sataphy-i2c-phandle = <&sata_phy_i2c>; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index d26ac7401258..1ee78016dc72 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -1,29 +1,3 @@ -Samsung SATA PHY Controller ---------------------------- - -SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers. -Each SATA PHY controller should have its own node. - -Required properties: -- compatible : compatible list, contains "samsung,exynos5250-sata-phy" -- reg : offset and length of the SATA PHY register set; -- #phy-cells : must be zero -- clocks : must be exactly one entry -- clock-names : must be "sata_phyctrl" -- samsung,exynos-sataphy-i2c-phandle : a phandle to the I2C device, no arguments -- samsung,syscon-phandle : a phandle to the PMU system controller, no arguments - -Example: - sata_phy: sata-phy@12170000 { - compatible = "samsung,exynos5250-sata-phy"; - reg = <0x12170000 0x1ff>; - clocks = <&clock 287>; - clock-names = "sata_phyctrl"; - #phy-cells = <0>; - samsung,exynos-sataphy-i2c-phandle = <&sata_phy_i2c>; - samsung,syscon-phandle = <&pmu_syscon>; - }; - Device-Tree bindings for sataphy i2c client driver -------------------------------------------------- -- cgit From 5a6aa8683c155133923312f0826196ca1e872ee7 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 29 Jan 2022 20:36:45 +0100 Subject: dt-bindings: phy: samsung: move SATA phy I2C to trivial devices The I2C interface for Samsung Exynos SoC SATA phy is a very simple and limited, so move it to trivial devices. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220129193646.372481-7-krzysztof.kozlowski@canonical.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/samsung-phy.txt | 14 -------------- Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ 2 files changed, 2 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 1ee78016dc72..b0abeb4ac0a2 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -1,17 +1,3 @@ -Device-Tree bindings for sataphy i2c client driver --------------------------------------------------- - -Required properties: -compatible: Should be "samsung,exynos-sataphy-i2c" -- reg: I2C address of the sataphy i2c device. - -Example: - - sata_phy_i2c:sata-phy@38 { - compatible = "samsung,exynos-sataphy-i2c"; - reg = <0x38>; - }; - Samsung Exynos5 SoC series USB DRD PHY controller -------------------------------------------------- diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 091792ba993e..d53a4b2f81aa 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -283,6 +283,8 @@ properties: - renesas,isl29501 # S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power) - samsung,24ad0xd1 + # Samsung Exynos SoC SATA PHY I2C device + - samsung,exynos-sataphy-i2c # Sensirion low power multi-pixel gas sensor with I2C interface - sensirion,sgpc3 # Sensirion multi-pixel gas sensor with I2C interface -- cgit From 60c24dbfc54f27027a9d72a968fcf7d20aeb8b1f Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 29 Jan 2022 20:36:46 +0100 Subject: dt-bindings: phy: samsung,usb3-drd-phy: convert to dtschema Convert the Samsung Exynos USB 3.0 DRD PHY bindings to DT schema format. Except the conversion, add also vbus-supply and vbus-boost-supply properties which were already used by the driver and DTS. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220129193646.372481-8-krzysztof.kozlowski@canonical.com Signed-off-by: Vinod Koul --- .../bindings/phy/samsung,usb3-drd-phy.yaml | 126 +++++++++++++++++++++ .../devicetree/bindings/phy/samsung-phy.txt | 53 --------- 2 files changed, 126 insertions(+), 53 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml delete mode 100644 Documentation/devicetree/bindings/phy/samsung-phy.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml new file mode 100644 index 000000000000..f83f0f8135b9 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/samsung,usb3-drd-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC USB 3.0 DRD PHY USB 2.0 PHY + +maintainers: + - Krzysztof Kozlowski + - Marek Szyprowski + - Sylwester Nawrocki + +description: | + For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy + compatible PHYs, the second cell in the PHY specifier identifies the + PHY id, which is interpreted as follows:: + 0 - UTMI+ type phy, + 1 - PIPE3 type phy. + + For SoCs like Exynos5420 having multiple USB 3.0 DRD PHY controllers, + 'usbdrd_phy' nodes should have numbered alias in the aliases node, in the + form of usbdrdphyN, N = 0, 1... (depending on number of controllers). + +properties: + compatible: + enum: + - samsung,exynos5250-usbdrd-phy + - samsung,exynos5420-usbdrd-phy + - samsung,exynos5433-usbdrd-phy + - samsung,exynos7-usbdrd-phy + + clocks: + minItems: 2 + maxItems: 5 + + clock-names: + minItems: 2 + maxItems: 5 + description: | + At least two clocks:: + - Main PHY clock (same as USB DRD controller i.e. DWC3 IP clock), used + for register access. + - PHY reference clock (usually crystal clock), used for PHY operations, + associated by phy name. It is used to determine bit values for clock + settings register. For Exynos5420 this is given as 'sclk_usbphy30' + in the CMU. + + "#phy-cells": + const: 1 + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + Any connector to the data bus of this controller should be modelled using + the OF graph bindings specified. + + reg: + maxItems: 1 + + samsung,pmu-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to PMU system controller interface. + + vbus-supply: + description: + VBUS power source. + + vbus-boost-supply: + description: + VBUS Boost 5V power source. + +required: + - compatible + - clocks + - clock-names + - "#phy-cells" + - reg + - samsung,pmu-syscon + +allOf: + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos5433-usbdrd-phy + - samsung,exynos7-usbdrd-phy + then: + properties: + clocks: + minItems: 5 + maxItems: 5 + clock-names: + items: + - const: phy + - const: ref + - const: phy_utmi + - const: phy_pipe + - const: itp + else: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: phy + - const: ref + +additionalProperties: false + +examples: + - | + #include + + phy@12100000 { + compatible = "samsung,exynos5420-usbdrd-phy"; + reg = <0x12100000 0x100>; + #phy-cells = <1>; + clocks = <&clock CLK_USBD300>, <&clock CLK_SCLK_USBPHY300>; + clock-names = "phy", "ref"; + samsung,pmu-syscon = <&pmu_system_controller>; + vbus-supply = <&usb300_vbus_reg>; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt deleted file mode 100644 index b0abeb4ac0a2..000000000000 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ /dev/null @@ -1,53 +0,0 @@ -Samsung Exynos5 SoC series USB DRD PHY controller --------------------------------------------------- - -Required properties: -- compatible : Should be set to one of the following supported values: - - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC, - - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC. - - "samsung,exynos5433-usbdrd-phy" - for exynos5433 SoC. - - "samsung,exynos7-usbdrd-phy" - for exynos7 SoC. -- reg : Register offset and length of USB DRD PHY register set; -- clocks: Clock IDs array as required by the controller -- clock-names: names of clocks correseponding to IDs in the clock property; - Required clocks: - - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock), - used for register access. - - ref: PHY's reference clock (usually crystal clock), used for - PHY operations, associated by phy name. It is used to - determine bit values for clock settings register. - For Exynos5420 this is given as 'sclk_usbphy30' in CMU. - - optional clocks: Exynos5433 & Exynos7 SoC has now following additional - gate clocks available: - - phy_pipe: for PIPE3 phy - - phy_utmi: for UTMI+ phy - - itp: for ITP generation -- samsung,pmu-syscon: phandle for PMU system controller interface, used to - control pmu registers for power isolation. -- #phy-cells : from the generic PHY bindings, must be 1; - -For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy" -compatible PHYs, the second cell in the PHY specifier identifies the -PHY id, which is interpreted as follows: - 0 - UTMI+ type phy, - 1 - PIPE3 type phy, - -Example: - usbdrd_phy: usbphy@12100000 { - compatible = "samsung,exynos5250-usbdrd-phy"; - reg = <0x12100000 0x100>; - clocks = <&clock 286>, <&clock 1>; - clock-names = "phy", "ref"; - samsung,pmu-syscon = <&pmu_system_controller>; - #phy-cells = <1>; - }; - -- aliases: For SoCs like Exynos5420 having multiple USB 3.0 DRD PHY controllers, - 'usbdrd_phy' nodes should have numbered alias in the aliases node, - in the form of usbdrdphyN, N = 0, 1... (depending on number of - controllers). -Example: - aliases { - usbdrdphy0 = &usb3_phy0; - usbdrdphy1 = &usb3_phy1; - }; -- cgit From 26b982ca83210684b04191b73a7bbc02cdd3164f Mon Sep 17 00:00:00 2001 From: Pali Rohár Date: Tue, 22 Feb 2022 16:50:22 +0100 Subject: dt-bindings: PCI: mvebu: Add num-lanes property MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Controller driver needs to correctly configure PCIe link if it contains 1 or 4 SerDes PCIe lanes. Therefore add a new 'num-lanes' DT property for mvebu PCIe controller. Property 'num-lanes' seems to be de-facto standard way how number of lanes is specified in other PCIe controllers. Link: https://lore.kernel.org/r/20220222155030.988-5-pali@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Acked-by: Rob Herring --- Documentation/devicetree/bindings/pci/mvebu-pci.txt | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt index 6173af6885f8..24225852bce0 100644 --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt @@ -77,6 +77,7 @@ and the following optional properties: - marvell,pcie-lane: the physical PCIe lane number, for ports having multiple lanes. If this property is not found, we assume that the value is 0. +- num-lanes: number of SerDes PCIe lanes for this link (1 or 4) - reset-gpios: optional GPIO to PERST# - reset-delay-us: delay in us to wait after reset de-assertion, if not specified will default to 100ms, as required by the PCIe specification. @@ -141,6 +142,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 58>; marvell,pcie-port = <0>; marvell,pcie-lane = <0>; + num-lanes = <1>; /* low-active PERST# reset on GPIO 25 */ reset-gpios = <&gpio0 25 1>; /* wait 20ms for device settle after reset deassertion */ @@ -161,6 +163,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 59>; marvell,pcie-port = <0>; marvell,pcie-lane = <1>; + num-lanes = <1>; clocks = <&gateclk 6>; }; @@ -177,6 +180,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 60>; marvell,pcie-port = <0>; marvell,pcie-lane = <2>; + num-lanes = <1>; clocks = <&gateclk 7>; }; @@ -193,6 +197,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 61>; marvell,pcie-port = <0>; marvell,pcie-lane = <3>; + num-lanes = <1>; clocks = <&gateclk 8>; }; @@ -209,6 +214,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 62>; marvell,pcie-port = <1>; marvell,pcie-lane = <0>; + num-lanes = <1>; clocks = <&gateclk 9>; }; @@ -225,6 +231,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 63>; marvell,pcie-port = <1>; marvell,pcie-lane = <1>; + num-lanes = <1>; clocks = <&gateclk 10>; }; @@ -241,6 +248,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 64>; marvell,pcie-port = <1>; marvell,pcie-lane = <2>; + num-lanes = <1>; clocks = <&gateclk 11>; }; @@ -257,6 +265,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 65>; marvell,pcie-port = <1>; marvell,pcie-lane = <3>; + num-lanes = <1>; clocks = <&gateclk 12>; }; @@ -273,6 +282,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 99>; marvell,pcie-port = <2>; marvell,pcie-lane = <0>; + num-lanes = <1>; clocks = <&gateclk 26>; }; @@ -289,6 +299,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 103>; marvell,pcie-port = <3>; marvell,pcie-lane = <0>; + num-lanes = <1>; clocks = <&gateclk 27>; }; }; -- cgit From 0124989220f21b5275f6bf9ad9a924c8fb278dce Mon Sep 17 00:00:00 2001 From: Pali Rohár Date: Tue, 22 Feb 2022 16:50:27 +0100 Subject: dt-bindings: PCI: mvebu: Update information about intx interrupts MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Link: https://lore.kernel.org/r/20220222155030.988-10-pali@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Acked-by: Rob Herring --- Documentation/devicetree/bindings/pci/mvebu-pci.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt index 24225852bce0..6d022a9d36ee 100644 --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt @@ -81,6 +81,11 @@ and the following optional properties: - reset-gpios: optional GPIO to PERST# - reset-delay-us: delay in us to wait after reset de-assertion, if not specified will default to 100ms, as required by the PCIe specification. +- interrupt-names: list of interrupt names, supported are: + - "intx" - interrupt line triggered by one of the legacy interrupt +- interrupts or interrupts-extended: List of the interrupt sources which + corresponding to the "interrupt-names". If non-empty then also additional + 'interrupt-controller' subnode must be defined. Example: -- cgit From e0891269a8c25715bd9510dc355326b00ab42db2 Mon Sep 17 00:00:00 2001 From: Mark Rutland Date: Wed, 16 Feb 2022 16:22:26 +0000 Subject: linkage: add SYM_FUNC_ALIAS{,_LOCAL,_WEAK}() Currently aliasing an asm function requires adding START and END annotations for each name, as per Documentation/asm-annotations.rst: SYM_FUNC_START_ALIAS(__memset) SYM_FUNC_START(memset) ... asm insns ... SYM_FUNC_END(memset) SYM_FUNC_END_ALIAS(__memset) This is more painful than necessary to maintain, especially where a function has many aliases, some of which we may wish to define conditionally. For example, arm64's memcpy/memmove implementation (which uses some arch-specific SYM_*() helpers) has: SYM_FUNC_START_ALIAS(__memmove) SYM_FUNC_START_ALIAS_WEAK_PI(memmove) SYM_FUNC_START_ALIAS(__memcpy) SYM_FUNC_START_WEAK_PI(memcpy) ... asm insns ... SYM_FUNC_END_PI(memcpy) EXPORT_SYMBOL(memcpy) SYM_FUNC_END_ALIAS(__memcpy) EXPORT_SYMBOL(__memcpy) SYM_FUNC_END_ALIAS_PI(memmove) EXPORT_SYMBOL(memmove) SYM_FUNC_END_ALIAS(__memmove) EXPORT_SYMBOL(__memmove) SYM_FUNC_START(name) It would be much nicer if we could define the aliases *after* the standard function definition. This would avoid the need to specify each symbol name twice, and would make it easier to spot the canonical function definition. This patch adds new macros to allow us to do so, which allows the above example to be rewritten more succinctly as: SYM_FUNC_START(__pi_memcpy) ... asm insns ... SYM_FUNC_END(__pi_memcpy) SYM_FUNC_ALIAS(__memcpy, __pi_memcpy) EXPORT_SYMBOL(__memcpy) SYM_FUNC_ALIAS_WEAK(memcpy, __memcpy) EXPORT_SYMBOL(memcpy) SYM_FUNC_ALIAS(__pi_memmove, __pi_memcpy) SYM_FUNC_ALIAS(__memmove, __pi_memmove) EXPORT_SYMBOL(__memmove) SYM_FUNC_ALIAS_WEAK(memmove, __memmove) EXPORT_SYMBOL(memmove) The reduction in duplication will also make it possible to replace some uses of WEAK with more accurate Kconfig guards, e.g. #ifndef CONFIG_KASAN SYM_FUNC_ALIAS(memmove, __memmove) EXPORT_SYMBOL(memmove) #endif ... which should make it easier to ensure that symbols are neither used nor overidden unexpectedly. The existing SYM_FUNC_START_ALIAS() and SYM_FUNC_START_LOCAL_ALIAS() are marked as deprecated, and will be removed once existing users are moved over to the new scheme. The tools/perf/ copy of linkage.h is updated to match. A subsequent patch will depend upon this when updating the x86 asm annotations. Signed-off-by: Mark Rutland Acked-by: Ard Biesheuvel Acked-by: Josh Poimboeuf Acked-by: Mark Brown Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Jiri Slaby Cc: Peter Zijlstra Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20220216162229.1076788-2-mark.rutland@arm.com Signed-off-by: Will Deacon --- Documentation/asm-annotations.rst | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/asm-annotations.rst b/Documentation/asm-annotations.rst index f4bf0f6395fb..4868b58c60fb 100644 --- a/Documentation/asm-annotations.rst +++ b/Documentation/asm-annotations.rst @@ -130,8 +130,20 @@ denoting a range of code via ``SYM_*_START/END`` annotations. In fact, this kind of annotation corresponds to the now deprecated ``ENTRY`` and ``ENDPROC`` macros. -* ``SYM_FUNC_START_ALIAS`` and ``SYM_FUNC_START_LOCAL_ALIAS`` serve for those - who decided to have two or more names for one function. The typical use is:: +* ``SYM_FUNC_ALIAS``, ``SYM_FUNC_ALIAS_LOCAL``, and ``SYM_FUNC_ALIAS_WEAK`` can + be used to define multiple names for a function. The typical use is:: + + SYM_FUNC_START(__memset) + ... asm insns ... + SYN_FUNC_END(__memset) + SYM_FUNC_ALIAS(memset, __memset) + + In this example, one can call ``__memset`` or ``memset`` with the same + result, except the debug information for the instructions is generated to + the object file only once -- for the non-``ALIAS`` case. + +* ``SYM_FUNC_START_ALIAS`` and ``SYM_FUNC_START_LOCAL_ALIAS`` are deprecated + ways to define two or more names for one function. The typical use is:: SYM_FUNC_START_ALIAS(__memset) SYM_FUNC_START(memset) -- cgit From be9aea74400433e03c2a8b0260fc9ffe2495f698 Mon Sep 17 00:00:00 2001 From: Mark Rutland Date: Wed, 16 Feb 2022 16:22:29 +0000 Subject: linkage: remove SYM_FUNC_{START,END}_ALIAS() Now that all aliases are defined using SYM_FUNC_ALIAS(), remove the old SYM_FUNC_{START,END}_ALIAS() macros. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland Acked-by: Ard Biesheuvel Acked-by: Josh Poimboeuf Acked-by: Mark Brown Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Jiri Slaby Cc: Peter Zijlstra Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20220216162229.1076788-5-mark.rutland@arm.com Signed-off-by: Will Deacon --- Documentation/asm-annotations.rst | 13 ------------- 1 file changed, 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/asm-annotations.rst b/Documentation/asm-annotations.rst index 4868b58c60fb..a64f2ca469d4 100644 --- a/Documentation/asm-annotations.rst +++ b/Documentation/asm-annotations.rst @@ -142,19 +142,6 @@ denoting a range of code via ``SYM_*_START/END`` annotations. result, except the debug information for the instructions is generated to the object file only once -- for the non-``ALIAS`` case. -* ``SYM_FUNC_START_ALIAS`` and ``SYM_FUNC_START_LOCAL_ALIAS`` are deprecated - ways to define two or more names for one function. The typical use is:: - - SYM_FUNC_START_ALIAS(__memset) - SYM_FUNC_START(memset) - ... asm insns ... - SYM_FUNC_END(memset) - SYM_FUNC_END_ALIAS(__memset) - - In this example, one can call ``__memset`` or ``memset`` with the same - result, except the debug information for the instructions is generated to - the object file only once -- for the non-``ALIAS`` case. - * ``SYM_CODE_START`` and ``SYM_CODE_START_LOCAL`` should be used only in special cases -- if you know what you are doing. This is used exclusively for interrupt handlers and similar where the calling convention is not the C -- cgit From 5dad90f360579534cf19444a7db8532258f811e9 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 21 Feb 2022 09:22:26 +0100 Subject: dt-bindings: vendor-prefixes: add second HiSilicon prefix There are few boards DTS using "hisi,rst-syscon" property - undocumented "hisi" prefix. The property will not be changed in DTS to non-deprecated one, because of compatibility reasons. Add deprecated "hisi" prefix to silence DT schema warnings. Cc: Wei Xu Cc: David Heidelberg Signed-off-by: Krzysztof Kozlowski Reviewed-by: David Heidelberg Reviewed-by: Wei Xu Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220221082228.34407-1-krzysztof.kozlowski@canonical.com --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 913f722a6b8d..fc2838960323 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -499,6 +499,9 @@ patternProperties: description: Himax Technologies, Inc. "^hirschmann,.*": description: Hirschmann Automation and Control GmbH + "^hisi,.*": + description: HiSilicon Limited (deprecated, use hisilicon) + deprecated: true "^hisilicon,.*": description: HiSilicon Limited. "^hit,.*": -- cgit From aaffb26991bca8cae5f00bb65f0b5a190ca71929 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 21 Feb 2022 09:22:27 +0100 Subject: dt-bindings: vendor-prefixes: add second Synopsys prefix There are few bindings with compatibles starting with a "synopsys" prefix. Document it as deprecated, to be sure no new usages will appear. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220221082228.34407-2-krzysztof.kozlowski@canonical.com --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index fc2838960323..3da2b08429e1 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1186,6 +1186,9 @@ patternProperties: description: Synaptics Inc. "^synology,.*": description: Synology, Inc. + "^synopsys,.*": + description: Synopsys, Inc. (deprecated, use snps) + deprecated: true "^tbs,.*": description: TBS Technologies "^tbs-biometrics,.*": -- cgit From 16234ef1d2aa170e37c27734ab6544633707ba19 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 21 Feb 2022 09:22:28 +0100 Subject: dt-bindings: usb: do not use deprecated synopsys prefix The "synopsys" prefix and "synopsys,dwc3" compatible are deprecated. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220221082228.34407-3-krzysztof.kozlowski@canonical.com --- Documentation/devicetree/bindings/usb/dwc3-cavium.txt | 2 +- Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/dwc3-cavium.txt b/Documentation/devicetree/bindings/usb/dwc3-cavium.txt index 710b782ccf65..171df79360ff 100644 --- a/Documentation/devicetree/bindings/usb/dwc3-cavium.txt +++ b/Documentation/devicetree/bindings/usb/dwc3-cavium.txt @@ -20,7 +20,7 @@ Example device node: refclk-type-hs = "dlmc_ref_clk0"; power = <0x00000002 0x00000002 0x00000001>; xhci@1690000000000 { - compatible = "cavium,octeon-7130-xhci", "synopsys,dwc3"; + compatible = "cavium,octeon-7130-xhci", "snps,dwc3"; reg = <0x00016900 0x00000000 0x00000010 0x00000000>; interrupt-parent = <0x00000010>; interrupts = <0x00000009 0x00000004>; diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml index f6e91a5fd8fe..b1f65a656528 100644 --- a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml @@ -92,7 +92,7 @@ examples: ranges; usb@2690000 { - compatible = "synopsys,dwc3"; + compatible = "snps,dwc3"; reg = <0x2690000 0x70000>; interrupts = ; usb-phy = <&usb_phy>, <&usb_phy>; -- cgit From 201d41745ea9173e0463a164af493c2c49c29e80 Mon Sep 17 00:00:00 2001 From: Loic Poulain Date: Mon, 14 Feb 2022 16:37:40 +0100 Subject: dt-bindings: msm/dsi: Add qcm2290 dsi controller binding Add DSI block specific qcm2290 compatible string as valid Qualcomm DSI controller. Signed-off-by: Loic Poulain Acked-by: Rob Herring Patchwork: https://patchwork.freedesktop.org/patch/474090/ Link: https://lore.kernel.org/r/1644853060-12222-3-git-send-email-loic.poulain@linaro.org Signed-off-by: Dmitry Baryshkov --- .../devicetree/bindings/display/msm/dsi-controller-main.yaml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 35426fde8610..7095ec3c890d 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -14,8 +14,9 @@ allOf: properties: compatible: - items: - - const: qcom,mdss-dsi-ctrl + enum: + - qcom,mdss-dsi-ctrl + - qcom,dsi-ctrl-6g-qcm2290 reg: maxItems: 1 -- cgit From 164f69d9d45a605574c0d0f05a21a6faf6f33657 Mon Sep 17 00:00:00 2001 From: Loic Poulain Date: Mon, 14 Feb 2022 16:29:07 +0100 Subject: dt-bindings: msm: disp: add yaml schemas for QCM2290 DPU bindings QCM2290 MSM Mobile Display Subsystem (MDSS) encapsulates sub-blocks like DPU display controller, DSI etc. Add YAML schema for DPU device tree bindings Signed-off-by: Loic Poulain Reviewed-by: Rob Herring Patchwork: https://patchwork.freedesktop.org/patch/474091/ Link: https://lore.kernel.org/r/1644852547-10067-2-git-send-email-loic.poulain@linaro.org Signed-off-by: Dmitry Baryshkov --- .../bindings/display/msm/dpu-qcm2290.yaml | 214 +++++++++++++++++++++ 1 file changed, 214 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml new file mode 100644 index 000000000000..8766b13f0c46 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml @@ -0,0 +1,214 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dpu-qcm2290.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DPU dt properties for QCM2290 target + +maintainers: + - Loic Poulain + +description: | + Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates + sub-blocks like DPU display controller and DSI. Device tree bindings of MDSS + and DPU are mentioned for QCM2290 target. + +properties: + compatible: + items: + - const: qcom,qcm2290-mdss + + reg: + maxItems: 1 + + reg-names: + const: mdss + + power-domains: + maxItems: 1 + + clocks: + items: + - description: Display AHB clock from gcc + - description: Display AXI clock + - description: Display core clock + + clock-names: + items: + - const: iface + - const: bus + - const: core + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#address-cells": true + + "#size-cells": true + + "#interrupt-cells": + const: 1 + + iommus: + items: + - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0 + - description: Phandle to apps_smmu node with SID mask for Hard-Fail port1 + + ranges: true + + interconnects: + items: + - description: Interconnect path specifying the port ids for data bus + + interconnect-names: + const: mdp0-mem + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + description: Node containing the properties of DPU. + + properties: + compatible: + items: + - const: qcom,qcm2290-dpu + + reg: + items: + - description: Address offset and size for mdp register set + - description: Address offset and size for vbif register set + + reg-names: + items: + - const: mdp + - const: vbif + + clocks: + items: + - description: Display AXI clock from gcc + - description: Display AHB clock from dispcc + - description: Display core clock from dispcc + - description: Display lut clock from dispcc + - description: Display vsync clock from dispcc + + clock-names: + items: + - const: bus + - const: iface + - const: core + - const: lut + - const: vsync + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + + operating-points-v2: true + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + Contains the list of output ports from DPU device. These ports + connect to interfaces that are external to the DPU hardware, + such as DSI. Each output port contains an endpoint that + describes how it is connected to an external interface. + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF1 (DSI1) + + required: + - port@0 + + required: + - compatible + - reg + - reg-names + - clocks + - interrupts + - power-domains + - operating-points-v2 + - ports + +required: + - compatible + - reg + - reg-names + - power-domains + - clocks + - interrupts + - interrupt-controller + - iommus + - ranges + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + #include + + mdss: mdss@5e00000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,qcm2290-mdss", "qcom,mdss"; + reg = <0x05e00000 0x1000>; + reg-names = "mdss"; + power-domains = <&dispcc MDSS_GDSC>; + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", "bus", "core"; + + interrupts = ; + interrupt-controller; + #interrupt-cells = <1>; + + interconnects = <&mmrt_virt MASTER_MDP0 &bimc SLAVE_EBI1>; + interconnect-names = "mdp0-mem"; + + iommus = <&apps_smmu 0x420 0x2>, + <&apps_smmu 0x421 0x0>; + ranges; + + mdss_mdp: mdp@5e01000 { + compatible = "qcom,qcm2290-dpu"; + reg = <0x05e01000 0x8f000>, + <0x05eb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "bus", "iface", "core", "lut", "vsync"; + + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmpd QCM2290_VDDCX>; + + interrupt-parent = <&mdss>; + interrupts = <0 IRQ_TYPE_NONE>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + }; + }; +... -- cgit From 1c4b5ecb7ea190fa3e9f9d6891e6c90b60e04f24 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Wed, 23 Feb 2022 08:47:20 +0100 Subject: remove the h8300 architecture Signed-off-by: Christoph Hellwig --- .../bindings/clock/renesas,h8300-div-clock.txt | 24 --------------- Documentation/devicetree/bindings/h8300/cpu.txt | 13 -------- .../interrupt-controller/renesas,h8300h-intc.txt | 22 -------------- .../interrupt-controller/renesas,h8s-intc.txt | 22 -------------- .../memory-controllers/renesas,h8300-bsc.yaml | 35 ---------------------- .../features/core/cBPF-JIT/arch-support.txt | 1 - .../features/core/eBPF-JIT/arch-support.txt | 1 - .../core/generic-idle-thread/arch-support.txt | 1 - .../features/core/jump-labels/arch-support.txt | 1 - .../core/thread-info-in-task/arch-support.txt | 1 - .../features/core/tracehook/arch-support.txt | 1 - .../features/debug/KASAN/arch-support.txt | 1 - .../debug/debug-vm-pgtable/arch-support.txt | 1 - .../debug/gcov-profile-all/arch-support.txt | 1 - Documentation/features/debug/kcov/arch-support.txt | 1 - Documentation/features/debug/kgdb/arch-support.txt | 1 - .../features/debug/kmemleak/arch-support.txt | 1 - .../debug/kprobes-on-ftrace/arch-support.txt | 1 - .../features/debug/kprobes/arch-support.txt | 1 - .../features/debug/kretprobes/arch-support.txt | 1 - .../features/debug/optprobes/arch-support.txt | 1 - .../features/debug/stackprotector/arch-support.txt | 1 - .../features/debug/uprobes/arch-support.txt | 1 - .../debug/user-ret-profiler/arch-support.txt | 1 - .../features/io/dma-contiguous/arch-support.txt | 1 - .../locking/cmpxchg-local/arch-support.txt | 1 - .../features/locking/lockdep/arch-support.txt | 1 - .../locking/queued-rwlocks/arch-support.txt | 1 - .../locking/queued-spinlocks/arch-support.txt | 1 - .../features/perf/kprobes-event/arch-support.txt | 1 - .../features/perf/perf-regs/arch-support.txt | 1 - .../features/perf/perf-stackdump/arch-support.txt | 1 - .../sched/membarrier-sync-core/arch-support.txt | 1 - .../features/sched/numa-balancing/arch-support.txt | 1 - .../seccomp/seccomp-filter/arch-support.txt | 1 - .../time/arch-tick-broadcast/arch-support.txt | 1 - .../features/time/clockevents/arch-support.txt | 1 - .../time/context-tracking/arch-support.txt | 1 - .../features/time/irq-time-acct/arch-support.txt | 1 - .../features/time/virt-cpuacct/arch-support.txt | 1 - .../features/vm/ELF-ASLR/arch-support.txt | 1 - .../features/vm/PG_uncached/arch-support.txt | 1 - Documentation/features/vm/THP/arch-support.txt | 1 - Documentation/features/vm/TLB/arch-support.txt | 1 - .../features/vm/huge-vmap/arch-support.txt | 1 - .../features/vm/ioremap_prot/arch-support.txt | 1 - .../features/vm/pte_special/arch-support.txt | 1 - 47 files changed, 158 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/renesas,h8300-div-clock.txt delete mode 100644 Documentation/devicetree/bindings/h8300/cpu.txt delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/renesas,h8300h-intc.txt delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/renesas,h8s-intc.txt delete mode 100644 Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,h8300-div-clock.txt b/Documentation/devicetree/bindings/clock/renesas,h8300-div-clock.txt deleted file mode 100644 index 399e0da22348..000000000000 --- a/Documentation/devicetree/bindings/clock/renesas,h8300-div-clock.txt +++ /dev/null @@ -1,24 +0,0 @@ -* Renesas H8/300 divider clock - -Required Properties: - - - compatible: Must be "renesas,h8300-div-clock" - - - clocks: Reference to the parent clocks ("extal1" and "extal2") - - - #clock-cells: Must be 1 - - - reg: Base address and length of the divide rate selector - - - renesas,width: bit width of selector - -Example -------- - - cclk: cclk { - compatible = "renesas,h8300-div-clock"; - clocks = <&xclk>; - #clock-cells = <0>; - reg = <0xfee01b 2>; - renesas,width = <2>; - }; diff --git a/Documentation/devicetree/bindings/h8300/cpu.txt b/Documentation/devicetree/bindings/h8300/cpu.txt deleted file mode 100644 index 70cd58608f4b..000000000000 --- a/Documentation/devicetree/bindings/h8300/cpu.txt +++ /dev/null @@ -1,13 +0,0 @@ -* H8/300 CPU bindings - -Required properties: - -- compatible: Compatible property value should be "renesas,h8300". -- clock-frequency: Contains the clock frequency for CPU, in Hz. - -Example: - - cpu@0 { - compatible = "renesas,h8300"; - clock-frequency = <20000000>; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,h8300h-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,h8300h-intc.txt deleted file mode 100644 index 56e8d82aff34..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,h8300h-intc.txt +++ /dev/null @@ -1,22 +0,0 @@ -* H8/300H Interrupt controller - -Required properties: - -- compatible: has to be "renesas,h8300h-intc", "renesas,h8300-intc" as fallback. -- #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in - interrupts.txt in this directory -- regs: Base address of interrupt controller registers. - -Optional properties: - -- any properties, listed in interrupts.txt, and any standard resource allocation - properties - -Example: - - h8intc: interrupt-controller@fee012 { - compatible = "renesas,h8300h-intc", "renesas,h8300-intc"; - #interrupt-cells = <2>; - interrupt-controller; - reg = <0xfee012 7>; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,h8s-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,h8s-intc.txt deleted file mode 100644 index faded2b1559b..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,h8s-intc.txt +++ /dev/null @@ -1,22 +0,0 @@ -* H8S Interrupt controller - -Required properties: - -- compatible: has to be "renesas,h8s-intc", "renesas,h8300-intc" as fallback. -- #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in - interrupts.txt in this directory -- regs: Base address of interrupt controller registers. - -Optional properties: - -- any properties, listed in interrupts.txt, and any standard resource allocation - properties - -Example: - - h8intc: interrupt-controller@fffe00 { - compatible = "renesas,h8s-intc", "renesas,h8300-intc"; - #interrupt-cells = <2>; - interrupt-controller; - reg = <0xfffe00 24>; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.yaml deleted file mode 100644 index 2b18cef99511..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.yaml +++ /dev/null @@ -1,35 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/memory-controllers/renesas,h8300-bsc.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: H8/300 bus controller - -maintainers: - - Krzysztof Kozlowski - - Yoshinori Sato - -properties: - compatible: - items: - - enum: - - renesas,h8300h-bsc - - renesas,h8s-bsc - - const: renesas,h8300-bsc - - reg: - maxItems: 1 - -required: - - compatible - - reg - -additionalProperties: false - -examples: - - | - memory-controller@fee01e { - compatible = "renesas,h8300h-bsc", "renesas,h8300-bsc"; - reg = <0xfee01e 8>; - }; diff --git a/Documentation/features/core/cBPF-JIT/arch-support.txt b/Documentation/features/core/cBPF-JIT/arch-support.txt index e59b5215402d..55b2aca6a2c3 100644 --- a/Documentation/features/core/cBPF-JIT/arch-support.txt +++ b/Documentation/features/core/cBPF-JIT/arch-support.txt @@ -11,7 +11,6 @@ | arm: | TODO | | arm64: | TODO | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/core/eBPF-JIT/arch-support.txt b/Documentation/features/core/eBPF-JIT/arch-support.txt index dcbd8679f514..92b723e897d7 100644 --- a/Documentation/features/core/eBPF-JIT/arch-support.txt +++ b/Documentation/features/core/eBPF-JIT/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/core/generic-idle-thread/arch-support.txt b/Documentation/features/core/generic-idle-thread/arch-support.txt index 4efcba7b5239..c1e69d518f1d 100644 --- a/Documentation/features/core/generic-idle-thread/arch-support.txt +++ b/Documentation/features/core/generic-idle-thread/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | ok | | ia64: | ok | | m68k: | TODO | diff --git a/Documentation/features/core/jump-labels/arch-support.txt b/Documentation/features/core/jump-labels/arch-support.txt index 0c801d1bd2da..968ffd3fa20b 100644 --- a/Documentation/features/core/jump-labels/arch-support.txt +++ b/Documentation/features/core/jump-labels/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/core/thread-info-in-task/arch-support.txt b/Documentation/features/core/thread-info-in-task/arch-support.txt index bc74d8beea72..cefb0ed6adca 100644 --- a/Documentation/features/core/thread-info-in-task/arch-support.txt +++ b/Documentation/features/core/thread-info-in-task/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/core/tracehook/arch-support.txt b/Documentation/features/core/tracehook/arch-support.txt index af34308fce7f..8e1ad2dc15d8 100644 --- a/Documentation/features/core/tracehook/arch-support.txt +++ b/Documentation/features/core/tracehook/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | ok | | ia64: | ok | | m68k: | TODO | diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt index c244ac7eee26..72392302c543 100644 --- a/Documentation/features/debug/KASAN/arch-support.txt +++ b/Documentation/features/debug/KASAN/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt index fa83403b4aec..db10ff31805d 100644 --- a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt +++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt @@ -11,7 +11,6 @@ | arm: | TODO | | arm64: | ok | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/debug/gcov-profile-all/arch-support.txt b/Documentation/features/debug/gcov-profile-all/arch-support.txt index b39c1a5de3f3..8c972103d18c 100644 --- a/Documentation/features/debug/gcov-profile-all/arch-support.txt +++ b/Documentation/features/debug/gcov-profile-all/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/debug/kcov/arch-support.txt b/Documentation/features/debug/kcov/arch-support.txt index 7e44013cc320..e0412ef3ed7d 100644 --- a/Documentation/features/debug/kcov/arch-support.txt +++ b/Documentation/features/debug/kcov/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/debug/kgdb/arch-support.txt b/Documentation/features/debug/kgdb/arch-support.txt index 2cb0576f9180..2dfd383cbe55 100644 --- a/Documentation/features/debug/kgdb/arch-support.txt +++ b/Documentation/features/debug/kgdb/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | TODO | - | h8300: | ok | | hexagon: | ok | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/debug/kmemleak/arch-support.txt b/Documentation/features/debug/kmemleak/arch-support.txt index e9ac415f8aec..7408dc258f57 100644 --- a/Documentation/features/debug/kmemleak/arch-support.txt +++ b/Documentation/features/debug/kmemleak/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt index 96156e8802a7..fe707c04794a 100644 --- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt @@ -11,7 +11,6 @@ | arm: | TODO | | arm64: | TODO | | csky: | ok | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/debug/kprobes/arch-support.txt b/Documentation/features/debug/kprobes/arch-support.txt index ee95ed61909a..7f4ef559ff60 100644 --- a/Documentation/features/debug/kprobes/arch-support.txt +++ b/Documentation/features/debug/kprobes/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | TODO | | ia64: | ok | | m68k: | TODO | diff --git a/Documentation/features/debug/kretprobes/arch-support.txt b/Documentation/features/debug/kretprobes/arch-support.txt index 612cb97d47b8..0eace8acbde1 100644 --- a/Documentation/features/debug/kretprobes/arch-support.txt +++ b/Documentation/features/debug/kretprobes/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | TODO | | ia64: | ok | | m68k: | TODO | diff --git a/Documentation/features/debug/optprobes/arch-support.txt b/Documentation/features/debug/optprobes/arch-support.txt index d6ff141a6122..b0cbb80e2138 100644 --- a/Documentation/features/debug/optprobes/arch-support.txt +++ b/Documentation/features/debug/optprobes/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | TODO | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/debug/stackprotector/arch-support.txt b/Documentation/features/debug/stackprotector/arch-support.txt index ad4de22a71ab..7776884e9d0d 100644 --- a/Documentation/features/debug/stackprotector/arch-support.txt +++ b/Documentation/features/debug/stackprotector/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/debug/uprobes/arch-support.txt b/Documentation/features/debug/uprobes/arch-support.txt index 8bd5548a4485..080257b34ecc 100644 --- a/Documentation/features/debug/uprobes/arch-support.txt +++ b/Documentation/features/debug/uprobes/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/debug/user-ret-profiler/arch-support.txt b/Documentation/features/debug/user-ret-profiler/arch-support.txt index 2a3fe812a5fa..8da784e2d8d1 100644 --- a/Documentation/features/debug/user-ret-profiler/arch-support.txt +++ b/Documentation/features/debug/user-ret-profiler/arch-support.txt @@ -11,7 +11,6 @@ | arm: | TODO | | arm64: | TODO | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/io/dma-contiguous/arch-support.txt b/Documentation/features/io/dma-contiguous/arch-support.txt index bece89586efa..6bd6ff52a0bd 100644 --- a/Documentation/features/io/dma-contiguous/arch-support.txt +++ b/Documentation/features/io/dma-contiguous/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/locking/cmpxchg-local/arch-support.txt b/Documentation/features/locking/cmpxchg-local/arch-support.txt index 52bdda004f5c..307d362622c4 100644 --- a/Documentation/features/locking/cmpxchg-local/arch-support.txt +++ b/Documentation/features/locking/cmpxchg-local/arch-support.txt @@ -11,7 +11,6 @@ | arm: | TODO | | arm64: | ok | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/locking/lockdep/arch-support.txt b/Documentation/features/locking/lockdep/arch-support.txt index a8cd163c8b7e..ada677830246 100644 --- a/Documentation/features/locking/lockdep/arch-support.txt +++ b/Documentation/features/locking/lockdep/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | ok | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/locking/queued-rwlocks/arch-support.txt b/Documentation/features/locking/queued-rwlocks/arch-support.txt index 8c85949752b3..c000efd4b069 100644 --- a/Documentation/features/locking/queued-rwlocks/arch-support.txt +++ b/Documentation/features/locking/queued-rwlocks/arch-support.txt @@ -11,7 +11,6 @@ | arm: | TODO | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/locking/queued-spinlocks/arch-support.txt b/Documentation/features/locking/queued-spinlocks/arch-support.txt index 5f4e1b3841af..c4decfc115f5 100644 --- a/Documentation/features/locking/queued-spinlocks/arch-support.txt +++ b/Documentation/features/locking/queued-spinlocks/arch-support.txt @@ -11,7 +11,6 @@ | arm: | TODO | | arm64: | ok | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/perf/kprobes-event/arch-support.txt b/Documentation/features/perf/kprobes-event/arch-support.txt index 78f3fe080f0e..b2e45810af06 100644 --- a/Documentation/features/perf/kprobes-event/arch-support.txt +++ b/Documentation/features/perf/kprobes-event/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | ok | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/perf/perf-regs/arch-support.txt b/Documentation/features/perf/perf-regs/arch-support.txt index 5bf3b1854a1f..86fa79b8e719 100644 --- a/Documentation/features/perf/perf-regs/arch-support.txt +++ b/Documentation/features/perf/perf-regs/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/perf/perf-stackdump/arch-support.txt b/Documentation/features/perf/perf-stackdump/arch-support.txt index d88659bb4fc1..9b76c8206b7f 100644 --- a/Documentation/features/perf/perf-stackdump/arch-support.txt +++ b/Documentation/features/perf/perf-stackdump/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/sched/membarrier-sync-core/arch-support.txt b/Documentation/features/sched/membarrier-sync-core/arch-support.txt index 883d33b265d6..4ba3b6308aed 100644 --- a/Documentation/features/sched/membarrier-sync-core/arch-support.txt +++ b/Documentation/features/sched/membarrier-sync-core/arch-support.txt @@ -34,7 +34,6 @@ | arm: | ok | | arm64: | ok | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/sched/numa-balancing/arch-support.txt b/Documentation/features/sched/numa-balancing/arch-support.txt index 9affb7c2c500..54814bbb87b2 100644 --- a/Documentation/features/sched/numa-balancing/arch-support.txt +++ b/Documentation/features/sched/numa-balancing/arch-support.txt @@ -11,7 +11,6 @@ | arm: | .. | | arm64: | ok | | csky: | .. | - | h8300: | .. | | hexagon: | .. | | ia64: | TODO | | m68k: | .. | diff --git a/Documentation/features/seccomp/seccomp-filter/arch-support.txt b/Documentation/features/seccomp/seccomp-filter/arch-support.txt index 26eec58ab819..e243eaa7696f 100644 --- a/Documentation/features/seccomp/seccomp-filter/arch-support.txt +++ b/Documentation/features/seccomp/seccomp-filter/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/time/arch-tick-broadcast/arch-support.txt b/Documentation/features/time/arch-tick-broadcast/arch-support.txt index 8dcaab070c7b..38f06a18bac3 100644 --- a/Documentation/features/time/arch-tick-broadcast/arch-support.txt +++ b/Documentation/features/time/arch-tick-broadcast/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/time/clockevents/arch-support.txt b/Documentation/features/time/clockevents/arch-support.txt index 9a81cb03b1fd..bf640aaed17b 100644 --- a/Documentation/features/time/clockevents/arch-support.txt +++ b/Documentation/features/time/clockevents/arch-support.txt @@ -11,7 +11,6 @@ | arm: | TODO | | arm64: | ok | | csky: | ok | - | h8300: | ok | | hexagon: | ok | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/time/context-tracking/arch-support.txt b/Documentation/features/time/context-tracking/arch-support.txt index 4ed116c2ec39..45bf771065b4 100644 --- a/Documentation/features/time/context-tracking/arch-support.txt +++ b/Documentation/features/time/context-tracking/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/time/irq-time-acct/arch-support.txt b/Documentation/features/time/irq-time-acct/arch-support.txt index bc30c15557c7..25eac3f7597c 100644 --- a/Documentation/features/time/irq-time-acct/arch-support.txt +++ b/Documentation/features/time/irq-time-acct/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | .. | | m68k: | TODO | diff --git a/Documentation/features/time/virt-cpuacct/arch-support.txt b/Documentation/features/time/virt-cpuacct/arch-support.txt index 050de43bbbb9..b71a91066e35 100644 --- a/Documentation/features/time/virt-cpuacct/arch-support.txt +++ b/Documentation/features/time/virt-cpuacct/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | ok | - | h8300: | TODO | | hexagon: | TODO | | ia64: | ok | | m68k: | TODO | diff --git a/Documentation/features/vm/ELF-ASLR/arch-support.txt b/Documentation/features/vm/ELF-ASLR/arch-support.txt index 2949c99fbb2f..64f387045b38 100644 --- a/Documentation/features/vm/ELF-ASLR/arch-support.txt +++ b/Documentation/features/vm/ELF-ASLR/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/vm/PG_uncached/arch-support.txt b/Documentation/features/vm/PG_uncached/arch-support.txt index 6cde38458596..334353455540 100644 --- a/Documentation/features/vm/PG_uncached/arch-support.txt +++ b/Documentation/features/vm/PG_uncached/arch-support.txt @@ -11,7 +11,6 @@ | arm: | TODO | | arm64: | TODO | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | ok | | m68k: | TODO | diff --git a/Documentation/features/vm/THP/arch-support.txt b/Documentation/features/vm/THP/arch-support.txt index 7dbd6967b37e..36b5dfb4f8d6 100644 --- a/Documentation/features/vm/THP/arch-support.txt +++ b/Documentation/features/vm/THP/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | .. | - | h8300: | .. | | hexagon: | .. | | ia64: | TODO | | m68k: | .. | diff --git a/Documentation/features/vm/TLB/arch-support.txt b/Documentation/features/vm/TLB/arch-support.txt index e1c3a4c4d107..7d0de7f173d5 100644 --- a/Documentation/features/vm/TLB/arch-support.txt +++ b/Documentation/features/vm/TLB/arch-support.txt @@ -11,7 +11,6 @@ | arm: | TODO | | arm64: | N/A | | csky: | TODO | - | h8300: | .. | | hexagon: | TODO | | ia64: | TODO | | m68k: | .. | diff --git a/Documentation/features/vm/huge-vmap/arch-support.txt b/Documentation/features/vm/huge-vmap/arch-support.txt index bc53905a0306..64e8e14e67e0 100644 --- a/Documentation/features/vm/huge-vmap/arch-support.txt +++ b/Documentation/features/vm/huge-vmap/arch-support.txt @@ -11,7 +11,6 @@ | arm: | TODO | | arm64: | ok | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/vm/ioremap_prot/arch-support.txt b/Documentation/features/vm/ioremap_prot/arch-support.txt index 9a0c8783b84d..6bc7f77ef20d 100644 --- a/Documentation/features/vm/ioremap_prot/arch-support.txt +++ b/Documentation/features/vm/ioremap_prot/arch-support.txt @@ -11,7 +11,6 @@ | arm: | TODO | | arm64: | TODO | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | diff --git a/Documentation/features/vm/pte_special/arch-support.txt b/Documentation/features/vm/pte_special/arch-support.txt index 40b969f3a6bb..45463dac131f 100644 --- a/Documentation/features/vm/pte_special/arch-support.txt +++ b/Documentation/features/vm/pte_special/arch-support.txt @@ -11,7 +11,6 @@ | arm: | ok | | arm64: | ok | | csky: | TODO | - | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | -- cgit From 5b21b566b977155407bd0d0ea0d28018f33e6c12 Mon Sep 17 00:00:00 2001 From: Jacopo Mondi Date: Mon, 21 Feb 2022 18:47:22 +0100 Subject: media: imx: Rename imx7-mipi-csis.c to imx-mipi-csis.c Rename the imx7-mipi-csis.c driver to remove the reference to i.MX7. The driver is for an IP core found on i.MX7 and i.MX8 SoC, so do not specify a SoC version number in the driver name. Remove the references to the i.MX7 SoC in the driver symbols and expand the driver's header with more information about the IP core the driver controls. Also rename the associated bindings documentation. Signed-off-by: Jacopo Mondi Reviewed-by: Laurent Pinchart Acked-by: Rui Miguel Silva Acked-by: Sakari Ailus Signed-off-by: Hans Verkuil --- Documentation/admin-guide/media/imx7.rst | 2 +- .../bindings/media/nxp,imx-mipi-csi2.yaml | 214 +++++++++++++++++++++ .../bindings/media/nxp,imx7-mipi-csi2.yaml | 214 --------------------- 3 files changed, 215 insertions(+), 215 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml delete mode 100644 Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml (limited to 'Documentation') diff --git a/Documentation/admin-guide/media/imx7.rst b/Documentation/admin-guide/media/imx7.rst index 4785ae8ac978..2fa27718f52a 100644 --- a/Documentation/admin-guide/media/imx7.rst +++ b/Documentation/admin-guide/media/imx7.rst @@ -33,7 +33,7 @@ reference manual [#f1]_. Entities -------- -imx7-mipi-csi2 +imx-mipi-csi2 -------------- This is the MIPI CSI-2 receiver entity. It has one sink pad to receive the pixel diff --git a/Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml new file mode 100644 index 000000000000..36b135bf9f2a --- /dev/null +++ b/Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml @@ -0,0 +1,214 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/nxp,imx-mipi-csi2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX7 and i.MX8 MIPI CSI-2 receiver + +maintainers: + - Rui Miguel Silva + - Laurent Pinchart + +description: |- + The NXP i.MX7 and i.MX8 families contain SoCs that include a MIPI CSI-2 + receiver IP core named CSIS. The IP core originates from Samsung, and may be + compatible with some of the Exynos4 and S5P SoCs. i.MX7 SoCs use CSIS version + 3.3, and i.MX8 SoCs use CSIS version 3.6.3. + + While the CSI-2 receiver is separate from the MIPI D-PHY IP core, the PHY is + completely wrapped by the CSIS and doesn't expose a control interface of its + own. This binding thus covers both IP cores. + +properties: + compatible: + enum: + - fsl,imx7-mipi-csi2 + - fsl,imx8mm-mipi-csi2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 3 + items: + - description: The peripheral clock (a.k.a. APB clock) + - description: The external clock (optionally used as the pixel clock) + - description: The MIPI D-PHY clock + - description: The AXI clock + + clock-names: + minItems: 3 + items: + - const: pclk + - const: wrap + - const: phy + - const: axi + + power-domains: + maxItems: 1 + + phy-supply: + description: The MIPI D-PHY digital power supply + + resets: + items: + - description: MIPI D-PHY slave reset + + clock-frequency: + description: The desired external clock ("wrap") frequency, in Hz + default: 166000000 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port node, single endpoint describing the CSI-2 transmitter. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + description: + Note that 'fsl,imx7-mipi-csi2' only supports up to 2 data lines. + minItems: 1 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + + required: + - data-lanes + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Output port node + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + - ports + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + const: fsl,imx7-mipi-csi2 + then: + required: + - phy-supply + - resets + else: + properties: + clocks: + minItems: 4 + clock-names: + minItems: 4 + phy-supply: false + resets: false + +examples: + - | + #include + #include + #include + #include + + mipi-csi@30750000 { + compatible = "fsl,imx7-mipi-csi2"; + reg = <0x30750000 0x10000>; + interrupts = ; + + clocks = <&clks IMX7D_IPG_ROOT_CLK>, + <&clks IMX7D_MIPI_CSI_ROOT_CLK>, + <&clks IMX7D_MIPI_DPHY_ROOT_CLK>; + clock-names = "pclk", "wrap", "phy"; + clock-frequency = <166000000>; + + power-domains = <&pgc_mipi_phy>; + phy-supply = <®_1p0d>; + resets = <&src IMX7_RESET_MIPI_PHY_MRST>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + mipi_from_sensor: endpoint { + remote-endpoint = <&ov2680_to_mipi>; + data-lanes = <1>; + }; + }; + + port@1 { + reg = <1>; + + mipi_vc0_to_csi_mux: endpoint { + remote-endpoint = <&csi_mux_from_mipi_vc0>; + }; + }; + }; + }; + + - | + #include + #include + #include + + mipi-csi@32e30000 { + compatible = "fsl,imx8mm-mipi-csi2"; + reg = <0x32e30000 0x1000>; + interrupts = ; + clock-frequency = <333000000>; + clocks = <&clk IMX8MM_CLK_DISP_APB_ROOT>, + <&clk IMX8MM_CLK_CSI1_ROOT>, + <&clk IMX8MM_CLK_CSI1_PHY_REF>, + <&clk IMX8MM_CLK_DISP_AXI_ROOT>; + clock-names = "pclk", "wrap", "phy", "axi"; + power-domains = <&mipi_pd>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + imx8mm_mipi_csi_in: endpoint { + remote-endpoint = <&imx477_out>; + data-lanes = <1 2 3 4>; + }; + }; + + port@1 { + reg = <1>; + + imx8mm_mipi_csi_out: endpoint { + remote-endpoint = <&csi_in>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml deleted file mode 100644 index e2e6e9aa0fe6..000000000000 --- a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml +++ /dev/null @@ -1,214 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/media/nxp,imx7-mipi-csi2.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: NXP i.MX7 and i.MX8 MIPI CSI-2 receiver - -maintainers: - - Rui Miguel Silva - - Laurent Pinchart - -description: |- - The NXP i.MX7 and i.MX8 families contain SoCs that include a MIPI CSI-2 - receiver IP core named CSIS. The IP core originates from Samsung, and may be - compatible with some of the Exynos4 and S5P SoCs. i.MX7 SoCs use CSIS version - 3.3, and i.MX8 SoCs use CSIS version 3.6.3. - - While the CSI-2 receiver is separate from the MIPI D-PHY IP core, the PHY is - completely wrapped by the CSIS and doesn't expose a control interface of its - own. This binding thus covers both IP cores. - -properties: - compatible: - enum: - - fsl,imx7-mipi-csi2 - - fsl,imx8mm-mipi-csi2 - - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - - clocks: - minItems: 3 - items: - - description: The peripheral clock (a.k.a. APB clock) - - description: The external clock (optionally used as the pixel clock) - - description: The MIPI D-PHY clock - - description: The AXI clock - - clock-names: - minItems: 3 - items: - - const: pclk - - const: wrap - - const: phy - - const: axi - - power-domains: - maxItems: 1 - - phy-supply: - description: The MIPI D-PHY digital power supply - - resets: - items: - - description: MIPI D-PHY slave reset - - clock-frequency: - description: The desired external clock ("wrap") frequency, in Hz - default: 166000000 - - ports: - $ref: /schemas/graph.yaml#/properties/ports - - properties: - port@0: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: - Input port node, single endpoint describing the CSI-2 transmitter. - - properties: - endpoint: - $ref: video-interfaces.yaml# - unevaluatedProperties: false - - properties: - data-lanes: - description: - Note that 'fsl,imx7-mipi-csi2' only supports up to 2 data lines. - minItems: 1 - items: - - const: 1 - - const: 2 - - const: 3 - - const: 4 - - required: - - data-lanes - - port@1: - $ref: /schemas/graph.yaml#/properties/port - description: - Output port node - -required: - - compatible - - reg - - interrupts - - clocks - - clock-names - - power-domains - - ports - -additionalProperties: false - -allOf: - - if: - properties: - compatible: - contains: - const: fsl,imx7-mipi-csi2 - then: - required: - - phy-supply - - resets - else: - properties: - clocks: - minItems: 4 - clock-names: - minItems: 4 - phy-supply: false - resets: false - -examples: - - | - #include - #include - #include - #include - - mipi-csi@30750000 { - compatible = "fsl,imx7-mipi-csi2"; - reg = <0x30750000 0x10000>; - interrupts = ; - - clocks = <&clks IMX7D_IPG_ROOT_CLK>, - <&clks IMX7D_MIPI_CSI_ROOT_CLK>, - <&clks IMX7D_MIPI_DPHY_ROOT_CLK>; - clock-names = "pclk", "wrap", "phy"; - clock-frequency = <166000000>; - - power-domains = <&pgc_mipi_phy>; - phy-supply = <®_1p0d>; - resets = <&src IMX7_RESET_MIPI_PHY_MRST>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - mipi_from_sensor: endpoint { - remote-endpoint = <&ov2680_to_mipi>; - data-lanes = <1>; - }; - }; - - port@1 { - reg = <1>; - - mipi_vc0_to_csi_mux: endpoint { - remote-endpoint = <&csi_mux_from_mipi_vc0>; - }; - }; - }; - }; - - - | - #include - #include - #include - - mipi-csi@32e30000 { - compatible = "fsl,imx8mm-mipi-csi2"; - reg = <0x32e30000 0x1000>; - interrupts = ; - clock-frequency = <333000000>; - clocks = <&clk IMX8MM_CLK_DISP_APB_ROOT>, - <&clk IMX8MM_CLK_CSI1_ROOT>, - <&clk IMX8MM_CLK_CSI1_PHY_REF>, - <&clk IMX8MM_CLK_DISP_AXI_ROOT>; - clock-names = "pclk", "wrap", "phy", "axi"; - power-domains = <&mipi_pd>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - imx8mm_mipi_csi_in: endpoint { - remote-endpoint = <&imx477_out>; - data-lanes = <1 2 3 4>; - }; - }; - - port@1 { - reg = <1>; - - imx8mm_mipi_csi_out: endpoint { - remote-endpoint = <&csi_in>; - }; - }; - }; - }; - -... -- cgit From 9c634d6d137fa2024579b2c23fa3f19053e7a910 Mon Sep 17 00:00:00 2001 From: Nicolas Dufresne Date: Mon, 21 Feb 2022 14:12:01 -0500 Subject: doc: media: Document MM21 tiled format MM21 has been documented through two software implementation [0] in libyuv and [2] GStreamer. This format is similar to other tiled format, though it uses uneven tile sizes. The luma tiles are 16x32 while the chroma tile have a subsampled size of 16x16. This is the uncompressed cousin of V4L2_PIX_FMT_MT21C and shares its tiling pattern and alignment. [0] https://chromium.googlesource.com/libyuv/libyuv/+/b4ddbaf549a1bf5572bf703fd2862d1eb7380c6a [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/c9b127dae3af4b3fe78468e697cb491902425254 Signed-off-by: Nicolas Dufresne Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil --- Documentation/userspace-api/media/v4l/pixfmt-reserved.rst | 15 ++++----------- .../userspace-api/media/v4l/pixfmt-yuv-planar.rst | 6 ++++++ 2 files changed, 10 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst index 2f2133b4cd9c..cabfa34b7db5 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst @@ -233,19 +233,12 @@ please make a proposal on the linux-media mailing list. - ``V4L2_PIX_FMT_MT21C`` - 'MT21' - - Compressed two-planar YVU420 format used by Mediatek MT8173. - The compression is lossless. - It is an opaque intermediate format and the MDP hardware must be + - Compressed two-planar YVU420 format used by Mediatek MT8173, MT8192, + MT8195 and more. The compression is lossless. This format have + similitude with ``V4L2_PIX_FMT_MM21`` in term of alignment and tiling. + It remains an opaque intermediate format and the MDP hardware must be used to convert ``V4L2_PIX_FMT_MT21C`` to ``V4L2_PIX_FMT_NV12M``, ``V4L2_PIX_FMT_YUV420M`` or ``V4L2_PIX_FMT_YVU420``. - * .. _V4L2-PIX-FMT-MM21: - - - ``V4L2_PIX_FMT_MM21`` - - 'MM21' - - Non-compressed, tiled two-planar format used by Mediatek MT8183. - This is an opaque intermediate format and the MDP3 hardware can be - used to convert it to other formats. - .. raw:: latex \normalsize diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst index 3a09d93d405b..570791fbc5c8 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst @@ -296,6 +296,12 @@ tiles linearly in memory. The line stride and image height must be aligned to a multiple of 32. The layouts of the luma and chroma planes are identical. +``V4L2_PIX_FMT_MM21`` store luma pixel in 16x32 tiles, and chroma pixels +in 16x16 tiles. The line stride must be aligned to a multiple of 16 and the +image height must be aligned to a multiple of 32. The number of luma and chroma +tiles are identical, even though the tile size differ. The image is formed of +two non-contiguous planes. + .. _nv12mt: .. kernel-figure:: nv12mt.svg -- cgit From 88c63ac741266bf3fc0812578199dfb16a3c31b5 Mon Sep 17 00:00:00 2001 From: Nicolas Dufresne Date: Mon, 21 Feb 2022 14:37:27 -0500 Subject: doc: media: Document VP9 reference_mode miss-placement The reference_mode derived syntax is part of the compressed headers and should have been moved into the corresponding control structure. Document this mistake. The value can be set to 0 if the driver does not require compressed headers information. Signed-off-by: Nicolas Dufresne Reviewed-by: Andrzej Pietrasiewicz Signed-off-by: Hans Verkuil [hverkuil: fix small typo in comment] --- .../userspace-api/media/v4l/ext-ctrls-codec-stateless.rst | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst index cc080c4257d0..c6ef05e0d3a4 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst @@ -1692,7 +1692,12 @@ See section '7.3.1 Tx mode semantics' of the :ref:`vp9` specification for more d * - __u8 - ``reference_mode`` - Specifies the type of inter prediction to be used. See - :ref:`Reference Mode` for more details. + :ref:`Reference Mode` for more details. Note that + this is derived as part of the compressed header parsing process and + for this reason should have been part of + :c:type: `v4l2_ctrl_vp9_compressed_hdr` optional control. It is safe to + set this value to zero if the driver does not require compressed + headers. * - __u8 - ``reserved[7]`` - Applications and drivers must set this to zero. -- cgit From 7f1b8e0d6360178e3527d4f14e6921c254a86035 Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Mon, 20 Dec 2021 21:43:28 +0100 Subject: x86/mce: Remove the tolerance level control This is pretty much unused and not really useful. What is more, all relevant MCA hardware has recoverable machine checks support so there's no real need to tweak MCA tolerance levels in order to *maybe* extend machine lifetime. So rip it out. Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/YcDq8PxvKtTENl/e@zn.tnic --- Documentation/ABI/removed/sysfs-mce | 37 +++++++++++++++++++++++++++++++ Documentation/ABI/testing/sysfs-mce | 32 -------------------------- Documentation/vm/hwpoison.rst | 2 -- Documentation/x86/x86_64/boot-options.rst | 9 +------- 4 files changed, 38 insertions(+), 42 deletions(-) create mode 100644 Documentation/ABI/removed/sysfs-mce (limited to 'Documentation') diff --git a/Documentation/ABI/removed/sysfs-mce b/Documentation/ABI/removed/sysfs-mce new file mode 100644 index 000000000000..ef5dd2a80918 --- /dev/null +++ b/Documentation/ABI/removed/sysfs-mce @@ -0,0 +1,37 @@ +What: /sys/devices/system/machinecheck/machinecheckX/tolerant +Contact: Borislav Petkov +Date: Dec, 2021 +Description: + Unused and obsolete after the advent of recoverable machine + checks (see last sentence below) and those are present since + 2010 (Nehalem). + + Original description: + + The entries appear for each CPU, but they are truly shared + between all CPUs. + + Tolerance level. When a machine check exception occurs for a + non corrected machine check the kernel can take different + actions. + + Since machine check exceptions can happen any time it is + sometimes risky for the kernel to kill a process because it + defies normal kernel locking rules. The tolerance level + configures how hard the kernel tries to recover even at some + risk of deadlock. Higher tolerant values trade potentially + better uptime with the risk of a crash or even corruption + (for tolerant >= 3). + + == =========================================================== + 0 always panic on uncorrected errors, log corrected errors + 1 panic or SIGBUS on uncorrected errors, log corrected errors + 2 SIGBUS or log uncorrected errors, log corrected errors + 3 never panic or SIGBUS, log all errors (for testing only) + == =========================================================== + + Default: 1 + + Note this only makes a difference if the CPU allows recovery + from a machine check exception. Current x86 CPUs generally + do not. diff --git a/Documentation/ABI/testing/sysfs-mce b/Documentation/ABI/testing/sysfs-mce index c8cd989034b4..83172f50e27c 100644 --- a/Documentation/ABI/testing/sysfs-mce +++ b/Documentation/ABI/testing/sysfs-mce @@ -53,38 +53,6 @@ Description: (but some corrected errors might be still reported in other ways) -What: /sys/devices/system/machinecheck/machinecheckX/tolerant -Contact: Andi Kleen -Date: Feb, 2007 -Description: - The entries appear for each CPU, but they are truly shared - between all CPUs. - - Tolerance level. When a machine check exception occurs for a - non corrected machine check the kernel can take different - actions. - - Since machine check exceptions can happen any time it is - sometimes risky for the kernel to kill a process because it - defies normal kernel locking rules. The tolerance level - configures how hard the kernel tries to recover even at some - risk of deadlock. Higher tolerant values trade potentially - better uptime with the risk of a crash or even corruption - (for tolerant >= 3). - - == =========================================================== - 0 always panic on uncorrected errors, log corrected errors - 1 panic or SIGBUS on uncorrected errors, log corrected errors - 2 SIGBUS or log uncorrected errors, log corrected errors - 3 never panic or SIGBUS, log all errors (for testing only) - == =========================================================== - - Default: 1 - - Note this only makes a difference if the CPU allows recovery - from a machine check exception. Current x86 CPUs generally - do not. - What: /sys/devices/system/machinecheck/machinecheckX/trigger Contact: Andi Kleen Date: Feb, 2007 diff --git a/Documentation/vm/hwpoison.rst b/Documentation/vm/hwpoison.rst index 89b5f7a52077..c742de1769d1 100644 --- a/Documentation/vm/hwpoison.rst +++ b/Documentation/vm/hwpoison.rst @@ -60,8 +60,6 @@ There are two (actually three) modes memory failure recovery can be in: vm.memory_failure_recovery sysctl set to zero: All memory failures cause a panic. Do not attempt recovery. - (on x86 this can be also affected by the tolerant level of the - MCE subsystem) early kill (can be controlled globally and per process) diff --git a/Documentation/x86/x86_64/boot-options.rst b/Documentation/x86/x86_64/boot-options.rst index ccb7e86bf8d9..07aa0007f346 100644 --- a/Documentation/x86/x86_64/boot-options.rst +++ b/Documentation/x86/x86_64/boot-options.rst @@ -47,14 +47,7 @@ Please see Documentation/x86/x86_64/machinecheck.rst for sysfs runtime tunables. in a reboot. On Intel systems it is enabled by default. mce=nobootlog Disable boot machine check logging. - mce=tolerancelevel[,monarchtimeout] (number,number) - tolerance levels: - 0: always panic on uncorrected errors, log corrected errors - 1: panic or SIGBUS on uncorrected errors, log corrected errors - 2: SIGBUS or log uncorrected errors, log corrected errors - 3: never panic or SIGBUS, log all errors (for testing only) - Default is 1 - Can be also set using sysfs which is preferable. + mce=monarchtimeout (number) monarchtimeout: Sets the time in us to wait for other CPUs on machine checks. 0 to disable. -- cgit From 56bd1c86e050994ddaadf327625068de123f298d Mon Sep 17 00:00:00 2001 From: Peter Chiu Date: Wed, 9 Feb 2022 14:11:55 +0800 Subject: dt-bindings: net: wireless: mt76: document bindings for MT7986 Add an entry for MT7986 SoC. Signed-off-by: Peter Chiu Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring Signed-off-by: Felix Fietkau --- .../bindings/net/wireless/mediatek,mt76.yaml | 33 ++++++++++++++++++++-- 1 file changed, 30 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml index 025f4242f8f7..3216c999f0e1 100644 --- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml @@ -18,7 +18,7 @@ description: | wireless device. The node is expected to be specified as a child node of the PCI controller to which the wireless chip is connected. Alternatively, it can specify the wireless part of the MT7628/MT7688 - or MT7622 SoC. + or MT7622/MT7986 SoC. allOf: - $ref: ieee80211.yaml# @@ -29,9 +29,13 @@ properties: - mediatek,mt76 - mediatek,mt7628-wmac - mediatek,mt7622-wmac + - mediatek,mt7986-wmac reg: - maxItems: 1 + minItems: 1 + maxItems: 3 + description: + MT7986 should contain 3 regions consys, dcm, and sku, in this order. interrupts: maxItems: 1 @@ -39,6 +43,17 @@ properties: power-domains: maxItems: 1 + memory-region: + maxItems: 1 + + resets: + maxItems: 1 + description: + Specify the consys reset for mt7986. + + reset-name: + const: consys + mediatek,infracfg: $ref: /schemas/types.yaml#/definitions/phandle description: @@ -174,7 +189,7 @@ required: - compatible - reg -additionalProperties: false +unevaluatedProperties: false examples: - | @@ -240,3 +255,15 @@ examples: power-domains = <&scpsys 3>; }; + + - | + wifi@18000000 { + compatible = "mediatek,mt7986-wmac"; + resets = <&watchdog 23>; + reset-names = "consys"; + reg = <0x18000000 0x1000000>, + <0x10003000 0x1000>, + <0x11d10000 0x1000>; + interrupts = ; + memory-region = <&wmcpu_emi>; + }; -- cgit From 07f5ed0eee011f2b76ee01a4939f3ff1d34ac5e3 Mon Sep 17 00:00:00 2001 From: Matan Ziv-Av Date: Sat, 19 Feb 2022 15:54:46 +0200 Subject: lg-laptop: Move setting of battery charge limit to common location For now leave also the driver specific location, with deprecated warning in documentation. Signed-off-by: Matan Ziv-Av Link: https://lore.kernel.org/r/eca2fa354f60b8a6e5a5c9c8e244fea56616970a.1645278914.git.matan@svgalib.org Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede --- Documentation/ABI/testing/sysfs-platform-lg-laptop | 1 + Documentation/admin-guide/laptops/lg-laptop.rst | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-platform-lg-laptop b/Documentation/ABI/testing/sysfs-platform-lg-laptop index cf47749b19df..0570cd524d0e 100644 --- a/Documentation/ABI/testing/sysfs-platform-lg-laptop +++ b/Documentation/ABI/testing/sysfs-platform-lg-laptop @@ -17,6 +17,7 @@ Date: October 2018 KernelVersion: 4.20 Contact: "Matan Ziv-Av Description: + Deprecated use /sys/class/power_supply/CMB0/charge_control_end_threshold Maximal battery charge level. Accepted values are 80 or 100. What: /sys/devices/platform/lg-laptop/fan_mode diff --git a/Documentation/admin-guide/laptops/lg-laptop.rst b/Documentation/admin-guide/laptops/lg-laptop.rst index 6fbe165dcd27..67fd6932cef4 100644 --- a/Documentation/admin-guide/laptops/lg-laptop.rst +++ b/Documentation/admin-guide/laptops/lg-laptop.rst @@ -38,7 +38,7 @@ FN lock. Battery care limit ------------------ -Writing 80/100 to /sys/devices/platform/lg-laptop/battery_care_limit +Writing 80/100 to /sys/class/power_supply/CMB0/charge_control_end_threshold sets the maximum capacity to charge the battery. Limiting the charge reduces battery capacity loss over time. -- cgit From dddb4efa519282456a48da77f08a6414bc696c92 Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Wed, 23 Feb 2022 13:14:32 +0300 Subject: dt-bindings: pci: qcom: Document PCIe bindings for SM8450 Document the PCIe DT bindings for SM8450 SoC. The PCIe IP is similar to the one used on SM8250, however unlike SM8250, PCIe0 and PCIe1 use different set of clocks, so two compatible entries are required. Link: https://lore.kernel.org/r/20220223101435.447839-2-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Reviewed-by: Bjorn Andersson Acked-by: Stanimir Varbanov --- .../devicetree/bindings/pci/qcom,pcie.txt | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt index a0ae024c2d0c..0adb56d5645e 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt @@ -15,6 +15,8 @@ - "qcom,pcie-sc8180x" for sc8180x - "qcom,pcie-sdm845" for sdm845 - "qcom,pcie-sm8250" for sm8250 + - "qcom,pcie-sm8450-pcie0" for PCIe0 on sm8450 + - "qcom,pcie-sm8450-pcie1" for PCIe1 on sm8450 - "qcom,pcie-ipq6018" for ipq6018 - reg: @@ -169,6 +171,24 @@ - "ddrss_sf_tbu" PCIe SF TBU clock - "pipe" PIPE clock +- clock-names: + Usage: required for sm8450-pcie0 and sm8450-pcie1 + Value type: + Definition: Should contain the following entries + - "aux" Auxiliary clock + - "cfg" Configuration clock + - "bus_master" Master AXI clock + - "bus_slave" Slave AXI clock + - "slave_q2a" Slave Q2A clock + - "tbu" PCIe TBU clock + - "ddrss_sf_tbu" PCIe SF TBU clock + - "pipe" PIPE clock + - "pipe_mux" PIPE MUX + - "phy_pipe" PIPE output clock + - "ref" REFERENCE clock + - "aggre0" Aggre NoC PCIe0 AXI clock, only for sm8450-pcie0 + - "aggre1" Aggre NoC PCIe1 AXI clock + - resets: Usage: required Value type: @@ -246,7 +266,7 @@ - "ahb" AHB reset - reset-names: - Usage: required for sc8180x, sdm845 and sm8250 + Usage: required for sc8180x, sdm845, sm8250 and sm8450 Value type: Definition: Should contain the following entries - "pci" PCIe core reset -- cgit From 00d93611f00219bd142aa119c5121793cac30ff0 Mon Sep 17 00:00:00 2001 From: Corey Minyard Date: Sun, 20 Feb 2022 14:38:39 -0600 Subject: ipmi:ipmb: Add the ability to have a separate slave and master device A situation has come up where there is a slave-only device for the slave and a separate master device on the same bug. Allow a separate slave device to be registered. Signed-off-by: Corey Minyard --- Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml b/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml index 93d8f8e88cf5..71bc031c4fde 100644 --- a/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml +++ b/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml @@ -36,6 +36,14 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 description: Number of retries before a failure is declared. Defaults to 1. + slave-dev: + $ref: /schemas/types.yaml#/definitions/phandle + description: | + The slave i2c device. If not present, the main device is used. This + lets you use two devices on the IPMB, one for master and one for slave, + in case you have a slave device that can only be a slave. The slave + will receive messages and the master will transmit. + required: - compatible - reg -- cgit From a0d61d02c102d93e8c8f653cbfdc3bf485d45aaf Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Tue, 15 Feb 2022 23:15:35 +0300 Subject: dt-bindings: clocks: convert SDM845 Camera CC bindings to YAML Convert clock/qcom,camcc.txt to clock/qcom,sdm845-camcc.yaml. Signed-off-by: Dmitry Baryshkov Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220215201539.3970459-2-dmitry.baryshkov@linaro.org --- .../devicetree/bindings/clock/qcom,camcc.txt | 18 ------- .../bindings/clock/qcom,sdm845-camcc.yaml | 63 ++++++++++++++++++++++ 2 files changed, 63 insertions(+), 18 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/qcom,camcc.txt create mode 100644 Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,camcc.txt b/Documentation/devicetree/bindings/clock/qcom,camcc.txt deleted file mode 100644 index c5eb6694fda9..000000000000 --- a/Documentation/devicetree/bindings/clock/qcom,camcc.txt +++ /dev/null @@ -1,18 +0,0 @@ -Qualcomm Camera Clock & Reset Controller Binding ------------------------------------------------- - -Required properties : -- compatible : shall contain "qcom,sdm845-camcc". -- reg : shall contain base register location and length. -- #clock-cells : from common clock binding, shall contain 1. -- #reset-cells : from common reset binding, shall contain 1. -- #power-domain-cells : from generic power domain binding, shall contain 1. - -Example: - camcc: clock-controller@ad00000 { - compatible = "qcom,sdm845-camcc"; - reg = <0xad00000 0x10000>; - #clock-cells = <1>; - #reset-cells = <1>; - #power-domain-cells = <1>; - }; diff --git a/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml new file mode 100644 index 000000000000..c61314caf692 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sdm845-camcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Camera Clock & Reset Controller Binding for SDM845 + +maintainers: + - Bjorn Andersson + +description: | + Qualcomm camera clock control module which supports the clocks, resets and + power domains on SDM845. + + See also dt-bindings/clock/qcom,camcc-sm845.h + +properties: + compatible: + const: qcom,sdm845-camcc + + clocks: + items: + - description: Board XO source + + clock-names: + items: + - const: bi_tcxo + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include + clock-controller@ad00000 { + compatible = "qcom,sdm845-camcc"; + reg = <0x0ad00000 0x10000>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... -- cgit From 2564aa7544f493c64b397e02a2b477591016aa24 Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Tue, 15 Feb 2022 23:15:36 +0300 Subject: dt-bindings: clocks: qcom,sdm845-camcc: add clocks/clock-names The driver can parse bi-tcxo clock from the clocks passed in the device tree. Specify it in schema. Signed-off-by: Dmitry Baryshkov Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220215201539.3970459-3-dmitry.baryshkov@linaro.org --- Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml index c61314caf692..d4239ccae917 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml @@ -56,6 +56,8 @@ examples: clock-controller@ad00000 { compatible = "qcom,sdm845-camcc"; reg = <0x0ad00000 0x10000>; + clocks = <&rpmhcc RPMH_CXO_CLK>; + clock-names = "bi_tcxo"; #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; -- cgit From 1241e329ce2e1f5b1039fd356b75867b29721ad2 Mon Sep 17 00:00:00 2001 From: Subbaraya Sundeep Date: Wed, 23 Feb 2022 00:09:12 +0530 Subject: ethtool: add support to set/get completion queue event size Add support to set completion queue event size via ethtool -G parameter and get it via ethtool -g parameter. ~ # ./ethtool -G eth0 cqe-size 512 ~ # ./ethtool -g eth0 Ring parameters for eth0: Pre-set maximums: RX: 1048576 RX Mini: n/a RX Jumbo: n/a TX: 1048576 Current hardware settings: RX: 256 RX Mini: n/a RX Jumbo: n/a TX: 4096 RX Buf Len: 2048 CQE Size: 128 Signed-off-by: Subbaraya Sundeep Signed-off-by: Sunil Goutham Signed-off-by: Jakub Kicinski --- Documentation/networking/ethtool-netlink.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index cae28af7a476..24d9be69065d 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -861,6 +861,7 @@ Kernel response contents: ``ETHTOOL_A_RINGS_TX`` u32 size of TX ring ``ETHTOOL_A_RINGS_RX_BUF_LEN`` u32 size of buffers on the ring ``ETHTOOL_A_RINGS_TCP_DATA_SPLIT`` u8 TCP header / data split + ``ETHTOOL_A_RINGS_CQE_SIZE`` u32 Size of TX/RX CQE ==================================== ====== =========================== ``ETHTOOL_A_RINGS_TCP_DATA_SPLIT`` indicates whether the device is usable with @@ -885,6 +886,7 @@ Request contents: ``ETHTOOL_A_RINGS_RX_JUMBO`` u32 size of RX jumbo ring ``ETHTOOL_A_RINGS_TX`` u32 size of TX ring ``ETHTOOL_A_RINGS_RX_BUF_LEN`` u32 size of buffers on the ring + ``ETHTOOL_A_RINGS_CQE_SIZE`` u32 Size of TX/RX CQE ==================================== ====== =========================== Kernel checks that requested ring sizes do not exceed limits reported by @@ -892,6 +894,15 @@ driver. Driver may impose additional constraints and may not suspport all attributes. +``ETHTOOL_A_RINGS_CQE_SIZE`` specifies the completion queue event size. +Completion queue events(CQE) are the events posted by NIC to indicate the +completion status of a packet when the packet is sent(like send success or +error) or received(like pointers to packet fragments). The CQE size parameter +enables to modify the CQE size other than default size if NIC supports it. +A bigger CQE can have more receive buffer pointers inturn NIC can transfer +a bigger frame from wire. Based on the NIC hardware, the overall completion +queue size can be adjusted in the driver if CQE size is modified. + CHANNELS_GET ============ -- cgit From 66224f6656d10c379da10db2208ebfae02854a08 Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde Date: Wed, 11 Nov 2020 09:08:47 +0100 Subject: dt-binding: can: mcp251xfd: include common CAN controller bindings Since commit | 1f9234401ce0 ("dt-bindings: can: add can-controller.yaml") there is a common CAN controller binding. Add this to the mcp251xfd binding. Link: https://lore.kernel.org/all/20220124220653.3477172-2-mkl@pengutronix.de Cc: Manivannan Sadhasivam Cc: Thomas Kopp Acked-by: Rob Herring Signed-off-by: Marc Kleine-Budde --- Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml index 2a884c1fe0e0..b3826af6bd6e 100644 --- a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml +++ b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml @@ -11,6 +11,9 @@ title: maintainers: - Marc Kleine-Budde +allOf: + - $ref: can-controller.yaml# + properties: compatible: oneOf: -- cgit From d931686dc21f9092c5367ba6b51d4b12772d4685 Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde Date: Wed, 11 Nov 2020 09:08:47 +0100 Subject: dt-binding: can: sun4i_can: include common CAN controller bindings Since commit | 1f9234401ce0 ("dt-bindings: can: add can-controller.yaml") there is a common CAN controller binding. Add this to the sun4i_can binding. Link: https://lore.kernel.org/all/20220124220653.3477172-3-mkl@pengutronix.de Cc: Evgeny Boger Cc: Gerhard Bertelsmann Acked-by: Rob Herring Signed-off-by: Marc Kleine-Budde --- Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml b/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml index c93fe9d3ea82..3c51b2d02957 100644 --- a/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml +++ b/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml @@ -10,6 +10,9 @@ maintainers: - Chen-Yu Tsai - Maxime Ripard +allOf: + - $ref: can-controller.yaml# + properties: compatible: oneOf: -- cgit From edd056a109eedaa8445991089cd6c0f57a871061 Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde Date: Thu, 17 Feb 2022 12:36:09 +0100 Subject: dt-binding: can: m_can: list Chandrasekar Ramakrishnan as maintainer Since Sriram Dash's email bounces, change the maintainer entry to Chandrasekar Ramakrishnan. Chandrasekar Ramakrishnan is already listed as a maintainer in the MAINTAINERS file. Link: https://lore.kernel.org/all/20220217113839.2311417-1-mkl@pengutronix.de Cc: Chandrasekar Ramakrishnan Acked-by: Krzysztof Kozlowski Signed-off-by: Marc Kleine-Budde --- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 401ab7cdb379..f8f504953e78 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -9,7 +9,7 @@ title: Bosch MCAN controller Bindings description: Bosch MCAN controller for CAN bus maintainers: - - Sriram Dash + - Chandrasekar Ramakrishnan properties: compatible: -- cgit From bffd5217ca2e17b069604a2de3bc00296b951c6f Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde Date: Tue, 18 Jan 2022 15:18:50 +0100 Subject: dt-binding: can: m_can: fix indention of table in bosch,mram-cfg description This patch fixes the indention of the table in the description of the bosch,mram-cfg property. Link: https://lore.kernel.org/all/20220217101111.2291151-1-mkl@pengutronix.de Reviewed-by: Chandrasekar Ramakrishnan Signed-off-by: Marc Kleine-Budde --- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index f8f504953e78..fd4d291fe4c1 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -66,8 +66,8 @@ properties: M_CAN includes the following elements according to user manual: 11-bit Filter 0-128 elements / 0-128 words 29-bit Filter 0-64 elements / 0-128 words - Rx FIFO 0 0-64 elements / 0-1152 words - Rx FIFO 1 0-64 elements / 0-1152 words + Rx FIFO 0 0-64 elements / 0-1152 words + Rx FIFO 1 0-64 elements / 0-1152 words Rx Buffers 0-64 elements / 0-1152 words Tx Event FIFO 0-32 elements / 0-64 words Tx Buffers 0-32 elements / 0-576 words -- cgit From 58212e03e5ec315b368afea5a32a87866feb59b0 Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde Date: Wed, 11 Nov 2020 09:08:47 +0100 Subject: dt-binding: can: m_can: include common CAN controller bindings Since commit | 1f9234401ce0 ("dt-bindings: can: add can-controller.yaml") there is a common CAN controller binding. Add this to the m_can binding. Link: https://lore.kernel.org/all/20220124220653.3477172-4-mkl@pengutronix.de Reviewed-by: Chandrasekar Ramakrishnan Acked-by: Rob Herring Signed-off-by: Marc Kleine-Budde --- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index fd4d291fe4c1..b7f9803c1c6d 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -11,6 +11,9 @@ description: Bosch MCAN controller for CAN bus maintainers: - Chandrasekar Ramakrishnan +allOf: + - $ref: can-controller.yaml# + properties: compatible: const: bosch,m_can -- cgit From 84842911322fc6a02a03ab9e728a48c691fe3efd Mon Sep 17 00:00:00 2001 From: Christophe Leroy Date: Thu, 17 Feb 2022 09:49:59 +0100 Subject: vsprintf: Fix %pK with kptr_restrict == 0 Although kptr_restrict is set to 0 and the kernel is booted with no_hash_pointers parameter, the content of /proc/vmallocinfo is lacking the real addresses. / # cat /proc/vmallocinfo 0x(ptrval)-0x(ptrval) 8192 load_module+0xc0c/0x2c0c pages=1 vmalloc 0x(ptrval)-0x(ptrval) 12288 start_kernel+0x4e0/0x690 pages=2 vmalloc 0x(ptrval)-0x(ptrval) 12288 start_kernel+0x4e0/0x690 pages=2 vmalloc 0x(ptrval)-0x(ptrval) 8192 _mpic_map_mmio.constprop.0+0x20/0x44 phys=0x80041000 ioremap 0x(ptrval)-0x(ptrval) 12288 _mpic_map_mmio.constprop.0+0x20/0x44 phys=0x80041000 ioremap ... According to the documentation for /proc/sys/kernel/, %pK is equivalent to %p when kptr_restrict is set to 0. Fixes: 5ead723a20e0 ("lib/vsprintf: no_hash_pointers prints all addresses as unhashed") Signed-off-by: Christophe Leroy Reviewed-by: Petr Mladek Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/107476128e59bff11a309b5bf7579a1753a41aca.1645087605.git.christophe.leroy@csgroup.eu --- Documentation/admin-guide/kernel-parameters.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 46bfadf02bc7..86e2b586c171 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3491,8 +3491,7 @@ difficult since unequal pointers can no longer be compared. However, if this command-line option is specified, then all normal pointers will have their true - value printed. Pointers printed via %pK may still be - hashed. This option should only be specified when + value printed. This option should only be specified when debugging the kernel. Please do not use on production kernels. -- cgit From 05f2281b4192320a20d746df6146b3dd82f96e39 Mon Sep 17 00:00:00 2001 From: Ricardo Rivera-Matos Date: Mon, 14 Feb 2022 18:07:56 -0600 Subject: power: supply: Introduces bypass charging property Adds a POWER_SUPPLY_CHARGE_TYPE_BYPASS option to the POWER_SUPPLY_PROP_CHARGE_TYPE property to facilitate bypass charging operation. In bypass charging operation, the charger bypasses the charging path around the integrated converter allowing for a "smart" wall adaptor to perform the power conversion externally. This operational mode is critical for the USB PPS standard of power adaptors and is becoming a common feature in modern charging ICs such as: - BQ25980 - BQ25975 - BQ25960 - LN8000 - LN8410 Signed-off-by: Ricardo Rivera-Matos Signed-off-by: Sebastian Reichel --- Documentation/ABI/testing/sysfs-class-power | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power index fde21d900420..738dcb0cf180 100644 --- a/Documentation/ABI/testing/sysfs-class-power +++ b/Documentation/ABI/testing/sysfs-class-power @@ -380,13 +380,16 @@ Description: algorithm to adjust the charge rate dynamically, without any user configuration required. "Custom" means that the charger uses the charge_control_* properties as configuration for some - different algorithm. + different algorithm. "Bypass" means the charger bypasses the + charging path around the integrated converter allowing for a + "smart" wall adaptor to perform the power conversion + externally. Access: Read, Write Valid values: "Unknown", "N/A", "Trickle", "Fast", "Standard", - "Adaptive", "Custom" + "Adaptive", "Custom", "Bypass" What: /sys/class/power_supply//charge_term_current Date: July 2014 -- cgit From 1ff8cc2ca84d695da3fc30a2ead1054e4c99e2fa Mon Sep 17 00:00:00 2001 From: Ricardo Rivera-Matos Date: Mon, 14 Feb 2022 18:07:58 -0600 Subject: ABI: testing: sysfs-class-power: Adds "Long Life" entry Adds a brief desciption of the "Long Life" charge type and adds "Long Life" to the list of valid values. Signed-off-by: Ricardo Rivera-Matos Signed-off-by: Sebastian Reichel --- Documentation/ABI/testing/sysfs-class-power | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power index 738dcb0cf180..1a04e729cc77 100644 --- a/Documentation/ABI/testing/sysfs-class-power +++ b/Documentation/ABI/testing/sysfs-class-power @@ -380,16 +380,17 @@ Description: algorithm to adjust the charge rate dynamically, without any user configuration required. "Custom" means that the charger uses the charge_control_* properties as configuration for some - different algorithm. "Bypass" means the charger bypasses the - charging path around the integrated converter allowing for a - "smart" wall adaptor to perform the power conversion - externally. + different algorithm. "Long Life" means the charger reduces its + charging rate in order to prolong the battery health. "Bypass" + means the charger bypasses the charging path around the + integrated converter allowing for a "smart" wall adaptor to + perform the power conversion externally. Access: Read, Write Valid values: "Unknown", "N/A", "Trickle", "Fast", "Standard", - "Adaptive", "Custom", "Bypass" + "Adaptive", "Custom", "Long Life", "Bypass" What: /sys/class/power_supply//charge_term_current Date: July 2014 -- cgit From 6b94ee669e8a3c2276cfb92103328d0713d74c3c Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 09:19:13 +0100 Subject: dt-bindings: pwm: google,cros-ec: include generic pwm schema Include generic pwm.yaml schema, which enforces PWM node naming. Keep the old name in bindings as deprecated. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Acked-by: Lee Jones Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/mfd/google,cros-ec.yaml | 4 ++++ Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml | 5 ++++- 2 files changed, 8 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml index d1f53bd449f7..0255b7028496 100644 --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml @@ -89,6 +89,10 @@ properties: ec-pwm: $ref: "/schemas/pwm/google,cros-ec-pwm.yaml#" + deprecated: true + + pwm: + $ref: "/schemas/pwm/google,cros-ec-pwm.yaml#" keyboard-controller: $ref: "/schemas/input/google,cros-ec-keyb.yaml#" diff --git a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml index 4cfbffd8414a..7ab6912a845f 100644 --- a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml @@ -16,6 +16,9 @@ description: | An EC PWM node should be only found as a sub-node of the EC node (see Documentation/devicetree/bindings/mfd/google,cros-ec.yaml). +allOf: + - $ref: pwm.yaml# + properties: compatible: const: google,cros-ec-pwm @@ -39,7 +42,7 @@ examples: compatible = "google,cros-ec-spi"; reg = <0>; - cros_ec_pwm: ec-pwm { + cros_ec_pwm: pwm { compatible = "google,cros-ec-pwm"; #pwm-cells = <1>; }; -- cgit From 113cc0b06570ea87568343f92839c092f21f7484 Mon Sep 17 00:00:00 2001 From: Allen-KH Cheng Date: Mon, 7 Feb 2022 19:26:57 +0800 Subject: dt-bindings: pwm: mtk-disp: Add compatible string for MT8183 SoC Add compatible string for MT8183 SoC in device tree binding. Signed-off-by: Allen-KH Cheng Acked-by: Rob Herring Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt index 902b271891ae..691e58b6c223 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt @@ -6,6 +6,7 @@ Required properties: - "mediatek,mt6595-disp-pwm": found on mt6595 SoC. - "mediatek,mt8167-disp-pwm", "mediatek,mt8173-disp-pwm": found on mt8167 SoC. - "mediatek,mt8173-disp-pwm": found on mt8173 SoC. + - "mediatek,mt8183-disp-pwm": found on mt8183 SoC.$ - reg: physical base address and length of the controller's registers. - #pwm-cells: must be 2. See pwm.yaml in this directory for a description of the cell format. -- cgit From 4f34ebbe43f67f112169f61a2f35f6c3dbc8bc52 Mon Sep 17 00:00:00 2001 From: Aidan MacDonald Date: Wed, 9 Feb 2022 23:11:41 +0000 Subject: dt-bindings: timer: Add PWM compatible for X1000 SoC The PWM hardware on the X1000 SoC is almost identical to other Ingenic SoCs, so it can be used with only minor driver changes. Signed-off-by: Aidan MacDonald Acked-by: Rob Herring Acked-by: Paul Cercueil Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/timer/ingenic,tcu.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml index 7fb37eae9da7..d541cf2067bc 100644 --- a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml +++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml @@ -152,6 +152,7 @@ patternProperties: - enum: - ingenic,jz4740-pwm - ingenic,jz4725b-pwm + - ingenic,x1000-pwm - items: - enum: - ingenic,jz4760-pwm -- cgit From 360e770c9c4d27cca50d17e34cf50d93a34eb457 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:40 +0100 Subject: dt-bindings: pwm: allwinner,sun4i-a10: Include generic PWM schema Include generic pwm.yaml schema, which enforces PWM node naming and brings pwm-cells requirement. Signed-off-by: Krzysztof Kozlowski Acked-by: Jernej Skrabec Signed-off-by: Thierry Reding --- .../bindings/pwm/allwinner,sun4i-a10-pwm.yaml | 53 ++++++++++++---------- 1 file changed, 28 insertions(+), 25 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml index 800d511502c4..e93e935564fb 100644 --- a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml @@ -52,33 +52,36 @@ properties: resets: maxItems: 1 -if: - properties: - compatible: - contains: - const: allwinner,sun50i-h6-pwm - -then: - properties: - clocks: - maxItems: 2 - - clock-names: - items: - - const: mod - - const: bus - - required: - - clock-names - - resets - -else: - properties: - clocks: - maxItems: 1 + +allOf: + - $ref: pwm.yaml# + + - if: + properties: + compatible: + contains: + const: allwinner,sun50i-h6-pwm + + then: + properties: + clocks: + maxItems: 2 + + clock-names: + items: + - const: mod + - const: bus + + required: + - clock-names + - resets + + else: + properties: + clocks: + maxItems: 1 required: - - "#pwm-cells" - compatible - reg - clocks -- cgit From e766d5b80ad47d1733636c2055e1351965e0721b Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:41 +0100 Subject: dt-bindings: pwm: imx: Include generic PWM schema Include generic pwm.yaml schema, which enforces PWM node naming and brings pwm-cells requirement. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/imx-pwm.yaml | 4 +++- Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml index 379d693889f6..b3da4e629341 100644 --- a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml @@ -9,6 +9,9 @@ title: Freescale i.MX PWM controller maintainers: - Philipp Zabel +allOf: + - $ref: pwm.yaml# + properties: "#pwm-cells": description: | @@ -59,7 +62,6 @@ properties: maxItems: 1 required: - - "#pwm-cells" - compatible - reg - clocks diff --git a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml index fe9ef42544f1..8bef9dfeba9a 100644 --- a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml @@ -13,6 +13,9 @@ description: | The TPM counter and period counter are shared between multiple channels, so all channels should use same period setting. +allOf: + - $ref: pwm.yaml# + properties: "#pwm-cells": const: 3 @@ -34,7 +37,6 @@ properties: maxItems: 1 required: - - "#pwm-cells" - compatible - reg - clocks -- cgit From 1bdb7a0b4244e38665fda93ac0d8bce66f434040 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:42 +0100 Subject: dt-bindings: pwm: intel,lgm: Include generic PWM schema Include generic pwm.yaml schema, which enforces PWM node naming and brings pwm-cells requirement. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml index 11a606536169..59d7c4d864c1 100644 --- a/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml @@ -9,6 +9,9 @@ title: LGM SoC PWM fan controller maintainers: - Rahul Tanwar +allOf: + - $ref: pwm.yaml# + properties: compatible: const: intel,lgm-pwm -- cgit From 0c11ff8775ee85fb0615e75caf3fbba27f62c34c Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:43 +0100 Subject: dt-bindings: pwm: iqs620a: Include generic PWM schema Include generic pwm.yaml schema, which enforces PWM node naming and brings pwm-cells requirement. Signed-off-by: Krzysztof Kozlowski Acked-by: Jeff LaBundy Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml b/Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml index 1d7c27be50da..0a46af240d83 100644 --- a/Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml @@ -15,6 +15,9 @@ description: | Documentation/devicetree/bindings/mfd/iqs62x.yaml for further details as well as an example. +allOf: + - $ref: pwm.yaml# + properties: compatible: enum: @@ -25,7 +28,6 @@ properties: required: - compatible - - "#pwm-cells" additionalProperties: false -- cgit From a63cb1a9f9e9d556769e0e146a9c9f442570635d Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:44 +0100 Subject: dt-bindings: pwm: mxs: Include generic PWM schema Include generic pwm.yaml schema, which enforces PWM node naming and brings pwm-cells requirement. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/mxs-pwm.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml b/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml index 8740e076061e..a34cbc13f691 100644 --- a/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml @@ -10,6 +10,9 @@ maintainers: - Shawn Guo - Anson Huang +allOf: + - $ref: pwm.yaml# + properties: compatible: enum: @@ -28,7 +31,6 @@ properties: required: - compatible - reg - - "#pwm-cells" - fsl,pwm-number additionalProperties: false -- cgit From ef75324d91eb7b03bda0304b8c1ec26049e054ad Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:45 +0100 Subject: dt-bindings: pwm: rockchip: Include generic PWM schema Include generic pwm.yaml schema, which enforces PWM node naming and brings pwm-cells requirement. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Heiko Stuebner Signed-off-by: Thierry Reding --- .../devicetree/bindings/pwm/pwm-rockchip.yaml | 74 +++++++++++----------- 1 file changed, 38 insertions(+), 36 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml index 81a54a4e8e3e..a336ff9364a9 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml @@ -51,42 +51,44 @@ properties: required: - compatible - reg - - "#pwm-cells" - -if: - properties: - compatible: - contains: - enum: - - rockchip,rk3328-pwm - - rockchip,rv1108-pwm - -then: - properties: - clocks: - items: - - description: Used to derive the functional clock for the device. - - description: Used as the APB bus clock. - - clock-names: - items: - - const: pwm - - const: pclk - - required: - - clocks - - clock-names - -else: - properties: - clocks: - maxItems: 1 - description: - Used both to derive the functional clock - for the device and as the bus clock. - - required: - - clocks + +allOf: + - $ref: pwm.yaml# + + - if: + properties: + compatible: + contains: + enum: + - rockchip,rk3328-pwm + - rockchip,rv1108-pwm + + then: + properties: + clocks: + items: + - description: Used to derive the functional clock for the device. + - description: Used as the APB bus clock. + + clock-names: + items: + - const: pwm + - const: pclk + + required: + - clocks + - clock-names + + else: + properties: + clocks: + maxItems: 1 + description: + Used both to derive the functional clock + for the device and as the bus clock. + + required: + - clocks additionalProperties: false -- cgit From e040921c9ba4b05aabff9be1e40b657628874fb5 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:46 +0100 Subject: dt-bindings: pwm: sifive: Include generic PWM schema Include generic pwm.yaml schema, which enforces PWM node naming and brings pwm-cells requirement. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/pwm-sifive.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml b/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml index 84e66913d042..676b2160bada 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml @@ -22,6 +22,9 @@ description: https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/pwm +allOf: + - $ref: pwm.yaml# + properties: compatible: items: @@ -55,7 +58,6 @@ required: - compatible - reg - clocks - - "#pwm-cells" - interrupts additionalProperties: false -- cgit From 84b3b8df51e26b8bc2c7178b068ef447473d4609 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:47 +0100 Subject: dt-bindings: pwm: renesas,pwm: Include generic PWM schema Include generic pwm.yaml schema, which enforces PWM node naming and brings pwm-cells requirement. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Yoshihiro Shimoda Signed-off-by: Thierry Reding --- .../devicetree/bindings/pwm/renesas,pwm-rcar.yaml | 26 ++++++++++++---------- 1 file changed, 14 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml index 7ea1070b4b3a..1c94acbc2b4a 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml @@ -59,21 +59,23 @@ properties: required: - compatible - reg - - '#pwm-cells' - clocks - power-domains -if: - not: - properties: - compatible: - contains: - enum: - - renesas,pwm-r8a7778 - - renesas,pwm-r8a7779 -then: - required: - - resets +allOf: + - $ref: pwm.yaml# + + - if: + not: + properties: + compatible: + contains: + enum: + - renesas,pwm-r8a7778 + - renesas,pwm-r8a7779 + then: + required: + - resets additionalProperties: false -- cgit From 43ded59106468aaa17fbe194b5f44ef5154295d6 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:48 +0100 Subject: dt-bindings: pwm: toshiba,visconti: Include generic PWM schema Include generic pwm.yaml schema, which enforces PWM node naming and brings pwm-cells requirement. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Nobuhiro Iwamatsu Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml b/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml index d350f5edfb67..46622661e5fb 100644 --- a/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml +++ b/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml @@ -9,6 +9,9 @@ title: Toshiba Visconti PWM Controller maintainers: - Nobuhiro Iwamatsu +allOf: + - $ref: pwm.yaml# + properties: compatible: items: @@ -23,7 +26,6 @@ properties: required: - compatible - reg - - '#pwm-cells' additionalProperties: false -- cgit From d41188a7960120734d94dd941e4069d47ecf032f Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:49 +0100 Subject: dt-bindings: pwm: brcm,bcm7038: Do not require pwm-cells twice pwm-cells property is already required by pwm.yaml schema. Signed-off-by: Krzysztof Kozlowski Acked-by: Florian Fainelli Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml index 4080e098f746..119de3d7f9dd 100644 --- a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml @@ -28,7 +28,6 @@ properties: required: - compatible - reg - - "#pwm-cells" - clocks additionalProperties: false -- cgit From e0f2c7dfe8b4daefacb9cf1bef66147cc8ccec4c Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:50 +0100 Subject: dt-bindings: pwm: intel,keembay: Do not require pwm-cells twice pwm-cells property is already required by pwm.yaml schema. Signed-off-by: Krzysztof Kozlowski Acked-by: Vijayakannan Ayyathurai Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml b/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml index ff6880a02ce6..ec9f6bab798c 100644 --- a/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml @@ -31,7 +31,6 @@ required: - compatible - reg - clocks - - '#pwm-cells' additionalProperties: false -- cgit From 46ac2474ea2a8c0c99adda30194705b70f7590d8 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:51 +0100 Subject: dt-bindings: pwm: samsung: Do not require pwm-cells twice pwm-cells property is already required by pwm.yaml schema. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/pwm-samsung.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml index 188679cb8b8c..fe603fb1b2cc 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml @@ -86,7 +86,6 @@ required: - clocks - clock-names - compatible - - "#pwm-cells" - reg additionalProperties: false -- cgit From 400002e05664a341ca324d56abeff6d4b8536dca Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:52 +0100 Subject: dt-bindings: pwm: tiecap: Do not require pwm-cells twice pwm-cells property is already required by pwm.yaml schema. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml b/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml index ed35b6cc48d5..3840ae709bc6 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml @@ -47,7 +47,6 @@ properties: required: - compatible - reg - - "#pwm-cells" - clocks - clock-names -- cgit From 83d41a76d9c5c4da076f99b507a086f4a73636f0 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:53 +0100 Subject: dt-bindings: pwm: tiehrpwm: Do not require pwm-cells twice pwm-cells property is already required by pwm.yaml schema. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml index ee312cb210e6..70a8f766212e 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml @@ -48,7 +48,6 @@ properties: required: - compatible - reg - - "#pwm-cells" - clocks - clock-names -- cgit From f4866732a7b55b8ce65e8ef259e8782cac910653 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Feb 2022 22:21:54 +0100 Subject: dt-bindings: pwm: renesas,tpu: Do not require pwm-cells twice pwm-cells property is already required by pwm.yaml schema. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Yoshihiro Shimoda Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml index 1f5c6384182e..c6b2ab56b7fe 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml @@ -68,7 +68,6 @@ properties: required: - compatible - reg - - '#pwm-cells' - clocks - power-domains -- cgit From b3df807e1fb00fa9b466b51d8ce1a1e8704928c8 Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Tue, 8 Feb 2022 17:13:23 +0800 Subject: dt-bindings: soc: grf: add naneng combo phy register compatible Add Naneng combo phy register compatible. Acked-by: Rob Herring Signed-off-by: Johan Jonker Signed-off-by: Yifeng Zhao Tested-by: Frank Wunderlich Link: https://lore.kernel.org/r/20220208091326.12495-2-yifeng.zhao@rock-chips.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index dfebf425ca49..fe68e22efce0 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -38,6 +38,8 @@ properties: - rockchip,rk3399-grf - rockchip,rk3399-pmugrf - rockchip,rk3568-grf + - rockchip,rk3568-pipe-grf + - rockchip,rk3568-pipe-phy-grf - rockchip,rk3568-pmugrf - rockchip,rv1108-grf - rockchip,rv1108-pmugrf -- cgit From dedc3acedcd30a9cb6ea811e8260ef34131e968c Mon Sep 17 00:00:00 2001 From: Yifeng Zhao Date: Tue, 8 Feb 2022 17:13:24 +0800 Subject: dt-bindings: phy: rockchip: Add Naneng combo PHY bindings Add the compatible strings for the Naneng combo PHY found on rockchip SoC. Reviewed-by: Rob Herring Signed-off-by: Yifeng Zhao Signed-off-by: Johan Jonker Tested-by: Frank Wunderlich Link: https://lore.kernel.org/r/20220208091326.12495-3-yifeng.zhao@rock-chips.com Signed-off-by: Vinod Koul --- .../bindings/phy/phy-rockchip-naneng-combphy.yaml | 109 +++++++++++++++++++++ 1 file changed, 109 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml new file mode 100644 index 000000000000..f14454401419 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml @@ -0,0 +1,109 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/phy-rockchip-naneng-combphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip SoC Naneng Combo Phy Device Tree Bindings + +maintainers: + - Heiko Stuebner + +properties: + compatible: + enum: + - rockchip,rk3568-naneng-combphy + + reg: + maxItems: 1 + + clocks: + items: + - description: reference clock + - description: apb clock + - description: pipe clock + + clock-names: + items: + - const: ref + - const: apb + - const: pipe + + resets: + items: + - description: exclusive PHY reset line + + rockchip,enable-ssc: + type: boolean + description: + The option SSC can be enabled for U3, SATA and PCIE. + Most commercially available platforms use SSC to reduce EMI. + + rockchip,ext-refclk: + type: boolean + description: + Many PCIe connections, especially backplane connections, + require a synchronous reference clock between the two link partners. + To achieve this a common clock source, referred to as REFCLK in + the PCI Express Card Electromechanical Specification, + should be used by both ends of the PCIe link. + In PCIe mode one can choose to use an internal or an external reference + clock. + By default the internal clock is selected. The PCIe PHY provides a 100MHz + differential clock output(optional with SSC) for system applications. + When selecting this option an externally 100MHz differential + reference clock needs to be provided to the PCIe PHY. + + rockchip,pipe-grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Some additional phy settings are accessed through GRF regs. + + rockchip,pipe-phy-grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Some additional pipe settings are accessed through GRF regs. + + "#phy-cells": + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - rockchip,pipe-grf + - rockchip,pipe-phy-grf + - "#phy-cells" + +additionalProperties: false + +examples: + - | + #include + + pipegrf: syscon@fdc50000 { + compatible = "rockchip,rk3568-pipe-grf", "syscon"; + reg = <0xfdc50000 0x1000>; + }; + + pipe_phy_grf0: syscon@fdc70000 { + compatible = "rockchip,rk3568-pipe-phy-grf", "syscon"; + reg = <0xfdc70000 0x1000>; + }; + + combphy0: phy@fe820000 { + compatible = "rockchip,rk3568-naneng-combphy"; + reg = <0xfe820000 0x100>; + clocks = <&pmucru CLK_PCIEPHY0_REF>, + <&cru PCLK_PIPEPHY0>, + <&cru PCLK_PIPE>; + clock-names = "ref", "apb", "pipe"; + assigned-clocks = <&pmucru CLK_PCIEPHY0_REF>; + assigned-clock-rates = <100000000>; + resets = <&cru SRST_PIPEPHY0>; + rockchip,pipe-grf = <&pipegrf>; + rockchip,pipe-phy-grf = <&pipe_phy_grf0>; + #phy-cells = <1>; + }; -- cgit From 2b709a7209ef43f02607815a2ab8027e5593ed1a Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 23 Feb 2022 08:35:46 +0100 Subject: dt-bindings: writing-schema: Install from PyPI repository Installing dtschema from github.com/devicetree-org is not needed anymore because dtschema is now part of regular PyPI repository. In certain cases it might cause some troubles as it brings latest master version, not the stable release: $ pip3 show dtschema Version: 2020.8.2.dev4+g341f3e3 $ make dt_binding_check dtschema minimum version is v2020.8.1 Reported-by: Marek Szyprowski Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220223073547.8746-1-krzysztof.kozlowski@canonical.com --- Documentation/devicetree/bindings/writing-schema.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/writing-schema.rst b/Documentation/devicetree/bindings/writing-schema.rst index ea21c72aeb37..4004dd9209a6 100644 --- a/Documentation/devicetree/bindings/writing-schema.rst +++ b/Documentation/devicetree/bindings/writing-schema.rst @@ -118,7 +118,7 @@ The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip:: - pip3 install git+https://github.com/devicetree-org/dt-schema.git@master + pip3 install dtschema Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default). -- cgit From 418adabeb3d048a4fd2575b8b96d0769c2fcd1c1 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 23 Feb 2022 08:35:47 +0100 Subject: dt-bindings: example: Extend with typical case (int-array and disallowed prop) Extend the example with: - an array where each element has constraints (min/max value), - property not allowed in case of different compatible. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220223073547.8746-2-krzysztof.kozlowski@canonical.com --- Documentation/devicetree/bindings/example-schema.yaml | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml index c078796ae1b5..80a28781845d 100644 --- a/Documentation/devicetree/bindings/example-schema.yaml +++ b/Documentation/devicetree/bindings/example-schema.yaml @@ -162,6 +162,16 @@ properties: don't need a type. enum: [ 100, 200, 300 ] + vendor,int-array-variable-length-and-constrained-values: + description: Array might define what type of elements might be used (e.g. + their range). + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 3 + items: + minimum: 0 + maximum: 8 + child-node: description: Child nodes are just another property from a json-schema perspective. @@ -207,6 +217,10 @@ allOf: then: required: - foo-supply + else: + # If otherwise the property is not allowed: + properties: + foo-supply: false # Altering schema depending on presence of properties is usually done by # dependencies (see above), however some adjustments might require if: - if: -- cgit From 62a40dad573406cdcb489dd45cfd201717c2e765 Mon Sep 17 00:00:00 2001 From: Oscar Shiang Date: Sun, 20 Feb 2022 20:12:00 +0800 Subject: docs: Remove duplicated words in trace/osnoise-tracer There are 2 duplicated words found in osnoise tracer documentation. This patch removes them. Signed-off-by: Oscar Shiang Acked-by: Steven Rostedt (Google) Acked-by: Daniel Bristot de Oliveira Link: https://lore.kernel.org/r/TYCP286MB1913117487F390E3BCE38B15A1399@TYCP286MB1913.JPNP286.PROD.OUTLOOK.COM Signed-off-by: Jonathan Corbet --- Documentation/trace/osnoise-tracer.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/osnoise-tracer.rst b/Documentation/trace/osnoise-tracer.rst index b648cb9bf1f0..963def9f97c6 100644 --- a/Documentation/trace/osnoise-tracer.rst +++ b/Documentation/trace/osnoise-tracer.rst @@ -51,7 +51,7 @@ For example:: [root@f32 ~]# cd /sys/kernel/tracing/ [root@f32 tracing]# echo osnoise > current_tracer -It is possible to follow the trace by reading the trace trace file:: +It is possible to follow the trace by reading the trace file:: [root@f32 tracing]# cat trace # tracer: osnoise @@ -108,7 +108,7 @@ The tracer has a set of options inside the osnoise directory, they are: option. - tracing_threshold: the minimum delta between two time() reads to be considered as noise, in us. When set to 0, the default value will - will be used, which is currently 5 us. + be used, which is currently 5 us. Additional Tracing ------------------ -- cgit From d978ab1a7b7a334634e60ed2467e657ca13b76d6 Mon Sep 17 00:00:00 2001 From: Mohan Kumar Date: Wed, 16 Feb 2022 14:52:39 +0530 Subject: dt-bindings: Document Tegra234 HDA support Update binding document for HDA support on Tegra234 chip. Tegra234 has max of 2 clocks and 2 resets which requires to add minItems and maxItems for clocks and resets as Tegra chips can now have minimum of 2 and maximum of 3 clocks and reset support. Signed-off-by: Mohan Kumar Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml index 2c913aa44fee..12c31b4b99e1 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml @@ -23,6 +23,7 @@ properties: - const: nvidia,tegra30-hda - items: - enum: + - nvidia,tegra234-hda - nvidia,tegra194-hda - nvidia,tegra186-hda - nvidia,tegra210-hda @@ -41,9 +42,11 @@ properties: maxItems: 1 clocks: + minItems: 2 maxItems: 3 clock-names: + minItems: 2 items: - const: hda - const: hda2hdmi -- cgit From e74964d0236f34b2abded4fead22dbec2272e213 Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Thu, 10 Feb 2022 14:18:17 +0100 Subject: dt-bindings: arm: at91: add Kontron's new KSwitches The Kontron KSwitch D10 MMT series ethernet switches features a LAN9668 SoC with either 8 copper ports or 6 copper port and two SFP cages. Signed-off-by: Michael Walle Reviewed-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Nicolas Ferre Link: https://lore.kernel.org/r/20220210131817.484922-1-michael@walle.cc --- Documentation/devicetree/bindings/arm/atmel-at91.yaml | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml index c612e1f48dba..9d46ff78739f 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml @@ -174,6 +174,15 @@ properties: - const: microchip,lan9668 - const: microchip,lan966 + - description: Kontron KSwitch D10 MMT series + items: + - enum: + - kontron,kswitch-d10-mmt-8g + - kontron,kswitch-d10-mmt-6g-2gs + - const: kontron,s1921 + - const: microchip,lan9668 + - const: microchip,lan966 + - items: - enum: - atmel,sams70j19 -- cgit From 024314d6d540a24cfe029421ad7e97e1d6e886b2 Mon Sep 17 00:00:00 2001 From: Yixuan Cao Date: Wed, 23 Feb 2022 21:41:04 +0800 Subject: Documentation/vm/page_owner.rst: fix language There are some words that need to be fixed. Thanks for Shuah Khan's constructive suggestions. The text has been fixed as follows. a. So, if you'd like to use it, you need to add "page_owner=on" into your boot cmdline. Here, "into" has been replaced with "to". b. ...page owner is disabled in runtime due to no enabling, boot option, runtime overhead is marginal. Here, "no" has been replaced with "not". Signed-off-by: Yixuan Cao Acked-by: Randy Dunlap Link: https://lore.kernel.org/r/20220223134104.2663-1-caoyixuan2019@email.szu.edu.cn Signed-off-by: Jonathan Corbet --- Documentation/vm/page_owner.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index 9837fc8147dd..bc28edaf3de1 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -26,9 +26,9 @@ fragmentation statistics can be obtained through gfp flag information of each page. It is already implemented and activated if page owner is enabled. Other usages are more than welcome. -page owner is disabled in default. So, if you'd like to use it, you need -to add "page_owner=on" into your boot cmdline. If the kernel is built -with page owner and page owner is disabled in runtime due to no enabling +page owner is disabled by default. So, if you'd like to use it, you need +to add "page_owner=on" to your boot cmdline. If the kernel is built +with page owner and page owner is disabled in runtime due to not enabling boot option, runtime overhead is marginal. If disabled in runtime, it doesn't require memory to store owner information, so there is no runtime memory overhead. And, page owner inserts just two unlikely branches into -- cgit From b089f167c384c7ca0adc50c78dd7a98f747d5e03 Mon Sep 17 00:00:00 2001 From: Naohiro Aota Date: Tue, 22 Feb 2022 10:27:51 +0900 Subject: Documentation: block/diskstats: update function names __make_request() and end_that_request_last() do no longer exist. Replace them with the current call-site. Signed-off-by: Naohiro Aota Reviewed-by: Chaitanya Kulkarni Reviwed-by: Jens Axboe Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220222012751.1933194-1-naohiro.aota@wdc.com Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/iostats.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/iostats.rst b/Documentation/admin-guide/iostats.rst index 9b14b0c2c9c4..609a3201fd4e 100644 --- a/Documentation/admin-guide/iostats.rst +++ b/Documentation/admin-guide/iostats.rst @@ -76,7 +76,7 @@ Field 3 -- # of sectors read (unsigned long) Field 4 -- # of milliseconds spent reading (unsigned int) This is the total number of milliseconds spent by all reads (as - measured from __make_request() to end_that_request_last()). + measured from blk_mq_alloc_request() to __blk_mq_end_request()). Field 5 -- # of writes completed (unsigned long) This is the total number of writes completed successfully. @@ -89,7 +89,7 @@ Field 7 -- # of sectors written (unsigned long) Field 8 -- # of milliseconds spent writing (unsigned int) This is the total number of milliseconds spent by all writes (as - measured from __make_request() to end_that_request_last()). + measured from blk_mq_alloc_request() to __blk_mq_end_request()). Field 9 -- # of I/Os currently in progress (unsigned int) The only field that should go to zero. Incremented as requests are @@ -120,7 +120,7 @@ Field 14 -- # of sectors discarded (unsigned long) Field 15 -- # of milliseconds spent discarding (unsigned int) This is the total number of milliseconds spent by all discards (as - measured from __make_request() to end_that_request_last()). + measured from blk_mq_alloc_request() to __blk_mq_end_request()). Field 16 -- # of flush requests completed This is the total number of flush requests completed successfully. -- cgit From 398f7abdcb7e2307facebcbdae5639f7d35916cd Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Fri, 18 Feb 2022 23:11:17 +0900 Subject: docs: pdfdocs: Pull LaTeX preamble part out of conf.py Quote from Jon's remark [1]: I do notice that Documentation/conf.py is getting large and unapproachable. At some future point, it might be nice to pull all of the latex stuff out into a separate file where it won't scare people who stumble into it by accident. Pull LaTeX preamble settings added since commit 3b4c963243b1 ("docs: conf.py: adjust the LaTeX document output") out into sphinx/kerneldoc-preamble.sty. It will be copied to the build directory by the added "latex_additional_files" setting in conf.py. As a bonus, LaTeX/TeX code can be maintained without escaping backslashes. To compensate the loss of change history in sphinx/kerneldoc-preamble.sty, here is a list of changes made in conf.py: - f7ebe6b76940 ("docs: Activate exCJK only in CJK chapters") - 0afd4df0d16a ("docs: pdfdocs: Prevent column squeezing by tabulary") - 659653c9e546 ("docs: pdfdocs: Refactor config for CJK document") - e291ff6f5a03 ("docs: pdfdocs: Add CJK-language-specific font settings") - 7eb368cc319b ("docs: pdfdocs: Choose Serif font as CJK mainfont if possible") - 35382965bdd2 ("docs: pdfdocs: Preserve inter-phrase space in Korean translations") - 77abc2c230b1 ("docs: pdfdocs: One-half spacing for CJK translations") - 788d28a25799 ("docs: pdfdocs: Permit AutoFakeSlant for CJK fonts") - 29ac9822358f ("docs: pdfdocs: Teach xeCJK about character classes of quotation marks") - 7c5c18bdb656 ("docs: pdfdocs: Fix typo in CJK-language specific font settings") - aa872e0647dc ("docs: pdfdocs: Adjust \headheight for fancyhdr") - 8716ef413aa5 ("docs: pdfdocs: Tweak width params of TOC") - 66939df53948 ("docs: pdfdocs: Switch default CJK font to KR variants") - 7b686a2ea1e4 ("docs: pdfdocs: Enable CJKspace in TOC for Korean titles") - 5d9158e3c762 ("docs/translations: Skip CJK contents if suitable fonts not found") - b774cc46313b ("docs: pdfdocs: Move CJK monospace font setting to main conf.py") [1]: https://lore.kernel.org/all/87zgmr66cn.fsf@meer.lwn.net/ Suggested-by: Jonathan Corbet Signed-off-by: Akira Yokosawa Link: https://lore.kernel.org/r/aaa9dca1-27c0-c414-77f3-c5587db0cc5b@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/conf.py | 184 ++-------------------------- Documentation/sphinx/kerneldoc-preamble.sty | 184 ++++++++++++++++++++++++++++ 2 files changed, 197 insertions(+), 171 deletions(-) create mode 100644 Documentation/sphinx/kerneldoc-preamble.sty (limited to 'Documentation') diff --git a/Documentation/conf.py b/Documentation/conf.py index fb8f69fc4d38..072ee31a301d 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -409,188 +409,25 @@ latex_elements = { # Additional stuff for the LaTeX preamble. 'preamble': ''' - % Custom width parameters for TOC --- Redefine low-level commands - % defined in report.cls - \\makeatletter - %% Redefine \\@pnumwidth (page number width) - \\renewcommand*\\@pnumwidth{2.7em} - %% Redefine \\l@chapter (chapter list entry) - \\renewcommand*\\l@chapter[2]{% - \\ifnum \\c@tocdepth >\\m@ne - \\addpenalty{-\\@highpenalty}% - \\vskip 1.0em \\@plus\\p@ - \\setlength\\@tempdima{1.8em}% - \\begingroup - \\parindent \\z@ \\rightskip \\@pnumwidth - \\parfillskip -\\@pnumwidth - \\leavevmode \\bfseries - \\advance\\leftskip\\@tempdima - \\hskip -\\leftskip - #1\\nobreak\\hfil - \\nobreak\\hb@xt@\\@pnumwidth{\\hss #2% - \\kern-\\p@\\kern\\p@}\\par - \\penalty\\@highpenalty - \\endgroup - \\fi} - %% Redefine \\l@section and \\l@subsection - \\renewcommand*\\l@section{\\@dottedtocline{1}{1.8em}{3.2em}} - \\renewcommand*\\l@subsection{\\@dottedtocline{2}{5em}{4.3em}} - \\makeatother - %% Sphinx < 1.8 doesn't have \\sphinxtableofcontentshook - \\providecommand{\\sphinxtableofcontentshook}{} - %% Undefine it for compatibility with Sphinx 1.7.9 - \\renewcommand{\\sphinxtableofcontentshook}{} % Empty the hook - % Prevent column squeezing of tabulary. - \\setlength{\\tymin}{20em} % Use some font with UTF-8 support with XeLaTeX \\usepackage{fontspec} \\setsansfont{DejaVu Sans} \\setromanfont{DejaVu Serif} \\setmonofont{DejaVu Sans Mono} - % Adjust \\headheight for fancyhdr - \\addtolength{\\headheight}{1.6pt} - \\addtolength{\\topmargin}{-1.6pt} - ''', + ''', } -# Translations have Asian (CJK) characters which are only displayed if -# xeCJK is used - -latex_elements['preamble'] += ''' - \\IfFontExistsTF{Noto Sans CJK SC}{ - % This is needed for translations - \\usepackage{xeCJK} - \\IfFontExistsTF{Noto Serif CJK KR}{ - \\setCJKmainfont{Noto Serif CJK KR}[AutoFakeSlant] - }{ - \\setCJKmainfont{Noto Sans CJK KR}[AutoFakeSlant] - } - \\setCJKsansfont{Noto Sans CJK KR}[AutoFakeSlant] - \\setCJKmonofont{Noto Sans Mono CJK KR}[AutoFakeSlant] - \\xeCJKDeclareCharClass{HalfLeft}{`“,`‘} - \\xeCJKDeclareCharClass{HalfRight}{`”,`’} - % CJK Language-specific font choices - \\IfFontExistsTF{Noto Serif CJK SC}{ - \\newCJKfontfamily[SCmain]\\scmain{Noto Serif CJK SC}[AutoFakeSlant] - \\newCJKfontfamily[SCserif]\\scserif{Noto Serif CJK SC}[AutoFakeSlant] - }{ - \\newCJKfontfamily[SCmain]\\scmain{Noto Sans CJK SC}[AutoFakeSlant] - \\newCJKfontfamily[SCserif]\\scserif{Noto Sans CJK SC}[AutoFakeSlant] - } - \\newCJKfontfamily[SCsans]\\scsans{Noto Sans CJK SC}[AutoFakeSlant] - \\newCJKfontfamily[SCmono]\\scmono{Noto Sans Mono CJK SC}[AutoFakeSlant] - \\IfFontExistsTF{Noto Serif CJK TC}{ - \\newCJKfontfamily[TCmain]\\tcmain{Noto Serif CJK TC}[AutoFakeSlant] - \\newCJKfontfamily[TCserif]\\tcserif{Noto Serif CJK TC}[AutoFakeSlant] - }{ - \\newCJKfontfamily[TCmain]\\tcmain{Noto Sans CJK TC}[AutoFakeSlant] - \\newCJKfontfamily[TCserif]\\tcserif{Noto Sans CJK TC}[AutoFakeSlant] - } - \\newCJKfontfamily[TCsans]\\tcsans{Noto Sans CJK TC}[AutoFakeSlant] - \\newCJKfontfamily[TCmono]\\tcmono{Noto Sans Mono CJK TC}[AutoFakeSlant] - \\IfFontExistsTF{Noto Serif CJK KR}{ - \\newCJKfontfamily[KRmain]\\krmain{Noto Serif CJK KR}[AutoFakeSlant] - \\newCJKfontfamily[KRserif]\\krserif{Noto Serif CJK KR}[AutoFakeSlant] - }{ - \\newCJKfontfamily[KRmain]\\krmain{Noto Sans CJK KR}[AutoFakeSlant] - \\newCJKfontfamily[KRserif]\\krserif{Noto Sans CJK KR}[AutoFakeSlant] - } - \\newCJKfontfamily[KRsans]\\krsans{Noto Sans CJK KR}[AutoFakeSlant] - \\newCJKfontfamily[KRmono]\\krmono{Noto Sans Mono CJK KR}[AutoFakeSlant] - \\IfFontExistsTF{Noto Serif CJK JP}{ - \\newCJKfontfamily[JPmain]\\jpmain{Noto Serif CJK JP}[AutoFakeSlant] - \\newCJKfontfamily[JPserif]\\jpserif{Noto Serif CJK JP}[AutoFakeSlant] - }{ - \\newCJKfontfamily[JPmain]\\jpmain{Noto Sans CJK JP}[AutoFakeSlant] - \\newCJKfontfamily[JPserif]\\jpserif{Noto Sans CJK JP}[AutoFakeSlant] - } - \\newCJKfontfamily[JPsans]\\jpsans{Noto Sans CJK JP}[AutoFakeSlant] - \\newCJKfontfamily[JPmono]\\jpmono{Noto Sans Mono CJK JP}[AutoFakeSlant] - % Dummy commands for Sphinx < 2.3 (no 'extrapackages' support) - \\providecommand{\\onehalfspacing}{} - \\providecommand{\\singlespacing}{} - % Define custom macros to on/off CJK - \\newcommand{\\kerneldocCJKon}{\\makexeCJKactive\\onehalfspacing} - \\newcommand{\\kerneldocCJKoff}{\\makexeCJKinactive\\singlespacing} - \\newcommand{\\kerneldocBeginSC}{% - \\begingroup% - \\scmain% - \\xeCJKDeclareCharClass{FullLeft}{`“,`‘}% - \\xeCJKDeclareCharClass{FullRight}{`”,`’}% - \\renewcommand{\\CJKrmdefault}{SCserif}% - \\renewcommand{\\CJKsfdefault}{SCsans}% - \\renewcommand{\\CJKttdefault}{SCmono}% - \\xeCJKsetup{CJKspace = false}% - % For CJK ascii-art alignment - \\setmonofont{Noto Sans Mono CJK SC}[AutoFakeSlant]% - } - \\newcommand{\\kerneldocEndSC}{\\endgroup} - \\newcommand{\\kerneldocBeginTC}{% - \\begingroup% - \\tcmain% - \\xeCJKDeclareCharClass{FullLeft}{`“,`‘}% - \\xeCJKDeclareCharClass{FullRight}{`”,`’}% - \\renewcommand{\\CJKrmdefault}{TCserif}% - \\renewcommand{\\CJKsfdefault}{TCsans}% - \\renewcommand{\\CJKttdefault}{TCmono}% - \\xeCJKsetup{CJKspace = false}% - % For CJK ascii-art alignment - \\setmonofont{Noto Sans Mono CJK TC}[AutoFakeSlant]% - } - \\newcommand{\\kerneldocEndTC}{\\endgroup} - \\newcommand{\\kerneldocBeginKR}{% - \\begingroup% - \\krmain% - \\renewcommand{\\CJKrmdefault}{KRserif}% - \\renewcommand{\\CJKsfdefault}{KRsans}% - \\renewcommand{\\CJKttdefault}{KRmono}% - % \\xeCJKsetup{CJKspace = true} % true by default - % For CJK ascii-art alignment (still misaligned for Hangul) - \\setmonofont{Noto Sans Mono CJK KR}[AutoFakeSlant]% - } - \\newcommand{\\kerneldocEndKR}{\\endgroup} - \\newcommand{\\kerneldocBeginJP}{% - \\begingroup% - \\jpmain% - \\renewcommand{\\CJKrmdefault}{JPserif}% - \\renewcommand{\\CJKsfdefault}{JPsans}% - \\renewcommand{\\CJKttdefault}{JPmono}% - \\xeCJKsetup{CJKspace = false}% - % For CJK ascii-art alignment - \\setmonofont{Noto Sans Mono CJK JP}[AutoFakeSlant]% - } - \\newcommand{\\kerneldocEndJP}{\\endgroup} - % Single spacing in literal blocks - \\fvset{baselinestretch=1} - % To customize \\sphinxtableofcontents - \\usepackage{etoolbox} - % Inactivate CJK after tableofcontents - \\apptocmd{\\sphinxtableofcontents}{\\kerneldocCJKoff}{}{} - \\xeCJKsetup{CJKspace = true} % For inter-phrase space of Korean TOC - }{ % No CJK font found - % Custom macros to on/off CJK (Dummy) - \\newcommand{\\kerneldocCJKon}{} - \\newcommand{\\kerneldocCJKoff}{} - \\newcommand{\\kerneldocBeginSC}[1]{% - \\begin{sphinxadmonition}{note}{Note:} - ``Noto Sans CJK'' fonts are not found while building this PDF\\@. - Translations of zh\\_CN, zh\\_TW, ko\\_KR, and ja\\_JP are - skipped. - \\end{sphinxadmonition}} - \\newcommand{\\kerneldocEndSC}{} - \\newcommand{\\kerneldocBeginTC}[1]{} - \\newcommand{\\kerneldocEndTC}{} - \\newcommand{\\kerneldocBeginKR}[1]{} - \\newcommand{\\kerneldocEndKR}{} - \\newcommand{\\kerneldocBeginJP}[1]{} - \\newcommand{\\kerneldocEndJP}{} - } -''' - # Fix reference escape troubles with Sphinx 1.4.x if major == 1: latex_elements['preamble'] += '\\renewcommand*{\\DUrole}[2]{ #2 }\n' + +# Load kerneldoc specific LaTeX settings +latex_elements['preamble'] += ''' + % Load kerneldoc specific LaTeX settings + \\input{kerneldoc-preamble.sty} +''' + # With Sphinx 1.6, it is possible to change the Bg color directly # by using: # \definecolor{sphinxnoteBgColor}{RGB}{204,255,255} @@ -652,6 +489,11 @@ for fn in os.listdir('.'): # If false, no module index is generated. #latex_domain_indices = True +# Additional LaTeX stuff to be copied to build directory +latex_additional_files = [ + 'sphinx/kerneldoc-preamble.sty', +] + # -- Options for manual page output --------------------------------------- diff --git a/Documentation/sphinx/kerneldoc-preamble.sty b/Documentation/sphinx/kerneldoc-preamble.sty new file mode 100644 index 000000000000..4e56ccea1dbd --- /dev/null +++ b/Documentation/sphinx/kerneldoc-preamble.sty @@ -0,0 +1,184 @@ +% -*- coding: utf-8 -*- +% SPDX-License-Identifier: GPL-2.0 +% +% LaTeX preamble for "make latexdocs" or "make pdfdocs" including: +% - TOC width settings +% - Setting of tabulary (\tymin) +% - Headheight setting for fancyhdr +% - Fontfamily settings for CJK (Chinese, Japanese, and Korean) translations +% +% Note on the suffix of .sty: +% This is not implemented as a LaTeX style file, but as a file containing +% plain LaTeX code to be included into preamble. +% ".sty" is chosen because ".tex" would cause the build scripts to confuse +% this file with a LaTeX main file. +% +% Copyright (C) 2022 Akira Yokosawa + +% Custom width parameters for TOC --- Redefine low-level commands +% defined in report.cls +\makeatletter +%% Redefine \@pnumwidth (page number width) +\renewcommand*\@pnumwidth{2.7em} +%% Redefine \l@chapter (chapter list entry) +\renewcommand*\l@chapter[2]{% + \ifnum \c@tocdepth >\m@ne + \addpenalty{-\@highpenalty}% + \vskip 1.0em \@plus\p@ + \setlength\@tempdima{1.8em}% + \begingroup + \parindent \z@ \rightskip \@pnumwidth + \parfillskip -\@pnumwidth + \leavevmode \bfseries + \advance\leftskip\@tempdima + \hskip -\leftskip + #1\nobreak\hfil + \nobreak\hb@xt@\@pnumwidth{\hss #2% + \kern-\p@\kern\p@}\par + \penalty\@highpenalty + \endgroup + \fi} +%% Redefine \l@section and \l@subsection +\renewcommand*\l@section{\@dottedtocline{1}{1.8em}{3.2em}} +\renewcommand*\l@subsection{\@dottedtocline{2}{5em}{4.3em}} +\makeatother +%% Sphinx < 1.8 doesn't have \sphinxtableofcontentshook +\providecommand{\sphinxtableofcontentshook}{} +%% Undefine it for compatibility with Sphinx 1.7.9 +\renewcommand{\sphinxtableofcontentshook}{} % Empty the hook +% Prevent column squeezing of tabulary. +\setlength{\tymin}{20em} + +% Adjust \headheight for fancyhdr +\addtolength{\headheight}{1.6pt} +\addtolength{\topmargin}{-1.6pt} + +% Translations have Asian (CJK) characters which are only displayed if +% xeCJK is used +\IfFontExistsTF{Noto Sans CJK SC}{ + % This is needed for translations + \usepackage{xeCJK} + \IfFontExistsTF{Noto Serif CJK KR}{ + \setCJKmainfont{Noto Serif CJK KR}[AutoFakeSlant] + }{ + \setCJKmainfont{Noto Sans CJK KR}[AutoFakeSlant] + } + \setCJKsansfont{Noto Sans CJK KR}[AutoFakeSlant] + \setCJKmonofont{Noto Sans Mono CJK KR}[AutoFakeSlant] + \xeCJKDeclareCharClass{HalfLeft}{`“,`‘} + \xeCJKDeclareCharClass{HalfRight}{`”,`’} + % CJK Language-specific font choices + \IfFontExistsTF{Noto Serif CJK SC}{ + \newCJKfontfamily[SCmain]\scmain{Noto Serif CJK SC}[AutoFakeSlant] + \newCJKfontfamily[SCserif]\scserif{Noto Serif CJK SC}[AutoFakeSlant] + }{ + \newCJKfontfamily[SCmain]\scmain{Noto Sans CJK SC}[AutoFakeSlant] + \newCJKfontfamily[SCserif]\scserif{Noto Sans CJK SC}[AutoFakeSlant] + } + \newCJKfontfamily[SCsans]\scsans{Noto Sans CJK SC}[AutoFakeSlant] + \newCJKfontfamily[SCmono]\scmono{Noto Sans Mono CJK SC}[AutoFakeSlant] + \IfFontExistsTF{Noto Serif CJK TC}{ + \newCJKfontfamily[TCmain]\tcmain{Noto Serif CJK TC}[AutoFakeSlant] + \newCJKfontfamily[TCserif]\tcserif{Noto Serif CJK TC}[AutoFakeSlant] + }{ + \newCJKfontfamily[TCmain]\tcmain{Noto Sans CJK TC}[AutoFakeSlant] + \newCJKfontfamily[TCserif]\tcserif{Noto Sans CJK TC}[AutoFakeSlant] + } + \newCJKfontfamily[TCsans]\tcsans{Noto Sans CJK TC}[AutoFakeSlant] + \newCJKfontfamily[TCmono]\tcmono{Noto Sans Mono CJK TC}[AutoFakeSlant] + \IfFontExistsTF{Noto Serif CJK KR}{ + \newCJKfontfamily[KRmain]\krmain{Noto Serif CJK KR}[AutoFakeSlant] + \newCJKfontfamily[KRserif]\krserif{Noto Serif CJK KR}[AutoFakeSlant] + }{ + \newCJKfontfamily[KRmain]\krmain{Noto Sans CJK KR}[AutoFakeSlant] + \newCJKfontfamily[KRserif]\krserif{Noto Sans CJK KR}[AutoFakeSlant] + } + \newCJKfontfamily[KRsans]\krsans{Noto Sans CJK KR}[AutoFakeSlant] + \newCJKfontfamily[KRmono]\krmono{Noto Sans Mono CJK KR}[AutoFakeSlant] + \IfFontExistsTF{Noto Serif CJK JP}{ + \newCJKfontfamily[JPmain]\jpmain{Noto Serif CJK JP}[AutoFakeSlant] + \newCJKfontfamily[JPserif]\jpserif{Noto Serif CJK JP}[AutoFakeSlant] + }{ + \newCJKfontfamily[JPmain]\jpmain{Noto Sans CJK JP}[AutoFakeSlant] + \newCJKfontfamily[JPserif]\jpserif{Noto Sans CJK JP}[AutoFakeSlant] + } + \newCJKfontfamily[JPsans]\jpsans{Noto Sans CJK JP}[AutoFakeSlant] + \newCJKfontfamily[JPmono]\jpmono{Noto Sans Mono CJK JP}[AutoFakeSlant] + % Dummy commands for Sphinx < 2.3 (no 'extrapackages' support) + \providecommand{\onehalfspacing}{} + \providecommand{\singlespacing}{} + % Define custom macros to on/off CJK + \newcommand{\kerneldocCJKon}{\makexeCJKactive\onehalfspacing} + \newcommand{\kerneldocCJKoff}{\makexeCJKinactive\singlespacing} + \newcommand{\kerneldocBeginSC}{% + \begingroup% + \scmain% + \xeCJKDeclareCharClass{FullLeft}{`“,`‘}% + \xeCJKDeclareCharClass{FullRight}{`”,`’}% + \renewcommand{\CJKrmdefault}{SCserif}% + \renewcommand{\CJKsfdefault}{SCsans}% + \renewcommand{\CJKttdefault}{SCmono}% + \xeCJKsetup{CJKspace = false}% + % For CJK ascii-art alignment + \setmonofont{Noto Sans Mono CJK SC}[AutoFakeSlant]% + } + \newcommand{\kerneldocEndSC}{\endgroup} + \newcommand{\kerneldocBeginTC}{% + \begingroup% + \tcmain% + \xeCJKDeclareCharClass{FullLeft}{`“,`‘}% + \xeCJKDeclareCharClass{FullRight}{`”,`’}% + \renewcommand{\CJKrmdefault}{TCserif}% + \renewcommand{\CJKsfdefault}{TCsans}% + \renewcommand{\CJKttdefault}{TCmono}% + \xeCJKsetup{CJKspace = false}% + % For CJK ascii-art alignment + \setmonofont{Noto Sans Mono CJK TC}[AutoFakeSlant]% + } + \newcommand{\kerneldocEndTC}{\endgroup} + \newcommand{\kerneldocBeginKR}{% + \begingroup% + \krmain% + \renewcommand{\CJKrmdefault}{KRserif}% + \renewcommand{\CJKsfdefault}{KRsans}% + \renewcommand{\CJKttdefault}{KRmono}% + % \xeCJKsetup{CJKspace = true} % true by default + % For CJK ascii-art alignment (still misaligned for Hangul) + \setmonofont{Noto Sans Mono CJK KR}[AutoFakeSlant]% + } + \newcommand{\kerneldocEndKR}{\endgroup} + \newcommand{\kerneldocBeginJP}{% + \begingroup% + \jpmain% + \renewcommand{\CJKrmdefault}{JPserif}% + \renewcommand{\CJKsfdefault}{JPsans}% + \renewcommand{\CJKttdefault}{JPmono}% + \xeCJKsetup{CJKspace = false}% + % For CJK ascii-art alignment + \setmonofont{Noto Sans Mono CJK JP}[AutoFakeSlant]% + } + \newcommand{\kerneldocEndJP}{\endgroup} + % Single spacing in literal blocks + \fvset{baselinestretch=1} + % To customize \sphinxtableofcontents + \usepackage{etoolbox} + % Inactivate CJK after tableofcontents + \apptocmd{\sphinxtableofcontents}{\kerneldocCJKoff}{}{} + \xeCJKsetup{CJKspace = true} % For inter-phrase space of Korean TOC +}{ % No CJK font found + % Custom macros to on/off CJK (Dummy) + \newcommand{\kerneldocCJKon}{} + \newcommand{\kerneldocCJKoff}{} + \newcommand{\kerneldocBeginSC}[1]{% + \begin{sphinxadmonition}{note}{Note:} + ``Noto Sans CJK'' fonts are not found while building this PDF\@. + Translations of zh\_CN, zh\_TW, ko\_KR, and ja\_JP are skipped. + \end{sphinxadmonition}} + \newcommand{\kerneldocEndSC}{} + \newcommand{\kerneldocBeginTC}[1]{} + \newcommand{\kerneldocEndTC}{} + \newcommand{\kerneldocBeginKR}[1]{} + \newcommand{\kerneldocEndKR}{} + \newcommand{\kerneldocBeginJP}[1]{} + \newcommand{\kerneldocEndJP}{} +} -- cgit From 7cee33ce237cef25cbd782783a7e0241ef6d0776 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Fri, 18 Feb 2022 23:13:41 +0900 Subject: docs: kerneldoc-preamble.sty: Expand comments in LaTeX code Expand comments in LaTeX code and mention some of important points told in changelogs of conf.py changes. Hopefully they can help future contributors in this area. No code change involved. Signed-off-by: Akira Yokosawa Cc: Jonathan Corbet Link: https://lore.kernel.org/r/bce9261b-1950-3146-07b2-07bd2ec79158@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/sphinx/kerneldoc-preamble.sty | 61 +++++++++++++++++++++++------ 1 file changed, 48 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sphinx/kerneldoc-preamble.sty b/Documentation/sphinx/kerneldoc-preamble.sty index 4e56ccea1dbd..5e59900e994d 100644 --- a/Documentation/sphinx/kerneldoc-preamble.sty +++ b/Documentation/sphinx/kerneldoc-preamble.sty @@ -15,8 +15,20 @@ % % Copyright (C) 2022 Akira Yokosawa -% Custom width parameters for TOC --- Redefine low-level commands -% defined in report.cls +% Custom width parameters for TOC +% - Redefine low-level commands defined in report.cls. +% - Indent of 2 chars is preserved for ease of comparison. +% Summary of changes from default params: +% Width of page number (\@pnumwidth): 1.55em -> 2.7em +% Width of chapter number: 1.5em -> 1.8em +% Indent of section number: 1.5em -> 1.8em +% Width of section number: 2.6em -> 3.2em +% Indent of sebsection number: 4.1em -> 5em +% Width of subsection number: 3.5em -> 4.3em +% +% These params can have 4 digit page counts, 2 digit chapter counts, +% section counts of 4 digits + 1 period (e.g., 18.10), and subsection counts +% of 5 digits + 2 periods (e.g., 18.7.13). \makeatletter %% Redefine \@pnumwidth (page number width) \renewcommand*\@pnumwidth{2.7em} @@ -46,7 +58,10 @@ \providecommand{\sphinxtableofcontentshook}{} %% Undefine it for compatibility with Sphinx 1.7.9 \renewcommand{\sphinxtableofcontentshook}{} % Empty the hook -% Prevent column squeezing of tabulary. + +% Prevent column squeezing of tabulary. \tymin is set by Sphinx as: +% \setlength{\tymin}{3\fontcharwd\font`0 } +% , which is too short. \setlength{\tymin}{20em} % Adjust \headheight for fancyhdr @@ -56,8 +71,12 @@ % Translations have Asian (CJK) characters which are only displayed if % xeCJK is used \IfFontExistsTF{Noto Sans CJK SC}{ - % This is needed for translations + % Load xeCJK when CJK font is available \usepackage{xeCJK} + % Noto CJK fonts don't provide slant shape. [AutoFakeSlant] permits + % its emulation. + % Select KR variant at the beginning of each document so that quotation + % and apostorph symbols of half-width is used in TOC of Latin documents. \IfFontExistsTF{Noto Serif CJK KR}{ \setCJKmainfont{Noto Serif CJK KR}[AutoFakeSlant] }{ @@ -65,9 +84,11 @@ } \setCJKsansfont{Noto Sans CJK KR}[AutoFakeSlant] \setCJKmonofont{Noto Sans Mono CJK KR}[AutoFakeSlant] + % Teach xeCJK of half-width symbols \xeCJKDeclareCharClass{HalfLeft}{`“,`‘} \xeCJKDeclareCharClass{HalfRight}{`”,`’} % CJK Language-specific font choices + %% for Simplified Chinese \IfFontExistsTF{Noto Serif CJK SC}{ \newCJKfontfamily[SCmain]\scmain{Noto Serif CJK SC}[AutoFakeSlant] \newCJKfontfamily[SCserif]\scserif{Noto Serif CJK SC}[AutoFakeSlant] @@ -77,6 +98,7 @@ } \newCJKfontfamily[SCsans]\scsans{Noto Sans CJK SC}[AutoFakeSlant] \newCJKfontfamily[SCmono]\scmono{Noto Sans Mono CJK SC}[AutoFakeSlant] + %% for Traditional Chinese \IfFontExistsTF{Noto Serif CJK TC}{ \newCJKfontfamily[TCmain]\tcmain{Noto Serif CJK TC}[AutoFakeSlant] \newCJKfontfamily[TCserif]\tcserif{Noto Serif CJK TC}[AutoFakeSlant] @@ -86,6 +108,7 @@ } \newCJKfontfamily[TCsans]\tcsans{Noto Sans CJK TC}[AutoFakeSlant] \newCJKfontfamily[TCmono]\tcmono{Noto Sans Mono CJK TC}[AutoFakeSlant] + %% for Korean \IfFontExistsTF{Noto Serif CJK KR}{ \newCJKfontfamily[KRmain]\krmain{Noto Serif CJK KR}[AutoFakeSlant] \newCJKfontfamily[KRserif]\krserif{Noto Serif CJK KR}[AutoFakeSlant] @@ -95,6 +118,7 @@ } \newCJKfontfamily[KRsans]\krsans{Noto Sans CJK KR}[AutoFakeSlant] \newCJKfontfamily[KRmono]\krmono{Noto Sans Mono CJK KR}[AutoFakeSlant] + %% for Japanese \IfFontExistsTF{Noto Serif CJK JP}{ \newCJKfontfamily[JPmain]\jpmain{Noto Serif CJK JP}[AutoFakeSlant] \newCJKfontfamily[JPserif]\jpserif{Noto Serif CJK JP}[AutoFakeSlant] @@ -108,34 +132,39 @@ \providecommand{\onehalfspacing}{} \providecommand{\singlespacing}{} % Define custom macros to on/off CJK + %% One and half spacing for CJK contents \newcommand{\kerneldocCJKon}{\makexeCJKactive\onehalfspacing} \newcommand{\kerneldocCJKoff}{\makexeCJKinactive\singlespacing} + % Define custom macros for switching CJK font setting + %% for Simplified Chinese \newcommand{\kerneldocBeginSC}{% \begingroup% \scmain% - \xeCJKDeclareCharClass{FullLeft}{`“,`‘}% - \xeCJKDeclareCharClass{FullRight}{`”,`’}% + \xeCJKDeclareCharClass{FullLeft}{`“,`‘}% Full-width in SC + \xeCJKDeclareCharClass{FullRight}{`”,`’}% Full-width in SC \renewcommand{\CJKrmdefault}{SCserif}% \renewcommand{\CJKsfdefault}{SCsans}% \renewcommand{\CJKttdefault}{SCmono}% - \xeCJKsetup{CJKspace = false}% + \xeCJKsetup{CJKspace = false}% gobble white spaces by ' ' % For CJK ascii-art alignment \setmonofont{Noto Sans Mono CJK SC}[AutoFakeSlant]% } \newcommand{\kerneldocEndSC}{\endgroup} + %% for Traditional Chinese \newcommand{\kerneldocBeginTC}{% \begingroup% \tcmain% - \xeCJKDeclareCharClass{FullLeft}{`“,`‘}% - \xeCJKDeclareCharClass{FullRight}{`”,`’}% + \xeCJKDeclareCharClass{FullLeft}{`“,`‘}% Full-width in TC + \xeCJKDeclareCharClass{FullRight}{`”,`’}% Full-width in TC \renewcommand{\CJKrmdefault}{TCserif}% \renewcommand{\CJKsfdefault}{TCsans}% \renewcommand{\CJKttdefault}{TCmono}% - \xeCJKsetup{CJKspace = false}% + \xeCJKsetup{CJKspace = false}% gobble white spaces by ' ' % For CJK ascii-art alignment \setmonofont{Noto Sans Mono CJK TC}[AutoFakeSlant]% } \newcommand{\kerneldocEndTC}{\endgroup} + %% for Korean \newcommand{\kerneldocBeginKR}{% \begingroup% \krmain% @@ -147,29 +176,35 @@ \setmonofont{Noto Sans Mono CJK KR}[AutoFakeSlant]% } \newcommand{\kerneldocEndKR}{\endgroup} + %% for Japanese \newcommand{\kerneldocBeginJP}{% \begingroup% \jpmain% \renewcommand{\CJKrmdefault}{JPserif}% \renewcommand{\CJKsfdefault}{JPsans}% \renewcommand{\CJKttdefault}{JPmono}% - \xeCJKsetup{CJKspace = false}% + \xeCJKsetup{CJKspace = false}% gobble white space by ' ' % For CJK ascii-art alignment \setmonofont{Noto Sans Mono CJK JP}[AutoFakeSlant]% } \newcommand{\kerneldocEndJP}{\endgroup} + % Single spacing in literal blocks \fvset{baselinestretch=1} % To customize \sphinxtableofcontents \usepackage{etoolbox} % Inactivate CJK after tableofcontents \apptocmd{\sphinxtableofcontents}{\kerneldocCJKoff}{}{} - \xeCJKsetup{CJKspace = true} % For inter-phrase space of Korean TOC + \xeCJKsetup{CJKspace = true}% For inter-phrase space of Korean TOC }{ % No CJK font found - % Custom macros to on/off CJK (Dummy) + % Custom macros to on/off CJK and switch CJK fonts (Dummy) \newcommand{\kerneldocCJKon}{} \newcommand{\kerneldocCJKoff}{} + %% By defining \kerneldocBegin(SC|TC|KR|JP) as commands with an argument + %% and ignore the argument (#1) in their definitions, whole contents of + %% CJK chapters can be ignored. \newcommand{\kerneldocBeginSC}[1]{% + %% Put a note on missing CJK fonts in place of zh_CN translation. \begin{sphinxadmonition}{note}{Note:} ``Noto Sans CJK'' fonts are not found while building this PDF\@. Translations of zh\_CN, zh\_TW, ko\_KR, and ja\_JP are skipped. -- cgit From 96c7f3b53cc34d8d11ce0b8c6baabba1c5ee16e0 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Fri, 18 Feb 2022 23:26:34 +0900 Subject: Reword note on missing CJK fonts Use past tense as the fonts can be installed after the fact. Add suggestion to install "Noto Sans CJK" and "Noto Serif CJK" font families. ("Noto Serif CJK" is optional.) Signed-off-by: Akira Yokosawa Cc: Jonathan Corbet Link: https://lore.kernel.org/r/dfefa601-c58d-c86c-953f-5e4454db9409@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/sphinx/kerneldoc-preamble.sty | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sphinx/kerneldoc-preamble.sty b/Documentation/sphinx/kerneldoc-preamble.sty index 5e59900e994d..9d0204dc38be 100644 --- a/Documentation/sphinx/kerneldoc-preamble.sty +++ b/Documentation/sphinx/kerneldoc-preamble.sty @@ -205,9 +205,16 @@ %% CJK chapters can be ignored. \newcommand{\kerneldocBeginSC}[1]{% %% Put a note on missing CJK fonts in place of zh_CN translation. - \begin{sphinxadmonition}{note}{Note:} - ``Noto Sans CJK'' fonts are not found while building this PDF\@. - Translations of zh\_CN, zh\_TW, ko\_KR, and ja\_JP are skipped. + \begin{sphinxadmonition}{note}{Note on missing fonts:} + Translations of Simplified Chinese (zh\_CN), Traditional Chinese + (zh\_TW), Korean (ko\_KR), and Japanese (ja\_JP) were skipped + due to the lack of suitable font families. + + If you want them, please install ``Noto Sans CJK'' font families + by following instructions from + \sphinxcode{./scripts/sphinx-pre-install}. + Having optional ``Noto Serif CJK'' font families will improve + the looks of those translations. \end{sphinxadmonition}} \newcommand{\kerneldocEndSC}{} \newcommand{\kerneldocBeginTC}[1]{} -- cgit From 18ab307823bb643fc985d316448f2d70eb1cb7c3 Mon Sep 17 00:00:00 2001 From: Jonathan Corbet Date: Thu, 24 Feb 2022 12:35:07 -0700 Subject: docs: fix RST error in vm/page_owner.rst Commit f7df2b1cf03a ("tools/vm/page_owner_sort.c: count and sort by mem") added a literal text block without the necessary markup, leading to these warnings in the docs build: Documentation/vm/page_owner.rst:92: WARNING: Unexpected indentation. Documentation/vm/page_owner.rst:96: WARNING: Unexpected indentation. Documentation/vm/page_owner.rst:107: WARNING: Unexpected indentation. Add the necessary colons and make the build quieter. Signed-off-by: Jonathan Corbet --- Documentation/vm/page_owner.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index bc28edaf3de1..905555e3e483 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -85,7 +85,7 @@ Usage cat /sys/kernel/debug/page_owner > page_owner_full.txt ./page_owner_sort page_owner_full.txt sorted_page_owner.txt - The general output of ``page_owner_full.txt`` is as follows: + The general output of ``page_owner_full.txt`` is as follows:: Page allocated via order XXX, ... PFN XXX ... @@ -100,7 +100,7 @@ Usage and pages of buf, and finally sorts them according to the times. See the result about who allocated each page - in the ``sorted_page_owner.txt``. General output: + in the ``sorted_page_owner.txt``. General output:: XXX times, XXX pages: Page allocated via order XXX, ... -- cgit From 1ecf393fc5a5962ebbe8d011dede6cab880f349b Mon Sep 17 00:00:00 2001 From: Thorsten Leemhuis Date: Wed, 16 Feb 2022 07:51:33 +0100 Subject: docs: add two documents about regression handling Create two documents explaining various aspects around regression handling and tracking; one is aimed at users, the other targets developers. The texts among others describes the first rule of Linux kernel development and what it means in practice. They also explain what a regression actually is and how to report one properly. Both texts additionally provide a brief introduction to the bot the kernel's regression tracker uses to facilitate the work, but mention the use is optional. To sum things up, provide a few quotes from Linus in the document for developers to show how serious we take regressions. Signed-off-by: Thorsten Leemhuis Link: https://lore.kernel.org/r/34e56d3588f22d7e0b4d635ef9c9c3b33ca4ac04.1644994117.git.linux@leemhuis.info Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/index.rst | 1 + .../admin-guide/reporting-regressions.rst | 439 ++++++++++++++ Documentation/process/handling-regressions.rst | 659 +++++++++++++++++++++ Documentation/process/index.rst | 1 + 4 files changed, 1100 insertions(+) create mode 100644 Documentation/admin-guide/reporting-regressions.rst create mode 100644 Documentation/process/handling-regressions.rst (limited to 'Documentation') diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index 1bedab498104..5bfafcbb9562 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -35,6 +35,7 @@ problems and bugs in particular. :maxdepth: 1 reporting-issues + reporting-regressions security-bugs bug-hunting bug-bisect diff --git a/Documentation/admin-guide/reporting-regressions.rst b/Documentation/admin-guide/reporting-regressions.rst new file mode 100644 index 000000000000..6fbd24ceb3bf --- /dev/null +++ b/Documentation/admin-guide/reporting-regressions.rst @@ -0,0 +1,439 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0) +.. [see the bottom of this file for redistribution information] + +Reporting regressions ++++++++++++++++++++++ + +"*We don't cause regressions*" is the first rule of Linux kernel development; +Linux founder and lead developer Linus Torvalds established it himself and +ensures it's obeyed. + +This document describes what the rule means for users and how the Linux kernel's +development model ensures to address all reported regressions; aspects relevant +for kernel developers are left to Documentation/process/handling-regressions.rst. + + +The important bits (aka "TL;DR") +================================ + +#. It's a regression if something running fine with one Linux kernel works worse + or not at all with a newer version. Note, the newer kernel has to be compiled + using a similar configuration; the detailed explanations below describes this + and other fine print in more detail. + +#. Report your issue as outlined in Documentation/admin-guide/reporting-issues.rst, + it already covers all aspects important for regressions and repeated + below for convenience. Two of them are important: start your report's subject + with "[REGRESSION]" and CC or forward it to `the regression mailing list + `_ (regressions@lists.linux.dev). + +#. Optional, but recommended: when sending or forwarding your report, make the + Linux kernel regression tracking bot "regzbot" track the issue by specifying + when the regression started like this:: + + #regzbot introduced v5.13..v5.14-rc1 + + +All the details on Linux kernel regressions relevant for users +============================================================== + + +The important basics +-------------------- + + +What is a "regression" and what is the "no regressions rule"? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It's a regression if some application or practical use case running fine with +one Linux kernel works worse or not at all with a newer version compiled using a +similar configuration. The "no regressions rule" forbids this to take place; if +it happens by accident, developers that caused it are expected to quickly fix +the issue. + +It thus is a regression when a WiFi driver from Linux 5.13 works fine, but with +5.14 doesn't work at all, works significantly slower, or misbehaves somehow. +It's also a regression if a perfectly working application suddenly shows erratic +behavior with a newer kernel version; such issues can be caused by changes in +procfs, sysfs, or one of the many other interfaces Linux provides to userland +software. But keep in mind, as mentioned earlier: 5.14 in this example needs to +be built from a configuration similar to the one from 5.13. This can be achieved +using ``make olddefconfig``, as explained in more detail below. + +Note the "practical use case" in the first sentence of this section: developers +despite the "no regressions" rule are free to change any aspect of the kernel +and even APIs or ABIs to userland, as long as no existing application or use +case breaks. + +Also be aware the "no regressions" rule covers only interfaces the kernel +provides to the userland. It thus does not apply to kernel-internal interfaces +like the module API, which some externally developed drivers use to hook into +the kernel. + +How do I report a regression? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Just report the issue as outlined in +Documentation/admin-guide/reporting-issues.rst, it already describes the +important points. The following aspects outlined there are especially relevant +for regressions: + + * When checking for existing reports to join, also search the `archives of the + Linux regressions mailing list `_ and + `regzbot's web-interface `_. + + * Start your report's subject with "[REGRESSION]". + + * In your report, clearly mention the last kernel version that worked fine and + the first broken one. Ideally try to find the exact change causing the + regression using a bisection, as explained below in more detail. + + * Remember to let the Linux regressions mailing list + (regressions@lists.linux.dev) know about your report: + + * If you report the regression by mail, CC the regressions list. + + * If you report your regression to some bug tracker, forward the submitted + report by mail to the regressions list while CCing the maintainer and the + mailing list for the subsystem in question. + + If it's a regression within a stable or longterm series (e.g. + v5.15.3..v5.15.5), remember to CC the `Linux stable mailing list + `_ (stable@vger.kernel.org). + + In case you performed a successful bisection, add everyone to the CC the + culprit's commit message mentions in lines starting with "Signed-off-by:". + +When CCing for forwarding your report to the list, consider directly telling the +aforementioned Linux kernel regression tracking bot about your report. To do +that, include a paragraph like this in your mail:: + + #regzbot introduced: v5.13..v5.14-rc1 + +Regzbot will then consider your mail a report for a regression introduced in the +specified version range. In above case Linux v5.13 still worked fine and Linux +v5.14-rc1 was the first version where you encountered the issue. If you +performed a bisection to find the commit that caused the regression, specify the +culprit's commit-id instead:: + + #regzbot introduced: 1f2e3d4c5d + +Placing such a "regzbot command" is in your interest, as it will ensure the +report won't fall through the cracks unnoticed. If you omit this, the Linux +kernel's regressions tracker will take care of telling regzbot about your +regression, as long as you send a copy to the regressions mailing lists. But the +regression tracker is just one human which sometimes has to rest or occasionally +might even enjoy some time away from computers (as crazy as that might sound). +Relying on this person thus will result in an unnecessary delay before the +regressions becomes mentioned `on the list of tracked and unresolved Linux +kernel regressions `_ and the +weekly regression reports sent by regzbot. Such delays can result in Linus +Torvalds being unaware of important regressions when deciding between "continue +development or call this finished and release the final?". + +Are really all regressions fixed? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Nearly all of them are, as long as the change causing the regression (the +"culprit commit") is reliably identified. Some regressions can be fixed without +this, but often it's required. + +Who needs to find the root cause of a regression? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Developers of the affected code area should try to locate the culprit on their +own. But for them that's often impossible to do with reasonable effort, as quite +a lot of issues only occur in a particular environment outside the developer's +reach -- for example, a specific hardware platform, firmware, Linux distro, +system's configuration, or application. That's why in the end it's often up to +the reporter to locate the culprit commit; sometimes users might even need to +run additional tests afterwards to pinpoint the exact root cause. Developers +should offer advice and reasonably help where they can, to make this process +relatively easy and achievable for typical users. + +How can I find the culprit? +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Perform a bisection, as roughly outlined in +Documentation/admin-guide/reporting-issues.rst and described in more detail by +Documentation/admin-guide/bug-bisect.rst. It might sound like a lot of work, but +in many cases finds the culprit relatively quickly. If it's hard or +time-consuming to reliably reproduce the issue, consider teaming up with other +affected users to narrow down the search range together. + +Who can I ask for advice when it comes to regressions? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Send a mail to the regressions mailing list (regressions@lists.linux.dev) while +CCing the Linux kernel's regression tracker (regressions@leemhuis.info); if the +issue might better be dealt with in private, feel free to omit the list. + + +Additional details about regressions +------------------------------------ + + +What is the goal of the "no regressions rule"? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Users should feel safe when updating kernel versions and not have to worry +something might break. This is in the interest of the kernel developers to make +updating attractive: they don't want users to stay on stable or longterm Linux +series that are either abandoned or more than one and a half years old. That's +in everybody's interest, as `those series might have known bugs, security +issues, or other problematic aspects already fixed in later versions +`_. +Additionally, the kernel developers want to make it simple and appealing for +users to test the latest pre-release or regular release. That's also in +everybody's interest, as it's a lot easier to track down and fix problems, if +they are reported shortly after being introduced. + +Is the "no regressions" rule really adhered in practice? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It's taken really seriously, as can be seen by many mailing list posts from +Linux creator and lead developer Linus Torvalds, some of which are quoted in +Documentation/process/handling-regressions.rst. + +Exceptions to this rule are extremely rare; in the past developers almost always +turned out to be wrong when they assumed a particular situation was warranting +an exception. + +Who ensures the "no regressions" is actually followed? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The subsystem maintainers should take care of that, which are watched and +supported by the tree maintainers -- e.g. Linus Torvalds for mainline and +Greg Kroah-Hartman et al. for various stable/longterm series. + +All of them are helped by people trying to ensure no regression report falls +through the cracks. One of them is Thorsten Leemhuis, who's currently acting as +the Linux kernel's "regressions tracker"; to facilitate this work he relies on +regzbot, the Linux kernel regression tracking bot. That's why you want to bring +your report on the radar of these people by CCing or forwarding each report to +the regressions mailing list, ideally with a "regzbot command" in your mail to +get it tracked immediately. + +Is it a regression, if the issue can be avoided by updating some software? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Almost always: yes. If a developer tells you otherwise, ask the regression +tracker for advice as outlined above. + +Is it a regression, if a newer kernel works slower or consumes more energy? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Yes, but the difference has to be significant. A five percent slow-down in a +micro-benchmark thus is unlikely to qualify as regression, unless it also +influences the results of a broad benchmark by more than one percent. If in +doubt, ask for advice. + +Is it a regression, if an external kernel module breaks when updating Linux? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +No, as the "no regression" rule is about interfaces and services the Linux +kernel provides to the userland. It thus does not cover building or running +externally developed kernel modules, as they run in kernel-space and hook into +the kernel using internal interfaces occasionally changed. + +How are regressions handled that are caused by security fixes? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In extremely rare situations security issues can't be fixed without causing +regressions; those fixes are given way, as they are the lesser evil in the end. +Luckily this middling almost always can be avoided, as key developers for the +affected area and often Linus Torvalds himself try very hard to fix security +issues without causing regressions. + +If you nevertheless face such a case, check the mailing list archives if people +tried their best to avoid the regression. If not, report it; if in doubt, ask +for advice as outlined above. + +What happens if fixing a regression is impossible without causing another? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Sadly these things happen, but luckily not very often; if they occur, expert +developers of the affected code area should look into the issue to find a fix +that avoids regressions or at least their impact. If you run into such a +situation, do what was outlined already for regressions caused by security +fixes: check earlier discussions if people already tried their best and ask for +advice if in doubt. + +A quick note while at it: these situations could be avoided, if people would +regularly give mainline pre-releases (say v5.15-rc1 or -rc3) from each +development cycle a test run. This is best explained by imagining a change +integrated between Linux v5.14 and v5.15-rc1 which causes a regression, but at +the same time is a hard requirement for some other improvement applied for +5.15-rc1. All these changes often can simply be reverted and the regression thus +solved, if someone finds and reports it before 5.15 is released. A few days or +weeks later this solution can become impossible, as some software might have +started to rely on aspects introduced by one of the follow-up changes: reverting +all changes would then cause a regression for users of said software and thus is +out of the question. + +Is it a regression, if some feature I relied on was removed months ago? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is, but often it's hard to fix such regressions due to the aspects outlined +in the previous section. It hence needs to be dealt with on a case-by-case +basis. This is another reason why it's in everybody's interest to regularly test +mainline pre-releases. + +Does the "no regression" rule apply if I seem to be the only affected person? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It does, but only for practical usage: the Linux developers want to be free to +remove support for hardware only to be found in attics and museums anymore. + +Note, sometimes regressions can't be avoided to make progress -- and the latter +is needed to prevent Linux from stagnation. Hence, if only very few users seem +to be affected by a regression, it for the greater good might be in their and +everyone else's interest to lettings things pass. Especially if there is an +easy way to circumvent the regression somehow, for example by updating some +software or using a kernel parameter created just for this purpose. + +Does the regression rule apply for code in the staging tree as well? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Not according to the `help text for the configuration option covering all +staging code `_, +which since its early days states:: + + Please note that these drivers are under heavy development, may or + may not work, and may contain userspace interfaces that most likely + will be changed in the near future. + +The staging developers nevertheless often adhere to the "no regressions" rule, +but sometimes bend it to make progress. That's for example why some users had to +deal with (often negligible) regressions when a WiFi driver from the staging +tree was replaced by a totally different one written from scratch. + +Why do later versions have to be "compiled with a similar configuration"? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Because the Linux kernel developers sometimes integrate changes known to cause +regressions, but make them optional and disable them in the kernel's default +configuration. This trick allows progress, as the "no regressions" rule +otherwise would lead to stagnation. + +Consider for example a new security feature blocking access to some kernel +interfaces often abused by malware, which at the same time are required to run a +few rarely used applications. The outlined approach makes both camps happy: +people using these applications can leave the new security feature off, while +everyone else can enable it without running into trouble. + +How to create a configuration similar to the one of an older kernel? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Start your machine with a known-good kernel and configure the newer Linux +version with ``make olddefconfig``. This makes the kernel's build scripts pick +up the configuration file (the ".config" file) from the running kernel as base +for the new one you are about to compile; afterwards they set all new +configuration options to their default value, which should disable new features +that might cause regressions. + +Can I report a regression I found with pre-compiled vanilla kernels? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You need to ensure the newer kernel was compiled with a similar configuration +file as the older one (see above), as those that built them might have enabled +some known-to-be incompatible feature for the newer kernel. If in doubt, report +the matter to the kernel's provider and ask for advice. + + +More about regression tracking with "regzbot" +--------------------------------------------- + +What is regression tracking and why should I care about it? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Rules like "no regressions" need someone to ensure they are followed, otherwise +they are broken either accidentally or on purpose. History has shown this to be +true for Linux kernel development as well. That's why Thorsten Leemhuis, the +Linux Kernel's regression tracker, and some people try to ensure all regression +are fixed by keeping an eye on them until they are resolved. Neither of them are +paid for this, that's why the work is done on a best effort basis. + +Why and how are Linux kernel regressions tracked using a bot? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Tracking regressions completely manually has proven to be quite hard due to the +distributed and loosely structured nature of Linux kernel development process. +That's why the Linux kernel's regression tracker developed regzbot to facilitate +the work, with the long term goal to automate regression tracking as much as +possible for everyone involved. + +Regzbot works by watching for replies to reports of tracked regressions. +Additionally, it's looking out for posted or committed patches referencing such +reports with "Link:" tags; replies to such patch postings are tracked as well. +Combined this data provides good insights into the current state of the fixing +process. + +How to see which regressions regzbot tracks currently? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Check out `regzbot's web-interface `_. + +What kind of issues are supposed to be tracked by regzbot? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The bot is meant to track regressions, hence please don't involve regzbot for +regular issues. But it's okay for the Linux kernel's regression tracker if you +involve regzbot to track severe issues, like reports about hangs, corrupted +data, or internal errors (Panic, Oops, BUG(), warning, ...). + +How to change aspects of a tracked regression? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +By using a 'regzbot command' in a direct or indirect reply to the mail with the +report. The easiest way to do that: find the report in your "Sent" folder or the +mailing list archive and reply to it using your mailer's "Reply-all" function. +In that mail, use one of the following commands in a stand-alone paragraph (IOW: +use blank lines to separate one or multiple of these commands from the rest of +the mail's text). + + * Update when the regression started to happen, for example after performing a + bisection:: + + #regzbot introduced: 1f2e3d4c5d + + * Set or update the title:: + + #regzbot title: foo + + * Monitor a discussion or bugzilla.kernel.org ticket where additions aspects of + the issue or a fix are discussed::: + + #regzbot monitor: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/ + #regzbot monitor: https://bugzilla.kernel.org/show_bug.cgi?id=123456789 + + * Point to a place with further details of interest, like a mailing list post + or a ticket in a bug tracker that are slightly related, but about a different + topic:: + + #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789 + + * Mark a regression as invalid:: + + #regzbot invalid: wasn't a regression, problem has always existed + +Regzbot supports a few other commands primarily used by developers or people +tracking regressions. They and more details about the aforementioned regzbot +commands can be found in the `getting started guide +`_ and +the `reference documentation `_ +for regzbot. + +.. + end-of-content +.. + This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top + of the file. If you want to distribute this text under CC-BY-4.0 only, + please use "The Linux kernel developers" for author attribution and link + this as source: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-regressions.rst +.. + Note: Only the content of this RST file as found in the Linux kernel sources + is available under CC-BY-4.0, as versions of this text that were processed + (for example by the kernel's build system) might contain content taken from + files which use a more restrictive license. diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst new file mode 100644 index 000000000000..e1102a3207e3 --- /dev/null +++ b/Documentation/process/handling-regressions.rst @@ -0,0 +1,659 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0) +.. See the bottom of this file for additional redistribution information. + +Handling regressions +++++++++++++++++++++ + +*We don't cause regressions* -- this document describes what this "first rule of +Linux kernel development" means in practice for developers. It complements +Documentation/admin-guide/reporting-regressions.rst, which covers the topic from a +user's point of view; if you never read that text, go and at least skim over it +before continuing here. + +The important bits (aka "The TL;DR") +==================================== + +#. Ensure subscribers of the `regression mailing list `_ + (regressions@lists.linux.dev) quickly become aware of any new regression + report: + + * When receiving a mailed report that did not CC the list, bring it into the + loop by immediately sending at least a brief "Reply-all" with the list + CCed. + + * Forward or bounce any reports submitted in bug trackers to the list. + +#. Make the Linux kernel regression tracking bot "regzbot" track the issue (this + is optional, but recommended): + + * For mailed reports, check if the reporter included a line like ``#regzbot + introduced v5.13..v5.14-rc1``. If not, send a reply (with the regressions + list in CC) containing a paragraph like the following, which tells regzbot + when the issue started to happen:: + + #regzbot ^introduced 1f2e3d4c5b6a + + * When forwarding reports from a bug tracker to the regressions list (see + above), include a paragraph like the following:: + + #regzbot introduced: v5.13..v5.14-rc1 + #regzbot from: Some N. Ice Human + #regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789 + +#. When submitting fixes for regressions, add "Link:" tags to the patch + description pointing to all places where the issue was reported, as + mandated by Documentation/process/submitting-patches.rst and + :ref:`Documentation/process/5.Posting.rst `. + + +All the details on Linux kernel regressions relevant for developers +=================================================================== + + +The important basics in more detail +----------------------------------- + + +What to do when receiving regression reports +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Ensure the Linux kernel's regression tracker and others subscribers of the +`regression mailing list `_ +(regressions@lists.linux.dev) become aware of any newly reported regression: + + * When you receive a report by mail that did not CC the list, immediately bring + it into the loop by sending at least a brief "Reply-all" with the list CCed; + try to ensure it gets CCed again in case you reply to a reply that omitted + the list. + + * If a report submitted in a bug tracker hits your Inbox, forward or bounce it + to the list. Consider checking the list archives beforehand, if the reporter + already forwarded the report as instructed by + Documentation/admin-guide/reporting-issues.rst. + +When doing either, consider making the Linux kernel regression tracking bot +"regzbot" immediately start tracking the issue: + + * For mailed reports, check if the reporter included a "regzbot command" like + ``#regzbot introduced 1f2e3d4c5b6a``. If not, send a reply (with the + regressions list in CC) with a paragraph like the following::: + + #regzbot ^introduced: v5.13..v5.14-rc1 + + This tells regzbot the version range in which the issue started to happen; + you can specify a range using commit-ids as well or state a single commit-id + in case the reporter bisected the culprit. + + Note the caret (^) before the "introduced": it tells regzbot to treat the + parent mail (the one you reply to) as the initial report for the regression + you want to see tracked; that's important, as regzbot will later look out + for patches with "Link:" tags pointing to the report in the archives on + lore.kernel.org. + + * When forwarding a regressions reported to a bug tracker, include a paragraph + with these regzbot commands:: + + #regzbot introduced: 1f2e3d4c5b6a + #regzbot from: Some N. Ice Human + #regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789 + + Regzbot will then automatically associate patches with the report that + contain "Link:" tags pointing to your mail or the mentioned ticket. + +What's important when fixing regressions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You don't need to do anything special when submitting fixes for regression, just +remember to do what Documentation/process/submitting-patches.rst, +:ref:`Documentation/process/5.Posting.rst `, and +Documentation/process/stable-kernel-rules.rst already explain in more detail: + + * Point to all places where the issue was reported using "Link:" tags:: + + Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/ + Link: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890 + + * Add a "Fixes:" tag to specify the commit causing the regression. + + * If the culprit was merged in an earlier development cycle, explicitly mark + the fix for backporting using the ``Cc: stable@vger.kernel.org`` tag. + +All this is expected from you and important when it comes to regression, as +these tags are of great value for everyone (you included) that might be looking +into the issue weeks, months, or years later. These tags are also crucial for +tools and scripts used by other kernel developers or Linux distributions; one of +these tools is regzbot, which heavily relies on the "Link:" tags to associate +reports for regression with changes resolving them. + + +More aspects regarding regressions developers should be aware of +---------------------------------------------------------------- + + +How to deal with changes where a risk of regression is known +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Evaluate how big the risk of regressions is, for example by performing a code +search in Linux distributions and Git forges. Also consider asking other +developers or projects likely to be affected to evaluate or even test the +proposed change; if problems surface, maybe some solution acceptable for all +can be found. + +If the risk of regressions in the end seems to be relatively small, go ahead +with the change, but let all involved parties know about the risk. Hence, make +sure your patch description makes this aspect obvious. Once the change is +merged, tell the Linux kernel's regression tracker and the regressions mailing +list about the risk, so everyone has the change on the radar in case reports +trickle in. Depending on the risk, you also might want to ask the subsystem +maintainer to mention the issue in his mainline pull request. + +What else is there to known about regressions? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Check out Documentation/admin-guide/reporting-regressions.rst, it covers a lot +of other aspects you want might want to be aware of: + + * the purpose of the "no regressions rule" + + * what issues actually qualify as regression + + * who's in charge for finding the root cause of a regression + + * how to handle tricky situations, e.g. when a regression is caused by a + security fix or when fixing a regression might cause another one + +Whom to ask for advice when it comes to regressions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Send a mail to the regressions mailing list (regressions@lists.linux.dev) while +CCing the Linux kernel's regression tracker (regressions@leemhuis.info); if the +issue might better be dealt with in private, feel free to omit the list. + + +More about regression tracking and regzbot +------------------------------------------ + + +Why the Linux kernel has a regression tracker, and why is regzbot used? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Rules like "no regressions" need someone to ensure they are followed, otherwise +they are broken either accidentally or on purpose. History has shown this to be +true for the Linux kernel as well. That's why Thorsten Leemhuis volunteered to +keep an eye on things as the Linux kernel's regression tracker, who's +occasionally helped by other people. Neither of them are paid to do this, +that's why regression tracking is done on a best effort basis. + +Earlier attempts to manually track regressions have shown it's an exhausting and +frustrating work, which is why they were abandoned after a while. To prevent +this from happening again, Thorsten developed regzbot to facilitate the work, +with the long term goal to automate regression tracking as much as possible for +everyone involved. + +How does regression tracking work with regzbot? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The bot watches for replies to reports of tracked regressions. Additionally, +it's looking out for posted or committed patches referencing such reports +with "Link:" tags; replies to such patch postings are tracked as well. +Combined this data provides good insights into the current state of the fixing +process. + +Regzbot tries to do its job with as little overhead as possible for both +reporters and developers. In fact, only reporters are burdened with an extra +duty: they need to tell regzbot about the regression report using the ``#regzbot +introduced`` command outlined above; if they don't do that, someone else can +take care of that using ``#regzbot ^introduced``. + +For developers there normally is no extra work involved, they just need to make +sure to do something that was expected long before regzbot came to light: add +"Link:" tags to the patch description pointing to all reports about the issue +fixed. + +Do I have to use regzbot? +~~~~~~~~~~~~~~~~~~~~~~~~~ + +It's in the interest of everyone if you do, as kernel maintainers like Linus +Torvalds partly rely on regzbot's tracking in their work -- for example when +deciding to release a new version or extend the development phase. For this they +need to be aware of all unfixed regression; to do that, Linus is known to look +into the weekly reports sent by regzbot. + +Do I have to tell regzbot about every regression I stumble upon? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Ideally yes: we are all humans and easily forget problems when something more +important unexpectedly comes up -- for example a bigger problem in the Linux +kernel or something in real life that's keeping us away from keyboards for a +while. Hence, it's best to tell regzbot about every regression, except when you +immediately write a fix and commit it to a tree regularly merged to the affected +kernel series. + +How to see which regressions regzbot tracks currently? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Check `regzbot's web-interface `_ +for the latest info; alternatively, `search for the latest regression report +`_, +which regzbot normally sends out once a week on Sunday evening (UTC), which is a +few hours before Linus usually publishes new (pre-)releases. + +What places is regzbot monitoring? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Regzbot is watching the most important Linux mailing lists as well as the git +repositories of linux-next, mainline, and stable/longterm. + +What kind of issues are supposed to be tracked by regzbot? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The bot is meant to track regressions, hence please don't involve regzbot for +regular issues. But it's okay for the Linux kernel's regression tracker if you +use regzbot to track severe issues, like reports about hangs, corrupted data, +or internal errors (Panic, Oops, BUG(), warning, ...). + +Can I add regressions found by CI systems to regzbot's tracking? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Feel free to do so, if the particular regression likely has impact on practical +use cases and thus might be noticed by users; hence, please don't involve +regzbot for theoretical regressions unlikely to show themselves in real world +usage. + +How to interact with regzbot? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +By using a 'regzbot command' in a direct or indirect reply to the mail with the +regression report. These commands need to be in their own paragraph (IOW: they +need to be separated from the rest of the mail using blank lines). + +One such command is ``#regzbot introduced ``, which makes +regzbot consider your mail as a regressions report added to the tracking, as +already described above; ``#regzbot ^introduced `` is another +such command, which makes regzbot consider the parent mail as a report for a +regression which it starts to track. + +Once one of those two commands has been utilized, other regzbot commands can be +used in direct or indirect replies to the report. You can write them below one +of the `introduced` commands or in replies to the mail that used one of them +or itself is a reply to that mail: + + * Set or update the title:: + + #regzbot title: foo + + * Monitor a discussion or bugzilla.kernel.org ticket where additions aspects of + the issue or a fix are discussed -- for example the posting of a patch fixing + the regression:: + + #regzbot monitor: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/ + + Monitoring only works for lore.kernel.org and bugzilla.kernel.org; regzbot + will consider all messages in that thread or ticket as related to the fixing + process. + + * Point to a place with further details of interest, like a mailing list post + or a ticket in a bug tracker that are slightly related, but about a different + topic:: + + #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789 + + * Mark a regression as fixed by a commit that is heading upstream or already + landed:: + + #regzbot fixed-by: 1f2e3d4c5d + + * Mark a regression as a duplicate of another one already tracked by regzbot:: + + #regzbot dup-of: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/ + + * Mark a regression as invalid:: + + #regzbot invalid: wasn't a regression, problem has always existed + +Is there more to tell about regzbot and its commands? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +More detailed and up-to-date information about the Linux +kernel's regression tracking bot can be found on its +`project page `_, which among others +contains a `getting started guide `_ +and `reference documentation `_ +which both cover more details than the above section. + +Quotes from Linus about regression +---------------------------------- + +Find below a few real life examples of how Linus Torvalds expects regressions to +be handled: + + * From `2017-10-26 (1/2) + `_:: + + If you break existing user space setups THAT IS A REGRESSION. + + It's not ok to say "but we'll fix the user space setup". + + Really. NOT OK. + + [...] + + The first rule is: + + - we don't cause regressions + + and the corollary is that when regressions *do* occur, we admit to + them and fix them, instead of blaming user space. + + The fact that you have apparently been denying the regression now for + three weeks means that I will revert, and I will stop pulling apparmor + requests until the people involved understand how kernel development + is done. + + * From `2017-10-26 (2/2) + `_:: + + People should basically always feel like they can update their kernel + and simply not have to worry about it. + + I refuse to introduce "you can only update the kernel if you also + update that other program" kind of limitations. If the kernel used to + work for you, the rule is that it continues to work for you. + + There have been exceptions, but they are few and far between, and they + generally have some major and fundamental reasons for having happened, + that were basically entirely unavoidable, and people _tried_hard_ to + avoid them. Maybe we can't practically support the hardware any more + after it is decades old and nobody uses it with modern kernels any + more. Maybe there's a serious security issue with how we did things, + and people actually depended on that fundamentally broken model. Maybe + there was some fundamental other breakage that just _had_ to have a + flag day for very core and fundamental reasons. + + And notice that this is very much about *breaking* peoples environments. + + Behavioral changes happen, and maybe we don't even support some + feature any more. There's a number of fields in /proc//stat that + are printed out as zeroes, simply because they don't even *exist* in + the kernel any more, or because showing them was a mistake (typically + an information leak). But the numbers got replaced by zeroes, so that + the code that used to parse the fields still works. The user might not + see everything they used to see, and so behavior is clearly different, + but things still _work_, even if they might no longer show sensitive + (or no longer relevant) information. + + But if something actually breaks, then the change must get fixed or + reverted. And it gets fixed in the *kernel*. Not by saying "well, fix + your user space then". It was a kernel change that exposed the + problem, it needs to be the kernel that corrects for it, because we + have a "upgrade in place" model. We don't have a "upgrade with new + user space". + + And I seriously will refuse to take code from people who do not + understand and honor this very simple rule. + + This rule is also not going to change. + + And yes, I realize that the kernel is "special" in this respect. I'm + proud of it. + + I have seen, and can point to, lots of projects that go "We need to + break that use case in order to make progress" or "you relied on + undocumented behavior, it sucks to be you" or "there's a better way to + do what you want to do, and you have to change to that new better + way", and I simply don't think that's acceptable outside of very early + alpha releases that have experimental users that know what they signed + up for. The kernel hasn't been in that situation for the last two + decades. + + We do API breakage _inside_ the kernel all the time. We will fix + internal problems by saying "you now need to do XYZ", but then it's + about internal kernel API's, and the people who do that then also + obviously have to fix up all the in-kernel users of that API. Nobody + can say "I now broke the API you used, and now _you_ need to fix it + up". Whoever broke something gets to fix it too. + + And we simply do not break user space. + + * From `2020-05-21 + `_:: + + The rules about regressions have never been about any kind of + documented behavior, or where the code lives. + + The rules about regressions are always about "breaks user workflow". + + Users are literally the _only_ thing that matters. + + No amount of "you shouldn't have used this" or "that behavior was + undefined, it's your own fault your app broke" or "that used to work + simply because of a kernel bug" is at all relevant. + + Now, reality is never entirely black-and-white. So we've had things + like "serious security issue" etc that just forces us to make changes + that may break user space. But even then the rule is that we don't + really have other options that would allow things to continue. + + And obviously, if users take years to even notice that something + broke, or if we have sane ways to work around the breakage that + doesn't make for too much trouble for users (ie "ok, there are a + handful of users, and they can use a kernel command line to work + around it" kind of things) we've also been a bit less strict. + + But no, "that was documented to be broken" (whether it's because the + code was in staging or because the man-page said something else) is + irrelevant. If staging code is so useful that people end up using it, + that means that it's basically regular kernel code with a flag saying + "please clean this up". + + The other side of the coin is that people who talk about "API + stability" are entirely wrong. API's don't matter either. You can make + any changes to an API you like - as long as nobody notices. + + Again, the regression rule is not about documentation, not about + API's, and not about the phase of the moon. + + It's entirely about "we caused problems for user space that used to work". + + * From `2017-11-05 + `_:: + + And our regression rule has never been "behavior doesn't change". + That would mean that we could never make any changes at all. + + For example, we do things like add new error handling etc all the + time, which we then sometimes even add tests for in our kselftest + directory. + + So clearly behavior changes all the time and we don't consider that a + regression per se. + + The rule for a regression for the kernel is that some real user + workflow breaks. Not some test. Not a "look, I used to be able to do + X, now I can't". + + * From `2018-08-03 + `_:: + + YOU ARE MISSING THE #1 KERNEL RULE. + + We do not regress, and we do not regress exactly because your are 100% wrong. + + And the reason you state for your opinion is in fact exactly *WHY* you + are wrong. + + Your "good reasons" are pure and utter garbage. + + The whole point of "we do not regress" is so that people can upgrade + the kernel and never have to worry about it. + + > Kernel had a bug which has been fixed + + That is *ENTIRELY* immaterial. + + Guys, whether something was buggy or not DOES NOT MATTER. + + Why? + + Bugs happen. That's a fact of life. Arguing that "we had to break + something because we were fixing a bug" is completely insane. We fix + tens of bugs every single day, thinking that "fixing a bug" means that + we can break something is simply NOT TRUE. + + So bugs simply aren't even relevant to the discussion. They happen, + they get found, they get fixed, and it has nothing to do with "we + break users". + + Because the only thing that matters IS THE USER. + + How hard is that to understand? + + Anybody who uses "but it was buggy" as an argument is entirely missing + the point. As far as the USER was concerned, it wasn't buggy - it + worked for him/her. + + Maybe it worked *because* the user had taken the bug into account, + maybe it worked because the user didn't notice - again, it doesn't + matter. It worked for the user. + + Breaking a user workflow for a "bug" is absolutely the WORST reason + for breakage you can imagine. + + It's basically saying "I took something that worked, and I broke it, + but now it's better". Do you not see how f*cking insane that statement + is? + + And without users, your program is not a program, it's a pointless + piece of code that you might as well throw away. + + Seriously. This is *why* the #1 rule for kernel development is "we + don't break users". Because "I fixed a bug" is absolutely NOT AN + ARGUMENT if that bug fix broke a user setup. You actually introduced a + MUCH BIGGER bug by "fixing" something that the user clearly didn't + even care about. + + And dammit, we upgrade the kernel ALL THE TIME without upgrading any + other programs at all. It is absolutely required, because flag-days + and dependencies are horribly bad. + + And it is also required simply because I as a kernel developer do not + upgrade random other tools that I don't even care about as I develop + the kernel, and I want any of my users to feel safe doing the same + time. + + So no. Your rule is COMPLETELY wrong. If you cannot upgrade a kernel + without upgrading some other random binary, then we have a problem. + + * From `2021-06-05 + `_:: + + THERE ARE NO VALID ARGUMENTS FOR REGRESSIONS. + + Honestly, security people need to understand that "not working" is not + a success case of security. It's a failure case. + + Yes, "not working" may be secure. But security in that case is *pointless*. + + * From `2011-05-06 (1/3) + `_:: + + Binary compatibility is more important. + + And if binaries don't use the interface to parse the format (or just + parse it wrongly - see the fairly recent example of adding uuid's to + /proc/self/mountinfo), then it's a regression. + + And regressions get reverted, unless there are security issues or + similar that makes us go "Oh Gods, we really have to break things". + + I don't understand why this simple logic is so hard for some kernel + developers to understand. Reality matters. Your personal wishes matter + NOT AT ALL. + + If you made an interface that can be used without parsing the + interface description, then we're stuck with the interface. Theory + simply doesn't matter. + + You could help fix the tools, and try to avoid the compatibility + issues that way. There aren't that many of them. + + From `2011-05-06 (2/3) + `_:: + + it's clearly NOT an internal tracepoint. By definition. It's being + used by powertop. + + From `2011-05-06 (3/3) + `_:: + + We have programs that use that ABI and thus it's a regression if they break. + + * From `2012-07-06 `_:: + + > Now this got me wondering if Debian _unstable_ actually qualifies as a + > standard distro userspace. + + Oh, if the kernel breaks some standard user space, that counts. Tons + of people run Debian unstable + + * From `2019-09-15 + `_:: + + One _particularly_ last-minute revert is the top-most commit (ignoring + the version change itself) done just before the release, and while + it's very annoying, it's perhaps also instructive. + + What's instructive about it is that I reverted a commit that wasn't + actually buggy. In fact, it was doing exactly what it set out to do, + and did it very well. In fact it did it _so_ well that the much + improved IO patterns it caused then ended up revealing a user-visible + regression due to a real bug in a completely unrelated area. + + The actual details of that regression are not the reason I point that + revert out as instructive, though. It's more that it's an instructive + example of what counts as a regression, and what the whole "no + regressions" kernel rule means. The reverted commit didn't change any + API's, and it didn't introduce any new bugs. But it ended up exposing + another problem, and as such caused a kernel upgrade to fail for a + user. So it got reverted. + + The point here being that we revert based on user-reported _behavior_, + not based on some "it changes the ABI" or "it caused a bug" concept. + The problem was really pre-existing, and it just didn't happen to + trigger before. The better IO patterns introduced by the change just + happened to expose an old bug, and people had grown to depend on the + previously benign behavior of that old issue. + + And never fear, we'll re-introduce the fix that improved on the IO + patterns once we've decided just how to handle the fact that we had a + bad interaction with an interface that people had then just happened + to rely on incidental behavior for before. It's just that we'll have + to hash through how to do that (there are no less than three different + patches by three different developers being discussed, and there might + be more coming...). In the meantime, I reverted the thing that exposed + the problem to users for this release, even if I hope it will be + re-introduced (perhaps even backported as a stable patch) once we have + consensus about the issue it exposed. + + Take-away from the whole thing: it's not about whether you change the + kernel-userspace ABI, or fix a bug, or about whether the old code + "should never have worked in the first place". It's about whether + something breaks existing users' workflow. + + Anyway, that was my little aside on the whole regression thing. Since + it's that "first rule of kernel programming", I felt it is perhaps + worth just bringing it up every once in a while + +.. + end-of-content +.. + This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top + of the file. If you want to distribute this text under CC-BY-4.0 only, + please use "The Linux kernel developers" for author attribution and link + this as source: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/process/handling-regressions.rst +.. + Note: Only the content of this RST file as found in the Linux kernel sources + is available under CC-BY-4.0, as versions of this text that were processed + (for example by the kernel's build system) might contain content taken from + files which use a more restrictive license. diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index 9f1b88492bb3..428e39074f61 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -25,6 +25,7 @@ Below are the essential guides that every developer should read. code-of-conduct-interpretation development-process submitting-patches + handling-regressions programming-language coding-style maintainer-handbooks -- cgit From d2b40ba2cce207ecea8a740f71e113f03cc75fd5 Mon Sep 17 00:00:00 2001 From: Thorsten Leemhuis Date: Wed, 16 Feb 2022 07:51:34 +0100 Subject: docs: *-regressions.rst: explain how quickly issues should be handled Add a section with a few rules of thumb about how quickly developers should address regressions to Documentation/process/handling-regressions.rst; additionally, add a short paragraph about this to the companion document Documentation/admin-guide/reporting-regressions.rst as well. The rules of thumb were written after studying the quotes from Linus found in handling-regressions.rst and especially influenced by statements like "Users are literally the _only_ thing that matters" and "without users, your program is not a program, it's a pointless piece of code that you might as well throw away". The author interpreted those in perspective to how the various Linux kernel series are maintained currently and what those practices might mean for users running into a regression on a small or big kernel update. That for example lead to the paragraph starting with "Aim to get fixes for regressions mainlined within one week after identifying the culprit, if the regression was introduced in a stable/longterm release or the devel cycle for the latest mainline release". Some might see this as pretty high bar, but on the other hand something like that is needed to not leave users out in the cold for too long -- which can quickly happen when updating to the latest stable series, as the previous one is normally stamped "End of Life" about three or four weeks after a new mainline release. This makes a lot of users switch during this timeframe. Any of them thus risk running into regressions not promptly fixed; even worse, once the previous stable series is EOLed for real, users that face a regression might be left with only three options: (1) continue running an outdated and thus potentially insecure kernel version from an abandoned stable series (2) run the kernel with the regression (3) downgrade to an earlier longterm series still supported This is better avoided, as (1) puts users and their data in danger, (2) will only be possible if it's a minor regression that doesn't interfere with booting or serious usage, and (3) might be regression itself or impossible on the particular machine, as the users might require drivers or features only introduced after the latest longterm series branched of. In the end this lead to the aforementioned "Aim to fix regression within one week" part. It's also the reason for the "Try to resolve any regressions introduced in the current development cycle before its end.". Signed-off-by: Thorsten Leemhuis CC: Linus Torvalds Acked-by: Greg Kroah-Hartman Reviewed-by: Lukas Bulwahn Link: https://lore.kernel.org/r/a7b717b52c0d54cdec9b6daf56ed6669feddee2c.1644994117.git.linux@leemhuis.info Signed-off-by: Jonathan Corbet --- .../admin-guide/reporting-regressions.rst | 12 +++ Documentation/process/handling-regressions.rst | 87 ++++++++++++++++++++++ 2 files changed, 99 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/reporting-regressions.rst b/Documentation/admin-guide/reporting-regressions.rst index 6fbd24ceb3bf..d8adccdae23f 100644 --- a/Documentation/admin-guide/reporting-regressions.rst +++ b/Documentation/admin-guide/reporting-regressions.rst @@ -214,6 +214,18 @@ your report on the radar of these people by CCing or forwarding each report to the regressions mailing list, ideally with a "regzbot command" in your mail to get it tracked immediately. +How quickly are regressions normally fixed? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Developers should fix any reported regression as quickly as possible, to provide +affected users with a solution in a timely manner and prevent more users from +running into the issue; nevertheless developers need to take enough time and +care to ensure regression fixes do not cause additional damage. + +The answer thus depends on various factors like the impact of a regression, its +age, or the Linux series in which it occurs. In the end though, most regressions +should be fixed within two weeks. + Is it a regression, if the issue can be avoided by updating some software? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst index e1102a3207e3..abb741b1aeee 100644 --- a/Documentation/process/handling-regressions.rst +++ b/Documentation/process/handling-regressions.rst @@ -45,6 +45,10 @@ The important bits (aka "The TL;DR") mandated by Documentation/process/submitting-patches.rst and :ref:`Documentation/process/5.Posting.rst `. +#. Try to fix regressions quickly once the culprit has been identified; fixes + for most regressions should be merged within two weeks, but some need to be + resolved within two or three days. + All the details on Linux kernel regressions relevant for developers =================================================================== @@ -125,6 +129,89 @@ tools and scripts used by other kernel developers or Linux distributions; one of these tools is regzbot, which heavily relies on the "Link:" tags to associate reports for regression with changes resolving them. +Prioritize work on fixing regressions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You should fix any reported regression as quickly as possible, to provide +affected users with a solution in a timely manner and prevent more users from +running into the issue; nevertheless developers need to take enough time and +care to ensure regression fixes do not cause additional damage. + +In the end though, developers should give their best to prevent users from +running into situations where a regression leaves them only three options: "run +a kernel with a regression that seriously impacts usage", "continue running an +outdated and thus potentially insecure kernel version for more than two weeks +after a regression's culprit was identified", and "downgrade to a still +supported kernel series that lack required features". + +How to realize this depends a lot on the situation. Here are a few rules of +thumb for you, in order or importance: + + * Prioritize work on handling regression reports and fixing regression over all + other Linux kernel work, unless the latter concerns acute security issues or + bugs causing data loss or damage. + + * Always consider reverting the culprit commits and reapplying them later + together with necessary fixes, as this might be the least dangerous and + quickest way to fix a regression. + + * Developers should handle regressions in all supported kernel series, but are + free to delegate the work to the stable team, if the issue probably at no + point in time occurred with mainline. + + * Try to resolve any regressions introduced in the current development before + its end. If you fear a fix might be too risky to apply only days before a new + mainline release, let Linus decide: submit the fix separately to him as soon + as possible with the explanation of the situation. He then can make a call + and postpone the release if necessary, for example if multiple such changes + show up in his inbox. + + * Address regressions in stable, longterm, or proper mainline releases with + more urgency than regressions in mainline pre-releases. That changes after + the release of the fifth pre-release, aka "-rc5": mainline then becomes as + important, to ensure all the improvements and fixes are ideally tested + together for at least one week before Linus releases a new mainline version. + + * Fix regressions within two or three days, if they are critical for some + reason -- for example, if the issue is likely to affect many users of the + kernel series in question on all or certain architectures. Note, this + includes mainline, as issues like compile errors otherwise might prevent many + testers or continuous integration systems from testing the series. + + * Aim to fix regressions within one week after the culprit was identified, if + the issue was introduced in either: + + * a recent stable/longterm release + + * the development cycle of the latest proper mainline release + + In the latter case (say Linux v5.14), try to address regressions even + quicker, if the stable series for the predecessor (v5.13) will be abandoned + soon or already was stamped "End-of-Life" (EOL) -- this usually happens about + three to four weeks after a new mainline release. + + * Try to fix all other regressions within two weeks after the culprit was + found. Two or three additional weeks are acceptable for performance + regressions and other issues which are annoying, but don't prevent anyone + from running Linux (unless it's an issue in the current development cycle, + as those should ideally be addressed before the release). A few weeks in + total are acceptable if a regression can only be fixed with a risky change + and at the same time is affecting only a few users; as much time is + also okay if the regression is already present in the second newest longterm + kernel series. + +Note: The aforementioned time frames for resolving regressions are meant to +include getting the fix tested, reviewed, and merged into mainline, ideally with +the fix being in linux-next at least briefly. This leads to delays you need to +account for. + +Subsystem maintainers are expected to assist in reaching those periods by doing +timely reviews and quick handling of accepted patches. They thus might have to +send git-pull requests earlier or more often than usual; depending on the fix, +it might even be acceptable to skip testing in linux-next. Especially fixes for +regressions in stable and longterm kernels need to be handled quickly, as fixes +need to be merged in mainline before they can be backported to older series. + More aspects regarding regressions developers should be aware of ---------------------------------------------------------------- -- cgit From 247097e2bbff4201b85eee8de4f31b4065877f67 Mon Sep 17 00:00:00 2001 From: Thorsten Leemhuis Date: Wed, 16 Feb 2022 07:51:35 +0100 Subject: docs: reporting-issues.rst: link new document about regressions Make Documentation/admin-guide/reporting-issues.rst point to the newly created document about regressions (Documentation/admin-guide/regressions-regressions.rst). This allows to shorten a few explanations the new document describes better and in more detail. While at it move the copyright hint to the end of the file and remove quotes around links to other places in the documentation. Both issues came up during the review of the new documents about regressions. Signed-off-by: Thorsten Leemhuis Link: https://lore.kernel.org/r/f20114eaddc356a8c79dd62812a6c7f4ca5d87b9.1644994117.git.linux@leemhuis.info Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/reporting-issues.rst | 73 +++++++++++++------------- 1 file changed, 36 insertions(+), 37 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst index d7ac13f789cc..ec62151fe672 100644 --- a/Documentation/admin-guide/reporting-issues.rst +++ b/Documentation/admin-guide/reporting-issues.rst @@ -1,14 +1,5 @@ .. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0) -.. - If you want to distribute this text under CC-BY-4.0 only, please use 'The - Linux kernel developers' for author attribution and link this as source: - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst -.. - Note: Only the content of this RST file as found in the Linux kernel sources - is available under CC-BY-4.0, as versions of this text that were processed - (for example by the kernel's build system) might contain content taken from - files which use a more restrictive license. - +.. See the bottom of this file for additional redistribution information. Reporting issues ++++++++++++++++ @@ -395,22 +386,16 @@ fixed as soon as possible, hence there are 'issues of high priority' that get handled slightly differently in the reporting process. Three type of cases qualify: regressions, security issues, and really severe problems. -You deal with a 'regression' if something that worked with an older version of -the Linux kernel does not work with a newer one or somehow works worse with it. -It thus is a regression when a WiFi driver that did a fine job with Linux 5.7 -somehow misbehaves with 5.8 or doesn't work at all. It's also a regression if -an application shows erratic behavior with a newer kernel, which might happen -due to incompatible changes in the interface between the kernel and the -userland (like procfs and sysfs). Significantly reduced performance or -increased power consumption also qualify as regression. But keep in mind: the -new kernel needs to be built with a configuration that is similar to the one -from the old kernel (see below how to achieve that). That's because the kernel -developers sometimes can not avoid incompatibilities when implementing new -features; but to avoid regressions such features have to be enabled explicitly -during build time configuration. +You deal with a regression if some application or practical use case running +fine with one Linux kernel works worse or not at all with a newer version +compiled using a similar configuration. The document +Documentation/admin-guide/reporting-regressions.rst explains this in more +detail. It also provides a good deal of other information about regressions you +might want to be aware of; it for example explains how to add your issue to the +list of tracked regressions, to ensure it won't fall through the cracks. What qualifies as security issue is left to your judgment. Consider reading -'Documentation/admin-guide/security-bugs.rst' before proceeding, as it +Documentation/admin-guide/security-bugs.rst before proceeding, as it provides additional details how to best handle security issues. An issue is a 'really severe problem' when something totally unacceptably bad @@ -517,7 +502,7 @@ line starting with 'CPU:'. It should end with 'Not tainted' if the kernel was not tainted when it noticed the problem; it was tainted if you see 'Tainted:' followed by a few spaces and some letters. -If your kernel is tainted, study 'Documentation/admin-guide/tainted-kernels.rst' +If your kernel is tainted, study Documentation/admin-guide/tainted-kernels.rst to find out why. Try to eliminate the reason. Often it's caused by one these three things: @@ -1043,7 +1028,7 @@ down the culprit, as maintainers often won't have the time or setup at hand to reproduce it themselves. To find the change there is a process called 'bisection' which the document -'Documentation/admin-guide/bug-bisect.rst' describes in detail. That process +Documentation/admin-guide/bug-bisect.rst describes in detail. That process will often require you to build about ten to twenty kernel images, trying to reproduce the issue with each of them before building the next. Yes, that takes some time, but don't worry, it works a lot quicker than most people assume. @@ -1073,10 +1058,11 @@ When dealing with regressions make sure the issue you face is really caused by the kernel and not by something else, as outlined above already. In the whole process keep in mind: an issue only qualifies as regression if the -older and the newer kernel got built with a similar configuration. The best way -to archive this: copy the configuration file (``.config``) from the old working -kernel freshly to each newer kernel version you try. Afterwards run ``make -olddefconfig`` to adjust it for the needs of the new version. +older and the newer kernel got built with a similar configuration. This can be +achieved by using ``make olddefconfig``, as explained in more detail by +Documentation/admin-guide/reporting-regressions.rst; that document also +provides a good deal of other information about regressions you might want to be +aware of. Write and send the report @@ -1283,7 +1269,7 @@ them when sending the report by mail. If you filed it in a bug tracker, forward the report's text to these addresses; but on top of it put a small note where you mention that you filed it with a link to the ticket. -See 'Documentation/admin-guide/security-bugs.rst' for more information. +See Documentation/admin-guide/security-bugs.rst for more information. Duties after the report went out @@ -1571,7 +1557,7 @@ Once your report is out your might get asked to do a proper one, as it allows to pinpoint the exact change that causes the issue (which then can easily get reverted to fix the issue quickly). Hence consider to do a proper bisection right away if time permits. See the section 'Special care for regressions' and -the document 'Documentation/admin-guide/bug-bisect.rst' for details how to +the document Documentation/admin-guide/bug-bisect.rst for details how to perform one. In case of a successful bisection add the author of the culprit to the recipients; also CC everyone in the signed-off-by chain, which you find at the end of its commit message. @@ -1594,7 +1580,7 @@ Some fixes are too complex Even small and seemingly obvious code-changes sometimes introduce new and totally unexpected problems. The maintainers of the stable and longterm kernels are very aware of that and thus only apply changes to these kernels that are -within rules outlined in 'Documentation/process/stable-kernel-rules.rst'. +within rules outlined in Documentation/process/stable-kernel-rules.rst. Complex or risky changes for example do not qualify and thus only get applied to mainline. Other fixes are easy to get backported to the newest stable and @@ -1756,10 +1742,23 @@ art will lay some groundwork to improve the situation over time. .. - This text is maintained by Thorsten Leemhuis . If you - spot a typo or small mistake, feel free to let him know directly and he'll - fix it. You are free to do the same in a mostly informal way if you want - to contribute changes to the text, but for copyright reasons please CC + end-of-content +.. + This document is maintained by Thorsten Leemhuis . If + you spot a typo or small mistake, feel free to let him know directly and + he'll fix it. You are free to do the same in a mostly informal way if you + want to contribute changes to the text, but for copyright reasons please CC linux-doc@vger.kernel.org and "sign-off" your contribution as Documentation/process/submitting-patches.rst outlines in the section "Sign your work - the Developer's Certificate of Origin". +.. + This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top + of the file. If you want to distribute this text under CC-BY-4.0 only, + please use "The Linux kernel developers" for author attribution and link + this as source: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst +.. + Note: Only the content of this RST file as found in the Linux kernel sources + is available under CC-BY-4.0, as versions of this text that were processed + (for example by the kernel's build system) might contain content taken from + files which use a more restrictive license. -- cgit From 08b25f7d99e15f2aa5f4cce3f13ad0c67a4c1e34 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Sun, 20 Feb 2022 21:18:57 +0100 Subject: dt-bindings: arm: cpus: Add Kryo 250 CPUs Document Kryo 250 CPUs found in Qualcomm Snapdragon 632 (SDM632). Signed-off-by: Luca Weiss Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220220201909.445468-5-luca@z3ntu.xyz --- Documentation/devicetree/bindings/arm/cpus.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index 0dcebc48ea22..3aad1b93742c 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -173,6 +173,7 @@ properties: - nvidia,tegra194-carmel - qcom,krait - qcom,kryo + - qcom,kryo250 - qcom,kryo260 - qcom,kryo280 - qcom,kryo385 -- cgit From cb898d5e59b41a268dcf4dbef31d651c393dfbae Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Sun, 20 Feb 2022 21:19:02 +0100 Subject: dt-bindings: arm: qcom: Document sdm632 and fairphone,fp3 board Add binding documentation for Fairphone 3 smartphone which is based on Snapdragon 632 (sm632). Signed-off-by: Luca Weiss Acked-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220220201909.445468-10-luca@z3ntu.xyz --- Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 298d7129f907..f4336ea0c6a7 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -42,6 +42,7 @@ description: | sc7180 sc7280 sdm630 + sdm632 sdm660 sdm845 sdx55 @@ -225,6 +226,11 @@ properties: - google,senor - const: qcom,sc7280 + - items: + - enum: + - fairphone,fp3 + - const: qcom,sdm632 + - items: - enum: - xiaomi,lavender -- cgit From d148363684a41162a835c1803c02cfd90b22b2c6 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Sun, 20 Feb 2022 23:30:01 +0100 Subject: dt-bindings: power: rpmpd: Add MSM8226 to rpmpd binding Add compatible and constants for the power domains exposed by the MSM8226 RPM. Signed-off-by: Luca Weiss Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220220223004.507739-1-luca@z3ntu.xyz --- Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index f48bc41d81ec..940e97b565bf 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -17,6 +17,7 @@ properties: compatible: enum: - qcom,mdm9607-rpmpd + - qcom,msm8226-rpmpd - qcom,msm8916-rpmpd - qcom,msm8939-rpmpd - qcom,msm8953-rpmpd -- cgit From f3fc4fbfa2d2a09cb279af4e290d0a6dbbc93c7e Mon Sep 17 00:00:00 2001 From: Srinivasa Rao Mandadapu Date: Thu, 24 Feb 2022 21:03:47 +0530 Subject: ASoC: dt-bindings: Add SC7280 lpass cpu bindings Add bindings for sc7280 lpass cpu driver which supports audio over i2s based speaker, soundwire based headset, msm dmics and HDMI Port. Signed-off-by: Srinivasa Rao Mandadapu Co-developed-by: Venkata Prasad Potturu Signed-off-by: Venkata Prasad Potturu Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1645716828-15305-9-git-send-email-quic_srivasam@quicinc.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 75 +++++++++++++++++++--- 1 file changed, 67 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml index 1e23c0e20bc1..2c81efb5fa37 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml @@ -22,35 +22,41 @@ properties: - qcom,lpass-cpu - qcom,apq8016-lpass-cpu - qcom,sc7180-lpass-cpu + - qcom,sc7280-lpass-cpu reg: - maxItems: 2 + minItems: 2 + maxItems: 6 description: LPAIF core registers reg-names: - maxItems: 2 + minItems: 2 + maxItems: 6 clocks: minItems: 3 - maxItems: 6 + maxItems: 7 clock-names: minItems: 3 - maxItems: 6 + maxItems: 7 interrupts: - maxItems: 2 + minItems: 2 + maxItems: 4 description: LPAIF DMA buffer interrupt interrupt-names: - maxItems: 2 + minItems: 2 + maxItems: 4 qcom,adsp: $ref: /schemas/types.yaml#/definitions/phandle description: Phandle for the audio DSP node iommus: - maxItems: 2 + minItems: 2 + maxItems: 3 description: Phandle to apps_smmu node with sid mask power-domains: @@ -69,7 +75,7 @@ patternProperties: "^dai-link@[0-9a-f]$": type: object description: | - LPASS CPU dai node for each I2S device. Bindings of each node + LPASS CPU dai node for each I2S device or Soundwire device. Bindings of each node depends on the specific driver providing the functionality and properties. properties: @@ -174,6 +180,59 @@ allOf: - iommus - power-domains + - if: + properties: + compatible: + contains: + const: qcom,sc7280-lpass-cpu + + then: + properties: + clock-names: + oneOf: + - items: #for I2S + - const: aon_cc_audio_hm_h + - const: core_cc_sysnoc_mport_core + - const: core_cc_ext_if1_ibit + - items: #for Soundwire + - const: aon_cc_audio_hm_h + - const: audio_cc_codec_mem0 + - const: audio_cc_codec_mem1 + - const: audio_cc_codec_mem2 + - items: #for HDMI + - const: aon_cc_audio_hm_h + + reg-names: + anyOf: + - items: #for I2S + - const: lpass-lpaif + - items: #for I2S and HDMI + - const: lpass-hdmiif + - const: lpass-lpaif + - items: #for I2S, soundwire and HDMI + - const: lpass-hdmiif + - const: lpass-lpaif + - const: lpass-rxtx-cdc-dma-lpm + - const: lpass-rxtx-lpaif + - const: lpass-va-lpaif + - const: lpass-va-cdc-dma-lpm + interrupt-names: + anyOf: + - items: #for I2S + - const: lpass-irq-lpaif + - items: #for I2S and HDMI + - const: lpass-irq-lpaif + - const: lpass-irq-hdmi + - items: #for I2S, soundwire and HDMI + - const: lpass-irq-lpaif + - const: lpass-irq-hdmi + - const: lpass-irq-vaif + - const: lpass-irq-rxtxif + + required: + - iommus + - power-domains + examples: - | #include -- cgit From de2f678b11bdcbabb6d804c543f9a3325c0e83bf Mon Sep 17 00:00:00 2001 From: Krishna Yarlagadda Date: Tue, 22 Feb 2022 23:26:08 +0530 Subject: spi: Add Tegra234 QUAD SPI compatible Add compatible string for Tegra234 for Tegra QUAD SPI Signed-off-by: Krishna Yarlagadda Link: https://lore.kernel.org/r/20220222175611.58051-3-kyarlagadda@nvidia.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml index 35a8045b2c70..6efea8970e62 100644 --- a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml @@ -19,6 +19,7 @@ properties: - nvidia,tegra210-qspi - nvidia,tegra186-qspi - nvidia,tegra194-qspi + - nvidia,tegra234-qspi reg: maxItems: 1 -- cgit From 10d7e312497f13419e1f99d903961c7ec0739da3 Mon Sep 17 00:00:00 2001 From: Robin Murphy Date: Thu, 17 Feb 2022 17:47:14 +0000 Subject: dt-bindings: reserved-memory: Add restricted-dma-pool constraints The "restricted-dma-pool" definition prohibits combination with either of the "no-map" and "reusable" properties, but this is only stated in the description text. Add those constraints to the schema so we can properly validate them. Signed-off-by: Robin Murphy Acked-by: Florian Fainelli Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/a4f3d4e2feef008d1236ebc3f5f0c46360f20c60.1645119806.git.robin.murphy@arm.com --- .../devicetree/bindings/reserved-memory/shared-dma-pool.yaml | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml b/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml index a4bf757d6881..618105f079be 100644 --- a/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml +++ b/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml @@ -56,6 +56,16 @@ properties: If this property is present, then Linux will use the region for the default pool of the consistent DMA allocator. +if: + properties: + compatible: + contains: + const: restricted-dma-pool +then: + properties: + no-map: false + reusable: false + unevaluatedProperties: false examples: -- cgit From 8b6167a90135b749bd0e0cab07a75bc07e0fc925 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Tue, 22 Feb 2022 20:45:15 -0800 Subject: dt-bindings: clock: Add sc8280xp to the RPMh clock controller binding The Qualcomm SC8280XP has a RPMh clock controller, so add a compatible for this to the binding. Signed-off-by: Bjorn Andersson Reviewed-by: Stephen Boyd Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220223044516.3776637-1-bjorn.andersson@linaro.org --- Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml index 8406dde17937..8fcaf418f84a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml @@ -20,6 +20,7 @@ properties: - qcom,sc7180-rpmh-clk - qcom,sc7280-rpmh-clk - qcom,sc8180x-rpmh-clk + - qcom,sc8280xp-rpmh-clk - qcom,sdm845-rpmh-clk - qcom,sdx55-rpmh-clk - qcom,sdx65-rpmh-clk -- cgit From 6773675ae8ccd9b4dea9efc4b5e4189465d6a3a8 Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Wed, 2 Feb 2022 19:35:54 -0600 Subject: dt-bindings: phy: Add compatible for D1 USB PHY D1 features one OTG port and one host port, like the A64 SoC, so its USB PHY supports the same set of properties. Add the new compatible to the existing binding. Signed-off-by: Samuel Holland Acked-by: Rob Herring Acked-by: Maxime Ripard Link: https://lore.kernel.org/r/20220203013558.11490-1-samuel@sholland.org Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml index 078af52b16ed..0fa4b32b097e 100644 --- a/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml @@ -15,7 +15,9 @@ properties: const: 1 compatible: - const: allwinner,sun50i-a64-usb-phy + enum: + - allwinner,sun20i-d1-usb-phy + - allwinner,sun50i-a64-usb-phy reg: items: -- cgit From 54ae8c4b8c29e576d6dbfb49832522f782bb7190 Mon Sep 17 00:00:00 2001 From: Robert Marko Date: Mon, 31 Jan 2022 14:30:48 +0100 Subject: dt-bindings: mfd: Add Delta TN48M CPLD drivers bindings Add binding documents for the Delta TN48M CPLD drivers. Signed-off-by: Robert Marko Link: https://lore.kernel.org/r/20220131133049.77780-6-robert.marko@sartura.hr Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/gpio/delta,tn48m-gpio.yaml | 39 ++++++++++ .../devicetree/bindings/mfd/delta,tn48m-cpld.yaml | 90 ++++++++++++++++++++++ .../bindings/reset/delta,tn48m-reset.yaml | 35 +++++++++ 3 files changed, 164 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/delta,tn48m-gpio.yaml create mode 100644 Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml create mode 100644 Documentation/devicetree/bindings/reset/delta,tn48m-reset.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/delta,tn48m-gpio.yaml b/Documentation/devicetree/bindings/gpio/delta,tn48m-gpio.yaml new file mode 100644 index 000000000000..e3e668a12091 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/delta,tn48m-gpio.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/delta,tn48m-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Delta Networks TN48M CPLD GPIO controller + +maintainers: + - Robert Marko + +description: | + This module is part of the Delta TN48M multi-function device. For more + details see ../mfd/delta,tn48m-cpld.yaml. + + Delta TN48M has an onboard Lattice CPLD that is used as an GPIO expander. + It provides 12 pins in total, they are input-only or ouput-only type. + +properties: + compatible: + enum: + - delta,tn48m-gpo + - delta,tn48m-gpi + + reg: + maxItems: 1 + + "#gpio-cells": + const: 2 + + gpio-controller: true + +required: + - compatible + - reg + - "#gpio-cells" + - gpio-controller + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml b/Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml new file mode 100644 index 000000000000..f6967c1f6235 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/delta,tn48m-cpld.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Delta Networks TN48M CPLD controller + +maintainers: + - Robert Marko + +description: | + Lattice CPLD onboard the TN48M switches is used for system + management. + + It provides information about the hardware model, revision, + PSU status etc. + + It is also being used as a GPIO expander and reset controller + for the switch MAC-s and other peripherals. + +properties: + compatible: + const: delta,tn48m-cpld + + reg: + description: + I2C device address. + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +patternProperties: + "^gpio(@[0-9a-f]+)?$": + $ref: ../gpio/delta,tn48m-gpio.yaml + + "^reset-controller?$": + $ref: ../reset/delta,tn48m-reset.yaml + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + cpld@41 { + compatible = "delta,tn48m-cpld"; + reg = <0x41>; + #address-cells = <1>; + #size-cells = <0>; + + gpio@31 { + compatible = "delta,tn48m-gpo"; + reg = <0x31>; + gpio-controller; + #gpio-cells = <2>; + }; + + gpio@3a { + compatible = "delta,tn48m-gpi"; + reg = <0x3a>; + gpio-controller; + #gpio-cells = <2>; + }; + + gpio@40 { + compatible = "delta,tn48m-gpi"; + reg = <0x40>; + gpio-controller; + #gpio-cells = <2>; + }; + + reset-controller { + compatible = "delta,tn48m-reset"; + #reset-cells = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/reset/delta,tn48m-reset.yaml b/Documentation/devicetree/bindings/reset/delta,tn48m-reset.yaml new file mode 100644 index 000000000000..0e5ee8decc0d --- /dev/null +++ b/Documentation/devicetree/bindings/reset/delta,tn48m-reset.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/delta,tn48m-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Delta Networks TN48M CPLD reset controller + +maintainers: + - Robert Marko + +description: | + This module is part of the Delta TN48M multi-function device. For more + details see ../mfd/delta,tn48m-cpld.yaml. + + Reset controller modules provides resets for the following: + * 88F7040 SoC + * 88F6820 SoC + * 98DX3265 switch MAC-s + * 88E1680 PHY-s + * 88E1512 PHY + * PoE PSE controller + +properties: + compatible: + const: delta,tn48m-reset + + "#reset-cells": + const: 1 + +required: + - compatible + - "#reset-cells" + +additionalProperties: false -- cgit From abb29c4783d0ed68ab62ead609d7a2469f70cd71 Mon Sep 17 00:00:00 2001 From: Allen-KH Cheng Date: Thu, 24 Feb 2022 21:08:22 +0800 Subject: dt-bindings: phy: mediatek,tphy: Add compatible for MT8192 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add MT8192 compatible to the Mediatek T-PHY dt-binding. Signed-off-by: Allen-KH Cheng Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Nícolas F. R. A. Prado Link: https://lore.kernel.org/r/20220224130822.11292-2-allen-kh.cheng@mediatek.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index d279ba222316..7b2e1bc119be 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -81,6 +81,7 @@ properties: - mediatek,mt7629-tphy - mediatek,mt8183-tphy - mediatek,mt8186-tphy + - mediatek,mt8192-tphy - const: mediatek,generic-tphy-v2 - items: - enum: -- cgit From bc25c55812ff72cd3f2c310ba42f78a812dac95e Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Sun, 20 Feb 2022 21:18:56 +0100 Subject: dt-bindings: usb: qcom,dwc3: Add msm8953 compatible Document the compatible string for the DWC3 controller in msm8953. Signed-off-by: Luca Weiss Acked-by: Konrad Dybcio Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220220201909.445468-4-luca@z3ntu.xyz Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index 2d23a4ff702f..ce252db2aab3 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -16,6 +16,7 @@ properties: - qcom,ipq4019-dwc3 - qcom,ipq6018-dwc3 - qcom,ipq8064-dwc3 + - qcom,msm8953-dwc3 - qcom,msm8996-dwc3 - qcom,msm8998-dwc3 - qcom,sc7180-dwc3 -- cgit From 9b0d5d4b7a585e94a31c09bd2363e2029d782ba7 Mon Sep 17 00:00:00 2001 From: Pali Rohár Date: Sat, 19 Feb 2022 16:28:14 +0100 Subject: dt-bindings: mvebu-uart: document DT bindings for marvell,armada-3700-uart-clock MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add DT bindings documentation for device nodes with compatible string "marvell,armada-3700-uart-clock". Reviewed-by: Rob Herring Reviewed-by: Marek Behún Reviewed-by: Stephen Boyd Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Link: https://lore.kernel.org/r/20220219152818.4319-3-kabel@kernel.org Signed-off-by: Greg Kroah-Hartman --- .../clock/marvell,armada-3700-uart-clock.yaml | 59 ++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/marvell,armada-3700-uart-clock.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/marvell,armada-3700-uart-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,armada-3700-uart-clock.yaml new file mode 100644 index 000000000000..175f5c8f2bc5 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/marvell,armada-3700-uart-clock.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/marvell,armada-3700-uart-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# +title: Marvell Armada 3720 UART clocks + +maintainers: + - Pali Rohár + +properties: + compatible: + const: marvell,armada-3700-uart-clock + + reg: + items: + - description: UART Clock Control Register + - description: UART 2 Baud Rate Divisor Register + + clocks: + description: | + List of parent clocks suitable for UART from following set: + "TBG-A-P", "TBG-B-P", "TBG-A-S", "TBG-B-S", "xtal" + UART clock can use one from this set and when more are provided + then kernel would choose and configure the most suitable one. + It is suggest to specify at least one TBG clock to achieve + baudrates above 230400 and also to specify clock which bootloader + used for UART (most probably xtal) for smooth boot log on UART. + + clock-names: + items: + - const: TBG-A-P + - const: TBG-B-P + - const: TBG-A-S + - const: TBG-B-S + - const: xtal + minItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + +additionalProperties: false + +examples: + - | + uartclk: clock-controller@12010 { + compatible = "marvell,armada-3700-uart-clock"; + reg = <0x12010 0x4>, <0x12210 0x4>; + clocks = <&tbg 0>, <&tbg 1>, <&tbg 2>, <&tbg 3>, <&xtalclk>; + clock-names = "TBG-A-P", "TBG-B-P", "TBG-A-S", "TBG-B-S", "xtal"; + #clock-cells = <1>; + }; -- cgit From ebd7e37a8b7e703555b0ca4796441c3876254773 Mon Sep 17 00:00:00 2001 From: Pali Rohár Date: Sat, 19 Feb 2022 16:28:16 +0100 Subject: dt-bindings: mvebu-uart: update information about UART clock MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Device "marvell,armada-3700-uart" should use "marvell,armada-3700-uart-clock" compatible clock. Reviewed-by: Rob Herring Reviewed-by: Marek Behún Reviewed-by: Stephen Boyd Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Link: https://lore.kernel.org/r/20220219152818.4319-5-kabel@kernel.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/mvebu-uart.txt | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/serial/mvebu-uart.txt index 2d0dbdf32d1d..a062bbca532c 100644 --- a/Documentation/devicetree/bindings/serial/mvebu-uart.txt +++ b/Documentation/devicetree/bindings/serial/mvebu-uart.txt @@ -14,7 +14,10 @@ Required properties: is provided (possible only with the "marvell,armada-3700-uart" compatible string for backward compatibility), it will only work if the baudrate was initialized by the bootloader and no baudrate - change will then be possible. + change will then be possible. When provided it should be UART1-clk + for standard variant of UART and UART2-clk for extended variant + of UART. TBG clock (with UART TBG divisors d1=d2=1) or xtal clock + should not be used and are supported only for backward compatibility. - interrupts: - Must contain three elements for the standard variant of the IP (marvell,armada-3700-uart): "uart-sum", "uart-tx" and "uart-rx", @@ -34,7 +37,7 @@ Example: uart0: serial@12000 { compatible = "marvell,armada-3700-uart"; reg = <0x12000 0x18>; - clocks = <&xtalclk>; + clocks = <&uartclk 0>; interrupts = , , @@ -45,7 +48,7 @@ Example: uart1: serial@12200 { compatible = "marvell,armada-3700-uart-ext"; reg = <0x12200 0x30>; - clocks = <&xtalclk>; + clocks = <&uartclk 1>; interrupts = , ; -- cgit From 8fb29b4501824e1b700881679c7b4c981aadf155 Mon Sep 17 00:00:00 2001 From: Vincent Shih Date: Wed, 23 Feb 2022 22:35:02 +0000 Subject: dt-bindings: nvmem: Add bindings doc for Sunplus OCOTP driver Add bindings doc for Sunplus OCOTP driver Reviewed-by: Rob Herring Signed-off-by: Vincent Shih Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220223223502.29454-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman --- .../bindings/nvmem/sunplus,sp7021-ocotp.yaml | 86 ++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml new file mode 100644 index 000000000000..4b28f37dfb67 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) Sunplus Co., Ltd. 2021 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/sunplus,sp7021-ocotp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: On-Chip OTP Memory for Sunplus SP7021 + +maintainers: + - Vincent Shih + +allOf: + - $ref: "nvmem.yaml#" + +properties: + compatible: + const: sunplus,sp7021-ocotp + + reg: + maxItems: 2 + + reg-names: + items: + - const: hb_gpio + - const: otprx + + clocks: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + thermal-calibration: + type: object + description: thermal calibration values + + disconnect-voltage: + type: object + description: disconnect voltages of usb2 port 0 and port 1 + + mac-address0: + type: object + description: MAC address of ethernet port 0 + + mac-address1: + type: object + description: MAC address of ethernet port 1 + +required: + - compatible + - reg + - reg-names + - clocks + +unevaluatedProperties: false + +examples: + - | + #include + + otp: otp@9c00af00 { + compatible = "sunplus,sp7021-ocotp"; + reg = <0x9c00af00 0x34>, <0x9c00af80 0x58>; + reg-names = "hb_gpio", "otprx"; + clocks = <&clks OTPRX>; + + #address-cells = <1>; + #size-cells = <1>; + therm_calib: thermal-calibration@14 { + reg = <0x14 0x3>; + }; + disc_vol: disconnect-voltage@18 { + reg = <0x18 0x2>; + }; + mac_addr0: mac-address0@34 { + reg = <0x34 0x6>; + }; + mac_addr1: mac-address1@3a { + reg = <0x3a 0x6>; + }; + }; +... -- cgit From de8512339520a850bb290cbf5c8bb07aa4e5adda Mon Sep 17 00:00:00 2001 From: Ronak Jain Date: Wed, 9 Feb 2022 00:27:08 -0800 Subject: firmware: zynqmp: Add documentation for runtime feature config Add documentation for sysfs entries like feature_config_id and feature_config_value for runtime feature configuration. The support is added for an over temperature and external watchdog features. Acked-by: Michal Simek Signed-off-by: Ronak Jain Link: https://lore.kernel.org/r/20220209082709.32378-3-ronak.jain@xilinx.com Signed-off-by: Greg Kroah-Hartman --- .../ABI/stable/sysfs-driver-firmware-zynqmp | 141 +++++++++++++++++++++ 1 file changed, 141 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp index f5724bb5b462..c3fec3c835af 100644 --- a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp +++ b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp @@ -113,3 +113,144 @@ Description: # echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/health_status Users: Xilinx + +What: /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "Ronak Jain" +Description: + This sysfs interface allows user to configure features at + runtime. The user can enable or disable features running at + firmware as well as the user can configure the parameters of + the features at runtime. The supported features are over + temperature and external watchdog. Here, the external watchdog + is completely different than the /dev/watchdog as the external + watchdog is running on the firmware and it is used to monitor + the health of firmware not APU(Linux). Also, the external + watchdog is interfaced outside of the zynqmp soc. + + The supported config ids are for the feature configuration is, + 1. PM_FEATURE_OVERTEMP_STATUS = 1, the user can enable or + disable the over temperature feature. + 2. PM_FEATURE_OVERTEMP_VALUE = 2, the user can configure the + over temperature limit in Degree Celsius. + 3. PM_FEATURE_EXTWDT_STATUS = 3, the user can enable or disable + the external watchdog feature. + 4. PM_FEATURE_EXTWDT_VALUE = 4, the user can configure the + external watchdog feature. + + Usage: + + Select over temperature config ID to enable/disable feature + # echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + + Check over temperature config ID is selected or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + The expected result is 1. + + Select over temperature config ID to configure OT limit + # echo 2 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + + Check over temperature config ID is selected or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + The expected result is 2. + + Select external watchdog config ID to enable/disable feature + # echo 3 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + + Check external watchdog config ID is selected or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + The expected result is 3. + + Select external watchdog config ID to configure time interval + # echo 4 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + + Check external watchdog config ID is selected or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + The expected result is 4. + +Users: Xilinx + +What: /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "Ronak Jain" +Description: + This sysfs interface allows to configure features at runtime. + The user can enable or disable features running at firmware. + Also, the user can configure the parameters of the features + at runtime. The supported features are over temperature and + external watchdog. Here, the external watchdog is completely + different than the /dev/watchdog as the external watchdog is + running on the firmware and it is used to monitor the health + of firmware not APU(Linux). Also, the external watchdog is + interfaced outside of the zynqmp soc. + + By default the features are disabled in the firmware. The user + can enable features by querying appropriate config id of the + features. + + The default limit for the over temperature is 90 Degree Celsius. + The default timer interval for the external watchdog is 570ms. + + The supported config ids are for the feature configuration is, + 1. PM_FEATURE_OVERTEMP_STATUS = 1, the user can enable or + disable the over temperature feature. + 2. PM_FEATURE_OVERTEMP_VALUE = 2, the user can configure the + over temperature limit in Degree Celsius. + 3. PM_FEATURE_EXTWDT_STATUS = 3, the user can enable or disable + the external watchdog feature. + 4. PM_FEATURE_EXTWDT_VALUE = 4, the user can configure the + external watchdog feature. + + Usage: + + Enable over temperature feature + # echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + # echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + + Check whether the over temperature feature is enabled or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + The expected result is 1. + + Disable over temperature feature + # echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + # echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + + Check whether the over temperature feature is disabled or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + The expected result is 0. + + Configure over temperature limit to 50 Degree Celsius + # echo 2 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + # echo 50 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + + Check whether the over temperature limit is configured or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + The expected result is 50. + + Enable external watchdog feature + # echo 3 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + # echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + + Check whether the external watchdog feature is enabled or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + The expected result is 1. + + Disable external watchdog feature + # echo 3 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + # echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + + Check whether the external watchdog feature is disabled or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + The expected result is 0. + + Configure external watchdog timer interval to 500ms + # echo 4 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + # echo 500 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + + Check whether the external watchdog timer interval is configured or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + The expected result is 500. + +Users: Xilinx -- cgit From 80ce91730d3283f10810245db2605498d794fa29 Mon Sep 17 00:00:00 2001 From: Julius Werner Date: Wed, 23 Feb 2022 16:34:19 -0800 Subject: dt-bindings: memory: lpddr2: Adjust revision ID property to match lpddr3 Commit 3539a2c6c689 ("dt-bindings: memory: lpddr2: Add revision-id properties") added the properties `revision-id1` and `revision-id2` to the "jedec,lpddr2" binding. The "jedec,lpddr3" binding already had a single array property `revision-id` for the same purpose. For consistency between related memory types, this patch deprecates the LPDDR2 properties and instead adds a property in the same style as for LPDDR3 to that binding. Signed-off-by: Julius Werner Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220224003421.3440124-2-jwerner@chromium.org Signed-off-by: Krzysztof Kozlowski --- .../bindings/memory-controllers/ddr/jedec,lpddr2.yaml | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml index 2d8a701e2a05..dd2141cad866 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml @@ -30,12 +30,26 @@ properties: maximum: 255 description: | Revision 1 value of SDRAM chip. Obtained from device datasheet. + Property is deprecated, use revision-id instead. + deprecated: true revision-id2: $ref: /schemas/types.yaml#/definitions/uint32 maximum: 255 description: | Revision 2 value of SDRAM chip. Obtained from device datasheet. + Property is deprecated, use revision-id instead. + deprecated: true + + revision-id: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Revision IDs read from Mode Register 6 and 7. One byte per uint32 cell (i.e. ). + minItems: 2 + maxItems: 2 + items: + minimum: 0 + maximum: 255 density: $ref: /schemas/types.yaml#/definitions/uint32 @@ -162,8 +176,7 @@ examples: compatible = "elpida,ECB240ABACN", "jedec,lpddr2-s4"; density = <2048>; io-width = <32>; - revision-id1 = <1>; - revision-id2 = <0>; + revision-id = <1 0>; tRPab-min-tck = <3>; tRCD-min-tck = <3>; -- cgit From 64d45edd8b267ccac6f15302fdb44add905398f7 Mon Sep 17 00:00:00 2001 From: LUU HOAI Date: Mon, 21 Feb 2022 16:43:36 +0100 Subject: dt-bindings: pinctrl: renesas,pfc: Document r8a779f0 support Document Pin Function Controller (PFC) support for the Renesas R-Car S4-8 (R8A779F0) SoC. Signed-off-by: LUU HOAI Signed-off-by: Geert Uytterhoeven Reviewed-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/d51828853396773be2d6837f3301ac9da8b6f29e.1645457792.git.geert+renesas@glider.be --- Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml index 8548e3639b75..2a57df75d832 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml @@ -44,6 +44,7 @@ properties: - renesas,pfc-r8a77990 # R-Car E3 - renesas,pfc-r8a77995 # R-Car D3 - renesas,pfc-r8a779a0 # R-Car V3U + - renesas,pfc-r8a779f0 # R-Car S4-8 - renesas,pfc-sh73a0 # SH-Mobile AG5 reg: -- cgit From ba7bb663f5547ef474c98df99a97bb4a13c5715f Mon Sep 17 00:00:00 2001 From: David Dunn Date: Wed, 23 Feb 2022 22:57:41 +0000 Subject: KVM: x86: Provide per VM capability for disabling PMU virtualization Add a new capability, KVM_CAP_PMU_CAPABILITY, that takes a bitmask of settings/features to allow userspace to configure PMU virtualization on a per-VM basis. For now, support a single flag, KVM_PMU_CAP_DISABLE, to allow disabling PMU virtualization for a VM even when KVM is configured with enable_pmu=true a module level. To keep KVM simple, disallow changing VM's PMU configuration after vCPUs have been created. Signed-off-by: David Dunn Message-Id: <20220223225743.2703915-2-daviddunn@google.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index c3e68c1531f0..f5d011351016 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7643,3 +7643,25 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace the hypercalls whose corresponding bit is in the argument, and return ENOSYS for the others. + +8.35 KVM_CAP_PMU_CAPABILITY +--------------------------- + +:Capability KVM_CAP_PMU_CAPABILITY +:Architectures: x86 +:Type: vm +:Parameters: arg[0] is bitmask of PMU virtualization capabilities. +:Returns 0 on success, -EINVAL when arg[0] contains invalid bits + +This capability alters PMU virtualization in KVM. + +Calling KVM_CHECK_EXTENSION for this capability returns a bitmask of +PMU virtualization capabilities that can be adjusted on a VM. + +The argument to KVM_ENABLE_CAP is also a bitmask and selects specific +PMU virtualization capabilities to be applied to the VM. This can +only be invoked on a VM prior to the creation of VCPUs. + +At this time, KVM_PMU_CAP_DISABLE is the only capability. Setting +this capability will disable PMU virtualization for that VM. Usermode +should adjust CPUID leaf 0xA to reflect that the PMU is disabled. -- cgit From 83854c231262d2ad43c4fb32414ba25304f925d8 Mon Sep 17 00:00:00 2001 From: Li-hao Kuo Date: Fri, 25 Feb 2022 14:31:53 +0800 Subject: spi: dt-bindings: remove unused required property fix issue /builds/robherring/linux-dt/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.example.dt.yaml: spi@9C002D80: 'clocks-names' is a required property From schema: /builds/robherring/linux-dt/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml delete unused required(clock-name) Fixes: 3b8ab4da34 ("spi: Fix test error for sp7021") Reported-by: Rob Herring Signed-off-by: Li-hao Kuo Link: https://lore.kernel.org/r/097bbc8b703b17e8fb3e3f6f6d2f97fe668bd5c5.1645770648.git.lhjeff911@gmail.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml b/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml index 298eac28c40f..3a58cf0f1ec8 100644 --- a/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml +++ b/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml @@ -50,7 +50,6 @@ required: - interrupts - interrupt-names - clocks - - clocks-names - resets - pinctrl-names - pinctrl-0 -- cgit From 3f9ab2a6986fe2930782408cc2a6c25e3e5cb98f Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Wed, 16 Feb 2022 17:32:21 +0000 Subject: arm64/mte: Document ABI for asymmetric mode MTE3 adds a new mode which is synchronous for reads but asynchronous for writes. Document the userspace ABI for this feature, we call the new mode ASYMM and add a new prctl flag and mte_tcf_preferred value for it. Signed-off-by: Mark Brown Reviewed-by: Catalin Marinas Link: https://lore.kernel.org/r/20220216173224.2342152-2-broonie@kernel.org Signed-off-by: Will Deacon --- Documentation/arm64/memory-tagging-extension.rst | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arm64/memory-tagging-extension.rst index 7b99c8f428eb..42677d48a114 100644 --- a/Documentation/arm64/memory-tagging-extension.rst +++ b/Documentation/arm64/memory-tagging-extension.rst @@ -76,6 +76,9 @@ configurable behaviours: with ``.si_code = SEGV_MTEAERR`` and ``.si_addr = 0`` (the faulting address is unknown). +- *Asymmetric* - Reads are handled as for synchronous mode while writes + are handled as for asynchronous mode. + The user can select the above modes, per thread, using the ``prctl(PR_SET_TAGGED_ADDR_CTRL, flags, 0, 0, 0)`` system call where ``flags`` contains any number of the following values in the ``PR_MTE_TCF_MASK`` @@ -85,6 +88,7 @@ bit-field: (ignored if combined with other options) - ``PR_MTE_TCF_SYNC`` - *Synchronous* tag check fault mode - ``PR_MTE_TCF_ASYNC`` - *Asynchronous* tag check fault mode +- ``PR_MTE_TCF_ASYMM`` - *Asymmetric* tag check fault mode If no modes are specified, tag check faults are ignored. If a single mode is specified, the program will run in that mode. If multiple @@ -139,18 +143,23 @@ tag checking mode as the CPU's preferred tag checking mode. The preferred tag checking mode for each CPU is controlled by ``/sys/devices/system/cpu/cpu/mte_tcf_preferred``, to which a -privileged user may write the value ``async`` or ``sync``. The default -preferred mode for each CPU is ``async``. +privileged user may write the value ``async``, ``sync`` or ``asymm``. The +default preferred mode for each CPU is ``async``. To allow a program to potentially run in the CPU's preferred tag checking mode, the user program may set multiple tag check fault mode bits in the ``flags`` argument to the ``prctl(PR_SET_TAGGED_ADDR_CTRL, flags, 0, 0, 0)`` system call. If the CPU's preferred tag checking -mode is in the task's set of provided tag checking modes (this will -always be the case at present because the kernel only supports two -tag checking modes, but future kernels may support more modes), that +mode is in the task's set of provided tag checking modes, that mode will be selected. Otherwise, one of the modes in the task's mode -set will be selected in a currently unspecified manner. +selected by the kernel using the preference order: + + 1. Asynchronous + 2. Asymmetric + 3. Synchronous + +If asymmetric mode is specified by the program but not supported by +either the system or the kernel then an error will be returned. Initial process state --------------------- -- cgit From d082a0255fcb8fcb4bd8257df111f2caa67086bc Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Wed, 16 Feb 2022 17:32:23 +0000 Subject: arm64/mte: Add hwcap for asymmetric mode Allow userspace to detect support for asymmetric mode by providing a hwcap for it, using the official feature name FEAT_MTE3. Signed-off-by: Mark Brown Reviewed-by: Catalin Marinas Reviewed-by: Vincenzo Frascino Tested-by: Branislav Rankov Link: https://lore.kernel.org/r/20220216173224.2342152-4-broonie@kernel.org Signed-off-by: Will Deacon --- Documentation/arm64/elf_hwcaps.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst index b72ff17d600a..a8f30963e550 100644 --- a/Documentation/arm64/elf_hwcaps.rst +++ b/Documentation/arm64/elf_hwcaps.rst @@ -259,6 +259,11 @@ HWCAP2_RPRES Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001. +HWCAP2_MTE3 + + Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described + by Documentation/arm64/memory-tagging-extension.rst. + 4. Unused AT_HWCAP bits ----------------------- -- cgit From 0750b8fcf313845b21c71344b4bea8ad7d3cee84 Mon Sep 17 00:00:00 2001 From: Srinivas Pandruvada Date: Fri, 11 Feb 2022 08:09:32 -0800 Subject: Documentation/admin-guide/acpi: Add documentation for fine grain control Add documentation for the newly added attributes: fine_grain_control fan_speed_rpm Signed-off-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki --- .../admin-guide/acpi/fan_performance_states.rst | 28 ++++++++++++++++++++++ 1 file changed, 28 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/acpi/fan_performance_states.rst b/Documentation/admin-guide/acpi/fan_performance_states.rst index 98fe5c333121..b9e4b4d146c1 100644 --- a/Documentation/admin-guide/acpi/fan_performance_states.rst +++ b/Documentation/admin-guide/acpi/fan_performance_states.rst @@ -60,3 +60,31 @@ For example:: When a given field is not populated or its value provided by the platform firmware is invalid, the "not-defined" string is shown instead of the value. + +ACPI Fan Fine Grain Control +============================= + +When _FIF object specifies support for fine grain control, then fan speed +can be set from 0 to 100% with the recommended minimum "step size" via +_FSL object. User can adjust fan speed using thermal sysfs cooling device. + +Here use can look at fan performance states for a reference speed (speed_rpm) +and set it by changing cooling device cur_state. If the fine grain control +is supported then user can also adjust to some other speeds which are +not defined in the performance states. + +The support of fine grain control is presented via sysfs attribute +"fine_grain_control". If fine grain control is present, this attribute +will show "1" otherwise "0". + +This sysfs attribute is presented in the same directory as performance states. + +ACPI Fan Performance Feedback +============================= + +The optional _FST object provides status information for the fan device. +This includes field to provide current fan speed in revolutions per minute +at which the fan is rotating. + +This speed is presented in the sysfs using the attribute "fan_speed_rpm", +in the same directory as performance states. -- cgit From b48b9f6deacf0b499a14b9fc3f9d1ab45cc137f8 Mon Sep 17 00:00:00 2001 From: Hammer Hsieh Date: Tue, 22 Feb 2022 17:36:02 +0800 Subject: dt-bindings: serial: Add bindings doc for Sunplus SoC UART Driver Add bindings doc for Sunplus SoC UART Driver Reviewed-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Hammer Hsieh Link: https://lore.kernel.org/r/1645522563-17183-2-git-send-email-hammerh0314@gmail.com Signed-off-by: Greg Kroah-Hartman --- .../bindings/serial/sunplus,sp7021-uart.yaml | 56 ++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml b/Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml new file mode 100644 index 000000000000..2e9b64abde70 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) Sunplus Co., Ltd. 2021 +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/serial/sunplus,sp7021-uart.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Sunplus SoC SP7021 UART Controller Device Tree Bindings + +maintainers: + - Hammer Hsieh + +allOf: + - $ref: serial.yaml# + +properties: + compatible: + const: sunplus,sp7021-uart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - resets + +additionalProperties: false + +examples: + - | + #include + aliases { + serial0 = &uart0; + }; + + uart0: serial@9c000900 { + compatible = "sunplus,sp7021-uart"; + reg = <0x9c000900 0x80>; + interrupt-parent = <&intc>; + interrupts = <53 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clkc 0x28>; + resets = <&rstc 0x18>; + }; +... -- cgit From 10dce8deabb523b2cb43be517f6df89d25a11d27 Mon Sep 17 00:00:00 2001 From: Jagath Jog J Date: Wed, 23 Feb 2022 22:05:25 +0530 Subject: dt-bindings: iio: potentiometer: Add Maxim DS3502 in trivial-devices Maxim DS3502 is a 7 bit nonvolatile digital potentiometer. Add DS3502 binding into trivial-devices.yaml. Signed-off-by: Jagath Jog J Acked-by: Rob Herring Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220223163525.13399-8-jagathjog1996@gmail.com Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 091792ba993e..b6187603317a 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -157,6 +157,8 @@ properties: - maxim,ds1803-050 # 100 kOhm digital potentiometer with I2C interface - maxim,ds1803-100 + # 10 kOhm digital potentiometer with I2C interface + - maxim,ds3502 # Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs - maxim,max1237 # Temperature Sensor, I2C interface -- cgit From d27656d02d85078c63f060fca9c5d99794791a75 Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Fri, 25 Feb 2022 11:22:18 +0200 Subject: docs: net: dsa: sja1105: document limitations of tc-flower rule VLAN awareness After change "net: dsa: tag_8021q: replace the SVL bridging with VLAN-unaware IVL bridging", tag_8021q enforces two different pvids on a port, depending on whether it is standalone or in a VLAN-unaware bridge. Up until now, there was a single pvid, represented by dsa_tag_8021q_rx_vid(), and that was used as the VLAN for VLAN-unaware virtual link rules, regardless of whether the port was bridged or standalone. To keep VLAN-unaware virtual links working, we need to follow whether the port is in a bridge or not, and update the VLAN ID from those rules. In fact we can't fully do that. Depending on whether the switch is VLAN-aware or not, we can accept Virtual Link rules with just the MAC DA, or with a MAC DA and a VID. So we already deny changes to the VLAN awareness of the switch. But the VLAN awareness may also change as a result of joining or leaving a bridge. One might say we could just allow the following: a port may leave a VLAN-unaware bridge while it has VLAN-unaware VL (tc-flower) rules, and the driver will update those with the new tag_8021q pvid for standalone mode, but the driver won't accept joining a bridge at all while VL rules were installed in standalone mode. This is sort of a compromise made because leaving a bridge is an operation that cannot be vetoed. But this sort of setup change is not fully supported, either: as mentioned, VLAN filtering changes can also be triggered by leaving a bridge, therefore, the existing veto we have in place for turning VLAN filtering off with VLAN-aware VL rules active still isn't fully effective. I really don't know how to deal with this in a way that produces predictable behavior for user space. Since at the moment, keeping this feature fully functional on constellation changes (not changing the tag_8021q port pvid when joining a bridge) is blocking progress for the DSA FDB isolation, I'd rather document it as a (potentially temporary) limitation and go on without it. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller --- Documentation/networking/dsa/sja1105.rst | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/dsa/sja1105.rst b/Documentation/networking/dsa/sja1105.rst index 29b1bae0cf00..e0219c1452ab 100644 --- a/Documentation/networking/dsa/sja1105.rst +++ b/Documentation/networking/dsa/sja1105.rst @@ -293,6 +293,33 @@ of dropped frames, which is a sum of frames dropped due to timing violations, lack of destination ports and MTU enforcement checks). Byte-level counters are not available. +Limitations +=========== + +The SJA1105 switch family always performs VLAN processing. When configured as +VLAN-unaware, frames carry a different VLAN tag internally, depending on +whether the port is standalone or under a VLAN-unaware bridge. + +The virtual link keys are always fixed at {MAC DA, VLAN ID, VLAN PCP}, but the +driver asks for the VLAN ID and VLAN PCP when the port is under a VLAN-aware +bridge. Otherwise, it fills in the VLAN ID and PCP automatically, based on +whether the port is standalone or in a VLAN-unaware bridge, and accepts only +"VLAN-unaware" tc-flower keys (MAC DA). + +The existing tc-flower keys that are offloaded using virtual links are no +longer operational after one of the following happens: + +- port was standalone and joins a bridge (VLAN-aware or VLAN-unaware) +- port is part of a bridge whose VLAN awareness state changes +- port was part of a bridge and becomes standalone +- port was standalone, but another port joins a VLAN-aware bridge and this + changes the global VLAN awareness state of the bridge + +The driver cannot veto all these operations, and it cannot update/remove the +existing tc-flower filters either. So for proper operation, the tc-flower +filters should be installed only after the forwarding configuration of the port +has been made, and removed by user space before making any changes to it. + Device Tree bindings and board design ===================================== -- cgit From 602744fa9f8b6160018ff29074ceb607d157395f Mon Sep 17 00:00:00 2001 From: Antoniu Miclaus Date: Wed, 23 Feb 2022 14:01:10 +0200 Subject: dt-bindings: iio: amplifiers: add ada4250 doc Add device tree bindings for the ADA4250 driver. Signed-off-by: Antoniu Miclaus Reviewed-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220223120112.8067-1-antoniu.miclaus@analog.com Signed-off-by: Jonathan Cameron --- .../bindings/iio/amplifiers/adi,ada4250.yaml | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/amplifiers/adi,ada4250.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/amplifiers/adi,ada4250.yaml b/Documentation/devicetree/bindings/iio/amplifiers/adi,ada4250.yaml new file mode 100644 index 000000000000..5277479be382 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/amplifiers/adi,ada4250.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/amplifiers/adi,ada4250.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ADA4250 Programmable Gain Instrumentation Amplifier + +maintainers: + - Antoniu Miclaus + +description: | + Precision Low Power, 110kHz, 26uA, Programmable Gain Instrumentation Amplifier. + +properties: + compatible: + enum: + - adi,ada4250 + + reg: + maxItems: 1 + + avdd-supply: true + + adi,refbuf-enable: + description: + Enable internal buffer to drive the reference pin. + type: boolean + + spi-max-frequency: true + +required: + - compatible + - reg + - avdd-supply + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + amplifier@0 { + compatible = "adi,ada4250"; + reg = <0>; + avdd-supply = <&avdd>; + }; + }; +... -- cgit From bfdf1635a2d7cc0da1e1b4f2b68e3f20bf3bb16b Mon Sep 17 00:00:00 2001 From: Cristian Pop Date: Wed, 23 Feb 2022 15:08:07 +0200 Subject: dt-bindings: iio: frequency: Add ADMV4420 doc Add device tree bindings for the ADMV4420 K band downconverter. Signed-off-by: Cristian Pop Acked-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220223130808.13352-1-cristian.pop@analog.com Signed-off-by: Jonathan Cameron --- .../bindings/iio/frequency/adi,admv4420.yaml | 55 ++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/frequency/adi,admv4420.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,admv4420.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,admv4420.yaml new file mode 100644 index 000000000000..da7fe85ec92e --- /dev/null +++ b/Documentation/devicetree/bindings/iio/frequency/adi,admv4420.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/frequency/adi,admv4420.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ADMV4420 K Band Downconverter + +maintainers: + - Cristian Pop + +description: + The ADMV4420 is a highly integrated, double balanced, active + mixer with an integrated fractional-N synthesizer, ideally suited + for next generation K band satellite communications + +properties: + compatible: + enum: + - adi,admv4420 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 1000000 + + adi,lo-freq-khz: + description: LO Frequency + $ref: /schemas/types.yaml#/definitions/uint32 + + adi,ref-ext-single-ended-en: + description: External reference selected. + type: boolean + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + mixer@0 { + compatible = "adi,admv4420"; + reg = <0>; + spi-max-frequency = <1000000>; + adi,lo-freq-khz = <16750000>; + adi,ref-ext-single-ended-en; + }; + }; +... -- cgit From 32b9a19a1966fb3124d7ddd60ebd08688be2f3fa Mon Sep 17 00:00:00 2001 From: Paul Cercueil Date: Mon, 10 Jan 2022 18:22:55 +0000 Subject: ABI: hwmon: Document "label" sysfs attribute Add the "label" sysfs attribute, which can contain a descriptive label that allows to uniquely identify a device within the system. Signed-off-by: Paul Cercueil Link: https://lore.kernel.org/r/20220110182256.30763-2-paul@crapouillou.net Signed-off-by: Guenter Roeck --- Documentation/ABI/testing/sysfs-class-hwmon | 8 ++++++++ Documentation/hwmon/sysfs-interface.rst | 4 ++++ 2 files changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-hwmon b/Documentation/ABI/testing/sysfs-class-hwmon index 1f20687def44..653d4c75eddb 100644 --- a/Documentation/ABI/testing/sysfs-class-hwmon +++ b/Documentation/ABI/testing/sysfs-class-hwmon @@ -9,6 +9,14 @@ Description: RO +What: /sys/class/hwmon/hwmonX/label +Description: + A descriptive label that allows to uniquely identify a + device within the system. + The contents of the label are free-form. + + RO + What: /sys/class/hwmon/hwmonX/update_interval Description: The interval at which the chip will update readings. diff --git a/Documentation/hwmon/sysfs-interface.rst b/Documentation/hwmon/sysfs-interface.rst index 85652a6aaa3e..209626fb2405 100644 --- a/Documentation/hwmon/sysfs-interface.rst +++ b/Documentation/hwmon/sysfs-interface.rst @@ -99,6 +99,10 @@ Global attributes `name` The chip name. +`label` + A descriptive label that allows to uniquely identify a device + within the system. + `update_interval` The interval at which the chip will update readings. -- cgit From 1b089084ec654c05df202896d54df8d92b16fc1e Mon Sep 17 00:00:00 2001 From: Armin Wolf Date: Sun, 9 Jan 2022 22:42:46 +0100 Subject: Documentation: admin-guide: Update i8k driver name The driver should be called dell_smm_hwmon, i8k is only an alias now. Signed-off-by: Armin Wolf Acked-by: Randy Dunlap Link: https://lore.kernel.org/r/20220109214248.61759-2-W_Armin@gmx.de Signed-off-by: Guenter Roeck --- Documentation/admin-guide/kernel-parameters.txt | 29 +++++++++++++++---------- 1 file changed, 18 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index f5a27f067db9..7189402e9fc7 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -944,6 +944,24 @@ dump out devices still on the deferred probe list after retrying. + dell_smm_hwmon.ignore_dmi= + [HW] Continue probing hardware even if DMI data + indicates that the driver is running on unsupported + hardware. + + dell_smm_hwmon.force= + [HW] Activate driver even if SMM BIOS signature does + not match list of supported models and enable otherwise + blacklisted features. + + dell_smm_hwmon.power_status= + [HW] Report power status in /proc/i8k + (disabled by default). + + dell_smm_hwmon.restricted= + [HW] Allow controlling fans only if SYS_ADMIN + capability is set. + dfltcc= [HW,S390] Format: { on | off | def_only | inf_only | always } on: s390 zlib hardware support for compression on @@ -1703,17 +1721,6 @@ i810= [HW,DRM] - i8k.ignore_dmi [HW] Continue probing hardware even if DMI data - indicates that the driver is running on unsupported - hardware. - i8k.force [HW] Activate i8k driver even if SMM BIOS signature - does not match list of supported models. - i8k.power_status - [HW] Report power status in /proc/i8k - (disabled by default) - i8k.restricted [HW] Allow controlling fans only if SYS_ADMIN - capability is set. - i915.invert_brightness= [DRM] Invert the sense of the variable that is used to set the brightness of the panel backlight. Normally a -- cgit From 99fdc5875b005b6014be2bd2a7c6aaf0abe2896d Mon Sep 17 00:00:00 2001 From: Armin Wolf Date: Sun, 9 Jan 2022 22:42:47 +0100 Subject: Documentation: admin-guide: Add Documentation for undocumented dell_smm_hwmon parameters Add documentation for fan_mult and fan_max. Signed-off-by: Armin Wolf Link: https://lore.kernel.org/r/20220109214248.61759-3-W_Armin@gmx.de Signed-off-by: Guenter Roeck --- Documentation/admin-guide/kernel-parameters.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 7189402e9fc7..d68053db21cc 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -962,6 +962,12 @@ [HW] Allow controlling fans only if SYS_ADMIN capability is set. + dell_smm_hwmon.fan_mult= + [HW] Factor to multiply fan speed with. + + dell_smm_hwmon.fan_max= + [HW] Maximum configurable fan speed. + dfltcc= [HW,S390] Format: { on | off | def_only | inf_only | always } on: s390 zlib hardware support for compression on -- cgit From 34781a6bec382dd11254caff0d379c7be70576fd Mon Sep 17 00:00:00 2001 From: Armin Wolf Date: Sun, 9 Jan 2022 22:42:48 +0100 Subject: Documentation: ABI: Add ABI file for legacy /proc/i8k interface Add ABI file for informing remaining users of the deprecation of the legacy /proc/i8k interface. Signed-off-by: Armin Wolf Link: https://lore.kernel.org/r/20220109214248.61759-4-W_Armin@gmx.de Signed-off-by: Guenter Roeck --- Documentation/ABI/obsolete/procfs-i8k | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 Documentation/ABI/obsolete/procfs-i8k (limited to 'Documentation') diff --git a/Documentation/ABI/obsolete/procfs-i8k b/Documentation/ABI/obsolete/procfs-i8k new file mode 100644 index 000000000000..32df4d5bdd15 --- /dev/null +++ b/Documentation/ABI/obsolete/procfs-i8k @@ -0,0 +1,10 @@ +What: /proc/i8k +Date: November 2001 +KernelVersion: 2.4.14 +Contact: Pali Rohár +Description: Legacy interface for getting/setting sensor information like + fan speed, temperature, serial number, hotkey status etc + on Dell Laptops. + Since the driver is now using the standard hwmon sysfs interface, + the procfs interface is deprecated. +Users: https://github.com/vitorafsr/i8kutils -- cgit From f86380b797834bed6cd55c6c1f49a590356ec828 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 18 Jan 2022 19:55:13 -0600 Subject: dt-bindings: hwmon: lm90: Drop Tegra specifics from example There's no need to complicate examples with a platform specific macro. It also complicates example parsing to figure out the number of interrupt cells in examples (based on bracketing). Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220119015514.2441231-1-robh@kernel.org Signed-off-by: Guenter Roeck --- Documentation/devicetree/bindings/hwmon/national,lm90.yaml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml index 6e1d54ff5d5b..30db92977937 100644 --- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml +++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml @@ -60,7 +60,6 @@ additionalProperties: false examples: - | - #include #include i2c { @@ -71,8 +70,7 @@ examples: compatible = "onnn,nct1008"; reg = <0x4c>; vcc-supply = <&palmas_ldo6_reg>; - interrupt-parent = <&gpio>; - interrupts = ; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; #thermal-sensor-cells = <1>; }; }; -- cgit From 0314c6ac9e98d7551554fe422128726cd2849a8e Mon Sep 17 00:00:00 2001 From: Eugene Shalygin Date: Mon, 24 Jan 2022 02:56:44 +0100 Subject: hwmon: (asus-ec-sensors) update documentation Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20220124015658.687309-3-eugene.shalygin@gmail.com Tested-by: Oleksandr Natalenko Tested-by: Denis Pauk [groeck: update index.rst, do not drop asus_wmi_ec_sensors.rst] Signed-off-by: Guenter Roeck --- Documentation/hwmon/asus_ec_sensors.rst | 52 +++++++++++++++++++++++++++++++++ Documentation/hwmon/index.rst | 1 + 2 files changed, 53 insertions(+) create mode 100644 Documentation/hwmon/asus_ec_sensors.rst (limited to 'Documentation') diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst new file mode 100644 index 000000000000..b12ac7ebeb1a --- /dev/null +++ b/Documentation/hwmon/asus_ec_sensors.rst @@ -0,0 +1,52 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver asus_ec_sensors +================================= + +Supported boards: + * PRIME X570-PRO, + * Pro WS X570-ACE, + * ROG CROSSHAIR VIII DARK HERO, + * ROG CROSSHAIR VIII FORMULA, + * ROG CROSSHAIR VIII HERO, + * ROG CROSSHAIR VIII IMPACT, + * ROG STRIX B550-E GAMING, + * ROG STRIX B550-I GAMING, + * ROG STRIX X570-E GAMING, + * ROG STRIX X570-F GAMING, + * ROG STRIX X570-I GAMING + +Authors: + - Eugene Shalygin + +Description: +------------ +ASUS mainboards publish hardware monitoring information via Super I/O +chip and the ACPI embedded controller (EC) registers. Some of the sensors +are only available via the EC. + +The driver is aware of and reads the following sensors: + +1. Chipset (PCH) temperature +2. CPU package temperature +3. Motherboard temperature +4. Readings from the T_Sensor header +5. VRM temperature +6. CPU_Opt fan RPM +7. VRM heatsink fan RPM +8. Chipset fan RPM +9. Readings from the "Water flow meter" header (RPM) +10. Readings from the "Water In" and "Water Out" temperature headers +11. CPU current + +Sensor values are read from EC registers, and to avoid race with the board +firmware the driver acquires ACPI mutex, the one used by the WMI when its +methods access the EC. + +Module Parameters +----------------- + * mutex_path: string + The driver holds path to the ACPI mutex for each board (actually, + the path is mostly identical for them). If ASUS changes this path + in a future BIOS update, this parameter can be used to override + the stored in the driver value until it gets updated. diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index df20022c741f..b69fdaf1af82 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -43,6 +43,7 @@ Hardware Monitoring Kernel Drivers asb100 asc7621 aspeed-pwm-tacho + asus_ec_sensors asus_wmi_ec_sensors asus_wmi_sensors bcm54140 -- cgit From 06f7d6e75d1232fefc2c3c8567159963c38ec628 Mon Sep 17 00:00:00 2001 From: Marcello Sylvester Bauer Date: Thu, 27 Jan 2022 17:17:27 +0100 Subject: hwmon: (max6639) Update Datasheet URL The old Datasheet does not exist anymore. Signed-off-by: Marcello Sylvester Bauer Link: https://lore.kernel.org/r/76025f40d2684dc0d3ec02c8899b726b07a0e7da.1643299570.git.sylv@sylv.io Signed-off-by: Guenter Roeck --- Documentation/hwmon/max6639.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/max6639.rst b/Documentation/hwmon/max6639.rst index 3da54225f83c..c85d285a3489 100644 --- a/Documentation/hwmon/max6639.rst +++ b/Documentation/hwmon/max6639.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: I2C 0x2c, 0x2e, 0x2f - Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6639.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX6639-MAX6639F.pdf Authors: - He Changqing -- cgit From 2f66cb5bf35265a8c9413a019166a0c29823ce57 Mon Sep 17 00:00:00 2001 From: Eugene Shalygin Date: Thu, 3 Feb 2022 21:30:52 +0100 Subject: hwmon: (asus-ec-sensors) Add Crosshair VIII Hero WiFi The Wi-Fi variant of Crosshair VIII Hero provides the same sensors, which was tested by a Libre Hardware Monitor user [1]. [1] https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/pull/453#issuecomment-1028398487 Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20220203203052.441712-1-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck --- Documentation/hwmon/asus_ec_sensors.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst index b12ac7ebeb1a..22de1b037cfb 100644 --- a/Documentation/hwmon/asus_ec_sensors.rst +++ b/Documentation/hwmon/asus_ec_sensors.rst @@ -7,6 +7,7 @@ Supported boards: * PRIME X570-PRO, * Pro WS X570-ACE, * ROG CROSSHAIR VIII DARK HERO, + * ROG CROSSHAIR VIII HERO (WI-FI) * ROG CROSSHAIR VIII FORMULA, * ROG CROSSHAIR VIII HERO, * ROG CROSSHAIR VIII IMPACT, -- cgit From f545a2fd473606809cb4a5045919a10194d86d36 Mon Sep 17 00:00:00 2001 From: Eugene Shalygin Date: Tue, 8 Feb 2022 10:42:43 +0100 Subject: hwmon: (asus-ec-sensors) add CPU core voltage A user discovered [1] the CPU Core voltage sensor, which spans 2 registers and provides output in mV. Althroug the discovery was made with a X470 chipset, the sensor is present in X570 (tested with C8H). For now simply add it to each board with the CPU current sensor present. [1] https://github.com/zeule/asus-ec-sensors/issues/12 Signed-off-by: Eugene Shalygin Tested-by: Oleksandr Natalenko Tested-by: Denis Pauk Link: https://lore.kernel.org/r/20220208094244.1106312-1-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck --- Documentation/hwmon/asus_ec_sensors.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst index 22de1b037cfb..e7e8f1640f45 100644 --- a/Documentation/hwmon/asus_ec_sensors.rst +++ b/Documentation/hwmon/asus_ec_sensors.rst @@ -39,6 +39,7 @@ The driver is aware of and reads the following sensors: 9. Readings from the "Water flow meter" header (RPM) 10. Readings from the "Water In" and "Water Out" temperature headers 11. CPU current +12. CPU core voltage Sensor values are read from EC registers, and to avoid race with the board firmware the driver acquires ACPI mutex, the one used by the WMI when its -- cgit From ec3db1ecf63e02265b4e93ddb1ba5cc6858c3972 Mon Sep 17 00:00:00 2001 From: Armin Wolf Date: Tue, 15 Feb 2022 20:11:12 +0100 Subject: hwmon: (dell-smm) Add SMM interface documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document the SMM interface as requested by Pali Rohar. Since Dell does not offer any offical documentation regarding the SMM interface, the necessary information was extracted from the dell_smm_hwmon driver and other sources. Suggested-by: Pali Rohár Signed-off-by: Armin Wolf Reviewed-by: Pali Rohár Link: https://lore.kernel.org/r/20220215191113.16640-7-W_Armin@gmx.de Signed-off-by: Guenter Roeck --- Documentation/hwmon/dell-smm-hwmon.rst | 180 +++++++++++++++++++++++++++++++++ 1 file changed, 180 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/dell-smm-hwmon.rst b/Documentation/hwmon/dell-smm-hwmon.rst index beec88491171..d3323a96665d 100644 --- a/Documentation/hwmon/dell-smm-hwmon.rst +++ b/Documentation/hwmon/dell-smm-hwmon.rst @@ -165,3 +165,183 @@ obtain the same information and to control the fan status. The ioctl interface can be accessed from C programs or from shell using the i8kctl utility. See the source file of ``i8kutils`` for more information on how to use the ioctl interface. + +SMM Interface +------------- + +.. warning:: The SMM interface was reverse-engineered by trial-and-error + since Dell did not provide any Documentation, + please keep that in mind. + +The driver uses the SMM interface to send commands to the system BIOS. +This interface is normally used by Dell's 32-bit diagnostic program or +on newer notebook models by the buildin BIOS diagnostics. +The SMM is triggered by writing to the special ioports ``0xb2`` and ``0x84``, +and may cause short hangs when the BIOS code is taking too long to +execute. + +The SMM handler inside the system BIOS looks at the contents of the +``eax``, ``ebx``, ``ecx``, ``edx``, ``esi`` and ``edi`` registers. +Each register has a special purpose: + +=============== ================================== +Register Purpose +=============== ================================== +eax Holds the command code before SMM, + holds the first result after SMM. +ebx Holds the arguments. +ecx Unknown, set to 0. +edx Holds the second result after SMM. +esi Unknown, set to 0. +edi Unknown, set to 0. +=============== ================================== + +The SMM handler can signal a failure by either: + +- setting the lower sixteen bits of ``eax`` to ``0xffff`` +- not modifying ``eax`` at all +- setting the carry flag + +SMM command codes +----------------- + +=============== ======================= ================================================ +Command Code Command Name Description +=============== ======================= ================================================ +``0x0025`` Get Fn key status Returns the Fn key pressed after SMM: + + - 9th bit in ``eax`` indicates Volume up + - 10th bit in ``eax`` indicates Volume down + - both bits indicate Volume mute + +``0xa069`` Get power status Returns current power status after SMM: + + - 1st bit in ``eax`` indicates Battery connected + - 3th bit in ``eax`` indicates AC connected + +``0x00a3`` Get fan state Returns current fan state after SMM: + + - 1st byte in ``eax`` holds the current + fan state (0 - 2 or 3) + +``0x01a3`` Set fan state Sets the fan speed: + + - 1st byte in ``ebx`` holds the fan number + - 2nd byte in ``ebx`` holds the desired + fan state (0 - 2 or 3) + +``0x02a3`` Get fan speed Returns the current fan speed in RPM: + + - 1st byte in ``ebx`` holds the fan number + - 1st word in ``eax`` holds the current + fan speed in RPM (after SMM) + +``0x03a3`` Get fan type Returns the fan type: + + - 1st byte in ``ebx`` holds the fan number + - 1st byte in ``eax`` holds the + fan type (after SMM): + + - 5th bit indicates docking fan + - 1 indicates Processor fan + - 2 indicates Motherboard fan + - 3 indicates Video fan + - 4 indicates Power supply fan + - 5 indicates Chipset fan + - 6 indicates other fan type + +``0x04a3`` Get nominal fan speed Returns the nominal RPM in each fan state: + + - 1st byte in ``ebx`` holds the fan number + - 2nd byte in ``ebx`` holds the fan state + in question (0 - 2 or 3) + - 1st word in ``eax`` holds the nominal + fan speed in RPM (after SMM) + +``0x05a3`` Get fan speed tolerance Returns the speed tolerance for each fan state: + + - 1st byte in ``ebx`` holds the fan number + - 2nd byte in ``ebx`` holds the fan state + in question (0 - 2 or 3) + - 1st byte in ``eax`` returns the speed + tolerance + +``0x10a3`` Get sensor temperature Returns the measured temperature: + + - 1st byte in ``ebx`` holds the sensor number + - 1st byte in ``eax`` holds the measured + temperature (after SMM) + +``0x11a3`` Get sensor type Returns the sensor type: + + - 1st byte in ``ebx`` holds the sensor number + - 1st byte in ``eax`` holds the + temperature type (after SMM): + + - 1 indicates CPU sensor + - 2 indicates GPU sensor + - 3 indicates SODIMM sensor + - 4 indicates other sensor type + - 5 indicates Ambient sensor + - 6 indicates other sensor type + +``0xfea3`` Get SMM signature Returns Dell signature if interface + is supported (after SMM): + + - ``eax`` holds 1145651527 + (0x44494147 or "DIAG") + - ``edx`` holds 1145392204 + (0x44454c4c or "DELL") + +``0xffa3`` Get SMM signature Same as ``0xfea3``, check both. +=============== ======================= ================================================ + +There are additional commands for enabling (``0x31a3`` or ``0x35a3``) and +disabling (``0x30a3`` or ``0x34a3``) automatic fan speed control. +The commands are however causing severe sideeffects on many machines, so +they are not used by default. + +On several machines (Inspiron 3505, Precision 490, Vostro 1720, ...), the +fans supports a 4th "magic" state, which signals the BIOS that automatic +fan control should be enabled for a specific fan. +However there are also some machines who do support a 4th regular fan state too, +but in case of the "magic" state, the nominal RPM reported for this state is a +placeholder value, which however is not always detectable. + +Firmware Bugs +------------- + +The SMM calls can behave erratic on some machines: + +======================================================= ================= +Firmware Bug Affected Machines +======================================================= ================= +Reading of fan states return spurious errors. Precision 490 + +Reading of fan types causes erratic fan behaviour. Studio XPS 8000 + + Studio XPS 8100 + + Inspiron 580 + +Fan-related SMM calls take too long (about 500ms). Inspiron 7720 + + Vostro 3360 + + XPS 13 9333 + + XPS 15 L502X +======================================================= ================= + +In case you experience similar issues on your Dell machine, please +submit a bugreport on bugzilla to we can apply workarounds. + +Limitations +----------- + +The SMM calls can take too long to execute on some machines, causing +short hangs and/or audio glitches. +Also the fan state needs to be restored after suspend, as well as +the automatic mode settings. +When reading a temperature sensor, values above 127 degrees indicate +a BIOS read error or a deactivated sensor. -- cgit From 4b1dd41cf211c2c1b93cab77aebbb0a01157d3ff Mon Sep 17 00:00:00 2001 From: Marcello Sylvester Bauer Date: Mon, 21 Feb 2022 10:42:04 +0100 Subject: dt-bindings: vendor-prefixes: add Vicor Corporation Add vendor prefix for Vicor Corporation. Signed-off-by: Marcello Sylvester Bauer Acked-by: Rob Herring Link: https://lore.kernel.org/r/5b487a0b68d58b64022662f1e527ac80a6ad81ef.1645435888.git.sylv@sylv.io Signed-off-by: Guenter Roeck --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 294093d45a23..047a83a089ce 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1298,6 +1298,8 @@ patternProperties: description: Vertexcom Technologies, Inc. "^via,.*": description: VIA Technologies, Inc. + "^vicor,.*": + description: Vicor Corporation "^videostrong,.*": description: Videostrong Technology Co., Ltd. "^virtio,.*": -- cgit From b7b94f15e55223e75b588863075a10ae79445db4 Mon Sep 17 00:00:00 2001 From: Marcello Sylvester Bauer Date: Mon, 21 Feb 2022 10:42:05 +0100 Subject: dt-bindings:trivial-devices: Add pli1209bc Add trivial device entry for PLI1209BC Digital Supervisor from Vicor Corporation. Signed-off-by: Marcello Sylvester Bauer Acked-by: Rob Herring Link: https://lore.kernel.org/r/15a9fcfb5b9592c6d87f12c2a4c77fd069f5cfff.1645435888.git.sylv@sylv.io Signed-off-by: Guenter Roeck --- Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 091792ba993e..d03d90360aa0 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -354,6 +354,8 @@ properties: - ti,tps544c25 # Winbond/Nuvoton H/W Monitor - winbond,w83793 + # Vicor Corporation Digital Supervisor + - vicor,pli1209bc # i2c trusted platform module (TPM) - winbond,wpct301 -- cgit From d0cd978513f2e37c353ec2dcfbd863f97edb1dcd Mon Sep 17 00:00:00 2001 From: Marcello Sylvester Bauer Date: Mon, 21 Feb 2022 10:42:06 +0100 Subject: hwmon: (pmbus) Add support for pli1209bc PLI1209BC is a Digital Supervisor from Vicor Corporation. Signed-off-by: Marcello Sylvester Bauer Link: https://lore.kernel.org/r/4e016e66275bc46c90974aec18b150c874e64787.1645435888.git.sylv@sylv.io Signed-off-by: Guenter Roeck --- Documentation/hwmon/index.rst | 1 + Documentation/hwmon/pli1209bc.rst | 75 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 76 insertions(+) create mode 100644 Documentation/hwmon/pli1209bc.rst (limited to 'Documentation') diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index b69fdaf1af82..075d1defcd20 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -161,6 +161,7 @@ Hardware Monitoring Kernel Drivers pc87427 pcf8591 pim4328 + pli1209bc pm6764tr pmbus powr1220 diff --git a/Documentation/hwmon/pli1209bc.rst b/Documentation/hwmon/pli1209bc.rst new file mode 100644 index 000000000000..ea5b3f68a515 --- /dev/null +++ b/Documentation/hwmon/pli1209bc.rst @@ -0,0 +1,75 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver pli1209bc +======================= + +Supported chips: + + * Digital Supervisor PLI1209BC + + Prefix: 'pli1209bc' + + Addresses scanned: 0x50 - 0x5F + + Datasheet: https://www.vicorpower.com/documents/datasheets/ds-PLI1209BCxyzz-VICOR.pdf + +Authors: + - Marcello Sylvester Bauer + +Description +----------- + +The Vicor PLI1209BC is an isolated digital power system supervisor that provides +a communication interface between a host processor and one Bus Converter Module +(BCM). The PLI communicates with a system controller via a PMBus compatible +interface over an isolated UART interface. Through the PLI, the host processor +can configure, set protection limits, and monitor the BCM. + +Sysfs entries +------------- + +======================= ======================================================== +in1_label "vin2" +in1_input Input voltage. +in1_rated_min Minimum rated input voltage. +in1_rated_max Maximum rated input voltage. +in1_max Maximum input voltage. +in1_max_alarm Input voltage high alarm. +in1_crit Critical input voltage. +in1_crit_alarm Input voltage critical alarm. + +in2_label "vout2" +in2_input Output voltage. +in2_rated_min Minimum rated output voltage. +in2_rated_max Maximum rated output voltage. +in2_alarm Output voltage alarm + +curr1_label "iin2" +curr1_input Input current. +curr1_max Maximum input current. +curr1_max_alarm Maximum input current high alarm. +curr1_crit Critical input current. +curr1_crit_alarm Input current critical alarm. + +curr2_label "iout2" +curr2_input Output current. +curr2_crit Critical output current. +curr2_crit_alarm Output current critical alarm. +curr2_max Maximum output current. +curr2_max_alarm Output current high alarm. + +power1_label "pin2" +power1_input Input power. +power1_alarm Input power alarm. + +power2_label "pout2" +power2_input Output power. +power2_rated_max Maximum rated output power. + +temp1_input Die temperature. +temp1_alarm Die temperature alarm. +temp1_max Maximum die temperature. +temp1_max_alarm Die temperature high alarm. +temp1_crit Critical die temperature. +temp1_crit_alarm Die temperature critical alarm. +======================= ======================================================== -- cgit From 64b631fb0c6f7e5fbbe0d641556e07e7a8a272ef Mon Sep 17 00:00:00 2001 From: Christian Lamparter Date: Fri, 18 Feb 2022 10:06:42 +0100 Subject: dt-bindings: Add ti,tmp125 temperature sensor binding MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From the freely available Texas Instruments' TMP125 datasheet: "The TMP125 is an SPI-compatible temperature sensor available in the tiny SOT23-6 package. Requiring no external components, the TMP125 is capable of measuring temperatures within 2 degree C of accuracy over a temperature range of −25 degree C to +85 degree C and 2.5 degree C of accuracy over −40 degree C to +125 degree C." The TMP125 is very similar to the TMP121/TMP122 series of familiar chips. Signed-off-by: Christian Lamparter Acked-by: Krzysztof Kozlowski Acked-by: Rob Herring Link: https://lore.kernel.org/r/d3538ba9beededfe3a9ad5dab4903a6a01834822.1645175187.git.chunkeey@gmail.com Signed-off-by: Guenter Roeck --- Documentation/devicetree/bindings/trivial-devices.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index d03d90360aa0..1c49bbc654ee 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -337,6 +337,7 @@ properties: # Thermometer with SPI interface - ti,tmp121 - ti,tmp122 + - ti,tmp125 # Digital Temperature Sensor - ti,tmp275 # TI DC-DC converter on PMBus -- cgit From cd929672a9ef644aca12de59a75de5f061d5983d Mon Sep 17 00:00:00 2001 From: Christian Lamparter Date: Fri, 18 Feb 2022 10:06:43 +0100 Subject: hwmon: (lm70) Add ti,tmp125 support The TMP125 is a 2 degree Celsius accurate Digital Temperature Sensor with a SPI interface. The temperature register is a 16-bit, read-only register. The MSB (Bit 15) is a leading zero and never set. Bits 14 to 5 are the 1+9 temperature data bits in a two's complement format. Bits 4 to 0 are useless copies of Bit 5 value and therefore ignored. This was tested on a Aerohive HiveAP-350. Bonus: lm70 supports TMP122/TMP124 as well. I added them to the Kconfig module description. Signed-off-by: Christian Lamparter Link: https://lore.kernel.org/r/43b19cbd4e7f51e9509e561b02b5d8d0e7079fac.1645175187.git.chunkeey@gmail.com Signed-off-by: Guenter Roeck --- Documentation/hwmon/lm70.rst | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm70.rst b/Documentation/hwmon/lm70.rst index 6ddc5b67ccb5..11303a7e16a8 100644 --- a/Documentation/hwmon/lm70.rst +++ b/Documentation/hwmon/lm70.rst @@ -15,6 +15,10 @@ Supported chips: Information: https://www.ti.com/product/tmp122 + * Texas Instruments TMP125 + + Information: https://www.ti.com/product/tmp125 + * National Semiconductor LM71 Datasheet: https://www.ti.com/product/LM71 @@ -53,6 +57,9 @@ The LM74 and TMP121/TMP122/TMP123/TMP124 are very similar; main difference is The TMP122/TMP124 also feature configurable temperature thresholds. +The TMP125 is less accurate and provides 10-bit temperature data +with 0.25 degrees Celsius resolution. + The LM71 is also very similar; main difference is 14-bit temperature data (0.03125 degrees celsius resolution). -- cgit From aa9f833dfc128169a1162261c5641aa516b4a231 Mon Sep 17 00:00:00 2001 From: Armin Wolf Date: Thu, 24 Feb 2022 07:12:10 +0100 Subject: hwmon: (sch5627) Add pwmX_auto_channels_temp support After doing some research, it seems that Fujitsu's hardware monitoring solution exports data describing which temperature sensors affect which fans, similar to the data in fan_source of the ftsteutates driver. Writing 0 into these registers forces the fans to full speed. Export this data with standard attributes. Signed-off-by: Armin Wolf Link: https://lore.kernel.org/r/20220224061210.16452-3-W_Armin@gmx.de Signed-off-by: Guenter Roeck --- Documentation/hwmon/sch5627.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/sch5627.rst b/Documentation/hwmon/sch5627.rst index 187682e99114..ecb4fc84d045 100644 --- a/Documentation/hwmon/sch5627.rst +++ b/Documentation/hwmon/sch5627.rst @@ -20,6 +20,10 @@ Description SMSC SCH5627 Super I/O chips include complete hardware monitoring capabilities. They can monitor up to 5 voltages, 4 fans and 8 temperatures. +In addition, the SCH5627 exports data describing which temperature sensors +affect the speed of each fan. Setting pwmX_auto_channels_temp to 0 forces +the corresponding fan to full speed until another value is written. + The SMSC SCH5627 hardware monitoring part also contains an integrated watchdog. In order for this watchdog to function some motherboard specific initialization most be done by the BIOS, so if the watchdog is not enabled -- cgit From 2fd3eec19c6e0a2c218853db9df27d4e74921673 Mon Sep 17 00:00:00 2001 From: Aleksa Savic Date: Sun, 27 Feb 2022 21:56:25 +0100 Subject: hwmon: (aquacomputer_d5next) Add support for Aquacomputer Farbwerk 360 Extend aquacomputer_d5next driver to expose hardware temperature sensors of the Aquacomputer Farbwerk 360 RGB controller, which communicates through a proprietary USB HID protocol. Four temperature sensors are available. Additionally, serial number and firmware version are exposed through debugfs. This driver has been tested on x86_64. Signed-off-by: Aleksa Savic Signed-off-by: Guenter Roeck --- Documentation/hwmon/aquacomputer_d5next.rst | 49 ++++++++++++++--------------- 1 file changed, 23 insertions(+), 26 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/aquacomputer_d5next.rst b/Documentation/hwmon/aquacomputer_d5next.rst index 1f4bb4ba2e4b..3373e27b707d 100644 --- a/Documentation/hwmon/aquacomputer_d5next.rst +++ b/Documentation/hwmon/aquacomputer_d5next.rst @@ -6,22 +6,21 @@ Kernel driver aquacomputer-d5next Supported devices: * Aquacomputer D5 Next watercooling pump +* Aquacomputer Farbwerk 360 RGB controller Author: Aleksa Savic Description ----------- -This driver exposes hardware sensors of the Aquacomputer D5 Next watercooling -pump, which communicates through a proprietary USB HID protocol. +This driver exposes hardware sensors of listed Aquacomputer devices, which +communicate through proprietary USB HID protocols. -Available sensors are pump and fan speed, power, voltage and current, as -well as coolant temperature. Also available through debugfs are the serial -number, firmware version and power-on count. - -Attaching a fan is optional and allows it to be controlled using temperature -curves directly from the pump. If it's not connected, the fan-related sensors -will report zeroes. +For the D5 Next pump, available sensors are pump and fan speed, power, voltage +and current, as well as coolant temperature. Also available through debugfs are +the serial number, firmware version and power-on count. Attaching a fan to it is +optional and allows it to be controlled using temperature curves directly from the +pump. If it's not connected, the fan-related sensors will report zeroes. The pump can be configured either through software or via its physical interface. Configuring the pump through this driver is not implemented, as it @@ -29,33 +28,31 @@ seems to require sending it a complete configuration. That includes addressable RGB LEDs, for which there is no standard sysfs interface. Thus, that task is better suited for userspace tools. +The Farbwerk 360 exposes four temperature sensors. Depending on the device, +not all sysfs and debugfs entries will be available. + Usage notes ----------- -The pump communicates via HID reports. The driver is loaded automatically by +The devices communicate via HID reports. The driver is loaded automatically by the kernel and supports hotswapping. Sysfs entries ------------- -============ ============================================= -temp1_input Coolant temperature (in millidegrees Celsius) -fan1_input Pump speed (in RPM) -fan2_input Fan speed (in RPM) -power1_input Pump power (in micro Watts) -power2_input Fan power (in micro Watts) -in0_input Pump voltage (in milli Volts) -in1_input Fan voltage (in milli Volts) -in2_input +5V rail voltage (in milli Volts) -curr1_input Pump current (in milli Amperes) -curr2_input Fan current (in milli Amperes) -============ ============================================= +================ ============================================= +temp[1-4]_input Temperature sensors (in millidegrees Celsius) +fan[1-2]_input Pump/fan speed (in RPM) +power[1-2]_input Pump/fan power (in micro Watts) +in[0-2]_input Pump/fan voltage (in milli Volts) +curr[1-2]_input Pump/fan current (in milli Amperes) +================ ============================================= Debugfs entries --------------- -================ =============================================== -serial_number Serial number of the pump +================ ================================================= +serial_number Serial number of the device firmware_version Version of installed firmware -power_cycles Count of how many times the pump was powered on -================ =============================================== +power_cycles Count of how many times the device was powered on +================ ================================================= -- cgit From 5c139ce9e1c2737a37454b607912da619d09637e Mon Sep 17 00:00:00 2001 From: Khazhismel Kumykov Date: Fri, 18 Feb 2022 16:16:01 -0800 Subject: scsi: core: docs: Update notes about scsi_times_out Most importantly: eh_timed_out() is not limited by scmd->allowed, and can reset timer forever. Fixes: c829c394165f ("[SCSI] FC transport : Avoid device offline cases by stalling aborts until device unblocked") Link: https://lore.kernel.org/r/20220219001601.3534043-1-khazhy@google.com Reviewed-by: Bart Van Assche Signed-off-by: Khazhismel Kumykov Signed-off-by: Martin K. Petersen --- Documentation/scsi/scsi_eh.rst | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scsi/scsi_eh.rst b/Documentation/scsi/scsi_eh.rst index 7d78c2475615..885395dc1f15 100644 --- a/Documentation/scsi/scsi_eh.rst +++ b/Documentation/scsi/scsi_eh.rst @@ -95,19 +95,18 @@ function - BLK_EH_RESET_TIMER This indicates that more time is required to finish the - command. Timer is restarted. This action is counted as a - retry and only allowed scmd->allowed + 1(!) times. Once the - limit is reached, action for BLK_EH_DONE is taken instead. + command. Timer is restarted. - BLK_EH_DONE eh_timed_out() callback did not handle the command. Step #2 is taken. - 2. scsi_abort_command() is invoked to schedule an asynchrous abort. - Asynchronous abort are not invoked for commands which the - SCSI_EH_ABORT_SCHEDULED flag is set (this indicates that the command - already had been aborted once, and this is a retry which failed), - or when the EH deadline is expired. In these case Step #3 is taken. + 2. scsi_abort_command() is invoked to schedule an asynchronous abort which may + issue a retry scmd->allowed + 1 times. Asynchronous aborts are not invoked + for commands for which the SCSI_EH_ABORT_SCHEDULED flag is set (this + indicates that the command already had been aborted once, and this is a + retry which failed), when retries are exceeded, or when the EH deadline is + expired. In these cases Step #3 is taken. 3. scsi_eh_scmd_add(scmd, SCSI_EH_CANCEL_CMD) is invoked for the command. See [1-4] for more information. -- cgit From 4db3189ce0621be901f249f8cd8226c977dd601d Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Thu, 24 Feb 2022 14:24:25 +0100 Subject: drm/todo: Update panic handling todo Some things changed, and add two useful links. v2: Also include a link to the QR encoding work. Plus review from Javier. v3: Fix typo Guilherme spotted. Reviewed-by: Guilherme G. Piccoli Acked-by: Pekka Paalanen Reviewed-by: Javier Martinez Canillas Cc: Javier Martinez Canillas Cc: Pekka Paalanen Cc: gpiccoli@igalia.com Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220224132425.3463791-1-daniel.vetter@ffwll.ch --- Documentation/gpu/todo.rst | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 1b2372ef4131..d6a7ebf717be 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -499,8 +499,12 @@ This is a really varied tasks with lots of little bits and pieces: achieved by using an IPI to the local processor. * There's a massive confusion of different panic handlers. DRM fbdev emulation - helpers have one, but on top of that the fbcon code itself also has one. We - need to make sure that they stop fighting over each another. + helpers had their own (long removed), but on top of that the fbcon code itself + also has one. We need to make sure that they stop fighting over each other. + This is worked around by checking ``oops_in_progress`` at various entry points + into the DRM fbdev emulation helpers. A much cleaner approach here would be to + switch fbcon to the `threaded printk support + `_. * ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and isn't a full solution for panic paths. We need to make sure that it only @@ -512,16 +516,15 @@ This is a really varied tasks with lots of little bits and pieces: even spinlocks (because NMI and hardirq can panic too). We need to either make sure to not call such paths, or trylock everything. Really tricky. -* For the above locking troubles reasons it's pretty much impossible to - attempt a synchronous modeset from panic handlers. The only thing we could - try to achive is an atomic ``set_base`` of the primary plane, and hope that - it shows up. Everything else probably needs to be delayed to some worker or - something else which happens later on. Otherwise it just kills the box - harder, prevent the panic from going out on e.g. netconsole. +* A clean solution would be an entirely separate panic output support in KMS, + bypassing the current fbcon support. See `[PATCH v2 0/3] drm: Add panic handling + `_. -* There's also proposal for a simplied DRM console instead of the full-blown - fbcon and DRM fbdev emulation. Any kind of panic handling tricks should - obviously work for both console, in case we ever get kmslog merged. +* Encoding the actual oops and preceding dmesg in a QR might help with the + dread "important stuff scrolled away" problem. See `[RFC][PATCH] Oops messages + transfer using QR codes + `_ + for some example code that could be reused. Contact: Daniel Vetter -- cgit From 2f3468b82db97f48894252c14bb240165f89806b Mon Sep 17 00:00:00 2001 From: Noralf Trønnes Date: Sun, 27 Feb 2022 13:47:09 +0100 Subject: dt-bindings: display: add bindings for MIPI DBI compatible SPI panels MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add binding for MIPI DBI compatible SPI panels. v6: - Fix indentation (Rob) v5: - Add sainsmart18 to compatible items (Rob) - Expand write-only description (Sam) v4: - There should only be two compatible (Maxime) - s/panel-dbi-spi/panel-mipi-dbi-spi/in compatible v3: - Move properties to Device Tree (Maxime) - Use contains for compatible (Maxime) - Add backlight property to example - Flesh out description v2: - Fix path for panel-common.yaml - Use unevaluatedProperties - Drop properties which are in the allOf section - Drop model property (Rob) Acked-by: Maxime Ripard Acked-by: Sam Ravnborg Reviewed-by: Rob Herring Signed-off-by: Noralf Trønnes Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20220227124713.39766-2-noralf@tronnes.org --- .../bindings/display/panel/panel-mipi-dbi-spi.yaml | 126 +++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml new file mode 100644 index 000000000000..f29789994b18 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-mipi-dbi-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MIPI DBI SPI Panel + +maintainers: + - Noralf Trønnes + +description: | + This binding is for display panels using a MIPI DBI compatible controller + in SPI mode. + + The MIPI Alliance Standard for Display Bus Interface defines the electrical + and logical interfaces for display controllers historically used in mobile + phones. The standard defines 4 display architecture types and this binding is + for type 1 which has full frame memory. There are 3 interface types in the + standard and type C is the serial interface. + + The standard defines the following interface signals for type C: + - Power: + - Vdd: Power supply for display module + - Vddi: Logic level supply for interface signals + Combined into one in this binding called: power-supply + - Interface: + - CSx: Chip select + - SCL: Serial clock + - Dout: Serial out + - Din: Serial in + - SDA: Bidrectional in/out + - D/CX: Data/command selection, high=data, low=command + Called dc-gpios in this binding. + - RESX: Reset when low + Called reset-gpios in this binding. + + The type C interface has 3 options: + + - Option 1: 9-bit mode and D/CX as the 9th bit + | Command | the next command or following data | + |<0>|| + + - Option 2: 16-bit mode and D/CX as a 9th bit + | Command or data | + || + + - Option 3: 8-bit mode and D/CX as a separate interface line + | Command or data | + || + + The panel resolution is specified using the panel-timing node properties + hactive (width) and vactive (height). The other mandatory panel-timing + properties should be set to zero except clock-frequency which can be + optionally set to inform about the actual pixel clock frequency. + + If the panel is wired to the controller at an offset specify this using + hback-porch (x-offset) and vback-porch (y-offset). + +allOf: + - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +properties: + compatible: + items: + - enum: + - sainsmart18 + - const: panel-mipi-dbi-spi + + write-only: + type: boolean + description: + Controller is not readable (ie. Din (MISO on the SPI interface) is not + wired up). + + dc-gpios: + maxItems: 1 + description: | + Controller data/command selection (D/CX) in 4-line SPI mode. + If not set, the controller is in 3-line SPI mode. + +required: + - compatible + - reg + - panel-timing + +unevaluatedProperties: false + +examples: + - | + #include + + spi { + #address-cells = <1>; + #size-cells = <0>; + + display@0{ + compatible = "sainsmart18", "panel-mipi-dbi-spi"; + reg = <0>; + spi-max-frequency = <40000000>; + + dc-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio 25 GPIO_ACTIVE_HIGH>; + write-only; + + backlight = <&backlight>; + + width-mm = <35>; + height-mm = <28>; + + panel-timing { + hactive = <160>; + vactive = <128>; + hback-porch = <0>; + vback-porch = <0>; + clock-frequency = <0>; + hfront-porch = <0>; + hsync-len = <0>; + vfront-porch = <0>; + vsync-len = <0>; + }; + }; + }; + +... -- cgit From d065a283fe8109a055930fc438eeea81d7f121df Mon Sep 17 00:00:00 2001 From: Liam Beguin Date: Sat, 12 Feb 2022 21:57:38 -0500 Subject: dt-bindings: iio: afe: add bindings for temperature-sense-rtd An ADC is often used to measure other quantities indirectly. This binding describe one case, the measurement of a temperature through the voltage across an RTD resistor such as a PT1000. Signed-off-by: Liam Beguin Reviewed-by: Rob Herring Reviewed-by: Peter Rosin Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220213025739.2561834-10-liambeguin@gmail.com Signed-off-by: Jonathan Cameron --- .../bindings/iio/afe/temperature-sense-rtd.yaml | 101 +++++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/afe/temperature-sense-rtd.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/afe/temperature-sense-rtd.yaml b/Documentation/devicetree/bindings/iio/afe/temperature-sense-rtd.yaml new file mode 100644 index 000000000000..336ce96371db --- /dev/null +++ b/Documentation/devicetree/bindings/iio/afe/temperature-sense-rtd.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/afe/temperature-sense-rtd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Temperature Sense RTD + +maintainers: + - Liam Beguin + +description: | + RTDs (Resistance Temperature Detectors) are a kind of temperature sensors + used to get a linear voltage to temperature reading within a give range + (usually 0 to 100 degrees Celsius). + + When an io-channel measures the output voltage across an RTD such as a + PT1000, the interesting measurement is almost always the corresponding + temperature, not the voltage output. This binding describes such a circuit. + + The general transfer function here is (using SI units) + + V = R(T) * iexc + R(T) = r0 * (1 + alpha * T) + T = 1 / (alpha * r0 * iexc) * (V - r0 * iexc) + + The following circuit matches what's in the examples section. + + 5V0 + ----- + | + +---+----+ + | R 5k | + +---+----+ + | + V 1mA + | + +---- Vout + | + +---+----+ + | PT1000 | + +---+----+ + | + ----- + GND + +properties: + compatible: + const: temperature-sense-rtd + + io-channels: + maxItems: 1 + description: | + Channel node of a voltage io-channel. + + '#io-channel-cells': + const: 0 + + excitation-current-microamp: + description: The current fed through the RTD sensor. + + alpha-ppm-per-celsius: + description: | + alpha can also be expressed in micro-ohms per ohm Celsius. It's a linear + approximation of the resistance versus temperature relationship + between 0 and 100 degrees Celsius. + + alpha = (R_100 - R_0) / (100 * R_0) + + Where, R_100 is the resistance of the sensor at 100 degrees Celsius, and + R_0 (or r-naught-ohms) is the resistance of the sensor at 0 degrees + Celsius. + + Pure platinum has an alpha of 3925. Industry standards such as IEC60751 + and ASTM E-1137 specify an alpha of 3850. + + r-naught-ohms: + description: | + Resistance of the sensor at 0 degrees Celsius. + Common values are 100 for PT100, 500 for PT500, and 1000 for PT1000 + +additionalProperties: false +required: + - compatible + - io-channels + - excitation-current-microamp + - alpha-ppm-per-celsius + - r-naught-ohms + +examples: + - | + pt1000_1: temperature-sensor0 { + compatible = "temperature-sense-rtd"; + #io-channel-cells = <0>; + io-channels = <&temp_adc1 0>; + + excitation-current-microamp = <1000>; /* i = U/R = 5 / 5000 */ + alpha-ppm-per-celsius = <3908>; + r-naught-ohms = <1000>; + }; +... -- cgit From 66724c31c0a0959e540c95a82ed87763df7a5a69 Mon Sep 17 00:00:00 2001 From: Liam Beguin Date: Sat, 12 Feb 2022 21:57:39 -0500 Subject: dt-bindings: iio: afe: add bindings for temperature transducers An ADC is often used to measure other quantities indirectly. This binding describe one case, the measurement of a temperature through a temperature transducer (either voltage or current). Signed-off-by: Liam Beguin Reviewed-by: Rob Herring Reviewed-by: Peter Rosin Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220213025739.2561834-11-liambeguin@gmail.com Signed-off-by: Jonathan Cameron --- .../bindings/iio/afe/temperature-transducer.yaml | 114 +++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/afe/temperature-transducer.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/afe/temperature-transducer.yaml b/Documentation/devicetree/bindings/iio/afe/temperature-transducer.yaml new file mode 100644 index 000000000000..cfbf5350db27 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/afe/temperature-transducer.yaml @@ -0,0 +1,114 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/afe/temperature-transducer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Temperature Transducer + +maintainers: + - Liam Beguin + +description: | + A temperature transducer is a device that converts a thermal quantity + into any other physical quantity. This binding applies to temperature to + voltage (like the LTC2997), and temperature to current (like the AD590) + linear transducers. + In both cases these are assumed to be connected to a voltage ADC. + + When an io-channel measures the output voltage of a temperature analog front + end such as a temperature transducer, the interesting measurement is almost + always the corresponding temperature, not the voltage output. This binding + describes such a circuit. + + The general transfer function here is (using SI units) + V(T) = Rsense * Isense(T) + T = (Isense(T) / alpha) + offset + T = 1 / (Rsense * alpha) * (V + offset * Rsense * alpha) + + When using a temperature to voltage transducer, Rsense is set to 1. + + The following circuits show a temperature to current and a temperature to + voltage transducer that can be used with this binding. + + VCC + ----- + | + +---+---+ + | AD590 | VCC + +---+---+ ----- + | | + V proportional to T +----+----+ + | D+ --+ | + +---- Vout | LTC2997 +--- Vout + | D- --+ | + +---+----+ +---------+ + | Rsense | | + +---+----+ ----- + | GND + ----- + GND + +properties: + compatible: + const: temperature-transducer + + io-channels: + maxItems: 1 + description: | + Channel node of a voltage io-channel. + + '#io-channel-cells': + const: 0 + + sense-offset-millicelsius: + description: | + Temperature offset. + This offset is commonly used to convert from Kelvins to degrees Celsius. + In that case, sense-offset-millicelsius would be set to <(-273150)>. + default: 0 + + sense-resistor-ohms: + description: | + The sense resistor. + By default sense-resistor-ohms cancels out the resistor making the + circuit behave like a temperature transducer. + default: 1 + + alpha-ppm-per-celsius: + description: | + Sometimes referred to as output gain, slope, or temperature coefficient. + + alpha is expressed in parts per million which can be micro-amps per + degrees Celsius or micro-volts per degrees Celsius. The is the main + characteristic of a temperature transducer and should be stated in the + datasheet. + +additionalProperties: false + +required: + - compatible + - io-channels + - alpha-ppm-per-celsius + +examples: + - | + ad950: temperature-sensor-0 { + compatible = "temperature-transducer"; + #io-channel-cells = <0>; + io-channels = <&temp_adc 3>; + + sense-offset-millicelsius = <(-273150)>; /* Kelvin to degrees Celsius */ + sense-resistor-ohms = <8060>; + alpha-ppm-per-celsius = <1>; /* 1 uA/K */ + }; + - | + znq_tmp: temperature-sensor-1 { + compatible = "temperature-transducer"; + #io-channel-cells = <0>; + io-channels = <&temp_adc 2>; + + sense-offset-millicelsius = <(-273150)>; /* Kelvin to degrees Celsius */ + alpha-ppm-per-celsius = <4000>; /* 4 mV/K */ + }; +... -- cgit From 73c022e129630fb16e5eb64d98ce5f14d9b74efd Mon Sep 17 00:00:00 2001 From: Chun-Jie Chen Date: Sun, 30 Jan 2022 09:21:00 +0800 Subject: dt-bindings: power: Add MT8195 power domains Add power domains dt-bindings for MT8195. Signed-off-by: Chun-Jie Chen Acked-by: Rob Herring Reviewed-by: Enric Balletbo i Serra Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220130012104.5292-2-chun-jie.chen@mediatek.com Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/power/mediatek,power-controller.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml index f234a756c193..d6ebd77d28a7 100644 --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml @@ -27,6 +27,7 @@ properties: - mediatek,mt8173-power-controller - mediatek,mt8183-power-controller - mediatek,mt8192-power-controller + - mediatek,mt8195-power-controller '#power-domain-cells': const: 1 @@ -64,6 +65,7 @@ patternProperties: "include/dt-bindings/power/mt8173-power.h" - for MT8173 type power domain. "include/dt-bindings/power/mt8183-power.h" - for MT8183 type power domain. "include/dt-bindings/power/mt8192-power.h" - for MT8192 type power domain. + "include/dt-bindings/power/mt8195-power.h" - for MT8195 type power domain. maxItems: 1 clocks: -- cgit From c8a006896fce9410cb7c479b6b52de553b69bfd9 Mon Sep 17 00:00:00 2001 From: Chun-Jie Chen Date: Tue, 15 Feb 2022 18:49:16 +0800 Subject: dt-bindings: power: Add MT8186 power domains Add power domains dt-bindings for MT8186. Signed-off-by: Chun-Jie Chen Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220215104917.5726-2-chun-jie.chen@mediatek.com Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/power/mediatek,power-controller.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml index d6ebd77d28a7..135c6f722091 100644 --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml @@ -26,6 +26,7 @@ properties: - mediatek,mt8167-power-controller - mediatek,mt8173-power-controller - mediatek,mt8183-power-controller + - mediatek,mt8186-power-controller - mediatek,mt8192-power-controller - mediatek,mt8195-power-controller -- cgit From c4dda0cb4574a5541ca92a6ebb5e33798de1c59e Mon Sep 17 00:00:00 2001 From: Nishanth Menon Date: Fri, 25 Feb 2022 17:32:36 +0530 Subject: dt-bindings: arm: ti: Add bindings for AM625 SoC The AM62 SoC family is the follow on AM335x built on K3 Multicore SoC architecture platform, providing ultra-low-power modes, dual display, multi-sensor edge compute, security and other BOM-saving integration. The AM62 SoC targets broad market to enable applications such as Industrial HMI, PLC/CNC/Robot control, Medical Equipment, Building Automation, Appliances and more. Some highlights of this SoC are: * Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster. Pin-to-pin compatible options for single and quad core are available. * Cortex-M4F for general-purpose or safety usage. * Dual display support, providing 24-bit RBG parallel interface and OLDI/LVDS-4 Lane x2, up to 200MHz pixel clock support for 2K display resolution. * Selectable GPUsupport, up to 8GFLOPS, providing better user experience in 3D graphic display case and Android. * PRU(Programmable Realtime Unit) support for customized programmable interfaces/IOs. * Integrated Giga-bit Ethernet switch supporting up to a total of two external ports (TSN capable). * 9xUARTs, 5xSPI, 6xI2C, 2xUSB2, 3xCAN-FD, 3x eMMC and SD, GPMC for NAND/FPGA connection, OSPI memory controller, 3xMcASP for audio, 1x CSI-RX-4L for Camera, eCAP/eQEP, ePWM, among other peripherals. * Dedicated Centralized System Controller for Security, Power, and Resource Management. * Multiple low power modes support, ex: Deep sleep,Standby, MCU-only, enabling battery powered system design. AM625 is the first device of the family. Add DT bindings for the same. More details can be found in the Technical Reference Manual: https://www.ti.com/lit/pdf/spruiv7 Signed-off-by: Nishanth Menon Signed-off-by: Vignesh Raghavendra Acked-by: Krzysztof Kozlowski Acked-by: Rob Herring Reviewed-by: Bryan Brattlof Link: https://lore.kernel.org/r/20220225120239.1303821-3-vigneshr@ti.com --- Documentation/devicetree/bindings/arm/ti/k3.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index b03c10fa2e7a..61c6ab4f52e2 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -46,6 +46,12 @@ properties: - ti,j7200-evm - const: ti,j7200 + - description: K3 AM625 SoC + items: + - enum: + - ti,am625-sk + - const: ti,am625 + - description: K3 AM642 SoC items: - enum: -- cgit From b59294d65ae5740e79d70c6712d91f76a667ee2e Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Wed, 12 Jan 2022 20:40:54 +0100 Subject: dt-bindings: mmc: sdhci-msm: Add msm8953 compatible Add msm8953 SoC specific compatible strings for qcom-sdhci controller. Signed-off-by: Luca Weiss Acked-by: Konrad Dybcio Link: https://lore.kernel.org/r/20220112194118.178026-6-luca@z3ntu.xyz Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt index 6a8cc261bf61..6216ed777343 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt @@ -14,6 +14,7 @@ Required properties: full compatible strings with SoC and version: "qcom,apq8084-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8226-sdhci", "qcom,sdhci-msm-v4" + "qcom,msm8953-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8974-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8916-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8992-sdhci", "qcom,sdhci-msm-v4" -- cgit From 50d5d1626dac1dfda0d7e8029d0a783d9ef24f83 Mon Sep 17 00:00:00 2001 From: Gabriel Somlo Date: Thu, 13 Jan 2022 12:02:59 -0500 Subject: dt-bindings: mmc: Add bindings for LiteSDCard LiteSDCard is a small footprint, configurable SDCard core for FPGA based SoCs. Signed-off-by: Gabriel Somlo Reviewed-by: Geert Uytterhoeven Reviewed-by: Rob Herring Reviewed-by: Joel Stanley Link: https://lore.kernel.org/r/20220113170300.3555651-3-gsomlo@gmail.com Signed-off-by: Ulf Hansson --- .../devicetree/bindings/mmc/litex,mmc.yaml | 78 ++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 Documentation/devicetree/bindings/mmc/litex,mmc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/litex,mmc.yaml b/Documentation/devicetree/bindings/mmc/litex,mmc.yaml new file mode 100644 index 000000000000..ef9e0da44bf8 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/litex,mmc.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/litex,mmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LiteX LiteSDCard device + +maintainers: + - Gabriel Somlo + +description: | + LiteSDCard is a small footprint, configurable SDCard core for FPGA based + system on chips. + + The hardware source is Open Source and can be found on at + https://github.com/enjoy-digital/litesdcard/. + +allOf: + - $ref: mmc-controller.yaml# + +properties: + compatible: + const: litex,mmc + + reg: + items: + - description: PHY registers + - description: CORE registers + - description: DMA Reader buffer + - description: DMA Writer buffer + - description: IRQ registers + minItems: 4 + + reg-names: + items: + - const: phy + - const: core + - const: reader + - const: writer + - const: irq + minItems: 4 + + clocks: + maxItems: 1 + description: + Handle to reference clock. + + vmmc-supply: + description: + Handle to fixed-voltage supply for the card power. + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - reg-names + - clocks + - vmmc-supply + +additionalProperties: false + +examples: + - | + mmc: mmc@12005000 { + compatible = "litex,mmc"; + reg = <0x12005000 0x100>, + <0x12003800 0x100>, + <0x12003000 0x100>, + <0x12004800 0x100>, + <0x12004000 0x100>; + reg-names = "phy", "core", "reader", "writer", "irq"; + clocks = <&reference_clk>; + vmmc-supply = <&vreg_mmc>; + interrupts = <4>; + }; -- cgit From 43a6a11aaf875bc2567c2d0d930d59d022ee8e68 Mon Sep 17 00:00:00 2001 From: Allen-KH Cheng Date: Fri, 28 Jan 2022 14:20:47 +0800 Subject: dt-bindings: mmc: Add compatible for Mediatek MT8186 This commit adds dt-binding documentation of mmc for Mediatek MT8186 SoC Platform. Signed-off-by: Allen-KH Cheng Link: https://lore.kernel.org/r/20220128062050.23978-5-allen-kh.cheng@mediatek.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/mtk-sd.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index faf89b0c918f..297ada03e3de 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -29,6 +29,9 @@ properties: - items: - const: mediatek,mt7623-mmc - const: mediatek,mt2701-mmc + - items: + - const: mediatek,mt8186-mmc + - const: mediatek,mt8183-mmc - items: - const: mediatek,mt8192-mmc - const: mediatek,mt8183-mmc -- cgit From 02d9c3f436d6ad9ec086d11130be3d22927f457d Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Wed, 2 Feb 2022 19:51:10 -0600 Subject: dt-bindings: mmc: sunxi: Add D1 MMC and eMMC compatibles D1 contains variants of the usual sunxi MMC controller. The eMMC controller has the same parameters as the A100 eMMC controller. The other controllers have a DMA address shift like on A100, but they have a smaller 13-bit size field, making them a new incompatible variant. Signed-off-by: Samuel Holland Acked-by: Maxime Ripard Link: https://lore.kernel.org/r/20220203015112.12008-1-samuel@sholland.org Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml index 4f62ad6ce50c..94e2c6c4e4b7 100644 --- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml @@ -24,6 +24,7 @@ properties: - const: allwinner,sun7i-a20-mmc - const: allwinner,sun8i-a83t-emmc - const: allwinner,sun9i-a80-mmc + - const: allwinner,sun20i-d1-mmc - const: allwinner,sun50i-a64-emmc - const: allwinner,sun50i-a64-mmc - const: allwinner,sun50i-a100-emmc @@ -49,6 +50,9 @@ properties: - items: - const: allwinner,sun50i-h6-mmc - const: allwinner,sun50i-a64-mmc + - items: + - const: allwinner,sun20i-d1-emmc + - const: allwinner,sun50i-a100-emmc - items: - const: allwinner,sun50i-h616-emmc - const: allwinner,sun50i-a100-emmc -- cgit From 3569a139a8739949d187fbe0e04949d1d2cb1330 Mon Sep 17 00:00:00 2001 From: Aswath Govindraju Date: Wed, 16 Feb 2022 19:13:46 +0530 Subject: dt-bindings: mmc: sdhci-am654: Add compatible string for AM62 SoC Add compatible string for AM62 SoC in device tree binding of AM654 SDHCI module as the same IP is used. Signed-off-by: Aswath Govindraju Link: https://lore.kernel.org/r/20220216134346.11029-1-a-govindraju@ti.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/sdhci-am654.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml index 9fbf16b3bc8d..0566493c4def 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml @@ -21,6 +21,7 @@ properties: - const: ti,j721e-sdhci-4bit - const: ti,am64-sdhci-8bit - const: ti,am64-sdhci-4bit + - const: ti,am62-sdhci - items: - const: ti,j7200-sdhci-8bit - const: ti,j721e-sdhci-8bit -- cgit From b9df01a50d516d7a62d5fd3eff5b57981f283be1 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Tue, 15 Feb 2022 16:15:02 +0800 Subject: dt-bindings: mmc: imx-esdhc: Add imx93 compatible string Add i.MX93 compatible string, it uses two compatible strings. Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20220215081502.789067-1-peng.fan@oss.nxp.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index 17acbc665f5a..7dbbcae9485c 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -47,6 +47,7 @@ properties: - const: fsl,imx7d-usdhc - items: - enum: + - fsl,imx93-usdhc - fsl,imx8ulp-usdhc - const: fsl,imx8mm-usdhc -- cgit From 4edb4ffe39c9bdaec50186d0ca583a7ff01143de Mon Sep 17 00:00:00 2001 From: Oded Gabbay Date: Wed, 5 Jan 2022 23:14:45 +0200 Subject: habanalabs/gaudi: disable CGM permanently Due to the need of SynapseAI to configure all TPC engines from a single QMAN, the driver must disable CGM and never allow the user to enable it. Otherwise, the configuration of the TPC engines will fail. Signed-off-by: Oded Gabbay --- Documentation/ABI/testing/debugfs-driver-habanalabs | 19 +------------------ 1 file changed, 1 insertion(+), 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index 2667cbf940f3..783001a574b3 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs @@ -12,24 +12,7 @@ What: /sys/kernel/debug/habanalabs/hl/clk_gate Date: May 2020 KernelVersion: 5.8 Contact: ogabbay@kernel.org -Description: Allow the root user to disable/enable in runtime the clock - gating mechanism in Gaudi. Due to how Gaudi is built, the - clock gating needs to be disabled in order to access the - registers of the TPC and MME engines. This is sometimes needed - during debug by the user and hence the user needs this option. - The user can supply a bitmask value, each bit represents - a different engine to disable/enable its clock gating feature. - The bitmask is composed of 20 bits: - - ======= ============ - 0 - 7 DMA channels - 8 - 11 MME engines - 12 - 19 TPC engines - ======= ============ - - The bit's location of a specific engine can be determined - using (1 << GAUDI_ENGINE_ID_*). GAUDI_ENGINE_ID_* values - are defined in uapi habanalabs.h file in enum gaudi_engine_id +Description: This setting is now deprecated as clock gating is handled solely by the f/w What: /sys/kernel/debug/habanalabs/hl/command_buffers Date: Jan 2019 -- cgit From b62ff1a4123693551383f306ab736758e6fe0d84 Mon Sep 17 00:00:00 2001 From: Oded Gabbay Date: Sat, 8 Jan 2022 23:45:32 +0200 Subject: habanalabs: add vrm version to sysfs infineon version is only applicable to GOYA and GAUDI. For later ASICs, we display the Voltage Regulator Monitor f/w version. Signed-off-by: Oded Gabbay --- Documentation/ABI/testing/sysfs-driver-habanalabs | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-habanalabs b/Documentation/ABI/testing/sysfs-driver-habanalabs index 1f127f71d2b4..c16a573eb680 100644 --- a/Documentation/ABI/testing/sysfs-driver-habanalabs +++ b/Documentation/ABI/testing/sysfs-driver-habanalabs @@ -115,7 +115,7 @@ What: /sys/class/habanalabs/hl/infineon_ver Date: Jan 2019 KernelVersion: 5.1 Contact: ogabbay@kernel.org -Description: Version of the Device's power supply F/W code +Description: Version of the Device's power supply F/W code. Relevant only to GOYA and GAUDI What: /sys/class/habanalabs/hl/max_power Date: Jan 2019 @@ -220,4 +220,10 @@ What: /sys/class/habanalabs/hl/uboot_ver Date: Jan 2019 KernelVersion: 5.1 Contact: ogabbay@kernel.org -Description: Version of the u-boot running on the device's CPU \ No newline at end of file +Description: Version of the u-boot running on the device's CPU + +What: /sys/class/habanalabs/hl/vrm_ver +Date: Jan 2022 +KernelVersion: not yet upstreamed +Contact: ogabbay@kernel.org +Description: Version of the Device's Voltage Regulator Monitor F/W code. N/A to GOYA and GAUDI -- cgit From 4c01e524b21ff4342d8ab16a32a0acf91db761e3 Mon Sep 17 00:00:00 2001 From: Rajaravi Krishna Katta Date: Wed, 29 Dec 2021 13:13:45 +0200 Subject: habanalabs: sysfs support for fw os version Adds new sysfs entry to display firmware os version /sys/class/habanalabs/hl/fw_os_ver Signed-off-by: Rajaravi Krishna Katta Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay --- Documentation/ABI/testing/sysfs-driver-habanalabs | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-habanalabs b/Documentation/ABI/testing/sysfs-driver-habanalabs index c16a573eb680..96646fb2e7a1 100644 --- a/Documentation/ABI/testing/sysfs-driver-habanalabs +++ b/Documentation/ABI/testing/sysfs-driver-habanalabs @@ -69,6 +69,12 @@ KernelVersion: 5.1 Contact: ogabbay@kernel.org Description: Displays the device's version from the eFuse +What: /sys/class/habanalabs/hl/fw_os_ver +Date: Dec 2021 +KernelVersion: 5.18 +Contact: ogabbay@kernel.org +Description: Version of the firmware OS running on the device's CPU + What: /sys/class/habanalabs/hl/hard_reset Date: Jan 2019 KernelVersion: 5.1 -- cgit From d01e6cc97b44d8501b5c24a36d60c9cab94640cd Mon Sep 17 00:00:00 2001 From: Tomer Tayar Date: Wed, 12 Jan 2022 20:08:01 +0200 Subject: habanalabs: enable stop-on-error debugfs setting per ASIC On Goya and Gaudi, the stop-on-error configuration can be set via debugfs. However, in future devices, this configuration will always be enabled. Modify the debugfs node to be allowed only for ASICs that support this dynamic configuration. Signed-off-by: Tomer Tayar Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay --- Documentation/ABI/testing/debugfs-driver-habanalabs | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index 783001a574b3..bcf6915987e4 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs @@ -222,6 +222,7 @@ KernelVersion: 5.6 Contact: ogabbay@kernel.org Description: Sets the stop-on_error option for the device engines. Value of "0" is for disable, otherwise enable. + Relevant only for GOYA and GAUDI. What: /sys/kernel/debug/habanalabs/hl/timeout_locked Date: Sep 2021 -- cgit From 6619c7d4379aca716a90f7581be2853071c086f6 Mon Sep 17 00:00:00 2001 From: Srinivasa Rao Mandadapu Date: Sat, 26 Feb 2022 23:39:19 +0530 Subject: ASoC: qcom: dt-bindings: Add bindings for power domains in lpass digital codecs Include power domain dt-bindings for lpass digital codecs RX, TX and VA macros, which are required for ADSP bypass architecture. Signed-off-by: Srinivasa Rao Mandadapu Co-developed-by: Venkata Prasad Potturu Signed-off-by: Venkata Prasad Potturu Link: https://lore.kernel.org/r/1645898959-11231-3-git-send-email-quic_srivasam@quicinc.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml | 8 ++++++++ Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml | 8 ++++++++ Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml | 8 ++++++++ 3 files changed, 24 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml index bc762b39c68a..6127df5836c2 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml @@ -39,6 +39,14 @@ properties: items: - const: mclk + power-domains: + maxItems: 2 + + power-domain-names: + items: + - const: macro + - const: dcodec + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml index 74f53864e7a7..3f0f99cb18ca 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml @@ -39,6 +39,14 @@ properties: items: - const: mclk + power-domains: + maxItems: 2 + + power-domain-names: + items: + - const: macro + - const: dcodec + qcom,dmic-sample-rate: description: dmic sample rate $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml index 99f2c3687fbd..9868a5ebe27e 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml @@ -37,6 +37,14 @@ properties: items: - const: fsgen + power-domains: + maxItems: 2 + + power-domain-names: + items: + - const: macro + - const: dcodec + qcom,dmic-sample-rate: description: dmic sample rate $ref: /schemas/types.yaml#/definitions/uint32 -- cgit From 032959d880fd99a790607cf59cf6c00b77a32cef Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Sun, 27 Feb 2022 22:56:32 +0000 Subject: ASoC: dt-bindings: renesas,rz-ssi: Document RZ/V2L SoC Document RZ/V2L SSI bindings. RZ/V2L SSI is identical to one found on the RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,rz-ssi" will be used as a fallback. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220227225633.28829-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml index 414ff8035a4e..7e8d252f7bca 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/sound/renesas,rz-ssi.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas RZ/G2L ASoC Sound Serial Interface (SSIF-2) +title: Renesas RZ/{G2L,V2L} ASoC Sound Serial Interface (SSIF-2) maintainers: - Biju Das @@ -14,6 +14,7 @@ properties: items: - enum: - renesas,r9a07g044-ssi # RZ/G2{L,LC} + - renesas,r9a07g054-ssi # RZ/V2L - const: renesas,rz-ssi reg: -- cgit From 20f01f163203666010ee1560852590a0c0572726 Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Mon, 24 Jan 2022 13:59:38 -0800 Subject: blk-crypto: show crypto capabilities in sysfs Add sysfs files that expose the inline encryption capabilities of request queues: /sys/block/$disk/queue/crypto/max_dun_bits /sys/block/$disk/queue/crypto/modes/$mode /sys/block/$disk/queue/crypto/num_keyslots Userspace can use these new files to decide what encryption settings to use, or whether to use inline encryption at all. This also brings the crypto capabilities in line with the other queue properties, which are already discoverable via the queue directory in sysfs. Design notes: - Place the new files in a new subdirectory "crypto" to group them together and to avoid complicating the main "queue" directory. This also makes it possible to replace "crypto" with a symlink later if we ever make the blk_crypto_profiles into real kobjects (see below). - It was necessary to define a new kobject that corresponds to the crypto subdirectory. For now, this kobject just contains a pointer to the blk_crypto_profile. Note that multiple queues (and hence multiple such kobjects) may refer to the same blk_crypto_profile. An alternative design would more closely match the current kernel data structures: the blk_crypto_profile could be a kobject itself, located directly under the host controller device's kobject, while /sys/block/$disk/queue/crypto would be a symlink to it. I decided not to do that for now because it would require a lot more changes, such as no longer embedding blk_crypto_profile in other structures, and also because I'm not sure we can rule out moving the crypto capabilities into 'struct queue_limits' in the future. (Even if multiple queues share the same crypto engine, maybe the supported data unit sizes could differ due to other queue properties.) It would also still be possible to switch to that design later without breaking userspace, by replacing the directory with a symlink. - Use "max_dun_bits" instead of "max_dun_bytes". Currently, the kernel internally stores this value in bytes, but that's an implementation detail. It probably makes more sense to talk about this value in bits, and choosing bits is more future-proof. - "modes" is a sub-subdirectory, since there may be multiple supported crypto modes, sysfs is supposed to have one value per file, and it makes sense to group all the mode files together. - Each mode had to be named. The crypto API names like "xts(aes)" are not appropriate because they don't specify the key size. Therefore, I assigned new names. The exact names chosen are arbitrary, but they happen to match the names used in log messages in fs/crypto/. - The "num_keyslots" file is a bit different from the others in that it is only useful to know for performance reasons. However, it's included as it can still be useful. For example, a user might not want to use inline encryption if there aren't very many keyslots. Reviewed-by: Hannes Reinecke Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20220124215938.2769-4-ebiggers@kernel.org Signed-off-by: Jens Axboe --- Documentation/ABI/stable/sysfs-block | 49 ++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block index 8dd3e84a8aad..e8797cd09aff 100644 --- a/Documentation/ABI/stable/sysfs-block +++ b/Documentation/ABI/stable/sysfs-block @@ -155,6 +155,55 @@ Description: last zone of the device which may be smaller. +What: /sys/block//queue/crypto/ +Date: February 2022 +Contact: linux-block@vger.kernel.org +Description: + The presence of this subdirectory of /sys/block//queue/ + indicates that the device supports inline encryption. This + subdirectory contains files which describe the inline encryption + capabilities of the device. For more information about inline + encryption, refer to Documentation/block/inline-encryption.rst. + + +What: /sys/block//queue/crypto/max_dun_bits +Date: February 2022 +Contact: linux-block@vger.kernel.org +Description: + [RO] This file shows the maximum length, in bits, of data unit + numbers accepted by the device in inline encryption requests. + + +What: /sys/block//queue/crypto/modes/ +Date: February 2022 +Contact: linux-block@vger.kernel.org +Description: + [RO] For each crypto mode (i.e., encryption/decryption + algorithm) the device supports with inline encryption, a file + will exist at this location. It will contain a hexadecimal + number that is a bitmask of the supported data unit sizes, in + bytes, for that crypto mode. + + Currently, the crypto modes that may be supported are: + + * AES-256-XTS + * AES-128-CBC-ESSIV + * Adiantum + + For example, if a device supports AES-256-XTS inline encryption + with data unit sizes of 512 and 4096 bytes, the file + /sys/block//queue/crypto/modes/AES-256-XTS will exist and + will contain "0x1200". + + +What: /sys/block//queue/crypto/num_keyslots +Date: February 2022 +Contact: linux-block@vger.kernel.org +Description: + [RO] This file shows the number of keyslots the device has for + use with inline encryption. + + What: /sys/block//queue/dax Date: June 2016 Contact: linux-block@vger.kernel.org -- cgit From f16ed63e53c79070283d3c264de5309794272ae9 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Sun, 27 Feb 2022 22:59:56 +0000 Subject: spi: dt-bindings: renesas,rspi: Document RZ/V2L SoC Add RSPI binding documentation for Renesas RZ/V2L SoC. RSPI block is identical to one found on RZ/A, so no driver changes are required. The fallback compatible string "renesas,rspi-rz" will be used on RZ/V2L. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Acked-by: Krzysztof Kozlowski Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20220227225956.29570-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/renesas,rspi.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/renesas,rspi.yaml b/Documentation/devicetree/bindings/spi/renesas,rspi.yaml index 76e6d9e52fc7..a902f0ca2198 100644 --- a/Documentation/devicetree/bindings/spi/renesas,rspi.yaml +++ b/Documentation/devicetree/bindings/spi/renesas,rspi.yaml @@ -22,6 +22,7 @@ properties: - renesas,rspi-r7s72100 # RZ/A1H - renesas,rspi-r7s9210 # RZ/A2 - renesas,r9a07g044-rspi # RZ/G2{L,LC} + - renesas,r9a07g054-rspi # RZ/V2L - const: renesas,rspi-rz # RZ/A and RZ/G2{L,LC} - items: @@ -124,6 +125,7 @@ allOf: enum: - renesas,qspi - renesas,r9a07g044-rspi + - renesas,r9a07g054-rspi then: required: - resets -- cgit From 70868c6b8fd80db585da57a264c50a69af8fd3c3 Mon Sep 17 00:00:00 2001 From: Wan Jiabing Date: Mon, 28 Feb 2022 10:56:41 +0800 Subject: docs: fix 'make htmldocs' warning in SCTP.rst Fix following 'make htmldocs' warnings: ./Documentation/security/SCTP.rst:123: WARNING: Title underline too short. security_sctp_assoc_established() ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./Documentation/security/SCTP.rst:123: WARNING: Title underline too short. security_sctp_assoc_established() ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./Documentation/security/SCTP.rst:273: WARNING: Title underline too short. security_sctp_assoc_established() ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./Documentation/security/SCTP.rst:273: WARNING: Title underline too short. security_sctp_assoc_established() ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fixes: 5e50f5d4ff31 ("security: add sctp_assoc_established hook") Signed-off-by: Wan Jiabing Reviewed-by: Xin Long Signed-off-by: Paul Moore --- Documentation/security/SCTP.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/security/SCTP.rst b/Documentation/security/SCTP.rst index 406cc68b8808..b73eb764a001 100644 --- a/Documentation/security/SCTP.rst +++ b/Documentation/security/SCTP.rst @@ -120,7 +120,7 @@ calls **sctp_peeloff**\(3). security_sctp_assoc_established() -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Called when a COOKIE ACK is received, and the peer secid will be saved into ``@asoc->peer_secid`` for client:: @@ -270,7 +270,7 @@ sockets sid and peer sid to that contained in the ``@asoc sid`` and security_sctp_assoc_established() -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Called when a COOKIE ACK is received where it sets the connection's peer sid to that in ``@skb``:: -- cgit From 643d6a78ac76bc87cdf65183c0dec2457390b383 Mon Sep 17 00:00:00 2001 From: Pawel Dembicki Date: Tue, 15 Feb 2022 17:39:23 +0100 Subject: dt-bindings: vendor-prefixes: Add Ctera Networks CTERA Networks Intl. is a company based in Israel. They manufacture NASes, network devices and provide software products for cloud storage and IT security. Signed-off-by: Pawel Dembicki Signed-off-by: Gregory CLEMENT --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 294093d45a23..dececb66b206 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -277,6 +277,8 @@ patternProperties: description: Hangzhou C-SKY Microsystems Co., Ltd "^csq,.*": description: Shenzen Chuangsiqi Technology Co.,Ltd. + "^ctera,.*": + description: CTERA Networks Intl. "^cubietech,.*": description: Cubietech, Ltd. "^cui,.*": -- cgit From 43429ea74a121683dc231d0a694bb32734caea92 Mon Sep 17 00:00:00 2001 From: Wan Jiabing Date: Mon, 28 Feb 2022 16:04:16 +0800 Subject: bpf, docs: Add a missing colon in verifier.rst Add a missing colon to fix the document style. Fixes: 88691e9e1ef5 ("bpf, docs: Split general purpose eBPF documentation out of filter.rst") Signed-off-by: Wan Jiabing Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220228080416.1689327-1-wanjiabing@vivo.com --- Documentation/bpf/verifier.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/bpf/verifier.rst b/Documentation/bpf/verifier.rst index fae5f6273bac..d4326caf01f9 100644 --- a/Documentation/bpf/verifier.rst +++ b/Documentation/bpf/verifier.rst @@ -329,7 +329,7 @@ Program with unreachable instructions:: BPF_EXIT_INSN(), }; -Error: +Error:: unreachable insn 1 -- cgit From 73b9f6389e5cc2980ca892b9cf048659e6a98d28 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Fri, 28 Jan 2022 10:07:35 +0100 Subject: dt-bindings: timer: sifive,clint: Fix number of interrupts The number of interrupts lacks an upper bound, thus assuming one, causing properly grouped "interrupts-extended" properties to be flagged as an error by "make dtbs_check". Fix this by adding the missing "maxItems", using the architectural maximum of 4095 interrupts. Signed-off-by: Geert Uytterhoeven Acked-by: Rob Herring Reviewed-by: Anup Patel Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/e6a4c5b20d2acb52125d7d6e6c7e3694d7cb182c.1643360652.git.geert@linux-m68k.org --- Documentation/devicetree/bindings/timer/sifive,clint.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml index 8d5f4687add9..fe4b73c3f269 100644 --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml @@ -44,6 +44,7 @@ properties: interrupts-extended: minItems: 1 + maxItems: 4095 additionalProperties: false -- cgit From 4eb7b1339c23517922b4e3710abadb153f75336f Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Fri, 28 Jan 2022 10:07:36 +0100 Subject: dt-bindings: timer: sifive,clint: Group interrupt tuples To improve human readability and enable automatic validation, the tuples in "interrupts-extended" properties should be grouped using angle brackets. Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Reviewed-by: Anup Patel Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/62bf4ee6613550c07a99d4bd226ab0d33acae4c4.1643360652.git.geert@linux-m68k.org --- Documentation/devicetree/bindings/timer/sifive,clint.yaml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml index fe4b73c3f269..e64f46339079 100644 --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml @@ -57,10 +57,10 @@ examples: - | timer@2000000 { compatible = "sifive,fu540-c000-clint", "sifive,clint0"; - interrupts-extended = <&cpu1intc 3 &cpu1intc 7 - &cpu2intc 3 &cpu2intc 7 - &cpu3intc 3 &cpu3intc 7 - &cpu4intc 3 &cpu4intc 7>; + interrupts-extended = <&cpu1intc 3>, <&cpu1intc 7>, + <&cpu2intc 3>, <&cpu2intc 7>, + <&cpu3intc 3>, <&cpu3intc 7>, + <&cpu4intc 3>, <&cpu4intc 7>; reg = <0x2000000 0x10000>; }; ... -- cgit From 8e4296c286ed7a3b69e619d5069493bdcc9a2b25 Mon Sep 17 00:00:00 2001 From: Frank Rowand Date: Tue, 1 Feb 2022 12:14:13 -0600 Subject: of: unittest: add program to process EXPECT messages If unittest detects a problem it will print a warning or error message to the console. Unittest also triggers warning and error messages from other kernel code as a result of intentionally bad unittest data. This has led to confusion as to whether the triggered messages are an expected result of a test or whether there is a real problem that is independent of unittest. EXPECT messages were added to unittest to report each triggered message that is expected, resulting in verbose console output. scripts/dtc/of_unittest is a new program that processes the EXPECT messages to determine whether the triggered messages occurred and also removes the excess verbosity of the EXPECT messages. More information is available from 'scripts/dtc/of_unittest_expect --help'. Signed-off-by: Frank Rowand Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220201181413.2719955-1-frowand.list@gmail.com --- Documentation/devicetree/of_unittest.rst | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/of_unittest.rst b/Documentation/devicetree/of_unittest.rst index 2afe41a37148..8864b52d1195 100644 --- a/Documentation/devicetree/of_unittest.rst +++ b/Documentation/devicetree/of_unittest.rst @@ -24,7 +24,28 @@ from the unflattened device tree data structure. This interface is used by most of the device drivers in various use cases. -2. Test-data +2. Verbose Output (EXPECT) +========================== + +If unittest detects a problem it will print a warning or error message to +the console. Unittest also triggers warning and error messages from other +kernel code as a result of intentionally bad unittest data. This has led +to confusion as to whether the triggered messages are an expected result +of a test or whether there is a real problem that is independent of unittest. + +'EXPECT \ : text' (begin) and 'EXPECT / : text' (end) messages have been +added to unittest to report that a warning or error is expected. The +begin is printed before triggering the warning or error, and the end is +printed after triggering the warning or error. + +The EXPECT messages result in very noisy console messages that are difficult +to read. The script scripts/dtc/of_unittest_expect was created to filter +this verbosity and highlight mismatches between triggered warnings and +errors vs expected warnings and errors. More information is available +from 'scripts/dtc/of_unittest_expect --help'. + + +3. Test-data ============ The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains @@ -56,7 +77,7 @@ The assembly file is compiled into an object file (testcases.dtb.o), and is linked into the kernel image. -2.1. Adding the test data +3.1. Adding the test data ------------------------- Un-flattened device tree structure: @@ -191,7 +212,7 @@ properties are updated to the live tree's node by calling the function update_node_properties(). -2.2. Removing the test data +3.2. Removing the test data --------------------------- Once the test case execution is complete, selftest_data_remove is called in -- cgit From a319fbfd3f6a7feeb226e94b60ddc0d827de30ba Mon Sep 17 00:00:00 2001 From: Johnson Wang Date: Mon, 7 Feb 2022 16:30:34 +0800 Subject: dt-bindings: mediatek: add compatible for MT8186 pwrap This adds dt-binding documentation of pwrap for Mediatek MT8186 SoCs Platform. Acked-by: Rob Herring Acked-by: AngeloGioacchino Del Regno Signed-off-by: Johnson Wang Link: https://lore.kernel.org/r/20220207083034.15327-3-johnson.wang@mediatek.com Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/soc/mediatek/pwrap.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt index d74a7a5ae9f2..214a34633824 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt @@ -27,6 +27,7 @@ Required properties in pwrap device node. "mediatek,mt8135-pwrap" for MT8135 SoCs "mediatek,mt8173-pwrap" for MT8173 SoCs "mediatek,mt8183-pwrap" for MT8183 SoCs + "mediatek,mt8186-pwrap" for MT8186 SoCs "mediatek,mt8195-pwrap" for MT8195 SoCs "mediatek,mt8516-pwrap" for MT8516 SoCs - interrupts: IRQ for pwrap in SOC -- cgit From eb1b02bef52ae545d5eb24116d5c099f738d39d5 Mon Sep 17 00:00:00 2001 From: Rex-BC Chen Date: Tue, 1 Mar 2022 16:01:00 +0800 Subject: dt-bindings: arm: mediatek: mmsys: add support for MT8186 Add "mediatek,mt8186-mmsys" to binding document. Signed-off-by: Rex-BC Chen Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220301080105.31323-2-rex-bc.chen@mediatek.com Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index 763c62323a74..b31d90dc9eb4 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -29,6 +29,7 @@ properties: - mediatek,mt8167-mmsys - mediatek,mt8173-mmsys - mediatek,mt8183-mmsys + - mediatek,mt8186-mmsys - mediatek,mt8192-mmsys - mediatek,mt8365-mmsys - const: syscon -- cgit From a4ee79063f44c60992c89eb4f66853329908ecca Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Sun, 27 Feb 2022 21:23:30 +0000 Subject: dt-bindings: mmc: renesas,sdhi: Document RZ/V2L SoC Document RZ/V2L SDHI bindings. RZ/V2L SDHI is almost identical to one found on the R-Car Gen3. No driver changes are required as generic compatible string "renesas,rcar-gen3-sdhi" will be used as a fallback. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Krzysztof Kozlowski Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20220227212330.22262-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml index 9ce6e06c19db..3b191fb89cf1 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml @@ -58,6 +58,7 @@ properties: - renesas,sdhi-r8a77995 # R-Car D3 - renesas,sdhi-r8a779a0 # R-Car V3U - renesas,sdhi-r9a07g044 # RZ/G2{L,LC} + - renesas,sdhi-r9a07g054 # RZ/V2L - const: renesas,rcar-gen3-sdhi # R-Car Gen3 or RZ/G2 reg: @@ -107,7 +108,9 @@ allOf: properties: compatible: contains: - const: renesas,sdhi-r9a07g044 + enum: + - renesas,sdhi-r9a07g044 + - renesas,sdhi-r9a07g054 then: properties: clocks: -- cgit From e65a3b46b5b1fab92c3273bcf71e028a4d307400 Mon Sep 17 00:00:00 2001 From: Sean Christopherson Date: Fri, 25 Feb 2022 18:22:47 +0000 Subject: KVM: Drop KVM_REQ_MMU_RELOAD and update vcpu-requests.rst documentation Remove the now unused KVM_REQ_MMU_RELOAD, shift KVM_REQ_VM_DEAD into the unoccupied space, and update vcpu-requests.rst, which was missing an entry for KVM_REQ_VM_DEAD. Switching KVM_REQ_VM_DEAD to entry '1' also fixes the stale comment about bits 4-7 being reserved. Reviewed-by: Claudio Imbrenda Signed-off-by: Sean Christopherson Reviewed-by: Ben Gardon Message-Id: <20220225182248.3812651-7-seanjc@google.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/vcpu-requests.rst | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/vcpu-requests.rst b/Documentation/virt/kvm/vcpu-requests.rst index ad2915ef7020..b61d48aec36c 100644 --- a/Documentation/virt/kvm/vcpu-requests.rst +++ b/Documentation/virt/kvm/vcpu-requests.rst @@ -112,11 +112,10 @@ KVM_REQ_TLB_FLUSH choose to use the common kvm_flush_remote_tlbs() implementation will need to handle this VCPU request. -KVM_REQ_MMU_RELOAD +KVM_REQ_VM_DEAD - When shadow page tables are used and memory slots are removed it's - necessary to inform each VCPU to completely refresh the tables. This - request is used for that. + This request informs all VCPUs that the VM is dead and unusable, e.g. due to + fatal error or because the VM's state has been intentionally destroyed. KVM_REQ_UNBLOCK -- cgit From 12bbb0d163a90d81a2677cf7808d364697290207 Mon Sep 17 00:00:00 2001 From: Dust Li Date: Tue, 1 Mar 2022 17:43:58 +0800 Subject: net/smc: add sysctl for autocorking This add a new sysctl: net.smc.autocorking_size We can dynamically change the behaviour of autocorking by change the value of autocorking_size. Setting to 0 disables autocorking in SMC Signed-off-by: Dust Li Signed-off-by: David S. Miller --- Documentation/networking/smc-sysctl.rst | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 Documentation/networking/smc-sysctl.rst (limited to 'Documentation') diff --git a/Documentation/networking/smc-sysctl.rst b/Documentation/networking/smc-sysctl.rst new file mode 100644 index 000000000000..c53f8c61c9e4 --- /dev/null +++ b/Documentation/networking/smc-sysctl.rst @@ -0,0 +1,23 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========= +SMC Sysctl +========= + +/proc/sys/net/smc/* Variables +============================== + +autocorking_size - INTEGER + Setting SMC auto corking size: + SMC auto corking is like TCP auto corking from the application's + perspective of view. When applications do consecutive small + write()/sendmsg() system calls, we try to coalesce these small writes + as much as possible, to lower total amount of CDC and RDMA Write been + sent. + autocorking_size limits the maximum corked bytes that can be sent to + the under device in 1 single sending. If set to 0, the SMC auto corking + is disabled. + Applications can still use TCP_CORK for optimal behavior when they + know how/when to uncork their sockets. + + Default: 64K -- cgit From 42764f97e6ebf1ff518c83e4a36395fddf7a6085 Mon Sep 17 00:00:00 2001 From: Benjamin Tissoires Date: Thu, 3 Feb 2022 15:32:26 +0100 Subject: Input: docs: add more details on the use of BTN_TOOL The HID core stack used to be very relaxed considering the BTN_TOOL_* usage. With the recent commits, we should now enforce to have only one tool at a time, meaning that we can now express that requirement in the docs. Signed-off-by: Benjamin Tissoires Reviewed-by: Ping Cheng Acked-by: Peter Hutterer Signed-off-by: Jiri Kosina --- Documentation/input/event-codes.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst index b24ae7d292cc..8741d390b184 100644 --- a/Documentation/input/event-codes.rst +++ b/Documentation/input/event-codes.rst @@ -137,7 +137,11 @@ A few EV_KEY codes have special meanings: code should be set to a value of 1. When the tool is no longer interacting with the input device, the BTN_TOOL_ code should be reset to 0. All trackpads, tablets, and touchscreens should use at least one BTN_TOOL_ - code when events are generated. + code when events are generated. Likewise all trackpads, tablets, and + touchscreens should export only one BTN_TOOL_ at a time. To not break + existing userspace, it is recommended to not switch tool in one EV_SYN frame + but first emitting the old BTN_TOOL_ at 0, then emit one SYN_REPORT + and then set the new BTN_TOOL_ at 1. * BTN_TOUCH: -- cgit From 36c11fee4fb5e5b4bf320d65957bbc21da9cd6d3 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 24 Feb 2022 13:31:21 +0100 Subject: dt-bindings: i2c: microchip,corei2c: Fix indentation of compatible items make dt_binding_check: Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml:19:9: [warning] wrong indentation: expected 10 but found 8 (indentation) Fixes: f1bd6661946b20d1 ("dt-bindings: i2c: add bindings for microchip mpfs i2c") Signed-off-by: Geert Uytterhoeven Acked-by: Rob Herring Acked-by: Conor Dooley Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml b/Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml index c8e605fbb8a6..7bad4b946a34 100644 --- a/Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml +++ b/Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml @@ -16,8 +16,8 @@ properties: compatible: oneOf: - items: - - const: microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs - - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core + - const: microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs + - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core reg: -- cgit From c205cac49e09deac8f91462138136d22a3161571 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Sun, 27 Feb 2022 21:32:50 +0000 Subject: dt-bindings: net: can: renesas,rcar-canfd: Document RZ/V2L SoC Document RZ/V2L CANFD bindings. RZ/V2L CANFD is identical to one found on the RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,rzg2l-canfd" will be used as a fallback. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Geert Uytterhoeven Acked-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220227213250.23637-1-prabhakar.mahadev-lad.rj@bp.renesas.com --- Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml index 546c6e6d2fb0..720130bda6a6 100644 --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml @@ -33,6 +33,7 @@ properties: - items: - enum: - renesas,r9a07g044-canfd # RZ/G2{L,LC} + - renesas,r9a07g054-canfd # RZ/V2L - const: renesas,rzg2l-canfd # RZ/G2L family reg: -- cgit From eb1e49e04ab9863f5e9a73ebadaae15aef2fce35 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Sun, 27 Feb 2022 21:47:47 +0000 Subject: dt-bindings: i2c: renesas,riic: Document RZ/V2L SoC Document RZ/V2L I2C bindings. RZ/V2L I2C is identical to one found on the RZ/G2L SoC. No driver changes are required as RZ/G2L compatible string "renesas,riic-rz" will be used as a fallback. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Geert Uytterhoeven Acked-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220227214747.24819-1-prabhakar.mahadev-lad.rj@bp.renesas.com --- Documentation/devicetree/bindings/i2c/renesas,riic.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml index 402fd125e010..f4b235a87ac6 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml +++ b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml @@ -20,6 +20,7 @@ properties: - renesas,riic-r7s72100 # RZ/A1H - renesas,riic-r7s9210 # RZ/A2M - renesas,riic-r9a07g044 # RZ/G2{L,LC} + - renesas,riic-r9a07g054 # RZ/V2L - const: renesas,riic-rz # RZ/A or RZ/G2L reg: @@ -75,6 +76,7 @@ if: contains: enum: - renesas,riic-r9a07g044 + - renesas,riic-r9a07g054 then: required: - resets -- cgit From 7419553d03ffff648be0aba03f2f762212fc013b Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Sun, 27 Feb 2022 22:48:44 +0000 Subject: dt-bindings: timer: renesas: ostm: Document Renesas RZ/V2L OSTM Document the General Timer Module(a.k.a OSTM) found on the RZ/V2L SoC. OSTM module is identical to one found RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,ostm" will be used as a fallback. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Acked-by: Krzysztof Kozlowski Reviewed-by: Geert Uytterhoeven Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220227224845.27348-1-prabhakar.mahadev-lad.rj@bp.renesas.com --- Documentation/devicetree/bindings/timer/renesas,ostm.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml index 7fa7f977b44c..c399a019dde7 100644 --- a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml @@ -24,6 +24,7 @@ properties: - renesas,r7s72100-ostm # RZ/A1H - renesas,r7s9210-ostm # RZ/A2M - renesas,r9a07g044-ostm # RZ/G2{L,LC} + - renesas,r9a07g054-ostm # RZ/V2L - const: renesas,ostm # Generic reg: @@ -54,6 +55,7 @@ if: contains: enum: - renesas,r9a07g044-ostm + - renesas,r9a07g054-ostm then: required: - resets -- cgit From f866a7ae1265960af80e555a0f0e1d22c72476eb Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Sun, 27 Feb 2022 23:03:01 +0000 Subject: dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/V2L USBPHY Control bindings Add device tree binding document for RZ/V2L USBPHY Control Device. RZ/V2L USBPHY Control Device is identical to one found on the RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,rzg2l-usbphy-ctrl" will be used as a fallback. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Geert Uytterhoeven Acked-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220227230302.30388-1-prabhakar.mahadev-lad.rj@bp.renesas.com --- Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml index b13514e6783d..86c2569ced97 100644 --- a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml +++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/reset/renesas,rzg2l-usbphy-ctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas RZ/G2L USBPHY Control +title: Renesas RZ/{G2L,V2L} USBPHY Control maintainers: - Biju Das @@ -18,6 +18,7 @@ properties: items: - enum: - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC} + - renesas,r9a07g054-usbphy-ctrl # RZ/V2L - const: renesas,rzg2l-usbphy-ctrl reg: -- cgit From 53157759f56bae8aa6ad2912378f7e75e218e779 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Sun, 27 Feb 2022 23:15:31 +0000 Subject: dt-bindings: usb: renesas,usbhs: Document RZ/V2L bindings Document RZ/V2L (R9A07G054) SoC bindings. USBHS block is identical to one found on RZ/A2 SoC. No driver changes are required as generic compatible string "renesas,rza2-usbhs" will be used as a fallback. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Geert Uytterhoeven Acked-by: Krzysztof Kozlowski Acked-by: Yoshihiro Shimoda Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220227231531.32279-1-prabhakar.mahadev-lad.rj@bp.renesas.com --- Documentation/devicetree/bindings/usb/renesas,usbhs.yaml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml index 012fe80a7611..0bb841b28003 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml @@ -20,6 +20,7 @@ properties: - enum: - renesas,usbhs-r7s9210 # RZ/A2 - renesas,usbhs-r9a07g044 # RZ/G2{L,LC} + - renesas,usbhs-r9a07g054 # RZ/V2L - const: renesas,rza2-usbhs - items: @@ -116,7 +117,9 @@ allOf: properties: compatible: contains: - const: renesas,usbhs-r9a07g044 + enum: + - renesas,usbhs-r9a07g044 + - renesas,usbhs-r9a07g054 then: properties: interrupts: -- cgit From 448841d9a2bcb81962bcf8beb6db8da4d377ee29 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 18 Feb 2022 17:15:19 +0100 Subject: dt-bindings: usb: dwc2: fix compatible of Intel Agilex Intel Agilex USB DWC2 node is used as compatible with generic snps,dwc2 (just like Altera's Stratix10). Acked-by: Rob Herring Signed-off-by: Krzysztof Kozlowski Signed-off-by: Dinh Nguyen --- Documentation/devicetree/bindings/usb/dwc2.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index f00867ebc147..048e352c531a 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -41,6 +41,7 @@ properties: - amlogic,meson8b-usb - amlogic,meson-gxbb-usb - amlogic,meson-g12a-usb + - intel,socfpga-agilex-hsotg - const: snps,dwc2 - const: amcc,dwc-otg - const: apm,apm82181-dwc-otg -- cgit From 1b5f9a0487594bae57a6b60d11ee2e274648ec05 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 18 Feb 2022 17:15:20 +0100 Subject: dt-bindings: usb: dwc2: add iommus The DWC2 node might use IOMMU (e.g. Altera Stratix10), so add "iommus" property. This fixes warnings like: arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dt.yaml: usb@ffb40000: 'iommus' does not match any of the regexes: 'pinctrl-[0-9]+' Acked-by: Rob Herring Signed-off-by: Krzysztof Kozlowski Signed-off-by: Dinh Nguyen --- Documentation/devicetree/bindings/usb/dwc2.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index 048e352c531a..1ba96706bbcb 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -68,6 +68,9 @@ properties: items: - const: otg + iommus: + maxItems: 1 + resets: items: - description: common reset -- cgit From 4b9ff41f22d69f06dd6bfc929eec0f2a1f05789c Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 18 Feb 2022 17:15:21 +0100 Subject: dt-bindings: usb: dwc2: add disable-over-current The driver parses disable-over-current protection and some implementations use it (e.g. Altera Stratix10), so document it in the bindings. Acked-by: Rob Herring Signed-off-by: Krzysztof Kozlowski Signed-off-by: Dinh Nguyen --- Documentation/devicetree/bindings/usb/dwc2.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index 1ba96706bbcb..1addab83f4fd 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -68,6 +68,10 @@ properties: items: - const: otg + disable-over-current: + type: boolean + description: whether to disable detection of over-current condition. + iommus: maxItems: 1 -- cgit From a644161ba11df38e5582e718c99668e282ddbf36 Mon Sep 17 00:00:00 2001 From: Srinivas Pandruvada Date: Mon, 28 Feb 2022 11:57:59 -0800 Subject: Documentation: admin-guide: pm: Document uncore frequency scaling Added documentation to configure uncore frequency limits in Intel Xeon processors. Signed-off-by: Srinivas Pandruvada [ rjw: Clean up the document wording ] Signed-off-by: Rafael J. Wysocki --- .../pm/intel_uncore_frequency_scaling.rst | 60 ++++++++++++++++++++++ Documentation/admin-guide/pm/working-state.rst | 1 + 2 files changed, 61 insertions(+) create mode 100644 Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst (limited to 'Documentation') diff --git a/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst b/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst new file mode 100644 index 000000000000..09169d935835 --- /dev/null +++ b/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst @@ -0,0 +1,60 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +============================== +Intel Uncore Frequency Scaling +============================== + +:Copyright: |copy| 2022 Intel Corporation + +:Author: Srinivas Pandruvada + +Introduction +------------ + +The uncore can consume significant amount of power in Intel's Xeon servers based +on the workload characteristics. To optimize the total power and improve overall +performance, SoCs have internal algorithms for scaling uncore frequency. These +algorithms monitor workload usage of uncore and set a desirable frequency. + +It is possible that users have different expectations of uncore performance and +want to have control over it. The objective is similar to allowing users to set +the scaling min/max frequencies via cpufreq sysfs to improve CPU performance. +Users may have some latency sensitive workloads where they do not want any +change to uncore frequency. Also, users may have workloads which require +different core and uncore performance at distinct phases and they may want to +use both cpufreq and the uncore scaling interface to distribute power and +improve overall performance. + +Sysfs Interface +--------------- + +To control uncore frequency, a sysfs interface is provided in the directory: +`/sys/devices/system/cpu/intel_uncore_frequency/`. + +There is one directory for each package and die combination as the scope of +uncore scaling control is per die in multiple die/package SoCs or per +package for single die per package SoCs. The name represents the +scope of control. For example: 'package_00_die_00' is for package id 0 and +die 0. + +Each package_*_die_* contains the following attributes: + +``initial_max_freq_khz`` + Out of reset, this attribute represent the maximum possible frequency. + This is a read-only attribute. If users adjust max_freq_khz, + they can always go back to maximum using the value from this attribute. + +``initial_min_freq_khz`` + Out of reset, this attribute represent the minimum possible frequency. + This is a read-only attribute. If users adjust min_freq_khz, + they can always go back to minimum using the value from this attribute. + +``max_freq_khz`` + This attribute is used to set the maximum uncore frequency. + +``min_freq_khz`` + This attribute is used to set the minimum uncore frequency. + +``current_freq_khz`` + This attribute is used to get the current uncore frequency. diff --git a/Documentation/admin-guide/pm/working-state.rst b/Documentation/admin-guide/pm/working-state.rst index 5d2757e2de65..ee45887811ff 100644 --- a/Documentation/admin-guide/pm/working-state.rst +++ b/Documentation/admin-guide/pm/working-state.rst @@ -15,3 +15,4 @@ Working-State Power Management cpufreq_drivers intel_epb intel-speed-select + intel_uncore_frequency_scaling -- cgit From 52302f87d0a126a34686f40cdd4ab28f9e824a68 Mon Sep 17 00:00:00 2001 From: Nuno Sá Date: Fri, 25 Feb 2022 14:01:28 +0100 Subject: iio: ABI: add ABI file for the LTC2688 DAC MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Define the sysfs interface for toggle or dither capable channels. Dither capable channels will have the extended interface: * out_voltageY_dither_en * out_voltageY_dither_raw * out_voltageY_dither_offset * out_voltageY_dither_raw_available * out_voltageY_dither_frequency * out_voltageY_dither_frequency_available * out_voltageY_dither_phase * out_voltageY_dither_phase_available Toggle enabled channels will have: * out_voltageY_toggle_en * out_voltageY_raw0 * out_voltageY_raw1 * out_voltageY_symbol The common interface present in all channels is: * out_voltageY_raw (not present in toggle enabled channels) * out_voltageY_raw_available * out_voltageY_powerdown * out_voltageY_scale * out_voltageY_offset * out_voltageY_calibbias * out_voltageY_calibscale Signed-off-by: Nuno Sá Link: https://lore.kernel.org/r/20220225130129.69-3-nuno.sa@analog.com Signed-off-by: Jonathan Cameron --- .../ABI/testing/sysfs-bus-iio-dac-ltc2688 | 86 ++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 b/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 new file mode 100644 index 000000000000..1c35971277ba --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 @@ -0,0 +1,86 @@ +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_en +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Dither enable. Write 1 to enable dither or 0 to disable it. This is useful + for changing the dither parameters. They way it should be done is: + + - disable dither operation; + - change dither parameters (eg: frequency, phase...); + - enabled dither operation + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_raw +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + This raw, unscaled value refers to the dither signal amplitude. + The same scale as in out_voltageY_raw applies. However, the + offset might be different as it's always 0 for this attribute. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_raw_available +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Available range for dither raw amplitude values. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_offset +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Offset applied to out_voltageY_dither_raw. Read only attribute + always set to 0. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_frequency +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Sets the dither signal frequency. Units are in Hz. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_frequency_available +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Returns the available values for the dither frequency. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_phase +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Sets the dither signal phase. Units are in Radians. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_phase_available +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Returns the available values for the dither phase. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_toggle_en +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Toggle enable. Write 1 to enable toggle or 0 to disable it. This is + useful when one wants to change the DAC output codes. The way it should + be done is: + + - disable toggle operation; + - change out_voltageY_raw0 and out_voltageY_raw1; + - enable toggle operation. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_raw0 +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_raw1 +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + It has the same meaning as out_voltageY_raw. This attribute is + specific to toggle enabled channels and refers to the DAC output + code in INPUT_A (_raw0) and INPUT_B (_raw1). The same scale and offset + as in out_voltageY_raw applies. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_symbol +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Performs a SW toggle. This attribute is specific to toggle + enabled channels and allows to toggle between out_voltageY_raw0 + and out_voltageY_raw1 through software. Writing 0 will select + out_voltageY_raw0 while 1 selects out_voltageY_raw1. -- cgit From f568cbd9aef24a02b22884d92c154f3af076b383 Mon Sep 17 00:00:00 2001 From: Nuno Sá Date: Fri, 25 Feb 2022 14:01:29 +0100 Subject: dt-bindings: iio: Add ltc2688 documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document the LTC2688 devicetree properties. Signed-off-by: Nuno Sá Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220225130129.69-4-nuno.sa@analog.com Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/dac/adi,ltc2688.yaml | 146 +++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml new file mode 100644 index 000000000000..48f9e7d29423 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml @@ -0,0 +1,146 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ltc2688.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices LTC2688 DAC + +maintainers: + - Nuno Sá + +description: | + Analog Devices LTC2688 16 channel, 16 bit, +-15V DAC + https://www.analog.com/media/en/technical-documentation/data-sheets/ltc2688.pdf + +properties: + compatible: + enum: + - adi,ltc2688 + + reg: + maxItems: 1 + + vcc-supply: + description: Analog Supply Voltage Input. + + iovcc-supply: + description: Digital Input/Output Supply Voltage. + + vref-supply: + description: + Reference Input/Output. The voltage at the REF pin sets the full-scale + range of all channels. If not provided the internal reference is used and + also provided on the VREF pin". + + clr-gpios: + description: + If specified, it will be asserted during driver probe. As the line is + active low, it should be marked GPIO_ACTIVE_LOW. + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + "^channel@([0-9]|1[0-5])$": + type: object + + properties: + reg: + description: The channel number representing the DAC output channel. + maximum: 15 + + adi,toggle-mode: + description: + Set the channel as a toggle enabled channel. Toggle operation enables + fast switching of a DAC output between two different DAC codes without + any SPI transaction. + type: boolean + + adi,output-range-microvolt: + description: Specify the channel output full scale range. + oneOf: + - items: + - const: 0 + - enum: [5000000, 10000000] + - items: + - const: -5000000 + - const: 5000000 + - items: + - const: -10000000 + - const: 10000000 + - items: + - const: -15000000 + - const: 15000000 + + adi,overrange: + description: Enable 5% overrange over the selected full scale range. + type: boolean + + clocks: + maxItems: 1 + + adi,toggle-dither-input: + description: + Selects the TGPx pin to be associated with this channel. This setting + only makes sense for toggle or dither enabled channels. If + @adi,toggle-mode is not set and this property is given, the channel is + assumed to be a dither capable channel. Note that multiple channels + can be mapped to the same pin. If this setting is given, the + respective @clock must also be provided. Mappings between this and + input pins + 0 - TGP1 + 1 - TGP2 + 2 - TGP3 + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + + dependencies: + adi,toggle-dither-input: [ clocks ] + + required: + - reg + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + + spi { + #address-cells = <1>; + #size-cells = <0>; + ltc2688: ltc2688@0 { + compatible = "adi,ltc2688"; + reg = <0>; + + vcc-supply = <&vcc>; + iovcc-supply = <&vcc>; + vref-supply = <&vref>; + + #address-cells = <1>; + #size-cells = <0>; + channel@0 { + reg = <0>; + adi,toggle-mode; + adi,overrange; + }; + + channel@1 { + reg = <1>; + adi,output-range-microvolt = <0 10000000>; + + clocks = <&clock_tgp3>; + adi,toggle-dither-input = <2>; + }; + }; + }; + +... -- cgit From 719ca379729002b0ec888069a36e508a26e51204 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 1 Mar 2022 15:05:13 -0600 Subject: dt-bindings: display/msm: Drop bogus interrupt flags cell on MDSS nodes The MDSS interrupt provider is a single cell, so specifying interrupt flags on the consumers is incorrect. Signed-off-by: Rob Herring Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20220301210513.1855076-1-robh@kernel.org Signed-off-by: Rob Clark --- Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml | 4 ++-- Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml index 167bc48748d7..2df64afb76e6 100644 --- a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml +++ b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml @@ -155,7 +155,7 @@ examples: #include #include - display-subsystem@c900000 { + mdss: display-subsystem@c900000 { compatible = "qcom,msm8998-mdss"; reg = <0x0c900000 0x1000>; reg-names = "mdss"; @@ -192,7 +192,7 @@ examples: clock-names = "iface", "bus", "mnoc", "core", "vsync"; interrupt-parent = <&mdss>; - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + interrupts = <0>; operating-points-v2 = <&mdp_opp_table>; power-domains = <&rpmpd MSM8998_VDDMX>; diff --git a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml index 8766b13f0c46..28617bc1d2ff 100644 --- a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml +++ b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml @@ -197,7 +197,7 @@ examples: power-domains = <&rpmpd QCM2290_VDDCX>; interrupt-parent = <&mdss>; - interrupts = <0 IRQ_TYPE_NONE>; + interrupts = <0>; ports { #address-cells = <1>; -- cgit From 76f22f4dcae645ea468811f9d30ec04f9ffaa1ea Mon Sep 17 00:00:00 2001 From: Sunrisepeak Date: Sun, 27 Feb 2022 22:52:04 +0800 Subject: Documentation: sound: fix typo in control-names.rst change 'cannel' to 'channel' Signed-off-by: Sunrisepeak Link: https://lore.kernel.org/r/20220227145204.16600-1-speakshen@163.com Signed-off-by: Takashi Iwai --- Documentation/sound/designs/control-names.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/designs/control-names.rst b/Documentation/sound/designs/control-names.rst index 7fedd0f33cd9..765ff9b5b7d9 100644 --- a/Documentation/sound/designs/control-names.rst +++ b/Documentation/sound/designs/control-names.rst @@ -34,7 +34,7 @@ CHANNEL Front front left/right channels Surround rear left/right in 4.0/5.1 surround CLFE C/LFE channels -Center center cannel +Center center channel LFE LFE channel Side side left/right for 7.1 surround ============ ================================================== -- cgit From 91f410aa679a035e7abdff47daca4418c384c770 Mon Sep 17 00:00:00 2001 From: Suma Hegde Date: Tue, 22 Feb 2022 10:35:00 +0530 Subject: platform/x86: Add AMD system management interface Recent Fam19h EPYC server line of processors from AMD support system management functionality via HSMP (Host System Management Port) interface. The Host System Management Port (HSMP) is an interface to provide OS-level software with access to system management functions via a set of mailbox registers. More details on the interface can be found in chapter "7 Host System Management Port (HSMP)" of the following PPR https://www.amd.com/system/files/TechDocs/55898_B1_pub_0.50.zip This patch adds new amd_hsmp module under the drivers/platforms/x86/ which creates miscdevice with an IOCTL interface to the user space. /dev/hsmp is for running the hsmp mailbox commands. Signed-off-by: Suma Hegde Signed-off-by: Naveen Krishna Chatradhi Reviewed-by: Carlos Bilbao Acked-by: Song Liu Reviewed-by: Nathan Fontenot Link: https://lore.kernel.org/r/20220222050501.18789-1-nchatrad@amd.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede --- Documentation/userspace-api/ioctl/ioctl-number.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 687efcf245c1..663e316d320c 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -372,6 +372,8 @@ Code Seq# Include File Comments 0xF6 all LTTng Linux Trace Toolkit Next Generation +0xF8 all arch/x86/include/uapi/asm/amd_hsmp.h AMD HSMP EPYC system management interface driver + 0xFD all linux/dm-ioctl.h 0xFE all linux/isst_if.h ==== ===== ======================================================= ================================================================ -- cgit From 402576d9804e9dc9b31af4e3613aa8da9ebce84e Mon Sep 17 00:00:00 2001 From: Naveen Krishna Chatradhi Date: Tue, 22 Feb 2022 10:35:01 +0530 Subject: Documentation: Add x86/amd_hsmp driver This documentation for amd_hsmp driver explains how to use the device interface. Signed-off-by: Naveen Krishna Chatradhi Acked-by: Song Liu Link: https://lore.kernel.org/r/20220222050501.18789-2-nchatrad@amd.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede --- Documentation/x86/amd_hsmp.rst | 86 ++++++++++++++++++++++++++++++++++++++++++ Documentation/x86/index.rst | 1 + 2 files changed, 87 insertions(+) create mode 100644 Documentation/x86/amd_hsmp.rst (limited to 'Documentation') diff --git a/Documentation/x86/amd_hsmp.rst b/Documentation/x86/amd_hsmp.rst new file mode 100644 index 000000000000..440e4b645a1c --- /dev/null +++ b/Documentation/x86/amd_hsmp.rst @@ -0,0 +1,86 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================ +AMD HSMP interface +============================================ + +Newer Fam19h EPYC server line of processors from AMD support system +management functionality via HSMP (Host System Management Port). + +The Host System Management Port (HSMP) is an interface to provide +OS-level software with access to system management functions via a +set of mailbox registers. + +More details on the interface can be found in chapter +"7 Host System Management Port (HSMP)" of the family/model PPR +Eg: https://www.amd.com/system/files/TechDocs/55898_B1_pub_0.50.zip + +HSMP interface is supported on EPYC server CPU models only. + + +HSMP device +============================================ + +amd_hsmp driver under the drivers/platforms/x86/ creates miscdevice +/dev/hsmp to let user space programs run hsmp mailbox commands. + +$ ls -al /dev/hsmp +crw-r--r-- 1 root root 10, 123 Jan 21 21:41 /dev/hsmp + +Characteristics of the dev node: + * Write mode is used for running set/configure commands + * Read mode is used for running get/status monitor commands + +Access restrictions: + * Only root user is allowed to open the file in write mode. + * The file can be opened in read mode by all the users. + +In-kernel integration: + * Other subsystems in the kernel can use the exported transport + function hsmp_send_message(). + * Locking across callers is taken care by the driver. + + +An example +========== + +To access hsmp device from a C program. +First, you need to include the headers:: + + #include + +Which defines the supported messages/message IDs. + +Next thing, open the device file, as follows:: + + int file; + + file = open("/dev/hsmp", O_RDWR); + if (file < 0) { + /* ERROR HANDLING; you can check errno to see what went wrong */ + exit(1); + } + +The following IOCTL is defined: + +``ioctl(file, HSMP_IOCTL_CMD, struct hsmp_message *msg)`` + The argument is a pointer to a:: + + struct hsmp_message { + __u32 msg_id; /* Message ID */ + __u16 num_args; /* Number of input argument words in message */ + __u16 response_sz; /* Number of expected output/response words */ + __u32 args[HSMP_MAX_MSG_LEN]; /* argument/response buffer */ + __u16 sock_ind; /* socket number */ + }; + +The ioctl would return a non-zero on failure; you can read errno to see +what happened. The transaction returns 0 on success. + +More details on the interface and message definitions can be found in chapter +"7 Host System Management Port (HSMP)" of the respective family/model PPR +eg: https://www.amd.com/system/files/TechDocs/55898_B1_pub_0.50.zip + +User space C-APIs are made available by linking against the esmi library, +which is provided by the E-SMS project https://developer.amd.com/e-sms/. +See: https://github.com/amd/esmi_ib_library diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index f498f1d36cd3..334d0a498749 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -24,6 +24,7 @@ x86-specific Documentation intel-iommu intel_txt amd-memory-encryption + amd_hsmp pti mds microcode -- cgit From 5165102efa41c2aedc77441612f4506a8a8671db Mon Sep 17 00:00:00 2001 From: Robert Hancock Date: Thu, 27 Jan 2022 11:34:47 -0600 Subject: dt-bindings: iio: adc: zynqmp_ams: Add clock entry The AMS driver DT binding was missing the clock entry, which is actually mandatory according to the driver implementation. Add this in. Fixes: 39dd2d1e251d ("dt-bindings: iio: adc: Add Xilinx AMS binding documentation") Signed-off-by: Robert Hancock Reviewed-by: Rob Herring Acked-by: Michal Simek Link: https://lore.kernel.org/r/20220127173450.3684318-2-robert.hancock@calian.com Cc: Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml b/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml index 87992db389b2..3698b4b0900f 100644 --- a/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml +++ b/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml @@ -92,6 +92,10 @@ properties: description: AMS Controller register space maxItems: 1 + clocks: + items: + - description: AMS reference clock + ranges: description: Maps the child address space for PS and/or PL. @@ -181,12 +185,15 @@ properties: required: - compatible - reg + - clocks - ranges additionalProperties: false examples: - | + #include + bus { #address-cells = <2>; #size-cells = <2>; @@ -196,6 +203,7 @@ examples: interrupt-parent = <&gic>; interrupts = <0 56 4>; reg = <0x0 0xffa50000 0x0 0x800>; + clocks = <&zynqmp_clk AMS_REF>; #address-cells = <1>; #size-cells = <1>; #io-channel-cells = <1>; -- cgit From ee8ad9440f18478796dbd7e0891efcc44376ab70 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Tue, 1 Mar 2022 13:42:43 +0000 Subject: spi: dt-bindings: renesas,rspi: Drop comment for generic compatible string Drop comment "# RZ/A and RZ/G2{L,LC}" for generic compatible string "renesas,rspi-rz" as this will avoid changing the line for every new SoC addition. Suggested-by: Geert Uytterhoeven Signed-off-by: Lad Prabhakar Link: https://lore.kernel.org/r/20220301134244.20174-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/renesas,rspi.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/renesas,rspi.yaml b/Documentation/devicetree/bindings/spi/renesas,rspi.yaml index a902f0ca2198..2c3c6bd6ec45 100644 --- a/Documentation/devicetree/bindings/spi/renesas,rspi.yaml +++ b/Documentation/devicetree/bindings/spi/renesas,rspi.yaml @@ -23,7 +23,7 @@ properties: - renesas,rspi-r7s9210 # RZ/A2 - renesas,r9a07g044-rspi # RZ/G2{L,LC} - renesas,r9a07g054-rspi # RZ/V2L - - const: renesas,rspi-rz # RZ/A and RZ/G2{L,LC} + - const: renesas,rspi-rz - items: - enum: -- cgit From d149dd2a806b9d11e570c3731eca8bda3c5f6238 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 1 Mar 2022 15:23:57 -0600 Subject: spi: dt-bindings: mediatek: Set min size for 'mediatek,pad-select' The minimum array length defaults to the same size as the maximum. For 'mediatek,pad-select', the example has a length of 2 and in-tree .dts files have a length of 1, but the schema says the length must be 4. There's currently no warning in the example because the schema fixups are not handling this case correctly. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220301212358.1887668-1-robh@kernel.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml index bfa44acb1bdd..ac9ff12ae27a 100644 --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml @@ -62,6 +62,7 @@ properties: mediatek,pad-select: $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 maxItems: 4 items: enum: [0, 1, 2, 3] -- cgit From 7a37e890bd5db4a89a17ec9bcd7e5f4a33396648 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Tue, 1 Mar 2022 12:42:55 +0000 Subject: dt-bindings: phy: renesas,usb2-phy: Document RZ/V2L phy bindings Document USB phy bindings for RZ/V2L SoC. RZ/V2L USB phy is identical to one found on the RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,rzg2l-usb2-phy" will be used as a fallback. While at it, drop the comment "RZ/G2L family" for "renesas,rzg2l-usb2-phy" compatible string as this will avoid changing the line for every new SoC addition. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Acked-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20220301124255.16836-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml index 3a6e1165419c..16807bbbdcb1 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml @@ -33,7 +33,8 @@ properties: - items: - enum: - renesas,usb2-phy-r9a07g044 # RZ/G2{L,LC} - - const: renesas,rzg2l-usb2-phy # RZ/G2L family + - renesas,usb2-phy-r9a07g054 # RZ/V2L + - const: renesas,rzg2l-usb2-phy reg: maxItems: 1 -- cgit From 40b95583561e18480d36c732b89cc1126725078c Mon Sep 17 00:00:00 2001 From: Pratyush Yadav Date: Tue, 1 Mar 2022 16:46:19 +0530 Subject: phy: dt-bindings: Convert Cadence DPHY binding to YAML Convert Cadence DPHY binding to YAML. Signed-off-by: Pratyush Yadav Reviewed-by: Laurent Pinchart Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220301111621.2992275-3-p.yadav@ti.com Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/cdns,dphy.txt | 20 --------- .../devicetree/bindings/phy/cdns,dphy.yaml | 51 ++++++++++++++++++++++ 2 files changed, 51 insertions(+), 20 deletions(-) delete mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.txt b/Documentation/devicetree/bindings/phy/cdns,dphy.txt deleted file mode 100644 index 1095bc4e72d9..000000000000 --- a/Documentation/devicetree/bindings/phy/cdns,dphy.txt +++ /dev/null @@ -1,20 +0,0 @@ -Cadence DPHY -============ - -Cadence DPHY block. - -Required properties: -- compatible: should be set to "cdns,dphy". -- reg: physical base address and length of the DPHY registers. -- clocks: DPHY reference clocks. -- clock-names: must contain "psm" and "pll_ref". -- #phy-cells: must be set to 0. - -Example: - dphy0: dphy@fd0e0000{ - compatible = "cdns,dphy"; - reg = <0x0 0xfd0e0000 0x0 0x1000>; - clocks = <&psm_clk>, <&pll_ref_clk>; - clock-names = "psm", "pll_ref"; - #phy-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml new file mode 100644 index 000000000000..b90a58773bf2 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/cdns,dphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence DPHY Device Tree Bindings + +maintainers: + - Pratyush Yadav + +properties: + compatible: + items: + - const: cdns,dphy + + reg: + maxItems: 1 + + clocks: + items: + - description: PMA state machine clock + - description: PLL reference clock + + clock-names: + items: + - const: psm + - const: pll_ref + + "#phy-cells": + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + - "#phy-cells" + +additionalProperties: false + +examples: + - | + + dphy0: phy@fd0e0000{ + compatible = "cdns,dphy"; + reg = <0xfd0e0000 0x1000>; + clocks = <&psm_clk>, <&pll_ref_clk>; + clock-names = "psm", "pll_ref"; + #phy-cells = <0>; + }; -- cgit From 222e7d3f623506460658db7a3acdb7847329888d Mon Sep 17 00:00:00 2001 From: Pratyush Yadav Date: Tue, 1 Mar 2022 16:46:20 +0530 Subject: phy: dt-bindings: cdns,dphy: add power-domains property This property is needed on TI platforms to enable the PD of the DPHY before it can be used. Signed-off-by: Pratyush Yadav Reviewed-by: Laurent Pinchart Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220301111621.2992275-4-p.yadav@ti.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/cdns,dphy.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml index b90a58773bf2..c50629bd1b51 100644 --- a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml +++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml @@ -30,6 +30,9 @@ properties: "#phy-cells": const: 0 + power-domains: + maxItems: 1 + required: - compatible - reg @@ -41,11 +44,13 @@ additionalProperties: false examples: - | + #include dphy0: phy@fd0e0000{ compatible = "cdns,dphy"; reg = <0xfd0e0000 0x1000>; clocks = <&psm_clk>, <&pll_ref_clk>; clock-names = "psm", "pll_ref"; + power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>; #phy-cells = <0>; }; -- cgit From e02cebea3fbcaa4de8e31c88ff64f90c26497eaa Mon Sep 17 00:00:00 2001 From: Pratyush Yadav Date: Tue, 1 Mar 2022 16:46:21 +0530 Subject: phy: dt-bindings: Add Cadence D-PHY Rx bindings The Rx mode DPHY is different from Tx mode DPHY. Add a separate binding for it. Signed-off-by: Pratyush Yadav Reviewed-by: Laurent Pinchart Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220301111621.2992275-5-p.yadav@ti.com Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/cdns,dphy-rx.yaml | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml new file mode 100644 index 000000000000..07be031d82e6 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/cdns,dphy-rx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence DPHY Rx Device Tree Bindings + +maintainers: + - Pratyush Yadav + +properties: + compatible: + items: + - const: cdns,dphy-rx + + reg: + maxItems: 1 + + "#phy-cells": + const: 0 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - "#phy-cells" + +additionalProperties: false + +examples: + - | + #include + + dphy0: phy@4580000 { + compatible = "cdns,dphy-rx"; + reg = <0x4580000 0x1100>; + #phy-cells = <0>; + power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>; + }; -- cgit From bb1fea8454b4babd04b401f4dd9f4e8f6b82900b Mon Sep 17 00:00:00 2001 From: Vinod Koul Date: Wed, 2 Mar 2022 20:04:27 +0530 Subject: dt-bindings: Revert "dt-bindings: soc: grf: add naneng combo phy register compatible" This reverts commit b3df807e1fb0 ("dt-bindings: soc: grf: add naneng combo phy register compatible") as that was wrongly merged, so better to drop the wrong patch Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20220302143427.447748-1-vkoul@kernel.org Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index fe68e22efce0..dfebf425ca49 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -38,8 +38,6 @@ properties: - rockchip,rk3399-grf - rockchip,rk3399-pmugrf - rockchip,rk3568-grf - - rockchip,rk3568-pipe-grf - - rockchip,rk3568-pipe-phy-grf - rockchip,rk3568-pmugrf - rockchip,rv1108-grf - rockchip,rv1108-pmugrf -- cgit From 641024df6a8215b19e87b10ede7e68d3c5d2281c Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Thu, 24 Feb 2022 19:40:48 -0800 Subject: dt-bindings: phy: qcom,usb-snps-femto-v2: Add sc8180x and sc8280xp Add compatible for the femto USB PHY found in sc8180x, sc8280xp and the generic 5nm form of the latter. Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220225034049.2294207-1-bjorn.andersson@linaro.org Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml index 0dfe6914ec87..1ce251de0855 100644 --- a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml @@ -15,8 +15,11 @@ description: | properties: compatible: enum: + - qcom,usb-snps-hs-5nm-phy - qcom,usb-snps-hs-7nm-phy - qcom,sc7280-usb-hs-phy + - qcom,sc8180x-usb-hs-phy + - qcom,sc8280xp-usb-hs-phy - qcom,sm8150-usb-hs-phy - qcom,sm8250-usb-hs-phy - qcom,sm8350-usb-hs-phy -- cgit From f01da68667dce6f9cfd48dc98c3c0704fa0b55cb Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Thu, 24 Feb 2022 19:51:04 -0800 Subject: dt-bindings: phy: qcom,qmp: add sc8180x and sc8280xp ufs compatibles Add compatible for the UFS PHY found in the Qualcomm SC8280XP platform and document the required clocks for this and the SC8180X UFS PHY. Signed-off-by: Bjorn Andersson Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220225035105.2294599-1-bjorn.andersson@linaro.org Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index e417cd667997..e20d9b087bb8 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -32,6 +32,7 @@ properties: - qcom,sc8180x-qmp-pcie-phy - qcom,sc8180x-qmp-ufs-phy - qcom,sc8180x-qmp-usb3-phy + - qcom,sc8280xp-qmp-ufs-phy - qcom,sdm845-qhp-pcie-phy - qcom,sdm845-qmp-pcie-phy - qcom,sdm845-qmp-ufs-phy @@ -280,6 +281,8 @@ allOf: - qcom,sdm845-qmp-ufs-phy - qcom,sm8150-qmp-ufs-phy - qcom,sm8250-qmp-ufs-phy + - qcom,sc8180x-qmp-ufs-phy + - qcom,sc8280xp-qmp-ufs-phy then: properties: clocks: -- cgit From c7449e766de3c7334d5ded1ab18e17fb9fb4dd76 Mon Sep 17 00:00:00 2001 From: Srinivas Kandagatla Date: Mon, 28 Feb 2022 17:25:27 +0000 Subject: dt-bindings: soundwire: qcom: document optional wake irq Wake IRQ is optional interrupt that can be wired up on SoundWire controller instances like RX path along with MBHC(Multi Button Headset connection). Document this in bindings. Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220228172528.3489-3-srinivas.kandagatla@linaro.org Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/soundwire/qcom,sdw.txt | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt index b93a2b3e029d..51ddbc509382 100644 --- a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt +++ b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt @@ -22,7 +22,19 @@ board specific bus parameters. - interrupts: Usage: required Value type: - Definition: should specify the SoundWire Controller IRQ + Definition: should specify the SoundWire Controller core and optional + wake IRQ + +- interrupt-names: + Usage: Optional + Value type: boolean + Value type: + Definition: should be "core" for core and "wakeup" for wake interrupt. + +- wakeup-source: + Usage: Optional + Value type: boolean + Definition: should specify if SoundWire Controller is wake up capable. - clock-names: Usage: required -- cgit From ff4670ed6e8137642b0760aa198bc04188451b80 Mon Sep 17 00:00:00 2001 From: Marcello Sylvester Bauer Date: Wed, 2 Mar 2022 10:49:19 +0100 Subject: dt-bindings: trivial-devices: Add xdpe11280 Add Infineon Multi-phase Digital Controller XDPE11280. Signed-off-by: Marcello Sylvester Bauer Acked-by: Rob Herring Link: https://lore.kernel.org/r/81c0523ba790965a371d267bb1944652d80f5f72.1646214248.git.sylv@sylv.io Signed-off-by: Guenter Roeck --- Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 1c49bbc654ee..da929cb08463 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -137,6 +137,8 @@ properties: - infineon,slb9645tt # Infineon TLV493D-A1B6 I2C 3D Magnetic Sensor - infineon,tlv493d-a1b6 + # Infineon Multi-phase Digital VR Controller xdpe11280 + - infineon,xdpe11280 # Infineon Multi-phase Digital VR Controller xdpe12254 - infineon,xdpe12254 # Infineon Multi-phase Digital VR Controller xdpe12284 -- cgit From efdab64d88ab693bdcadc23780e347cc4185d4be Mon Sep 17 00:00:00 2001 From: Marcello Sylvester Bauer Date: Wed, 2 Mar 2022 10:49:20 +0100 Subject: hwmon: (xdpe12284) Add support for xdpe11280 Add support for another Infineon Multi-phase controller chip. The xdpe11280 uses linear instead of vid data format for VOUT. Detect VOUT_MODE format during identification and skip the xdpe122 related adaptions in case it is linear. Signed-off-by: Marcello Sylvester Bauer Link: https://lore.kernel.org/r/fa6a4b636a05ecb337d132824efca2545188a2a2.1646214248.git.sylv@sylv.io Signed-off-by: Guenter Roeck --- Documentation/hwmon/xdpe12284.rst | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/xdpe12284.rst b/Documentation/hwmon/xdpe12284.rst index 67d1f87808e5..a224dc74ad35 100644 --- a/Documentation/hwmon/xdpe12284.rst +++ b/Documentation/hwmon/xdpe12284.rst @@ -5,6 +5,10 @@ Kernel driver xdpe122 Supported chips: + * Infineon XDPE11280 + + Prefix: 'xdpe11280' + * Infineon XDPE12254 Prefix: 'xdpe12254' @@ -20,10 +24,10 @@ Authors: Description ----------- -This driver implements support for Infineon Multi-phase XDPE122 family -dual loop voltage regulators. -The family includes XDPE12284 and XDPE12254 devices. -The devices from this family complaint with: +This driver implements support for Infineon Multi-phase XDPE112 and XDPE122 +family dual loop voltage regulators. +These families include XDPE11280, XDPE12284 and XDPE12254 devices. +The devices from this family compliant with: - Intel VR13 and VR13HC rev 1.3, IMVP8 rev 1.2 and IMPVP9 rev 1.3 DC-DC converter specification. -- cgit From a113870165b862440a31a8614fa6905a85033486 Mon Sep 17 00:00:00 2001 From: Potin Lai Date: Wed, 2 Mar 2022 20:38:17 +0800 Subject: dt-bindings: hwmon: Add sample averaging properties for ADM1275 Add documentation of new properties for sample averaging in PMON_CONFIG register. New properties: - adi,volt-curr-sample-average - adi,power-sample-average Signed-off-by: Potin Lai Reviewed-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220302123817.27025-3-potin.lai@quantatw.com Signed-off-by: Guenter Roeck --- .../devicetree/bindings/hwmon/adi,adm1275.yaml | 68 ++++++++++++++++++++++ 1 file changed, 68 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml index 223393d7cafd..ab87f51c5aef 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml @@ -37,6 +37,72 @@ properties: description: Shunt resistor value in micro-Ohm. + adi,volt-curr-sample-average: + description: | + Number of samples to be used to report voltage and current values. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8, 16, 32, 64, 128] + + adi,power-sample-average: + description: | + Number of samples to be used to report power values. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8, 16, 32, 64, 128] + +allOf: + - if: + properties: + compatible: + contains: + enum: + - adi,adm1075 + - adi,adm1276 + then: + properties: + adi,volt-curr-sample-average: + default: 128 + adi,power-sample-average: false + + - if: + properties: + compatible: + contains: + enum: + - adi,adm1275 + then: + properties: + adi,volt-curr-sample-average: + default: 16 + adi,power-sample-average: false + + - if: + properties: + compatible: + contains: + enum: + - adi,adm1272 + then: + properties: + adi,volt-curr-sample-average: + default: 128 + adi,power-sample-average: + default: 128 + + - if: + properties: + compatible: + contains: + enum: + - adi,adm1278 + - adi,adm1293 + - adi,adm1294 + then: + properties: + adi,volt-curr-sample-average: + default: 128 + adi,power-sample-average: + default: 1 + required: - compatible - reg @@ -53,5 +119,7 @@ examples: compatible = "adi,adm1272"; reg = <0x10>; shunt-resistor-micro-ohms = <500>; + adi,volt-curr-sample-average = <128>; + adi,power-sample-average = <128>; }; }; -- cgit From 9ae2ac4d31a85ce59cc560d514a31b95f4ace154 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Wed, 23 Feb 2022 20:38:04 +0100 Subject: drm: Add TODO item for optimizing format helpers Add a TODO item for optimizing blitting and format-conversion helpers in DRM and fbdev. There's always demand for faster graphics output. v4: * fix typos (Sam) Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20220223193804.18636-6-tzimmermann@suse.de --- Documentation/gpu/todo.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index d6a7ebf717be..4260c62d751b 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -241,6 +241,28 @@ Contact: Thomas Zimmermann , Daniel Vetter Level: Advanced +Benchmark and optimize blitting and format-conversion function +-------------------------------------------------------------- + +Drawing to dispay memory quickly is crucial for many applications' +performance. + +On at least x86-64, sys_imageblit() is significantly slower than +cfb_imageblit(), even though both use the same blitting algorithm and +the latter is written for I/O memory. It turns out that cfb_imageblit() +uses movl instructions, while sys_imageblit apparently does not. This +seems to be a problem with gcc's optimizer. DRM's format-conversion +helpers might be subject to similar issues. + +Benchmark and optimize fbdev's sys_() helpers and DRM's format-conversion +helpers. In cases that can be further optimized, maybe implement a different +algorithm. For micro-optimizations, use movl/movq instructions explicitly. +That might possibly require architecture-specific helpers (e.g., storel() +storeq()). + +Contact: Thomas Zimmermann + +Level: Intermediate drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup ----------------------------------------------------------------- -- cgit From dca669354e6ff494222dfc461bed1087264f3755 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Mon, 28 Feb 2022 15:38:02 -0600 Subject: dt-bindings: Another pass removing cases of 'allOf' containing a '$ref' MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Another pass at removing unnecessary use of 'allOf' with a '$ref'. json-schema versions draft7 and earlier have a weird behavior in that any keywords combined with a '$ref' are ignored (silently). The correct form was to put a '$ref' under an 'allOf'. This behavior is now changed in the 2019-09 json-schema spec and '$ref' can be mixed with other keywords. Cc: Krzysztof Kozlowski Cc: Thierry Reding Cc: Sam Ravnborg Cc: Dmitry Torokhov Cc: Pavel Machek Cc: Guenter Roeck Cc: Richard Weinberger Cc: Vignesh Raghavendra Cc: "David S. Miller" Cc: Kishon Vijay Abraham I Cc: Sebastian Reichel Cc: Mathieu Poirier Signed-off-by: Rob Herring Acked-by: Mark Brown Reviewed-by: Greg Kroah-Hartman Acked-By: Vinod Koul Acked-by: Lee Jones Acked-by: Marek Behún Acked-by: Miquel Raynal Reviewed-by: Laurent Pinchart Acked-by: Jakub Kicinski Acked-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220228213802.1639658-1-robh@kernel.org --- .../devicetree/bindings/connector/usb-connector.yaml | 3 +-- .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 3 +-- .../devicetree/bindings/display/bridge/adi,adv7511.yaml | 5 ++--- .../bindings/display/bridge/synopsys,dw-hdmi.yaml | 5 ++--- .../bindings/display/panel/display-timings.yaml | 3 +-- Documentation/devicetree/bindings/display/ste,mcde.yaml | 4 ++-- Documentation/devicetree/bindings/input/adc-joystick.yaml | 9 ++++----- .../devicetree/bindings/leds/cznic,turris-omnia-leds.yaml | 3 +-- Documentation/devicetree/bindings/leds/leds-lp50xx.yaml | 3 +-- Documentation/devicetree/bindings/mfd/google,cros-ec.yaml | 12 ++++-------- .../devicetree/bindings/mtd/rockchip,nand-controller.yaml | 3 +-- Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml | 3 +-- .../devicetree/bindings/phy/phy-stm32-usbphyc.yaml | 3 +-- .../devicetree/bindings/power/supply/sbs,sbs-manager.yaml | 4 +--- .../devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml | 3 +-- Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml | 15 +++------------ Documentation/devicetree/bindings/sound/st,stm32-sai.yaml | 3 +-- .../devicetree/bindings/sound/tlv320adcx140.yaml | 13 ++++++------- Documentation/devicetree/bindings/spi/spi-controller.yaml | 4 +--- Documentation/devicetree/bindings/usb/st,stusb160x.yaml | 4 +--- 20 files changed, 36 insertions(+), 69 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index 7eb8659fa610..0420fa563532 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -104,8 +104,7 @@ properties: - "1.5A" and "3.0A", 5V 1.5A and 5V 3.0A respectively, as defined in USB Type-C Cable and Connector specification, when Power Delivery is not supported. - allOf: - - $ref: /schemas/types.yaml#/definitions/string + $ref: /schemas/types.yaml#/definitions/string enum: - default - 1.5A diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml index a1d5a32660e0..a9d34dd7bbc5 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml @@ -72,8 +72,7 @@ properties: - const: hpd-removed ddc: - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: > Phandle of the I2C controller used for DDC EDID probing diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml index d3dd7a79b909..f08a01dfedf3 100644 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml @@ -76,9 +76,8 @@ properties: adi,input-depth: description: Number of bits per color component at the input. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 8, 10, 12 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 8, 10, 12 ] adi,input-colorspace: description: Input color space. diff --git a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml index 9be44a682e67..b00246faea57 100644 --- a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml @@ -26,9 +26,8 @@ properties: reg-io-width: description: Width (in bytes) of the registers specified by the reg property. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [1, 4] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 4] default: 1 clocks: diff --git a/Documentation/devicetree/bindings/display/panel/display-timings.yaml b/Documentation/devicetree/bindings/display/panel/display-timings.yaml index 56903ded005e..6d30575819d3 100644 --- a/Documentation/devicetree/bindings/display/panel/display-timings.yaml +++ b/Documentation/devicetree/bindings/display/panel/display-timings.yaml @@ -31,8 +31,7 @@ properties: patternProperties: "^timing": type: object - allOf: - - $ref: panel-timing.yaml# + $ref: panel-timing.yaml# additionalProperties: false diff --git a/Documentation/devicetree/bindings/display/ste,mcde.yaml b/Documentation/devicetree/bindings/display/ste,mcde.yaml index de0c678b3c29..564ea845c82e 100644 --- a/Documentation/devicetree/bindings/display/ste,mcde.yaml +++ b/Documentation/devicetree/bindings/display/ste,mcde.yaml @@ -58,8 +58,8 @@ patternProperties: "^dsi@[0-9a-f]+$": description: subnodes for the three DSI host adapters type: object - allOf: - - $ref: dsi-controller.yaml# + $ref: dsi-controller.yaml# + properties: compatible: const: ste,mcde-dsi diff --git a/Documentation/devicetree/bindings/input/adc-joystick.yaml b/Documentation/devicetree/bindings/input/adc-joystick.yaml index 721878d5b7af..2ee04e03bc22 100644 --- a/Documentation/devicetree/bindings/input/adc-joystick.yaml +++ b/Documentation/devicetree/bindings/input/adc-joystick.yaml @@ -61,11 +61,10 @@ patternProperties: description: EV_ABS specific event code generated by the axis. abs-range: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - items: - - description: minimum value - - description: maximum value + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: minimum value + - description: maximum value description: > Minimum and maximum values produced by the axis. For an ABS_X axis this will be the left-most and right-most diff --git a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml index c7ed2871da06..9362b1ef9e88 100644 --- a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml +++ b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml @@ -32,8 +32,7 @@ properties: patternProperties: "^multi-led@[0-9a-b]$": type: object - allOf: - - $ref: leds-class-multicolor.yaml# + $ref: leds-class-multicolor.yaml# description: This node represents one of the RGB LED devices on Turris Omnia. No subnodes need to be added for subchannels since this controller only diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml index c192b5feadc7..f12fe5b53f30 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml +++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml @@ -55,8 +55,7 @@ properties: patternProperties: '^multi-led@[0-9a-f]$': type: object - allOf: - - $ref: leds-class-multicolor.yaml# + $ref: leds-class-multicolor.yaml# properties: reg: minItems: 1 diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml index d1f53bd449f7..a52f3a82283c 100644 --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml @@ -38,18 +38,14 @@ properties: description: This property specifies the delay in usecs between the assertion of the CS and the first clock pulse. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - default: 0 - - minimum: 0 + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 google,cros-ec-spi-msg-delay: description: This property specifies the delay in usecs between messages. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - default: 0 - - minimum: 0 + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 google,has-vbc-nvram: description: diff --git a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml index 0922536b1811..d681a4676f06 100644 --- a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml @@ -96,8 +96,7 @@ patternProperties: rockchip,boot-ecc-strength: enum: [16, 24, 40, 60, 70] - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | If specified it indicates that a different BCH/ECC setting is supported by the boot ROM. diff --git a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml index 07a00f53adbf..31bf825c6598 100644 --- a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml +++ b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml @@ -88,8 +88,7 @@ properties: type: object description: CPSW external ports - allOf: - - $ref: ethernet-controller.yaml# + $ref: ethernet-controller.yaml# properties: reg: diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml index 267b695215b6..dc287d428e49 100644 --- a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml +++ b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml @@ -76,8 +76,7 @@ patternProperties: connector: type: object - allOf: - - $ref: ../connector/usb-connector.yaml + $ref: /schemas/connector/usb-connector.yaml properties: vbus-supply: true diff --git a/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml index 72e8f274c791..99f506d6b0a0 100644 --- a/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml +++ b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml @@ -46,9 +46,7 @@ additionalProperties: false patternProperties: "^i2c@[1-4]$": type: object - - allOf: - - $ref: /schemas/i2c/i2c-controller.yaml# + $ref: /schemas/i2c/i2c-controller.yaml# examples: - | diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml index 0868154a0364..fb9605f0655b 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml @@ -95,8 +95,7 @@ patternProperties: addresses. Cache and memory access settings are provided through a Memory Protection Unit (MPU), programmable only from the R5Fs. - allOf: - - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml# + $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml index 9d128b9e7deb..64461d432004 100644 --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml @@ -281,10 +281,7 @@ patternProperties: PRUSS INTC Node. Each PRUSS has a single interrupt controller instance that is common to all the PRU cores. This should be represented as an interrupt-controller node. - - allOf: - - $ref: /schemas/interrupt-controller/ti,pruss-intc.yaml# - + $ref: /schemas/interrupt-controller/ti,pruss-intc.yaml# type: object mdio@[a-f0-9]+$: @@ -292,10 +289,7 @@ patternProperties: MDIO Node. Each PRUSS has an MDIO module that can be used to control external PHYs. The MDIO module used within the PRU-ICSS is an instance of the MDIO Controller used in TI Davinci SoCs. - - allOf: - - $ref: /schemas/net/ti,davinci-mdio.yaml# - + $ref: /schemas/net/ti,davinci-mdio.yaml# type: object "^(pru|rtu|txpru)@[0-9a-f]+$": @@ -305,10 +299,7 @@ patternProperties: inactive by using the standard DT string property, "status". The ICSSG IP present on K3 SoCs have additional auxiliary PRU cores with slightly different IP integration. - - allOf: - - $ref: /schemas/remoteproc/ti,pru-rproc.yaml# - + $ref: /schemas/remoteproc/ti,pru-rproc.yaml# type: object required: diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml index d4fc8fdcb72f..b3dbcba33e41 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -115,8 +115,7 @@ patternProperties: By default, custom protocol is assumed, meaning that protocol is configured according to protocol defined in related DAI link node, such as i2s, left justified, right justified, dsp and pdm protocols. - allOf: - - $ref: /schemas/types.yaml#/definitions/flag + $ref: /schemas/types.yaml#/definitions/flag "#clock-cells": description: Configure the SAI device as master clock provider. diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml index d77c8283526d..2ad17b361db0 100644 --- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml +++ b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml @@ -176,13 +176,12 @@ patternProperties: 4 - Drive weak low and active high 5 - Drive Hi-Z and active high - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 2 - maxItems: 2 - items: - maximum: 15 - default: [2, 2] + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + items: + maximum: 15 + default: [2, 2] required: - compatible diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index 36b72518f565..6d0511a8727f 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -93,9 +93,7 @@ properties: patternProperties: "^.*@[0-9a-f]+$": type: object - - allOf: - - $ref: spi-peripheral-props.yaml + $ref: spi-peripheral-props.yaml required: - compatible diff --git a/Documentation/devicetree/bindings/usb/st,stusb160x.yaml b/Documentation/devicetree/bindings/usb/st,stusb160x.yaml index ead1571e0e43..b5a8c9814dd3 100644 --- a/Documentation/devicetree/bindings/usb/st,stusb160x.yaml +++ b/Documentation/devicetree/bindings/usb/st,stusb160x.yaml @@ -32,9 +32,7 @@ properties: connector: type: object - - allOf: - - $ref: ../connector/usb-connector.yaml + $ref: /schemas/connector/usb-connector.yaml# properties: compatible: -- cgit From 8ddb80c5fcf455fe38156636126a83eadacfb743 Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Wed, 2 Mar 2022 03:14:10 +0300 Subject: dt-bindings: display/msm: add missing brace in dpu-qcm2290.yaml Add missing brace in dpu-qcm2290.yaml. While we are at it, also fix indentation for another brace, so it matches the corresponding line. Reported-by: Rob Herring Cc: Loic Poulain Reviewed-by: Bjorn Andersson Signed-off-by: Dmitry Baryshkov Fixes: 164f69d9d45a ("dt-bindings: msm: disp: add yaml schemas for QCM2290 DPU bindings") Link: https://lore.kernel.org/r/20220302001410.2264039-1-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark Reviewed-by: Abhinav Kumar Reviewed-by: Stephen Boyd Signed-off-by: Dmitry Baryshkov --- Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml index 28617bc1d2ff..d31483a78eab 100644 --- a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml +++ b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml @@ -209,6 +209,7 @@ examples: remote-endpoint = <&dsi0_in>; }; }; - }; + }; }; + }; ... -- cgit From 0409ab77728d705f376ae28fd7114161295e7ed2 Mon Sep 17 00:00:00 2001 From: Lukasz Luba Date: Wed, 2 Mar 2022 11:29:13 +0000 Subject: dt-bindings: opp: Add "opp-microwatt" entry in the OPP Add new entry for the OPP which provides information about power expressed in micro-Watts. It is useful for the Energy Model framework. Signed-off-by: Lukasz Luba Reviewed-by: Rob Herring Signed-off-by: Viresh Kumar --- .../devicetree/bindings/opp/opp-v2-base.yaml | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml index 15a76bcd6d42..04a592c0f862 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml @@ -93,6 +93,21 @@ patternProperties: minItems: 1 maxItems: 8 # Should be enough regulators + opp-microwatt: + description: | + The power for the OPP in micro-Watts. + + Entries for multiple regulators shall be provided in the same field + separated by angular brackets <>. If current values aren't required + for a regulator, then it shall be filled with 0. If power values + aren't required for any of the regulators, then this field is not + required. The OPP binding doesn't provide any provisions to relate the + values to their power supplies or the order in which the supplies need + to be configured and that is left for the implementation specific + binding. + minItems: 1 + maxItems: 8 # Should be enough regulators + opp-level: description: A value representing the performance level of the device. @@ -203,6 +218,14 @@ patternProperties: minItems: 1 maxItems: 8 # Should be enough regulators + '^opp-microwatt': + description: + Named opp-microwatt property. Similar to opp-microamp property, + but for microwatt instead. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 # Should be enough regulators + dependencies: opp-avg-kBps: [ opp-peak-kBps ] -- cgit From f48a0c475c2aec8f2274703e1dc7be503f40f7cc Mon Sep 17 00:00:00 2001 From: Lukasz Luba Date: Wed, 2 Mar 2022 11:29:17 +0000 Subject: Documentation: EM: Describe new registration method using DT The new registration method allows to get power values from the DT OPP definition. The new OPP entry property "opp-microwatt" contains total power expressed in micro-Watts. Align the EM documentation with this new possible registration method of EM. Signed-off-by: Lukasz Luba Signed-off-by: Viresh Kumar --- Documentation/power/energy-model.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst index 5ac62a7b4b7c..49549aab41b4 100644 --- a/Documentation/power/energy-model.rst +++ b/Documentation/power/energy-model.rst @@ -113,6 +113,16 @@ to: return warning/error, stop working or panic. See Section 3. for an example of driver implementing this callback, or Section 2.4 for further documentation on this API +Registration of EM using DT +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The EM can also be registered using OPP framework and information in DT +"operating-points-v2". Each OPP entry in DT can be extended with a property +"opp-microwatt" containing micro-Watts power value. This OPP DT property +allows a platform to register EM power values which are reflecting total power +(static + dynamic). These power values might be coming directly from +experiments and measurements. + Registration of 'simple' EM ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit From 3a9a6f3da073304fe64a27a319760524a6f5f671 Mon Sep 17 00:00:00 2001 From: Nikita Yushchenko Date: Fri, 24 Dec 2021 08:23:09 +0300 Subject: dt-bindings: display: bridge: renesas,lvds: Document r8a77961 bindings Document the R-Car M3-W+ (R8A77961) SoC in the R-Car LVDS encoder bindings. Signed-off-by: Nikita Yushchenko Reviewed-by: Laurent Pinchart Acked-by: Rob Herring Signed-off-by: Laurent Pinchart --- Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml index acfc327f70a7..a51baf8a4c76 100644 --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml @@ -28,6 +28,7 @@ properties: - renesas,r8a7793-lvds # for R-Car M2-N compatible LVDS encoders - renesas,r8a7795-lvds # for R-Car H3 compatible LVDS encoders - renesas,r8a7796-lvds # for R-Car M3-W compatible LVDS encoders + - renesas,r8a77961-lvds # for R-Car M3-W+ compatible LVDS encoders - renesas,r8a77965-lvds # for R-Car M3-N compatible LVDS encoders - renesas,r8a77970-lvds # for R-Car V3M compatible LVDS encoders - renesas,r8a77980-lvds # for R-Car V3H compatible LVDS encoders -- cgit From a3dd98281b9f265c7b89cb0c7a91739bff2e6506 Mon Sep 17 00:00:00 2001 From: Joe Damato Date: Tue, 1 Mar 2022 23:55:50 -0800 Subject: Documentation: update networking/page_pool.rst Add the new stats API, kernel config parameter, and stats structure information to the page_pool documentation. Signed-off-by: Joe Damato Signed-off-by: David S. Miller --- Documentation/networking/page_pool.rst | 56 ++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/page_pool.rst b/Documentation/networking/page_pool.rst index a147591ce203..5db8c263b0c6 100644 --- a/Documentation/networking/page_pool.rst +++ b/Documentation/networking/page_pool.rst @@ -105,6 +105,47 @@ a page will cause no race conditions is enough. Please note the caller must not use data area after running page_pool_put_page_bulk(), as this function overwrites it. +* page_pool_get_stats(): Retrieve statistics about the page_pool. This API + is only available if the kernel has been configured with + ``CONFIG_PAGE_POOL_STATS=y``. A pointer to a caller allocated ``struct + page_pool_stats`` structure is passed to this API which is filled in. The + caller can then report those stats to the user (perhaps via ethtool, + debugfs, etc.). See below for an example usage of this API. + +Stats API and structures +------------------------ +If the kernel is configured with ``CONFIG_PAGE_POOL_STATS=y``, the API +``page_pool_get_stats()`` and structures described below are available. It +takes a pointer to a ``struct page_pool`` and a pointer to a ``struct +page_pool_stats`` allocated by the caller. + +The API will fill in the provided ``struct page_pool_stats`` with +statistics about the page_pool. + +The stats structure has the following fields:: + + struct page_pool_stats { + struct page_pool_alloc_stats alloc_stats; + struct page_pool_recycle_stats recycle_stats; + }; + + +The ``struct page_pool_alloc_stats`` has the following fields: + * ``fast``: successful fast path allocations + * ``slow``: slow path order-0 allocations + * ``slow_high_order``: slow path high order allocations + * ``empty``: ptr ring is empty, so a slow path allocation was forced. + * ``refill``: an allocation which triggered a refill of the cache + * ``waive``: pages obtained from the ptr ring that cannot be added to + the cache due to a NUMA mismatch. + +The ``struct page_pool_recycle_stats`` has the following fields: + * ``cached``: recycling placed page in the page pool cache + * ``cache_full``: page pool cache was full + * ``ring``: page placed into the ptr ring + * ``ring_full``: page released from page pool because the ptr ring was full + * ``released_refcnt``: page released (and not recycled) because refcnt > 1 + Coding examples =============== @@ -157,6 +198,21 @@ NAPI poller } } +Stats +----- + +.. code-block:: c + + #ifdef CONFIG_PAGE_POOL_STATS + /* retrieve stats */ + struct page_pool_stats stats = { 0 }; + if (page_pool_get_stats(page_pool, &stats)) { + /* perhaps the driver reports statistics with ethool */ + ethtool_print_allocation_stats(&stats.alloc_stats); + ethtool_print_recycle_stats(&stats.recycle_stats); + } + #endif + Driver unload ------------- -- cgit From 4db073174f95653c5436615fc3a9a8dbae659b65 Mon Sep 17 00:00:00 2001 From: Jonathan Lemon Date: Wed, 2 Mar 2022 13:34:59 -0800 Subject: docs: ABI: Document new timecard sysfs nodes. Add documentation for the tod_correction, clock_status_drift, and clock_status_offset nodes. Signed-off-by: Jonathan Lemon Signed-off-by: David S. Miller --- Documentation/ABI/testing/sysfs-timecard | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-timecard b/Documentation/ABI/testing/sysfs-timecard index 97f6773794a5..5bf78486a469 100644 --- a/Documentation/ABI/testing/sysfs-timecard +++ b/Documentation/ABI/testing/sysfs-timecard @@ -63,6 +63,18 @@ Description: (RW) Contains the current synchronization source used by the PHC. May be changed by writing one of the listed values from the available_clock_sources attribute set. +What: /sys/class/timecard/ocpN/clock_status_drift +Date: March 2022 +Contact: Jonathan Lemon +Description: (RO) Contains the current drift value used by the firmware + for internal disciplining of the atomic clock. + +What: /sys/class/timecard/ocpN/clock_status_offset +Date: March 2022 +Contact: Jonathan Lemon +Description: (RO) Contains the current offset value used by the firmware + for internal disciplining of the atomic clock. + What: /sys/class/timecard/ocpN/gnss_sync Date: September 2021 Contact: Jonathan Lemon @@ -126,6 +138,16 @@ Description: (RW) These attributes specify the direction of the signal The 10Mhz reference clock input is currently only valid on SMA1 and may not be combined with other destination sinks. +What: /sys/class/timecard/ocpN/tod_correction +Date: March 2022 +Contact: Jonathan Lemon +Description: (RW) The incoming GNSS signal is in UTC time, and the NMEA + format messages do not provide a TAI offset. This sets the + correction value for the incoming time. + + If UBX_LS is enabled, this should be 0, and the offset is + taken from the UBX-NAV-TIMELS message. + What: /sys/class/timecard/ocpN/ts_window_adjust Date: September 2021 Contact: Jonathan Lemon -- cgit From 949ea75b7ba4a8ea883b9d1a2bd0d391ffd86a80 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 2 Mar 2022 20:09:37 +0100 Subject: dt-bindings: usb: samsung,exynos-dwc3: convert to dtschema Convert the Samsung Exynos SoC USB 3.0 DWC3 Controller bindings to DT schema format. Reviewed-by: Rob Herring Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220302190938.6195-2-krzysztof.kozlowski@canonical.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/exynos-usb.txt | 49 -------- .../bindings/usb/samsung,exynos-dwc3.yaml | 129 +++++++++++++++++++++ 2 files changed, 129 insertions(+), 49 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt index f7ae79825d7d..61c03c0ef19f 100644 --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt @@ -64,52 +64,3 @@ Example: phys = <&usb2phy 1>; phy-names = "host"; }; - -DWC3 -Required properties: - - compatible: should be one of the following - - "samsung,exynos5250-dwusb3": for USB 3.0 DWC3 controller on - Exynos5250/5420. - "samsung,exynos5433-dwusb3": for USB 3.0 DWC3 controller on - Exynos5433. - "samsung,exynos7-dwusb3": for USB 3.0 DWC3 controller on Exynos7. - - #address-cells, #size-cells : should be '1' if the device has sub-nodes - with 'reg' property. - - ranges: allows valid 1:1 translation between child's address space and - parent's address space - - clocks: Clock IDs array as required by the controller. - - clock-names: Names of clocks corresponding to IDs in the clock property. - Following clock names shall be provided for different - compatibles: - - samsung,exynos5250-dwusb3: "usbdrd30", - - samsung,exynos5433-dwusb3: "aclk", "susp_clk", "pipe_pclk", - "phyclk", - - samsung,exynos7-dwusb3: "usbdrd30", "usbdrd30_susp_clk", - "usbdrd30_axius_clk" - - vdd10-supply: 1.0V powr supply - - vdd33-supply: 3.0V/3.3V power supply - -Sub-nodes: -The dwc3 core should be added as subnode to Exynos dwc3 glue. -- dwc3 : - The binding details of dwc3 can be found in: - Documentation/devicetree/bindings/usb/snps,dwc3.yaml - -Example: - usb@12000000 { - compatible = "samsung,exynos5250-dwusb3"; - clocks = <&clock 286>; - clock-names = "usbdrd30"; - #address-cells = <1>; - #size-cells = <1>; - ranges; - vdd10-supply = <&ldo11_reg>; - vdd33-supply = <&ldo9_reg>; - - dwc3 { - compatible = "synopsys,dwc3"; - reg = <0x12000000 0x10000>; - interrupts = <0 72 0>; - usb-phy = <&usb2_phy &usb3_phy>; - }; - }; diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml new file mode 100644 index 000000000000..22b91a27d776 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml @@ -0,0 +1,129 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/samsung,exynos-dwc3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC USB 3.0 DWC3 Controller + +maintainers: + - Krzysztof Kozlowski + +properties: + compatible: + enum: + - samsung,exynos5250-dwusb3 + - samsung,exynos5433-dwusb3 + - samsung,exynos7-dwusb3 + + '#address-cells': + const: 1 + + clocks: + minItems: 1 + maxItems: 4 + + clock-names: + minItems: 1 + maxItems: 4 + + ranges: true + + '#size-cells': + const: 1 + + vdd10-supply: + description: 1.0V power supply + + vdd33-supply: + description: 3.0V/3.3V power supply + +patternProperties: + "^usb@[0-9a-f]+$": + $ref: snps,dwc3.yaml# + description: Required child node + +required: + - compatible + - '#address-cells' + - clocks + - clock-names + - ranges + - '#size-cells' + - vdd10-supply + - vdd33-supply + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos5250-dwusb3 + then: + properties: + clocks: + minItems: 1 + maxItems: 1 + clock-names: + items: + - const: usbdrd30 + + - if: + properties: + compatible: + contains: + const: samsung,exynos54333-dwusb3 + then: + properties: + clocks: + minItems: 4 + maxItems: 4 + clock-names: + items: + - const: aclk + - const: susp_clk + - const: pipe_pclk + - const: phyclk + + - if: + properties: + compatible: + contains: + const: samsung,exynos7-dwusb3 + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: usbdrd30 + - const: usbdrd30_susp_clk + - const: usbdrd30_axius_clk + +additionalProperties: false + +examples: + - | + #include + #include + + usb { + compatible = "samsung,exynos5250-dwusb3"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + clocks = <&clock CLK_USBD300>; + clock-names = "usbdrd30"; + vdd33-supply = <&ldo9_reg>; + vdd10-supply = <&ldo11_reg>; + + usb@12000000 { + compatible = "snps,dwc3"; + reg = <0x12000000 0x10000>; + interrupts = ; + phys = <&usbdrd_phy0 0>, <&usbdrd_phy0 1>; + phy-names = "usb2-phy", "usb3-phy"; + snps,dis_u3_susphy_quirk; + }; + }; -- cgit From 4bf2283cb2084aa44ba79d30ca8e0e886ac98f8a Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 2 Mar 2022 20:09:38 +0100 Subject: dt-bindings: usb: samsung,exynos-usb2: convert to dtschema Convert the Samsung Exynos SoC USB 2.0 EHCI and OHCI Controller bindings to DT schema format. Reviewed-by: Rob Herring Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220302190938.6195-3-krzysztof.kozlowski@canonical.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/exynos-usb.txt | 66 ------------ .../bindings/usb/samsung,exynos-usb2.yaml | 117 +++++++++++++++++++++ 2 files changed, 117 insertions(+), 66 deletions(-) delete mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt create mode 100644 Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt deleted file mode 100644 index 61c03c0ef19f..000000000000 --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt +++ /dev/null @@ -1,66 +0,0 @@ -Samsung Exynos SoC USB controller - -The USB devices interface with USB controllers on Exynos SOCs. -The device node has following properties. - -EHCI -Required properties: - - compatible: should be "samsung,exynos4210-ehci" for USB 2.0 - EHCI controller in host mode. - - reg: physical base address of the controller and length of memory mapped - region. - - interrupts: interrupt number to the cpu. - - clocks: from common clock binding: handle to usb clock. - - clock-names: from common clock binding: Shall be "usbhost". - - phys: from the *Generic PHY* bindings; array specifying phy(s) used - by the root port. - - phy-names: from the *Generic PHY* bindings; array of the names for - each phy for the root ports, must be a subset of the following: - "host", "hsic0", "hsic1". - -Optional properties: - - samsung,vbus-gpio: if present, specifies the GPIO that - needs to be pulled up for the bus to be powered. - -Example: - - usb@12110000 { - compatible = "samsung,exynos4210-ehci"; - reg = <0x12110000 0x100>; - interrupts = <0 71 0>; - samsung,vbus-gpio = <&gpx2 6 1 3 3>; - - clocks = <&clock 285>; - clock-names = "usbhost"; - - phys = <&usb2phy 1>; - phy-names = "host"; - }; - -OHCI -Required properties: - - compatible: should be "samsung,exynos4210-ohci" for USB 2.0 - OHCI companion controller in host mode. - - reg: physical base address of the controller and length of memory mapped - region. - - interrupts: interrupt number to the cpu. - - clocks: from common clock binding: handle to usb clock. - - clock-names: from common clock binding: Shall be "usbhost". - - phys: from the *Generic PHY* bindings; array specifying phy(s) used - by the root port. - - phy-names: from the *Generic PHY* bindings; array of the names for - each phy for the root ports, must be a subset of the following: - "host", "hsic0", "hsic1". - -Example: - usb@12120000 { - compatible = "samsung,exynos4210-ohci"; - reg = <0x12120000 0x100>; - interrupts = <0 71 0>; - - clocks = <&clock 285>; - clock-names = "usbhost"; - - phys = <&usb2phy 1>; - phy-names = "host"; - }; diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml new file mode 100644 index 000000000000..fbf07d6e707a --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/samsung,exynos-usb2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC USB 2.0 EHCI/OHCI Controller + +maintainers: + - Krzysztof Kozlowski + +properties: + compatible: + enum: + - samsung,exynos4210-ehci + - samsung,exynos4210-ohci + + '#address-cells': + const: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: usbhost + + interrupts: + maxItems: 1 + + phys: + minItems: 1 + maxItems: 3 + + phy-names: + items: + enum: [host, hsic0, hsic1] + minItems: 1 + maxItems: 3 + + reg: + maxItems: 1 + + samsung,vbus-gpio: + description: + Only for controller in EHCI mode, if present, specifies the GPIO that + needs to be pulled up for the bus to be powered. + + '#size-cells': + const: 0 + +patternProperties: + "^.*@[0-9a-f]{1,2}$": + description: The hard wired USB devices + type: object + $ref: /usb/usb-device.yaml + +required: + - compatible + - clocks + - clock-names + - interrupts + - phys + - phy-names + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos4210-ohci + then: + properties: + samsung,vbus-gpio: false + +additionalProperties: false + +examples: + - | + #include + #include + + usb@12110000 { + compatible = "samsung,exynos4210-ehci"; + reg = <0x12110000 0x100>; + interrupts = ; + clocks = <&clock CLK_USBH20>; + clock-names = "usbhost"; + phys = <&usb2_phy 0>; + phy-names = "host"; + + #address-cells = <1>; + #size-cells = <0>; + + hub@1 { + compatible = "usb0424,9514"; + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + usbether@1 { + compatible = "usb0424,ec00"; + reg = <1>; + local-mac-address = [00 00 00 00 00 00]; + }; + }; + }; + + usb@12120000 { + compatible = "samsung,exynos4210-ohci"; + reg = <0x12120000 0x100>; + interrupts = ; + clocks = <&clock CLK_USBH20>; + clock-names = "usbhost"; + phys = <&usb2_phy 0>; + phy-names = "host"; + }; -- cgit From b4fa042e92e17f243bdfa2c53e3cd4c8b3dfb56c Mon Sep 17 00:00:00 2001 From: Agathe Porte Date: Tue, 22 Feb 2022 14:36:09 -0800 Subject: dt-bindings: hwmon: add tmp464.yaml Add basic description of the tmp464 driver DT bindings. Signed-off-by: Agathe Porte Cc: Krzysztof Adamski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220222223610.23098-1-linux@roeck-us.net Signed-off-by: Guenter Roeck --- .../devicetree/bindings/hwmon/ti,tmp464.yaml | 114 +++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml new file mode 100644 index 000000000000..801ca9ba7d34 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml @@ -0,0 +1,114 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/ti,tmp464.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TMP464 and TMP468 temperature sensors + +maintainers: + - Agathe Porte + +description: | + ±0.0625°C Remote and Local temperature sensor + https://www.ti.com/lit/ds/symlink/tmp464.pdf + https://www.ti.com/lit/ds/symlink/tmp468.pdf + +properties: + compatible: + enum: + - ti,tmp464 + - ti,tmp468 + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +required: + - compatible + - reg + +additionalProperties: false + +patternProperties: + "^channel@([0-8])$": + type: object + description: | + Represents channels of the device and their specific configuration. + + properties: + reg: + description: | + The channel number. 0 is local channel, 1-8 are remote channels. + items: + minimum: 0 + maximum: 8 + + label: + description: | + A descriptive name for this channel, like "ambient" or "psu". + + ti,n-factor: + description: | + The value (two's complement) to be programmed in the channel specific N correction register. + For remote channels only. + $ref: /schemas/types.yaml#/definitions/int32 + items: + minimum: -128 + maximum: 127 + + required: + - reg + + additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@4b { + compatible = "ti,tmp464"; + reg = <0x4b>; + }; + }; + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@4b { + compatible = "ti,tmp464"; + reg = <0x4b>; + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0x0>; + label = "local"; + }; + + channel@1 { + reg = <0x1>; + ti,n-factor = <(-10)>; + label = "external"; + }; + + channel@2 { + reg = <0x2>; + ti,n-factor = <0x10>; + label = "somelabel"; + }; + + channel@3 { + reg = <0x3>; + status = "disabled"; + }; + }; + }; -- cgit From 007e433cf0373334a2bef1b0c9831647184906ba Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Tue, 22 Feb 2022 14:36:10 -0800 Subject: hwmon: Add driver for Texas Instruments TMP464 and TMP468 Add support for Texas Instruments TMP464 and TMP468 temperature sensor ICs. TI's TMP464 is an I2C temperature sensor chip. This chip is similar to TI's TMP421 chip, but with 16bit-wide registers (instead of 8bit-wide registers). The chip has one local sensor and four remote sensors. TMP468 is similar to TMP464 but has one local and eight remote sensors. Originally-from: Agathe Porte Cc: Agathe Porte Cc: Krzysztof Adamski Tested-by: Agathe Porte Link: https://lore.kernel.org/r/20220222223610.23098-2-linux@roeck-us.net Signed-off-by: Guenter Roeck --- Documentation/hwmon/index.rst | 1 + Documentation/hwmon/tmp464.rst | 73 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 74 insertions(+) create mode 100644 Documentation/hwmon/tmp464.rst (limited to 'Documentation') diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index 075d1defcd20..9d2787a12a69 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -195,6 +195,7 @@ Hardware Monitoring Kernel Drivers tmp108 tmp401 tmp421 + tmp464 tmp513 tps23861 tps40422 diff --git a/Documentation/hwmon/tmp464.rst b/Documentation/hwmon/tmp464.rst new file mode 100644 index 000000000000..7596e7623d06 --- /dev/null +++ b/Documentation/hwmon/tmp464.rst @@ -0,0 +1,73 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver tmp464 +==================== + +Supported chips: + + * Texas Instruments TMP464 + + Prefix: 'tmp464' + + Addresses scanned: I2C 0x48, 0x49, 0x4a and 0x4b + + Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp464.html + + * Texas Instruments TMP468 + + Prefix: 'tmp468' + + Addresses scanned: I2C 0x48, 0x49, 0x4a and 0x4b + + Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp468.html + +Authors: + + Agathe Porte + Guenter Roeck + +Description +----------- + +This driver implements support for Texas Instruments TMP464 and TMP468 +temperature sensor chips. TMP464 provides one local and four remote +sensors. TMP468 provides one local and eight remote sensors. +Temperature is measured in degrees Celsius. The chips are wired over +I2C/SMBus and specified over a temperature range of -40 to +125 degrees +Celsius. Resolution for both the local and remote channels is 0.0625 +degree C. + +The chips support only temperature measurements. The driver exports +temperature values, limits, and alarms via the following sysfs files: + +**temp[1-9]_input** + +**temp[1-9]_max** + +**temp[1-9]_max_hyst** + +**temp[1-9]_max_alarm** + +**temp[1-9]_crit** + +**temp[1-9]_crit_alarm** + +**temp[1-9]_crit_hyst** + +**temp[2-9]_offset** + +**temp[2-9]_fault** + +Each sensor can be individually disabled via Devicetree or from sysfs +via: + +**temp[1-9]_enable** + +If labels were specified in Devicetree, additional sysfs files will +be present: + +**temp[1-9]_label** + +The update interval is configurable with the following sysfs attribute. + +**update_interval** -- cgit From b625fe694626992c1d640b37c691cfcfc58d6006 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Tue, 1 Mar 2022 00:39:30 +0200 Subject: ACPI: docs: enumeration: Discourage to use custom _DSM methods Since we have _DSD established and specified (ACPI v5.1+) there is no need to use custom _DSM methods. Rewrite documentation to use _DSD. Fixes: f60e7074902a ("misc: at25: Make use of device property API") Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki --- Documentation/firmware-guide/acpi/enumeration.rst | 48 ++++++++++------------- 1 file changed, 21 insertions(+), 27 deletions(-) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index 74b830b2fd59..cda41e4255eb 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -188,43 +188,37 @@ to at25 SPI eeprom driver (this is meant for the above ACPI snippet):: }; Note that this driver actually needs more information like page size of the -eeprom etc. but at the time writing this there is no standard way of -passing those. One idea is to return this in _DSM method like:: +eeprom, etc. This information can be passed via _DSD method like:: Device (EEP0) { ... - Method (_DSM, 4, NotSerialized) + Name (_DSD, Package () { - Store (Package (6) + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { - "byte-len", 1024, - "addr-mode", 2, - "page-size, 32 - }, Local0) - - // Check UUIDs etc. - - Return (Local0) - } - -Then the at25 SPI driver can get this configuration by calling _DSM on its -ACPI handle like:: - - struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL }; - struct acpi_object_list input; - acpi_status status; + Package () { "size", 1024 }, + Package () { "pagesize", 32 }, + Package () { "address-width", 16 }, + } + }) + } - /* Fill in the input buffer */ +Then the at25 SPI driver can get this configuration by calling device property +APIs during ->probe() phase like:: - status = acpi_evaluate_object(ACPI_HANDLE(&spi->dev), "_DSM", - &input, &output); - if (ACPI_FAILURE(status)) - /* Handle the error */ + err = device_property_read_u32(dev, "size", &size); + if (err) + ...error handling... - /* Extract the data here */ + err = device_property_read_u32(dev, "pagesize", &page_size); + if (err) + ...error handling... - kfree(output.pointer); + err = device_property_read_u32(dev, "address-width", &addr_width); + if (err) + ...error handling... I2C serial bus support ====================== -- cgit From d72f06cee0d5cad0056967f0edc2c23b984238ba Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Tue, 1 Mar 2022 00:39:31 +0200 Subject: ACPI: docs: enumeration: Update UART serial bus resource documentation In some cases UART serial bus resource may be represented by struct serdev_device. Fixes: 53c7626356c7 ("serdev: Add ACPI support") Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki --- Documentation/firmware-guide/acpi/enumeration.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index cda41e4255eb..799ca240e612 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -19,16 +19,17 @@ possible we decided to do following: platform devices. - Devices behind real busses where there is a connector resource - are represented as struct spi_device or struct i2c_device - (standard UARTs are not busses so there is no struct uart_device). + are represented as struct spi_device or struct i2c_device. Note + that standard UARTs are not busses so there is no struct uart_device, + although some of them may be represented by sturct serdev_device. As both ACPI and Device Tree represent a tree of devices (and their resources) this implementation follows the Device Tree way as much as possible. -The ACPI implementation enumerates devices behind busses (platform, SPI and -I2C), creates the physical devices and binds them to their ACPI handle in -the ACPI namespace. +The ACPI implementation enumerates devices behind busses (platform, SPI, +I2C, and in some cases UART), creates the physical devices and binds them +to their ACPI handle in the ACPI namespace. This means that when ACPI_HANDLE(dev) returns non-NULL the device was enumerated from ACPI namespace. This handle can be used to extract other -- cgit From e8a62f363661d824495737427d59ba3fce91ae34 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Tue, 1 Mar 2022 00:39:32 +0200 Subject: ACPI: docs: enumeration: Remove redundant .owner assignment The owner member of the struct i2c_driver is assigned by a corresponding macro. No need to assign it explicitly. Fixes: 59c3987805a9 ("ACPI: add documentation about ACPI 5 enumeration") Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki --- Documentation/firmware-guide/acpi/enumeration.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index 799ca240e612..900d193ffa5e 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -243,7 +243,6 @@ input driver:: static struct i2c_driver mpu3050_i2c_driver = { .driver = { .name = "mpu3050", - .owner = THIS_MODULE, .pm = &mpu3050_pm, .of_match_table = mpu3050_of_match, .acpi_match_table = ACPI_PTR(mpu3050_acpi_match), @@ -252,6 +251,7 @@ input driver:: .remove = mpu3050_remove, .id_table = mpu3050_ids, }; + module_i2c_driver(mpu3050_i2c_driver); Reference to PWM device ======================= -- cgit From e92e19747c1e0eb805c7c72fa991da7a292b43a6 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Tue, 1 Mar 2022 00:39:33 +0200 Subject: ACPI: docs: enumeration: Amend PWM enumeration ASL example Drop blank line and add a closing curly brace to make ASL example closer to the reality. Fixes: ef3d13b86763 ("docs: firmware-guide: ACPI: Add a PWM example") Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki --- Documentation/firmware-guide/acpi/enumeration.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index 900d193ffa5e..7a5095901153 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -277,9 +277,9 @@ introduced, i.e.:: } } } - }) ... + } In the above example the PWM-based LED driver references to the PWM channel 0 of \_SB.PCI0.PWM device with initial period setting equal to 600 ms (note that -- cgit From 6bf87c4de91ca31f829587f69cd8ea13576a483d Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Tue, 1 Mar 2022 00:39:34 +0200 Subject: ACPI: docs: enumeration: Drop ugly ifdeffery from the examples The ifdeffery around ACPI ID tables are ugly and in some cases even less valuable than plain definitions. Drop them for good to avoid spreading rather bad pattern. Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki --- Documentation/firmware-guide/acpi/enumeration.rst | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index 7a5095901153..caa9a5e508b2 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -47,18 +47,16 @@ some minor changes. Adding ACPI support for an existing driver should be pretty straightforward. Here is the simplest example:: - #ifdef CONFIG_ACPI static const struct acpi_device_id mydrv_acpi_match[] = { /* ACPI IDs here */ { } }; MODULE_DEVICE_TABLE(acpi, mydrv_acpi_match); - #endif static struct platform_driver my_driver = { ... .driver = { - .acpi_match_table = ACPI_PTR(mydrv_acpi_match), + .acpi_match_table = mydrv_acpi_match, }, }; @@ -173,18 +171,16 @@ The SPI device drivers only need to add ACPI IDs in a similar way than with the platform device drivers. Below is an example where we add ACPI support to at25 SPI eeprom driver (this is meant for the above ACPI snippet):: - #ifdef CONFIG_ACPI static const struct acpi_device_id at25_acpi_match[] = { { "AT25", 0 }, { }, }; MODULE_DEVICE_TABLE(acpi, at25_acpi_match); - #endif static struct spi_driver at25_driver = { .driver = { ... - .acpi_match_table = ACPI_PTR(at25_acpi_match), + .acpi_match_table = at25_acpi_match, }, }; @@ -232,20 +228,18 @@ registered. Below is an example of how to add ACPI support to the existing mpu3050 input driver:: - #ifdef CONFIG_ACPI static const struct acpi_device_id mpu3050_acpi_match[] = { { "MPU3050", 0 }, { }, }; MODULE_DEVICE_TABLE(acpi, mpu3050_acpi_match); - #endif static struct i2c_driver mpu3050_i2c_driver = { .driver = { .name = "mpu3050", .pm = &mpu3050_pm, .of_match_table = mpu3050_of_match, - .acpi_match_table = ACPI_PTR(mpu3050_acpi_match), + .acpi_match_table = mpu3050_acpi_match, }, .probe = mpu3050_probe, .remove = mpu3050_remove, -- cgit From a889e50ea088a525338e7fb9adc887d407e4a5c4 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Tue, 1 Mar 2022 00:39:36 +0200 Subject: ACPI: docs: enumeration: Drop comma for terminator entry Drop comma for terminator entry to avoid copy'n'paste of this pattern. Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki --- Documentation/firmware-guide/acpi/enumeration.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index caa9a5e508b2..621ae95bc472 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -173,7 +173,7 @@ to at25 SPI eeprom driver (this is meant for the above ACPI snippet):: static const struct acpi_device_id at25_acpi_match[] = { { "AT25", 0 }, - { }, + { } }; MODULE_DEVICE_TABLE(acpi, at25_acpi_match); @@ -230,7 +230,7 @@ input driver:: static const struct acpi_device_id mpu3050_acpi_match[] = { { "MPU3050", 0 }, - { }, + { } }; MODULE_DEVICE_TABLE(acpi, mpu3050_acpi_match); -- cgit From 01399a994bb477bb7d0a32665ce77407da849faf Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Tue, 1 Mar 2022 00:39:35 +0200 Subject: ACPI: docs: enumeration: Unify Package () for properties Unify Package () representation for properties: - make them one line where it's possible - add spaces between parentheses and curly braces - drop the explicit size of package Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki --- Documentation/firmware-guide/acpi/enumeration.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index 621ae95bc472..a946643244f7 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -154,7 +154,7 @@ Here is what the ACPI namespace for a SPI slave might look like:: Device (EEP0) { Name (_ADR, 1) - Name (_CID, Package() { + Name (_CID, Package () { "ATML0025", "AT25", }) @@ -326,8 +326,8 @@ For example:: ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { - Package () {"power-gpios", Package() {^DEV, 0, 0, 0 }}, - Package () {"irq-gpios", Package() {^DEV, 1, 0, 0 }}, + Package () { "power-gpios", Package () { ^DEV, 0, 0, 0 } }, + Package () { "irq-gpios", Package () { ^DEV, 1, 0, 0 } }, } }) ... @@ -449,10 +449,10 @@ namespace link:: Device (TMP0) { Name (_HID, "PRP0001") - Name (_DSD, Package() { + Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { - Package (2) { "compatible", "ti,tmp75" }, + Package () { "compatible", "ti,tmp75" }, } }) Method (_CRS, 0, Serialized) -- cgit From 309d955985ee9e94697c197b7b489555f1ac7259 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Mon, 28 Feb 2022 14:10:05 -0600 Subject: dt-bindings: kbuild: Support partial matches with DT_SCHEMA_FILES DT_SCHEMA_FILES is currently restricted to a list of exact files with the full source tree path (i.e. Documentation/devicetree/bindings/...). Loosen this requirement and let DT_SCHEMA_FILES be a partial match. With this, checking all schema files in a directory is possible: $ make DT_SCHEMA_FILES=/gpio/ dt_binding_check Or all schema files with 'qcom' in the path or filename: $ make DT_SCHEMA_FILES=qcom dt_binding_check Cc: Masahiro Yamada Signed-off-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220228201006.1484903-1-robh@kernel.org --- Documentation/devicetree/bindings/Makefile | 15 +++++---------- Documentation/devicetree/bindings/writing-schema.rst | 9 +++++---- 2 files changed, 10 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index 41c555181b6f..5138d10e0601 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -31,11 +31,8 @@ find_all_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \ -name 'processed-schema*' ! \ -name '*.example.dt.yaml' \) -ifeq ($(DT_SCHEMA_FILES),) -find_cmd = $(find_all_cmd) -else -find_cmd = echo $(addprefix $(srctree)/, $(DT_SCHEMA_FILES)) -endif +find_cmd = $(find_all_cmd) | grep -F "$(DT_SCHEMA_FILES)" +CHK_DT_DOCS := $(shell $(find_cmd)) quiet_cmd_yamllint = LINT $(src) cmd_yamllint = ($(find_cmd) | \ @@ -83,22 +80,20 @@ ifeq ($(DT_SCHEMA_FILES),) $(obj)/processed-schema.json: $(obj)/processed-schema-examples.json FORCE $(call if_changed,copy) -DT_SCHEMA_FILES = $(DT_DOCS) - else # If DT_SCHEMA_FILES is specified, use it for processed-schema.json $(obj)/processed-schema.json: DT_MK_SCHEMA_FLAGS := -u -$(obj)/processed-schema.json: $(DT_SCHEMA_FILES) check_dtschema_version FORCE +$(obj)/processed-schema.json: $(CHK_DT_DOCS) check_dtschema_version FORCE $(call if_changed,mk_schema) endif always-$(CHECK_DT_BINDING) += processed-schema-examples.json always-$(CHECK_DTBS) += processed-schema.json -always-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dts, $(DT_SCHEMA_FILES)) -always-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dt.yaml, $(DT_SCHEMA_FILES)) +always-$(CHECK_DT_BINDING) += $(patsubst $(srctree)/$(src)/%.yaml,%.example.dts, $(CHK_DT_DOCS)) +always-$(CHECK_DT_BINDING) += $(patsubst $(srctree)/$(src)/%.yaml,%.example.dt.yaml, $(CHK_DT_DOCS)) # Hack: avoid 'Argument list too long' error for 'make clean'. Remove most of # build artifacts here before they are processed by scripts/Makefile.clean diff --git a/Documentation/devicetree/bindings/writing-schema.rst b/Documentation/devicetree/bindings/writing-schema.rst index 4004dd9209a6..3b00fe981494 100644 --- a/Documentation/devicetree/bindings/writing-schema.rst +++ b/Documentation/devicetree/bindings/writing-schema.rst @@ -157,13 +157,14 @@ It is possible to run both in a single command:: make dt_binding_check dtbs_check -It is also possible to run checks with a single schema file by setting the -``DT_SCHEMA_FILES`` variable to a specific schema file. +It is also possible to run checks with a subset of matching schema files by +setting the ``DT_SCHEMA_FILES`` variable to a specific schema file or pattern. :: - make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/trivial-devices.yaml - make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/trivial-devices.yaml + make dt_binding_check DT_SCHEMA_FILES=trivial-devices.yaml + make dt_binding_check DT_SCHEMA_FILES=/gpio/ + make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml json-schema Resources -- cgit From f0fb3328100e2be01b2b71e5e48e9800b13ed5a2 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Thu, 17 Feb 2022 16:44:06 +0100 Subject: media: dt-bindings: Add Intersil ISL79987 DT bindings Add bindings for the Intersil ISL79987 analog to MIPI CSI-2 decoder. Signed-off-by: Marek Vasut Cc: Sakari Ailus Cc: Mauro Carvalho Chehab Cc: Rob Herring Cc: devicetree@vger.kernel.org To: linux-media@vger.kernel.org Signed-off-by: Michael Tretter Reviewed-by: Rob Herring Acked-by: Hans Verkuil Signed-off-by: Sakari Ailus --- .../bindings/media/i2c/isil,isl79987.yaml | 113 +++++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/isil,isl79987.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/isil,isl79987.yaml b/Documentation/devicetree/bindings/media/i2c/isil,isl79987.yaml new file mode 100644 index 000000000000..034a6e3466af --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/isil,isl79987.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/isil,isl79987.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intersil ISL79987 Analog to MIPI CSI-2 decoder + +maintainers: + - Michael Tretter + - Marek Vasut + +description: + The Intersil ISL79987 is an analog to MIPI CSI-2 decoder which is capable of + receiving up to four analog stream and multiplexing them into up to four MIPI + CSI-2 virtual channels, using one MIPI clock lane and 1/2 data lanes. + +properties: + compatible: + enum: + - isil,isl79987 + + reg: + maxItems: 1 + + reset-gpios: + maxItems: 1 + description: + A GPIO spec for the RSTB pin (active high) + + powerdown-gpios: + maxItems: 1 + description: + A GPIO spec for the Power Down pin (active high) + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: Output port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 2 + + required: + - data-lanes + + patternProperties: + "^port@[1-4]$": + $ref: /schemas/graph.yaml#/properties/port + description: Input ports + + required: + - port@0 + +additionalProperties: false + +required: + - compatible + - reg + - ports + +examples: + - | + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + isl7998x_mipi@44 { + compatible = "isil,isl79987"; + reg = <0x44>; + powerdown-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio3 28 GPIO_ACTIVE_HIGH>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + isl79987_out: endpoint { + remote-endpoint = <&mipi_csi2_in>; + data-lanes = <1 2>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&camera_0>; + }; + }; + + port@2 { + reg = <2>; + endpoint { + remote-endpoint = <&camera_1>; + }; + }; + }; + }; + }; -- cgit From f9f52c3474282a5485b28cf188b47d6e2efee185 Mon Sep 17 00:00:00 2001 From: Dust Li Date: Thu, 3 Mar 2022 19:35:27 +0800 Subject: net/smc: fix document build WARNING from smc-sysctl.rst Stephen reported the following warning messages from smc-sysctl.rst Documentation/networking/smc-sysctl.rst:3: WARNING: Title overline too short. Documentation/networking/smc-sysctl.rst: WARNING: document isn't included in any toctree Fix the title overline and add smc-sysctl entry into Documentation/networking/index.rst Fixes: 12bbb0d163a9 ("net/smc: add sysctl for autocorking") Reported-by: Stephen Rothwell Signed-off-by: Dust Li Link: https://lore.kernel.org/r/20220303113527.62047-1-dust.li@linux.alibaba.com Signed-off-by: Jakub Kicinski --- Documentation/networking/index.rst | 1 + Documentation/networking/smc-sysctl.rst | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index 58bc8cd367c6..ce017136ab05 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -96,6 +96,7 @@ Contents: sctp secid seg6-sysctl + smc-sysctl statistics strparser switchdev diff --git a/Documentation/networking/smc-sysctl.rst b/Documentation/networking/smc-sysctl.rst index c53f8c61c9e4..0987fd1bc220 100644 --- a/Documentation/networking/smc-sysctl.rst +++ b/Documentation/networking/smc-sysctl.rst @@ -1,11 +1,11 @@ .. SPDX-License-Identifier: GPL-2.0 -========= +========== SMC Sysctl -========= +========== /proc/sys/net/smc/* Variables -============================== +============================= autocorking_size - INTEGER Setting SMC auto corking size: -- cgit From 69d6941949ea8a113ffc89410b0cb79bc7b35a0b Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Tue, 1 Mar 2022 12:35:26 +0000 Subject: dt-bindings: memory: renesas,rpc-if: Document RZ/V2L SoC Document RZ/V2L RPC-IF bindings. RZ/V2L RPC-IF is identical to one found on the RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,rzg2l-rpc-if" will be used as a fallback. While at it, drop the comment "# RZ/G2L family" for "renesas,rzg2l-rpc-if" compatible string as this will avoid changing the line for every new SoC addition. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20220301123527.15950-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/renesas,rpc-if.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml index 294f1036420d..9a6dbf54b540 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml @@ -40,7 +40,8 @@ properties: - items: - enum: - renesas,r9a07g044-rpc-if # RZ/G2{L,LC} - - const: renesas,rzg2l-rpc-if # RZ/G2L family + - renesas,r9a07g054-rpc-if # RZ/V2L + - const: renesas,rzg2l-rpc-if reg: items: -- cgit From 21f95a88eab49eebc70f25f17567aacb9cdafc01 Mon Sep 17 00:00:00 2001 From: Sebastian Andrzej Siewior Date: Thu, 3 Mar 2022 18:14:57 +0100 Subject: docs: networking: Use netif_rx(). Since commit baebdf48c3600 ("net: dev: Makes sure netif_rx() can be invoked in any context.") the function netif_rx() can be used in preemptible/thread context as well as in interrupt context. Use netif_rx(). Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: David S. Miller --- Documentation/networking/timestamping.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/timestamping.rst b/Documentation/networking/timestamping.rst index f5809206eb93..be4eb1242057 100644 --- a/Documentation/networking/timestamping.rst +++ b/Documentation/networking/timestamping.rst @@ -668,7 +668,7 @@ timestamping: (through another RX timestamping FIFO). Deferral on RX is typically necessary when retrieving the timestamp needs a sleepable context. In that case, it is the responsibility of the DSA driver to call - ``netif_rx_ni()`` on the freshly timestamped skb. + ``netif_rx()`` on the freshly timestamped skb. 3.2.2 Ethernet PHYs ^^^^^^^^^^^^^^^^^^^ -- cgit From 2358dd3fd325fc9689652f0c8d4a09475dd31b46 Mon Sep 17 00:00:00 2001 From: Divya Koppera Date: Fri, 4 Mar 2022 15:04:17 +0530 Subject: dt-bindings: net: micrel: Configure latency values and timestamping check for LAN8814 phy Supports configuring latency values and also adds check for phy timestamping feature. Signed-off-by: Divya Koppera Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/micrel.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt index 8d157f0295a5..c5ab62c39133 100644 --- a/Documentation/devicetree/bindings/net/micrel.txt +++ b/Documentation/devicetree/bindings/net/micrel.txt @@ -45,3 +45,20 @@ Optional properties: In fiber mode, auto-negotiation is disabled and the PHY can only work in 100base-fx (full and half duplex) modes. + + - lan8814,ignore-ts: If present the PHY will not support timestamping. + + This option acts as check whether Timestamping is supported by + hardware or not. LAN8814 phy support hardware tmestamping. + + - lan8814,latency_rx_10: Configures Latency value of phy in ingress at 10 Mbps. + + - lan8814,latency_tx_10: Configures Latency value of phy in egress at 10 Mbps. + + - lan8814,latency_rx_100: Configures Latency value of phy in ingress at 100 Mbps. + + - lan8814,latency_tx_100: Configures Latency value of phy in egress at 100 Mbps. + + - lan8814,latency_rx_1000: Configures Latency value of phy in ingress at 1000 Mbps. + + - lan8814,latency_tx_1000: Configures Latency value of phy in egress at 1000 Mbps. -- cgit From b066ad26ebf2cabcd961eab33910f19a0e79593b Mon Sep 17 00:00:00 2001 From: Horatiu Vultur Date: Fri, 4 Mar 2022 12:08:53 +0100 Subject: dt-bindings: net: sparx5: Extend with the ptp interrupt Extend dt-bindings for sparx5 with ptp interrupt. This is generated when doing 2-step timestamping and the timestamp can be read from the FIFO. Signed-off-by: Horatiu Vultur Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml index 347b912a46bb..6c86d3d85e99 100644 --- a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml +++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml @@ -53,12 +53,14 @@ properties: items: - description: register based extraction - description: frame dma based extraction + - description: ptp interrupt interrupt-names: minItems: 1 items: - const: xtr - const: fdma + - const: ptp resets: items: -- cgit From 8cf0e06a72306d30e1a01b2b68ab362036757d32 Mon Sep 17 00:00:00 2001 From: Abel Vesa Date: Tue, 22 Feb 2022 10:21:40 +0200 Subject: dt-bindings: fsl: scu: add imx8dxl scu clock support Add imx8dxl scu clock support. Signed-off-by: Abel Vesa Acked-by: Rob Herring Acked-by: Stephen Boyd Link: https://lore.kernel.org/r/20220222082140.2073629-1-abel.vesa@nxp.com --- Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index fd0061712443..a87ec15e28d2 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -86,6 +86,7 @@ This binding uses the common clock binding[1]. Required properties: - compatible: Should be one of: + "fsl,imx8dxl-clk" "fsl,imx8qm-clk" "fsl,imx8qxp-clk" followed by "fsl,scu-clk" -- cgit From 245830990da69abc913b80af0b43c5cbeb902c5d Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Mon, 28 Feb 2022 10:09:04 +0800 Subject: dt-bindings: clock: Add imx93 clock support Add the clock dt-binding file for i.MX93. Reviewed-by: Abel Vesa Reviewed-by: Rob Herring Reviewed-by: Stephen Boyd Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20220228020908.2810346-2-peng.fan@oss.nxp.com Signed-off-by: Abel Vesa --- .../devicetree/bindings/clock/imx93-clock.yaml | 62 ++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/imx93-clock.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/imx93-clock.yaml b/Documentation/devicetree/bindings/clock/imx93-clock.yaml new file mode 100644 index 000000000000..21a06194e4a3 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx93-clock.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx93-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX93 Clock Control Module Binding + +maintainers: + - Peng Fan + +description: | + i.MX93 clock control module is an integrated clock controller, which + includes clock generator, clock gate and supplies to all modules. + +properties: + compatible: + enum: + - fsl,imx93-ccm + + reg: + maxItems: 1 + + clocks: + description: + specify the external clocks used by the CCM module. + items: + - description: 32k osc + - description: 24m osc + - description: ext1 clock input + + clock-names: + description: + specify the external clocks names used by the CCM module. + items: + - const: osc_32k + - const: osc_24m + - const: clk_ext1 + + '#clock-cells': + const: 1 + description: + See include/dt-bindings/clock/imx93-clock.h for the full list of + i.MX93 clock IDs. + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + # Clock Control Module node: + - | + clock-controller@44450000 { + compatible = "fsl,imx93-ccm"; + reg = <0x44450000 0x10000>; + #clock-cells = <1>; + }; + +... -- cgit From d6a3be863dcf8c51ba2d18d8fd47a1fadb1336aa Mon Sep 17 00:00:00 2001 From: Qianggui Song Date: Fri, 25 Feb 2022 13:52:03 +0800 Subject: dt-bindings: interrupt-controller: New binding for Meson-S4 SoCs Update dt-binding document for GPIO interrupt controller of Meson-S4 SoCs Acked-by: Rob Herring Signed-off-by: Qianggui Song Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220225055207.1048-2-qianggui.song@amlogic.com --- .../devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt index 23b18b92c558..bde63f8f090e 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt @@ -18,6 +18,7 @@ Required properties: "amlogic,meson-g12a-gpio-intc" for G12A SoCs (S905D2, S905X2, S905Y2) "amlogic,meson-sm1-gpio-intc" for SM1 SoCs (S905D3, S905X3, S905Y3) "amlogic,meson-a1-gpio-intc" for A1 SoCs (A113L) + "amlogic,meson-s4-gpio-intc" for S4 SoCs (S802X2, S905Y4, S805X2G, S905W2) - reg : Specifies base physical address and size of the registers. - interrupt-controller : Identifies the node as an interrupt controller. - #interrupt-cells : Specifies the number of cells needed to encode an -- cgit From 0d2be10b3037c12d68003856b8d6c83d1b80e0c9 Mon Sep 17 00:00:00 2001 From: Andrew Halaney Date: Thu, 24 Feb 2022 15:23:12 -0600 Subject: Documentation/locking/locktypes: Fix PREEMPT_RT _bh() description With PREEMPT_RT the _bh() version of a spinlock leaves preemption enabled, align the doc to say that instead of the opposite. Reported-by: Leah Leshchinsky Signed-off-by: Andrew Halaney Reviewed-by: Boqun Feng Link: https://lore.kernel.org/r/20220224212312.2601153-1-ahalaney@redhat.com Signed-off-by: Jonathan Corbet --- Documentation/locking/locktypes.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/locking/locktypes.rst b/Documentation/locking/locktypes.rst index 4fd7b70fcde1..bfa75ea1b66a 100644 --- a/Documentation/locking/locktypes.rst +++ b/Documentation/locking/locktypes.rst @@ -247,7 +247,7 @@ based on rt_mutex which changes the semantics: Non-PREEMPT_RT kernels disable preemption to get this effect. PREEMPT_RT kernels use a per-CPU lock for serialization which keeps - preemption disabled. The lock disables softirq handlers and also + preemption enabled. The lock disables softirq handlers and also prevents reentrancy due to task preemption. PREEMPT_RT kernels preserve all other spinlock_t semantics: -- cgit From 0d6356d6cdd0afeb546f4e8ca653748a8ec3ba26 Mon Sep 17 00:00:00 2001 From: Wan Jiabing Date: Mon, 28 Feb 2022 11:16:56 +0800 Subject: docs: fix 'make htmldocs' warning in perf Fix following 'make htmldocs' warnings: ./Documentation/admin-guide/perf/hisi-pcie-pmu.rst: WARNING: document isn't included in any toctree Fixes: c8602008e247 ("docs: perf: Add description for HiSilicon PCIe PMU driver") Signed-off-by: Wan Jiabing Reviewed-by: John Garry Link: https://lore.kernel.org/r/20220228031700.1669086-1-wanjiabing@vivo.com Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/perf/index.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/perf/index.rst b/Documentation/admin-guide/perf/index.rst index 5a8f2529a033..69b23f087c05 100644 --- a/Documentation/admin-guide/perf/index.rst +++ b/Documentation/admin-guide/perf/index.rst @@ -8,6 +8,7 @@ Performance monitor support :maxdepth: 1 hisi-pmu + hisi-pcie-pmu imx-ddr qcom_l2_pmu qcom_l3_pmu -- cgit From 8dc355748a7cb4b374d1296bdd68f66c18aced9e Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Tue, 1 Mar 2022 13:42:53 +0100 Subject: dt-bindings: power: supply: ab8500_fg: Add line impedance To improve the inner resistance measurement of the battery we need to account for the line impedance of the connector to the battery. Cc: devicetree@vger.kernel.org Signed-off-by: Linus Walleij Acked-by: Rob Herring Signed-off-by: Sebastian Reichel --- .../devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml index 54ac42a9d354..2ce408a7c0ae 100644 --- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml +++ b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml @@ -25,6 +25,11 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle deprecated: true + line-impedance-micro-ohms: + description: The line impedance between the battery and the + AB8500 inputs, to compensate for this when determining internal + resistance. + interrupts: maxItems: 5 -- cgit From 14ea3e701c9599374bab4dc78002bd4a2757be23 Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Sun, 13 Feb 2022 22:22:57 -0600 Subject: dt-bindings: vendor-prefixes: Add Injoinic Add prefix for Injoinic Technology Corp. (http://www.injoinic.com/) Acked-by: Rob Herring Signed-off-by: Samuel Holland Signed-off-by: Sebastian Reichel --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 294093d45a23..3a1a7b2fbe52 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -561,6 +561,8 @@ patternProperties: description: InfoVision Optoelectronics Kunshan Co. Ltd. "^ingenic,.*": description: Ingenic Semiconductor + "^injoinic,.*": + description: Injoinic Technology Corp. "^innolux,.*": description: Innolux Corporation "^inside-secure,.*": -- cgit From 78eb753ea1d76356245ef8c008be70fbbac3f19d Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Sun, 13 Feb 2022 22:22:58 -0600 Subject: dt-bindings: trivial-devices: Add Injoinic power bank ICs Some Injoinic power bank ICs feature an I2C interface which allows monitoring and controlling the battery charger and boost converter. Acked-by: Rob Herring Signed-off-by: Samuel Holland Signed-off-by: Sebastian Reichel --- Documentation/devicetree/bindings/trivial-devices.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 091792ba993e..a045d627a297 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -141,6 +141,14 @@ properties: - infineon,xdpe12254 # Infineon Multi-phase Digital VR Controller xdpe12284 - infineon,xdpe12284 + # Injoinic IP5108 2.0A Power Bank IC with I2C + - injoinic,ip5108 + # Injoinic IP5109 2.1A Power Bank IC with I2C + - injoinic,ip5109 + # Injoinic IP5207 1.2A Power Bank IC with I2C + - injoinic,ip5207 + # Injoinic IP5209 2.4A Power Bank IC with I2C + - injoinic,ip5209 # Inspur Power System power supply unit version 1 - inspur,ipsps1 # Intersil ISL29028 Ambient Light and Proximity Sensor -- cgit From ea87f1eb4fd81375a3abf564f6f2999561985831 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Thu, 3 Mar 2022 10:57:09 -0600 Subject: dt-bindings: arm: Allow 32-bit 'cpu-release-addr' values While the DT Spec says 'cpu-release-addr' is always 64-bit, some 32-bit Arm DTs used a 32-bit value. We're now stuck with those cases, so add uint32 as a valid type. Signed-off-by: Rob Herring Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220303165710.1859862-1-robh@kernel.org --- Documentation/devicetree/bindings/arm/cpus.yaml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index 916a5aebefff..cddc3f63c9fd 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -232,14 +232,14 @@ properties: - ti,am4372 cpu-release-addr: - $ref: '/schemas/types.yaml#/definitions/uint64' - + oneOf: + - $ref: '/schemas/types.yaml#/definitions/uint32' + - $ref: '/schemas/types.yaml#/definitions/uint64' description: + The DT specification defines this as 64-bit always, but some 32-bit Arm + systems have used a 32-bit value which must be supported. Required for systems that have an "enable-method" property value of "spin-table". - On ARM v8 64-bit systems must be a two cell - property identifying a 64-bit zero-initialised - memory location. cpu-idle-states: $ref: '/schemas/types.yaml#/definitions/phandle-array' -- cgit From 617c3cc3aafd826c549b83f055f1e710adbdf99a Mon Sep 17 00:00:00 2001 From: Luiz Angelo Daros de Luca Date: Wed, 2 Mar 2022 22:52:33 -0300 Subject: dt-bindings: net: dsa: add rtl8_4 and rtl8_4t tag formats Realtek rtl8365mb DSA driver can use these two tag formats. Cc: devicetree@vger.kernel.org Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/dsa/dsa-port.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml index 702df848a71d..e60867c7c571 100644 --- a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml +++ b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml @@ -51,6 +51,8 @@ properties: - edsa - ocelot - ocelot-8021q + - rtl8_4 + - rtl8_4t - seville phy-handle: true -- cgit From 40b358f6156ac516e33e5252a8769737054da24e Mon Sep 17 00:00:00 2001 From: Shunzhou Jiang Date: Mon, 7 Mar 2022 10:53:56 +0800 Subject: dt-bindings: power: add Amlogic s4 power domains bindings Add the bindings for the Amlogic Secure power domains, controlling the secure power domains. The bindings targets the Amlogic s4, in which the power domains registers are in secure world. Signed-off-by: Shunzhou Jiang Reviewed-by: Martin Blumenstingl Acked-by: Rob Herring Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20220307025357.1368673-2-shunzhou.jiang@amlogic.com --- Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml index 5dae04d2936c..7657721a4e96 100644 --- a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml +++ b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml @@ -12,13 +12,14 @@ maintainers: - Jianxin Pan description: |+ - Secure Power Domains used in Meson A1/C1 SoCs, and should be the child node + Secure Power Domains used in Meson A1/C1/S4 SoCs, and should be the child node of secure-monitor. properties: compatible: enum: - amlogic,meson-a1-pwrc + - amlogic,meson-s4-pwrc "#power-domain-cells": const: 1 -- cgit From f3116f2e52e63d8e5b615040013f00c535126fc1 Mon Sep 17 00:00:00 2001 From: Adam Ford Date: Tue, 25 Jan 2022 18:11:22 +0100 Subject: media: dt-bindings: media: nxp, imx8mq-vpu: Split G1 and G2 nodes The G1 and G2 are independent and separate decoder blocks that are enabled by the vpu-blk-ctrl power-domain controller, which now has a proper driver. Because these blocks only share the power-domain, and can be independently fused out, update the bindings to support separate nodes for the G1 and G2 decoders with vpu-blk-ctrl power-domain support. The new DT + old kernel isn't a supported configuration. Signed-off-by: Adam Ford Reviewed-by: Rob Herring Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/nxp,imx8mq-vpu.yaml | 65 +++++++++------------- 1 file changed, 27 insertions(+), 38 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml index 762be3f96ce9..9c28d562112b 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml @@ -15,33 +15,20 @@ description: properties: compatible: - const: nxp,imx8mq-vpu + oneOf: + - const: nxp,imx8mq-vpu + deprecated: true + - const: nxp,imx8mq-vpu-g1 + - const: nxp,imx8mq-vpu-g2 reg: - maxItems: 3 - - reg-names: - items: - - const: g1 - - const: g2 - - const: ctrl + maxItems: 1 interrupts: - maxItems: 2 - - interrupt-names: - items: - - const: g1 - - const: g2 + maxItems: 1 clocks: - maxItems: 3 - - clock-names: - items: - - const: g1 - - const: g2 - - const: bus + maxItems: 1 power-domains: maxItems: 1 @@ -49,31 +36,33 @@ properties: required: - compatible - reg - - reg-names - interrupts - - interrupt-names - clocks - - clock-names additionalProperties: false examples: - | #include + #include + #include + + vpu_g1: video-codec@38300000 { + compatible = "nxp,imx8mq-vpu-g1"; + reg = <0x38300000 0x10000>; + interrupts = ; + clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>; + power-domains = <&vpu_blk_ctrl IMX8MQ_VPUBLK_PD_G1>; + }; + - | + #include + #include #include - vpu: video-codec@38300000 { - compatible = "nxp,imx8mq-vpu"; - reg = <0x38300000 0x10000>, - <0x38310000 0x10000>, - <0x38320000 0x10000>; - reg-names = "g1", "g2", "ctrl"; - interrupts = , - ; - interrupt-names = "g1", "g2"; - clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>, - <&clk IMX8MQ_CLK_VPU_G2_ROOT>, - <&clk IMX8MQ_CLK_VPU_DEC_ROOT>; - clock-names = "g1", "g2", "bus"; - power-domains = <&pgc_vpu>; + vpu_g2: video-codec@38300000 { + compatible = "nxp,imx8mq-vpu-g2"; + reg = <0x38310000 0x10000>; + interrupts = ; + clocks = <&clk IMX8MQ_CLK_VPU_G2_ROOT>; + power-domains = <&vpu_blk_ctrl IMX8MQ_VPUBLK_PD_G2>; }; -- cgit From 176f093c60764915b8cba26ce578ff26a9c6c1e3 Mon Sep 17 00:00:00 2001 From: Adam Ford Date: Tue, 25 Jan 2022 18:11:26 +0100 Subject: media: dt-bindings: media: nxp, imx8mq-vpu: Add support for G1 on imx8mm The i.MX8M mini appears to have a similar G1 decoder but the post-processing isn't present, so different compatible flag is required. Since all the other parameters are the same with imx8mq, just add the new compatible flag to nxp,imx8mq-vpu.yaml. Signed-off-by: Adam Ford Reviewed-by: Ezequiel Garcia Acked-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml index 9c28d562112b..7dc13a4b1805 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml @@ -5,7 +5,7 @@ $id: "http://devicetree.org/schemas/media/nxp,imx8mq-vpu.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" -title: Hantro G1/G2 VPU codecs implemented on i.MX8MQ SoCs +title: Hantro G1/G2 VPU codecs implemented on i.MX8M SoCs maintainers: - Philipp Zabel @@ -20,6 +20,7 @@ properties: deprecated: true - const: nxp,imx8mq-vpu-g1 - const: nxp,imx8mq-vpu-g2 + - const: nxp,imx8mm-vpu-g1 reg: maxItems: 1 -- cgit From 849139d46d096bc8022a1a38153e740b464fca46 Mon Sep 17 00:00:00 2001 From: Bryan O'Donoghue Date: Tue, 11 Jan 2022 13:52:05 +0100 Subject: media: dt-bindings: media: camss: Fixup vdda regulator descriptions sdm845 If we review the schematic for RB3 Thundercomm document Turbox-845 we see that the CAMSS CSI PHY has the same basic power-rail layout as UFS, PCIe and USB PHYs. We should therefore have two regulator declarations as is the case for UFS, PCIe and USB. Reviewed-by: Robert Foss Signed-off-by: Bryan O'Donoghue Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/qcom,sdm845-camss.yaml | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml index 9404d6b9db54..f9a003882f84 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml @@ -186,9 +186,13 @@ properties: - const: vfe1 - const: vfe_lite - vdda-supply: + vdda-phy-supply: description: - Definition of the regulator used as analog power supply. + Phandle to a regulator supply to PHY core block. + + vdda-pll-supply: + description: + Phandle to 1.8V regulator supply to PHY refclk pll block. required: - clock-names @@ -200,7 +204,8 @@ required: - power-domains - reg - reg-names - - vdda-supply + - vdda-phy-supply + - vdda-pll-supply additionalProperties: false @@ -344,7 +349,8 @@ examples: "vfe1", "vfe_lite"; - vdda-supply = <®_2v8>; + vdda-phy-supply = <&vreg_l1a_0p875>; + vdda-pll-supply = <&vreg_l26a_1p2>; ports { #address-cells = <1>; -- cgit From 088c0384bc87fe21ccd941765d20c7c31e6a6e90 Mon Sep 17 00:00:00 2001 From: Bryan O'Donoghue Date: Tue, 11 Jan 2022 13:52:06 +0100 Subject: media: dt-bindings: media: camss: Add vdda supply declarations sm8250 Add in missing vdda-phy-supply and vdda-pll-supply declarations. The sm8250 USB, PCIe, UFS, DSI and CSI PHYs use a common set of vdda rails. Define the CSI vdda regulators in the same way the qmp PHY does. Reviewed-by: Robert Foss Signed-off-by: Bryan O'Donoghue Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/qcom,sm8250-camss.yaml | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml index af877d61b607..07a2af12f37d 100644 --- a/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml @@ -265,6 +265,14 @@ properties: - const: vfe_lite0 - const: vfe_lite1 + vdda-phy-supply: + description: + Phandle to a regulator supply to PHY core block. + + vdda-pll-supply: + description: + Phandle to 1.8V regulator supply to PHY refclk pll block. + required: - clock-names - clocks @@ -277,6 +285,8 @@ required: - power-domains - reg - reg-names + - vdda-phy-supply + - vdda-pll-supply additionalProperties: false @@ -316,6 +326,9 @@ examples: "vfe_lite0", "vfe_lite1"; + vdda-phy-supply = <&vreg_l5a_0p88>; + vdda-pll-supply = <&vreg_l9a_1p2>; + interrupts = , , , -- cgit From f63429f483c9611c7a5bd84e6bf6d8f6d7c801d7 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Fri, 21 Jan 2022 01:26:22 +0100 Subject: media: dt-bindings: media: renesas,csi2: Update data-lanes property CSI-2 (CSI4LNK0) on R-Car and RZ/G2 supports 4-lane mode which is already handled by rcar-csi2.c driver. This patch updates the data-lanes property to describe the same. Signed-off-by: Lad Prabhakar Reviewed-by: Jacopo Mondi Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/renesas,csi2.yaml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/renesas,csi2.yaml b/Documentation/devicetree/bindings/media/renesas,csi2.yaml index e6a036721082..b520d6c5c102 100644 --- a/Documentation/devicetree/bindings/media/renesas,csi2.yaml +++ b/Documentation/devicetree/bindings/media/renesas,csi2.yaml @@ -67,7 +67,10 @@ properties: maxItems: 1 data-lanes: - maxItems: 1 + minItems: 1 + maxItems: 4 + items: + maximum: 4 required: - clock-lanes -- cgit From 875fa4c0d85ae5e6c622e1e9f72ce6c21b6134b1 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Tue, 15 Feb 2022 12:20:32 +0100 Subject: media: doc: pixfmt-rgb: Fix V4L2_PIX_FMT_BGR24 format description The V4L2_PIX_FMT_BGR24 format is incorrectly described, with the B and G components swapped. Fix it. Fixes: 2ac9280cb459 ("media: doc: pixfmt-rgb: Make 8 bits per component table more compact") Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/pixfmt-rgb.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst index 48b0f787274c..30f51cd33f99 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst @@ -672,8 +672,8 @@ nomenclature that instead use the order of components as seen in a 24- or - ``V4L2_PIX_FMT_BGR24`` - 'BGR3' - - G\ :sub:`7-0` - B\ :sub:`7-0` + - G\ :sub:`7-0` - R\ :sub:`7-0` - * .. _V4L2-PIX-FMT-RGB24: -- cgit From 96ba61ee5331eb6e2f4c2baeb994b9ceb01d8266 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Sun, 20 Feb 2022 21:46:16 +0100 Subject: media: v4l2-ctrls: Add new V4L2_H264_DECODE_PARAM_FLAG_P/BFRAME flags Add new V4L2_H264_DECODE_PARAM_FLAG_P/BFRAME flags that are needed by NVIDIA Tegra video decoder. Userspace will have to set these flags in accordance to the type of a decoded frame. Reviewed-by: Nicolas Dufresne Signed-off-by: Dmitry Osipenko Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst index cc080c4257d0..f87584ad90ba 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst @@ -616,6 +616,12 @@ Stateless Codec Control ID * - ``V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD`` - 0x00000004 - + * - ``V4L2_H264_DECODE_PARAM_FLAG_PFRAME`` + - 0x00000008 + - + * - ``V4L2_H264_DECODE_PARAM_FLAG_BFRAME`` + - 0x00000010 + - .. raw:: latex -- cgit From 9729cad0278b4fdde172bb7b5da65bd1a0e0fb8b Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 11 Jan 2022 18:48:02 +0100 Subject: dt-bindings: extcon: maxim,max77843: Add MAX77843 bindings Document the bindings for MAX77843 MUIC/extcon driver, based on Exynos5433 TM2 devicetree. These are neither accurate nor finished bindings but at least allow parsing existing DTS files. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220111174805.223732-3-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/extcon/maxim,max77843.yaml | 40 ++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 Documentation/devicetree/bindings/extcon/maxim,max77843.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml b/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml new file mode 100644 index 000000000000..f9ffe3d6f957 --- /dev/null +++ b/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/extcon/maxim,max77843.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77843 MicroUSB and Companion Power Management IC Extcon + +maintainers: + - Chanwoo Choi + - Krzysztof Kozlowski + +description: | + This is a part of device tree bindings for Maxim MAX77843 MicroUSB + Integrated Circuit (MUIC). + + See also Documentation/devicetree/bindings/mfd/maxim,max77843.yaml for + additional information and example. + +properties: + compatible: + const: maxim,max77843-muic + + connector: + $ref: /schemas/connector/usb-connector.yaml# + + ports: + $ref: /schemas/graph.yaml#/properties/port + description: + Any connector to the data bus of this controller should be modelled using + the OF graph bindings specified + properties: + port: + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - connector + +additionalProperties: false -- cgit From 77357c50e4003f38e3e058fa64ae5e84dec414a3 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 11 Jan 2022 18:48:03 +0100 Subject: regulator: dt-bindings: maxim,max77843: Add MAX77843 bindings Document the bindings for MAX77843 regulator driver. The bindings are almost identical to MAX77693 bindings, except the actual names of regulators. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Mark Brown Reviewed-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220111174805.223732-4-krzysztof.kozlowski@canonical.com --- .../bindings/regulator/maxim,max77843.yaml | 65 ++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/maxim,max77843.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77843.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77843.yaml new file mode 100644 index 000000000000..a963025e96c1 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max77843.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max77843.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77843 MicroUSB and Companion Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski + +description: | + This is a part of device tree bindings for Maxim MAX77843 MicroUSB Integrated + Circuit (MUIC). + + See also Documentation/devicetree/bindings/mfd/maxim,max77843.yaml for + additional information and example. + +properties: + compatible: + const: maxim,max77843-regulator + + CHARGER: + type: object + $ref: regulator.yaml# + additionalProperties: false + description: | + Current regulator. + + properties: + regulator-name: true + regulator-always-on: true + regulator-boot-on: true + regulator-min-microamp: + minimum: 100000 + regulator-max-microamp: + maximum: 3150000 + + required: + - regulator-name + +patternProperties: + "^SAFEOUT[12]$": + type: object + $ref: regulator.yaml# + additionalProperties: false + description: | + Safeout LDO regulator. + + properties: + regulator-name: true + regulator-always-on: true + regulator-boot-on: true + regulator-min-microvolt: + minimum: 3300000 + regulator-max-microvolt: + maximum: 4950000 + + required: + - regulator-name + +required: + - compatible + +additionalProperties: false -- cgit From 4fddb6211da1749a5fb683a33d7d4890d1290b1b Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 11 Jan 2022 18:48:04 +0100 Subject: dt-bindings: mfd: maxim,max77843: Add MAX77843 bindings Document the bindings for MAX77843 MFD driver, based on Exynos5433 TM2 devicetree. These are neither accurate nor finished bindings but at least allow parsing existing DTS files. The example DTS was copied from existing DTS (exynos5433-tm2-common.dtsi), so keep the license as GPL-2.0-only. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220111174805.223732-5-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/mfd/maxim,max77843.yaml | 144 +++++++++++++++++++++ 1 file changed, 144 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/maxim,max77843.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77843.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77843.yaml new file mode 100644 index 000000000000..61a0f9dcb983 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/maxim,max77843.yaml @@ -0,0 +1,144 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/maxim,max77843.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77843 MicroUSB and Companion Power Management IC + +maintainers: + - Krzysztof Kozlowski + +description: | + This is a part of device tree bindings for Maxim MAX77843 MicroUSB + Integrated Circuit (MUIC). + + The Maxim MAX77843 is a MicroUSB and Companion Power Management IC which + includes voltage current regulators, charger, fuel-gauge, haptic motor driver + and MicroUSB management IC. + +properties: + compatible: + const: maxim,max77843 + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + extcon: + $ref: /schemas/extcon/maxim,max77843.yaml + + motor-driver: + type: object + properties: + compatible: + const: maxim,max77843-haptic + + haptic-supply: + description: Power supply to the haptic motor + + pwms: + maxItems: 1 + + required: + - compatible + - haptic-supply + - pwms + + regulators: + $ref: /schemas/regulator/maxim,max77843.yaml + +required: + - compatible + - interrupts + - reg + +additionalProperties: false + +examples: + - | + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@66 { + compatible = "maxim,max77843"; + interrupt-parent = <&gpa1>; + interrupts = <5 IRQ_TYPE_EDGE_FALLING>; + reg = <0x66>; + + extcon { + compatible = "maxim,max77843-muic"; + + connector { + compatible = "samsung,usb-connector-11pin", + "usb-b-connector"; + label = "micro-USB"; + type = "micro"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + /* + * TODO: The DTS this is based on does not have + * port@0 which is a required property. The ports + * look incomplete and need fixing. + * Add a disabled port just to satisfy dtschema. + */ + reg = <0>; + status = "disabled"; + }; + + port@3 { + reg = <3>; + endpoint { + remote-endpoint = <&mhl_to_musb_con>; + }; + }; + }; + }; + + ports { + port { + endpoint { + remote-endpoint = <&usb_to_muic>; + }; + }; + }; + }; + + regulators { + compatible = "maxim,max77843-regulator"; + + SAFEOUT1 { + regulator-name = "SAFEOUT1"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <4950000>; + }; + + SAFEOUT2 { + regulator-name = "SAFEOUT2"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <4950000>; + }; + + CHARGER { + regulator-name = "CHARGER"; + regulator-min-microamp = <100000>; + regulator-max-microamp = <3150000>; + }; + }; + + motor-driver { + compatible = "maxim,max77843-haptic"; + haptic-supply = <&ldo38_reg>; + pwms = <&pwm 0 33670 0>; + }; + }; + }; -- cgit From aec499c75cf8e0b599be4d559e6922b613085f8f Mon Sep 17 00:00:00 2001 From: Alan Kao Date: Wed, 2 Mar 2022 15:42:45 +0800 Subject: nds32: Remove the architecture The nds32 architecture, also known as AndeStar V3, is a custom 32-bit RISC target designed by Andes Technologies. Support was added to the kernel in 2016 as the replacement RISC-V based V5 processors were already announced, and maintained by (current or former) Andes employees. As explained by Alan Kao, new customers are now all using RISC-V, and all known nds32 users are already on longterm stable kernels provided by Andes, with no development work going into mainline support any more. While the port is still in a reasonably good shape, it only gets worse over time without active maintainers, so it seems best to remove it before it becomes unusable. As always, if it turns out that there are mainline users after all, and they volunteer to maintain the port in the future, the removal can be reverted. Link: https://lore.kernel.org/linux-mm/YhdWNLUhk+x9RAzU@yamatobi.andestech.com/ Link: https://lore.kernel.org/lkml/20220302065213.82702-1-alankao@andestech.com/ Link: https://www.andestech.com/en/products-solutions/andestar-architecture/ Signed-off-by: Alan Kao [arnd: rewrite changelog to provide more background] Signed-off-by: Arnd Bergmann --- .../interrupt-controller/andestech,ativic32.txt | 19 ---------- .../devicetree/bindings/nds32/andestech-boards | 40 ---------------------- Documentation/devicetree/bindings/nds32/atl2c.txt | 28 --------------- Documentation/devicetree/bindings/nds32/cpus.txt | 38 -------------------- .../devicetree/bindings/perf/nds32v3-pmu.txt | 17 --------- .../bindings/timer/andestech,atcpit100-timer.txt | 33 ------------------ .../features/core/cBPF-JIT/arch-support.txt | 1 - .../features/core/eBPF-JIT/arch-support.txt | 1 - .../core/generic-idle-thread/arch-support.txt | 1 - .../features/core/jump-labels/arch-support.txt | 1 - .../core/thread-info-in-task/arch-support.txt | 1 - .../features/core/tracehook/arch-support.txt | 1 - .../features/debug/KASAN/arch-support.txt | 1 - .../debug/debug-vm-pgtable/arch-support.txt | 1 - .../debug/gcov-profile-all/arch-support.txt | 1 - Documentation/features/debug/kcov/arch-support.txt | 1 - Documentation/features/debug/kgdb/arch-support.txt | 1 - .../features/debug/kmemleak/arch-support.txt | 1 - .../debug/kprobes-on-ftrace/arch-support.txt | 1 - .../features/debug/kprobes/arch-support.txt | 1 - .../features/debug/kretprobes/arch-support.txt | 1 - .../features/debug/optprobes/arch-support.txt | 1 - .../features/debug/stackprotector/arch-support.txt | 1 - .../features/debug/uprobes/arch-support.txt | 1 - .../debug/user-ret-profiler/arch-support.txt | 1 - .../features/io/dma-contiguous/arch-support.txt | 1 - .../locking/cmpxchg-local/arch-support.txt | 1 - .../features/locking/lockdep/arch-support.txt | 1 - .../locking/queued-rwlocks/arch-support.txt | 1 - .../locking/queued-spinlocks/arch-support.txt | 1 - .../features/perf/kprobes-event/arch-support.txt | 1 - .../features/perf/perf-regs/arch-support.txt | 1 - .../features/perf/perf-stackdump/arch-support.txt | 1 - .../sched/membarrier-sync-core/arch-support.txt | 1 - .../features/sched/numa-balancing/arch-support.txt | 1 - .../seccomp/seccomp-filter/arch-support.txt | 1 - .../time/arch-tick-broadcast/arch-support.txt | 1 - .../features/time/clockevents/arch-support.txt | 1 - .../time/context-tracking/arch-support.txt | 1 - .../features/time/irq-time-acct/arch-support.txt | 1 - .../features/time/virt-cpuacct/arch-support.txt | 1 - .../features/vm/ELF-ASLR/arch-support.txt | 1 - .../features/vm/PG_uncached/arch-support.txt | 1 - Documentation/features/vm/THP/arch-support.txt | 1 - Documentation/features/vm/TLB/arch-support.txt | 1 - .../features/vm/huge-vmap/arch-support.txt | 1 - .../features/vm/ioremap_prot/arch-support.txt | 1 - .../features/vm/pte_special/arch-support.txt | 1 - 48 files changed, 217 deletions(-) delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt delete mode 100644 Documentation/devicetree/bindings/nds32/andestech-boards delete mode 100644 Documentation/devicetree/bindings/nds32/atl2c.txt delete mode 100644 Documentation/devicetree/bindings/nds32/cpus.txt delete mode 100644 Documentation/devicetree/bindings/perf/nds32v3-pmu.txt delete mode 100644 Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt b/Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt deleted file mode 100644 index f4b4193d830e..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt +++ /dev/null @@ -1,19 +0,0 @@ -* Andestech Internal Vector Interrupt Controller - -The Internal Vector Interrupt Controller (IVIC) is a basic interrupt controller -suitable for a simpler SoC platform not requiring a more sophisticated and -bigger External Vector Interrupt Controller. - - -Main node required properties: - -- compatible : should at least contain "andestech,ativic32". -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells: 1 cells and refer to interrupt-controller/interrupts - -Examples: - intc: interrupt-controller { - compatible = "andestech,ativic32"; - #interrupt-cells = <1>; - interrupt-controller; - }; diff --git a/Documentation/devicetree/bindings/nds32/andestech-boards b/Documentation/devicetree/bindings/nds32/andestech-boards deleted file mode 100644 index f5d75693e3c7..000000000000 --- a/Documentation/devicetree/bindings/nds32/andestech-boards +++ /dev/null @@ -1,40 +0,0 @@ -Andestech(nds32) AE3XX Platform ------------------------------------------------------------------------------ -The AE3XX prototype demonstrates the AE3XX example platform on the FPGA. It -is composed of one Andestech(nds32) processor and AE3XX. - -Required properties (in root node): -- compatible = "andestech,ae3xx"; - -Example: -/dts-v1/; -/ { - compatible = "andestech,ae3xx"; - #address-cells = <1>; - #size-cells = <1>; - interrupt-parent = <&intc>; -}; - -Andestech(nds32) AG101P Platform ------------------------------------------------------------------------------ -AG101P is a generic SoC Platform IP that works with any of Andestech(nds32) -processors to provide a cost-effective and high performance solution for -majority of embedded systems in variety of application domains. Users may -simply attach their IP on one of the system buses together with certain glue -logics to complete a SoC solution for a specific application. With -comprehensive simulation and design environments, users may evaluate the -system performance of their applications and track bugs of their designs -efficiently. The optional hardware development platform further provides real -system environment for early prototyping and software/hardware co-development. - -Required properties (in root node): - compatible = "andestech,ag101p"; - -Example: -/dts-v1/; -/ { - compatible = "andestech,ag101p"; - #address-cells = <1>; - #size-cells = <1>; - interrupt-parent = <&intc>; -}; diff --git a/Documentation/devicetree/bindings/nds32/atl2c.txt b/Documentation/devicetree/bindings/nds32/atl2c.txt deleted file mode 100644 index da8ab8e7ae9b..000000000000 --- a/Documentation/devicetree/bindings/nds32/atl2c.txt +++ /dev/null @@ -1,28 +0,0 @@ -* Andestech L2 cache Controller - -The level-2 cache controller plays an important role in reducing memory latency -for high performance systems, such as thoese designs with AndesCore processors. -Level-2 cache controller in general enhances overall system performance -signigicantly and the system power consumption might be reduced as well by -reducing DRAM accesses. - -This binding specifies what properties must be available in the device tree -representation of an Andestech L2 cache controller. - -Required properties: - - compatible: - Usage: required - Value type: - Definition: "andestech,atl2c" - - reg : Physical base address and size of cache controller's memory mapped - - cache-unified : Specifies the cache is a unified cache. - - cache-level : Should be set to 2 for a level 2 cache. - -* Example - - cache-controller@e0500000 { - compatible = "andestech,atl2c"; - reg = <0xe0500000 0x1000>; - cache-unified; - cache-level = <2>; - }; diff --git a/Documentation/devicetree/bindings/nds32/cpus.txt b/Documentation/devicetree/bindings/nds32/cpus.txt deleted file mode 100644 index 6f9e311b6589..000000000000 --- a/Documentation/devicetree/bindings/nds32/cpus.txt +++ /dev/null @@ -1,38 +0,0 @@ -* Andestech Processor Binding - -This binding specifies what properties must be available in the device tree -representation of a Andestech Processor Core, which is the root node in the -tree. - -Required properties: - - - compatible: - Usage: required - Value type: - Definition: Should be "andestech,", "andestech,nds32v3" as fallback. - Must contain "andestech,nds32v3" as the most generic value, in addition to - one of the following identifiers for a particular CPU core: - "andestech,n13" - "andestech,n15" - "andestech,d15" - "andestech,n10" - "andestech,d10" - - device_type - Usage: required - Value type: - Definition: must be "cpu" - - reg: Contains CPU index. - - clock-frequency: Contains the clock frequency for CPU, in Hz. - -* Examples - -/ { - cpus { - cpu@0 { - device_type = "cpu"; - compatible = "andestech,n13", "andestech,nds32v3"; - reg = <0x0>; - clock-frequency = <60000000> - }; - }; -}; diff --git a/Documentation/devicetree/bindings/perf/nds32v3-pmu.txt b/Documentation/devicetree/bindings/perf/nds32v3-pmu.txt deleted file mode 100644 index 1bd15785b4ae..000000000000 --- a/Documentation/devicetree/bindings/perf/nds32v3-pmu.txt +++ /dev/null @@ -1,17 +0,0 @@ -* NDS32 Performance Monitor Units - -NDS32 core have a PMU for counting cpu and cache events like cache misses. -The NDS32 PMU representation in the device tree should be done as under: - -Required properties: - -- compatible : - "andestech,nds32v3-pmu" - -- interrupts : The interrupt number for NDS32 PMU is 13. - -Example: -pmu{ - compatible = "andestech,nds32v3-pmu"; - interrupts = <13>; -} diff --git a/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt deleted file mode 100644 index 4c9ea5989e35..000000000000 --- a/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt +++ /dev/null @@ -1,33 +0,0 @@ -Andestech ATCPIT100 timer ------------------------------------------------------------------- -ATCPIT100 is a generic IP block from Andes Technology, embedded in -Andestech AE3XX platforms and other designs. - -This timer is a set of compact multi-function timers, which can be -used as pulse width modulators (PWM) as well as simple timers. - -It supports up to 4 PIT channels. Each PIT channel is a -multi-function timer and provide the following usage scenarios: -One 32-bit timer -Two 16-bit timers -Four 8-bit timers -One 16-bit PWM -One 16-bit timer and one 8-bit PWM -Two 8-bit timer and one 8-bit PWM - -Required properties: -- compatible : Should be "andestech,atcpit100" -- reg : Address and length of the register set -- interrupts : Reference to the timer interrupt -- clocks : a clock to provide the tick rate for "andestech,atcpit100" -- clock-names : should be "PCLK" for the peripheral clock source. - -Examples: - -timer0: timer@f0400000 { - compatible = "andestech,atcpit100"; - reg = <0xf0400000 0x1000>; - interrupts = <2>; - clocks = <&apb>; - clock-names = "PCLK"; -}; diff --git a/Documentation/features/core/cBPF-JIT/arch-support.txt b/Documentation/features/core/cBPF-JIT/arch-support.txt index e59b5215402d..77bd6974dd6d 100644 --- a/Documentation/features/core/cBPF-JIT/arch-support.txt +++ b/Documentation/features/core/cBPF-JIT/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/core/eBPF-JIT/arch-support.txt b/Documentation/features/core/eBPF-JIT/arch-support.txt index dcbd8679f514..d5ab547b2be6 100644 --- a/Documentation/features/core/eBPF-JIT/arch-support.txt +++ b/Documentation/features/core/eBPF-JIT/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/core/generic-idle-thread/arch-support.txt b/Documentation/features/core/generic-idle-thread/arch-support.txt index 4efcba7b5239..ddb3762ca7f5 100644 --- a/Documentation/features/core/generic-idle-thread/arch-support.txt +++ b/Documentation/features/core/generic-idle-thread/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | ok | | parisc: | ok | diff --git a/Documentation/features/core/jump-labels/arch-support.txt b/Documentation/features/core/jump-labels/arch-support.txt index 0c801d1bd2da..d5380ef68713 100644 --- a/Documentation/features/core/jump-labels/arch-support.txt +++ b/Documentation/features/core/jump-labels/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/core/thread-info-in-task/arch-support.txt b/Documentation/features/core/thread-info-in-task/arch-support.txt index bc74d8beea72..0654ba3a42ff 100644 --- a/Documentation/features/core/thread-info-in-task/arch-support.txt +++ b/Documentation/features/core/thread-info-in-task/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | ok | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/core/tracehook/arch-support.txt b/Documentation/features/core/tracehook/arch-support.txt index af34308fce7f..8e95dc0c7b90 100644 --- a/Documentation/features/core/tracehook/arch-support.txt +++ b/Documentation/features/core/tracehook/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | ok | | nios2: | ok | | openrisc: | ok | | parisc: | ok | diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt index c244ac7eee26..407ca1d91242 100644 --- a/Documentation/features/debug/KASAN/arch-support.txt +++ b/Documentation/features/debug/KASAN/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt index fa83403b4aec..83eafe1a7f68 100644 --- a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt +++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/gcov-profile-all/arch-support.txt b/Documentation/features/debug/gcov-profile-all/arch-support.txt index b39c1a5de3f3..49e0dda11227 100644 --- a/Documentation/features/debug/gcov-profile-all/arch-support.txt +++ b/Documentation/features/debug/gcov-profile-all/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | ok | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/kcov/arch-support.txt b/Documentation/features/debug/kcov/arch-support.txt index 7e44013cc320..3d34b724ddae 100644 --- a/Documentation/features/debug/kcov/arch-support.txt +++ b/Documentation/features/debug/kcov/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/kgdb/arch-support.txt b/Documentation/features/debug/kgdb/arch-support.txt index 2cb0576f9180..7aa073d908c5 100644 --- a/Documentation/features/debug/kgdb/arch-support.txt +++ b/Documentation/features/debug/kgdb/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | ok | | mips: | ok | - | nds32: | TODO | | nios2: | ok | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/debug/kmemleak/arch-support.txt b/Documentation/features/debug/kmemleak/arch-support.txt index e9ac415f8aec..5c784ff9768a 100644 --- a/Documentation/features/debug/kmemleak/arch-support.txt +++ b/Documentation/features/debug/kmemleak/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | ok | | mips: | ok | - | nds32: | ok | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt index 96156e8802a7..a1f6e98c6b1f 100644 --- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/debug/kprobes/arch-support.txt b/Documentation/features/debug/kprobes/arch-support.txt index ee95ed61909a..e7e7015175e7 100644 --- a/Documentation/features/debug/kprobes/arch-support.txt +++ b/Documentation/features/debug/kprobes/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/debug/kretprobes/arch-support.txt b/Documentation/features/debug/kretprobes/arch-support.txt index 612cb97d47b8..838eb53a6fa5 100644 --- a/Documentation/features/debug/kretprobes/arch-support.txt +++ b/Documentation/features/debug/kretprobes/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/debug/optprobes/arch-support.txt b/Documentation/features/debug/optprobes/arch-support.txt index d6ff141a6122..6358b00b1723 100644 --- a/Documentation/features/debug/optprobes/arch-support.txt +++ b/Documentation/features/debug/optprobes/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/stackprotector/arch-support.txt b/Documentation/features/debug/stackprotector/arch-support.txt index ad4de22a71ab..f6cdf781305f 100644 --- a/Documentation/features/debug/stackprotector/arch-support.txt +++ b/Documentation/features/debug/stackprotector/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/uprobes/arch-support.txt b/Documentation/features/debug/uprobes/arch-support.txt index 8bd5548a4485..0b871e797d24 100644 --- a/Documentation/features/debug/uprobes/arch-support.txt +++ b/Documentation/features/debug/uprobes/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/user-ret-profiler/arch-support.txt b/Documentation/features/debug/user-ret-profiler/arch-support.txt index 2a3fe812a5fa..a2feda7adff1 100644 --- a/Documentation/features/debug/user-ret-profiler/arch-support.txt +++ b/Documentation/features/debug/user-ret-profiler/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/io/dma-contiguous/arch-support.txt b/Documentation/features/io/dma-contiguous/arch-support.txt index bece89586efa..9b407f26d45e 100644 --- a/Documentation/features/io/dma-contiguous/arch-support.txt +++ b/Documentation/features/io/dma-contiguous/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | ok | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/locking/cmpxchg-local/arch-support.txt b/Documentation/features/locking/cmpxchg-local/arch-support.txt index 52bdda004f5c..090520b0e02d 100644 --- a/Documentation/features/locking/cmpxchg-local/arch-support.txt +++ b/Documentation/features/locking/cmpxchg-local/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/locking/lockdep/arch-support.txt b/Documentation/features/locking/lockdep/arch-support.txt index a8cd163c8b7e..6d840b103537 100644 --- a/Documentation/features/locking/lockdep/arch-support.txt +++ b/Documentation/features/locking/lockdep/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | ok | | mips: | ok | - | nds32: | ok | | nios2: | TODO | | openrisc: | ok | | parisc: | TODO | diff --git a/Documentation/features/locking/queued-rwlocks/arch-support.txt b/Documentation/features/locking/queued-rwlocks/arch-support.txt index 8c85949752b3..de586be05d64 100644 --- a/Documentation/features/locking/queued-rwlocks/arch-support.txt +++ b/Documentation/features/locking/queued-rwlocks/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | ok | | parisc: | TODO | diff --git a/Documentation/features/locking/queued-spinlocks/arch-support.txt b/Documentation/features/locking/queued-spinlocks/arch-support.txt index 5f4e1b3841af..29d0c8b7b1c5 100644 --- a/Documentation/features/locking/queued-spinlocks/arch-support.txt +++ b/Documentation/features/locking/queued-spinlocks/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | ok | | parisc: | TODO | diff --git a/Documentation/features/perf/kprobes-event/arch-support.txt b/Documentation/features/perf/kprobes-event/arch-support.txt index 78f3fe080f0e..881a8a50e41e 100644 --- a/Documentation/features/perf/kprobes-event/arch-support.txt +++ b/Documentation/features/perf/kprobes-event/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | ok | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/perf/perf-regs/arch-support.txt b/Documentation/features/perf/perf-regs/arch-support.txt index 5bf3b1854a1f..7639a796a8e1 100644 --- a/Documentation/features/perf/perf-regs/arch-support.txt +++ b/Documentation/features/perf/perf-regs/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/perf/perf-stackdump/arch-support.txt b/Documentation/features/perf/perf-stackdump/arch-support.txt index d88659bb4fc1..df1a4c679a45 100644 --- a/Documentation/features/perf/perf-stackdump/arch-support.txt +++ b/Documentation/features/perf/perf-stackdump/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/sched/membarrier-sync-core/arch-support.txt b/Documentation/features/sched/membarrier-sync-core/arch-support.txt index 883d33b265d6..51b7afc937f1 100644 --- a/Documentation/features/sched/membarrier-sync-core/arch-support.txt +++ b/Documentation/features/sched/membarrier-sync-core/arch-support.txt @@ -40,7 +40,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/sched/numa-balancing/arch-support.txt b/Documentation/features/sched/numa-balancing/arch-support.txt index 9affb7c2c500..d0e308135434 100644 --- a/Documentation/features/sched/numa-balancing/arch-support.txt +++ b/Documentation/features/sched/numa-balancing/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | .. | | microblaze: | .. | | mips: | TODO | - | nds32: | TODO | | nios2: | .. | | openrisc: | .. | | parisc: | .. | diff --git a/Documentation/features/seccomp/seccomp-filter/arch-support.txt b/Documentation/features/seccomp/seccomp-filter/arch-support.txt index 26eec58ab819..05613c5ff560 100644 --- a/Documentation/features/seccomp/seccomp-filter/arch-support.txt +++ b/Documentation/features/seccomp/seccomp-filter/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/time/arch-tick-broadcast/arch-support.txt b/Documentation/features/time/arch-tick-broadcast/arch-support.txt index 8dcaab070c7b..b4c96ebab7e3 100644 --- a/Documentation/features/time/arch-tick-broadcast/arch-support.txt +++ b/Documentation/features/time/arch-tick-broadcast/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/time/clockevents/arch-support.txt b/Documentation/features/time/clockevents/arch-support.txt index 9a81cb03b1fd..3f6976052e2a 100644 --- a/Documentation/features/time/clockevents/arch-support.txt +++ b/Documentation/features/time/clockevents/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | ok | | mips: | ok | - | nds32: | ok | | nios2: | ok | | openrisc: | ok | | parisc: | TODO | diff --git a/Documentation/features/time/context-tracking/arch-support.txt b/Documentation/features/time/context-tracking/arch-support.txt index 4ed116c2ec39..bb1c1801553e 100644 --- a/Documentation/features/time/context-tracking/arch-support.txt +++ b/Documentation/features/time/context-tracking/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/time/irq-time-acct/arch-support.txt b/Documentation/features/time/irq-time-acct/arch-support.txt index bc30c15557c7..3cea25b80c8c 100644 --- a/Documentation/features/time/irq-time-acct/arch-support.txt +++ b/Documentation/features/time/irq-time-acct/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | .. | diff --git a/Documentation/features/time/virt-cpuacct/arch-support.txt b/Documentation/features/time/virt-cpuacct/arch-support.txt index 050de43bbbb9..5163a60a1c1e 100644 --- a/Documentation/features/time/virt-cpuacct/arch-support.txt +++ b/Documentation/features/time/virt-cpuacct/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/vm/ELF-ASLR/arch-support.txt b/Documentation/features/vm/ELF-ASLR/arch-support.txt index 2949c99fbb2f..73ec761f1e27 100644 --- a/Documentation/features/vm/ELF-ASLR/arch-support.txt +++ b/Documentation/features/vm/ELF-ASLR/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/vm/PG_uncached/arch-support.txt b/Documentation/features/vm/PG_uncached/arch-support.txt index 6cde38458596..9066a90b38d9 100644 --- a/Documentation/features/vm/PG_uncached/arch-support.txt +++ b/Documentation/features/vm/PG_uncached/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/vm/THP/arch-support.txt b/Documentation/features/vm/THP/arch-support.txt index 7dbd6967b37e..f717ab792e5a 100644 --- a/Documentation/features/vm/THP/arch-support.txt +++ b/Documentation/features/vm/THP/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | .. | | microblaze: | .. | | mips: | ok | - | nds32: | TODO | | nios2: | .. | | openrisc: | .. | | parisc: | TODO | diff --git a/Documentation/features/vm/TLB/arch-support.txt b/Documentation/features/vm/TLB/arch-support.txt index e1c3a4c4d107..6fa76a37f299 100644 --- a/Documentation/features/vm/TLB/arch-support.txt +++ b/Documentation/features/vm/TLB/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | .. | | microblaze: | .. | | mips: | TODO | - | nds32: | TODO | | nios2: | .. | | openrisc: | .. | | parisc: | TODO | diff --git a/Documentation/features/vm/huge-vmap/arch-support.txt b/Documentation/features/vm/huge-vmap/arch-support.txt index bc53905a0306..6e1792ee37fe 100644 --- a/Documentation/features/vm/huge-vmap/arch-support.txt +++ b/Documentation/features/vm/huge-vmap/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/vm/ioremap_prot/arch-support.txt b/Documentation/features/vm/ioremap_prot/arch-support.txt index 9a0c8783b84d..a6dcbe5f47b6 100644 --- a/Documentation/features/vm/ioremap_prot/arch-support.txt +++ b/Documentation/features/vm/ioremap_prot/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/vm/pte_special/arch-support.txt b/Documentation/features/vm/pte_special/arch-support.txt index 40b969f3a6bb..376477749c42 100644 --- a/Documentation/features/vm/pte_special/arch-support.txt +++ b/Documentation/features/vm/pte_special/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | -- cgit From 0ff4827ed66f3cdb9d4f5cfad4a3c211215ff4f0 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 24 Jan 2022 09:23:44 +0100 Subject: spi: dt-bindings: samsung: Convert to dtschema Convert the Samsung SoC (S3C24xx, S3C64xx, S5Pv210, Exynos) SPI controller bindings to DT schema format. The conversion also drops requirement from providing controller-data and its data for each of SPI peripheral device nodes. The dtschema cannot express this and the requirement is being relaxed in the driver now. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sam Protsenko Acked-by: Pratyush Yadav Reviewed-by: Mark Brown Reviewed-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220124082347.32747-2-krzysztof.kozlowski@canonical.com --- .../bindings/soc/samsung/exynos-usi.yaml | 2 +- .../bindings/spi/samsung,spi-peripheral-props.yaml | 33 ++++ .../devicetree/bindings/spi/samsung,spi.yaml | 187 +++++++++++++++++++++ .../bindings/spi/spi-peripheral-props.yaml | 1 + .../devicetree/bindings/spi/spi-samsung.txt | 122 -------------- 5 files changed, 222 insertions(+), 123 deletions(-) create mode 100644 Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml create mode 100644 Documentation/devicetree/bindings/spi/samsung,spi.yaml delete mode 100644 Documentation/devicetree/bindings/spi/spi-samsung.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml index 273f2d95a043..e72b6a3fae99 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml @@ -22,7 +22,7 @@ description: | [1] Documentation/devicetree/bindings/serial/samsung_uart.yaml [2] Documentation/devicetree/bindings/i2c/i2c-exynos5.txt - [3] Documentation/devicetree/bindings/spi/spi-samsung.txt + [3] Documentation/devicetree/bindings/spi/samsung,spi.yaml properties: $nodename: diff --git a/Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml new file mode 100644 index 000000000000..f0db3fb3d688 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/samsung,spi-peripheral-props.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Peripheral-specific properties for Samsung S3C/S5P/Exynos SoC SPI controller + +maintainers: + - Krzysztof Kozlowski + +description: + See spi-peripheral-props.yaml for more info. + +properties: + controller-data: + type: object + additionalProperties: false + + properties: + samsung,spi-feedback-delay: + description: | + The sampling phase shift to be applied on the miso line (to account + for any lag in the miso line). Valid values: + - 0: No phase shift. + - 1: 90 degree phase shift sampling. + - 2: 180 degree phase shift sampling. + - 3: 270 degree phase shift sampling. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 0 + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/spi/samsung,spi.yaml b/Documentation/devicetree/bindings/spi/samsung,spi.yaml new file mode 100644 index 000000000000..61c77088e8ee --- /dev/null +++ b/Documentation/devicetree/bindings/spi/samsung,spi.yaml @@ -0,0 +1,187 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/samsung,spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C/S5P/Exynos SoC SPI controller + +maintainers: + - Krzysztof Kozlowski + +description: + All the SPI controller nodes should be represented in the aliases node using + the following format 'spi{n}' where n is a unique number for the alias. + +properties: + compatible: + oneOf: + - enum: + - samsung,s3c2443-spi # for S3C2443, S3C2416 and S3C2450 + - samsung,s3c6410-spi + - samsung,s5pv210-spi # for S5PV210 and S5PC110 + - samsung,exynos5433-spi + - const: samsung,exynos7-spi + deprecated: true + + clocks: + minItems: 2 + maxItems: 3 + + clock-names: + minItems: 2 + maxItems: 3 + + cs-gpios: true + + dmas: + minItems: 2 + maxItems: 2 + + dma-names: + items: + - const: tx + - const: rx + + interrupts: + maxItems: 1 + + no-cs-readback: + description: + The CS line is disconnected, therefore the device should not operate + based on CS signalling. + type: boolean + + num-cs: + minimum: 1 + maximum: 4 + default: 1 + + samsung,spi-src-clk: + description: + If the spi controller includes a internal clock mux to select the clock + source for the spi bus clock, this property can be used to indicate the + clock to be used for driving the spi bus clock. If not specified, the + clock number 0 is used as default. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - dmas + - dma-names + - interrupts + - reg + +allOf: + - $ref: spi-controller.yaml# + - if: + properties: + compatible: + contains: + const: samsung,exynos5433-spi + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: spi + - enum: + - spi_busclk0 + - spi_busclk1 + - spi_busclk2 + - spi_busclk3 + - const: spi_ioclk + else: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: spi + - enum: + - spi_busclk0 + - spi_busclk1 + - spi_busclk2 + - spi_busclk3 + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + #include + + spi@14d30000 { + compatible = "samsung,exynos5433-spi"; + reg = <0x14d30000 0x100>; + interrupts = ; + dmas = <&pdma0 11>, <&pdma0 10>; + dma-names = "tx", "rx"; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&cmu_peric CLK_PCLK_SPI1>, + <&cmu_peric CLK_SCLK_SPI1>, + <&cmu_peric CLK_SCLK_IOCLK_SPI1>; + clock-names = "spi", + "spi_busclk0", + "spi_ioclk"; + samsung,spi-src-clk = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&spi1_bus>; + num-cs = <1>; + + cs-gpios = <&gpd6 3 GPIO_ACTIVE_HIGH>; + + audio-codec@0 { + compatible = "wlf,wm5110"; + reg = <0x0>; + spi-max-frequency = <20000000>; + interrupt-parent = <&gpa0>; + interrupts = <4 IRQ_TYPE_NONE>; + clocks = <&pmu_system_controller 0>, + <&s2mps13_osc S2MPS11_CLK_BT>; + clock-names = "mclk1", "mclk2"; + + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + + wlf,micd-detect-debounce = <300>; + wlf,micd-bias-start-time = <0x1>; + wlf,micd-rate = <0x7>; + wlf,micd-dbtime = <0x2>; + wlf,micd-force-micbias; + wlf,micd-configs = <0x0 1 0>; + wlf,hpdet-channel = <1>; + wlf,gpsw = <0x1>; + wlf,inmode = <2 0 2 0>; + + wlf,reset = <&gpc0 7 GPIO_ACTIVE_HIGH>; + wlf,ldoena = <&gpf0 0 GPIO_ACTIVE_HIGH>; + + /* core supplies */ + AVDD-supply = <&ldo18_reg>; + DBVDD1-supply = <&ldo18_reg>; + CPVDD-supply = <&ldo18_reg>; + DBVDD2-supply = <&ldo18_reg>; + DBVDD3-supply = <&ldo18_reg>; + SPKVDDL-supply = <&ldo18_reg>; + SPKVDDR-supply = <&ldo18_reg>; + + controller-data { + samsung,spi-feedback-delay = <0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml index 5dd209206e88..df885eeb144f 100644 --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml @@ -85,5 +85,6 @@ properties: # The controller specific properties go here. allOf: - $ref: cdns,qspi-nor-peripheral-props.yaml# + - $ref: samsung,spi-peripheral-props.yaml# additionalProperties: true diff --git a/Documentation/devicetree/bindings/spi/spi-samsung.txt b/Documentation/devicetree/bindings/spi/spi-samsung.txt deleted file mode 100644 index 49028a4f5df1..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-samsung.txt +++ /dev/null @@ -1,122 +0,0 @@ -* Samsung SPI Controller - -The Samsung SPI controller is used to interface with various devices such as flash -and display controllers using the SPI communication interface. - -Required SoC Specific Properties: - -- compatible: should be one of the following. - - samsung,s3c2443-spi: for s3c2443, s3c2416 and s3c2450 platforms - - samsung,s3c6410-spi: for s3c6410 platforms - - samsung,s5pv210-spi: for s5pv210 and s5pc110 platforms - - samsung,exynos5433-spi: for exynos5433 compatible controllers - - samsung,exynos7-spi: for exynos7 platforms - -- reg: physical base address of the controller and length of memory mapped - region. - -- interrupts: The interrupt number to the cpu. The interrupt specifier format - depends on the interrupt controller. - -- dmas : Two or more DMA channel specifiers following the convention outlined - in bindings/dma/dma.txt - -- dma-names: Names for the dma channels. There must be at least one channel - named "tx" for transmit and named "rx" for receive. - -- clocks: specifies the clock IDs provided to the SPI controller; they are - required for interacting with the controller itself, for synchronizing the bus - and as I/O clock (the latter is required by exynos5433 and exynos7). - -- clock-names: string names of the clocks in the 'clocks' property; for all the - the devices the names must be "spi", "spi_busclkN" (where N is determined by - "samsung,spi-src-clk"), while Exynos5433 should specify a third clock - "spi_ioclk" for the I/O clock. - -Required Board Specific Properties: - -- #address-cells: should be 1. -- #size-cells: should be 0. - -Optional Board Specific Properties: - -- samsung,spi-src-clk: If the spi controller includes a internal clock mux to - select the clock source for the spi bus clock, this property can be used to - indicate the clock to be used for driving the spi bus clock. If not specified, - the clock number 0 is used as default. - -- num-cs: Specifies the number of chip select lines supported. If - not specified, the default number of chip select lines is set to 1. - -- cs-gpios: should specify GPIOs used for chipselects (see spi-bus.txt) - -- no-cs-readback: the CS line is disconnected, therefore the device should not - operate based on CS signalling. - -SPI Controller specific data in SPI slave nodes: - -- The spi slave nodes should provide the following information which is required - by the spi controller. - - - samsung,spi-feedback-delay: The sampling phase shift to be applied on the - miso line (to account for any lag in the miso line). The following are the - valid values. - - - 0: No phase shift. - - 1: 90 degree phase shift sampling. - - 2: 180 degree phase shift sampling. - - 3: 270 degree phase shift sampling. - -Aliases: - -- All the SPI controller nodes should be represented in the aliases node using - the following format 'spi{n}' where n is a unique number for the alias. - - -Example: - -- SoC Specific Portion: - - spi_0: spi@12d20000 { - compatible = "samsung,exynos4210-spi"; - reg = <0x12d20000 0x100>; - interrupts = <0 66 0>; - dmas = <&pdma0 5 - &pdma0 4>; - dma-names = "tx", "rx"; - #address-cells = <1>; - #size-cells = <0>; - }; - -- Board Specific Portion: - - spi_0: spi@12d20000 { - #address-cells = <1>; - #size-cells = <0>; - pinctrl-names = "default"; - pinctrl-0 = <&spi0_bus>; - cs-gpios = <&gpa2 5 0>; - - w25q80bw@0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "w25x80"; - reg = <0>; - spi-max-frequency = <10000>; - - controller-data { - samsung,spi-feedback-delay = <0>; - }; - - partition@0 { - label = "U-Boot"; - reg = <0x0 0x40000>; - read-only; - }; - - partition@40000 { - label = "Kernel"; - reg = <0x40000 0xc0000>; - }; - }; - }; -- cgit From f412fe11c1a9d815565f3918c56f3fd02167c734 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 24 Jan 2022 09:23:45 +0100 Subject: mfd: dt-bindings: google,cros-ec: Reference Samsung SPI bindings The ChromeOS Embedded Controller appears on boards with Samsung Exynos SoC, where Exynos SPI bindings expect controller-data node. Reference SPI peripheral bindings which include now Samsung SPI peripheral parts. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220124082347.32747-3-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/mfd/google,cros-ec.yaml | 29 ++++++++++++---------- 1 file changed, 16 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml index d1f53bd449f7..525ab18005b3 100644 --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml @@ -31,7 +31,7 @@ properties: controller-data: description: - SPI controller data, see bindings/spi/spi-samsung.txt + SPI controller data, see bindings/spi/samsung,spi-peripheral-props.yaml type: object google,cros-ec-spi-pre-delay: @@ -148,18 +148,21 @@ patternProperties: required: - compatible -if: - properties: - compatible: - contains: - enum: - - google,cros-ec-i2c - - google,cros-ec-rpmsg -then: - properties: - google,cros-ec-spi-pre-delay: false - google,cros-ec-spi-msg-delay: false - spi-max-frequency: false +allOf: + - if: + properties: + compatible: + contains: + enum: + - google,cros-ec-i2c + - google,cros-ec-rpmsg + then: + properties: + google,cros-ec-spi-pre-delay: false + google,cros-ec-spi-msg-delay: false + spi-max-frequency: false + else: + $ref: /schemas/spi/spi-peripheral-props.yaml additionalProperties: false -- cgit From 96f06006a3505287b37ba19d4e50e504ac5b6a50 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 24 Jan 2022 09:23:46 +0100 Subject: mfd: dt-bindings: google,cros-ec: Fix indentation in example Correct level of indentation in the example. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220124082347.32747-4-krzysztof.kozlowski@canonical.com --- Documentation/devicetree/bindings/mfd/google,cros-ec.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml index 525ab18005b3..4caadf73fc4a 100644 --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml @@ -203,7 +203,7 @@ examples: spi-max-frequency = <5000000>; proximity { - compatible = "google,cros-ec-mkbp-proximity"; + compatible = "google,cros-ec-mkbp-proximity"; }; cbas { -- cgit From ce44e3aeec43a887a7999f4e0e50df1e4557af78 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 15 Feb 2022 08:47:57 +0100 Subject: dt-bindings: power: supply: maxim,max14577: Convert to dtschema Convert the Charger bindings of Maxim MAX14577/MAX77836 MUIC to DT schema format. The existing bindings were defined in ../bindings/mfd/max14577.txt. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Acked-by: Sebastian Reichel Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220215074759.29402-2-krzysztof.kozlowski@canonical.com --- .../bindings/power/supply/maxim,max14577.yaml | 84 ++++++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/supply/maxim,max14577.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max14577.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max14577.yaml new file mode 100644 index 000000000000..3978b48299de --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/maxim,max14577.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/maxim,max14577.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX14577/MAX77836 MicroUSB and Companion Power Management IC Charger + +maintainers: + - Krzysztof Kozlowski + +description: | + This is a part of device tree bindings for Maxim MAX14577/MAX77836 MicroUSB + Integrated Circuit (MUIC). + + See also Documentation/devicetree/bindings/mfd/maxim,max14577.yaml for + additional information and example. + +properties: + compatible: + enum: + - maxim,max14577-charger + - maxim,max77836-charger + + maxim,constant-uvolt: + description: + Battery Constant Voltage in uV + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 4000000 + maximum: 4350000 + + maxim,eoc-uamp: + description: | + Current in uA for End-Of-Charge mode. + MAX14577: 50000-20000 + MAX77836: 5000-100000 + $ref: /schemas/types.yaml#/definitions/uint32 + + maxim,fast-charge-uamp: + description: | + Current in uA for Fast Charge + MAX14577: 90000-950000 + MAX77836: 45000-475000 + $ref: /schemas/types.yaml#/definitions/uint32 + + maxim,ovp-uvolt: + description: + OverVoltage Protection Threshold in uV; In an overvoltage condition, INT + asserts and charging stops. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [6000000, 6500000, 7000000, 7500000] + +required: + - compatible + - maxim,constant-uvolt + - maxim,eoc-uamp + - maxim,fast-charge-uamp + - maxim,ovp-uvolt + +allOf: + - if: + properties: + compatible: + contains: + const: maxim,max14577-charger + then: + properties: + maxim,eoc-uamp: + minimum: 50000 + maximum: 200000 + maxim,fast-charge-uamp: + minimum: 90000 + maximum: 950000 + else: + # max77836 + properties: + maxim,eoc-uamp: + minimum: 5000 + maximum: 100000 + maxim,fast-charge-uamp: + minimum: 45000 + maximum: 475000 + +additionalProperties: false -- cgit From e1cd4265e547e02efc2a2547e8f390a7a9041787 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 15 Feb 2022 08:47:58 +0100 Subject: regulator: dt-bindings: maxim,max14577: Convert to dtschema Convert the regulator bindings of Maxim MAX14577/MAX77835 MUIC to DT schema format. The existing bindings were defined in ../bindings/mfd/max14577.txt. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Reviewed-by: Mark Brown Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220215074759.29402-3-krzysztof.kozlowski@canonical.com --- .../bindings/regulator/maxim,max14577.yaml | 78 ++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/maxim,max14577.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/maxim,max14577.yaml b/Documentation/devicetree/bindings/regulator/maxim,max14577.yaml new file mode 100644 index 000000000000..16f01886a601 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max14577.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max14577.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX14577/MAX77836 MicroUSB and Companion Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski + +description: | + This is a part of device tree bindings for Maxim MAX14577/MAX77836 MicroUSB + Integrated Circuit (MUIC). + + See also Documentation/devicetree/bindings/mfd/maxim,max14577.yaml for + additional information and example. + +properties: + compatible: + enum: + - maxim,max14577-regulator + - maxim,max77836-regulator + + CHARGER: + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: | + Current regulator. + + properties: + regulator-min-microvolt: false + regulator-max-microvolt: false + + SAFEOUT: + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: | + Safeout LDO regulator (fixed voltage). + + properties: + regulator-min-microamp: false + regulator-max-microamp: false + regulator-min-microvolt: + const: 4900000 + regulator-max-microvolt: + const: 4900000 + +patternProperties: + "^LDO[12]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: | + Current regulator. + + properties: + regulator-min-microamp: false + regulator-max-microamp: false + regulator-min-microvolt: + minimum: 800000 + regulator-max-microvolt: + maximum: 3950000 + +allOf: + - if: + properties: + compatible: + contains: + const: maxim,max14577-regulator + then: + properties: + LDO1: false + LDO2: false + +additionalProperties: false -- cgit From ed6e9aa8f52f88975b4692eb00bdeaf35cd3d529 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 15 Feb 2022 08:47:59 +0100 Subject: dt-bindings: mfd: maxim,max14577: Convert to dtschema Convert the MFD part of Maxim MAX14577/MAX77836 MUIC to DT schema format. The example DTS was copied from existing DTS (exynos3250-rinato.dts), so keep the license as GPL-2.0-only. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220215074759.29402-4-krzysztof.kozlowski@canonical.com --- Documentation/devicetree/bindings/mfd/max14577.txt | 147 ---------------- .../devicetree/bindings/mfd/maxim,max14577.yaml | 195 +++++++++++++++++++++ 2 files changed, 195 insertions(+), 147 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mfd/max14577.txt create mode 100644 Documentation/devicetree/bindings/mfd/maxim,max14577.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/max14577.txt b/Documentation/devicetree/bindings/mfd/max14577.txt deleted file mode 100644 index be11943a0560..000000000000 --- a/Documentation/devicetree/bindings/mfd/max14577.txt +++ /dev/null @@ -1,147 +0,0 @@ -Maxim MAX14577/77836 Multi-Function Device - -MAX14577 is a Multi-Function Device with Micro-USB Interface Circuit, Li+ -Battery Charger and SFOUT LDO output for powering USB devices. It is -interfaced to host controller using I2C. - -MAX77836 additionally contains PMIC (with two LDO regulators) and Fuel Gauge. -For the description of Fuel Gauge low SOC alert interrupt see: -../power/supply/max17040_battery.txt - - -Required properties: -- compatible : Must be "maxim,max14577" or "maxim,max77836". -- reg : I2C slave address for the max14577 chip (0x25 for max14577/max77836) -- interrupts : IRQ line for the chip. - - -Required nodes: - - charger : - Node for configuring the charger driver. - Required properties: - - compatible : "maxim,max14577-charger" - or "maxim,max77836-charger" - - maxim,fast-charge-uamp : Current in uA for Fast Charge; - Valid values: - - for max14577: 90000 - 950000; - - for max77836: 45000 - 475000; - - maxim,eoc-uamp : Current in uA for End-Of-Charge mode; - Valid values: - - for max14577: 50000 - 200000; - - for max77836: 5000 - 100000; - - maxim,ovp-uvolt : OverVoltage Protection Threshold in uV; - In an overvoltage condition, INT asserts and charging - stops. Valid values: - - 6000000, 6500000, 7000000, 7500000; - - maxim,constant-uvolt : Battery Constant Voltage in uV; - Valid values: - - 4000000 - 4280000 (step by 20000); - - 4350000; - - -Optional nodes: -- max14577-muic/max77836-muic : - Node used only by extcon consumers. - Required properties: - - compatible : "maxim,max14577-muic" or "maxim,max77836-muic" - -- regulators : - Required properties: - - compatible : "maxim,max14577-regulator" - or "maxim,max77836-regulator" - - May contain a sub-node per regulator from the list below. Each - sub-node should contain the constraints and initialization information - for that regulator. See regulator.txt for a description of standard - properties for these sub-nodes. - - List of valid regulator names: - - for max14577: CHARGER, SAFEOUT. - - for max77836: CHARGER, SAFEOUT, LDO1, LDO2. - - The SAFEOUT is a fixed voltage regulator so there is no need to specify - voltages for it. - - -Example: - -#include - -max14577@25 { - compatible = "maxim,max14577"; - reg = <0x25>; - interrupt-parent = <&gpx1>; - interrupts = <5 IRQ_TYPE_LEVEL_LOW>; - - muic: max14577-muic { - compatible = "maxim,max14577-muic"; - }; - - regulators { - compatible = "maxim,max14577-regulator"; - - SAFEOUT { - regulator-name = "SAFEOUT"; - }; - CHARGER { - regulator-name = "CHARGER"; - regulator-min-microamp = <90000>; - regulator-max-microamp = <950000>; - regulator-boot-on; - }; - }; - - charger { - compatible = "maxim,max14577-charger"; - - maxim,constant-uvolt = <4350000>; - maxim,fast-charge-uamp = <450000>; - maxim,eoc-uamp = <50000>; - maxim,ovp-uvolt = <6500000>; - }; -}; - - -max77836@25 { - compatible = "maxim,max77836"; - reg = <0x25>; - interrupt-parent = <&gpx1>; - interrupts = <5 IRQ_TYPE_LEVEL_LOW>; - - muic: max77836-muic { - compatible = "maxim,max77836-muic"; - }; - - regulators { - compatible = "maxim,max77836-regulator"; - - SAFEOUT { - regulator-name = "SAFEOUT"; - }; - CHARGER { - regulator-name = "CHARGER"; - regulator-min-microamp = <90000>; - regulator-max-microamp = <950000>; - regulator-boot-on; - }; - LDO1 { - regulator-name = "LDO1"; - regulator-min-microvolt = <2700000>; - regulator-max-microvolt = <2700000>; - }; - LDO2 { - regulator-name = "LDO2"; - regulator-min-microvolt = <800000>; - regulator-max-microvolt = <3950000>; - }; - }; - - charger { - compatible = "maxim,max77836-charger"; - - maxim,constant-uvolt = <4350000>; - maxim,fast-charge-uamp = <225000>; - maxim,eoc-uamp = <7500>; - maxim,ovp-uvolt = <6500000>; - }; -}; diff --git a/Documentation/devicetree/bindings/mfd/maxim,max14577.yaml b/Documentation/devicetree/bindings/mfd/maxim,max14577.yaml new file mode 100644 index 000000000000..27870b8760a6 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/maxim,max14577.yaml @@ -0,0 +1,195 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/maxim,max14577.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX14577/MAX77836 MicroUSB and Companion Power Management IC + +maintainers: + - Krzysztof Kozlowski + +description: | + This is a part of device tree bindings for Maxim MAX14577/MAX77836 MicroUSB + Integrated Circuit (MUIC). + + The Maxim MAX14577 is a MicroUSB and Companion Power Management IC which + includes voltage safeout regulators, charger and MicroUSB management IC. + + The Maxim MAX77836 is a MicroUSB and Companion Power Management IC which + includes voltage safeout and LDO regulators, charger, fuel-gauge and MicroUSB + management IC. + +properties: + compatible: + enum: + - maxim,max14577 + - maxim,max77836 + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + wakeup-source: true + + charger: + $ref: /schemas/power/supply/maxim,max14577.yaml + + extcon: + type: object + properties: + compatible: + enum: + - maxim,max14577-muic + - maxim,max77836-muic + + required: + - compatible + + regulators: + $ref: /schemas/regulator/maxim,max14577.yaml + +required: + - compatible + - interrupts + - reg + - charger + +allOf: + - if: + properties: + compatible: + contains: + const: maxim,max14577 + then: + properties: + charger: + properties: + compatible: + const: maxim,max14577-charger + extcon: + properties: + compatible: + const: maxim,max14577-muic + regulator: + properties: + compatible: + const: maxim,max14577-regulator + else: + properties: + charger: + properties: + compatible: + const: maxim,max77836-charger + extcon: + properties: + compatible: + const: maxim,max77836-muic + regulator: + properties: + compatible: + const: maxim,max77836-regulator + +additionalProperties: false + +examples: + - | + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@25 { + compatible = "maxim,max14577"; + reg = <0x25>; + interrupt-parent = <&gpx1>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW>; + + extcon { + compatible = "maxim,max14577-muic"; + }; + + regulators { + compatible = "maxim,max14577-regulator"; + + SAFEOUT { + regulator-name = "SAFEOUT"; + }; + + CHARGER { + regulator-name = "CHARGER"; + regulator-min-microamp = <90000>; + regulator-max-microamp = <950000>; + regulator-boot-on; + }; + }; + + charger { + compatible = "maxim,max14577-charger"; + + maxim,constant-uvolt = <4350000>; + maxim,fast-charge-uamp = <450000>; + maxim,eoc-uamp = <50000>; + maxim,ovp-uvolt = <6500000>; + }; + }; + }; + + - | + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@25 { + compatible = "maxim,max77836"; + interrupt-parent = <&gpx1>; + interrupts = <5 IRQ_TYPE_NONE>; + reg = <0x25>; + wakeup-source; + + extcon { + compatible = "maxim,max77836-muic"; + }; + + regulators { + compatible = "maxim,max77836-regulator"; + + SAFEOUT { + regulator-name = "SAFEOUT"; + }; + + CHARGER { + regulator-name = "CHARGER"; + regulator-min-microamp = <45000>; + regulator-max-microamp = <475000>; + regulator-boot-on; + }; + + LDO1 { + regulator-name = "MOT_2.7V"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <2700000>; + }; + + LDO2 { + regulator-name = "UNUSED_LDO2"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <3950000>; + }; + }; + + charger { + compatible = "maxim,max77836-charger"; + + maxim,constant-uvolt = <4350000>; + maxim,fast-charge-uamp = <225000>; + maxim,eoc-uamp = <7500>; + maxim,ovp-uvolt = <6500000>; + }; + }; + }; -- cgit From 6b9d48b418fbc91ae8dbcba2cfe078c4736a77f2 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 15 Feb 2022 08:53:43 +0100 Subject: regulator: dt-bindings: maxim,max77802: Convert to dtschema Convert the regulators of Maxim MAX77802 PMIC to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Reviewed-by: Javier Martinez Canillas Acked-by: Mark Brown Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220215075344.31421-2-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/regulator/max77802.txt | 111 --------------------- .../bindings/regulator/maxim,max77802.yaml | 85 ++++++++++++++++ 2 files changed, 85 insertions(+), 111 deletions(-) delete mode 100644 Documentation/devicetree/bindings/regulator/max77802.txt create mode 100644 Documentation/devicetree/bindings/regulator/maxim,max77802.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/max77802.txt b/Documentation/devicetree/bindings/regulator/max77802.txt deleted file mode 100644 index b82943d83677..000000000000 --- a/Documentation/devicetree/bindings/regulator/max77802.txt +++ /dev/null @@ -1,111 +0,0 @@ -Binding for Maxim MAX77802 regulators - -This is a part of device tree bindings of MAX77802 multi-function device. -More information can be found in bindings/mfd/max77802.txt file. - -The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout (LDO) -regulators that can be controlled over I2C. - -Following properties should be present in main device node of the MFD chip. - -Optional properties: -- inb1-supply: The input supply for BUCK1 -- inb2-supply: The input supply for BUCK2 -- inb3-supply: The input supply for BUCK3 -- inb4-supply: The input supply for BUCK4 -- inb5-supply: The input supply for BUCK5 -- inb6-supply: The input supply for BUCK6 -- inb7-supply: The input supply for BUCK7 -- inb8-supply: The input supply for BUCK8 -- inb9-supply: The input supply for BUCK9 -- inb10-supply: The input supply for BUCK10 -- inl1-supply: The input supply for LDO8 and LDO15 -- inl2-supply: The input supply for LDO17, LDO27, LDO30 and LDO35 -- inl3-supply: The input supply for LDO3, LDO5, LDO6 and LDO7 -- inl4-supply: The input supply for LDO10, LDO11, LDO13 and LDO14 -- inl5-supply: The input supply for LDO9 and LDO19 -- inl6-supply: The input supply for LDO4, LDO21, LDO24 and LDO33 -- inl7-supply: The input supply for LDO18, LDO20, LDO28 and LDO29 -- inl9-supply: The input supply for LDO12, LDO23, LDO25, LDO26, LDO32 and LDO34 -- inl10-supply: The input supply for LDO1 and LDO2 - -Optional nodes: -- regulators : The regulators of max77802 have to be instantiated - under subnode named "regulators" using the following format. - - regulator-name { - standard regulator constraints.... - }; - refer Documentation/devicetree/bindings/regulator/regulator.txt - -The regulator node name should be initialized with a string to get matched -with their hardware counterparts as follow. The valid names are: - - -LDOn : for LDOs, where n can lie in ranges 1-15, 17-21, 23-30 - and 32-35. - example: LDO1, LDO2, LDO35. - -BUCKn : for BUCKs, where n can lie in range 1 to 10. - example: BUCK1, BUCK5, BUCK10. - -The max77802 regulator supports two different operating modes: Normal and Low -Power Mode. Some regulators support the modes to be changed at startup or by -the consumers during normal operation while others only support to change the -mode during system suspend. The standard regulator suspend states binding can -be used to configure the regulator operating mode. - -The regulators that support the standard "regulator-initial-mode" property, -changing their mode during normal operation are: LDOs 1, 3, 20 and 21. - -The possible values for "regulator-initial-mode" and "regulator-mode" are: - 1: Normal regulator voltage output mode. - 3: Low Power which reduces the quiescent current down to only 1uA - -The valid modes list is defined in the dt-bindings/regulator/maxim,max77802.h -header and can be included by device tree source files. - -The standard "regulator-mode" property can only be used for regulators that -support changing their mode to Low Power Mode during suspend. These regulators -are: BUCKs 2-4 and LDOs 1-35. Also, it only takes effect if the regulator has -been enabled for the given suspend state using "regulator-on-in-suspend" and -has not been disabled for that state using "regulator-off-in-suspend". - -Example: - - max77802@9 { - compatible = "maxim,max77802"; - interrupt-parent = <&wakeup_eint>; - interrupts = <26 0>; - reg = <0x09>; - #address-cells = <1>; - #size-cells = <0>; - - inb1-supply = <&parent_reg>; - - regulators { - ldo1_reg: LDO1 { - regulator-name = "vdd_1v0"; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1000000>; - regulator-always-on; - regulator-initial-mode = ; - }; - - ldo11_reg: LDO11 { - regulator-name = "vdd_ldo11"; - regulator-min-microvolt = <1900000>; - regulator-max-microvolt = <1900000>; - regulator-always-on; - regulator-state-mem { - regulator-on-in-suspend; - regulator-mode = ; - }; - }; - - buck1_reg: BUCK1 { - regulator-name = "vdd_mif"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1300000>; - regulator-always-on; - regulator-boot-on; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml new file mode 100644 index 000000000000..f2b4dd15a0f3 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max77802.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77802 Power Management IC regulators + +maintainers: + - Javier Martinez Canillas + - Krzysztof Kozlowski + +description: | + This is a part of device tree bindings for Maxim MAX77802 Power Management + Integrated Circuit (PMIC). + + The Maxim MAX77686 provides 10 high-efficiency Buck and 32 Low-DropOut (LDO) + regulators. + + See also Documentation/devicetree/bindings/mfd/maxim,max77802.yaml for + additional information and example. + + Certain regulators support "regulator-initial-mode" and "regulator-mode". + The valid modes list is defined in the dt-bindings/regulator/maxim,max77802.h + and their meaning is:: + 1 - Normal regulator voltage output mode. + 3 - Low Power which reduces the quiescent current down to only 1uA + + The standard "regulator-mode" property can only be used for regulators that + support changing their mode to Low Power Mode during suspend. These + regulators are:: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the + regulator has been enabled for the given suspend state using + "regulator-on-in-suspend" and has not been disabled for that state using + "regulator-off-in-suspend". + +patternProperties: + # LDO1, LDO3, LDO20, LDO21 + "^LDO([13]|2[01])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + LDOs supporting the regulator-initial-mode property and changing their + mode during normal operation. + + # LDO2, LDO4-15, LDO17-19, LDO23-30, LDO32-35 + "^LDO([24-9]|1[0-5789]|2[3-9]|3[02345])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + LDOs supporting the regulator-mode property (changing mode to Low Power + Mode during suspend). + + properties: + regulator-initial-mode: false + + # buck2-4 + "^BUCK[2-4]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + bucks supporting the regulator-mode property (changing mode to Low Power + Mode during suspend). + + properties: + regulator-initial-mode: false + + # buck1, buck5-10 + "^BUCK([15-9]|10)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + + properties: + regulator-initial-mode: false + + patternProperties: + regulator-state-(standby|mem|disk): + type: object + properties: + regulator-mode: false + +additionalProperties: false -- cgit From 172e611b54e813c49a35b6b74bccaa99f27bf566 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 15 Feb 2022 08:53:44 +0100 Subject: dt-bindings: mfd: maxim,max77802: Convert to dtschema Convert the MFD part of Maxim MAX77802 PMIC to DT schema format. The example DTS was copied from existing DTS (exynos5800-peach-pi.dts), so keep the license as GPL-2.0-only. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Reviewed-by: Javier Martinez Canillas Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220215075344.31421-3-krzysztof.kozlowski@canonical.com --- Documentation/devicetree/bindings/mfd/max77802.txt | 25 --- .../devicetree/bindings/mfd/maxim,max77802.yaml | 194 +++++++++++++++++++++ 2 files changed, 194 insertions(+), 25 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt create mode 100644 Documentation/devicetree/bindings/mfd/maxim,max77802.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt b/Documentation/devicetree/bindings/mfd/max77802.txt deleted file mode 100644 index 09decac20d91..000000000000 --- a/Documentation/devicetree/bindings/mfd/max77802.txt +++ /dev/null @@ -1,25 +0,0 @@ -Maxim MAX77802 multi-function device - -The Maxim MAX77802 is a Power Management IC (PMIC) that contains 10 high -efficiency Buck regulators, 32 Low-DropOut (LDO) regulators used to power -up application processors and peripherals, a 2-channel 32kHz clock outputs, -a Real-Time-Clock (RTC) and a I2C interface to program the individual -regulators, clocks outputs and the RTC. - -Bindings for the built-in 32k clock generator block and -regulators are defined in ../clk/maxim,max77802.txt and -../regulator/max77802.txt respectively. - -Required properties: -- compatible : Must be "maxim,max77802" -- reg : Specifies the I2C slave address of PMIC block. -- interrupts : I2C device IRQ line connected to the main SoC. - -Example: - - max77802: pmic@9 { - compatible = "maxim,max77802"; - interrupt-parent = <&intc>; - interrupts = <26 IRQ_TYPE_NONE>; - reg = <0x09>; - }; diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77802.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77802.yaml new file mode 100644 index 000000000000..baa1346ac5d5 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/maxim,max77802.yaml @@ -0,0 +1,194 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/maxim,max77802.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77802 Power Management IC + +maintainers: + - Javier Martinez Canillas + - Krzysztof Kozlowski + +description: | + This is a part of device tree bindings for Maxim MAX77802 Power Management + Integrated Circuit (PMIC). + + The Maxim MAX77802 is a Power Management IC which includes voltage and + current regulators (10 high efficiency Buck regulators and 32 Low-DropOut + (LDO)), RTC and clock outputs. + + The MAX77802 provides two 32.768khz clock outputs that can be controlled + (gated/ungated) over I2C. The clock IDs are defined as preprocessor macros + in dt-bindings/clock/maxim,max77802.h. + +properties: + compatible: + const: maxim,max77802 + + '#clock-cells': + const: 1 + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + regulators: + $ref: /schemas/regulator/maxim,max77802.yaml + description: + List of child nodes that specify the regulators. + + inb1-supply: + description: Power supply for buck1 + inb2-supply: + description: Power supply for buck2 + inb3-supply: + description: Power supply for buck3 + inb4-supply: + description: Power supply for buck4 + inb5-supply: + description: Power supply for buck5 + inb6-supply: + description: Power supply for buck6 + inb7-supply: + description: Power supply for buck7 + inb8-supply: + description: Power supply for buck8 + inb9-supply: + description: Power supply for buck9 + inb10-supply: + description: Power supply for buck10 + + inl1-supply: + description: Power supply for LDO8, LDO15 + inl2-supply: + description: Power supply for LDO17, LDO27, LDO30, LDO35 + inl3-supply: + description: Power supply for LDO3, LDO5, LDO7, LDO7 + inl4-supply: + description: Power supply for LDO10, LDO11, LDO13, LDO14 + inl5-supply: + description: Power supply for LDO9, LDO19 + inl6-supply: + description: Power supply for LDO4, LDO21, LDO24, LDO33 + inl7-supply: + description: Power supply for LDO18, LDO20, LDO28, LDO29 + inl9-supply: + description: Power supply for LDO12, LDO23, LDO25, LDO26, LDO32, LDO34 + inl10-supply: + description: Power supply for LDO1, LDO2 + + wakeup-source: true + +required: + - compatible + - '#clock-cells' + - reg + +additionalProperties: false + +examples: + - | + #include + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@9 { + compatible = "maxim,max77802"; + interrupt-parent = <&gpx3>; + interrupts = <1 IRQ_TYPE_NONE>; + pinctrl-names = "default"; + pinctrl-0 = <&max77802_irq>, <&pmic_selb>, + <&pmic_dvs_1>, <&pmic_dvs_2>, <&pmic_dvs_3>; + wakeup-source; + reg = <0x9>; + #clock-cells = <1>; + + inb1-supply = <&tps65090_dcdc2>; + inb2-supply = <&tps65090_dcdc1>; + inb3-supply = <&tps65090_dcdc2>; + inb4-supply = <&tps65090_dcdc2>; + inb5-supply = <&tps65090_dcdc1>; + inb6-supply = <&tps65090_dcdc2>; + inb7-supply = <&tps65090_dcdc1>; + inb8-supply = <&tps65090_dcdc1>; + inb9-supply = <&tps65090_dcdc1>; + inb10-supply = <&tps65090_dcdc1>; + + inl1-supply = <&buck5_reg>; + inl2-supply = <&buck7_reg>; + inl3-supply = <&buck9_reg>; + inl4-supply = <&buck9_reg>; + inl5-supply = <&buck9_reg>; + inl6-supply = <&tps65090_dcdc2>; + inl7-supply = <&buck9_reg>; + inl9-supply = <&tps65090_dcdc2>; + inl10-supply = <&buck7_reg>; + + regulators { + BUCK1 { + regulator-name = "vdd_mif"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1300000>; + regulator-always-on; + regulator-boot-on; + regulator-ramp-delay = <12500>; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + BUCK2 { + regulator-name = "vdd_arm"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1500000>; + regulator-always-on; + regulator-boot-on; + regulator-ramp-delay = <12500>; + regulator-coupled-with = <&buck3_reg>; + regulator-coupled-max-spread = <300000>; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + // ... + + BUCK10 { + regulator-name = "vdd_1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + + LDO1 { + regulator-name = "vdd_1v0"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-always-on; + regulator-initial-mode = ; + regulator-state-mem { + regulator-on-in-suspend; + regulator-mode = ; + }; + }; + + // ... + + LDO35 { + regulator-name = "ldo_35"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + }; + }; + }; + }; -- cgit From 3c14b73454cf9f6e2146443fdfbdfb912c0efed3 Mon Sep 17 00:00:00 2001 From: "Pratik R. Sampat" Date: Thu, 17 Feb 2022 16:23:20 +0530 Subject: powerpc/pseries: Interface to represent PAPR firmware attributes Adds a syscall interface to represent the energy and frequency related PAPR attributes on the system using the new H_CALL "H_GET_ENERGY_SCALE_INFO". H_GET_EM_PARMS H_CALL was previously responsible for exporting this information in the lparcfg, however the H_GET_EM_PARMS H_CALL will be deprecated P10 onwards. The H_GET_ENERGY_SCALE_INFO H_CALL is of the following call format: hcall( uint64 H_GET_ENERGY_SCALE_INFO, // Get energy scale info uint64 flags, // Per the flag request uint64 firstAttributeId,// The attribute id uint64 bufferAddress, // Guest physical address of the output buffer uint64 bufferSize // The size in bytes of the output buffer ); As specified in PAPR+ v2.11, section 14.14.3. This H_CALL can query either all the attributes at once with firstAttributeId = 0, flags = 0 as well as query only one attribute at a time with firstAttributeId = id, flags = 1. The output buffer consists of the following 1. number of attributes - 8 bytes 2. array offset to the data location - 8 bytes 3. version info - 1 byte 4. A data array of size num attributes, which contains the following: a. attribute ID - 8 bytes b. attribute value in number - 8 bytes c. attribute name in string - 64 bytes d. attribute value in string - 64 bytes The new H_CALL exports information in direct string value format, hence a new interface has been introduced in /sys/firmware/papr/energy_scale_info to export this information to userspace so that the firmware can add new values without the need for the kernel to be changed. The H_CALL returns the name, numeric value and string value (if exists) The format of exposing the sysfs information is as follows: /sys/firmware/papr/energy_scale_info/ |-- / |-- desc |-- value |-- value_desc (if exists) |-- / |-- desc |-- value |-- value_desc (if exists) ... The energy information that is exported is useful for userspace tools such as powerpc-utils. Currently these tools infer the "power_mode_data" value in the lparcfg, which in turn is obtained from the to be deprecated H_GET_EM_PARMS H_CALL. On future platforms, such userspace utilities will have to look at the data returned from the new H_CALL being populated in this new sysfs interface and report this information directly without the need of interpretation. Signed-off-by: Pratik R. Sampat Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220217105321.52941-2-psampat@linux.ibm.com --- .../testing/sysfs-firmware-papr-energy-scale-info | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info new file mode 100644 index 000000000000..141a6b371469 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info @@ -0,0 +1,29 @@ +What: /sys/firmware/papr/energy_scale_info +Date: February 2022 +Contact: Linux for PowerPC mailing list +Description: Directory hosting a set of platform attributes like + energy/frequency on Linux running as a PAPR guest. + + Each file in a directory contains a platform + attribute hierarchy pertaining to performance/ + energy-savings mode and processor frequency. + +What: /sys/firmware/papr/energy_scale_info/ +Date: February 2022 +Contact: Linux for PowerPC mailing list +Description: Energy, frequency attributes directory for POWERVM servers + +What: /sys/firmware/papr/energy_scale_info//desc +Date: February 2022 +Contact: Linux for PowerPC mailing list +Description: String description of the energy attribute of + +What: /sys/firmware/papr/energy_scale_info//value +Date: February 2022 +Contact: Linux for PowerPC mailing list +Description: Numeric value of the energy attribute of + +What: /sys/firmware/papr/energy_scale_info//value_desc +Date: February 2022 +Contact: Linux for PowerPC mailing list +Description: String value of the energy attribute of -- cgit From 26e5366dd30569a469e1a87998b866b814deccf8 Mon Sep 17 00:00:00 2001 From: Richard Fitzgerald Date: Mon, 28 Feb 2022 17:27:53 +0000 Subject: ASoC: dt-bindings: audio-graph-port: Add dai-tdm-slot-width-map Some audio hardware cannot support a fixed slot width for all sample widths, or a slot width equal to the sample width for all sample widths. This is usually due either to limitations of the audio serial port or system clocking restrictions. This property allows setting a mapping of sample widths and the corresponding tdm slot widths. The slot count is also provided for each slot width - although this would almost always be the same for all slot widths this allows for possibly adding extra padding slots to maintain a fixed bitclock frequency. Signed-off-by: Richard Fitzgerald Link: https://lore.kernel.org/r/20220228172754.453783-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/audio-graph-port.yaml | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml index 476dcb49ece6..5c368674d11a 100644 --- a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml +++ b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml @@ -71,4 +71,24 @@ patternProperties: description: CPU to Codec rate channels. $ref: /schemas/types.yaml#/definitions/uint32 + dai-tdm-slot-width-map: + description: Mapping of sample widths to slot widths. For hardware + that cannot support a fixed slot width or a slot width always + equal to sample width. A matrix of one or more 3-tuples. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - + description: Sample width in bits + minimum: 8 + maximum: 64 + - + description: Slot width in bits + minimum: 8 + maximum: 256 + - + description: Slot count + minimum: 1 + maximum: 64 + additionalProperties: true -- cgit From b3284430615c27ca441967f99fbde957b434e092 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Fri, 4 Mar 2022 11:24:51 +0100 Subject: ASoC: dt-bindings: Add schema for "awinic,aw8738" Add a DT schema for describing Awinic AW8738 audio amplifiers. They are fairly simple and controlled using a single GPIO. The number of pulses during power up selects one of a few pre-defined operation modes. This can be used to configure the speaker-guard function (primarily the power limit for the amplifier). Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20220304102452.26856-2-stephan@gerhold.net Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/awinic,aw8738.yaml | 54 ++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/awinic,aw8738.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/awinic,aw8738.yaml b/Documentation/devicetree/bindings/sound/awinic,aw8738.yaml new file mode 100644 index 000000000000..dce86dafe382 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/awinic,aw8738.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/awinic,aw8738.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Awinic AW8738 Audio Amplifier + +maintainers: + - Stephan Gerhold + +description: + The Awinic AW8738 is a simple audio amplifier with different operation modes + (set using one-wire pulse control). The mode configures the speaker-guard + function (primarily the power limit for the amplifier). + +allOf: + - $ref: name-prefix.yaml# + +properties: + compatible: + const: awinic,aw8738 + + mode-gpios: + description: + GPIO used for one-wire pulse control. The pin is typically called SHDN + (active-low), but this is misleading since it is actually more than + just a simple shutdown/enable control. + maxItems: 1 + + awinic,mode: + description: Operation mode (number of pulses for one-wire pulse control) + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 7 + + sound-name-prefix: true + +required: + - compatible + - mode-gpios + - awinic,mode + +additionalProperties: false + +examples: + - | + #include + audio-amplifier { + compatible = "awinic,aw8738"; + mode-gpios = <&msmgpio 114 GPIO_ACTIVE_HIGH>; + awinic,mode = <5>; + sound-name-prefix = "Speaker Amp"; + }; -- cgit From af524ae5ad13a9c28acf0b2ec4489d5903c4fbed Mon Sep 17 00:00:00 2001 From: Kuldeep Singh Date: Thu, 3 Mar 2022 00:59:15 +0530 Subject: spi: Update NXP Flexspi maintainer details Add Han Xu as flexspi maintainer. Also, update my email address as previous one is not working anymore. Signed-off-by: Kuldeep Singh Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220302192915.6193-1-singh.kuldeep87k@gmail.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml index 283815d59e85..1b552c298277 100644 --- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml @@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: NXP Flex Serial Peripheral Interface (FSPI) maintainers: - - Kuldeep Singh + - Han Xu + - Kuldeep Singh allOf: - $ref: "spi-controller.yaml#" -- cgit From 320689a1b543ca1396b3ed43bb18045e4a7ffd79 Mon Sep 17 00:00:00 2001 From: Jon Hunter Date: Mon, 7 Mar 2022 11:35:29 +0000 Subject: spi: Fix Tegra QSPI example When running dt_binding_check on the nvidia,tegra210-quad.yaml binding document the following error is reported ... nvidia,tegra210-quad.example.dt.yaml:0:0: /example-0/spi@70410000/flash@0: failed to match any schema with compatible: ['spi-nor'] Update the example in the binding document to fix the above error. Signed-off-by: Jon Hunter Fixes: 9684752e5fe3 ("dt-bindings: spi: Add Tegra Quad SPI device tree binding") Link: https://lore.kernel.org/r/20220307113529.315685-1-jonathanh@nvidia.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml index 6efea8970e62..0296edd1de22 100644 --- a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml @@ -107,7 +107,7 @@ examples: dma-names = "rx", "tx"; flash@0 { - compatible = "spi-nor"; + compatible = "jedec,spi-nor"; reg = <0>; spi-max-frequency = <104000000>; spi-tx-bus-width = <2>; -- cgit From d1f3188478743ee302c8b0c1f6d17a82c517fa9d Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Wed, 23 Feb 2022 18:59:04 +0100 Subject: dt-bindings: mfd: Add Maxim MAX77714 PMIC Add bindings for the MAX77714 PMIC with GPIO, RTC and watchdog. Signed-off-by: Luca Ceresoli Reviewed-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Signed-off-by: Lee Jones --- .../devicetree/bindings/mfd/maxim,max77714.yaml | 68 ++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/maxim,max77714.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77714.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77714.yaml new file mode 100644 index 000000000000..74a6867d3c82 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/maxim,max77714.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/maxim,max77714.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MAX77714 PMIC with GPIO, RTC and watchdog from Maxim Integrated. + +maintainers: + - Luca Ceresoli + +description: | + MAX77714 is a Power Management IC with 4 buck regulators, 9 + low-dropout regulators, 8 GPIOs, RTC and watchdog. + +properties: + compatible: + const: maxim,max77714 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + description: + The first cell is the IRQ number, the second cell is the trigger type. + + regulators: + type: object + additionalProperties: false + + patternProperties: + '^(buck[0-3]|ldo[0-8])$': + type: object + unevaluatedProperties: false + $ref: /schemas/regulator/regulator.yaml# + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - "#interrupt-cells" + +additionalProperties: false + +examples: + - | + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@1c { + compatible = "maxim,max77714"; + reg = <0x1c>; + interrupt-parent = <&gpio2>; + interrupts = <3 IRQ_TYPE_LEVEL_LOW>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + }; -- cgit From 1092347165cf5ed1453c1f211641a859818a2828 Mon Sep 17 00:00:00 2001 From: Sean Young Date: Wed, 9 Feb 2022 17:03:12 +0100 Subject: media: lirc: remove unused feature LIRC_CAN_SET_REC_DUTY_CYCLE There is no hardware which can filter input on the duty cycle, so no driver implements this. On top of that, LIRC_CAN_SET_REC_DUTY_CYCLE has the same value as LIRC_CAN_MEASURE_CARRIER (0x02000000). Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/lirc.h.rst.exceptions | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/lirc.h.rst.exceptions b/Documentation/userspace-api/media/lirc.h.rst.exceptions index 5f31e967bc50..913d17b49831 100644 --- a/Documentation/userspace-api/media/lirc.h.rst.exceptions +++ b/Documentation/userspace-api/media/lirc.h.rst.exceptions @@ -30,7 +30,6 @@ ignore define LIRC_CAN_REC ignore define LIRC_CAN_SEND_MASK ignore define LIRC_CAN_REC_MASK -ignore define LIRC_CAN_SET_REC_DUTY_CYCLE # Obsolete ioctls -- cgit From 38ad8b32f3afd4314c486685bd1bd7c4c762bf82 Mon Sep 17 00:00:00 2001 From: Ming Qian Date: Thu, 24 Feb 2022 11:09:59 +0800 Subject: dt-bindings: media: amphion: add amphion video codec bindings Add devicetree binding documentation for amphion Video Processing Unit IP presents on NXP i.MX8Q Signed-off-by: Ming Qian Signed-off-by: Shijie Qin Signed-off-by: Zhou Peng Reviewed-by: Rob Herring Signed-off-by: Hans Verkuil --- .../devicetree/bindings/media/amphion,vpu.yaml | 180 +++++++++++++++++++++ 1 file changed, 180 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/amphion,vpu.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/amphion,vpu.yaml b/Documentation/devicetree/bindings/media/amphion,vpu.yaml new file mode 100644 index 000000000000..a9d80eaeeeb6 --- /dev/null +++ b/Documentation/devicetree/bindings/media/amphion,vpu.yaml @@ -0,0 +1,180 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/amphion,vpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amphion VPU codec IP + +maintainers: + - Ming Qian + - Shijie Qin + +description: |- + The Amphion MXC video encoder(Windsor) and decoder(Malone) accelerators present + on NXP i.MX8Q SoCs. + +properties: + $nodename: + pattern: "^vpu@[0-9a-f]+$" + + compatible: + items: + - enum: + - nxp,imx8qm-vpu + - nxp,imx8qxp-vpu + + reg: + maxItems: 1 + + power-domains: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + +patternProperties: + "^mailbox@[0-9a-f]+$": + description: + Each vpu encoder or decoder correspond a MU, which used for communication + between driver and firmware. Implement via mailbox on driver. + $ref: ../mailbox/fsl,mu.yaml# + + + "^vpu_core@[0-9a-f]+$": + description: + Each core correspond a decoder or encoder, need to configure them + separately. NXP i.MX8QM SoC has one decoder and two encoder, i.MX8QXP SoC + has one decoder and one encoder. + type: object + + properties: + compatible: + items: + - enum: + - nxp,imx8q-vpu-decoder + - nxp,imx8q-vpu-encoder + + reg: + maxItems: 1 + + power-domains: + maxItems: 1 + + mbox-names: + items: + - const: tx0 + - const: tx1 + - const: rx + + mboxes: + description: + List of phandle of 2 MU channels for tx, 1 MU channel for rx. + maxItems: 3 + + memory-region: + description: + Phandle to the reserved memory nodes to be associated with the + remoteproc device. The reserved memory nodes should be carveout nodes, + and should be defined as per the bindings in + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt + items: + - description: region reserved for firmware image sections. + - description: region used for RPC shared memory between firmware and + driver. + + required: + - compatible + - reg + - power-domains + - mbox-names + - mboxes + - memory-region + + additionalProperties: false + +required: + - compatible + - reg + - power-domains + +additionalProperties: false + +examples: + # Device node example for i.MX8QM platform: + - | + #include + + vpu: vpu@2c000000 { + compatible = "nxp,imx8qm-vpu"; + ranges = <0x2c000000 0x2c000000 0x2000000>; + reg = <0x2c000000 0x1000000>; + #address-cells = <1>; + #size-cells = <1>; + power-domains = <&pd IMX_SC_R_VPU>; + + mu_m0: mailbox@2d000000 { + compatible = "fsl,imx6sx-mu"; + reg = <0x2d000000 0x20000>; + interrupts = <0 472 4>; + #mbox-cells = <2>; + power-domains = <&pd IMX_SC_R_VPU_MU_0>; + }; + + mu1_m0: mailbox@2d020000 { + compatible = "fsl,imx6sx-mu"; + reg = <0x2d020000 0x20000>; + interrupts = <0 473 4>; + #mbox-cells = <2>; + power-domains = <&pd IMX_SC_R_VPU_MU_1>; + }; + + mu2_m0: mailbox@2d040000 { + compatible = "fsl,imx6sx-mu"; + reg = <0x2d040000 0x20000>; + interrupts = <0 474 4>; + #mbox-cells = <2>; + power-domains = <&pd IMX_SC_R_VPU_MU_2>; + }; + + vpu_core0: vpu_core@2d080000 { + compatible = "nxp,imx8q-vpu-decoder"; + reg = <0x2d080000 0x10000>; + power-domains = <&pd IMX_SC_R_VPU_DEC_0>; + mbox-names = "tx0", "tx1", "rx"; + mboxes = <&mu_m0 0 0>, + <&mu_m0 0 1>, + <&mu_m0 1 0>; + memory-region = <&decoder_boot>, <&decoder_rpc>; + }; + + vpu_core1: vpu_core@2d090000 { + compatible = "nxp,imx8q-vpu-encoder"; + reg = <0x2d090000 0x10000>; + power-domains = <&pd IMX_SC_R_VPU_ENC_0>; + mbox-names = "tx0", "tx1", "rx"; + mboxes = <&mu1_m0 0 0>, + <&mu1_m0 0 1>, + <&mu1_m0 1 0>; + memory-region = <&encoder1_boot>, <&encoder1_rpc>; + }; + + vpu_core2: vpu_core@2d0a0000 { + reg = <0x2d0a0000 0x10000>; + compatible = "nxp,imx8q-vpu-encoder"; + power-domains = <&pd IMX_SC_R_VPU_ENC_1>; + mbox-names = "tx0", "tx1", "rx"; + mboxes = <&mu2_m0 0 0>, + <&mu2_m0 0 1>, + <&mu2_m0 1 0>; + memory-region = <&encoder2_boot>, <&encoder2_rpc>; + }; + }; + +... -- cgit From 72a74c8f0a0df12c7d7ea012aa70d95152858dea Mon Sep 17 00:00:00 2001 From: Ming Qian Date: Thu, 24 Feb 2022 11:10:00 +0800 Subject: media: add nv12m_8l128 and nv12m_10be_8l128 video format. nv12m_8l128 is 8-bit tiled nv12 format used by amphion decoder. nv12m_10be_8l128 is 10-bit tiled format used by amphion decoder. The tile size is 8x128 Signed-off-by: Ming Qian Signed-off-by: Shijie Qin Signed-off-by: Zhou Peng Signed-off-by: Hans Verkuil --- .../userspace-api/media/v4l/pixfmt-yuv-planar.rst | 28 +++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst index 9a969f662595..cc3e4b5791c5 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst @@ -257,6 +257,8 @@ of the luma plane. .. _V4L2-PIX-FMT-NV12-4L4: .. _V4L2-PIX-FMT-NV12-16L16: .. _V4L2-PIX-FMT-NV12-32L32: +.. _V4L2_PIX_FMT_NV12M_8L128: +.. _V4L2_PIX_FMT_NV12M_10BE_8L128: Tiled NV12 ---------- @@ -281,21 +283,41 @@ If the vertical resolution is an odd number of tiles, the last row of tiles is stored in linear order. The layouts of the luma and chroma planes are identical. -``V4L2_PIX_FMT_NV12_4L4`` stores pixel in 4x4 tiles, and stores +``V4L2_PIX_FMT_NV12_4L4`` stores pixels in 4x4 tiles, and stores tiles linearly in memory. The line stride and image height must be aligned to a multiple of 4. The layouts of the luma and chroma planes are identical. -``V4L2_PIX_FMT_NV12_16L16`` stores pixel in 16x16 tiles, and stores +``V4L2_PIX_FMT_NV12_16L16`` stores pixels in 16x16 tiles, and stores tiles linearly in memory. The line stride and image height must be aligned to a multiple of 16. The layouts of the luma and chroma planes are identical. -``V4L2_PIX_FMT_NV12_32L32`` stores pixel in 32x32 tiles, and stores +``V4L2_PIX_FMT_NV12_32L32`` stores pixels in 32x32 tiles, and stores tiles linearly in memory. The line stride and image height must be aligned to a multiple of 32. The layouts of the luma and chroma planes are identical. +``V4L2_PIX_FMT_NV12M_8L128`` is similar to ``V4L2_PIX_FMT_NV12M`` but stores +pixels in 2D 8x128 tiles, and stores tiles linearly in memory. +The image height must be aligned to a multiple of 128. +The layouts of the luma and chroma planes are identical. + +``V4L2_PIX_FMT_NV12M_10BE_8L128`` is similar to ``V4L2_PIX_FMT_NV12M`` but stores +10 bits pixels in 2D 8x128 tiles, and stores tiles linearly in memory. +the data is arranged in big endian order. +The image height must be aligned to a multiple of 128. +The layouts of the luma and chroma planes are identical. +Note the tile size is 8bytes multiplied by 128 bytes, +it means that the low bits and high bits of one pixel may be in different tiles. +The 10 bit pixels are packed, so 5 bytes contain 4 10-bit pixels layout like +this (for luma): +byte 0: Y0(bits 9-2) +byte 1: Y0(bits 1-0) Y1(bits 9-4) +byte 2: Y1(bits 3-0) Y2(bits 9-6) +byte 3: Y2(bits 5-0) Y3(bits 9-8) +byte 4: Y3(bits 7-0) + ``V4L2_PIX_FMT_MM21`` store luma pixel in 16x32 tiles, and chroma pixels in 16x16 tiles. The line stride must be aligned to a multiple of 16 and the image height must be aligned to a multiple of 32. The number of luma and chroma -- cgit From cea9ffe0094d468b17814056fcebe7b3840af5f0 Mon Sep 17 00:00:00 2001 From: David Heidelberg Date: Fri, 4 Mar 2022 00:33:06 +0100 Subject: dt-bindings: timer: Tegra: Convert text bindings to yaml Convert Tegra timer binding into yaml format. This commit also merge 3 text bindings with almost identical content (differens in number of registers). Reviewed-by: Rob Herring Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20220303233307.61753-1-david@ixit.cz Signed-off-by: Daniel Lezcano --- .../bindings/timer/nvidia,tegra-timer.yaml | 150 +++++++++++++++++++++ .../bindings/timer/nvidia,tegra20-timer.txt | 24 ---- .../bindings/timer/nvidia,tegra210-timer.txt | 36 ----- .../bindings/timer/nvidia,tegra30-timer.txt | 28 ---- 4 files changed, 150 insertions(+), 88 deletions(-) create mode 100644 Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml delete mode 100644 Documentation/devicetree/bindings/timer/nvidia,tegra20-timer.txt delete mode 100644 Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt delete mode 100644 Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml b/Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml new file mode 100644 index 000000000000..b78209cd0f28 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml @@ -0,0 +1,150 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/timer/nvidia,tegra-timer.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: NVIDIA Tegra timer + +maintainers: + - Stephen Warren + +allOf: + - if: + properties: + compatible: + contains: + const: nvidia,tegra210-timer + then: + properties: + interrupts: + # Either a single combined interrupt or up to 14 individual interrupts + minItems: 1 + maxItems: 14 + description: > + A list of 14 interrupts; one per each timer channels 0 through 13 + + - if: + properties: + compatible: + oneOf: + - items: + - enum: + - nvidia,tegra114-timer + - nvidia,tegra124-timer + - nvidia,tegra132-timer + - const: nvidia,tegra30-timer + - items: + - const: nvidia,tegra30-timer + - const: nvidia,tegra20-timer + then: + properties: + interrupts: + # Either a single combined interrupt or up to 6 individual interrupts + minItems: 1 + maxItems: 6 + description: > + A list of 6 interrupts; one per each of timer channels 1 through 5, + and one for the shared interrupt for the remaining channels. + + - if: + properties: + compatible: + const: nvidia,tegra20-timer + then: + properties: + interrupts: + # Either a single combined interrupt or up to 4 individual interrupts + minItems: 1 + maxItems: 4 + description: | + A list of 4 interrupts; one per timer channel. + +properties: + compatible: + oneOf: + - const: nvidia,tegra210-timer + description: > + The Tegra210 timer provides fourteen 29-bit timer counters and one 32-bit + timestamp counter. The TMRs run at either a fixed 1 MHz clock rate derived + from the oscillator clock (TMR0-TMR9) or directly at the oscillator clock + (TMR10-TMR13). Each TMR can be programmed to generate one-shot, periodic, + or watchdog interrupts. + - items: + - enum: + - nvidia,tegra114-timer + - nvidia,tegra124-timer + - nvidia,tegra132-timer + - const: nvidia,tegra30-timer + - items: + - const: nvidia,tegra30-timer + - const: nvidia,tegra20-timer + description: > + The Tegra30 timer provides ten 29-bit timer channels, a single 32-bit free + running counter, and 5 watchdog modules. The first two channels may also + trigger a legacy watchdog reset. + - const: nvidia,tegra20-timer + description: > + The Tegra20 timer provides four 29-bit timer channels and a single 32-bit free + running counter. The first two channels may also trigger a watchdog reset. + + reg: + maxItems: 1 + + interrupts: true + + clocks: + maxItems: 1 + + clock-names: + items: + - const: timer + + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include + timer@60005000 { + compatible = "nvidia,tegra30-timer", "nvidia,tegra20-timer"; + reg = <0x60005000 0x400>; + interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>, + <0 1 IRQ_TYPE_LEVEL_HIGH>, + <0 41 IRQ_TYPE_LEVEL_HIGH>, + <0 42 IRQ_TYPE_LEVEL_HIGH>, + <0 121 IRQ_TYPE_LEVEL_HIGH>, + <0 122 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car 214>; + }; + - | + #include + #include + #include + + timer@60005000 { + compatible = "nvidia,tegra210-timer"; + reg = <0x60005000 0x400>; + interrupts = , + , + , + , + , + , + , + , + , + , + , + , + , + ; + clocks = <&tegra_car TEGRA210_CLK_TIMER>; + clock-names = "timer"; + }; diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra20-timer.txt b/Documentation/devicetree/bindings/timer/nvidia,tegra20-timer.txt deleted file mode 100644 index 4a864bd10d3d..000000000000 --- a/Documentation/devicetree/bindings/timer/nvidia,tegra20-timer.txt +++ /dev/null @@ -1,24 +0,0 @@ -NVIDIA Tegra20 timer - -The Tegra20 timer provides four 29-bit timer channels and a single 32-bit free -running counter. The first two channels may also trigger a watchdog reset. - -Required properties: - -- compatible : should be "nvidia,tegra20-timer". -- reg : Specifies base physical address and size of the registers. -- interrupts : A list of 4 interrupts; one per timer channel. -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - -Example: - -timer { - compatible = "nvidia,tegra20-timer"; - reg = <0x60005000 0x60>; - interrupts = <0 0 0x04 - 0 1 0x04 - 0 41 0x04 - 0 42 0x04>; - clocks = <&tegra_car 132>; -}; diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt b/Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt deleted file mode 100644 index 032cda96fe0d..000000000000 --- a/Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt +++ /dev/null @@ -1,36 +0,0 @@ -NVIDIA Tegra210 timer - -The Tegra210 timer provides fourteen 29-bit timer counters and one 32-bit -timestamp counter. The TMRs run at either a fixed 1 MHz clock rate derived -from the oscillator clock (TMR0-TMR9) or directly at the oscillator clock -(TMR10-TMR13). Each TMR can be programmed to generate one-shot, periodic, -or watchdog interrupts. - -Required properties: -- compatible : "nvidia,tegra210-timer". -- reg : Specifies base physical address and size of the registers. -- interrupts : A list of 14 interrupts; one per each timer channels 0 through - 13. -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - -timer@60005000 { - compatible = "nvidia,tegra210-timer"; - reg = <0x0 0x60005000 0x0 0x400>; - interrupts = , - , - , - , - , - , - , - , - , - , - , - , - , - ; - clocks = <&tegra_car TEGRA210_CLK_TIMER>; - clock-names = "timer"; -}; diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt b/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt deleted file mode 100644 index 1761f53ee36f..000000000000 --- a/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt +++ /dev/null @@ -1,28 +0,0 @@ -NVIDIA Tegra30 timer - -The Tegra30 timer provides ten 29-bit timer channels, a single 32-bit free -running counter, and 5 watchdog modules. The first two channels may also -trigger a legacy watchdog reset. - -Required properties: - -- compatible : For Tegra30, must contain "nvidia,tegra30-timer". Otherwise, - must contain '"nvidia,-timer", "nvidia,tegra30-timer"' where - is tegra124 or tegra132. -- reg : Specifies base physical address and size of the registers. -- interrupts : A list of 6 interrupts; one per each of timer channels 1 - through 5, and one for the shared interrupt for the remaining channels. -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - -timer { - compatible = "nvidia,tegra30-timer", "nvidia,tegra20-timer"; - reg = <0x60005000 0x400>; - interrupts = <0 0 0x04 - 0 1 0x04 - 0 41 0x04 - 0 42 0x04 - 0 121 0x04 - 0 122 0x04>; - clocks = <&tegra_car 214>; -}; -- cgit From 2369f171d5c5550b85ce96fd35d4438cf2e6b09e Mon Sep 17 00:00:00 2001 From: Huang Shijie Date: Wed, 9 Feb 2022 09:26:42 +0000 Subject: arm64: crash_core: Export MODULES, VMALLOC, and VMEMMAP ranges The following interrelated ranges are needed by the kdump crash tool: MODULES_VADDR ~ MODULES_END, VMALLOC_START ~ VMALLOC_END, VMEMMAP_START ~ VMEMMAP_END Since these values change from time to time, it is preferable to export them via vmcoreinfo than to change the crash's code frequently. Signed-off-by: Huang Shijie Link: https://lore.kernel.org/r/20220209092642.9181-1-shijie@os.amperecomputing.com Signed-off-by: Will Deacon --- Documentation/admin-guide/kdump/vmcoreinfo.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst index 3861a25faae1..a339af45a22e 100644 --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst @@ -494,6 +494,14 @@ architecture which is used to lookup the page-tables for the Virtual addresses in the higher VA range (refer to ARMv8 ARM document for more details). +MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END +------------- + +Used to get the correct ranges: + MODULES_VADDR ~ MODULES_END-1 : Kernel module space. + VMALLOC_START ~ VMALLOC_END-1 : vmalloc() / ioremap() space. + VMEMMAP_START ~ VMEMMAP_END-1 : vmemmap region, used for struct page array. + arm === -- cgit From 24a147bcef8ca039cb75d6d4b68c7cc339b11178 Mon Sep 17 00:00:00 2001 From: Linu Cherian Date: Mon, 7 Mar 2022 20:00:14 +0530 Subject: irqchip/gic-v3: Workaround Marvell erratum 38545 when reading IAR When a IAR register read races with a GIC interrupt RELEASE event, GIC-CPU interface could wrongly return a valid INTID to the CPU for an interrupt that is already released(non activated) instead of 0x3ff. As a side effect, an interrupt handler could run twice, once with interrupt priority and then with idle priority. As a workaround, gic_read_iar is updated so that it will return a valid interrupt ID only if there is a change in the active priority list after the IAR read on all the affected Silicons. Since there are silicon variants where both 23154 and 38545 are applicable, workaround for erratum 23154 has been extended to address both of them. Signed-off-by: Linu Cherian Reviewed-by: Marc Zyngier Acked-by: Catalin Marinas Link: https://lore.kernel.org/r/20220307143014.22758-1-lcherian@marvell.com Signed-off-by: Will Deacon --- Documentation/arm64/silicon-errata.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst index ea281dd75517..466cb9e89047 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arm64/silicon-errata.rst @@ -136,7 +136,7 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 | +----------------+-----------------+-----------------+-----------------------------+ -| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 | +| Cavium | ThunderX GICv3 | #23154,38545 | CAVIUM_ERRATUM_23154 | +----------------+-----------------+-----------------+-----------------------------+ | Cavium | ThunderX GICv3 | #38539 | N/A | +----------------+-----------------+-----------------+-----------------------------+ -- cgit From a96f688b4e4466da39385368f47fc02a0409a367 Mon Sep 17 00:00:00 2001 From: Lee Jones Date: Thu, 10 Feb 2022 08:44:44 +0000 Subject: hwmon: sy7636a: Fix trivial 'underline too short' warning Documentation/hwmon/sy7636a-hwmon.rst:4: WARNING: Title underline too short. Kernel driver sy7636a-hwmon ========================= Acked-by: Guenter Roeck Signed-off-by: Lee Jones Link: https://lore.kernel.org/all/YgTRu7iLgJMymeT5@google.com/ --- Documentation/hwmon/sy7636a-hwmon.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/sy7636a-hwmon.rst b/Documentation/hwmon/sy7636a-hwmon.rst index 5612079397d5..c85db7b32941 100644 --- a/Documentation/hwmon/sy7636a-hwmon.rst +++ b/Documentation/hwmon/sy7636a-hwmon.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0-or-later Kernel driver sy7636a-hwmon -========================= +=========================== Supported chips: -- cgit From 2a6bacf79b3ae3616393e4b9a0fc623e269e506f Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Wed, 12 Jan 2022 20:40:52 +0100 Subject: dt-bindings: mfd: qcom,tcsr: Document msm8953 compatible Document the compatible for tcsr found in msm8953. Signed-off-by: Luca Weiss Acked-by: Konrad Dybcio Acked-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220112194118.178026-4-luca@z3ntu.xyz --- Documentation/devicetree/bindings/mfd/qcom,tcsr.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt b/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt index c5f4f0ddfcc3..add61bcc3c74 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt +++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt @@ -10,6 +10,7 @@ Required properties: "qcom,tcsr-ipq8064", "syscon" for IPQ8064 "qcom,tcsr-apq8064", "syscon" for APQ8064 "qcom,tcsr-msm8660", "syscon" for MSM8660 + "qcom,tcsr-msm8953", "syscon" for MSM8953 "qcom,tcsr-msm8960", "syscon" for MSM8960 "qcom,tcsr-msm8974", "syscon" for MSM8974 "qcom,tcsr-apq8084", "syscon" for APQ8084 -- cgit From c3a0dcd8f5668e45a9e8a91b80f4ab99bbe21e78 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Wed, 12 Jan 2022 20:40:53 +0100 Subject: mfd: qcom-spmi-pmic: Add pm8953 compatible Document the compatible for pm8953 as found in msm8953. Signed-off-by: Luca Weiss Acked-by: Konrad Dybcio Acked-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220112194118.178026-5-luca@z3ntu.xyz --- Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt index 7a27c500ff63..a461ec2f758f 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt @@ -35,6 +35,7 @@ Required properties: "qcom,pm8916", "qcom,pm8941", "qcom,pm8950", + "qcom,pm8953", "qcom,pm8994", "qcom,pm8998", "qcom,pma8084", -- cgit From a002f65ab409608b643c79bf6417bd453b64a55f Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Sat, 15 Jan 2022 01:26:49 +0100 Subject: mfd: ab8500: Rewrite bindings in YAML This rewrites the former text based AB8500 bindings in YAML. When the AB8500 bindings were first written (in 2012) we were not strict on some things and node names were definitely not standardized. This patch uses standard node names to most of the subnodes on the AB8500 and is accompanied by another patch fixing all the DTS files to conform to this. The bindings are not as perfect as newly written bindings would be, it is a best effort to deal with the legacy. Cc: devicetree@vger.kernel.org Signed-off-by: Linus Walleij Reviewed-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220115002649.1526163-1-linus.walleij@linaro.org --- Documentation/devicetree/bindings/mfd/ab8500.txt | 282 ------------ .../devicetree/bindings/mfd/stericsson,ab8500.yaml | 500 +++++++++++++++++++++ .../bindings/mfd/stericsson,db8500-prcmu.yaml | 1 + 3 files changed, 501 insertions(+), 282 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mfd/ab8500.txt create mode 100644 Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt b/Documentation/devicetree/bindings/mfd/ab8500.txt deleted file mode 100644 index 937b3e5505e0..000000000000 --- a/Documentation/devicetree/bindings/mfd/ab8500.txt +++ /dev/null @@ -1,282 +0,0 @@ -* AB8500 Multi-Functional Device (MFD) - -Required parent device properties: -- compatible : contains "stericsson,ab8500" or "stericsson,ab8505"; -- interrupts : contains the IRQ line for the AB8500 -- interrupt-controller : describes the AB8500 as an Interrupt Controller (has its own domain) -- #interrupt-cells : should be 2, for 2-cell format - - The first cell is the AB8500 local IRQ number - - The second cell is used to specify optional parameters - - bits[3:0] trigger type and level flags: - 1 = low-to-high edge triggered - 2 = high-to-low edge triggered - 4 = active high level-sensitive - 8 = active low level-sensitive - -The AB8500 consists of a large and varied group of sub-devices: - -Device IRQ Names Supply Names Description ------- --------- ------------ ----------- -ab8500-bm : : : Battery Manager -ab8500-btemp : : : Battery Temperature -ab8500-charger : : : Battery Charger -ab8500-codec : : : Audio Codec -ab8500-fg : : vddadc : Fuel Gauge - : NCONV_ACCU : : Accumulate N Sample Conversion - : BATT_OVV : : Battery Over Voltage - : LOW_BAT_F : : LOW threshold battery voltage - : CC_INT_CALIB : : Coulomb Counter Internal Calibration - : CCEOC : : Coulomb Counter End of Conversion -ab8500-btemp : : vtvout : Battery Temperature - : BAT_CTRL_INDB : : Battery Removal Indicator - : BTEMP_LOW : : Btemp < BtempLow, if battery temperature is lower than -10°C - : BTEMP_LOW_MEDIUM : : BtempLow < Btemp < BtempMedium,if battery temperature is between -10 and 0°C - : BTEMP_MEDIUM_HIGH : : BtempMedium < Btemp < BtempHigh,if battery temperature is between 0°C and MaxTemp - : BTEMP_HIGH : : Btemp > BtempHigh, if battery temperature is higher than MaxTemp -ab8500-charger : : vddadc : Charger interface - : MAIN_CH_UNPLUG_DET : : main charger unplug detection management (not in 8505) - : MAIN_CHARGE_PLUG_DET : : main charger plug detection management (not in 8505) - : MAIN_EXT_CH_NOT_OK : : main charger not OK - : MAIN_CH_TH_PROT_R : : Die temp is above main charger - : MAIN_CH_TH_PROT_F : : Die temp is below main charger - : VBUS_DET_F : : VBUS falling detected - : VBUS_DET_R : : VBUS rising detected - : USB_LINK_STATUS : : USB link status has changed - : USB_CH_TH_PROT_R : : Die temp is above usb charger - : USB_CH_TH_PROT_F : : Die temp is below usb charger - : USB_CHARGER_NOT_OKR : : allowed USB charger not ok detection - : VBUS_OVV : : Overvoltage on Vbus ball detected (USB charge is stopped) - : CH_WD_EXP : : Charger watchdog detected -ab8500-gpadc : HW_CONV_END : vddadc : Analogue to Digital Converter - SW_CONV_END : : -ab8500-gpio : : : GPIO Controller (AB8500) -ab8505-gpio : : : GPIO Controller (AB8505) -ab8500-ponkey : ONKEY_DBF : : Power-on Key - ONKEY_DBR : : -ab8500-pwm : : : Pulse Width Modulator -ab8500-regulator : : : Regulators (AB8500) -ab8505-regulator : : : Regulators (AB8505) -ab8500-rtc : 60S : : Real Time Clock - : ALARM : : -ab8500-sysctrl : : : System Control -ab8500-usb : ID_WAKEUP_R : vddulpivio18 : Universal Serial Bus - : ID_WAKEUP_F : v-ape : - : VBUS_DET_F : musb_1v8 : - : VBUS_DET_R : : - : USB_LINK_STATUS : : - : USB_ADP_PROBE_PLUG : : - : USB_ADP_PROBE_UNPLUG : : - -Required child device properties: -- compatible : "stericsson,ab8500-[bm|btemp|charger|fg|gpadc|gpio|ponkey| - pwm|regulator|rtc|sysctrl|usb]"; - - A few child devices require ADC channels from the GPADC node. Those follow the - standard bindings from - https://github.com/devicetree-org/dt-schema/blob/master/schemas/iio/iio-consumer.yaml - and Documentation/devicetree/bindings/iio/adc/adc.yaml - - abx500-temp : io-channels "aux1" and "aux2" for measuring external - temperatures. - ab8500-fg : io-channel "main_bat_v" for measuring main battery voltage, - ab8500-btemp : io-channels "btemp_ball" and "bat_ctrl" for measuring the - battery voltage. - ab8500-charger : io-channels "main_charger_v", "main_charger_c", "vbus_v", - "usb_charger_c" for measuring voltage and current of the - different charging supplies. - -Optional child device properties: -- interrupts : contains the device IRQ(s) using the 2-cell format (see above) -- interrupt-names : contains names of IRQ resource in the order in which they were - supplied in the interrupts property -- -supply : contains a phandle to the regulator supply node in Device Tree - -Non-standard child device properties: - - Audio CODEC: - - stericsson,amic[1|2]-type-single-ended : Single-ended Analoge Mic (default: differential) - - stericsson,amic1a-bias-vamic2 : Analoge Mic wishes to use a non-standard Vamic - - stericsson,amic1b-bias-vamic2 : Analoge Mic wishes to use a non-standard Vamic - - stericsson,amic2-bias-vamic1 : Analoge Mic wishes to use a non-standard Vamic - - stericsson,earpeice-cmv : Earpeice voltage (only: 950 | 1100 | 1270 | 1580) - -ab8500 { - compatible = "stericsson,ab8500"; - interrupts = <0 40 0x4>; - interrupt-controller; - #interrupt-cells = <2>; - - ab8500-rtc { - compatible = "stericsson,ab8500-rtc"; - interrupts = <17 0x4 - 18 0x4>; - interrupt-names = "60S", "ALARM"; - }; - - ab8500-gpadc { - compatible = "stericsson,ab8500-gpadc"; - interrupts = <32 0x4 - 39 0x4>; - interrupt-names = "HW_CONV_END", "SW_CONV_END"; - vddadc-supply = <&ab8500_ldo_tvout_reg>; - #address-cells = <1>; - #size-cells = <0>; - #io-channel-cells = <1>; - - /* GPADC channels */ - bat_ctrl: channel@1 { - reg = <0x01>; - }; - btemp_ball: channel@2 { - reg = <0x02>; - }; - main_charger_v: channel@3 { - reg = <0x03>; - }; - acc_detect1: channel@4 { - reg = <0x04>; - }; - acc_detect2: channel@5 { - reg = <0x05>; - }; - adc_aux1: channel@6 { - reg = <0x06>; - }; - adc_aux2: channel@7 { - reg = <0x07>; - }; - main_batt_v: channel@8 { - reg = <0x08>; - }; - vbus_v: channel@9 { - reg = <0x09>; - }; - main_charger_c: channel@a { - reg = <0x0a>; - }; - usb_charger_c: channel@b { - reg = <0x0b>; - }; - bk_bat_v: channel@c { - reg = <0x0c>; - }; - die_temp: channel@d { - reg = <0x0d>; - }; - usb_id: channel@e { - reg = <0x0e>; - }; - xtal_temp: channel@12 { - reg = <0x12>; - }; - vbat_true_meas: channel@13 { - reg = <0x13>; - }; - bat_ctrl_and_ibat: channel@1c { - reg = <0x1c>; - }; - vbat_meas_and_ibat: channel@1d { - reg = <0x1d>; - }; - vbat_true_meas_and_ibat: channel@1e { - reg = <0x1e>; - }; - bat_temp_and_ibat: channel@1f { - reg = <0x1f>; - }; - }; - - ab8500_temp { - compatible = "stericsson,abx500-temp"; - io-channels = <&gpadc 0x06>, - <&gpadc 0x07>; - io-channel-name = "aux1", "aux2"; - }; - - ab8500_battery: ab8500_battery { - stericsson,battery-type = "LIPO"; - thermistor-on-batctrl; - }; - - ab8500_fg { - compatible = "stericsson,ab8500-fg"; - battery = <&ab8500_battery>; - io-channels = <&gpadc 0x08>; - io-channel-name = "main_bat_v"; - }; - - ab8500_btemp { - compatible = "stericsson,ab8500-btemp"; - battery = <&ab8500_battery>; - io-channels = <&gpadc 0x02>, - <&gpadc 0x01>; - io-channel-name = "btemp_ball", - "bat_ctrl"; - }; - - ab8500_charger { - compatible = "stericsson,ab8500-charger"; - battery = <&ab8500_battery>; - vddadc-supply = <&ab8500_ldo_tvout_reg>; - io-channels = <&gpadc 0x03>, - <&gpadc 0x0a>, - <&gpadc 0x09>, - <&gpadc 0x0b>; - io-channel-name = "main_charger_v", - "main_charger_c", - "vbus_v", - "usb_charger_c"; - }; - - ab8500-usb { - compatible = "stericsson,ab8500-usb"; - interrupts = < 90 0x4 - 96 0x4 - 14 0x4 - 15 0x4 - 79 0x4 - 74 0x4 - 75 0x4>; - interrupt-names = "ID_WAKEUP_R", - "ID_WAKEUP_F", - "VBUS_DET_F", - "VBUS_DET_R", - "USB_LINK_STATUS", - "USB_ADP_PROBE_PLUG", - "USB_ADP_PROBE_UNPLUG"; - vddulpivio18-supply = <&ab8500_ldo_intcore_reg>; - v-ape-supply = <&db8500_vape_reg>; - musb_1v8-supply = <&db8500_vsmps2_reg>; - }; - - ab8500-ponkey { - compatible = "stericsson,ab8500-ponkey"; - interrupts = <6 0x4 - 7 0x4>; - interrupt-names = "ONKEY_DBF", "ONKEY_DBR"; - }; - - ab8500-sysctrl { - compatible = "stericsson,ab8500-sysctrl"; - }; - - ab8500-pwm { - compatible = "stericsson,ab8500-pwm"; - }; - - codec: ab8500-codec { - compatible = "stericsson,ab8500-codec"; - - stericsson,earpeice-cmv = <950>; /* Units in mV. */ - }; - - ab8500-regulators { - compatible = "stericsson,ab8500-regulator"; - - ab8500_ldo_aux1_reg: ab8500_ldo_aux1 { - /* - * See: Documentation/devicetree/bindings/regulator/regulator.txt - * for more information on regulators - */ - }; - }; -}; diff --git a/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml b/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml new file mode 100644 index 000000000000..623a4b5cd27a --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml @@ -0,0 +1,500 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/stericsson,ab8500.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ST-Ericsson Analog Baseband AB8500 and AB8505 + +maintainers: + - Linus Walleij + +description: + the AB8500 "Analog Baseband" is the mixed-signals integrated circuit + handling power management (regulators), analog-to-digital conversion + (ADC), battery charging, fuel gauging of the battery, battery-backed + RTC, PWM, USB PHY and some GPIO lines in the ST-Ericsson U8500 platforms + in connection with the DB8500 digital baseband. The DB8500 PRCMU + communicates directly and autonomously with the AB8500 and thus it + appears as a subnode of the DB8500 PRCMU. An altered version called + AB8505 also exist, the difference in AB8505 is that some of the USB and + USB charging handling has changed, and it has an embedded USB-to-serial + converter. Most subblocks takes their interrupts directly from the + AB8500 embedded interrupt controller. + +properties: + $nodename: + pattern: '^ab850[05]$' + + compatible: + enum: + - stericsson,ab8500 + - stericsson,ab8505 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + # Some subnodes use a reg, some don't. Those that do use a single cell. + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + clock-controller: + description: Node describing the AB8500 clock controller. This + provides the reference clock for the entire U8500 system and + the DB8500 counterpart. + type: object + + properties: + compatible: + const: stericsson,ab8500-clk + + '#clock-cells': + const: 1 + + gpio: + description: Node describing the AB8500 GPIO controller. A few + GPIO pins available for misc usage. + type: object + + properties: + compatible: + enum: + - stericsson,ab8500-gpio + - stericsson,ab8505-gpio + + gpio-controller: true + + '#gpio-cells': + const: 2 + + rtc: + description: Node describing the AB8500 battery-backed RTC. + type: object + + properties: + compatible: + const: stericsson,ab8500-rtc + + interrupts: + items: + - description: 60 second interval alarm interrupt + - description: RTC alarm + + interrupt-names: + items: + - const: 60S + - const: ALARM + + adc: + description: Node describing the AB8500 general purpose analog to digital + converter, GPADC. + type: object + + properties: + compatible: + const: stericsson,ab8500-gpadc + + # AB8505 only supports one (software) EOC interrupt + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: true + + vddadc-supply: true + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + '#io-channel-cells': + const: 1 + + patternProperties: + "^channel@[0-9a-f]+$": + type: object + $ref: ../iio/adc/adc.yaml# + description: Represents each of the external channels which are + connected to the ADC. + + properties: + reg: + items: + minimum: 1 + maximum: 31 + + required: + - reg + + additionalProperties: false + + required: + - compatible + - interrupts + - interrupt-names + - vddadc-supply + - '#address-cells' + - '#size-cells' + - '#io-channel-cells' + + additionalProperties: false + + thermal: + description: Node describing the AB8500 thermal control block. All this block + really does is to fire an interrupt when the die becomes 130 degrees Celsius + in temperature. + type: object + + properties: + compatible: + const: stericsson,abx500-temp + + interrupts: + items: + - description: Thermal warm warning interrupt + + interrupt-names: + items: + - const: ABX500_TEMP_WARM + + required: + - compatible + - interrupts + - interrupt-names + + additionalProperties: false + + ab8500_fg: + description: Node describing the AB8500 fuel gauge control block. + type: object + $ref: ../power/supply/stericsson,ab8500-fg.yaml + + ab8500_btemp: + description: Node describing the AB8500 battery temperature control block. + type: object + $ref: ../power/supply/stericsson,ab8500-btemp.yaml + + ab8500_charger: + description: Node describing the AB8500 battery charger control block. + type: object + $ref: ../power/supply/stericsson,ab8500-charger.yaml + + ab8500_chargalg: + description: Node describing the AB8500 battery charger algorithm. + type: object + $ref: ../power/supply/stericsson,ab8500-chargalg.yaml + + phy: + description: Node describing the AB8500 USB PHY control block. + type: object + + properties: + compatible: + const: stericsson,ab8500-usb + + interrupts: + items: + - description: ID wakeup rising IRQ + - description: ID wakeup falling IRQ + - description: VBUS detection falling IRQ + - description: VBUS detection rising IRQ + - description: USB link status change IRQ + - description: ADP probe plug IRQ + - description: ADP probe unplug IRQ + + interrupt-names: + items: + - const: ID_WAKEUP_R + - const: ID_WAKEUP_F + - const: VBUS_DET_F + - const: VBUS_DET_R + - const: USB_LINK_STATUS + - const: USB_ADP_PROBE_PLUG + - const: USB_ADP_PROBE_UNPLUG + + vddulpivio18-supply: true + v-ape-supply: true + musb_1v8-supply: true + + clocks: + items: + - description: PRCMY system clock + + clock-names: + items: + - const: sysclk + + '#phy-cells': + const: 0 + + required: + - compatible + - interrupts + - interrupt-names + - vddulpivio18-supply + - v-ape-supply + - musb_1v8-supply + - clocks + - clock-names + - '#phy-cells' + + additionalProperties: false + + key: + description: Node describing the AB8500 power-on key control block. + type: object + + properties: + compatible: + const: stericsson,ab8500-poweron-key + + interrupts: + items: + - description: ON key falling IRQ + - description: ON key rising IRQ + + interrupt-names: + items: + - const: ONKEY_DBF + - const: ONKEY_DBR + + required: + - compatible + - interrupts + - interrupt-names + + additionalProperties: false + + ab8500-sysctrl: + description: Node describing the AB8500 system control block. + type: object + + properties: + compatible: + const: stericsson,ab8500-sysctrl + + required: + - compatible + + additionalProperties: false + + codec: + description: Node describing the AB8500 audio codec block. + type: object + + properties: + compatible: + const: stericsson,ab8500-codec + + V-AUD-supply: true + V-AMIC1-supply: true + V-AMIC2-supply: true + V-DMIC-supply: true + + clocks: + items: + - description: Audio system clock + + clock-names: + items: + - const: audioclk + + stericsson,earpeice-cmv: + description: Earpeice voltage + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 950, 1100, 1270, 1580 ] + + required: + - compatible + + additionalProperties: false + + regulator: + description: Node describing the AB8500 internal regulators. + type: object + + properties: + compatible: + enum: + - stericsson,ab8500-regulator + - stericsson,ab8505-regulator + + vin-supply: + description: The regulator supplying all of the internal regulators + with power. + + ab8500_ldo_aux1: + description: The voltage for the auxilary LDO regulator 1 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_aux2: + description: The voltage for the auxilary LDO regulator 2 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_aux3: + description: The voltage for the auxilary LDO regulator 3 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_aux4: + description: The voltage for the auxilary LDO regulator 4 + only present on AB8505 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_aux5: + description: The voltage for the auxilary LDO regulator 5 + only present on AB8505 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_aux6: + description: The voltage for the auxilary LDO regulator 6 + only present on AB8505 + type: object + $ref: ../regulator/regulator.yaml# + + # There is never any AUX7 regulator which is confusing + + ab8500_ldo_aux8: + description: The voltage for the auxilary LDO regulator 8 + only present on AB8505 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_intcore: + description: The LDO regulator for the internal core voltage + of the AB8500 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_adc: + description: Analog power regulator for the analog to digital converter + ADC, only present on AB8505 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_tvout: + description: The voltage for the TV output regulator, incidentally + this voltage is also used for other purposes such as measuring + the temperature of the NTC thermistor on the battery. + Only present on AB8500. + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_audio: + description: The LDO regulator for the audio codec output + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_anamic1: + description: The LDO regulator for the analog microphone 1 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_anamic2: + description: The LDO regulator for the analog microphone 2 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_dmic: + description: The LDO regulator for the digital microphone + only present on AB8500 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_ana: + description: Analog power regulator for CSI and DSI interfaces, + Camera Serial Interface CSI and Display Serial Interface DSI. + type: object + $ref: ../regulator/regulator.yaml# + + required: + - compatible + + additionalProperties: false + + + regulator-external: + description: Node describing the AB8500 external regulators. This + concerns the autonomous regulators VSMPS1, VSMPS2 and VSMPS3 + that are normally controlled by external electronics but also + sometimes need to be explicitly controlled by software. + type: object + + properties: + compatible: + const: stericsson,ab8500-ext-regulator + + ab8500_ext1: + description: The voltage for the VSMPS1 external regulator + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ext2: + description: The voltage for the VSMPS2 external regulator + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ext3: + description: The voltage for the VSMPS3 external regulator + type: object + $ref: ../regulator/regulator.yaml# + + required: + - compatible + + additionalProperties: false + +patternProperties: + "^pwm@[1-9]+?$": + type: object + $ref: ../pwm/pwm.yaml# + description: Represents each of the PWM blocks in the AB8500 + + properties: + compatible: + const: stericsson,ab8500-pwm + + reg: true + + clocks: + items: + - description: internal clock + + clock-names: + items: + - const: intclk + + required: + - compatible + - reg + +required: + - compatible + - clock-controller + - gpio + - rtc + - adc + - thermal + - ab8500_fg + - ab8500_btemp + - ab8500_charger + - ab8500_chargalg + - phy + - key + - regulator + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml b/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml index a0d4bad5dc81..1d4d88f7e82d 100644 --- a/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml +++ b/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml @@ -263,6 +263,7 @@ patternProperties: set of devicetree bindings. The AB8505 is a newer version of the same ASIC. type: object + $ref: stericsson,ab8500.yaml# required: - compatible -- cgit From dab18d3be1bf8da00bad9a567cf5b91eb16bcb2c Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 2 Feb 2022 16:13:10 +0100 Subject: dt-bindings: mfd: samsung,exynos5433-lpass: Convert to dtschema Convert the Exynos5433 LPASS bindings to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220202151310.285561-4-krzysztof.kozlowski@canonical.com --- .../bindings/mfd/samsung,exynos5433-lpass.txt | 72 ------------- .../bindings/mfd/samsung,exynos5433-lpass.yaml | 117 +++++++++++++++++++++ 2 files changed, 117 insertions(+), 72 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt create mode 100644 Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt deleted file mode 100644 index 30ea27c3936d..000000000000 --- a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt +++ /dev/null @@ -1,72 +0,0 @@ -Samsung Exynos SoC Low Power Audio Subsystem (LPASS) - -Required properties: - - - compatible : "samsung,exynos5433-lpass" - - reg : should contain the LPASS top SFR region location - and size - - clock-names : should contain following required clocks: "sfr0_ctrl" - - clocks : should contain clock specifiers of all clocks, which - input names have been specified in clock-names - property, in same order. - - #address-cells : should be 1 - - #size-cells : should be 1 - - ranges : must be present - -Each IP block of the Low Power Audio Subsystem should be specified as -an optional sub-node. For "samsung,exynos5433-lpass" compatible this includes: -UART, SLIMBUS, PCM, I2S, DMAC, Timers 0...4, VIC, WDT 0...1 devices. - -Bindings of the sub-nodes are described in: - ../serial/samsung_uart.yaml - ../sound/samsung-i2s.txt - ../dma/arm-pl330.txt - - -Example: - -audio-subsystem { - compatible = "samsung,exynos5433-lpass"; - reg = <0x11400000 0x100>, <0x11500000 0x08>; - clocks = <&cmu_aud CLK_PCLK_SFR0_CTRL>; - clock-names = "sfr0_ctrl"; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - adma: adma@11420000 { - compatible = "arm,pl330", "arm,primecell"; - reg = <0x11420000 0x1000>; - interrupts = <0 73 0>; - clocks = <&cmu_aud CLK_ACLK_DMAC>; - clock-names = "apb_pclk"; - #dma-cells = <1>; - #dma-channels = <8>; - #dma-requests = <32>; - }; - - i2s0: i2s0@11440000 { - compatible = "samsung,exynos7-i2s"; - reg = <0x11440000 0x100>; - dmas = <&adma 0 &adma 2>; - dma-names = "tx", "rx"; - interrupts = <0 70 0>; - clocks = <&cmu_aud CLK_PCLK_AUD_I2S>, - <&cmu_aud CLK_SCLK_AUD_I2S>, - <&cmu_aud CLK_SCLK_I2S_BCLK>; - clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; - pinctrl-names = "default"; - pinctrl-0 = <&i2s0_bus>; - }; - - serial_3: serial@11460000 { - compatible = "samsung,exynos5433-uart"; - reg = <0x11460000 0x100>; - interrupts = <0 67 0>; - clocks = <&cmu_aud CLK_PCLK_AUD_UART>, - <&cmu_aud CLK_SCLK_AUD_UART>; - clock-names = "uart", "clk_uart_baud0"; - pinctrl-names = "default"; - pinctrl-0 = <&uart_aud_bus>; - }; - }; diff --git a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml new file mode 100644 index 000000000000..bae55c98961c --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/samsung,exynos5433-lpass.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC Low Power Audio Subsystem (LPASS) + +maintainers: + - Krzysztof Kozlowski + - Sylwester Nawrocki + +properties: + compatible: + const: samsung,exynos5433-lpass + + '#address-cells': + const: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: sfr0_ctrl + + power-domains: + maxItems: 1 + + ranges: true + + reg: + minItems: 2 + maxItems: 2 + + '#size-cells': + const: 1 + +patternProperties: + "^dma-controller@[0-9a-f]+$": + $ref: /schemas/dma/arm,pl330.yaml + + "^i2s@[0-9a-f]+$": + $ref: /schemas/sound/samsung-i2s.yaml + + "^serial@[0-9a-f]+$": + $ref: /schemas/serial/samsung_uart.yaml + +required: + - compatible + - '#address-cells' + - clocks + - clock-names + - ranges + - reg + - '#size-cells' + +additionalProperties: false + +examples: + - | + #include + #include + + audio-subsystem@11400000 { + compatible = "samsung,exynos5433-lpass"; + reg = <0x11400000 0x100>, <0x11500000 0x08>; + clocks = <&cmu_aud CLK_PCLK_SFR0_CTRL>; + clock-names = "sfr0_ctrl"; + power-domains = <&pd_aud>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + dma-controller@11420000 { + compatible = "arm,pl330", "arm,primecell"; + reg = <0x11420000 0x1000>; + interrupts = ; + clocks = <&cmu_aud CLK_ACLK_DMAC>; + clock-names = "apb_pclk"; + #dma-cells = <1>; + #dma-channels = <8>; + #dma-requests = <32>; + power-domains = <&pd_aud>; + }; + + i2s@11440000 { + compatible = "samsung,exynos7-i2s"; + reg = <0x11440000 0x100>; + dmas = <&adma 0>, <&adma 2>; + dma-names = "tx", "rx"; + interrupts = ; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&cmu_aud CLK_PCLK_AUD_I2S>, + <&cmu_aud CLK_SCLK_AUD_I2S>, + <&cmu_aud CLK_SCLK_I2S_BCLK>; + clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; + #clock-cells = <1>; + pinctrl-names = "default"; + pinctrl-0 = <&i2s0_bus>; + power-domains = <&pd_aud>; + #sound-dai-cells = <1>; + }; + + serial@11460000 { + compatible = "samsung,exynos5433-uart"; + reg = <0x11460000 0x100>; + interrupts = ; + clocks = <&cmu_aud CLK_PCLK_AUD_UART>, + <&cmu_aud CLK_SCLK_AUD_UART>; + clock-names = "uart", "clk_uart_baud0"; + pinctrl-names = "default"; + pinctrl-0 = <&uart_aud_bus>; + power-domains = <&pd_aud>; + }; + }; -- cgit From 49be1630558751186ffe612c3e111a8699ce6b53 Mon Sep 17 00:00:00 2001 From: Johnson Wang Date: Thu, 6 Jan 2022 14:54:06 +0800 Subject: dt-bindings: mfd: Add compatible for the MediaTek MT6366 PMIC This adds compatible for the MediaTek MT6366 PMIC. Signed-off-by: Johnson Wang Acked-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220106065407.16036-4-johnson.wang@mediatek.com --- Documentation/devicetree/bindings/mfd/mt6397.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt index 99a84b69a29f..293db2a71ef2 100644 --- a/Documentation/devicetree/bindings/mfd/mt6397.txt +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt @@ -20,7 +20,7 @@ This document describes the binding for MFD device and its sub module. Required properties: compatible: "mediatek,mt6323" for PMIC MT6323 - "mediatek,mt6358" for PMIC MT6358 + "mediatek,mt6358" for PMIC MT6358 and MT6366 "mediatek,mt6359" for PMIC MT6359 "mediatek,mt6397" for PMIC MT6397 -- cgit From 805bbdf28b271ed82b204cfd58b6eb456462ea49 Mon Sep 17 00:00:00 2001 From: Bharat Bhushan Date: Fri, 11 Feb 2022 10:23:43 +0530 Subject: dt-bindings: perf: marvell: cn10k ddr performance monitor Add binding documentation for the Marvell CN10k DDR performance monitor unit. Signed-off-by: Bharat Bhushan Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220211045346.17894-2-bbhushan2@marvell.com Signed-off-by: Will Deacon --- .../bindings/perf/marvell-cn10k-ddr.yaml | 37 ++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn10k-ddr.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/perf/marvell-cn10k-ddr.yaml b/Documentation/devicetree/bindings/perf/marvell-cn10k-ddr.yaml new file mode 100644 index 000000000000..a18dd0a8c43a --- /dev/null +++ b/Documentation/devicetree/bindings/perf/marvell-cn10k-ddr.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/perf/marvell-cn10k-ddr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell CN10K DDR performance monitor + +maintainers: + - Bharat Bhushan + +properties: + compatible: + items: + - enum: + - marvell,cn10k-ddr-pmu + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + + pmu@87e1c0000000 { + compatible = "marvell,cn10k-ddr-pmu"; + reg = <0x87e1 0xc0000000 0x0 0x10000>; + }; + }; -- cgit From 07b58d61275ebbb39b678d18f7c4e472050b13eb Mon Sep 17 00:00:00 2001 From: Matthew Auld Date: Tue, 8 Feb 2022 15:12:28 +0000 Subject: drm/doc: pull in drm_buddy.c MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Make sure we pull in the kernel-doc for this. Reported-by: Daniel Vetter Signed-off-by: Matthew Auld Cc: Arunpravin Cc: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20220208151228.344997-1-matthew.auld@intel.com Signed-off-by: Christian König Reviewed-by: Christian König --- Documentation/gpu/drm-mm.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 198bcc1affa1..f32ccce5722d 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -466,6 +466,15 @@ DRM MM Range Allocator Function References .. kernel-doc:: drivers/gpu/drm/drm_mm.c :export: +DRM Buddy Allocator +=================== + +DRM Buddy Function References +----------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_buddy.c + :export: + DRM Cache Handling and Fast WC memcpy() ======================================= -- cgit From 015044e9610c8523794ea6cb55d5388bc00ba96a Mon Sep 17 00:00:00 2001 From: Codrin Ciubotariu Date: Mon, 7 Mar 2022 14:21:58 +0200 Subject: ASoC: dt-bindings: Document Microchip's PDMC Add DT bindings for the new Microchip PDMC embedded in sama7g5 SoCs. Signed-off-by: Codrin Ciubotariu Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220307122202.2251639-3-codrin.ciubotariu@microchip.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/microchip,pdmc.yaml | 100 +++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/microchip,pdmc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/microchip,pdmc.yaml b/Documentation/devicetree/bindings/sound/microchip,pdmc.yaml new file mode 100644 index 000000000000..04414eb4ada9 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/microchip,pdmc.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/microchip,pdmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip Pulse Density Microphone Controller + +maintainers: + - Codrin Ciubotariu + +description: + The Microchip Pulse Density Microphone Controller (PDMC) interfaces up to 4 + digital microphones having Pulse Density Modulated (PDM) outputs. + +properties: + compatible: + const: microchip,sama7g5-pdmc + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Peripheral Bus Clock + - description: Generic Clock + + clock-names: + items: + - const: pclk + - const: gclk + + dmas: + description: RX DMA Channel + maxItems: 1 + + dma-names: + const: rx + + microchip,mic-pos: + description: | + Position of PDM microphones on the DS line and the sampling edge (rising + or falling) of the CLK line. A microphone is represented as a pair of DS + line and the sampling edge. The first microphone is mapped to channel 0, + the second to channel 1, etc. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: value for DS line + - description: value for sampling edge + anyOf: + - enum: + - [0, 0] + - [0, 1] + - [1, 0] + - [1, 1] + minItems: 1 + maxItems: 4 + uniqueItems: true + +required: + - compatible + - reg + - "#sound-dai-cells" + - interrupts + - clocks + - clock-names + - dmas + - dma-names + - microchip,mic-pos + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + + pdmc: sound@e1608000 { + compatible = "microchip,sama7g5-pdmc"; + reg = <0xe1608000 0x4000>; + #sound-dai-cells = <0>; + interrupts = ; + dmas = <&dma0 AT91_XDMAC_DT_PERID(37)>; + dma-names = "rx"; + clocks = <&pmc PMC_TYPE_PERIPHERAL 68>, <&pmc PMC_TYPE_GCK 68>; + clock-names = "pclk", "gclk"; + microchip,mic-pos = , + , + , + ; + }; -- cgit From 5b05198b3108d5d287da8c457183855fb91ae4cc Mon Sep 17 00:00:00 2001 From: Sergiu Moga Date: Fri, 4 Mar 2022 18:11:58 +0200 Subject: dt-bindings: rtc: convert at91sam9 bindings to json-schema Convert RTC binding for Atmel/Microchip SoCs to Device Tree Schema format. Signed-off-by: Sergiu Moga Reviewed-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220304161159.147784-4-sergiu.moga@microchip.com --- .../devicetree/bindings/rtc/atmel,at91sam9-rtc.txt | 25 --------- .../bindings/rtc/atmel,at91sam9-rtc.yaml | 65 ++++++++++++++++++++++ 2 files changed, 65 insertions(+), 25 deletions(-) delete mode 100644 Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.txt create mode 100644 Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.txt b/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.txt deleted file mode 100644 index 3f0e2a5950eb..000000000000 --- a/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.txt +++ /dev/null @@ -1,25 +0,0 @@ -Atmel AT91SAM9260 Real Time Timer - -Required properties: -- compatible: should be one of the following: - - "atmel,at91sam9260-rtt" - - "microchip,sam9x60-rtt", "atmel,at91sam9260-rtt" -- reg: should encode the memory region of the RTT controller -- interrupts: rtt alarm/event interrupt -- clocks: should contain the 32 KHz slow clk that will drive the RTT block. -- atmel,rtt-rtc-time-reg: should encode the GPBR register used to store - the time base when the RTT is used as an RTC. - The first cell should point to the GPBR node and the second one - encode the offset within the GPBR block (or in other words, the - GPBR register used to store the time base). - - -Example: - -rtt@fffffd20 { - compatible = "atmel,at91sam9260-rtt"; - reg = <0xfffffd20 0x10>; - interrupts = <1 4 7>; - clocks = <&clk32k>; - atmel,rtt-rtc-time-reg = <&gpbr 0x0>; -}; diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.yaml b/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.yaml new file mode 100644 index 000000000000..d2452067bfe4 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/atmel,at91sam9-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel AT91 RTT Device Tree Bindings + +allOf: + - $ref: "rtc.yaml#" + +maintainers: + - Alexandre Belloni + +properties: + compatible: + oneOf: + - items: + - const: atmel,at91sam9260-rtt + - items: + - const: microchip,sam9x60-rtt + - const: atmel,at91sam9260-rtt + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + atmel,rtt-rtc-time-reg: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: Phandle to the GPBR node. + - description: Offset within the GPBR block. + description: + Should encode the GPBR register used to store the time base when the + RTT is used as an RTC. The first cell should point to the GPBR node + and the second one encodes the offset within the GPBR block (or in + other words, the GPBR register used to store the time base). + +required: + - compatible + - reg + - interrupts + - clocks + - atmel,rtt-rtc-time-reg + +unevaluatedProperties: false + +examples: + - | + #include + + rtc@fffffd20 { + compatible = "atmel,at91sam9260-rtt"; + reg = <0xfffffd20 0x10>; + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>; + clocks = <&clk32k>; + atmel,rtt-rtc-time-reg = <&gpbr 0x0>; + }; -- cgit From 64a6497017843fc23d4c18542bdd4cfcca7878c9 Mon Sep 17 00:00:00 2001 From: Sergiu Moga Date: Fri, 4 Mar 2022 18:11:59 +0200 Subject: dt-bindings: rtc: at91: Add SAMA7G5 compatible strings list Add compatible strings list for SAMA7G5. Signed-off-by: Sergiu Moga Reviewed-by: Krzysztof Kozlowski Reviewed-by: Tudor Ambarus Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220304161159.147784-5-sergiu.moga@microchip.com --- Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.yaml b/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.yaml index d2452067bfe4..e5c3c384e172 100644 --- a/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.yaml @@ -21,6 +21,10 @@ properties: - items: - const: microchip,sam9x60-rtt - const: atmel,at91sam9260-rtt + - items: + - const: microchip,sama7g5-rtt + - const: microchip,sam9x60-rtt + - const: atmel,at91sam9260-rtt reg: maxItems: 1 -- cgit From 8544073271d1cb8664d191a8e87dafb7e0407189 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 6 Mar 2022 12:11:14 +0100 Subject: dt-bindings: ufs: add common platform bindings Add bindings for common parts (platform) of Universal Flash Storage (UFS) Host Controllers in dtschema format. Include also the bindings directory in the UFS maintainers entry. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Alim Akhtar Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220306111125.116455-2-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/ufs/ufs-common.yaml | 82 ++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 Documentation/devicetree/bindings/ufs/ufs-common.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ufs/ufs-common.yaml b/Documentation/devicetree/bindings/ufs/ufs-common.yaml new file mode 100644 index 000000000000..47a4e9e1a775 --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/ufs-common.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ufs/ufs-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common properties for Universal Flash Storage (UFS) Host Controllers + +maintainers: + - Alim Akhtar + - Avri Altman + +properties: + clocks: true + + clock-names: true + + freq-table-hz: + items: + items: + - description: Minimum frequency for given clock in Hz + - description: Maximum frequency for given clock in Hz + description: | + Array of operating frequencies in Hz stored in the same order + as the clocks property. If this property is not defined or a value in the + array is "0" then it is assumed that the frequency is set by the parent + clock or a fixed rate clock source. + + interrupts: + maxItems: 1 + + lanes-per-direction: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2] + default: 2 + description: + Number of lanes available per direction. Note that it is assume same + number of lanes is used both directions at once. + + vdd-hba-supply: + description: + Phandle to UFS host controller supply regulator node. + + vcc-supply: + description: + Phandle to VCC supply regulator node. + + vccq-supply: + description: + Phandle to VCCQ supply regulator node. + + vccq2-supply: + description: + Phandle to VCCQ2 supply regulator node. + + vcc-supply-1p8: + type: boolean + description: + For embedded UFS devices, valid VCC range is 1.7-1.95V or 2.7-3.6V. This + boolean property when set, specifies to use low voltage range of + 1.7-1.95V. Note for external UFS cards this property is invalid and valid + VCC range is always 2.7-3.6V. + + vcc-max-microamp: + description: + Specifies max. load that can be drawn from VCC supply. + + vccq-max-microamp: + description: + Specifies max. load that can be drawn from VCCQ supply. + + vccq2-max-microamp: + description: + Specifies max. load that can be drawn from VCCQ2 supply. + +dependencies: + freq-table-hz: [ 'clocks' ] + +required: + - interrupts + +additionalProperties: true -- cgit From cebe22345fb8f92cd1ca4b5aafe63d77722e4a37 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 6 Mar 2022 12:11:15 +0100 Subject: dt-bindings: ufs: samsung,exynos-ufs: use common bindings Use common UFS bindings in Samsung Exynos UFS to cover generic/common properties in DTS. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Reviewed-by: Alim Akhtar Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220306111125.116455-3-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/ufs/samsung,exynos-ufs.yaml | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml index 95ac1c18334d..c949eb617313 100644 --- a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml @@ -11,12 +11,11 @@ maintainers: description: | Each Samsung UFS host controller instance should have its own node. - This binding define Samsung specific binding other then what is used - in the common ufshcd bindings - [1] Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt -properties: +allOf: + - $ref: ufs-common.yaml +properties: compatible: enum: - samsung,exynos7-ufs @@ -47,9 +46,6 @@ properties: - const: core_clk - const: sclk_unipro_main - interrupts: - maxItems: 1 - phys: maxItems: 1 @@ -67,13 +63,12 @@ properties: required: - compatible - reg - - interrupts - phys - phy-names - clocks - clock-names -additionalProperties: false +unevaluatedProperties: false examples: - | -- cgit From 1581355bd0edca670011ef15364cfa5326da36cd Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 6 Mar 2022 12:11:16 +0100 Subject: dt-bindings: ufs: cdns,ufshc: convert to dtschema Convert the Cadence Universal Flash Storage (UFS) Controlle to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220306111125.116455-4-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/ufs/cdns,ufshc.txt | 32 ---------- .../devicetree/bindings/ufs/cdns,ufshc.yaml | 68 ++++++++++++++++++++++ .../devicetree/bindings/ufs/ti,j721e-ufs.yaml | 7 +-- 3 files changed, 71 insertions(+), 36 deletions(-) delete mode 100644 Documentation/devicetree/bindings/ufs/cdns,ufshc.txt create mode 100644 Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ufs/cdns,ufshc.txt b/Documentation/devicetree/bindings/ufs/cdns,ufshc.txt deleted file mode 100644 index 02347b017abd..000000000000 --- a/Documentation/devicetree/bindings/ufs/cdns,ufshc.txt +++ /dev/null @@ -1,32 +0,0 @@ -* Cadence Universal Flash Storage (UFS) Controller - -UFS nodes are defined to describe on-chip UFS host controllers. -Each UFS controller instance should have its own node. -Please see the ufshcd-pltfrm.txt for a list of all available properties. - -Required properties: -- compatible : Compatible list, contains one of the following controllers: - "cdns,ufshc" - Generic CDNS HCI, - "cdns,ufshc-m31-16nm" - CDNS UFS HC + M31 16nm PHY - complemented with the JEDEC version: - "jedec,ufs-2.0" - -- reg : Address and length of the UFS register set. -- interrupts : One interrupt mapping. -- freq-table-hz : Clock frequency table. - See the ufshcd-pltfrm.txt for details. -- clocks : List of phandle and clock specifier pairs. -- clock-names : List of clock input name strings sorted in the same - order as the clocks property. "core_clk" is mandatory. - Depending on a type of a PHY, - the "phy_clk" clock can also be added, if needed. - -Example: - ufs@fd030000 { - compatible = "cdns,ufshc", "jedec,ufs-2.0"; - reg = <0xfd030000 0x10000>; - interrupts = <0 1 IRQ_TYPE_LEVEL_HIGH>; - freq-table-hz = <0 0>, <0 0>; - clocks = <&ufs_core_clk>, <&ufs_phy_clk>; - clock-names = "core_clk", "phy_clk"; - }; diff --git a/Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml b/Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml new file mode 100644 index 000000000000..d227dea368be --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ufs/cdns,ufshc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence Universal Flash Storage (UFS) Controller + +maintainers: + - Jan Kotas + +# Select only our matches, not all jedec,ufs-2.0 +select: + properties: + compatible: + contains: + enum: + - cdns,ufshc + - cdns,ufshc-m31-16nm + required: + - compatible + +allOf: + - $ref: ufs-common.yaml + +properties: + compatible: + items: + - enum: + - cdns,ufshc + # CDNS UFS HC + M31 16nm PHY + - cdns,ufshc-m31-16nm + - const: jedec,ufs-2.0 + + clocks: + minItems: 1 + maxItems: 3 + + clock-names: + minItems: 1 + items: + - const: core_clk + - const: phy_clk + - const: ref_clk + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - reg + +unevaluatedProperties: false + +examples: + - | + #include + + ufs@fd030000 { + compatible = "cdns,ufshc", "jedec,ufs-2.0"; + reg = <0xfd030000 0x10000>; + interrupts = ; + freq-table-hz = <0 0>, <0 0>; + clocks = <&ufs_core_clk>, <&ufs_phy_clk>; + clock-names = "core_clk", "phy_clk"; + }; diff --git a/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml b/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml index 4d13e6bc1c50..c5eca7735f76 100644 --- a/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml @@ -47,11 +47,10 @@ required: patternProperties: "^ufs@[0-9a-f]+$": - type: object + $ref: cdns,ufshc.yaml description: | - Cadence UFS controller node must be the child node. Refer - Documentation/devicetree/bindings/ufs/cdns,ufshc.txt for binding - documentation of child node + Cadence UFS controller node must be the child node. + unevaluatedProperties: false additionalProperties: false -- cgit From 578f116b7ad62c44306a1cde27cd0bc7873161f2 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 6 Mar 2022 12:11:17 +0100 Subject: dt-bindings: ufs: drop unused/old ufs-qcom PHY bindings The Qualcomm UFS PHY bindings are documented in bindings/phy/qcom,qmp-phy.yaml and the compatibles from separate file bindings/ufs/ufs-qcom.txt are not used at all. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Bjorn Andersson Reviewed-by: Rob Herring Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220306111125.116455-5-krzysztof.kozlowski@canonical.com --- Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 63 ---------------------- 1 file changed, 63 deletions(-) delete mode 100644 Documentation/devicetree/bindings/ufs/ufs-qcom.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt deleted file mode 100644 index fd59f93e9556..000000000000 --- a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt +++ /dev/null @@ -1,63 +0,0 @@ -* Qualcomm Technologies Inc Universal Flash Storage (UFS) PHY - -UFSPHY nodes are defined to describe on-chip UFS PHY hardware macro. -Each UFS PHY node should have its own node. - -To bind UFS PHY with UFS host controller, the controller node should -contain a phandle reference to UFS PHY node. - -Required properties: -- compatible : compatible list, contains one of the following - - "qcom,ufs-phy-qmp-20nm" for 20nm ufs phy, - "qcom,ufs-phy-qmp-14nm" for legacy 14nm ufs phy, - "qcom,msm8996-ufs-phy-qmp-14nm" for 14nm ufs phy - present on MSM8996 chipset. -- reg : should contain PHY register address space (mandatory), -- reg-names : indicates various resources passed to driver (via reg proptery) by name. - Required "reg-names" is "phy_mem". -- #phy-cells : This property shall be set to 0 -- vdda-phy-supply : phandle to main PHY supply for analog domain -- vdda-pll-supply : phandle to PHY PLL and Power-Gen block power supply -- clocks : List of phandle and clock specifier pairs -- clock-names : List of clock input name strings sorted in the same - order as the clocks property. "ref_clk_src", "ref_clk", - "tx_iface_clk" & "rx_iface_clk" are mandatory but - "ref_clk_parent" is optional - -Optional properties: -- vdda-phy-max-microamp : specifies max. load that can be drawn from phy supply -- vdda-pll-max-microamp : specifies max. load that can be drawn from pll supply -- vddp-ref-clk-supply : phandle to UFS device ref_clk pad power supply -- vddp-ref-clk-max-microamp : specifies max. load that can be drawn from this supply -- resets : specifies the PHY reset in the UFS controller - -Example: - - ufsphy1: ufsphy@fc597000 { - compatible = "qcom,ufs-phy-qmp-20nm"; - reg = <0xfc597000 0x800>; - reg-names = "phy_mem"; - #phy-cells = <0>; - vdda-phy-supply = <&pma8084_l4>; - vdda-pll-supply = <&pma8084_l12>; - vdda-phy-max-microamp = <50000>; - vdda-pll-max-microamp = <1000>; - clock-names = "ref_clk_src", - "ref_clk_parent", - "ref_clk", - "tx_iface_clk", - "rx_iface_clk"; - clocks = <&clock_rpm clk_ln_bb_clk>, - <&clock_gcc clk_pcie_1_phy_ldo >, - <&clock_gcc clk_ufs_phy_ldo>, - <&clock_gcc clk_gcc_ufs_tx_cfg_clk>, - <&clock_gcc clk_gcc_ufs_rx_cfg_clk>; - resets = <&ufshc 0>; - }; - - ufshc: ufshc@fc598000 { - #reset-cells = <1>; - ... - phys = <&ufsphy1>; - phy-names = "ufsphy"; - }; -- cgit From 462c5c0aa7989ea33fb4167daad0c0354b066f6b Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 6 Mar 2022 12:11:18 +0100 Subject: dt-bindings: ufs: qcom,ufs: convert to dtschema Convert the Qualcomm Universal Flash Storage (UFS) Controller to DT schema format. Except the conversion, add also properties already present in DTS: iommus, interconnects and power-domains. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220306111125.116455-6-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/ufs/qcom,ufs.yaml | 242 +++++++++++++++++++++ .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 90 -------- 2 files changed, 242 insertions(+), 90 deletions(-) create mode 100644 Documentation/devicetree/bindings/ufs/qcom,ufs.yaml delete mode 100644 Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml new file mode 100644 index 000000000000..5b3a2157f7e5 --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml @@ -0,0 +1,242 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ufs/qcom,ufs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Universal Flash Storage (UFS) Controller + +maintainers: + - Bjorn Andersson + - Andy Gross + +# Select only our matches, not all jedec,ufs-2.0 +select: + properties: + compatible: + contains: + const: qcom,ufshc + required: + - compatible + +properties: + compatible: + items: + - enum: + - qcom,msm8994-ufshc + - qcom,msm8996-ufshc + - qcom,msm8998-ufshc + - qcom,sdm845-ufshc + - qcom,sm8150-ufshc + - qcom,sm8250-ufshc + - qcom,sm8350-ufshc + - qcom,sm8450-ufshc + - const: qcom,ufshc + - const: jedec,ufs-2.0 + + clocks: + minItems: 8 + maxItems: 11 + + clock-names: + minItems: 8 + maxItems: 11 + + interconnects: + minItems: 2 + maxItems: 2 + + interconnect-names: + items: + - const: ufs-ddr + - const: cpu-ufs + + iommus: + minItems: 1 + maxItems: 2 + + phys: + maxItems: 1 + + phy-names: + items: + - const: ufsphy + + power-domains: + maxItems: 1 + + reg: + minItems: 1 + maxItems: 2 + + resets: + maxItems: 1 + + '#reset-cells': + const: 1 + + reset-names: + items: + - const: rst + + reset-gpios: + maxItems: 1 + description: + GPIO connected to the RESET pin of the UFS memory device. + +required: + - compatible + - reg + +allOf: + - $ref: ufs-common.yaml + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8998-ufshc + - qcom,sm8250-ufshc + - qcom,sm8350-ufshc + - qcom,sm8450-ufshc + then: + properties: + clocks: + minItems: 8 + maxItems: 8 + clock-names: + items: + - const: core_clk + - const: bus_aggr_clk + - const: iface_clk + - const: core_clk_unipro + - const: ref_clk + - const: tx_lane0_sync_clk + - const: rx_lane0_sync_clk + - const: rx_lane1_sync_clk + reg: + minItems: 1 + maxItems: 1 + + - if: + properties: + compatible: + contains: + enum: + - qcom,sdm845-ufshc + - qcom,sm8150-ufshc + then: + properties: + clocks: + minItems: 9 + maxItems: 9 + clock-names: + items: + - const: core_clk + - const: bus_aggr_clk + - const: iface_clk + - const: core_clk_unipro + - const: ref_clk + - const: tx_lane0_sync_clk + - const: rx_lane0_sync_clk + - const: rx_lane1_sync_clk + - const: ice_core_clk + reg: + minItems: 2 + maxItems: 2 + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8996-ufshc + then: + properties: + clocks: + minItems: 11 + maxItems: 11 + clock-names: + items: + - const: core_clk_src + - const: core_clk + - const: bus_clk + - const: bus_aggr_clk + - const: iface_clk + - const: core_clk_unipro_src + - const: core_clk_unipro + - const: core_clk_ice + - const: ref_clk + - const: tx_lane0_sync_clk + - const: rx_lane0_sync_clk + reg: + minItems: 1 + maxItems: 1 + + # TODO: define clock bindings for qcom,msm8994-ufshc + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + #include + #include + + soc { + #address-cells = <2>; + #size-cells = <2>; + + ufs@1d84000 { + compatible = "qcom,sm8450-ufshc", "qcom,ufshc", + "jedec,ufs-2.0"; + reg = <0 0x01d84000 0 0x3000>; + interrupts = ; + phys = <&ufs_mem_phy_lanes>; + phy-names = "ufsphy"; + lanes-per-direction = <2>; + #reset-cells = <1>; + resets = <&gcc GCC_UFS_PHY_BCR>; + reset-names = "rst"; + reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>; + + vcc-supply = <&vreg_l7b_2p5>; + vcc-max-microamp = <1100000>; + vccq-supply = <&vreg_l9b_1p2>; + vccq-max-microamp = <1200000>; + + power-domains = <&gcc UFS_PHY_GDSC>; + iommus = <&apps_smmu 0xe0 0x0>; + interconnects = <&aggre1_noc MASTER_UFS_MEM &mc_virt SLAVE_EBI1>, + <&gem_noc MASTER_APPSS_PROC &config_noc SLAVE_UFS_MEM_CFG>; + interconnect-names = "ufs-ddr", "cpu-ufs"; + + clock-names = "core_clk", + "bus_aggr_clk", + "iface_clk", + "core_clk_unipro", + "ref_clk", + "tx_lane0_sync_clk", + "rx_lane0_sync_clk", + "rx_lane1_sync_clk"; + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>, + <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>, + <&gcc GCC_UFS_PHY_AHB_CLK>, + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>, + <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>, + <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>, + <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>; + freq-table-hz = <75000000 300000000>, + <0 0>, + <0 0>, + <75000000 300000000>, + <75000000 300000000>, + <0 0>, + <0 0>, + <0 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt deleted file mode 100644 index d0fee78e6203..000000000000 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt +++ /dev/null @@ -1,90 +0,0 @@ -* Universal Flash Storage (UFS) Host Controller - -UFSHC nodes are defined to describe on-chip UFS host controllers. -Each UFS controller instance should have its own node. - -Required properties: -- compatible : must contain "jedec,ufs-1.1" or "jedec,ufs-2.0" - - For Qualcomm SoCs must contain, as below, an - SoC-specific compatible along with "qcom,ufshc" and - the appropriate jedec string: - "qcom,msm8994-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - "qcom,msm8996-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - "qcom,msm8998-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - "qcom,sdm845-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - "qcom,sm8150-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - "qcom,sm8250-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - "qcom,sm8350-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - "qcom,sm8450-ufshc", "qcom,ufshc", "jedec,ufs-2.0" -- interrupts : -- reg : - -Optional properties: -- phys : phandle to UFS PHY node -- phy-names : the string "ufsphy" when is found in a node, along - with "phys" attribute, provides phandle to UFS PHY node -- vdd-hba-supply : phandle to UFS host controller supply regulator node -- vcc-supply : phandle to VCC supply regulator node -- vccq-supply : phandle to VCCQ supply regulator node -- vccq2-supply : phandle to VCCQ2 supply regulator node -- vcc-supply-1p8 : For embedded UFS devices, valid VCC range is 1.7-1.95V - or 2.7-3.6V. This boolean property when set, specifies - to use low voltage range of 1.7-1.95V. Note for external - UFS cards this property is invalid and valid VCC range is - always 2.7-3.6V. -- vcc-max-microamp : specifies max. load that can be drawn from vcc supply -- vccq-max-microamp : specifies max. load that can be drawn from vccq supply -- vccq2-max-microamp : specifies max. load that can be drawn from vccq2 supply - -- clocks : List of phandle and clock specifier pairs -- clock-names : List of clock input name strings sorted in the same - order as the clocks property. - "ref_clk" indicates reference clock frequency. - UFS host supplies reference clock to UFS device and UFS device - specification allows host to provide one of the 4 frequencies (19.2 MHz, - 26 MHz, 38.4 MHz, 52MHz) for reference clock. This "ref_clk" entry is - parsed and used to update the reference clock setting in device. - Defaults to 26 MHz(as per specification) if not specified by host. -- freq-table-hz : Array of operating frequencies stored in the same - order as the clocks property. If this property is not - defined or a value in the array is "0" then it is assumed - that the frequency is set by the parent clock or a - fixed rate clock source. --lanes-per-direction : number of lanes available per direction - either 1 or 2. - Note that it is assume same number of lanes is used both - directions at once. If not specified, default is 2 lanes per direction. -- #reset-cells : Must be <1> for Qualcomm UFS controllers that expose - PHY reset from the UFS controller. -- resets : reset node register -- reset-names : describe reset node register, the "rst" corresponds to reset the whole UFS IP. -- reset-gpios : A phandle and gpio specifier denoting the GPIO connected - to the RESET pin of the UFS memory device. - -Note: If above properties are not defined it can be assumed that the supply -regulators or clocks are always on. - -Example: - ufshc@fc598000 { - compatible = "jedec,ufs-1.1"; - reg = <0xfc598000 0x800>; - interrupts = <0 28 0>; - - vdd-hba-supply = <&xxx_reg0>; - vcc-supply = <&xxx_reg1>; - vcc-supply-1p8; - vccq-supply = <&xxx_reg2>; - vccq2-supply = <&xxx_reg3>; - vcc-max-microamp = 500000; - vccq-max-microamp = 200000; - vccq2-max-microamp = 200000; - - clocks = <&core 0>, <&ref 0>, <&phy 0>, <&iface 0>; - clock-names = "core_clk", "ref_clk", "phy_clk", "iface_clk"; - freq-table-hz = <100000000 200000000>, <0 0>, <0 0>, <0 0>; - resets = <&reset 0 1>; - reset-names = "rst"; - phys = <&ufsphy1>; - phy-names = "ufsphy"; - #reset-cells = <1>; - }; -- cgit From 516075a230d4801222cf0d1b8c8534e73c81c16a Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 6 Mar 2022 12:11:19 +0100 Subject: dt-bindings: ufs: hisilicon,ufs: convert to dtschema Convert the HiSilicon Universal Flash Storage (UFS) Controller to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220306111125.116455-7-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/ufs/hisilicon,ufs.yaml | 90 ++++++++++++++++++++++ Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 42 ---------- 2 files changed, 90 insertions(+), 42 deletions(-) create mode 100644 Documentation/devicetree/bindings/ufs/hisilicon,ufs.yaml delete mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ufs/hisilicon,ufs.yaml b/Documentation/devicetree/bindings/ufs/hisilicon,ufs.yaml new file mode 100644 index 000000000000..4432bfa0cbc7 --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/hisilicon,ufs.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ufs/hisilicon,ufs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HiSilicon Universal Flash Storage (UFS) Controller + +maintainers: + - Li Wei + +# Select only our matches, not all jedec,ufs +select: + properties: + compatible: + contains: + enum: + - hisilicon,hi3660-ufs + - hisilicon,hi3670-ufs + required: + - compatible + +allOf: + - $ref: ufs-common.yaml + +properties: + compatible: + oneOf: + - items: + - const: hisilicon,hi3660-ufs + - const: jedec,ufs-1.1 + - items: + - enum: + - hisilicon,hi3670-ufs + - const: jedec,ufs-2.1 + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: ref_clk + - const: phy_clk + + reg: + items: + - description: UFS register address space + - description: UFS SYS CTRL register address space + + resets: + maxItems: 1 + + reset-names: + items: + - const: rst + +required: + - compatible + - reg + - resets + - reset-names + +unevaluatedProperties: false + +examples: + - | + #include + #include + + soc { + #address-cells = <2>; + #size-cells = <2>; + + ufs@ff3c0000 { + compatible = "hisilicon,hi3670-ufs", "jedec,ufs-2.1"; + reg = <0x0 0xff3c0000 0x0 0x1000>, + <0x0 0xff3e0000 0x0 0x1000>; + interrupt-parent = <&gic>; + interrupts = ; + clocks = <&crg_ctrl HI3670_CLK_GATE_UFSIO_REF>, + <&crg_ctrl HI3670_CLK_GATE_UFS_SUBSYS>; + clock-names = "ref_clk", "phy_clk"; + freq-table-hz = <0 0>, + <0 0>; + + resets = <&crg_rst 0x84 12>; + reset-names = "rst"; + }; + }; diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt deleted file mode 100644 index 0b83df1a5418..000000000000 --- a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt +++ /dev/null @@ -1,42 +0,0 @@ -* Hisilicon Universal Flash Storage (UFS) Host Controller - -UFS nodes are defined to describe on-chip UFS hardware macro. -Each UFS Host Controller should have its own node. - -Required properties: -- compatible : compatible list, contains one of the following - - "hisilicon,hi3660-ufs", "jedec,ufs-1.1" for hisi ufs - host controller present on Hi3660 chipset. - "hisilicon,hi3670-ufs", "jedec,ufs-2.1" for hisi ufs - host controller present on Hi3670 chipset. -- reg : should contain UFS register address space & UFS SYS CTRL register address, -- interrupts : interrupt number -- clocks : List of phandle and clock specifier pairs -- clock-names : List of clock input name strings sorted in the same - order as the clocks property. "ref_clk", "phy_clk" is optional -- freq-table-hz : Array of operating frequencies stored in the same - order as the clocks property. If this property is not - defined or a value in the array is "0" then it is assumed - that the frequency is set by the parent clock or a - fixed rate clock source. -- resets : describe reset node register -- reset-names : reset node register, the "rst" corresponds to reset the whole UFS IP. - -Example: - - ufs: ufs@ff3b0000 { - compatible = "hisilicon,hi3660-ufs", "jedec,ufs-1.1"; - /* 0: HCI standard */ - /* 1: UFS SYS CTRL */ - reg = <0x0 0xff3b0000 0x0 0x1000>, - <0x0 0xff3b1000 0x0 0x1000>; - interrupt-parent = <&gic>; - interrupts = ; - clocks = <&crg_ctrl HI3660_CLK_GATE_UFSIO_REF>, - <&crg_ctrl HI3660_CLK_GATE_UFSPHY_CFG>; - clock-names = "ref_clk", "phy_clk"; - freq-table-hz = <0 0>, <0 0>; - /* offset: 0x84; bit: 12 */ - resets = <&crg_rst 0x84 12>; - reset-names = "rst"; - }; -- cgit From 954c6010053ce387d50bed8fcd55cda701728f5e Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 6 Mar 2022 12:11:20 +0100 Subject: dt-bindings: ufs: mediatek,ufs: convert to dtschema Convert the Mediatek Universal Flash Storage (UFS) Controller to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220306111125.116455-8-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/ufs/mediatek,ufs.yaml | 67 ++++++++++++++++++++++ .../devicetree/bindings/ufs/ufs-mediatek.txt | 45 --------------- 2 files changed, 67 insertions(+), 45 deletions(-) create mode 100644 Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml delete mode 100644 Documentation/devicetree/bindings/ufs/ufs-mediatek.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml new file mode 100644 index 000000000000..32fd535a514a --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ufs/mediatek,ufs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek Universal Flash Storage (UFS) Controller + +maintainers: + - Stanley Chu + +allOf: + - $ref: ufs-common.yaml + +properties: + compatible: + enum: + - mediatek,mt8183-ufshci + - mediatek,mt8192-ufshci + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ufs + + phys: + maxItems: 1 + + reg: + maxItems: 1 + + vcc-supply: true + +required: + - compatible + - clocks + - clock-names + - phys + - reg + - vcc-supply + +unevaluatedProperties: false + +examples: + - | + #include + #include + + soc { + #address-cells = <2>; + #size-cells = <2>; + + ufs@ff3c0000 { + compatible = "mediatek,mt8183-ufshci"; + reg = <0 0x11270000 0 0x2300>; + interrupts = ; + phys = <&ufsphy>; + + clocks = <&infracfg_ao CLK_INFRA_UFS>; + clock-names = "ufs"; + freq-table-hz = <0 0>; + + vcc-supply = <&mt_pmic_vemc_ldo_reg>; + }; + }; diff --git a/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt deleted file mode 100644 index 63a953b672d2..000000000000 --- a/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt +++ /dev/null @@ -1,45 +0,0 @@ -* Mediatek Universal Flash Storage (UFS) Host Controller - -UFS nodes are defined to describe on-chip UFS hardware macro. -Each UFS Host Controller should have its own node. - -To bind UFS PHY with UFS host controller, the controller node should -contain a phandle reference to UFS M-PHY node. - -Required properties for UFS nodes: -- compatible : Compatible list, contains the following controller: - "mediatek,mt8183-ufshci" for MediaTek UFS host controller - present on MT8183 chipsets. - "mediatek,mt8192-ufshci" for MediaTek UFS host controller - present on MT8192 chipsets. -- reg : Address and length of the UFS register set. -- phys : phandle to m-phy. -- clocks : List of phandle and clock specifier pairs. -- clock-names : List of clock input name strings sorted in the same - order as the clocks property. "ufs" is mandatory. - "ufs": ufshci core control clock. -- freq-table-hz : Array of operating frequencies stored in the same - order as the clocks property. If this property is not - defined or a value in the array is "0" then it is assumed - that the frequency is set by the parent clock or a - fixed rate clock source. -- vcc-supply : phandle to VCC supply regulator node. - -Example: - - ufsphy: phy@11fa0000 { - ... - }; - - ufshci@11270000 { - compatible = "mediatek,mt8183-ufshci"; - reg = <0 0x11270000 0 0x2300>; - interrupts = ; - phys = <&ufsphy>; - - clocks = <&infracfg_ao INFRACFG_AO_UFS_CG>; - clock-names = "ufs"; - freq-table-hz = <0 0>; - - vcc-supply = <&mt_pmic_vemc_ldo_reg>; - }; -- cgit From f3e00820f51952bb75c4c2fd722d56e844e17c15 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 6 Mar 2022 12:11:21 +0100 Subject: dt-bindings: ufs: snps,tc-dwc-g210: convert to dtschema Convert the Synopsys Universal Flash Storage (UFS) Controller to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220306111125.116455-9-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/ufs/snps,tc-dwc-g210.yaml | 51 ++++++++++++++++++++++ .../devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt | 26 ----------- 2 files changed, 51 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/ufs/snps,tc-dwc-g210.yaml delete mode 100644 Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ufs/snps,tc-dwc-g210.yaml b/Documentation/devicetree/bindings/ufs/snps,tc-dwc-g210.yaml new file mode 100644 index 000000000000..671a70d95138 --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/snps,tc-dwc-g210.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ufs/snps,tc-dwc-g210.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare Universal Flash Storage (UFS) Controller + +maintainers: + - Li Wei + +# Select only our matches, not all jedec,ufs +select: + properties: + compatible: + contains: + enum: + - snps,dwc-ufshcd-1.40a + required: + - compatible + +allOf: + - $ref: ufs-common.yaml + +properties: + compatible: + items: + - enum: + - snps,g210-tc-6.00-20bit + - snps,g210-tc-6.00-40bit + - const: snps,dwc-ufshcd-1.40a + - const: jedec,ufs-2.0 + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + ufs@d0000000 { + compatible = "snps,g210-tc-6.00-40bit", + "snps,dwc-ufshcd-1.40a", + "jedec,ufs-2.0"; + reg = <0xd0000000 0x10000>; + interrupts = <24>; + }; diff --git a/Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt b/Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt deleted file mode 100644 index 71c0777960e9..000000000000 --- a/Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt +++ /dev/null @@ -1,26 +0,0 @@ -* Universal Flash Storage (UFS) DesignWare Host Controller - -DWC_UFS nodes are defined to describe on-chip UFS host controllers and MPHY. -Each UFS controller instance should have its own node. - -Required properties: -- compatible : compatible list must contain the PHY type & version: - "snps,g210-tc-6.00-20bit" - "snps,g210-tc-6.00-40bit" - complemented with the Controller IP version: - "snps,dwc-ufshcd-1.40a" - complemented with the JEDEC version: - "jedec,ufs-1.1" - "jedec,ufs-2.0" - -- reg : -- interrupts : - -Example for a setup using a 1.40a DWC Controller with a 6.00 G210 40-bit TC: - dwc-ufs@d0000000 { - compatible = "snps,g210-tc-6.00-40bit", - "snps,dwc-ufshcd-1.40a", - "jedec,ufs-2.0"; - reg = < 0xd0000000 0x10000 >; - interrupts = < 24 >; - }; -- cgit From 2594703044ad2ef7ea7d463bf2cf82a13f7fc266 Mon Sep 17 00:00:00 2001 From: Georgi Vlaev Date: Tue, 8 Mar 2022 15:44:54 +0200 Subject: regulator: Convert TPS62360 binding to json-schema Convert the TPS62360 regulator binding to DT schema format using json-schema. This also removes redundant "ti,enable-force-pwm" property from the example. The property description was removed from the original text binding file by commit 9a00630c3db8 ("regulator: tps62360: support force PWM mode via regulator mode"), but a reference to it remained in the example. Signed-off-by: Georgi Vlaev Reviewed-by: Krzysztof Kozlowski Reviewed-by: Laxman Dewangan Link: https://lore.kernel.org/r/20220308134454.14504-1-g-vlaev@ti.com Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/ti,tps62360.yaml | 98 ++++++++++++++++++++++ .../bindings/regulator/tps62360-regulator.txt | 44 ---------- 2 files changed, 98 insertions(+), 44 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/ti,tps62360.yaml delete mode 100644 Documentation/devicetree/bindings/regulator/tps62360-regulator.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml b/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml new file mode 100644 index 000000000000..12aeddedde05 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/ti,tps62360.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments TPS6236x Voltage Regulators + +maintainers: + - Laxman Dewangan + +description: | + The TPS6236x are a family of step down dc-dc converter with + an input voltage range of 2.5V to 5.5V. The devices provide + up to 3A peak load current, and an output voltage range of + 0.77V to 1.4V (TPS62360/62) and 0.5V to 1.77V (TPS62361B/63). + + Datasheet is available at: + https://www.ti.com/lit/gpn/tps62360 + +allOf: + - $ref: "regulator.yaml#" + +properties: + compatible: + enum: + - ti,tps62360 + - ti,tps62361 + - ti,tps62362 + - ti,tps62363 + + reg: + maxItems: 1 + + ti,vsel0-gpio: + description: | + GPIO for controlling VSEL0 line. If this property + is missing, then assume that there is no GPIO for + VSEL0 control. + maxItems: 1 + + ti,vsel1-gpio: + description: | + GPIO for controlling VSEL1 line. If this property + is missing, then assume that there is no GPIO for + VSEL1 control. + maxItems: 1 + + ti,enable-vout-discharge: + description: Enable output discharge. + type: boolean + + ti,enable-pull-down: + description: Enable pull down. + type: boolean + + ti,vsel0-state-high: + description: | + Initial state of VSEL0 input is high. If this property + is missing, then assume the state as low. + type: boolean + + ti,vsel1-state-high: + description: | + Initial state of VSEL1 input is high. If this property + is missing, then assume the state as low. + type: boolean + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@60 { + compatible = "ti,tps62361"; + reg = <0x60>; + regulator-name = "tps62361-vout"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on; + ti,vsel0-gpio = <&gpio1 16 GPIO_ACTIVE_HIGH>; + ti,vsel1-gpio = <&gpio1 17 GPIO_ACTIVE_HIGH>; + ti,vsel0-state-high; + ti,vsel1-state-high; + ti,enable-pull-down; + ti,enable-vout-discharge; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt b/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt deleted file mode 100644 index 1b20c3dbcdb8..000000000000 --- a/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt +++ /dev/null @@ -1,44 +0,0 @@ -TPS62360 Voltage regulators - -Required properties: -- compatible: Must be one of the following. - "ti,tps62360" - "ti,tps62361", - "ti,tps62362", - "ti,tps62363", -- reg: I2C slave address - -Optional properties: -- ti,enable-vout-discharge: Enable output discharge. This is boolean value. -- ti,enable-pull-down: Enable pull down. This is boolean value. -- ti,vsel0-gpio: GPIO for controlling VSEL0 line. - If this property is missing, then assume that there is no GPIO - for vsel0 control. -- ti,vsel1-gpio: Gpio for controlling VSEL1 line. - If this property is missing, then assume that there is no GPIO - for vsel1 control. -- ti,vsel0-state-high: Initial state of vsel0 input is high. - If this property is missing, then assume the state as low (0). -- ti,vsel1-state-high: Initial state of vsel1 input is high. - If this property is missing, then assume the state as low (0). - -Any property defined as part of the core regulator binding, defined in -regulator.txt, can also be used. - -Example: - - abc: tps62360 { - compatible = "ti,tps62361"; - reg = <0x60>; - regulator-name = "tps62361-vout"; - regulator-min-microvolt = <500000>; - regulator-max-microvolt = <1500000>; - regulator-boot-on - ti,vsel0-gpio = <&gpio1 16 0>; - ti,vsel1-gpio = <&gpio1 17 0>; - ti,vsel0-state-high; - ti,vsel1-state-high; - ti,enable-pull-down; - ti,enable-force-pwm; - ti,enable-vout-discharge; - }; -- cgit From 363d3c51bc5b3243b5b035a1f50d6d994a1b203f Mon Sep 17 00:00:00 2001 From: Alim Akhtar Date: Tue, 8 Mar 2022 17:46:39 +0530 Subject: spi: dt-bindings: samsung: Add fsd spi compatible Adds spi controller dt-binding compatible information for Tesla Full Self-Driving (FSD) SoC. Cc: linux-fsd@tesla.com Signed-off-by: Adithya K V Signed-off-by: Alim Akhtar Reviewed-by: Krzysztof Kozlowski Reviewed-by: Andi Shyti Link: https://lore.kernel.org/r/20220308121640.27344-1-alim.akhtar@samsung.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/samsung,spi.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/samsung,spi.yaml b/Documentation/devicetree/bindings/spi/samsung,spi.yaml index 61c77088e8ee..bf9a76d931d2 100644 --- a/Documentation/devicetree/bindings/spi/samsung,spi.yaml +++ b/Documentation/devicetree/bindings/spi/samsung,spi.yaml @@ -21,6 +21,7 @@ properties: - samsung,s3c6410-spi - samsung,s5pv210-spi # for S5PV210 and S5PC110 - samsung,exynos5433-spi + - tesla,fsd-spi - const: samsung,exynos7-spi deprecated: true -- cgit From 830751d54b4abb2d4d9e5e8072dffdd8ce195f1f Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Tue, 8 Mar 2022 16:05:59 +0200 Subject: ACPI: docs: gpio-properties: Unify ASL style for GPIO examples GPIO examples of ASL in the board.rst, enumeration.rst and gpio-properties.rst are not unified. Unify them for better reader experience. Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki --- Documentation/driver-api/gpio/board.rst | 21 ++++++++--------- Documentation/firmware-guide/acpi/enumeration.rst | 22 +++++------------- .../firmware-guide/acpi/gpio-properties.rst | 26 ++++++++++++---------- 3 files changed, 28 insertions(+), 41 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/gpio/board.rst b/Documentation/driver-api/gpio/board.rst index 191fa867826a..4e3adf31c8d1 100644 --- a/Documentation/driver-api/gpio/board.rst +++ b/Documentation/driver-api/gpio/board.rst @@ -71,14 +71,14 @@ with the help of _DSD (Device Specific Data), introduced in ACPI 5.1:: Device (FOO) { Name (_CRS, ResourceTemplate () { - GpioIo (Exclusive, ..., IoRestrictionOutputOnly, - "\\_SB.GPI0") {15} // red - GpioIo (Exclusive, ..., IoRestrictionOutputOnly, - "\\_SB.GPI0") {16} // green - GpioIo (Exclusive, ..., IoRestrictionOutputOnly, - "\\_SB.GPI0") {17} // blue - GpioIo (Exclusive, ..., IoRestrictionOutputOnly, - "\\_SB.GPI0") {1} // power + GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly, + "\\_SB.GPI0", 0, ResourceConsumer) { 15 } // red + GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly, + "\\_SB.GPI0", 0, ResourceConsumer) { 16 } // green + GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly, + "\\_SB.GPI0", 0, ResourceConsumer) { 17 } // blue + GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionOutputOnly, + "\\_SB.GPI0", 0, ResourceConsumer) { 1 } // power }) Name (_DSD, Package () { @@ -92,10 +92,7 @@ with the help of _DSD (Device Specific Data), introduced in ACPI 5.1:: ^FOO, 2, 0, 1, } }, - Package () { - "power-gpios", - Package () {^FOO, 3, 0, 0}, - }, + Package () { "power-gpios", Package () { ^FOO, 3, 0, 0 } }, } }) } diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index a946643244f7..c414646a1bb4 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -295,26 +295,13 @@ For example:: { Name (SBUF, ResourceTemplate() { - ... // Used to power on/off the device - GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, - IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0", - 0x00, ResourceConsumer,,) - { - // Pin List - 0x0055 - } + GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionOutputOnly, + "\\_SB.PCI0.GPI0", 0, ResourceConsumer) { 85 } // Interrupt for the device - GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, - 0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,) - { - // Pin list - 0x0058 - } - - ... - + GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, 0, + "\\_SB.PCI0.GPI0", 0, ResourceConsumer) { 88 } } Return (SBUF) @@ -331,6 +318,7 @@ For example:: } }) ... + } These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0" specifies the path to the controller. In order to use these GPIOs in Linux diff --git a/Documentation/firmware-guide/acpi/gpio-properties.rst b/Documentation/firmware-guide/acpi/gpio-properties.rst index df4b711053ee..eaec732cc77c 100644 --- a/Documentation/firmware-guide/acpi/gpio-properties.rst +++ b/Documentation/firmware-guide/acpi/gpio-properties.rst @@ -21,18 +21,18 @@ index, like the ASL example below shows:: Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly, - "\\_SB.GPO0", 0, ResourceConsumer) {15} + "\\_SB.GPO0", 0, ResourceConsumer) { 15 } GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly, - "\\_SB.GPO0", 0, ResourceConsumer) {27, 31} + "\\_SB.GPO0", 0, ResourceConsumer) { 27, 31 } }) Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () - { - Package () {"reset-gpios", Package() {^BTH, 1, 1, 0 }}, - Package () {"shutdown-gpios", Package() {^BTH, 0, 0, 0 }}, + { + Package () { "reset-gpios", Package () { ^BTH, 1, 1, 0 } }, + Package () { "shutdown-gpios", Package () { ^BTH, 0, 0, 0 } }, } }) } @@ -123,17 +123,17 @@ Example:: // _DSD Hierarchical Properties Extension UUID ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { - Package () {"hog-gpio8", "G8PU"} + Package () { "hog-gpio8", "G8PU" } } }) Name (G8PU, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { - Package () {"gpio-hog", 1}, - Package () {"gpios", Package () {8, 0}}, - Package () {"output-high", 1}, - Package () {"line-name", "gpio8-pullup"}, + Package () { "gpio-hog", 1 }, + Package () { "gpios", Package () { 8, 0 } }, + Package () { "output-high", 1 }, + Package () { "line-name", "gpio8-pullup" }, } }) @@ -266,15 +266,17 @@ have a device like below:: Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionNone, - "\\_SB.GPO0", 0, ResourceConsumer) {15} + "\\_SB.GPO0", 0, ResourceConsumer) { 15 } GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionNone, - "\\_SB.GPO0", 0, ResourceConsumer) {27} + "\\_SB.GPO0", 0, ResourceConsumer) { 27 } }) } The driver might expect to get the right GPIO when it does:: desc = gpiod_get(dev, "reset", GPIOD_OUT_LOW); + if (IS_ERR(desc)) + ...error handling... but since there is no way to know the mapping between "reset" and the GpioIo() in _CRS desc will hold ERR_PTR(-ENOENT). -- cgit From 17bf6b7c7835841f77adda76802ac2e6c11ec65e Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 8 Mar 2022 18:49:02 +0100 Subject: dt-bindings: firmware: arm,scpi: Add missing maxItems to mboxes/shmem "make dt_binding_check": Documentation/devicetree/bindings/firmware/arm,scpi.example.dt.yaml: scpi: shmem: [[2], [1]] is too long Fix this by adding a proper maxItems value to the shmem property, and to the related mboxes property. Fix the grouping of the "mboxes" property in the example. Signed-off-by: Geert Uytterhoeven Acked-by: Sudeep Holla Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/58b7c706f259f88a61bfe82d9106fe0a93a9838d.1646761693.git.geert+renesas@glider.be --- Documentation/devicetree/bindings/firmware/arm,scpi.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml index 800417a76bda..1f9322925e7c 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml @@ -43,6 +43,7 @@ properties: by remote SCP firmware for use by SCPI message protocol should be specified in any order. minItems: 1 + maxItems: 4 shmem: description: @@ -51,6 +52,7 @@ properties: be any memory reserved for the purpose of this communication between the processors. minItems: 1 + maxItems: 4 power-controller: type: object @@ -235,7 +237,7 @@ examples: firmware { scpi { compatible = "amlogic,meson-gxbb-scpi", "arm,scpi-pre-1.0"; - mboxes = <&mailbox 1 &mailbox 2>; + mboxes = <&mailbox 1>, <&mailbox 2>; shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>; scpi_sensors1: sensors { -- cgit From 16d1f0a7938568e32fafaedfeb45dd661e9880ee Mon Sep 17 00:00:00 2001 From: Oleksii Moisieiev Date: Mon, 7 Mar 2022 08:17:43 +0000 Subject: dt-bindings: Add vendor prefix for Xen hypervisor Xen is an open source type-1 hypervisor. Signed-off-by: Oleksii Moisieiev Reviewed-by: Stefano Stabellini Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/aece6fd976980131120456800de3558e1e2308a0.1646639462.git.oleksii_moisieiev@epam.com --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 3da2b08429e1..bf7a4a09aa71 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1368,6 +1368,8 @@ patternProperties: description: Wanchanglong Electronics Technology（SHENZHEN）Co.，Ltd. "^x-powers,.*": description: X-Powers + "^xen,.*": + description: Xen Hypervisor "^xes,.*": description: Extreme Engineering Solutions (X-ES) "^xiaomi,.*": -- cgit From 0fb74d0d21aaea1513eb8bfdbbde60113be4fcbc Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 22 Jan 2022 14:25:53 +0100 Subject: dt-bindings: thermal: samsung: Convert to dtschema Convert the Samsung Exynos SoC Thermal Management Unit bindings to DT schema format. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220122132554.65192-2-krzysztof.kozlowski@canonical.com Signed-off-by: Daniel Lezcano --- .../devicetree/bindings/thermal/exynos-thermal.txt | 106 ------------ .../bindings/thermal/samsung,exynos-thermal.yaml | 184 +++++++++++++++++++++ 2 files changed, 184 insertions(+), 106 deletions(-) delete mode 100644 Documentation/devicetree/bindings/thermal/exynos-thermal.txt create mode 100644 Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt deleted file mode 100644 index 33004ce7e5df..000000000000 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt +++ /dev/null @@ -1,106 +0,0 @@ -* Exynos Thermal Management Unit (TMU) - -** Required properties: - -- compatible : One of the following: - "samsung,exynos3250-tmu" - "samsung,exynos4412-tmu" - "samsung,exynos4210-tmu" - "samsung,exynos5250-tmu" - "samsung,exynos5260-tmu" - "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420 - "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4 - Exynos5420 (Must pass triminfo base and triminfo clock) - "samsung,exynos5433-tmu" - "samsung,exynos7-tmu" -- reg : Address range of the thermal registers. For soc's which has multiple - instances of TMU and some registers are shared across all TMU's like - interrupt related then 2 set of register has to supplied. First set - belongs to register set of TMU instance and second set belongs to - registers shared with the TMU instance. - - NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU - channels 2, 3 and 4 - Use "samsung,exynos5420-tmu-ext-triminfo" in cases, there is a misplaced - register, also provide clock to access that base. - - TRIMINFO at 0x1006c000 contains data for TMU channel 3 - TRIMINFO at 0x100a0000 contains data for TMU channel 4 - TRIMINFO at 0x10068000 contains data for TMU channel 2 - -- interrupts : Should contain interrupt for thermal system -- clocks : The main clocks for TMU device - -- 1. operational clock for TMU channel - -- 2. optional clock to access the shared registers of TMU channel - -- 3. optional special clock for functional operation -- clock-names : Thermal system clock name - -- "tmu_apbif" operational clock for current TMU channel - -- "tmu_triminfo_apbif" clock to access the shared triminfo register - for current TMU channel - -- "tmu_sclk" clock for functional operation of the current TMU - channel - -The Exynos TMU supports generating interrupts when reaching given -temperature thresholds. Number of supported thermal trip points depends -on the SoC (only first trip points defined in DT will be configured): - - most of SoC: 4 - - samsung,exynos5433-tmu: 8 - - samsung,exynos7-tmu: 8 - -** Optional properties: - -- vtmu-supply: This entry is optional and provides the regulator node supplying - voltage to TMU. If needed this entry can be placed inside - board/platform specific dts file. - -Example 1): - - tmu@100c0000 { - compatible = "samsung,exynos4412-tmu"; - interrupt-parent = <&combiner>; - reg = <0x100C0000 0x100>; - interrupts = <2 4>; - clocks = <&clock 383>; - clock-names = "tmu_apbif"; - vtmu-supply = <&tmu_regulator_node>; - #thermal-sensor-cells = <0>; - }; - -Example 2): (In case of Exynos5420 "with misplaced TRIMINFO register") - tmu_cpu2: tmu@10068000 { - compatible = "samsung,exynos5420-tmu-ext-triminfo"; - reg = <0x10068000 0x100>, <0x1006c000 0x4>; - interrupts = <0 184 0>; - clocks = <&clock 318>, <&clock 318>; - clock-names = "tmu_apbif", "tmu_triminfo_apbif"; - #thermal-sensor-cells = <0>; - }; - - tmu_cpu3: tmu@1006c000 { - compatible = "samsung,exynos5420-tmu-ext-triminfo"; - reg = <0x1006c000 0x100>, <0x100a0000 0x4>; - interrupts = <0 185 0>; - clocks = <&clock 318>, <&clock 319>; - clock-names = "tmu_apbif", "tmu_triminfo_apbif"; - #thermal-sensor-cells = <0>; - }; - - tmu_gpu: tmu@100a0000 { - compatible = "samsung,exynos5420-tmu-ext-triminfo"; - reg = <0x100a0000 0x100>, <0x10068000 0x4>; - interrupts = <0 215 0>; - clocks = <&clock 319>, <&clock 318>; - clock-names = "tmu_apbif", "tmu_triminfo_apbif"; - #thermal-sensor-cells = <0>; - }; - -Note: For multi-instance tmu each instance should have an alias correctly -numbered in "aliases" node. - -Example: - -aliases { - tmuctrl0 = &tmuctrl_0; - tmuctrl1 = &tmuctrl_1; - tmuctrl2 = &tmuctrl_2; -}; diff --git a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml new file mode 100644 index 000000000000..17129f75d962 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml @@ -0,0 +1,184 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/samsung,exynos-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC Thermal Management Unit (TMU) + +maintainers: + - Krzysztof Kozlowski + +description: | + For multi-instance tmu each instance should have an alias correctly numbered + in "aliases" node. + +properties: + compatible: + enum: + - samsung,exynos3250-tmu + - samsung,exynos4412-tmu + - samsung,exynos4210-tmu + - samsung,exynos5250-tmu + - samsung,exynos5260-tmu + # For TMU channel 0, 1 on Exynos5420: + - samsung,exynos5420-tmu + # For TMU channels 2, 3 and 4 of Exynos5420: + - samsung,exynos5420-tmu-ext-triminfo + - samsung,exynos5433-tmu + - samsung,exynos7-tmu + + clocks: + minItems: 1 + maxItems: 3 + + clock-names: + minItems: 1 + maxItems: 3 + + interrupts: + description: | + The Exynos TMU supports generating interrupts when reaching given + temperature thresholds. Number of supported thermal trip points depends + on the SoC (only first trip points defined in DT will be configured):: + - most of SoC: 4 + - samsung,exynos5433-tmu: 8 + - samsung,exynos7-tmu: 8 + maxItems: 1 + + reg: + items: + - description: TMU instance registers. + - description: | + Shared TMU registers. + + Note:: On Exynos5420, the TRIMINFO register is misplaced for TMU + channels 2, 3 and 4 Use "samsung,exynos5420-tmu-ext-triminfo" in + cases, there is a misplaced register, also provide clock to access + that base. + TRIMINFO at 0x1006c000 contains data for TMU channel 3 + TRIMINFO at 0x100a0000 contains data for TMU channel 4 + TRIMINFO at 0x10068000 contains data for TMU channel 2 + minItems: 1 + + '#thermal-sensor-cells': true + + vtmu-supply: + description: The regulator node supplying voltage to TMU. + +required: + - compatible + - clocks + - clock-names + - interrupts + - reg + +allOf: + - $ref: /schemas/thermal/thermal-sensor.yaml + - if: + properties: + compatible: + contains: + const: samsung,exynos5420-tmu-ext-triminfo + then: + properties: + clocks: + items: + - description: + Operational clock for TMU channel. + - description: + Optional clock to access the shared registers (e.g. TRIMINFO) of TMU + channel. + clock-names: + items: + - const: tmu_apbif + - const: tmu_triminfo_apbif + reg: + minItems: 2 + maxItems: 2 + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos5433-tmu + - samsung,exynos7-tmu + then: + properties: + clocks: + items: + - description: + Operational clock for TMU channel. + - description: + Optional special clock for functional operation of TMU channel. + clock-names: + items: + - const: tmu_apbif + - const: tmu_sclk + reg: + minItems: 1 + maxItems: 1 + + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos3250-tmu + - samsung,exynos4412-tmu + - samsung,exynos4210-tmu + - samsung,exynos5250-tmu + - samsung,exynos5260-tmu + - samsung,exynos5420-tmu + then: + properties: + clocks: + minItems: 1 + maxItems: 1 + reg: + minItems: 1 + maxItems: 1 + +additionalProperties: false + +examples: + - | + #include + + tmu@100c0000 { + compatible = "samsung,exynos4412-tmu"; + reg = <0x100C0000 0x100>; + interrupt-parent = <&combiner>; + interrupts = <2 4>; + #thermal-sensor-cells = <0>; + clocks = <&clock CLK_TMU_APBIF>; + clock-names = "tmu_apbif"; + vtmu-supply = <&ldo10_reg>; + }; + + - | + #include + + tmu@10068000 { + compatible = "samsung,exynos5420-tmu-ext-triminfo"; + reg = <0x10068000 0x100>, <0x1006c000 0x4>; + interrupts = ; + #thermal-sensor-cells = <0>; + clocks = <&clock 318>, <&clock 318>; /* CLK_TMU */ + clock-names = "tmu_apbif", "tmu_triminfo_apbif"; + vtmu-supply = <&ldo7_reg>; + }; + + - | + #include + + tmu@10060000 { + compatible = "samsung,exynos5433-tmu"; + reg = <0x10060000 0x200>; + interrupts = ; + #thermal-sensor-cells = <0>; + clocks = <&cmu_peris 3>, /* CLK_PCLK_TMU0_APBIF */ + <&cmu_peris 35>; /* CLK_SCLK_TMU0 */ + clock-names = "tmu_apbif", "tmu_sclk"; + vtmu-supply = <&ldo3_reg>; + }; -- cgit From 1f43fad1018a47a3c1723608e64fa01c12bafb81 Mon Sep 17 00:00:00 2001 From: Thara Gopinath Date: Thu, 6 Jan 2022 12:31:38 -0500 Subject: dt-bindings: thermal: Add sm8150 compatible string for LMh Extend the LMh dt binding document to include compatible string supporting sm8150 SoC. Signed-off-by: Thara Gopinath Acked-by: Rob Herring Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220106173138.411097-4-thara.gopinath@linaro.org Signed-off-by: Daniel Lezcano --- Documentation/devicetree/bindings/thermal/qcom-lmh.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml index 289e9a845600..a9b7388ca9ac 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml @@ -19,6 +19,7 @@ properties: compatible: enum: - qcom,sdm845-lmh + - qcom,sm8150-lmh reg: items: -- cgit From e8ec6bb302074e41268f9764bf6328599682b84f Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Sun, 20 Feb 2022 21:18:55 +0100 Subject: dt-bindings: thermal: tsens: Add msm8953 compatible Document the compatible string for tsens found in msm8953. Signed-off-by: Luca Weiss Acked-by: Konrad Dybcio Acked-by: Amit Kucheria Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220220201909.445468-3-luca@z3ntu.xyz Signed-off-by: Daniel Lezcano --- Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index d3b9e9b600a2..b6406bcc683f 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -43,6 +43,7 @@ properties: - description: v2 of TSENS items: - enum: + - qcom,msm8953-tsens - qcom,msm8996-tsens - qcom,msm8998-tsens - qcom,sc7180-tsens -- cgit From 6914b82f37215ef510f9867bec14d5150fd970e5 Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Tue, 22 Feb 2022 02:15:28 +0100 Subject: dt-bindings: clock: add QCOM SM6350 display clock bindings Add device tree bindings for display clock controller for Qualcomm Technology Inc's SM6350 SoC. Signed-off-by: Konrad Dybcio Reviewed-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220222011534.3502-1-konrad.dybcio@somainline.org --- .../bindings/clock/qcom,dispcc-sm6350.yaml | 86 ++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml new file mode 100644 index 000000000000..e706678b353a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,dispcc-sm6350.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display Clock & Reset Controller Binding for SM6350 + +maintainers: + - Konrad Dybcio + +description: | + Qualcomm display clock control module which supports the clocks, resets and + power domains on SM6350. + + See also dt-bindings/clock/qcom,dispcc-sm6350.h. + +properties: + compatible: + const: qcom,sm6350-dispcc + + clocks: + items: + - description: Board XO source + - description: GPLL0 source from GCC + - description: Byte clock from DSI PHY + - description: Pixel clock from DSI PHY + - description: Link clock from DP PHY + - description: VCO DIV clock from DP PHY + + clock-names: + items: + - const: bi_tcxo + - const: gcc_disp_gpll0_clk + - const: dsi0_phy_pll_out_byteclk + - const: dsi0_phy_pll_out_dsiclk + - const: dp_phy_pll_link_clk + - const: dp_phy_pll_vco_div_clk + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include + #include + clock-controller@af00000 { + compatible = "qcom,sm6350-dispcc"; + reg = <0x0af00000 0x20000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_DISP_GPLL0_CLK>, + <&dsi_phy 0>, + <&dsi_phy 1>, + <&dp_phy 0>, + <&dp_phy 1>; + clock-names = "bi_tcxo", + "gcc_disp_gpll0_clk", + "dsi0_phy_pll_out_byteclk", + "dsi0_phy_pll_out_dsiclk", + "dp_phy_pll_link_clk", + "dp_phy_pll_vco_div_clk"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... -- cgit From 7b91b9d8cc6c374cf41f772dd7191ea48011621f Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Tue, 22 Feb 2022 02:15:30 +0100 Subject: dt-bindings: clock: add SM6350 QCOM Graphics clock bindings Add device tree bindings for graphics clock controller for Qualcomm Technology Inc's SM6350 SoCs. Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Konrad Dybcio Reviewed-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220222011534.3502-3-konrad.dybcio@somainline.org --- Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml index 46dff46d5760..9ebcb1943b0a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml @@ -17,6 +17,7 @@ description: | dt-bindings/clock/qcom,gpucc-sdm845.h dt-bindings/clock/qcom,gpucc-sc7180.h dt-bindings/clock/qcom,gpucc-sc7280.h + dt-bindings/clock/qcom,gpucc-sm6350.h dt-bindings/clock/qcom,gpucc-sm8150.h dt-bindings/clock/qcom,gpucc-sm8250.h @@ -27,6 +28,7 @@ properties: - qcom,sc7180-gpucc - qcom,sc7280-gpucc - qcom,sc8180x-gpucc + - qcom,sm6350-gpucc - qcom,sm8150-gpucc - qcom,sm8250-gpucc -- cgit From 2cabc45237659cb3b0294c8b8ae12f5fd0dad28d Mon Sep 17 00:00:00 2001 From: Rohit Agarwal Date: Tue, 22 Feb 2022 10:26:21 +0530 Subject: dt-bindings: clock: Add A7 PLL binding for SDX65 Add information for Cortex A7 PLL clock in Qualcomm platform SDX65. Signed-off-by: Rohit Agarwal Reviewed-by: Manivannan Sadhasivam Reviewed-by: Stephen Boyd Acked-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/1645505785-2271-2-git-send-email-quic_rohiagar@quicinc.com --- Documentation/devicetree/bindings/clock/qcom,a7pll.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,a7pll.yaml b/Documentation/devicetree/bindings/clock/qcom,a7pll.yaml index 8666e995725f..0e96f693b050 100644 --- a/Documentation/devicetree/bindings/clock/qcom,a7pll.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,a7pll.yaml @@ -10,7 +10,7 @@ maintainers: - Manivannan Sadhasivam description: - The A7 PLL on the Qualcomm platforms like SDX55 is used to provide high + The A7 PLL on the Qualcomm platforms like SDX55, SDX65 is used to provide high frequency clock to the CPU. properties: -- cgit From a03965ed13108b2ad7015030455e150bc5e17fcf Mon Sep 17 00:00:00 2001 From: Ansuel Smith Date: Sat, 26 Feb 2022 14:52:21 +0100 Subject: dt-bindings: clock: split qcom,gcc.yaml to common and specific schema Split qcom,gcc.yaml to common and specific schema to use it as a template for schema that needs to use the gcc bindings and require to add additional bindings. Signed-off-by: Ansuel Smith Reviewed-by: Rob Herring Reviewed-by: Stephen Boyd Tested-by: Jonathan McDowell Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220226135235.10051-2-ansuelsmth@gmail.com --- .../devicetree/bindings/clock/qcom,gcc-other.yaml | 76 ++++++++++++++++++++++ .../devicetree/bindings/clock/qcom,gcc.yaml | 59 ++--------------- 2 files changed, 80 insertions(+), 55 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml new file mode 100644 index 000000000000..4e5903bcd70d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-other.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding + +maintainers: + - Stephen Boyd + - Taniya Das + +description: + Qualcomm global clock control module which supports the clocks, resets and + power domains. + + See also: + - dt-bindings/clock/qcom,gcc-apq8084.h + - dt-bindings/reset/qcom,gcc-apq8084.h + - dt-bindings/clock/qcom,gcc-ipq4019.h + - dt-bindings/clock/qcom,gcc-ipq6018.h + - dt-bindings/reset/qcom,gcc-ipq6018.h + - dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) + - dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) + - dt-bindings/clock/qcom,gcc-msm8939.h + - dt-bindings/clock/qcom,gcc-msm8953.h + - dt-bindings/reset/qcom,gcc-msm8939.h + - dt-bindings/clock/qcom,gcc-msm8660.h + - dt-bindings/reset/qcom,gcc-msm8660.h + - dt-bindings/clock/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974) + - dt-bindings/reset/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974) + - dt-bindings/clock/qcom,gcc-mdm9607.h + - dt-bindings/clock/qcom,gcc-mdm9615.h + - dt-bindings/reset/qcom,gcc-mdm9615.h + - dt-bindings/clock/qcom,gcc-sdm660.h (qcom,gcc-sdm630 and qcom,gcc-sdm660) + +allOf: + - $ref: "qcom,gcc.yaml#" + +properties: + compatible: + enum: + - qcom,gcc-apq8084 + - qcom,gcc-ipq4019 + - qcom,gcc-ipq6018 + - qcom,gcc-ipq8064 + - qcom,gcc-mdm9607 + - qcom,gcc-msm8226 + - qcom,gcc-msm8660 + - qcom,gcc-msm8916 + - qcom,gcc-msm8939 + - qcom,gcc-msm8953 + - qcom,gcc-msm8960 + - qcom,gcc-msm8974 + - qcom,gcc-msm8974pro + - qcom,gcc-msm8974pro-ac + - qcom,gcc-mdm9615 + - qcom,gcc-sdm630 + - qcom,gcc-sdm660 + +required: + - compatible + +unevaluatedProperties: false + +examples: + # Example for GCC for MSM8960: + - | + clock-controller@900000 { + compatible = "qcom,gcc-msm8960"; + reg = <0x900000 0x4000>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml index f66d703bd913..2ed27a2ef445 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml @@ -4,57 +4,17 @@ $id: http://devicetree.org/schemas/clock/qcom,gcc.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Global Clock & Reset Controller Binding +title: Qualcomm Global Clock & Reset Controller Binding Common Bindings maintainers: - Stephen Boyd - Taniya Das description: | - Qualcomm global clock control module which supports the clocks, resets and - power domains. - - See also: - - dt-bindings/clock/qcom,gcc-apq8084.h - - dt-bindings/reset/qcom,gcc-apq8084.h - - dt-bindings/clock/qcom,gcc-ipq4019.h - - dt-bindings/clock/qcom,gcc-ipq6018.h - - dt-bindings/reset/qcom,gcc-ipq6018.h - - dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) - - dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) - - dt-bindings/clock/qcom,gcc-msm8939.h - - dt-bindings/clock/qcom,gcc-msm8953.h - - dt-bindings/reset/qcom,gcc-msm8939.h - - dt-bindings/clock/qcom,gcc-msm8660.h - - dt-bindings/reset/qcom,gcc-msm8660.h - - dt-bindings/clock/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974) - - dt-bindings/reset/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974) - - dt-bindings/clock/qcom,gcc-mdm9607.h - - dt-bindings/clock/qcom,gcc-mdm9615.h - - dt-bindings/reset/qcom,gcc-mdm9615.h - - dt-bindings/clock/qcom,gcc-sdm660.h (qcom,gcc-sdm630 and qcom,gcc-sdm660) + Common bindings for Qualcomm global clock control module which supports + the clocks, resets and power domains. properties: - compatible: - enum: - - qcom,gcc-apq8084 - - qcom,gcc-ipq4019 - - qcom,gcc-ipq6018 - - qcom,gcc-ipq8064 - - qcom,gcc-mdm9607 - - qcom,gcc-msm8226 - - qcom,gcc-msm8660 - - qcom,gcc-msm8916 - - qcom,gcc-msm8939 - - qcom,gcc-msm8953 - - qcom,gcc-msm8960 - - qcom,gcc-msm8974 - - qcom,gcc-msm8974pro - - qcom,gcc-msm8974pro-ac - - qcom,gcc-mdm9615 - - qcom,gcc-sdm630 - - qcom,gcc-sdm660 - '#clock-cells': const: 1 @@ -72,22 +32,11 @@ properties: Protected clock specifier list as per common clock binding. required: - - compatible - reg - '#clock-cells' - '#reset-cells' - '#power-domain-cells' -additionalProperties: false +additionalProperties: true -examples: - # Example for GCC for MSM8960: - - | - clock-controller@900000 { - compatible = "qcom,gcc-msm8960"; - reg = <0x900000 0x4000>; - #clock-cells = <1>; - #reset-cells = <1>; - #power-domain-cells = <1>; - }; ... -- cgit From a469bf89a009c610dddf9c4e08fe7c69cabaebaa Mon Sep 17 00:00:00 2001 From: Ansuel Smith Date: Sat, 26 Feb 2022 14:52:22 +0100 Subject: dt-bindings: clock: simplify qcom,gcc-apq8064 Documentation Simplify qcon,gcc-apq8064 Documentation by using qcom,gcc.yaml as a template and remove the compatible from qcom,gcc.yaml Signed-off-by: Ansuel Smith Reviewed-by: Rob Herring Tested-by: Jonathan McDowell Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220226135235.10051-3-ansuelsmth@gmail.com --- .../bindings/clock/qcom,gcc-apq8064.yaml | 29 ++++++---------------- .../devicetree/bindings/clock/qcom,gcc-other.yaml | 3 --- 2 files changed, 7 insertions(+), 25 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml index 8e2eac6cbfb9..97936411b6b4 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml @@ -6,6 +6,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Global Clock & Reset Controller Binding for APQ8064 +allOf: + - $ref: qcom,gcc.yaml# + maintainers: - Stephen Boyd - Taniya Das @@ -17,22 +20,12 @@ description: | See also: - dt-bindings/clock/qcom,gcc-msm8960.h - dt-bindings/reset/qcom,gcc-msm8960.h + - dt-bindings/clock/qcom,gcc-apq8084.h + - dt-bindings/reset/qcom,gcc-apq8084.h properties: compatible: - const: qcom,gcc-apq8064 - - '#clock-cells': - const: 1 - - '#reset-cells': - const: 1 - - '#power-domain-cells': - const: 1 - - reg: - maxItems: 1 + const: qcom,gcc-apq8084 nvmem-cells: minItems: 1 @@ -53,21 +46,13 @@ properties: '#thermal-sensor-cells': const: 1 - protected-clocks: - description: - Protected clock specifier list as per common clock binding. - required: - compatible - - reg - - '#clock-cells' - - '#reset-cells' - - '#power-domain-cells' - nvmem-cells - nvmem-cell-names - '#thermal-sensor-cells' -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml index 4e5903bcd70d..47e1c5332d76 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml @@ -15,8 +15,6 @@ description: power domains. See also: - - dt-bindings/clock/qcom,gcc-apq8084.h - - dt-bindings/reset/qcom,gcc-apq8084.h - dt-bindings/clock/qcom,gcc-ipq4019.h - dt-bindings/clock/qcom,gcc-ipq6018.h - dt-bindings/reset/qcom,gcc-ipq6018.h @@ -40,7 +38,6 @@ allOf: properties: compatible: enum: - - qcom,gcc-apq8084 - qcom,gcc-ipq4019 - qcom,gcc-ipq6018 - qcom,gcc-ipq8064 -- cgit From 85e125878b4a238281df840f469d0b66d55a54b0 Mon Sep 17 00:00:00 2001 From: Ansuel Smith Date: Sat, 26 Feb 2022 14:52:23 +0100 Subject: dt-bindings: clock: document qcom,gcc-ipq8064 binding Document qcom,gcc-ipq8064 binding needed to declare pxo and cxo source clocks. The gcc node is also used by the tsens driver, already documented, to get the calib nvmem cells and the base reg from gcc. Use qcom,gcc.yaml as a template and remove the compatible from generic qcom,gcc-other.yaml Signed-off-by: Ansuel Smith Reviewed-by: Rob Herring Reviewed-by: Stephen Boyd Tested-by: Jonathan McDowell Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220226135235.10051-4-ansuelsmth@gmail.com --- .../bindings/clock/qcom,gcc-ipq8064.yaml | 76 ++++++++++++++++++++++ .../devicetree/bindings/clock/qcom,gcc-other.yaml | 3 - 2 files changed, 76 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml new file mode 100644 index 000000000000..9eb91dd22557 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-ipq8064.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding for IPQ8064 + +allOf: + - $ref: qcom,gcc.yaml# + +maintainers: + - Ansuel Smith + +description: | + Qualcomm global clock control module which supports the clocks, resets and + power domains on IPQ8064. + + See also: + - dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) + - dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) + +properties: + compatible: + items: + - const: qcom,gcc-ipq8064 + - const: syscon + + clocks: + items: + - description: PXO source + - description: CXO source + + clock-names: + items: + - const: pxo + - const: cxo + + thermal-sensor: + type: object + + allOf: + - $ref: /schemas/thermal/qcom-tsens.yaml# + +required: + - compatible + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include + + gcc: clock-controller@900000 { + compatible = "qcom,gcc-ipq8064", "syscon"; + reg = <0x00900000 0x4000>; + clocks = <&pxo_board>, <&cxo_board>; + clock-names = "pxo", "cxo"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + + tsens: thermal-sensor { + compatible = "qcom,ipq8064-tsens"; + + nvmem-cells = <&tsens_calib>, <&tsens_calib_backup>; + nvmem-cell-names = "calib", "calib_backup"; + interrupts = ; + interrupt-names = "uplow"; + + #qcom,sensors = <11>; + #thermal-sensor-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml index 47e1c5332d76..4dc0274dbd6b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml @@ -18,8 +18,6 @@ description: - dt-bindings/clock/qcom,gcc-ipq4019.h - dt-bindings/clock/qcom,gcc-ipq6018.h - dt-bindings/reset/qcom,gcc-ipq6018.h - - dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) - - dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) - dt-bindings/clock/qcom,gcc-msm8939.h - dt-bindings/clock/qcom,gcc-msm8953.h - dt-bindings/reset/qcom,gcc-msm8939.h @@ -40,7 +38,6 @@ properties: enum: - qcom,gcc-ipq4019 - qcom,gcc-ipq6018 - - qcom,gcc-ipq8064 - qcom,gcc-mdm9607 - qcom,gcc-msm8226 - qcom,gcc-msm8660 -- cgit From 296559d41e0f8e7c8f198dd3946e288255088cef Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sun, 6 Mar 2022 17:32:24 -0800 Subject: scsi: ufs: docs: UFS documentation corrections Make a variety of corrections to ufs.rst: - add spaces around parenthetical phrases - correct singular/plural grammar and nouns - correct punctuation - add article adjectives - add hyphens to multi-word adjectives - spell Lun as LUN - spell upiu as UPIU (in text, not code examples) - don't capitalize generic "specification" Link: https://lore.kernel.org/r/20220307013224.5130-1-rdunlap@infradead.org Cc: Alim Akhtar Cc: Avri Altman Cc: "James E.J. Bottomley" Cc: "Martin K. Petersen" Cc: linux-scsi@vger.kernel.org Cc: Jonathan Corbet Signed-off-by: Randy Dunlap Signed-off-by: Martin K. Petersen --- Documentation/scsi/ufs.rst | 70 +++++++++++++++++++++++----------------------- 1 file changed, 35 insertions(+), 35 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scsi/ufs.rst b/Documentation/scsi/ufs.rst index a920c0a5a1f6..fbac745b783c 100644 --- a/Documentation/scsi/ufs.rst +++ b/Documentation/scsi/ufs.rst @@ -10,8 +10,8 @@ Universal Flash Storage 1. Overview 2. UFS Architecture Overview 2.1 Application Layer - 2.2 UFS Transport Protocol(UTP) layer - 2.3 UFS Interconnect(UIC) Layer + 2.2 UFS Transport Protocol (UTP) layer + 2.3 UFS Interconnect (UIC) Layer 3. UFSHCD Overview 3.1 UFS controller initialization 3.2 UTP Transfer requests @@ -22,15 +22,15 @@ Universal Flash Storage 1. Overview =========== -Universal Flash Storage(UFS) is a storage specification for flash devices. -It is aimed to provide a universal storage interface for both -embedded and removable flash memory based storage in mobile +Universal Flash Storage (UFS) is a storage specification for flash devices. +It aims to provide a universal storage interface for both +embedded and removable flash memory-based storage in mobile devices such as smart phones and tablet computers. The specification is defined by JEDEC Solid State Technology Association. UFS is based -on MIPI M-PHY physical layer standard. UFS uses MIPI M-PHY as the +on the MIPI M-PHY physical layer standard. UFS uses MIPI M-PHY as the physical layer and MIPI Unipro as the link layer. -The main goals of UFS is to provide: +The main goals of UFS are to provide: * Optimized performance: @@ -53,17 +53,17 @@ The main goals of UFS is to provide: UFS has a layered communication architecture which is based on SCSI SAM-5 architectural model. -UFS communication architecture consists of following layers, +UFS communication architecture consists of the following layers. 2.1 Application Layer --------------------- - The Application layer is composed of UFS command set layer(UCS), + The Application layer is composed of the UFS command set layer (UCS), Task Manager and Device manager. The UFS interface is designed to be protocol agnostic, however SCSI has been selected as a baseline - protocol for versions 1.0 and 1.1 of UFS protocol layer. + protocol for versions 1.0 and 1.1 of the UFS protocol layer. - UFS supports subset of SCSI commands defined by SPC-4 and SBC-3. + UFS supports a subset of SCSI commands defined by SPC-4 and SBC-3. * UCS: It handles SCSI commands supported by UFS specification. @@ -78,10 +78,10 @@ UFS communication architecture consists of following layers, requests which are used to modify and retrieve configuration information of the device. -2.2 UFS Transport Protocol(UTP) layer -------------------------------------- +2.2 UFS Transport Protocol (UTP) layer +-------------------------------------- - UTP layer provides services for + The UTP layer provides services for the higher layers through Service Access Points. UTP defines 3 service access points for higher layers. @@ -89,19 +89,19 @@ UFS communication architecture consists of following layers, manager for device level operations. These device level operations are done through query requests. * UTP_CMD_SAP: Command service access point is exposed to UFS command - set layer(UCS) to transport commands. + set layer (UCS) to transport commands. * UTP_TM_SAP: Task management service access point is exposed to task manager to transport task management functions. - UTP transports messages through UFS protocol information unit(UPIU). + UTP transports messages through UFS protocol information unit (UPIU). -2.3 UFS Interconnect(UIC) Layer -------------------------------- +2.3 UFS Interconnect (UIC) Layer +-------------------------------- - UIC is the lowest layer of UFS layered architecture. It handles - connection between UFS host and UFS device. UIC consists of + UIC is the lowest layer of the UFS layered architecture. It handles + the connection between UFS host and UFS device. UIC consists of MIPI UniPro and MIPI M-PHY. UIC provides 2 service access points - to upper layer, + to upper layer: * UIC_SAP: To transport UPIU between UFS host and UFS device. * UIO_SAP: To issue commands to Unipro layers. @@ -110,25 +110,25 @@ UFS communication architecture consists of following layers, 3. UFSHCD Overview ================== -The UFS host controller driver is based on Linux SCSI Framework. -UFSHCD is a low level device driver which acts as an interface between -SCSI Midlayer and PCIe based UFS host controllers. +The UFS host controller driver is based on the Linux SCSI Framework. +UFSHCD is a low-level device driver which acts as an interface between +the SCSI Midlayer and PCIe-based UFS host controllers. -The current UFSHCD implementation supports following functionality, +The current UFSHCD implementation supports the following functionality: 3.1 UFS controller initialization --------------------------------- - The initialization module brings UFS host controller to active state - and prepares the controller to transfer commands/response between + The initialization module brings the UFS host controller to active state + and prepares the controller to transfer commands/responses between UFSHCD and UFS device. 3.2 UTP Transfer requests ------------------------- Transfer request handling module of UFSHCD receives SCSI commands - from SCSI Midlayer, forms UPIUs and issues the UPIUs to UFS Host - controller. Also, the module decodes, responses received from UFS + from the SCSI Midlayer, forms UPIUs and issues the UPIUs to the UFS Host + controller. Also, the module decodes responses received from the UFS host controller in the form of UPIUs and intimates the SCSI Midlayer of the status of the command. @@ -136,19 +136,19 @@ The current UFSHCD implementation supports following functionality, ---------------------- Error handling module handles Host controller fatal errors, - Device fatal errors and UIC interconnect layer related errors. + Device fatal errors and UIC interconnect layer-related errors. 3.4 SCSI Error handling ----------------------- This is done through UFSHCD SCSI error handling routines registered - with SCSI Midlayer. Examples of some of the error handling commands - issues by SCSI Midlayer are Abort task, Lun reset and host reset. + with the SCSI Midlayer. Examples of some of the error handling commands + issues by the SCSI Midlayer are Abort task, LUN reset and host reset. UFSHCD Routines to perform these tasks are registered with SCSI Midlayer through .eh_abort_handler, .eh_device_reset_handler and .eh_host_reset_handler. -In this version of UFSHCD Query requests and power management +In this version of UFSHCD, Query requests and power management functionality are not implemented. 4. BSG Support @@ -182,14 +182,14 @@ If you wish to read or write a descriptor, use the appropriate xferp of sg_io_v4. The userspace tool that interacts with the ufs-bsg endpoint and uses its -upiu-based protocol is available at: +UPIU-based protocol is available at: https://github.com/westerndigitalcorporation/ufs-tool For more detailed information about the tool and its supported features, please see the tool's README. -UFS Specifications can be found at: +UFS specifications can be found at: - UFS - http://www.jedec.org/sites/default/files/docs/JESD220.pdf - UFSHCI - http://www.jedec.org/sites/default/files/docs/JESD223.pdf -- cgit From 471e201f543559e2cb19b182b680ebf04d80ee31 Mon Sep 17 00:00:00 2001 From: Noralf Trønnes Date: Wed, 24 Nov 2021 16:07:52 +0100 Subject: dt-bindings: display: sitronix, st7735r: Fix backlight in example MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The backlight property was lost during conversion to yaml in commit abdd9e3705c8 ("dt-bindings: display: sitronix,st7735r: Convert to DT schema"). Put it back. Fixes: abdd9e3705c8 ("dt-bindings: display: sitronix,st7735r: Convert to DT schema") Signed-off-by: Noralf Trønnes Acked-by: Rob Herring Reviewed-by: Geert Uytterhoeven Acked-by: David Lechner Link: https://patchwork.freedesktop.org/patch/msgid/20211124150757.17929-2-noralf@tronnes.org --- Documentation/devicetree/bindings/display/sitronix,st7735r.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml index 0cebaaefda03..419c3b2ac5a6 100644 --- a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml +++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml @@ -72,6 +72,7 @@ examples: dc-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>; rotation = <270>; + backlight = <&backlight>; }; }; -- cgit From a2e8cbb27722b0992aceb93b35e9d9433d8a758e Mon Sep 17 00:00:00 2001 From: Noralf Trønnes Date: Wed, 24 Nov 2021 16:07:53 +0100 Subject: dt-bindings: display: sitronix, st7735r: Make reset-gpios optional MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit There are other ways than using a gpio to reset the controller so make this property optional. Signed-off-by: Noralf Trønnes Acked-by: Rob Herring Acked-by: David Lechner Link: https://patchwork.freedesktop.org/patch/msgid/20211124150757.17929-3-noralf@tronnes.org --- Documentation/devicetree/bindings/display/sitronix,st7735r.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml index 419c3b2ac5a6..f81d0d0d51fe 100644 --- a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml +++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml @@ -48,7 +48,6 @@ required: - compatible - reg - dc-gpios - - reset-gpios additionalProperties: false -- cgit From df0a9e8d3008050f61241f471c70438ef1e90a1b Mon Sep 17 00:00:00 2001 From: Noralf Trønnes Date: Wed, 24 Nov 2021 16:07:54 +0100 Subject: dt-bindings: display: sitronix, st7735r: Remove spi-max-frequency limit MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The datasheet lists the minimum Serial clock cycle (Write) as 66ns which is 15MHz. Mostly it can do much better than that and is in fact often run at 32MHz. With a clever driver that runs configuration commands at a low speed and only the pixel data at the maximum speed the configuration can't be messed up by transfer errors and the speed is only limited by the amount of pixel glitches that one is able to tolerate. Signed-off-by: Noralf Trønnes Acked-by: Rob Herring Acked-by: David Lechner Link: https://patchwork.freedesktop.org/patch/msgid/20211124150757.17929-4-noralf@tronnes.org --- Documentation/devicetree/bindings/display/sitronix,st7735r.yaml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml index f81d0d0d51fe..157b1a7b18f9 100644 --- a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml +++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml @@ -32,15 +32,13 @@ properties: - okaya,rh128128t - const: sitronix,st7715r - spi-max-frequency: - maximum: 32000000 - dc-gpios: maxItems: 1 description: Display data/command selection (D/CX) backlight: true reg: true + spi-max-frequency: true reset-gpios: true rotation: true -- cgit From 3fbf4207dc6807bf98e3d32558753cfa5eac2fa1 Mon Sep 17 00:00:00 2001 From: Oliver Upton Date: Tue, 8 Mar 2022 17:28:57 +0000 Subject: Documentation: KVM: Update documentation to indicate KVM is arm64-only KVM support for 32-bit ARM hosts (KVM/arm) has been removed from the kernel since commit 541ad0150ca4 ("arm: Remove 32bit KVM host support"). There still exists some remnants of the old architecture in the KVM documentation. Remove all traces of 32-bit host support from the documentation. Note that AArch32 guests are still supported. Suggested-by: Marc Zyngier Signed-off-by: Oliver Upton Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220308172856.2997250-1-oupton@google.com --- Documentation/virt/kvm/api.rst | 87 ++++++++++++++++----------------- Documentation/virt/kvm/devices/vcpu.rst | 2 +- 2 files changed, 44 insertions(+), 45 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index a4267104db50..cfbb63873963 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -417,7 +417,7 @@ kvm_run' (see below). ----------------- :Capability: basic -:Architectures: all except ARM, arm64 +:Architectures: all except arm64 :Type: vcpu ioctl :Parameters: struct kvm_regs (out) :Returns: 0 on success, -1 on error @@ -450,7 +450,7 @@ Reads the general purpose registers from the vcpu. ----------------- :Capability: basic -:Architectures: all except ARM, arm64 +:Architectures: all except arm64 :Type: vcpu ioctl :Parameters: struct kvm_regs (in) :Returns: 0 on success, -1 on error @@ -824,7 +824,7 @@ Writes the floating point state to the vcpu. ----------------------- :Capability: KVM_CAP_IRQCHIP, KVM_CAP_S390_IRQCHIP (s390) -:Architectures: x86, ARM, arm64, s390 +:Architectures: x86, arm64, s390 :Type: vm ioctl :Parameters: none :Returns: 0 on success, -1 on error @@ -833,7 +833,7 @@ Creates an interrupt controller model in the kernel. On x86, creates a virtual ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a local APIC. IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23 only go to the IOAPIC. -On ARM/arm64, a GICv2 is created. Any other GIC versions require the usage of +On arm64, a GICv2 is created. Any other GIC versions require the usage of KVM_CREATE_DEVICE, which also supports creating a GICv2. Using KVM_CREATE_DEVICE is preferred over KVM_CREATE_IRQCHIP for GICv2. On s390, a dummy irq routing table is created. @@ -846,7 +846,7 @@ before KVM_CREATE_IRQCHIP can be used. ----------------- :Capability: KVM_CAP_IRQCHIP -:Architectures: x86, arm, arm64 +:Architectures: x86, arm64 :Type: vm ioctl :Parameters: struct kvm_irq_level :Returns: 0 on success, -1 on error @@ -870,7 +870,7 @@ capability is present (or unless it is not using the in-kernel irqchip, of course). -ARM/arm64 can signal an interrupt either at the CPU level, or at the +arm64 can signal an interrupt either at the CPU level, or at the in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for specific cpus. The irq field is interpreted like this:: @@ -896,7 +896,7 @@ When KVM_CAP_ARM_IRQ_LINE_LAYOUT_2 is supported, the target vcpu is identified as (256 * vcpu2_index + vcpu_index). Otherwise, vcpu2_index must be zero. -Note that on arm/arm64, the KVM_CAP_IRQCHIP capability only conditions +Note that on arm64, the KVM_CAP_IRQCHIP capability only conditions injection of interrupts for the in-kernel irqchip. KVM_IRQ_LINE can always be used for a userspace interrupt controller. @@ -1087,7 +1087,7 @@ Other flags returned by ``KVM_GET_CLOCK`` are accepted but ignored. :Capability: KVM_CAP_VCPU_EVENTS :Extended by: KVM_CAP_INTR_SHADOW -:Architectures: x86, arm, arm64 +:Architectures: x86, arm64 :Type: vcpu ioctl :Parameters: struct kvm_vcpu_event (out) :Returns: 0 on success, -1 on error @@ -1146,8 +1146,8 @@ The following bits are defined in the flags field: fields contain a valid state. This bit will be set whenever KVM_CAP_EXCEPTION_PAYLOAD is enabled. -ARM/ARM64: -^^^^^^^^^^ +ARM64: +^^^^^^ If the guest accesses a device that is being emulated by the host kernel in such a way that a real device would generate a physical SError, KVM may make @@ -1206,7 +1206,7 @@ directly to the virtual CPU). :Capability: KVM_CAP_VCPU_EVENTS :Extended by: KVM_CAP_INTR_SHADOW -:Architectures: x86, arm, arm64 +:Architectures: x86, arm64 :Type: vcpu ioctl :Parameters: struct kvm_vcpu_event (in) :Returns: 0 on success, -1 on error @@ -1241,8 +1241,8 @@ can be set in the flags field to signal that the exception_has_payload, exception_payload, and exception.pending fields contain a valid state and shall be written into the VCPU. -ARM/ARM64: -^^^^^^^^^^ +ARM64: +^^^^^^ User space may need to inject several types of events to the guest. @@ -1449,7 +1449,7 @@ for vm-wide capabilities. --------------------- :Capability: KVM_CAP_MP_STATE -:Architectures: x86, s390, arm, arm64, riscv +:Architectures: x86, s390, arm64, riscv :Type: vcpu ioctl :Parameters: struct kvm_mp_state (out) :Returns: 0 on success; -1 on error @@ -1467,7 +1467,7 @@ Possible values are: ========================== =============================================== KVM_MP_STATE_RUNNABLE the vcpu is currently running - [x86,arm/arm64,riscv] + [x86,arm64,riscv] KVM_MP_STATE_UNINITIALIZED the vcpu is an application processor (AP) which has not yet received an INIT signal [x86] KVM_MP_STATE_INIT_RECEIVED the vcpu has received an INIT signal, and is @@ -1476,7 +1476,7 @@ Possible values are: is waiting for an interrupt [x86] KVM_MP_STATE_SIPI_RECEIVED the vcpu has just received a SIPI (vector accessible via KVM_GET_VCPU_EVENTS) [x86] - KVM_MP_STATE_STOPPED the vcpu is stopped [s390,arm/arm64,riscv] + KVM_MP_STATE_STOPPED the vcpu is stopped [s390,arm64,riscv] KVM_MP_STATE_CHECK_STOP the vcpu is in a special error state [s390] KVM_MP_STATE_OPERATING the vcpu is operating (running or halted) [s390] @@ -1488,8 +1488,8 @@ On x86, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel irqchip, the multiprocessing state must be maintained by userspace on these architectures. -For arm/arm64/riscv: -^^^^^^^^^^^^^^^^^^^^ +For arm64/riscv: +^^^^^^^^^^^^^^^^ The only states that are valid are KVM_MP_STATE_STOPPED and KVM_MP_STATE_RUNNABLE which reflect if the vcpu is paused or not. @@ -1498,7 +1498,7 @@ KVM_MP_STATE_RUNNABLE which reflect if the vcpu is paused or not. --------------------- :Capability: KVM_CAP_MP_STATE -:Architectures: x86, s390, arm, arm64, riscv +:Architectures: x86, s390, arm64, riscv :Type: vcpu ioctl :Parameters: struct kvm_mp_state (in) :Returns: 0 on success; -1 on error @@ -1510,8 +1510,8 @@ On x86, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel irqchip, the multiprocessing state must be maintained by userspace on these architectures. -For arm/arm64/riscv: -^^^^^^^^^^^^^^^^^^^^ +For arm64/riscv: +^^^^^^^^^^^^^^^^ The only states that are valid are KVM_MP_STATE_STOPPED and KVM_MP_STATE_RUNNABLE which reflect if the vcpu should be paused or not. @@ -1780,14 +1780,14 @@ The flags bitmap is defined as:: ------------------------ :Capability: KVM_CAP_IRQ_ROUTING -:Architectures: x86 s390 arm arm64 +:Architectures: x86 s390 arm64 :Type: vm ioctl :Parameters: struct kvm_irq_routing (in) :Returns: 0 on success, -1 on error Sets the GSI routing table entries, overwriting any previously set entries. -On arm/arm64, GSI routing has the following limitation: +On arm64, GSI routing has the following limitation: - GSI routing does not apply to KVM_IRQ_LINE but only to KVM_IRQFD. @@ -2855,7 +2855,7 @@ after pausing the vcpu, but before it is resumed. ------------------- :Capability: KVM_CAP_SIGNAL_MSI -:Architectures: x86 arm arm64 +:Architectures: x86 arm64 :Type: vm ioctl :Parameters: struct kvm_msi (in) :Returns: >0 on delivery, 0 if guest blocked the MSI, and -1 on error @@ -3043,7 +3043,7 @@ into the hash PTE second double word). -------------- :Capability: KVM_CAP_IRQFD -:Architectures: x86 s390 arm arm64 +:Architectures: x86 s390 arm64 :Type: vm ioctl :Parameters: struct kvm_irqfd (in) :Returns: 0 on success, -1 on error @@ -3069,7 +3069,7 @@ Note that closing the resamplefd is not sufficient to disable the irqfd. The KVM_IRQFD_FLAG_RESAMPLE is only necessary on assignment and need not be specified with KVM_IRQFD_FLAG_DEASSIGN. -On arm/arm64, gsi routing being supported, the following can happen: +On arm64, gsi routing being supported, the following can happen: - in case no routing entry is associated to this gsi, injection fails - in case the gsi is associated to an irqchip routing entry, @@ -3325,7 +3325,7 @@ current state. "addr" is ignored. ---------------------- :Capability: basic -:Architectures: arm, arm64 +:Architectures: arm64 :Type: vcpu ioctl :Parameters: struct kvm_vcpu_init (in) :Returns: 0 on success; -1 on error @@ -3423,7 +3423,7 @@ Possible features: ----------------------------- :Capability: basic -:Architectures: arm, arm64 +:Architectures: arm64 :Type: vm ioctl :Parameters: struct kvm_vcpu_init (out) :Returns: 0 on success; -1 on error @@ -3452,7 +3452,7 @@ VCPU matching underlying host. --------------------- :Capability: basic -:Architectures: arm, arm64, mips +:Architectures: arm64, mips :Type: vcpu ioctl :Parameters: struct kvm_reg_list (in/out) :Returns: 0 on success; -1 on error @@ -3479,7 +3479,7 @@ KVM_GET_ONE_REG/KVM_SET_ONE_REG calls. ----------------------------------------- :Capability: KVM_CAP_ARM_SET_DEVICE_ADDR -:Architectures: arm, arm64 +:Architectures: arm64 :Type: vm ioctl :Parameters: struct kvm_arm_device_address (in) :Returns: 0 on success, -1 on error @@ -3506,13 +3506,13 @@ can access emulated or directly exposed devices, which the host kernel needs to know about. The id field is an architecture specific identifier for a specific device. -ARM/arm64 divides the id field into two parts, a device id and an +arm64 divides the id field into two parts, a device id and an address type id specific to the individual device:: bits: | 63 ... 32 | 31 ... 16 | 15 ... 0 | field: | 0x00000000 | device id | addr type id | -ARM/arm64 currently only require this when using the in-kernel GIC +arm64 currently only require this when using the in-kernel GIC support for the hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2 as the device id. When setting the base address for the guest's mapping of the VGIC virtual CPU and distributor interface, the ioctl @@ -4726,7 +4726,7 @@ to I/O ports. ------------------------------------ :Capability: KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 -:Architectures: x86, arm, arm64, mips +:Architectures: x86, arm64, mips :Type: vm ioctl :Parameters: struct kvm_clear_dirty_log (in) :Returns: 0 on success, -1 on error @@ -4838,7 +4838,7 @@ version has the following quirks: 4.119 KVM_ARM_VCPU_FINALIZE --------------------------- -:Architectures: arm, arm64 +:Architectures: arm64 :Type: vcpu ioctl :Parameters: int feature (in) :Returns: 0 on success, -1 on error @@ -5920,7 +5920,7 @@ should put the acknowledged interrupt vector into the 'epr' field. If exit_reason is KVM_EXIT_SYSTEM_EVENT then the vcpu has triggered a system-level event using some architecture specific mechanism (hypercall -or some special instruction). In case of ARM/ARM64, this is triggered using +or some special instruction). In case of ARM64, this is triggered using HVC instruction based PSCI call from the vcpu. The 'type' field describes the system-level event type. The 'flags' field describes architecture specific flags for the system-level event. @@ -6013,7 +6013,7 @@ in send_page or recv a buffer to recv_page). __u64 fault_ipa; } arm_nisv; -Used on arm and arm64 systems. If a guest accesses memory not in a memslot, +Used on arm64 systems. If a guest accesses memory not in a memslot, KVM will typically return to userspace and ask it to do MMIO emulation on its behalf. However, for certain classes of instructions, no instruction decode (direction, length of memory access) is provided, and fetching and decoding @@ -6030,11 +6030,10 @@ did not fall within an I/O window. Userspace implementations can query for KVM_CAP_ARM_NISV_TO_USER, and enable this capability at VM creation. Once this is done, these types of errors will instead return to userspace with KVM_EXIT_ARM_NISV, with the valid bits from -the HSR (arm) and ESR_EL2 (arm64) in the esr_iss field, and the faulting IPA -in the fault_ipa field. Userspace can either fix up the access if it's -actually an I/O access by decoding the instruction from guest memory (if it's -very brave) and continue executing the guest, or it can decide to suspend, -dump, or restart the guest. +the ESR_EL2 in the esr_iss field, and the faulting IPA in the fault_ipa field. +Userspace can either fix up the access if it's actually an I/O access by +decoding the instruction from guest memory (if it's very brave) and continue +executing the guest, or it can decide to suspend, dump, or restart the guest. Note that KVM does not skip the faulting instruction as it does for KVM_EXIT_MMIO, but userspace has to emulate any change to the processing state @@ -6741,7 +6740,7 @@ and injected exceptions. 7.18 KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 -:Architectures: x86, arm, arm64, mips +:Architectures: x86, arm64, mips :Parameters: args[0] whether feature should be enabled or not Valid flags are:: @@ -7124,7 +7123,7 @@ reserved. 8.9 KVM_CAP_ARM_USER_IRQ ------------------------ -:Architectures: arm, arm64 +:Architectures: arm64 This capability, if KVM_CHECK_EXTENSION indicates that it is available, means that if userspace creates a VM without an in-kernel interrupt controller, it @@ -7251,7 +7250,7 @@ HvFlushVirtualAddressList, HvFlushVirtualAddressListEx. 8.19 KVM_CAP_ARM_INJECT_SERROR_ESR ---------------------------------- -:Architectures: arm, arm64 +:Architectures: arm64 This capability indicates that userspace can specify (via the KVM_SET_VCPU_EVENTS ioctl) the syndrome value reported to the guest when it diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst index 60a29972d3f1..92942440a9e7 100644 --- a/Documentation/virt/kvm/devices/vcpu.rst +++ b/Documentation/virt/kvm/devices/vcpu.rst @@ -108,7 +108,7 @@ using event 0x11 (CPU_CYCLES). 2. GROUP: KVM_ARM_VCPU_TIMER_CTRL ================================= -:Architectures: ARM, ARM64 +:Architectures: ARM64 2.1. ATTRIBUTES: KVM_ARM_VCPU_TIMER_IRQ_VTIMER, KVM_ARM_VCPU_TIMER_IRQ_PTIMER ----------------------------------------------------------------------------- -- cgit From 3c3dd2c81a1036c487353f7b9a485268b2fc1d7f Mon Sep 17 00:00:00 2001 From: Will Deacon Date: Wed, 9 Mar 2022 12:16:33 +0000 Subject: Documentation: vmcoreinfo: Fix htmldocs warning Since commit 2369f171d5c5 ("arm64: crash_core: Export MODULES, VMALLOC, and VMEMMAP ranges"), Stephen reports a warning when building htmldocs: | Documentation/admin-guide/kdump/vmcoreinfo.rst:498: WARNING: Title underline too short. Extend the underline to squash the warning. Fixes: 2369f171d5c5 ("arm64: crash_core: Export MODULES, VMALLOC, and VMEMMAP ranges") Reported-by: Stephen Rothwell Signed-off-by: Will Deacon --- Documentation/admin-guide/kdump/vmcoreinfo.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst index a339af45a22e..8419019b6a88 100644 --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst @@ -495,7 +495,7 @@ addresses in the higher VA range (refer to ARMv8 ARM document for more details). MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END -------------- +----------------------------------------------------------------------------- Used to get the correct ranges: MODULES_VADDR ~ MODULES_END-1 : Kernel module space. -- cgit From b77e70f6b8f2cc62fba847f3008a430a09ef275d Mon Sep 17 00:00:00 2001 From: ChiYuan Huang Date: Wed, 9 Mar 2022 16:01:42 +0800 Subject: regulator: Add bindings for Richtek RT5190A PMIC Add bindings for Richtek RT5190A PMIC. Signed-off-by: ChiYuan Huang Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/1646812903-32496-2-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown --- .../regulator/richtek,rt5190a-regulator.yaml | 141 +++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml new file mode 100644 index 000000000000..28725c5467fc --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml @@ -0,0 +1,141 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rt5190a-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT5190A PMIC Regulator + +maintainers: + - ChiYuan Huang + +description: | + The RT5190A integrates 1 channel buck controller, 3 channels high efficiency + synchronous buck converters, 1 LDO, I2C control interface and peripherial + logical control. + + It also supports mute AC OFF depop sound and quick setting storage while + input power is removed. + +properties: + compatible: + enum: + - richtek,rt5190a + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vin2-supply: + description: phandle to buck2 input voltage. + + vin3-supply: + description: phandle to buck3 input voltage. + + vin4-supply: + description: phandle to buck4 input voltage. + + vinldo-supply: + description: phandle to ldo input voltage + + richtek,mute-enable: + description: | + The mute function uses 'mutein', 'muteout', and 'vdet' pins as the control + signal. When enabled, The normal behavior is to bypass the 'mutein' signal + 'muteout'. But if the power source removal is detected from 'vdet', + whatever the 'mutein' signal is, it will pull down the 'muteout' to force + speakers mute. this function is commonly used to prevent the speaker pop + noise during AC power turned off in the modern TV system design. + type: boolean + + regulators: + type: object + + patternProperties: + "^buck[1-4]$|^ldo$": + type: object + $ref: regulator.yaml# + description: | + regulator description for buck1 and buck4. + + properties: + regulator-allowed-modes: + description: | + buck operating mode, only buck1/4 support mode operating. + 0: auto mode + 1: force pwm mode + items: + enum: [0, 1] + + richtek,latchup-enable: + type: boolean + description: | + If specified, undervolt protection mode changes from the default + hiccup to latchup. + + unevaluatedProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + #include + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@64 { + compatible = "richtek,rt5190a"; + reg = <0x64>; + interrupts-extended = <&gpio26 0 IRQ_TYPE_LEVEL_LOW>; + vin2-supply = <&rt5190_buck1>; + vin3-supply = <&rt5190_buck1>; + vin4-supply = <&rt5190_buck1>; + + regulators { + rt5190_buck1: buck1 { + regulator-name = "rt5190a-buck1"; + regulator-min-microvolt = <5090000>; + regulator-max-microvolt = <5090000>; + regulator-allowed-modes = ; + regulator-boot-on; + }; + buck2 { + regulator-name = "rt5190a-buck2"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <1400000>; + regulator-boot-on; + }; + buck3 { + regulator-name = "rt5190a-buck3"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <1400000>; + regulator-boot-on; + }; + buck4 { + regulator-name = "rt5190a-buck4"; + regulator-min-microvolt = <850000>; + regulator-max-microvolt = <850000>; + regulator-allowed-modes = ; + regulator-boot-on; + }; + ldo { + regulator-name = "rt5190a-ldo"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-boot-on; + }; + }; + }; + }; -- cgit From 8397c9c0c26b5129acb623044ecc2d8d1b15d420 Mon Sep 17 00:00:00 2001 From: Martin Botka Date: Thu, 3 Mar 2022 14:18:11 +0100 Subject: dt-bindings: clock: add QCOM SM6125 display clock bindings Add device tree bindings for display clock controller for Qualcomm Technology Inc's SM6125 SoC. Signed-off-by: Martin Botka Signed-off-by: Marijn Suijten Reviewed-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220303131812.302302-3-marijn.suijten@somainline.org --- .../bindings/clock/qcom,dispcc-sm6125.yaml | 87 ++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml new file mode 100644 index 000000000000..7a03ef19c947 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,dispcc-sm6125.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display Clock Controller Binding for SM6125 + +maintainers: + - Martin Botka + +description: | + Qualcomm display clock control module which supports the clocks and + power domains on SM6125. + + See also: + dt-bindings/clock/qcom,dispcc-sm6125.h + +properties: + compatible: + enum: + - qcom,sm6125-dispcc + + clocks: + items: + - description: Board XO source + - description: Byte clock from DSI PHY0 + - description: Pixel clock from DSI PHY0 + - description: Pixel clock from DSI PHY1 + - description: Link clock from DP PHY + - description: VCO DIV clock from DP PHY + - description: AHB config clock from GCC + + clock-names: + items: + - const: bi_tcxo + - const: dsi0_phy_pll_out_byteclk + - const: dsi0_phy_pll_out_dsiclk + - const: dsi1_phy_pll_out_dsiclk + - const: dp_phy_pll_link_clk + - const: dp_phy_pll_vco_div_clk + - const: cfg_ahb_clk + + '#clock-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include + #include + clock-controller@5f00000 { + compatible = "qcom,sm6125-dispcc"; + reg = <0x5f00000 0x20000>; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, + <&dsi0_phy 0>, + <&dsi0_phy 1>, + <&dsi1_phy 1>, + <&dp_phy 0>, + <&dp_phy 1>, + <&gcc GCC_DISP_AHB_CLK>; + clock-names = "bi_tcxo", + "dsi0_phy_pll_out_byteclk", + "dsi0_phy_pll_out_dsiclk", + "dsi1_phy_pll_out_dsiclk", + "dp_phy_pll_link_clk", + "dp_phy_pll_vco_div_clk", + "cfg_ahb_clk"; + #clock-cells = <1>; + #power-domain-cells = <1>; + }; +... -- cgit From cf220ad6749b8305ba11bdf601c55a17ad2a715d Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Wed, 9 Mar 2022 13:12:00 +0000 Subject: arm64/mte: Remove asymmetric mode from the prctl() interface As pointed out by Evgenii Stepanov one potential issue with the new ABI for enabling asymmetric is that if there are multiple places where MTE is configured in a process, some of which were compiled with the old prctl.h and some of which were compiled with the new prctl.h, there may be problems keeping track of which MTE modes are requested. For example some code may disable only sync and async modes leaving asymmetric mode enabled when it intended to fully disable MTE. In order to avoid such mishaps remove asymmetric mode from the prctl(), instead implicitly allowing it if both sync and async modes are requested. This should not disrupt userspace since a process requesting both may already see a mix of sync and async modes due to differing defaults between CPUs or changes in default while the process is running but it does mean that userspace is unable to explicitly request asymmetric mode without changing the system default for CPUs. Reported-by: Evgenii Stepanov Signed-off-by: Mark Brown Reviewed-by: Catalin Marinas Reviewed-by: Evgenii Stepanov Cc: Peter Collingbourne Cc: Joey Gouly Cc: Branislav Rankov Link: https://lore.kernel.org/r/20220309131200.112637-1-broonie@kernel.org Signed-off-by: Will Deacon --- Documentation/arm64/memory-tagging-extension.rst | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arm64/memory-tagging-extension.rst index 42677d48a114..7e812a51e506 100644 --- a/Documentation/arm64/memory-tagging-extension.rst +++ b/Documentation/arm64/memory-tagging-extension.rst @@ -88,7 +88,6 @@ bit-field: (ignored if combined with other options) - ``PR_MTE_TCF_SYNC`` - *Synchronous* tag check fault mode - ``PR_MTE_TCF_ASYNC`` - *Asynchronous* tag check fault mode -- ``PR_MTE_TCF_ASYMM`` - *Asymmetric* tag check fault mode If no modes are specified, tag check faults are ignored. If a single mode is specified, the program will run in that mode. If multiple @@ -149,17 +148,19 @@ default preferred mode for each CPU is ``async``. To allow a program to potentially run in the CPU's preferred tag checking mode, the user program may set multiple tag check fault mode bits in the ``flags`` argument to the ``prctl(PR_SET_TAGGED_ADDR_CTRL, -flags, 0, 0, 0)`` system call. If the CPU's preferred tag checking -mode is in the task's set of provided tag checking modes, that -mode will be selected. Otherwise, one of the modes in the task's mode -selected by the kernel using the preference order: +flags, 0, 0, 0)`` system call. If both synchronous and asynchronous +modes are requested then asymmetric mode may also be selected by the +kernel. If the CPU's preferred tag checking mode is in the task's set +of provided tag checking modes, that mode will be selected. Otherwise, +one of the modes in the task's mode will be selected by the kernel +from the task's mode set using the preference order: 1. Asynchronous 2. Asymmetric 3. Synchronous -If asymmetric mode is specified by the program but not supported by -either the system or the kernel then an error will be returned. +Note that there is no way for userspace to request multiple modes and +also disable asymmetric mode. Initial process state --------------------- -- cgit From b020771a66e474cd8450b3c483cec8492702db22 Mon Sep 17 00:00:00 2001 From: Jinzhou Su Date: Wed, 9 Mar 2022 09:23:51 +0800 Subject: Documentation: amd-pstate: add tracer tool introduction Add amd pstate tracer tool introduction Signed-off-by: Jinzhou Su Reviewed-by: Huang Rui Signed-off-by: Rafael J. Wysocki --- Documentation/admin-guide/pm/amd-pstate.rst | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst index 2f066df4ee9c..1923cb25073b 100644 --- a/Documentation/admin-guide/pm/amd-pstate.rst +++ b/Documentation/admin-guide/pm/amd-pstate.rst @@ -369,6 +369,32 @@ governor (for the policies it is attached to), or by the ``CPUFreq`` core (for t policies with other scaling governors). +Tracer Tool +------------- + +``amd_pstate_tracer.py`` can record and parse ``amd-pstate`` trace log, then +generate performance plots. This utility can be used to debug and tune the +performance of ``amd-pstate`` driver. The tracer tool needs to import intel +pstate tracer. + +Tracer tool located in ``linux/tools/power/x86/amd_pstate_tracer``. It can be +used in two ways. If trace file is available, then directly parse the file +with command :: + + ./amd_pstate_trace.py [-c cpus] -t -n + +Or generate trace file with root privilege, then parse and plot with command :: + + sudo ./amd_pstate_trace.py [-c cpus] -n -i [-m kbytes] + +The test result can be found in ``results/test_name``. Following is the example +about part of the output. :: + + common_cpu common_secs common_usecs min_perf des_perf max_perf freq mperf apef tsc load duration_ms sample_num elapsed_time common_comm + CPU_005 712 116384 39 49 166 0.7565 9645075 2214891 38431470 25.1 11.646 469 2.496 kworker/5:0-40 + CPU_006 712 116408 39 49 166 0.6769 8950227 1839034 37192089 24.06 11.272 470 2.496 kworker/6:0-1264 + + Reference =========== -- cgit From 1a7551f15097dff30cf0853117b2f8077bb84f0a Mon Sep 17 00:00:00 2001 From: Toke Høiland-Jørgensen Date: Wed, 9 Mar 2022 11:53:43 +0100 Subject: Documentation/bpf: Add documentation for BPF_PROG_RUN MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This adds documentation for the BPF_PROG_RUN command; a short overview of the command itself, and a more verbose description of the "live packet" mode for XDP introduced in the previous commit. Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20220309105346.100053-3-toke@redhat.com --- Documentation/bpf/bpf_prog_run.rst | 117 +++++++++++++++++++++++++++++++++++++ Documentation/bpf/index.rst | 1 + 2 files changed, 118 insertions(+) create mode 100644 Documentation/bpf/bpf_prog_run.rst (limited to 'Documentation') diff --git a/Documentation/bpf/bpf_prog_run.rst b/Documentation/bpf/bpf_prog_run.rst new file mode 100644 index 000000000000..4868c909df5c --- /dev/null +++ b/Documentation/bpf/bpf_prog_run.rst @@ -0,0 +1,117 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================== +Running BPF programs from userspace +=================================== + +This document describes the ``BPF_PROG_RUN`` facility for running BPF programs +from userspace. + +.. contents:: + :local: + :depth: 2 + + +Overview +-------- + +The ``BPF_PROG_RUN`` command can be used through the ``bpf()`` syscall to +execute a BPF program in the kernel and return the results to userspace. This +can be used to unit test BPF programs against user-supplied context objects, and +as way to explicitly execute programs in the kernel for their side effects. The +command was previously named ``BPF_PROG_TEST_RUN``, and both constants continue +to be defined in the UAPI header, aliased to the same value. + +The ``BPF_PROG_RUN`` command can be used to execute BPF programs of the +following types: + +- ``BPF_PROG_TYPE_SOCKET_FILTER`` +- ``BPF_PROG_TYPE_SCHED_CLS`` +- ``BPF_PROG_TYPE_SCHED_ACT`` +- ``BPF_PROG_TYPE_XDP`` +- ``BPF_PROG_TYPE_SK_LOOKUP`` +- ``BPF_PROG_TYPE_CGROUP_SKB`` +- ``BPF_PROG_TYPE_LWT_IN`` +- ``BPF_PROG_TYPE_LWT_OUT`` +- ``BPF_PROG_TYPE_LWT_XMIT`` +- ``BPF_PROG_TYPE_LWT_SEG6LOCAL`` +- ``BPF_PROG_TYPE_FLOW_DISSECTOR`` +- ``BPF_PROG_TYPE_STRUCT_OPS`` +- ``BPF_PROG_TYPE_RAW_TRACEPOINT`` +- ``BPF_PROG_TYPE_SYSCALL`` + +When using the ``BPF_PROG_RUN`` command, userspace supplies an input context +object and (for program types operating on network packets) a buffer containing +the packet data that the BPF program will operate on. The kernel will then +execute the program and return the results to userspace. Note that programs will +not have any side effects while being run in this mode; in particular, packets +will not actually be redirected or dropped, the program return code will just be +returned to userspace. A separate mode for live execution of XDP programs is +provided, documented separately below. + +Running XDP programs in "live frame mode" +----------------------------------------- + +The ``BPF_PROG_RUN`` command has a separate mode for running live XDP programs, +which can be used to execute XDP programs in a way where packets will actually +be processed by the kernel after the execution of the XDP program as if they +arrived on a physical interface. This mode is activated by setting the +``BPF_F_TEST_XDP_LIVE_FRAMES`` flag when supplying an XDP program to +``BPF_PROG_RUN``. + +The live packet mode is optimised for high performance execution of the supplied +XDP program many times (suitable for, e.g., running as a traffic generator), +which means the semantics are not quite as straight-forward as the regular test +run mode. Specifically: + +- When executing an XDP program in live frame mode, the result of the execution + will not be returned to userspace; instead, the kernel will perform the + operation indicated by the program's return code (drop the packet, redirect + it, etc). For this reason, setting the ``data_out`` or ``ctx_out`` attributes + in the syscall parameters when running in this mode will be rejected. In + addition, not all failures will be reported back to userspace directly; + specifically, only fatal errors in setup or during execution (like memory + allocation errors) will halt execution and return an error. If an error occurs + in packet processing, like a failure to redirect to a given interface, + execution will continue with the next repetition; these errors can be detected + via the same trace points as for regular XDP programs. + +- Userspace can supply an ifindex as part of the context object, just like in + the regular (non-live) mode. The XDP program will be executed as though the + packet arrived on this interface; i.e., the ``ingress_ifindex`` of the context + object will point to that interface. Furthermore, if the XDP program returns + ``XDP_PASS``, the packet will be injected into the kernel networking stack as + though it arrived on that ifindex, and if it returns ``XDP_TX``, the packet + will be transmitted *out* of that same interface. Do note, though, that + because the program execution is not happening in driver context, an + ``XDP_TX`` is actually turned into the same action as an ``XDP_REDIRECT`` to + that same interface (i.e., it will only work if the driver has support for the + ``ndo_xdp_xmit`` driver op). + +- When running the program with multiple repetitions, the execution will happen + in batches. The batch size defaults to 64 packets (which is same as the + maximum NAPI receive batch size), but can be specified by userspace through + the ``batch_size`` parameter, up to a maximum of 256 packets. For each batch, + the kernel executes the XDP program repeatedly, each invocation getting a + separate copy of the packet data. For each repetition, if the program drops + the packet, the data page is immediately recycled (see below). Otherwise, the + packet is buffered until the end of the batch, at which point all packets + buffered this way during the batch are transmitted at once. + +- When setting up the test run, the kernel will initialise a pool of memory + pages of the same size as the batch size. Each memory page will be initialised + with the initial packet data supplied by userspace at ``BPF_PROG_RUN`` + invocation. When possible, the pages will be recycled on future program + invocations, to improve performance. Pages will generally be recycled a full + batch at a time, except when a packet is dropped (by return code or because + of, say, a redirection error), in which case that page will be recycled + immediately. If a packet ends up being passed to the regular networking stack + (because the XDP program returns ``XDP_PASS``, or because it ends up being + redirected to an interface that injects it into the stack), the page will be + released and a new one will be allocated when the pool is empty. + + When recycling, the page content is not rewritten; only the packet boundary + pointers (``data``, ``data_end`` and ``data_meta``) in the context object will + be reset to the original values. This means that if a program rewrites the + packet contents, it has to be prepared to see either the original content or + the modified version on subsequent invocations. diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index ef5c996547ec..96056a7447c7 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst @@ -21,6 +21,7 @@ that goes into great technical depth about the BPF Architecture. helpers programs maps + bpf_prog_run classic_vs_extended.rst bpf_licensing test_debug -- cgit From f09f6f9b69821c9efcf16e6b5b466ce9e263ca51 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Fri, 4 Mar 2022 10:14:18 -0800 Subject: Documentation/process: Add Researcher Guidelines As a follow-up to the UMN incident[1], the TAB took the responsibility to document Researcher Guidelines so there would be a common place to point for describing our expectations as a developer community. Document best practices researchers should follow to participate successfully with the Linux developer community. [1] https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/ Co-developed-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman Co-developed-by: Jonathan Corbet Co-developed-by: Stefano Zacchiroli Signed-off-by: Stefano Zacchiroli Co-developed-by: Steven Rostedt Signed-off-by: Steven Rostedt Acked-by: Steve Rostedt Acked-by: Laura Abbott Reviewed-by: Julia Lawall Reviewed-by: Wenwen Wang Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220304181418.1692016-1-keescook@chromium.org Signed-off-by: Jonathan Corbet --- Documentation/process/index.rst | 1 + Documentation/process/researcher-guidelines.rst | 143 ++++++++++++++++++++++++ 2 files changed, 144 insertions(+) create mode 100644 Documentation/process/researcher-guidelines.rst (limited to 'Documentation') diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index 428e39074f61..3587dae4d0ef 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -49,6 +49,7 @@ Other guides to the community that are of interest to most developers are: deprecated embargoed-hardware-issues maintainers + researcher-guidelines These are some overall technical guides that have been put here for now for lack of a better place. diff --git a/Documentation/process/researcher-guidelines.rst b/Documentation/process/researcher-guidelines.rst new file mode 100644 index 000000000000..afc944e0e898 --- /dev/null +++ b/Documentation/process/researcher-guidelines.rst @@ -0,0 +1,143 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _researcher_guidelines: + +Researcher Guidelines ++++++++++++++++++++++ + +The Linux kernel community welcomes transparent research on the Linux +kernel, the activities involved in producing it, and any other byproducts +of its development. Linux benefits greatly from this kind of research, and +most aspects of Linux are driven by research in one form or another. + +The community greatly appreciates if researchers can share preliminary +findings before making their results public, especially if such research +involves security. Getting involved early helps both improve the quality +of research and ability for Linux to improve from it. In any case, +sharing open access copies of the published research with the community +is recommended. + +This document seeks to clarify what the Linux kernel community considers +acceptable and non-acceptable practices when conducting such research. At +the very least, such research and related activities should follow +standard research ethics rules. For more background on research ethics +generally, ethics in technology, and research of developer communities +in particular, see: + +* `History of Research Ethics `_ +* `IEEE Ethics `_ +* `Developer and Researcher Views on the Ethics of Experiments on Open-Source Projects `_ + +The Linux kernel community expects that everyone interacting with the +project is participating in good faith to make Linux better. Research on +any publicly-available artifact (including, but not limited to source +code) produced by the Linux kernel community is welcome, though research +on developers must be distinctly opt-in. + +Passive research that is based entirely on publicly available sources, +including posts to public mailing lists and commits to public +repositories, is clearly permissible. Though, as with any research, +standard ethics must still be followed. + +Active research on developer behavior, however, must be done with the +explicit agreement of, and full disclosure to, the individual developers +involved. Developers cannot be interacted with/experimented on without +consent; this, too, is standard research ethics. + +To help clarify: sending patches to developers *is* interacting +with them, but they have already consented to receiving *good faith +contributions*. Sending intentionally flawed/vulnerable patches or +contributing misleading information to discussions is not consented +to. Such communication can be damaging to the developer (e.g. draining +time, effort, and morale) and damaging to the project by eroding +the entire developer community's trust in the contributor (and the +contributor's organization as a whole), undermining efforts to provide +constructive feedback to contributors, and putting end users at risk of +software flaws. + +Participation in the development of Linux itself by researchers, as +with anyone, is welcomed and encouraged. Research into Linux code is +a common practice, especially when it comes to developing or running +analysis tools that produce actionable results. + +When engaging with the developer community, sending a patch has +traditionally been the best way to make an impact. Linux already has +plenty of known bugs -- what's much more helpful is having vetted fixes. +Before contributing, carefully read the appropriate documentation: + +* Documentation/process/development-process.rst +* Documentation/process/submitting-patches.rst +* Documentation/admin-guide/reporting-issues.rst +* Documentation/admin-guide/security-bugs.rst + +Then send a patch (including a commit log with all the details listed +below) and follow up on any feedback from other developers. + +When sending patches produced from research, the commit logs should +contain at least the following details, so that developers have +appropriate context for understanding the contribution. Answer: + +* What is the specific problem that has been found? +* How could the problem be reached on a running system? +* What effect would encountering the problem have on the system? +* How was the problem found? Specifically include details about any + testing, static or dynamic analysis programs, and any other tools or + methods used to perform the work. +* Which version of Linux was the problem found on? Using the most recent + release or a recent linux-next branch is strongly preferred (see + Documentation/process/howto.rst). +* What was changed to fix the problem, and why it is believed to be correct? +* How was the change build tested and run-time tested? +* What prior commit does this change fix? This should go in a "Fixes:" + tag as the documentation describes. +* Who else has reviewed this patch? This should go in appropriate + "Reviewed-by:" tags; see below. + +For example:: + + From: Author + Subject: [PATCH] drivers/foo_bar: Add missing kfree() + + The error path in foo_bar driver does not correctly free the allocated + struct foo_bar_info. This can happen if the attached foo_bar device + rejects the initialization packets sent during foo_bar_probe(). This + would result in a 64 byte slab memory leak once per device attach, + wasting memory resources over time. + + This flaw was found using an experimental static analysis tool we are + developing, LeakMagic[1], which reported the following warning when + analyzing the v5.15 kernel release: + + path/to/foo_bar.c:187: missing kfree() call? + + Add the missing kfree() to the error path. No other references to + this memory exist outside the probe function, so this is the only + place it can be freed. + + x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC + 11.2 show no new warnings, and LeakMagic no longer warns about this + code path. As we don't have a FooBar device to test with, no runtime + testing was able to be performed. + + [1] https://url/to/leakmagic/details + + Reported-by: Researcher + Fixes: aaaabbbbccccdddd ("Introduce support for FooBar") + Signed-off-by: Author + Reviewed-by: Reviewer + +If you are a first time contributor it is recommended that the patch +itself be vetted by others privately before being posted to public lists. +(This is required if you have been explicitly told your patches need +more careful internal review.) These people are expected to have their +"Reviewed-by" tag included in the resulting patch. Finding another +developer familiar with Linux contribution, especially within your own +organization, and having them help with reviews before sending them to +the public mailing lists tends to significantly improve the quality of the +resulting patches, and there by reduces the burden on other developers. + +If no one can be found to internally review patches and you need +help finding such a person, or if you have any other questions +related to this document and the developer community's expectations, +please reach out to the private Technical Advisory Board mailing list: +. -- cgit From 125c0d0bec56069810ab835daa49453890d159c8 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Tue, 1 Mar 2022 12:18:24 +0800 Subject: docs/zh_CN: add riscv vm-layout translation Translate .../riscv/vm-layout.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/b59965f7f88ea22ec824dc2e92561b018fd370d1.1646108017.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/riscv/index.rst | 1 + .../translations/zh_CN/riscv/vm-layout.rst | 67 ++++++++++++++++++++++ 2 files changed, 68 insertions(+) create mode 100644 Documentation/translations/zh_CN/riscv/vm-layout.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/riscv/index.rst b/Documentation/translations/zh_CN/riscv/index.rst index bbf5d7b3777a..614cde0c0997 100644 --- a/Documentation/translations/zh_CN/riscv/index.rst +++ b/Documentation/translations/zh_CN/riscv/index.rst @@ -18,6 +18,7 @@ RISC-V 体系结构 :maxdepth: 1 boot-image-header + vm-layout pmu patch-acceptance diff --git a/Documentation/translations/zh_CN/riscv/vm-layout.rst b/Documentation/translations/zh_CN/riscv/vm-layout.rst new file mode 100644 index 000000000000..585cb89317a3 --- /dev/null +++ b/Documentation/translations/zh_CN/riscv/vm-layout.rst @@ -0,0 +1,67 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/riscv/vm-layout.rst + +:翻译: + + 司延腾 Yanteng Si + +============================ +RISC-V Linux上的虚拟内存布局 +============================ + +:作者: Alexandre Ghiti +:日期: 12 February 2021 + +这份文件描述了RISC-V Linux内核使用的虚拟内存布局。 + +32位 RISC-V Linux 内核 +====================== + +RISC-V Linux Kernel SV32 +------------------------ + +TODO + +64位 RISC-V Linux 内核 +====================== + +RISC-V特权架构文档指出，64位地址 "必须使第63-48位值都等于第47位，否则将发生缺页异常。"：这将虚 +拟地址空间分成两半，中间有一个非常大的洞，下半部分是用户空间所在的地方，上半部分是RISC-V Linux +内核所在的地方。 + +RISC-V Linux Kernel SV39 +------------------------ + +:: + + ======================================================================================================================== + 开始地址 | 偏移 | 结束地址 | 大小 | 虚拟内存区域描述 + ======================================================================================================================== + | | | | + 0000000000000000 | 0 | 0000003fffffffff | 256 GB | 用户空间虚拟内存，每个内存管理器不同 + __________________|____________|__________________|_________|___________________________________________________________ + | | | | + 0000004000000000 | +256 GB | ffffffbfffffffff | ~16M TB | ... 巨大的、几乎64位宽的直到内核映射的-256GB地方 + | | | | 开始偏移的非经典虚拟内存地址空洞。 + | | | | + __________________|____________|__________________|_________|___________________________________________________________ + | + | 内核空间的虚拟内存，在所有进程之间共享: + ____________________________________________________________|___________________________________________________________ + | | | | + ffffffc6fee00000 | -228 GB | ffffffc6feffffff | 2 MB | fixmap + ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB | PCI io + ffffffc700000000 | -228 GB | ffffffc7ffffffff | 4 GB | vmemmap + ffffffc800000000 | -224 GB | ffffffd7ffffffff | 64 GB | vmalloc/ioremap space + ffffffd800000000 | -160 GB | fffffff6ffffffff | 124 GB | 直接映射所有物理内存 + fffffff700000000 | -36 GB | fffffffeffffffff | 32 GB | kasan + __________________|____________|__________________|_________|____________________________________________________________ + | + | + ____________________________________________________________|____________________________________________________________ + | | | | + ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF + ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel + __________________|____________|__________________|_________|____________________________________________________________ -- cgit From 0c21751f0a071a6fc94a48598e6c0752a284550c Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Tue, 1 Mar 2022 12:18:25 +0800 Subject: docs/zh_CN: add peci index translation Translate .../pici/index.rst into Chinese Signed-off-by: Yanteng Si Link: https://lore.kernel.org/r/9fdba94417277ae20db7e3b13418584c652be93f.1646108017.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/index.rst | 1 + Documentation/translations/zh_CN/peci/index.rst | 26 +++++++++++++++++++++++++ 2 files changed, 27 insertions(+) create mode 100644 Documentation/translations/zh_CN/peci/index.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 23f8f4c68e83..4cab13c1f69e 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -114,6 +114,7 @@ TODOList: filesystems/index scheduler/index vm/index + peci/index TODOList: diff --git a/Documentation/translations/zh_CN/peci/index.rst b/Documentation/translations/zh_CN/peci/index.rst new file mode 100644 index 000000000000..c536dbe1e1a8 --- /dev/null +++ b/Documentation/translations/zh_CN/peci/index.rst @@ -0,0 +1,26 @@ +.. SPDX-License-Identifier: GPL-2.0-only +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/peci/index.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + +================= +Linux PECI 子系统 +================= + +.. toctree:: + +TODOList +* peci + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` -- cgit From 78cebdb7c612cc62721812daec55bd7aa73f0956 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Tue, 1 Mar 2022 12:18:26 +0800 Subject: docs/zh_CN: add peci subsystem translation Translate .../peci/peci.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/00577790cb16375e0016513e03d06b671006a3da.1646108017.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/peci/index.rst | 4 +- Documentation/translations/zh_CN/peci/peci.rst | 54 +++++++++++++++++++++++++ 2 files changed, 56 insertions(+), 2 deletions(-) create mode 100644 Documentation/translations/zh_CN/peci/peci.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/peci/index.rst b/Documentation/translations/zh_CN/peci/index.rst index c536dbe1e1a8..4f6694c828fa 100644 --- a/Documentation/translations/zh_CN/peci/index.rst +++ b/Documentation/translations/zh_CN/peci/index.rst @@ -15,8 +15,8 @@ Linux PECI 子系统 .. toctree:: -TODOList -* peci + + peci .. only:: subproject and html diff --git a/Documentation/translations/zh_CN/peci/peci.rst b/Documentation/translations/zh_CN/peci/peci.rst new file mode 100644 index 000000000000..a3b4f99b994c --- /dev/null +++ b/Documentation/translations/zh_CN/peci/peci.rst @@ -0,0 +1,54 @@ +.. SPDX-License-Identifier: GPL-2.0-only +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/peci/peci.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + +==== +概述 +==== + +平台环境控制接口（PECI）是英特尔处理器和管理控制器（如底板管理控制器，BMC） +之间的一个通信接口。PECI提供的服务允许管理控制器通过访问各种寄存器来配置、监 +控和调试平台。它定义了一个专门的命令协议，管理控制器作为PECI的发起者，处理器 +作为PECI的响应者。PECI可以用于基于单处理器和多处理器的系统中。 + +注意：英特尔PECI规范没有作为专门的文件发布，而是作为英特尔CPU的外部设计规范 +（EDS）的一部分。外部设计规范通常是不公开的。 + +PECI 线 +--------- + +PECI线接口使用单线进行自锁和数据传输。它不需要任何额外的控制线--物理层是一个 +自锁的单线总线信号，每一个比特都从接近零伏的空闲状态开始驱动、上升边缘。驱动高 +电平信号的持续时间可以确定位值是逻辑 “0” 还是逻辑 “1”。PECI线还包括与每个信 +息建立的可变数据速率。 + +对于PECI线，每个处理器包将在一个定义的范围内利用唯一的、固定的地址，该地址应 +该与处理器插座ID有固定的关系--如果其中一个处理器被移除，它不会影响其余处理器 +的地址。 + +PECI子系统代码内嵌文档 +------------------------ + +该API在以下内核代码中: + +include/linux/peci.h + +drivers/peci/internal.h + +drivers/peci/core.c + +drivers/peci/request.c + +PECI CPU 驱动 API +------------------- + +该API在以下内核代码中: + +drivers/peci/cpu.c -- cgit From fa04150b8ef7f15cb7654c11a24a9a4e0834de33 Mon Sep 17 00:00:00 2001 From: Bagas Sanjaya Date: Mon, 7 Mar 2022 13:33:41 +0700 Subject: Documentation: describe how to apply incremental stable patches The applying patches document (Documentation/process/applying-patches.rst) mentions incremental stable patches, but there is no example of how to apply them. Describe the process. While at it, remove note about incremental patches and move the external link of 5.x.y incremental patches to "Where can I download patches?" section. Signed-off-by: Bagas Sanjaya Link: https://lore.kernel.org/r/20220307063340.256671-1-bagasdotme@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/process/applying-patches.rst | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/applying-patches.rst b/Documentation/process/applying-patches.rst index c2121c1e55d7..c269f5e1a0a3 100644 --- a/Documentation/process/applying-patches.rst +++ b/Documentation/process/applying-patches.rst @@ -249,6 +249,10 @@ The 5.x.y (-stable) and 5.x patches live at https://www.kernel.org/pub/linux/kernel/v5.x/ +The 5.x.y incremental patches live at + + https://www.kernel.org/pub/linux/kernel/v5.x/incr/ + The -rc patches are not stored on the webserver but are generated on demand from git tags such as @@ -308,12 +312,11 @@ versions. If no 5.x.y kernel is available, then the highest numbered 5.x kernel is the current stable kernel. -.. note:: +The -stable team provides normal as well as incremental patches. Below is +how to apply these patches. - The -stable team usually do make incremental patches available as well - as patches against the latest mainline release, but I only cover the - non-incremental ones below. The incremental ones can be found at - https://www.kernel.org/pub/linux/kernel/v5.x/incr/ +Normal patches +~~~~~~~~~~~~~~ These patches are not incremental, meaning that for example the 5.7.3 patch does not apply on top of the 5.7.2 kernel source, but rather on top @@ -331,6 +334,21 @@ Here's a small example:: $ cd .. $ mv linux-5.7.2 linux-5.7.3 # rename the kernel source dir +Incremental patches +~~~~~~~~~~~~~~~~~~~ + +Incremental patches are different: instead of being applied on top +of base 5.x kernel, they are applied on top of previous stable kernel +(5.x.y-1). + +Here's the example to apply these:: + + $ cd ~/linux-5.7.2 # change to the kernel source dir + $ patch -p1 < ../patch-5.7.2-3 # apply the new 5.7.3 patch + $ cd .. + $ mv linux-5.7.2 linux-5.7.3 # rename the kernel source dir + + The -rc kernels =============== -- cgit From a17b0169f29bd25c30750846ac0f1f7b5c13e978 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 7 Mar 2022 16:42:20 +0800 Subject: docs/zh_CN: add devicetree index translation Translate .../devicetree/index.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/0a01f2eee980da02c0810d3d99b95af9013b646f.1646642188.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/devicetree/index.rst | 49 ++++++++++++++++++++++ Documentation/translations/zh_CN/index.rst | 6 ++- 2 files changed, 54 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/devicetree/index.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/devicetree/index.rst b/Documentation/translations/zh_CN/devicetree/index.rst new file mode 100644 index 000000000000..5ca1ae87b57d --- /dev/null +++ b/Documentation/translations/zh_CN/devicetree/index.rst @@ -0,0 +1,49 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/Devicetree/index.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +============================= +Open Firmware 和 Devicetree +============================= + +该文档是整个设备树文档的总目录，标题中多是业内默认的术语，初见就翻译成中文， +晦涩难懂，因此尽量保留，后面翻译其子文档时，可能会根据语境，灵活地翻译为中文。 + +内核Devicetree的使用 +======================= +.. toctree:: + :maxdepth: 1 + +Todolist: + +* usage-model +* of_unittest +* kernel-api + +Devicetree Overlays +=================== +.. toctree:: + :maxdepth: 1 + +Todolist: + +* changesets +* dynamic-resolution-notes +* overlay-notes + +Devicetree Bindings +=================== +.. toctree:: + :maxdepth: 1 + +Todolist: + +* bindings/index diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 4cab13c1f69e..88d8df957a78 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -56,10 +56,14 @@ TODOList: 下列文档描述了内核需要的平台固件相关信息。 +.. toctree:: + :maxdepth: 2 + + devicetree/index + TODOList: * firmware-guide/index -* devicetree/index 应用程序开发人员文档 -------------------- -- cgit From c56481299df3d57a6f874e8dd35dab5e4cfc20e2 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 7 Mar 2022 16:42:21 +0800 Subject: docs/zh_CN: add devicetree usage-model translation Translate .../Devicetree/usage-model.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/abc4bfa5a8eb438013913bf8ea5f8a29e5730f33.1646642188.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/devicetree/index.rst | 4 +- .../translations/zh_CN/devicetree/usage-model.rst | 330 +++++++++++++++++++++ 2 files changed, 333 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/devicetree/usage-model.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/devicetree/index.rst b/Documentation/translations/zh_CN/devicetree/index.rst index 5ca1ae87b57d..6d9ac4254a1c 100644 --- a/Documentation/translations/zh_CN/devicetree/index.rst +++ b/Documentation/translations/zh_CN/devicetree/index.rst @@ -22,9 +22,11 @@ Open Firmware 和 Devicetree .. toctree:: :maxdepth: 1 + usage-model + Todolist: -* usage-model + * of_unittest * kernel-api diff --git a/Documentation/translations/zh_CN/devicetree/usage-model.rst b/Documentation/translations/zh_CN/devicetree/usage-model.rst new file mode 100644 index 000000000000..318a3c6a0114 --- /dev/null +++ b/Documentation/translations/zh_CN/devicetree/usage-model.rst @@ -0,0 +1,330 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/Devicetree/usage-model.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +=================== +Linux 和 Devicetree +=================== + +Linux对设备树数据的使用模型 + +:作者: Grant Likely + +这篇文章描述了Linux如何使用设备树。关于设备树数据格式的概述可以在 +devicetree.org\ [1]_ 的设备树使用页面上找到。 + +.. [1] https://www.devicetree.org/specifications/ + +"Open Firmware Device Tree"，或简称为Devicetree（DT），是一种用于描述硬 +件的数据结构和语言。更确切地说，它是一种操作系统可读的硬件描述，这样操作系统就不 +需要对机器的细节进行硬编码。 + +从结构上看，DT是一棵树，或者说是带有命名节点的无环图，节点可以有任意数量的命名 +属性来封装任意的数据。还存在一种机制，可以在自然的树状结构之外创建从一个节点到 +另一个节点的任意链接。 + +从概念上讲，一套通用的使用惯例，称为 "bindings"（后文译为绑定），被定义为数据 +应该如何出现在树中，以描述典型的硬件特性，包括数据总线、中断线、GPIO连接和外围 +设备。 + +尽可能使用现有的绑定来描述硬件，以最大限度地利用现有的支持代码，但由于属性和节 +点名称是简单的文本字符串，通过定义新的节点和属性来扩展现有的绑定或创建新的绑定 +很容易。然而，要警惕的是，在创建一个新的绑定之前，最好先对已经存在的东西做一些 +功课。目前有两种不同的、不兼容的i2c总线的绑定，这是因为在创建新的绑定时没有事先 +调查i2c设备在现有系统中是如何被枚举的。 + +1. 历史 +------- +DT最初是由Open Firmware创建的，作为将数据从Open Firmware传递给客户程序 +（如传递给操作系统）的通信方法的一部分。操作系统使用设备树在运行时探测硬件的拓 +扑结构，从而在没有硬编码信息的情况下支持大多数可用的硬件（假设所有设备的驱动程 +序都可用）。 + +由于Open Firmware通常在PowerPC和SPARC平台上使用，长期以来，对这些架构的 +Linux支持一直使用设备树。 + +2005年，当PowerPC Linux开始大规模清理并合并32位和64位支持时，决定在所有 +Powerpc平台上要求DT支持，无论它们是否使用Open Firmware。为了做到这一点， +我们创建了一个叫做扁平化设备树（FDT）的DT表示法，它可以作为一个二进制的blob +传递给内核，而不需要真正的Open Firmware实现。U-Boot、kexec和其他引导程序 +被修改，以支持传递设备树二进制（dtb）和在引导时修改dtb。DT也被添加到PowerPC +引导包装器（arch/powerpc/boot/\*）中，这样dtb就可以被包裹在内核镜像中，以 +支持引导现有的非DT察觉的固件。 + +一段时间后，FDT基础架构被普及到了所有的架构中。在写这篇文章的时候，6个主线架 +构（arm、microblaze、mips、powerpc、sparc和x86）和1个非主线架构（ios） +有某种程度的DT支持。 + +1. 数据模型 +----------- +如果你还没有读过设备树用法\ [1]_页，那么现在就去读吧。没关系，我等着.... + +2.1 高层次视角 +-------------- +最重要的是要明白，DT只是一个描述硬件的数据结构。它没有什么神奇之处，也不会神 +奇地让所有的硬件配置问题消失。它所做的是提供一种语言，将硬件配置与Linux内核 +（或任何其他操作系统）中的板卡和设备驱动支持解耦。使用它可以使板卡和设备支持 +变成数据驱动；根据传递到内核的数据做出设置决定，而不是根据每台机器的硬编码选 +择。 + +理想情况下，数据驱动的平台设置应该导致更少的代码重复，并使其更容易用一个内核 +镜像支持各种硬件。 + +Linux使用DT数据有三个主要目的: + +1) 平台识别。 +2) 运行时配置，以及 +3) 设备数量。 + +2.2 平台识别 +------------ +首先，内核将使用DT中的数据来识别特定的机器。在一个理想的世界里，具体的平台对 +内核来说并不重要，因为所有的平台细节都会被设备树以一致和可靠的方式完美描述。 +但是，硬件并不完美，所以内核必须在早期启动时识别机器，以便有机会运行特定于机 +器的修复程序。 + +在大多数情况下，机器的身份是不相关的，而内核将根据机器的核心CPU或SoC来选择 +设置代码。例如，在ARM上，arch/arm/kernel/setup.c中的setup_arch()将调 +用arch/arm/kernel/devtree.c中的setup_machine_fdt()，它通过 +machine_desc表搜索并选择与设备树数据最匹配的machine_desc。它通过查看根 +设备树节点中的'compatible'属性，并将其与struct machine_desc中的 +dt_compat列表（如果你好奇，该列表定义在arch/arm/include/asm/mach/arch.h +中）进行比较，从而确定最佳匹配。 + +“compatible” 属性包含一个排序的字符串列表，以机器的确切名称开始，后面是 +一个可选的与之兼容的板子列表，从最兼容到最不兼容排序。例如，TI BeagleBoard +和它的后继者BeagleBoard xM板的根兼容属性可能看起来分别为:: + + compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3"; + compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3"; + +其中 "ti,map3-beagleboard-xm "指定了确切的型号，它还声称它与OMAP 3450 SoC +以及一般的OMP3系列SoC兼容。你会注意到，该列表从最具体的（确切的板子）到最 +不具体的（SoC系列）进行排序。 + +聪明的读者可能会指出，Beagle xM也可以声称与原Beagle板兼容。然而，我们应 +该当心在板级上这样做，因为通常情况下，即使在同一产品系列中，每块板都有很高 +的变化，而且当一块板声称与另一块板兼容时，很难确定到底是什么意思。对于高层 +来说，最好是谨慎行事，不要声称一块板子与另一块板子兼容。值得注意的例外是， +当一块板子是另一块板子的载体时，例如CPU模块连接到一个载体板上。 + +关于兼容值还有一个注意事项。在兼容属性中使用的任何字符串都必须有文件说明它 +表示什么。在Documentation/devicetree/bindings中添加兼容字符串的文档。 + +同样在ARM上，对于每个machine_desc，内核会查看是否有任何dt_compat列表条 +目出现在兼容属性中。如果有，那么该机器_desc就是驱动该机器的候选者。在搜索 +了整个machine_descs表之后，setup_machine_fdt()根据每个machine_desc +在兼容属性中匹配的条目，返回 “最兼容” 的machine_desc。如果没有找到匹配 +的machine_desc，那么它将返回NULL。 + +这个方案背后的原因是观察到，在大多数情况下，如果它们都使用相同的SoC或相同 +系列的SoC，一个机器_desc可以支持大量的电路板。然而，不可避免地会有一些例 +外情况，即特定的板子需要特殊的设置代码，这在一般情况下是没有用的。特殊情况 +可以通过在通用设置代码中明确检查有问题的板子来处理，但如果超过几个情况下， +这样做很快就会变得很难看和/或无法维护。 + +相反，兼容列表允许通用机器_desc通过在dt_compat列表中指定“不太兼容”的值 +来提供对广泛的通用板的支持。在上面的例子中，通用板支持可以声称与“ti,ompa3” +或“ti,ompa3450”兼容。如果在最初的beagleboard上发现了一个bug，需要在 +早期启动时使用特殊的变通代码，那么可以添加一个新的machine_desc，实现变通， +并且只在“ti,omap3-beagleboard”上匹配。 + +PowerPC使用了一个稍微不同的方案，它从每个机器_desc中调用.probe()钩子， +并使用第一个返回TRUE的钩子。然而，这种方法没有考虑到兼容列表的优先级，对于 +新的架构支持可能应该避免。 + +2.3 运行时配置 +-------------- +在大多数情况下，DT是将数据从固件传递给内核的唯一方法，所以也被用来传递运行 +时和配置数据，如内核参数字符串和initrd镜像的位置。 + +这些数据大部分都包含在/chosen节点中，当启动Linux时，它看起来就像这样:: + + chosen { + bootargs = "console=ttyS0,115200 loglevel=8"; + initrd-start = <0xc8000000>; + initrd-end = <0xc8200000>; + }; + +bootargs属性包含内核参数，initrd-\*属性定义initrd blob的地址和大小。注 +意initrd-end是initrd映像后的第一个地址，所以这与结构体资源的通常语义不一 +致。选择的节点也可以选择包含任意数量的额外属性，用于平台特定的配置数据。 + +在早期启动过程中，架构设置代码通过不同的辅助回调函数多次调用 +of_scan_flat_dt()来解析设备树数据，然后进行分页设置。of_scan_flat_dt() +代码扫描设备树，并使用辅助函数来提取早期启动期间所需的信息。通常情况下， +early_init_dt_scan_chosen()辅助函数用于解析所选节点，包括内核参数， +early_init_dt_scan_root()用于初始化DT地址空间模型，early_init_dt_scan_memory() +用于确定可用RAM的大小和位置。 + +在ARM上，函数setup_machine_fdt()负责在选择支持板子的正确machine_desc +后，对设备树进行早期扫描。 + +2.4 设备数量 +------------ +在电路板被识别后，在早期配置数据被解析后，内核初始化可以以正常方式进行。在 +这个过程中的某个时刻，unflatten_device_tree()被调用以将数据转换成更有 +效的运行时表示。这也是调用机器特定设置钩子的时候，比如ARM上的machine_desc +.init_early()、.init_irq()和.init_machine()钩子。本节的其余部分使用 +了ARM实现的例子，但所有架构在使用DT时都会做几乎相同的事情。 + +从名称上可以猜到，.init_early()用于在启动过程早期需要执行的任何机器特定设 +置，而.init_irq()则用于设置中断处理。使用DT并不会实质性地改变这两个函数的 +行为。如果提供了DT，那么.init_early()和.init_irq()都能调用任何一个DT查 +询函数（of_* in include/linux/of*.h），以获得关于平台的额外数据。 + +DT上下文中最有趣的钩子是.init_machine()，它主要负责将平台的数据填充到 +Linux设备模型中。历史上，这在嵌入式平台上是通过在板卡support .c文件中定 +义一组静态时钟结构、platform_devices和其他数据，并在.init_machine()中 +大量注册来实现的。当使用DT时，就不用为每个平台的静态设备进行硬编码，可以通过 +解析DT获得设备列表，并动态分配设备结构体。 + +最简单的情况是，.init_machine()只负责注册一个platform_devices。 +platform_device是Linux使用的一个概念，用于不能被硬件检测到的内存或I/O映 +射的设备，以及“复合”或 “虚拟”设备（后面会详细介绍）。虽然DT没有“平台设备”的 +术语，但平台设备大致对应于树根的设备节点和简单内存映射总线节点的子节点。 + +现在是举例说明的好时机。下面是NVIDIA Tegra板的设备树的一部分:: + + /{ + compatible = "nvidia,harmony", "nvidia,tegra20"; + #address-cells = <1>; + #size-cells = <1>; + interrupt-parent = <&intc>; + + chosen { }; + aliases { }; + + memory { + device_type = "memory"; + reg = <0x00000000 0x40000000>; + }; + + soc { + compatible = "nvidia,tegra20-soc", "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + intc: interrupt-controller@50041000 { + compatible = "nvidia,tegra20-gic"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x50041000 0x1000>, < 0x50040100 0x0100 >; + }; + + serial@70006300 { + compatible = "nvidia,tegra20-uart"; + reg = <0x70006300 0x100>; + interrupts = <122>; + }; + + i2s1: i2s@70002800 { + compatible = "nvidia,tegra20-i2s"; + reg = <0x70002800 0x100>; + interrupts = <77>; + codec = <&wm8903>; + }; + + i2c@7000c000 { + compatible = "nvidia,tegra20-i2c"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x7000c000 0x100>; + interrupts = <70>; + + wm8903: codec@1a { + compatible = "wlf,wm8903"; + reg = <0x1a>; + interrupts = <347>; + }; + }; + }; + + sound { + compatible = "nvidia,harmony-sound"; + i2s-controller = <&i2s1>; + i2s-codec = <&wm8903>; + }; + }; + +在.init_machine()时，Tegra板支持代码将需要查看这个DT，并决定为哪些节点 +创建platform_devices。然而，看一下这个树，并不能立即看出每个节点代表什么 +类型的设备，甚至不能看出一个节点是否代表一个设备。/chosen、/aliases和 +/memory节点是信息节点，并不描述设备（尽管可以说内存可以被认为是一个设备）。 +/soc节点的子节点是内存映射的设备，但是codec@1a是一个i2c设备，而sound节 +点代表的不是一个设备，而是其他设备是如何连接在一起以创建音频子系统的。我知 +道每个设备是什么，因为我熟悉电路板的设计，但是内核怎么知道每个节点该怎么做？ + +诀窍在于，内核从树的根部开始，寻找具有“兼容”属性的节点。首先，一般认为任何 +具有“兼容”属性的节点都代表某种设备；其次，可以认为树根的任何节点要么直接连 +接到处理器总线上，要么是无法用其他方式描述的杂项系统设备。对于这些节点中的 +每一个，Linux都会分配和注册一个platform_device，它又可能被绑定到一个 +platform_driver。 + +为什么为这些节点使用platform_device是一个安全的假设？嗯，就Linux对设备 +的建模方式而言，几乎所有的总线类型都假定其设备是总线控制器的孩子。例如，每 +个i2c_client是i2c_master的一个子节点。每个spi_device都是SPI总线的一 +个子节点。类似的还有USB、PCI、MDIO等。同样的层次结构也出现在DT中，I2C设 +备节点只作为I2C总线节点的子节点出现。同理，SPI、MDIO、USB等等。唯一不需 +要特定类型的父设备的设备是platform_devices（和amba_devices，但后面会 +详细介绍），它们将愉快地运行在Linux/sys/devices树的底部。因此，如果一个 +DT节点位于树的根部，那么它真的可能最好注册为platform_device。 + +Linux板支持代码调用of_platform_populate(NULL, NULL, NULL, NULL)来 +启动树根的设备发现。参数都是NULL，因为当从树的根部开始时，不需要提供一个起 +始节点（第一个NULL），一个父结构设备（最后一个NULL），而且我们没有使用匹配 +表（尚未）。对于只需要注册设备的板子，除了of_platform_populate()的调用， +.init_machine()可以完全为空。 + +在Tegra的例子中，这说明了/soc和/sound节点，但是SoC节点的子节点呢？它们 +不应该也被注册为平台设备吗？对于Linux DT支持，一般的行为是子设备在驱动 +.probe()时被父设备驱动注册。因此，一个i2c总线设备驱动程序将为每个子节点 +注册一个i2c_client，一个SPI总线驱动程序将注册其spi_device子节点，其他 +总线类型也是如此。根据该模型，可以编写一个与SoC节点绑定的驱动程序，并简单 +地为其每个子节点注册platform_device。板卡支持代码将分配和注册一个SoC设 +备，一个（理论上的）SoC设备驱动程序可以绑定到SoC设备，并在其.probe()钩 +中为/soc/interruptcontroller、/soc/serial、/soc/i2s和/soc/i2c注 +册platform_devices。很简单，对吗？ + +实际上，事实证明，将一些platform_device的子设备注册为更多的platform_device +是一种常见的模式，设备树支持代码反映了这一点，并使上述例子更简单。 +of_platform_populate()的第二个参数是一个of_device_id表，任何与该表 +中的条目相匹配的节点也将获得其子节点的注册。在Tegra的例子中，代码可以是 +这样的:: + + static void __init harmony_init_machine(void) + { + /* ... */ + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); + } + +“simple-bus”在Devicetree规范中被定义为一个属性，意味着一个简单的内存映射 +的总线，所以of_platform_populate()代码可以被写成只是假设简单总线兼容的节 +点将总是被遍历。然而，我们把它作为一个参数传入，以便电路板支持代码可以随时覆 +盖默认行为。 + +[需要添加关于添加i2c/spi/etc子设备的讨论] 。 + +附录A：AMBA设备 +--------------- + +ARM Primecell是连接到ARM AMBA总线的某种设备，它包括对硬件检测和电源管理 +的一些支持。在Linux中，amba_device和amba_bus_type结构体被用来表示 +Primecell设备。然而，棘手的一点是，AMBA总线上的所有设备并非都是Primecell， +而且对于Linux来说，典型的情况是amba_device和platform_device实例都是同 +一总线段的同义词。 + +当使用DT时，这给of_platform_populate()带来了问题，因为它必须决定是否将 +每个节点注册为platform_device或amba_device。不幸的是，这使设备创建模型 +变得有点复杂，但解决方案原来并不是太具有侵略性。如果一个节点与“arm,amba-primecell” +兼容，那么of_platform_populate()将把它注册为amba_device而不是 +platform_device。 -- cgit From 09d4466d3f3c72e3c1d1277839e0f98283e31d1e Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 7 Mar 2022 16:42:22 +0800 Subject: docs/zh_CN: add devicetree of_unittest translation Translate .../Devicetree/of_unittest.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/da75225df2ac7bee8de653d95b2a872510b34f7d.1646642188.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/devicetree/index.rst | 3 +- .../translations/zh_CN/devicetree/of_unittest.rst | 189 +++++++++++++++++++++ 2 files changed, 190 insertions(+), 2 deletions(-) create mode 100644 Documentation/translations/zh_CN/devicetree/of_unittest.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/devicetree/index.rst b/Documentation/translations/zh_CN/devicetree/index.rst index 6d9ac4254a1c..23d0b6fccd58 100644 --- a/Documentation/translations/zh_CN/devicetree/index.rst +++ b/Documentation/translations/zh_CN/devicetree/index.rst @@ -23,11 +23,10 @@ Open Firmware 和 Devicetree :maxdepth: 1 usage-model + of_unittest Todolist: - -* of_unittest * kernel-api Devicetree Overlays diff --git a/Documentation/translations/zh_CN/devicetree/of_unittest.rst b/Documentation/translations/zh_CN/devicetree/of_unittest.rst new file mode 100644 index 000000000000..abd94e771ef8 --- /dev/null +++ b/Documentation/translations/zh_CN/devicetree/of_unittest.rst @@ -0,0 +1,189 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/Devicetree/of_unittest.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + +================================= +Open Firmware Devicetree 单元测试 +================================= + +作者: Gaurav Minocha + +1. 概述 +======= + +本文档解释了执行 OF 单元测试所需的测试数据是如何动态地附加到实时树上的，与机器的架构无关。 + +建议在继续读下去之前，先阅读以下文件。 + +(1) Documentation/devicetree/usage-model.rst +(2) http://www.devicetree.org/Device_Tree_Usage + +OF Selftest被设计用来测试提供给设备驱动开发者的接口（include/linux/of.h），以从未扁平 +化的设备树数据结构中获取设备信息等。这个接口被大多数设备驱动在各种使用情况下使用。 + + +2. 测试数据 +=========== + +设备树源文件（drivers/of/unittest-data/testcases.dts）包含执行drivers/of/unittest.c +中自动化单元测试所需的测试数据。目前，以下设备树源包含文件（.dtsi）被包含在testcases.dt中:: + + drivers/of/unittest-data/tests-interrupts.dtsi + drivers/of/unittest-data/tests-platform.dtsi + drivers/of/unittest-data/tests-phandle.dtsi + drivers/of/unittest-data/tests-match.dtsi + +当内核在启用OF_SELFTEST的情况下被构建时，那么下面的make规则:: + + $(obj)/%.dtb: $(src)/%.dts FORCE + $(call if_changed_dep, dtc) + +用于将DT源文件（testcases.dts）编译成二进制blob（testcases.dtb），也被称为扁平化的DT。 + +之后，使用以下规则将上述二进制blob包装成一个汇编文件（testcases.dtb.S）:: + + $(obj)/%.dtb.S: $(obj)/%.dtb + $(call cmd, dt_S_dtb) + +汇编文件被编译成一个对象文件（testcases.dtb.o），并被链接到内核镜像中。 + + +2.1. 添加测试数据 +----------------- + +未扁平化的设备树结构体: + +未扁平化的设备树由连接的设备节点组成，其树状结构形式如下所述:: + + // following struct members are used to construct the tree + struct device_node { + ... + struct device_node *parent; + struct device_node *child; + struct device_node *sibling; + ... + }; + +图1描述了一个机器的未扁平化设备树的通用结构，只考虑了子节点和同级指针。存在另一个指针， +``*parent`` ，用于反向遍历该树。因此，在一个特定的层次上，子节点和所有的兄弟姐妹节点将 +有一个指向共同节点的父指针（例如，child1、sibling2、sibling3、sibling4的父指针指向 +根节点）:: + + root ('/') + | + child1 -> sibling2 -> sibling3 -> sibling4 -> null + | | | | + | | | null + | | | + | | child31 -> sibling32 -> null + | | | | + | | null null + | | + | child21 -> sibling22 -> sibling23 -> null + | | | | + | null null null + | + child11 -> sibling12 -> sibling13 -> sibling14 -> null + | | | | + | | | null + | | | + null null child131 -> null + | + null + +Figure 1: 未扁平化的设备树的通用结构 + + +在执行OF单元测试之前，需要将测试数据附加到机器的设备树上（如果存在）。因此，当调用 +selftest_data_add()时，首先会读取通过以下内核符号链接到内核镜像中的扁平化设备树 +数据:: + + __dtb_testcases_begin - address marking the start of test data blob + __dtb_testcases_end - address marking the end of test data blob + +其次，它调用of_fdt_unflatten_tree()来解除扁平化的blob。最后，如果机器的设备树 +（即实时树）是存在的，那么它将未扁平化的测试数据树附加到实时树上，否则它将自己作为 +实时设备树附加。 + +attach_node_and_children()使用of_attach_node()将节点附加到实时树上，如下所 +述。为了解释这一点，图2中描述的测试数据树被附加到图1中描述的实时树上:: + + root ('/') + | + testcase-data + | + test-child0 -> test-sibling1 -> test-sibling2 -> test-sibling3 -> null + | | | | + test-child01 null null null + + +Figure 2: 将测试数据树附在实时树上的例子。 + +根据上面的方案，实时树已经存在，所以不需要附加根('/')节点。所有其他节点都是通过在 +每个节点上调用of_attach_node()来附加的。 + +在函数of_attach_node()中，新的节点被附在实时树中给定的父节点的子节点上。但是，如 +果父节点已经有了一个孩子，那么新节点就会取代当前的孩子，并将其变成其兄弟姐妹。因此， +当测试案例的数据节点被连接到上面的实时树（图1）时，最终的结构如图3所示:: + + root ('/') + | + testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null + | | | | | + (...) | | | null + | | child31 -> sibling32 -> null + | | | | + | | null null + | | + | child21 -> sibling22 -> sibling23 -> null + | | | | + | null null null + | + child11 -> sibling12 -> sibling13 -> sibling14 -> null + | | | | + null null | null + | + child131 -> null + | + null + ----------------------------------------------------------------------- + + root ('/') + | + testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null + | | | | | + | (...) (...) (...) null + | + test-sibling3 -> test-sibling2 -> test-sibling1 -> test-child0 -> null + | | | | + null null null test-child01 + + +Figure 3: 附加测试案例数据后的实时设备树结构。 + + +聪明的读者会注意到，与先前的结构相比，test-child0节点成为最后一个兄弟姐妹（图2）。 +在连接了第一个test-child0节点之后，又连接了test-sibling1节点，该节点推动子节点 +（即test-child0）成为兄弟姐妹，并使自己成为子节点，如上所述。 + +如果发现一个重复的节点（即如果一个具有相同full_name属性的节点已经存在于实时树中）， +那么该节点不会被附加，而是通过调用函数update_node_properties()将其属性更新到活 +树的节点中。 + + +2.2. 删除测试数据 +----------------- + +一旦测试用例执行完，selftest_data_remove被调用，以移除最初连接的设备节点（首先是 +叶子节点被分离，然后向上移动父节点被移除，最后是整个树）。selftest_data_remove() +调用detach_node_and_children()，使用of_detach_node()将节点从实时设备树上分离。 + +为了分离一个节点，of_detach_node()要么将给定节点的父节点的子节点指针更新为其同级节 +点，要么根据情况将前一个同级节点附在给定节点的同级节点上。就这样吧。 :) -- cgit From d29360ff239cd83aaf74897e3abfa7cd6dc2b06c Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Wed, 9 Mar 2022 23:36:59 +0800 Subject: docs/zh_CN: Add sched-stats Chinese translation Translate scheduler/sched-stats.rst into Chinese. Signed-off-by: Tang Yizhou Reviewed-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/20220309153659.24437-1-tangyizhou@huawei.com Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/scheduler/index.rst | 3 +- .../translations/zh_CN/scheduler/sched-stats.rst | 156 +++++++++++++++++++++ 2 files changed, 157 insertions(+), 2 deletions(-) create mode 100644 Documentation/translations/zh_CN/scheduler/sched-stats.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/scheduler/index.rst b/Documentation/translations/zh_CN/scheduler/index.rst index ab7925980266..c020f8382785 100644 --- a/Documentation/translations/zh_CN/scheduler/index.rst +++ b/Documentation/translations/zh_CN/scheduler/index.rst @@ -25,14 +25,13 @@ Linux调度器 sched-domains sched-capacity sched-energy - + sched-stats TODOList: sched-deadline sched-nice-design sched-rt-group - sched-stats text_files diff --git a/Documentation/translations/zh_CN/scheduler/sched-stats.rst b/Documentation/translations/zh_CN/scheduler/sched-stats.rst new file mode 100644 index 000000000000..1c68c3d1c283 --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/sched-stats.rst @@ -0,0 +1,156 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/sched-stats.rst + +:翻译: + + 唐艺舟 Tang Yizhou + +============== +调度器统计数据 +============== + +第15版schedstats去掉了sched_yield的一些计数器：yld_exp_empty，yld_act_empty +和yld_both_empty。在其它方面和第14版完全相同。 + +第14版schedstats包括对sched_domains（译注：调度域）的支持，该特性进入内核 +主线2.6.20，不过这一版schedstats与2.6.13-2.6.19内核的版本12的统计数据是完全 +相同的（内核未发布第13版）。有些计数器按每个运行队列统计是更有意义的，其它则 +按每个调度域统计是更有意义的。注意，调度域（以及它们的附属信息）仅在开启 +CONFIG_SMP的机器上是相关的和可用的。 + +在第14版schedstat中，每个被列出的CPU至少会有一级域统计数据，且很可能有一个 +以上的域。在这个实现中，域没有特别的名字，但是编号最高的域通常在机器上所有的 +CPU上仲裁平衡，而domain0是最紧密聚焦的域，有时仅在一对CPU之间进行平衡。此时， +没有任何体系结构需要3层以上的域。域统计数据中的第一个字段是一个位图，表明哪些 +CPU受该域的影响。 + +这些字段是计数器，而且只能递增。使用这些字段的程序将需要从基线观测开始，然后在 +后续每一个观测中计算出计数器的变化。一个能以这种方式处理其中很多字段的perl脚本 +可见 + + http://eaglet.pdxhosts.com/rick/linux/schedstat/ + +请注意，任何这样的脚本都必须是特定于版本的，改变版本的主要原因是输出格式的变化。 +对于那些希望编写自己的脚本的人，可以参考这里描述的各个字段。 + +CPU统计数据 +----------- +cpu 1 2 3 4 5 6 7 8 9 + +第一个字段是sched_yield()的统计数据： + + 1) sched_yield()被调用了#次 + +接下来的三个是schedule()的统计数据： + + 2) 这个字段是一个过时的数组过期计数，在O(1)调度器中使用。为了ABI兼容性， + 我们保留了它，但它总是被设置为0。 + 3) schedule()被调用了#次 + 4) 调用schedule()导致处理器变为空闲了#次 + +接下来的两个是try_to_wake_up()的统计数据： + + 5) try_to_wake_up()被调用了#次 + 6) 调用try_to_wake_up()导致本地CPU被唤醒了#次 + +接下来的三个统计数据描述了调度延迟： + + 7) 本处理器运行任务的总时间，单位是jiffies + 8) 本处理器任务等待运行的时间，单位是jiffies + 9) 本CPU运行了#个时间片 + +域统计数据 +---------- + +对于每个被描述的CPU，和它相关的每一个调度域均会产生下面一行数据（注意，如果 +CONFIG_SMP没有被定义，那么*没有*调度域被使用，这些行不会出现在输出中）。 + +domain 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 + +第一个字段是一个位掩码，表明该域在操作哪些CPU。 + +接下来的24个字段是load_balance()函数的各个统计数据，按空闲类型分组（空闲， +繁忙，新空闲）： + + + 1) 当CPU空闲时，load_balance()在这个调度域中被调用了#次 + 2) 当CPU空闲时，load_balance()在这个调度域中被调用，但是发现负载无需 + 均衡#次 + 3) 当CPU空闲时，load_balance()在这个调度域中被调用，试图迁移1个或更多 + 任务且失败了#次 + 4) 当CPU空闲时，load_balance()在这个调度域中被调用，发现不均衡（如果有） + #次 + 5) 当CPU空闲时，pull_task()在这个调度域中被调用#次 + 6) 当CPU空闲时，尽管目标任务是热缓存状态，pull_task()依然被调用#次 + 7) 当CPU空闲时，load_balance()在这个调度域中被调用，未能找到更繁忙的 + 队列#次 + 8) 当CPU空闲时，在调度域中找到了更繁忙的队列，但未找到更繁忙的调度组 + #次 + 9) 当CPU繁忙时，load_balance()在这个调度域中被调用了#次 + 10) 当CPU繁忙时，load_balance()在这个调度域中被调用，但是发现负载无需 + 均衡#次 + 11) 当CPU繁忙时，load_balance()在这个调度域中被调用，试图迁移1个或更多 + 任务且失败了#次 + 12) 当CPU繁忙时，load_balance()在这个调度域中被调用，发现不均衡（如果有） + #次 + 13) 当CPU繁忙时，pull_task()在这个调度域中被调用#次 + 14) 当CPU繁忙时，尽管目标任务是热缓存状态，pull_task()依然被调用#次 + 15) 当CPU繁忙时，load_balance()在这个调度域中被调用，未能找到更繁忙的 + 队列#次 + 16) 当CPU繁忙时，在调度域中找到了更繁忙的队列，但未找到更繁忙的调度组 + #次 + 17) 当CPU新空闲时，load_balance()在这个调度域中被调用了#次 + 18) 当CPU新空闲时，load_balance()在这个调度域中被调用，但是发现负载无需 + 均衡#次 + 19) 当CPU新空闲时，load_balance()在这个调度域中被调用，试图迁移1个或更多 + 任务且失败了#次 + 20) 当CPU新空闲时，load_balance()在这个调度域中被调用，发现不均衡（如果有） + #次 + 21) 当CPU新空闲时，pull_task()在这个调度域中被调用#次 + 22) 当CPU新空闲时，尽管目标任务是热缓存状态，pull_task()依然被调用#次 + 23) 当CPU新空闲时，load_balance()在这个调度域中被调用，未能找到更繁忙的 + 队列#次 + 24) 当CPU新空闲时，在调度域中找到了更繁忙的队列，但未找到更繁忙的调度组 + #次 + +接下来的3个字段是active_load_balance()函数的各个统计数据： + + 25) active_load_balance()被调用了#次 + 26) active_load_balance()被调用，试图迁移1个或更多任务且失败了#次 + 27) active_load_balance()被调用，成功迁移了#次任务 + +接下来的3个字段是sched_balance_exec()函数的各个统计数据： + + 28) sbe_cnt不再被使用 + 29) sbe_balanced不再被使用 + 30) sbe_pushed不再被使用 + +接下来的3个字段是sched_balance_fork()函数的各个统计数据： + + 31) sbf_cnt不再被使用 + 32) sbf_balanced不再被使用 + 33) sbf_pushed不再被使用 + +接下来的3个字段是try_to_wake_up()函数的各个统计数据： + + 34) 在这个调度域中调用try_to_wake_up()唤醒任务时，任务在调度域中一个 + 和上次运行不同的新CPU上运行了#次 + 35) 在这个调度域中调用try_to_wake_up()唤醒任务时，任务被迁移到发生唤醒 + 的CPU次数为#，因为该任务在原CPU是冷缓存状态 + 36) 在这个调度域中调用try_to_wake_up()唤醒任务时，引发被动负载均衡#次 + +/proc//schedstat +--------------------- +schedstats还添加了一个新的/proc//schedstat文件，来提供一些进程级的 +相同信息。这个文件中，有三个字段与该进程相关： + + 1) 在CPU上运行花费的时间 + 2) 在运行队列上等待的时间 + 3) 在CPU上运行了#个时间片 + +可以很容易地编写一个程序，利用这些额外的字段来报告一个特定的进程或一组进程在 +调度器策略下的表现如何。这样的程序的一个简单版本可在下面的链接找到 + + http://eaglet.pdxhosts.com/rick/linux/schedstat/v12/latency.c -- cgit From 1d38fe6ee6a874675ca3bba6b48e69a0e6176ffc Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Thu, 24 Feb 2022 16:47:43 -0600 Subject: PCI/VGA: Move vgaarb to drivers/pci The VGA arbiter is really PCI-specific and doesn't depend on any GPU things. Move it to the PCI subsystem. Note that misc_init() must be called before vga_arb_device_init(). These are both subsys_initcalls, so this ordering depends on the link order, which is determined by drivers/Makefile: obj-y += pci/ obj-y += char/ <-- misc_init() obj-y += gpu/ <-- vga_arb_device_init() (before this commit) The drivers/pci/ subsys_initcalls are called *before* misc_init(), so convert vga_arb_device_init() to subsys_initcall_sync(), which is called after *all* subsys_initcalls. Link: https://lore.kernel.org/r/20220224224753.297579-2-helgaas@kernel.org Signed-off-by: Bjorn Helgaas --- Documentation/gpu/vgaarbiter.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/gpu/vgaarbiter.rst b/Documentation/gpu/vgaarbiter.rst index 339ed5fecd2e..bde3c0afb059 100644 --- a/Documentation/gpu/vgaarbiter.rst +++ b/Documentation/gpu/vgaarbiter.rst @@ -100,7 +100,7 @@ In-kernel interface .. kernel-doc:: include/linux/vgaarb.h :internal: -.. kernel-doc:: drivers/gpu/vga/vgaarb.c +.. kernel-doc:: drivers/pci/vgaarb.c :export: libpciaccess -- cgit From 2bec6d9aa89cbe97deb6fbc64708212b780605a4 Mon Sep 17 00:00:00 2001 From: Kajol Jain Date: Fri, 25 Feb 2022 20:00:24 +0530 Subject: docs: ABI: sysfs-bus-nvdimm: Document sysfs event format entries for nvdimm pmu Details are added for the event, cpumask and format attributes in the ABI documentation. Acked-by: Peter Zijlstra (Intel) Tested-by: Nageswara R Sastry Signed-off-by: Kajol Jain Reviewed-by: Madhavan Srinivasan Link: https://lore.kernel.org/r/20220225143024.47947-5-kjain@linux.ibm.com Signed-off-by: Dan Williams --- Documentation/ABI/testing/sysfs-bus-nvdimm | 35 ++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-nvdimm b/Documentation/ABI/testing/sysfs-bus-nvdimm index bff84a16812a..1c1f5acbf53d 100644 --- a/Documentation/ABI/testing/sysfs-bus-nvdimm +++ b/Documentation/ABI/testing/sysfs-bus-nvdimm @@ -6,3 +6,38 @@ Description: The libnvdimm sub-system implements a common sysfs interface for platform nvdimm resources. See Documentation/driver-api/nvdimm/. + +What: /sys/bus/event_source/devices/nmemX/format +Date: February 2022 +KernelVersion: 5.18 +Contact: Kajol Jain +Description: (RO) Attribute group to describe the magic bits + that go into perf_event_attr.config for a particular pmu. + (See ABI/testing/sysfs-bus-event_source-devices-format). + + Each attribute under this group defines a bit range of the + perf_event_attr.config. Supported attribute is listed + below:: + event = "config:0-4" - event ID + + For example:: + ctl_res_cnt = "event=0x1" + +What: /sys/bus/event_source/devices/nmemX/events +Date: February 2022 +KernelVersion: 5.18 +Contact: Kajol Jain +Description: (RO) Attribute group to describe performance monitoring events + for the nvdimm memory device. Each attribute in this group + describes a single performance monitoring event supported by + this nvdimm pmu. The name of the file is the name of the event. + (See ABI/testing/sysfs-bus-event_source-devices-events). A + listing of the events supported by a given nvdimm provider type + can be found in Documentation/driver-api/nvdimm/$provider. + +What: /sys/bus/event_source/devices/nmemX/cpumask +Date: February 2022 +KernelVersion: 5.18 +Contact: Kajol Jain +Description: (RO) This sysfs file exposes the cpumask which is designated to + to retrieve nvdimm pmu event counter data. -- cgit From 65466904b015f6eeb9225b51aeb29b01a1d4b59c Mon Sep 17 00:00:00 2001 From: Eric Dumazet Date: Tue, 8 Mar 2022 17:57:57 -0800 Subject: tcp: adjust TSO packet sizes based on min_rtt Back when tcp_tso_autosize() and TCP pacing were introduced, our focus was really to reduce burst sizes for long distance flows. The simple heuristic of using sk_pacing_rate/1024 has worked well, but can lead to too small packets for hosts in the same rack/cluster, when thousands of flows compete for the bottleneck. Neal Cardwell had the idea of making the TSO burst size a function of both sk_pacing_rate and tcp_min_rtt() Indeed, for local flows, sending bigger bursts is better to reduce cpu costs, as occasional losses can be repaired quite fast. This patch is based on Neal Cardwell implementation done more than two years ago. bbr is adjusting max_pacing_rate based on measured bandwidth, while cubic would over estimate max_pacing_rate. /proc/sys/net/ipv4/tcp_tso_rtt_log can be used to tune or disable this new feature, in logarithmic steps. Tested: 100Gbit NIC, two hosts in the same rack, 4K MTU. 600 flows rate-limited to 20000000 bytes per second. Before patch: (TSO sizes would be limited to 20000000/1024/4096 -> 4 segments per TSO) ~# echo 0 >/proc/sys/net/ipv4/tcp_tso_rtt_log ~# nstat -n;perf stat ./super_netperf 600 -H otrv6 -l 20 -- -K dctcp -q 20000000;nstat|egrep "TcpInSegs|TcpOutSegs|TcpRetransSegs|Delivered" 96005 Performance counter stats for './super_netperf 600 -H otrv6 -l 20 -- -K dctcp -q 20000000': 65,945.29 msec task-clock # 2.845 CPUs utilized 1,314,632 context-switches # 19935.279 M/sec 5,292 cpu-migrations # 80.249 M/sec 940,641 page-faults # 14264.023 M/sec 201,117,030,926 cycles # 3049769.216 GHz (83.45%) 17,699,435,405 stalled-cycles-frontend # 8.80% frontend cycles idle (83.48%) 136,584,015,071 stalled-cycles-backend # 67.91% backend cycles idle (83.44%) 53,809,530,436 instructions # 0.27 insn per cycle # 2.54 stalled cycles per insn (83.36%) 9,062,315,523 branches # 137422329.563 M/sec (83.22%) 153,008,621 branch-misses # 1.69% of all branches (83.32%) 23.182970846 seconds time elapsed TcpInSegs 15648792 0.0 TcpOutSegs 58659110 0.0 # Average of 3.7 4K segments per TSO packet TcpExtTCPDelivered 58654791 0.0 TcpExtTCPDeliveredCE 19 0.0 After patch: ~# echo 9 >/proc/sys/net/ipv4/tcp_tso_rtt_log ~# nstat -n;perf stat ./super_netperf 600 -H otrv6 -l 20 -- -K dctcp -q 20000000;nstat|egrep "TcpInSegs|TcpOutSegs|TcpRetransSegs|Delivered" 96046 Performance counter stats for './super_netperf 600 -H otrv6 -l 20 -- -K dctcp -q 20000000': 48,982.58 msec task-clock # 2.104 CPUs utilized 186,014 context-switches # 3797.599 M/sec 3,109 cpu-migrations # 63.472 M/sec 941,180 page-faults # 19214.814 M/sec 153,459,763,868 cycles # 3132982.807 GHz (83.56%) 12,069,861,356 stalled-cycles-frontend # 7.87% frontend cycles idle (83.32%) 120,485,917,953 stalled-cycles-backend # 78.51% backend cycles idle (83.24%) 36,803,672,106 instructions # 0.24 insn per cycle # 3.27 stalled cycles per insn (83.18%) 5,947,266,275 branches # 121417383.427 M/sec (83.64%) 87,984,616 branch-misses # 1.48% of all branches (83.43%) 23.281200256 seconds time elapsed TcpInSegs 1434706 0.0 TcpOutSegs 58883378 0.0 # Average of 41 4K segments per TSO packet TcpExtTCPDelivered 58878971 0.0 TcpExtTCPDeliveredCE 9664 0.0 Signed-off-by: Eric Dumazet Reviewed-by: Neal Cardwell Link: https://lore.kernel.org/r/20220309015757.2532973-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski --- Documentation/networking/ip-sysctl.rst | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 2572eecc3e86..b0024aa7b051 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -878,6 +878,29 @@ tcp_min_tso_segs - INTEGER Default: 2 +tcp_tso_rtt_log - INTEGER + Adjustment of TSO packet sizes based on min_rtt + + Starting from linux-5.18, TCP autosizing can be tweaked + for flows having small RTT. + + Old autosizing was splitting the pacing budget to send 1024 TSO + per second. + + tso_packet_size = sk->sk_pacing_rate / 1024; + + With the new mechanism, we increase this TSO sizing using: + + distance = min_rtt_usec / (2^tcp_tso_rtt_log) + tso_packet_size += gso_max_size >> distance; + + This means that flows between very close hosts can use bigger + TSO packets, reducing their cpu costs. + + If you want to use the old autosizing, set this sysctl to 0. + + Default: 9 (2^9 = 512 usec) + tcp_pacing_ss_ratio - INTEGER sk->sk_pacing_rate is set by TCP stack using a ratio applied to current rate. (current_rate = cwnd * mss / srtt) -- cgit From 213556235526abffe4b7fdec2aabf4d751a7c0f9 Mon Sep 17 00:00:00 2001 From: Conor Dooley Date: Mon, 14 Feb 2022 13:58:31 +0000 Subject: dt-bindings: soc/microchip: update syscontroller compatibles The Polarfire SoC is currently using two different compatible string prefixes. Fix this by changing "polarfire-soc-*" strings to "mpfs-*" in its system controller in order to match the compatible string used in the soc binding and device tree Reviewed-by: Geert Uytterhoeven Signed-off-by: Conor Dooley Acked-by: Rob Herring Acked-by: Palmer Dabbelt Signed-off-by: Palmer Dabbelt --- .../bindings/mailbox/microchip,mpfs-mailbox.yaml | 47 ++++++++++++++++++++++ .../mailbox/microchip,polarfire-soc-mailbox.yaml | 47 ---------------------- .../microchip/microchip,mpfs-sys-controller.yaml | 35 ++++++++++++++++ .../microchip,polarfire-soc-sys-controller.yaml | 35 ---------------- 4 files changed, 82 insertions(+), 82 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml delete mode 100644 Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml create mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml delete mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml new file mode 100644 index 000000000000..082d397d3e89 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mailbox/microchip,mpfs-mailbox.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) mailbox controller + +maintainers: + - Conor Dooley + +properties: + compatible: + const: microchip,mpfs-mailbox + + reg: + items: + - description: mailbox data registers + - description: mailbox interrupt registers + + interrupts: + maxItems: 1 + + "#mbox-cells": + const: 1 + +required: + - compatible + - reg + - interrupts + - "#mbox-cells" + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + mbox: mailbox@37020000 { + compatible = "microchip,mpfs-mailbox"; + reg = <0x0 0x37020000 0x0 0x1000>, <0x0 0x2000318c 0x0 0x40>; + interrupt-parent = <&L1>; + interrupts = <96>; + #mbox-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml deleted file mode 100644 index bbb173ea483c..000000000000 --- a/Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml +++ /dev/null @@ -1,47 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: "http://devicetree.org/schemas/mailbox/microchip,polarfire-soc-mailbox.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" - -title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) mailbox controller - -maintainers: - - Conor Dooley - -properties: - compatible: - const: microchip,polarfire-soc-mailbox - - reg: - items: - - description: mailbox data registers - - description: mailbox interrupt registers - - interrupts: - maxItems: 1 - - "#mbox-cells": - const: 1 - -required: - - compatible - - reg - - interrupts - - "#mbox-cells" - -additionalProperties: false - -examples: - - | - soc { - #address-cells = <2>; - #size-cells = <2>; - mbox: mailbox@37020000 { - compatible = "microchip,polarfire-soc-mailbox"; - reg = <0x0 0x37020000 0x0 0x1000>, <0x0 0x2000318c 0x0 0x40>; - interrupt-parent = <&L1>; - interrupts = <96>; - #mbox-cells = <1>; - }; - }; diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml new file mode 100644 index 000000000000..f699772fedf3 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/microchip/microchip,mpfs-sys-controller.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) system controller + +maintainers: + - Conor Dooley + +description: | + The PolarFire SoC system controller is communicated with via a mailbox. + This document describes the bindings for the client portion of that mailbox. + + +properties: + mboxes: + maxItems: 1 + + compatible: + const: microchip,mpfs-sys-controller + +required: + - compatible + - mboxes + +additionalProperties: false + +examples: + - | + syscontroller: syscontroller { + compatible = "microchip,mpfs-sys-controller"; + mboxes = <&mbox 0>; + }; diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml deleted file mode 100644 index 2cd3bc6bd8d6..000000000000 --- a/Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml +++ /dev/null @@ -1,35 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: "http://devicetree.org/schemas/soc/microchip/microchip,polarfire-soc-sys-controller.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" - -title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) system controller - -maintainers: - - Conor Dooley - -description: | - The PolarFire SoC system controller is communicated with via a mailbox. - This document describes the bindings for the client portion of that mailbox. - - -properties: - mboxes: - maxItems: 1 - - compatible: - const: microchip,polarfire-soc-sys-controller - -required: - - compatible - - mboxes - -additionalProperties: false - -examples: - - | - syscontroller: syscontroller { - compatible = "microchip,polarfire-soc-sys-controller"; - mboxes = <&mbox 0>; - }; -- cgit From b435a1728c9f6811f6f337ebe80e3aca210f1b17 Mon Sep 17 00:00:00 2001 From: Conor Dooley Date: Mon, 14 Feb 2022 13:58:32 +0000 Subject: dt-bindings: soc/microchip: add info about services to mpfs sysctrl The services actually provided by the system controller are not documented so add some words about what the system controller can actually do. Add a link to the oneline documentation with the specific details of each individual service. Also, drop the unneeded label from the example. Signed-off-by: Conor Dooley Reviewed-by: Rob Herring Signed-off-by: Palmer Dabbelt --- .../bindings/soc/microchip/microchip,mpfs-sys-controller.yaml | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml index f699772fedf3..b0dae51e1d42 100644 --- a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml +++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml @@ -10,9 +10,14 @@ maintainers: - Conor Dooley description: | - The PolarFire SoC system controller is communicated with via a mailbox. - This document describes the bindings for the client portion of that mailbox. + PolarFire SoC devices include a microcontroller acting as the system controller, + which provides "services" to the main processor and to the FPGA fabric. These + services include hardware rng, reprogramming of the FPGA and verfification of the + eNVM contents etc. More information on these services can be found online, at + https://onlinedocs.microchip.com/pr/GUID-1409CF11-8EF9-4C24-A94E-70979A688632-en-US-1/index.html + Communication with the system controller is done via a mailbox, of which the client + portion is documented here. properties: mboxes: @@ -29,7 +34,7 @@ additionalProperties: false examples: - | - syscontroller: syscontroller { + syscontroller { compatible = "microchip,mpfs-sys-controller"; mboxes = <&mbox 0>; }; -- cgit From 4cbcc0d7b397b903b4b2ba749c36b8837d5dc782 Mon Sep 17 00:00:00 2001 From: Conor Dooley Date: Mon, 14 Feb 2022 13:58:33 +0000 Subject: dt-bindings: rtc: add bindings for microchip mpfs rtc Add device tree bindings for the real time clock on the Microchip PolarFire SoC. Signed-off-by: Daire McNamara Signed-off-by: Conor Dooley Acked-by: Palmer Dabbelt Reviewed-by: Rob Herring Acked-by: Alexandre Belloni Signed-off-by: Palmer Dabbelt --- .../bindings/rtc/microchip,mfps-rtc.yaml | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml b/Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml new file mode 100644 index 000000000000..a2e984ea3553 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/microchip,mfps-rtc.yaml# + +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip PolarFire Soc (MPFS) RTC Device Tree Bindings + +allOf: + - $ref: rtc.yaml# + +maintainers: + - Daire McNamara + - Lewis Hanly + +properties: + compatible: + enum: + - microchip,mpfs-rtc + + reg: + maxItems: 1 + + interrupts: + items: + - description: | + RTC_WAKEUP interrupt + - description: | + RTC_MATCH, asserted when the content of the Alarm register is equal + to that of the RTC's count register. + + clocks: + maxItems: 1 + + clock-names: + items: + - const: rtc + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + rtc@20124000 { + compatible = "microchip,mpfs-rtc"; + reg = <0x20124000 0x1000>; + clocks = <&clkcfg 21>; + clock-names = "rtc"; + interrupts = <80>, <81>; + }; +... -- cgit From 735806d8a68e96fd7cfca8497dc9dd672ce22236 Mon Sep 17 00:00:00 2001 From: Conor Dooley Date: Mon, 14 Feb 2022 13:58:34 +0000 Subject: dt-bindings: gpio: add bindings for microchip mpfs gpio Add device tree bindings for the gpio controller on the Microchip PolarFire SoC. Reviewed-by: Rob Herring Signed-off-by: Conor Dooley Acked-by: Palmer Dabbelt Acked-by: Bartosz Golaszewski Signed-off-by: Palmer Dabbelt --- .../bindings/gpio/microchip,mpfs-gpio.yaml | 79 ++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml new file mode 100644 index 000000000000..110651eafa70 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/microchip,mpfs-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip MPFS GPIO Controller Device Tree Bindings + +maintainers: + - Conor Dooley + +properties: + compatible: + items: + - enum: + - microchip,mpfs-gpio + + reg: + maxItems: 1 + + interrupts: + description: + Interrupt mapping, one per GPIO. Maximum 32 GPIOs. + minItems: 1 + maxItems: 32 + + interrupt-controller: true + + clocks: + maxItems: 1 + + "#gpio-cells": + const: 2 + + "#interrupt-cells": + const: 1 + + ngpios: + description: + The number of GPIOs available. + minimum: 1 + maximum: 32 + default: 32 + + gpio-controller: true + +required: + - compatible + - reg + - interrupts + - "#interrupt-cells" + - interrupt-controller + - "#gpio-cells" + - gpio-controller + - clocks + +additionalProperties: false + +examples: + - | + gpio@20122000 { + compatible = "microchip,mpfs-gpio"; + reg = <0x20122000 0x1000>; + clocks = <&clkcfg 25>; + interrupt-parent = <&plic>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <1>; + interrupts = <53>, <53>, <53>, <53>, + <53>, <53>, <53>, <53>, + <53>, <53>, <53>, <53>, + <53>, <53>, <53>, <53>, + <53>, <53>, <53>, <53>, + <53>, <53>, <53>, <53>, + <53>, <53>, <53>, <53>, + <53>, <53>, <53>, <53>; + }; +... -- cgit From df77f7735786ece2fcd8875b036a511ffcadfab6 Mon Sep 17 00:00:00 2001 From: Conor Dooley Date: Mon, 14 Feb 2022 13:58:35 +0000 Subject: dt-bindings: pwm: add microchip corepwm binding Add device tree bindings for the Microchip fpga fabric based "core" PWM controller. Reviewed-by: Rob Herring Signed-off-by: Conor Dooley Acked-by: Palmer Dabbelt Acked-by: Uwe Kleine-K=F6nig Acked-by: Thierry Reding Signed-off-by: Palmer Dabbelt --- .../devicetree/bindings/pwm/microchip,corepwm.yaml | 81 ++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml b/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml new file mode 100644 index 000000000000..a7fae1772a81 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/microchip,corepwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip IP corePWM controller bindings + +maintainers: + - Conor Dooley + +description: | + corePWM is an 16 channel pulse width modulator FPGA IP + + https://www.microsemi.com/existing-parts/parts/152118 + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + items: + - const: microchip,corepwm-rtl-v4 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + "#pwm-cells": + const: 2 + + microchip,sync-update-mask: + description: | + Depending on how the IP is instantiated, there are two modes of operation. + In synchronous mode, all channels are updated at the beginning of the PWM period, + and in asynchronous mode updates happen as the control registers are written. + A 16 bit wide "SHADOW_REG_EN" parameter of the IP core controls whether synchronous + mode is possible for each channel, and is set by the bitstream programmed to the + FPGA. If the IP core is instantiated with SHADOW_REG_ENx=1, both registers that + control the duty cycle for channel x have a second "shadow"/buffer reg synthesised. + At runtime a bit wide register exposed to APB can be used to toggle on/off + synchronised mode for all channels it has been synthesised for. + Each bit of "microchip,sync-update-mask" corresponds to a PWM channel & represents + whether synchronous mode is possible for the PWM channel. + + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + + microchip,dac-mode-mask: + description: | + Optional, per-channel Low Ripple DAC mode is possible on this IP core. It creates + a minimum period pulse train whose High/Low average is that of the chosen duty + cycle. This "DAC" will have far better bandwidth and ripple performance than the + standard PWM algorithm can achieve. A 16 bit DAC_MODE module parameter of the IP + core, set at instantiation and by the bitstream programmed to the FPGA, determines + whether a given channel operates in regular PWM or DAC mode. + Each bit corresponds to a PWM channel & represents whether DAC mode is enabled + for that channel. + + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + pwm@41000000 { + compatible = "microchip,corepwm-rtl-v4"; + microchip,sync-update-mask = /bits/ 32 <0>; + clocks = <&clkcfg 30>; + reg = <0x41000000 0xF0>; + #pwm-cells = <2>; + }; -- cgit From d6254d52d70de5301b4fd9acaea5cf1dd8d222b4 Mon Sep 17 00:00:00 2001 From: Ulrich Hecht Date: Wed, 9 Mar 2022 17:26:09 +0100 Subject: dt-bindings: can: renesas,rcar-canfd: Document r8a779a0 support Document support for rcar_canfd on R8A779A0 (V3U) SoCs. Link: https://lore.kernel.org/all/20220309162609.3726306-5-uli+renesas@fpond.eu Signed-off-by: Ulrich Hecht Reviewed-by: Geert Uytterhoeven Signed-off-by: Marc Kleine-Budde --- Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml index 546c6e6d2fb0..91a3554ca950 100644 --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml @@ -35,6 +35,8 @@ properties: - renesas,r9a07g044-canfd # RZ/G2{L,LC} - const: renesas,rzg2l-canfd # RZ/G2L family + - const: renesas,r8a779a0-canfd # R-Car V3U + reg: maxItems: 1 -- cgit From 9986c7650eb3d3e9f00def7bc10e9328a047112e Mon Sep 17 00:00:00 2001 From: Evgenii Stepanov Date: Wed, 9 Mar 2022 13:59:43 -0800 Subject: docs: sysfs-devices-system-cpu: document "asymm" value for mte_tcf_preferred It was added in commit 766121ba5de3 ("arm64/mte: Add userspace interface for enabling asymmetric mode"). Signed-off-by: Evgenii Stepanov Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20220309215943.87831-1-eugenis@google.com Signed-off-by: Will Deacon --- Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 61f5676a7429..2281d5eff403 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -662,6 +662,7 @@ Description: Preferred MTE tag checking mode ================ ============================================== "sync" Prefer synchronous mode + "asymm" Prefer asymmetric mode "async" Prefer asynchronous mode ================ ============================================== -- cgit From b3e664a7f449805aea492713223d7a5578325136 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Thu, 3 Mar 2022 11:45:14 -0600 Subject: dt-bindings: kbuild: Print a warning if yamllint is not found Running yamllint is effectively required for binding schemas, so print a warning if not found rather than silently skipping running it. Signed-off-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220303221417.2486268-1-robh@kernel.org --- Documentation/devicetree/bindings/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index 5138d10e0601..29b5dbd0807e 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -3,7 +3,8 @@ DT_DOC_CHECKER ?= dt-doc-validate DT_EXTRACT_EX ?= dt-extract-example DT_MK_SCHEMA ?= dt-mk-schema -DT_SCHEMA_LINT = $(shell which yamllint) +DT_SCHEMA_LINT := $(shell which yamllint || \ + echo "warning: python package 'yamllint' not installed, skipping" >&2) DT_SCHEMA_MIN_VERSION = 2021.2.1 -- cgit From 1bd524f7e8d8f194cd94bc4535df91391d0f1dc8 Mon Sep 17 00:00:00 2001 From: Anup Patel Date: Thu, 10 Feb 2022 11:19:46 +0530 Subject: dt-bindings: Add common bindings for ARM and RISC-V idle states The RISC-V CPU idle states will be described in under the /cpus/idle-states DT node in the same way as ARM CPU idle states. This patch adds common bindings documentation for both ARM and RISC-V idle states. Signed-off-by: Anup Patel Signed-off-by: Anup Patel Reviewed-by: Rob Herring Reviewed-by: Guo Ren Signed-off-by: Palmer Dabbelt --- .../devicetree/bindings/arm/idle-states.yaml | 661 ---------------- .../bindings/arm/msm/qcom,idle-state.txt | 2 +- Documentation/devicetree/bindings/arm/psci.yaml | 2 +- .../devicetree/bindings/cpu/idle-states.yaml | 855 +++++++++++++++++++++ Documentation/devicetree/bindings/riscv/cpus.yaml | 6 + 5 files changed, 863 insertions(+), 663 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/idle-states.yaml create mode 100644 Documentation/devicetree/bindings/cpu/idle-states.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/idle-states.yaml b/Documentation/devicetree/bindings/arm/idle-states.yaml deleted file mode 100644 index 52bce5dbb11f..000000000000 --- a/Documentation/devicetree/bindings/arm/idle-states.yaml +++ /dev/null @@ -1,661 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/arm/idle-states.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: ARM idle states binding description - -maintainers: - - Lorenzo Pieralisi - -description: |+ - ========================================== - 1 - Introduction - ========================================== - - ARM systems contain HW capable of managing power consumption dynamically, - where cores can be put in different low-power states (ranging from simple wfi - to power gating) according to OS PM policies. The CPU states representing the - range of dynamic idle states that a processor can enter at run-time, can be - specified through device tree bindings representing the parameters required to - enter/exit specific idle states on a given processor. - - According to the Server Base System Architecture document (SBSA, [3]), the - power states an ARM CPU can be put into are identified by the following list: - - - Running - - Idle_standby - - Idle_retention - - Sleep - - Off - - The power states described in the SBSA document define the basic CPU states on - top of which ARM platforms implement power management schemes that allow an OS - PM implementation to put the processor in different idle states (which include - states listed above; "off" state is not an idle state since it does not have - wake-up capabilities, hence it is not considered in this document). - - Idle state parameters (e.g. entry latency) are platform specific and need to - be characterized with bindings that provide the required information to OS PM - code so that it can build the required tables and use them at runtime. - - The device tree binding definition for ARM idle states is the subject of this - document. - - =========================================== - 2 - idle-states definitions - =========================================== - - Idle states are characterized for a specific system through a set of - timing and energy related properties, that underline the HW behaviour - triggered upon idle states entry and exit. - - The following diagram depicts the CPU execution phases and related timing - properties required to enter and exit an idle state: - - ..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]__.. - | | | | | - - |<------ entry ------->| - | latency | - |<- exit ->| - | latency | - |<-------- min-residency -------->| - |<------- wakeup-latency ------->| - - Diagram 1: CPU idle state execution phases - - EXEC: Normal CPU execution. - - PREP: Preparation phase before committing the hardware to idle mode - like cache flushing. This is abortable on pending wake-up - event conditions. The abort latency is assumed to be negligible - (i.e. less than the ENTRY + EXIT duration). If aborted, CPU - goes back to EXEC. This phase is optional. If not abortable, - this should be included in the ENTRY phase instead. - - ENTRY: The hardware is committed to idle mode. This period must run - to completion up to IDLE before anything else can happen. - - IDLE: This is the actual energy-saving idle period. This may last - between 0 and infinite time, until a wake-up event occurs. - - EXIT: Period during which the CPU is brought back to operational - mode (EXEC). - - entry-latency: Worst case latency required to enter the idle state. The - exit-latency may be guaranteed only after entry-latency has passed. - - min-residency: Minimum period, including preparation and entry, for a given - idle state to be worthwhile energywise. - - wakeup-latency: Maximum delay between the signaling of a wake-up event and the - CPU being able to execute normal code again. If not specified, this is assumed - to be entry-latency + exit-latency. - - These timing parameters can be used by an OS in different circumstances. - - An idle CPU requires the expected min-residency time to select the most - appropriate idle state based on the expected expiry time of the next IRQ - (i.e. wake-up) that causes the CPU to return to the EXEC phase. - - An operating system scheduler may need to compute the shortest wake-up delay - for CPUs in the system by detecting how long will it take to get a CPU out - of an idle state, e.g.: - - wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0) - - In other words, the scheduler can make its scheduling decision by selecting - (e.g. waking-up) the CPU with the shortest wake-up delay. - The wake-up delay must take into account the entry latency if that period - has not expired. The abortable nature of the PREP period can be ignored - if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than - the worst case since it depends on the CPU operating conditions, i.e. caches - state). - - An OS has to reliably probe the wakeup-latency since some devices can enforce - latency constraint guarantees to work properly, so the OS has to detect the - worst case wake-up latency it can incur if a CPU is allowed to enter an - idle state, and possibly to prevent that to guarantee reliable device - functioning. - - The min-residency time parameter deserves further explanation since it is - expressed in time units but must factor in energy consumption coefficients. - - The energy consumption of a cpu when it enters a power state can be roughly - characterised by the following graph: - - | - | - | - e | - n | /--- - e | /------ - r | /------ - g | /----- - y | /------ - | ---- - | /| - | / | - | / | - | / | - | / | - | / | - |/ | - -----|-------+---------------------------------- - 0| 1 time(ms) - - Graph 1: Energy vs time example - - The graph is split in two parts delimited by time 1ms on the X-axis. - The graph curve with X-axis values = { x | 0 < x < 1ms } has a steep slope - and denotes the energy costs incurred while entering and leaving the idle - state. - The graph curve in the area delimited by X-axis values = {x | x > 1ms } has - shallower slope and essentially represents the energy consumption of the idle - state. - - min-residency is defined for a given idle state as the minimum expected - residency time for a state (inclusive of preparation and entry) after - which choosing that state become the most energy efficient option. A good - way to visualise this, is by taking the same graph above and comparing some - states energy consumptions plots. - - For sake of simplicity, let's consider a system with two idle states IDLE1, - and IDLE2: - - | - | - | - | /-- IDLE1 - e | /--- - n | /---- - e | /--- - r | /-----/--------- IDLE2 - g | /-------/--------- - y | ------------ /---| - | / /---- | - | / /--- | - | / /---- | - | / /--- | - | --- | - | / | - | / | - |/ | time - ---/----------------------------+------------------------ - |IDLE1-energy < IDLE2-energy | IDLE2-energy < IDLE1-energy - | - IDLE2-min-residency - - Graph 2: idle states min-residency example - - In graph 2 above, that takes into account idle states entry/exit energy - costs, it is clear that if the idle state residency time (i.e. time till next - wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state - choice energywise. - - This is mainly down to the fact that IDLE1 entry/exit energy costs are lower - than IDLE2. - - However, the lower power consumption (i.e. shallower energy curve slope) of - idle state IDLE2 implies that after a suitable time, IDLE2 becomes more energy - efficient. - - The time at which IDLE2 becomes more energy efficient than IDLE1 (and other - shallower states in a system with multiple idle states) is defined - IDLE2-min-residency and corresponds to the time when energy consumption of - IDLE1 and IDLE2 states breaks even. - - The definitions provided in this section underpin the idle states - properties specification that is the subject of the following sections. - - =========================================== - 3 - idle-states node - =========================================== - - ARM processor idle states are defined within the idle-states node, which is - a direct child of the cpus node [1] and provides a container where the - processor idle states, defined as device tree nodes, are listed. - - On ARM systems, it is a container of processor idle states nodes. If the - system does not provide CPU power management capabilities, or the processor - just supports idle_standby, an idle-states node is not required. - - =========================================== - 4 - References - =========================================== - - [1] ARM Linux Kernel documentation - CPUs bindings - Documentation/devicetree/bindings/arm/cpus.yaml - - [2] ARM Linux Kernel documentation - PSCI bindings - Documentation/devicetree/bindings/arm/psci.yaml - - [3] ARM Server Base System Architecture (SBSA) - http://infocenter.arm.com/help/index.jsp - - [4] ARM Architecture Reference Manuals - http://infocenter.arm.com/help/index.jsp - - [6] ARM Linux Kernel documentation - Booting AArch64 Linux - Documentation/arm64/booting.rst - -properties: - $nodename: - const: idle-states - - entry-method: - description: | - Usage and definition depend on ARM architecture version. - - On ARM v8 64-bit this property is required. - On ARM 32-bit systems this property is optional - - This assumes that the "enable-method" property is set to "psci" in the cpu - node[6] that is responsible for setting up CPU idle management in the OS - implementation. - const: psci - -patternProperties: - "^(cpu|cluster)-": - type: object - description: | - Each state node represents an idle state description and must be defined - as follows. - - The idle state entered by executing the wfi instruction (idle_standby - SBSA,[3][4]) is considered standard on all ARM platforms and therefore - must not be listed. - - In addition to the properties listed above, a state node may require - additional properties specific to the entry-method defined in the - idle-states node. Please refer to the entry-method bindings - documentation for properties definitions. - - properties: - compatible: - const: arm,idle-state - - local-timer-stop: - description: - If present the CPU local timer control logic is - lost on state entry, otherwise it is retained. - type: boolean - - entry-latency-us: - description: - Worst case latency in microseconds required to enter the idle state. - - exit-latency-us: - description: - Worst case latency in microseconds required to exit the idle state. - The exit-latency-us duration may be guaranteed only after - entry-latency-us has passed. - - min-residency-us: - description: - Minimum residency duration in microseconds, inclusive of preparation - and entry, for this idle state to be considered worthwhile energy wise - (refer to section 2 of this document for a complete description). - - wakeup-latency-us: - description: | - Maximum delay between the signaling of a wake-up event and the CPU - being able to execute normal code again. If omitted, this is assumed - to be equal to: - - entry-latency-us + exit-latency-us - - It is important to supply this value on systems where the duration of - PREP phase (see diagram 1, section 2) is non-neglibigle. In such - systems entry-latency-us + exit-latency-us will exceed - wakeup-latency-us by this duration. - - idle-state-name: - $ref: /schemas/types.yaml#/definitions/string - description: - A string used as a descriptive name for the idle state. - - required: - - compatible - - entry-latency-us - - exit-latency-us - - min-residency-us - -additionalProperties: false - -examples: - - | - - cpus { - #size-cells = <0>; - #address-cells = <2>; - - cpu@0 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x0>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; - }; - - cpu@1 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x1>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; - }; - - cpu@100 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x100>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; - }; - - cpu@101 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x101>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; - }; - - cpu@10000 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x10000>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; - }; - - cpu@10001 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x10001>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; - }; - - cpu@10100 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x10100>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; - }; - - cpu@10101 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x10101>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; - }; - - cpu@100000000 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x1 0x0>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; - }; - - cpu@100000001 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x1 0x1>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; - }; - - cpu@100000100 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x1 0x100>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; - }; - - cpu@100000101 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x1 0x101>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; - }; - - cpu@100010000 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x1 0x10000>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; - }; - - cpu@100010001 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x1 0x10001>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; - }; - - cpu@100010100 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x1 0x10100>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; - }; - - cpu@100010101 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x1 0x10101>; - enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; - }; - - idle-states { - entry-method = "psci"; - - CPU_RETENTION_0_0: cpu-retention-0-0 { - compatible = "arm,idle-state"; - arm,psci-suspend-param = <0x0010000>; - entry-latency-us = <20>; - exit-latency-us = <40>; - min-residency-us = <80>; - }; - - CLUSTER_RETENTION_0: cluster-retention-0 { - compatible = "arm,idle-state"; - local-timer-stop; - arm,psci-suspend-param = <0x1010000>; - entry-latency-us = <50>; - exit-latency-us = <100>; - min-residency-us = <250>; - wakeup-latency-us = <130>; - }; - - CPU_SLEEP_0_0: cpu-sleep-0-0 { - compatible = "arm,idle-state"; - local-timer-stop; - arm,psci-suspend-param = <0x0010000>; - entry-latency-us = <250>; - exit-latency-us = <500>; - min-residency-us = <950>; - }; - - CLUSTER_SLEEP_0: cluster-sleep-0 { - compatible = "arm,idle-state"; - local-timer-stop; - arm,psci-suspend-param = <0x1010000>; - entry-latency-us = <600>; - exit-latency-us = <1100>; - min-residency-us = <2700>; - wakeup-latency-us = <1500>; - }; - - CPU_RETENTION_1_0: cpu-retention-1-0 { - compatible = "arm,idle-state"; - arm,psci-suspend-param = <0x0010000>; - entry-latency-us = <20>; - exit-latency-us = <40>; - min-residency-us = <90>; - }; - - CLUSTER_RETENTION_1: cluster-retention-1 { - compatible = "arm,idle-state"; - local-timer-stop; - arm,psci-suspend-param = <0x1010000>; - entry-latency-us = <50>; - exit-latency-us = <100>; - min-residency-us = <270>; - wakeup-latency-us = <100>; - }; - - CPU_SLEEP_1_0: cpu-sleep-1-0 { - compatible = "arm,idle-state"; - local-timer-stop; - arm,psci-suspend-param = <0x0010000>; - entry-latency-us = <70>; - exit-latency-us = <100>; - min-residency-us = <300>; - wakeup-latency-us = <150>; - }; - - CLUSTER_SLEEP_1: cluster-sleep-1 { - compatible = "arm,idle-state"; - local-timer-stop; - arm,psci-suspend-param = <0x1010000>; - entry-latency-us = <500>; - exit-latency-us = <1200>; - min-residency-us = <3500>; - wakeup-latency-us = <1300>; - }; - }; - }; - - - | - // Example 2 (ARM 32-bit, 8-cpu system, two clusters): - - cpus { - #size-cells = <0>; - #address-cells = <1>; - - cpu@0 { - device_type = "cpu"; - compatible = "arm,cortex-a15"; - reg = <0x0>; - cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; - }; - - cpu@1 { - device_type = "cpu"; - compatible = "arm,cortex-a15"; - reg = <0x1>; - cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; - }; - - cpu@2 { - device_type = "cpu"; - compatible = "arm,cortex-a15"; - reg = <0x2>; - cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; - }; - - cpu@3 { - device_type = "cpu"; - compatible = "arm,cortex-a15"; - reg = <0x3>; - cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; - }; - - cpu@100 { - device_type = "cpu"; - compatible = "arm,cortex-a7"; - reg = <0x100>; - cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; - }; - - cpu@101 { - device_type = "cpu"; - compatible = "arm,cortex-a7"; - reg = <0x101>; - cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; - }; - - cpu@102 { - device_type = "cpu"; - compatible = "arm,cortex-a7"; - reg = <0x102>; - cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; - }; - - cpu@103 { - device_type = "cpu"; - compatible = "arm,cortex-a7"; - reg = <0x103>; - cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; - }; - - idle-states { - cpu_sleep_0_0: cpu-sleep-0-0 { - compatible = "arm,idle-state"; - local-timer-stop; - entry-latency-us = <200>; - exit-latency-us = <100>; - min-residency-us = <400>; - wakeup-latency-us = <250>; - }; - - cluster_sleep_0: cluster-sleep-0 { - compatible = "arm,idle-state"; - local-timer-stop; - entry-latency-us = <500>; - exit-latency-us = <1500>; - min-residency-us = <2500>; - wakeup-latency-us = <1700>; - }; - - cpu_sleep_1_0: cpu-sleep-1-0 { - compatible = "arm,idle-state"; - local-timer-stop; - entry-latency-us = <300>; - exit-latency-us = <500>; - min-residency-us = <900>; - wakeup-latency-us = <600>; - }; - - cluster_sleep_1: cluster-sleep-1 { - compatible = "arm,idle-state"; - local-timer-stop; - entry-latency-us = <800>; - exit-latency-us = <2000>; - min-residency-us = <6500>; - wakeup-latency-us = <2300>; - }; - }; - }; - -... diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt index 6ce0b212ec6d..606b4b1b709d 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt +++ b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt @@ -81,4 +81,4 @@ Example: }; }; -[1]. Documentation/devicetree/bindings/arm/idle-states.yaml +[1]. Documentation/devicetree/bindings/cpu/idle-states.yaml diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml index 8b77cf83a095..dd83ef278af0 100644 --- a/Documentation/devicetree/bindings/arm/psci.yaml +++ b/Documentation/devicetree/bindings/arm/psci.yaml @@ -101,7 +101,7 @@ properties: bindings in [1]) must specify this property. [1] Kernel documentation - ARM idle states bindings - Documentation/devicetree/bindings/arm/idle-states.yaml + Documentation/devicetree/bindings/cpu/idle-states.yaml patternProperties: "^power-domain-": diff --git a/Documentation/devicetree/bindings/cpu/idle-states.yaml b/Documentation/devicetree/bindings/cpu/idle-states.yaml new file mode 100644 index 000000000000..95506ffb816c --- /dev/null +++ b/Documentation/devicetree/bindings/cpu/idle-states.yaml @@ -0,0 +1,855 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/cpu/idle-states.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Idle states binding description + +maintainers: + - Lorenzo Pieralisi + - Anup Patel + +description: |+ + ========================================== + 1 - Introduction + ========================================== + + ARM and RISC-V systems contain HW capable of managing power consumption + dynamically, where cores can be put in different low-power states (ranging + from simple wfi to power gating) according to OS PM policies. The CPU states + representing the range of dynamic idle states that a processor can enter at + run-time, can be specified through device tree bindings representing the + parameters required to enter/exit specific idle states on a given processor. + + ========================================== + 2 - ARM idle states + ========================================== + + According to the Server Base System Architecture document (SBSA, [3]), the + power states an ARM CPU can be put into are identified by the following list: + + - Running + - Idle_standby + - Idle_retention + - Sleep + - Off + + The power states described in the SBSA document define the basic CPU states on + top of which ARM platforms implement power management schemes that allow an OS + PM implementation to put the processor in different idle states (which include + states listed above; "off" state is not an idle state since it does not have + wake-up capabilities, hence it is not considered in this document). + + Idle state parameters (e.g. entry latency) are platform specific and need to + be characterized with bindings that provide the required information to OS PM + code so that it can build the required tables and use them at runtime. + + The device tree binding definition for ARM idle states is the subject of this + document. + + ========================================== + 3 - RISC-V idle states + ========================================== + + On RISC-V systems, the HARTs (or CPUs) [6] can be put in platform specific + suspend (or idle) states (ranging from simple WFI, power gating, etc). The + RISC-V SBI v0.3 (or higher) [7] hart state management extension provides a + standard mechanism for OS to request HART state transitions. + + The platform specific suspend (or idle) states of a hart can be either + retentive or non-rententive in nature. A retentive suspend state will + preserve HART registers and CSR values for all privilege modes whereas + a non-retentive suspend state will not preserve HART registers and CSR + values. + + =========================================== + 4 - idle-states definitions + =========================================== + + Idle states are characterized for a specific system through a set of + timing and energy related properties, that underline the HW behaviour + triggered upon idle states entry and exit. + + The following diagram depicts the CPU execution phases and related timing + properties required to enter and exit an idle state: + + ..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]__.. + | | | | | + + |<------ entry ------->| + | latency | + |<- exit ->| + | latency | + |<-------- min-residency -------->| + |<------- wakeup-latency ------->| + + Diagram 1: CPU idle state execution phases + + EXEC: Normal CPU execution. + + PREP: Preparation phase before committing the hardware to idle mode + like cache flushing. This is abortable on pending wake-up + event conditions. The abort latency is assumed to be negligible + (i.e. less than the ENTRY + EXIT duration). If aborted, CPU + goes back to EXEC. This phase is optional. If not abortable, + this should be included in the ENTRY phase instead. + + ENTRY: The hardware is committed to idle mode. This period must run + to completion up to IDLE before anything else can happen. + + IDLE: This is the actual energy-saving idle period. This may last + between 0 and infinite time, until a wake-up event occurs. + + EXIT: Period during which the CPU is brought back to operational + mode (EXEC). + + entry-latency: Worst case latency required to enter the idle state. The + exit-latency may be guaranteed only after entry-latency has passed. + + min-residency: Minimum period, including preparation and entry, for a given + idle state to be worthwhile energywise. + + wakeup-latency: Maximum delay between the signaling of a wake-up event and the + CPU being able to execute normal code again. If not specified, this is assumed + to be entry-latency + exit-latency. + + These timing parameters can be used by an OS in different circumstances. + + An idle CPU requires the expected min-residency time to select the most + appropriate idle state based on the expected expiry time of the next IRQ + (i.e. wake-up) that causes the CPU to return to the EXEC phase. + + An operating system scheduler may need to compute the shortest wake-up delay + for CPUs in the system by detecting how long will it take to get a CPU out + of an idle state, e.g.: + + wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0) + + In other words, the scheduler can make its scheduling decision by selecting + (e.g. waking-up) the CPU with the shortest wake-up delay. + The wake-up delay must take into account the entry latency if that period + has not expired. The abortable nature of the PREP period can be ignored + if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than + the worst case since it depends on the CPU operating conditions, i.e. caches + state). + + An OS has to reliably probe the wakeup-latency since some devices can enforce + latency constraint guarantees to work properly, so the OS has to detect the + worst case wake-up latency it can incur if a CPU is allowed to enter an + idle state, and possibly to prevent that to guarantee reliable device + functioning. + + The min-residency time parameter deserves further explanation since it is + expressed in time units but must factor in energy consumption coefficients. + + The energy consumption of a cpu when it enters a power state can be roughly + characterised by the following graph: + + | + | + | + e | + n | /--- + e | /------ + r | /------ + g | /----- + y | /------ + | ---- + | /| + | / | + | / | + | / | + | / | + | / | + |/ | + -----|-------+---------------------------------- + 0| 1 time(ms) + + Graph 1: Energy vs time example + + The graph is split in two parts delimited by time 1ms on the X-axis. + The graph curve with X-axis values = { x | 0 < x < 1ms } has a steep slope + and denotes the energy costs incurred while entering and leaving the idle + state. + The graph curve in the area delimited by X-axis values = {x | x > 1ms } has + shallower slope and essentially represents the energy consumption of the idle + state. + + min-residency is defined for a given idle state as the minimum expected + residency time for a state (inclusive of preparation and entry) after + which choosing that state become the most energy efficient option. A good + way to visualise this, is by taking the same graph above and comparing some + states energy consumptions plots. + + For sake of simplicity, let's consider a system with two idle states IDLE1, + and IDLE2: + + | + | + | + | /-- IDLE1 + e | /--- + n | /---- + e | /--- + r | /-----/--------- IDLE2 + g | /-------/--------- + y | ------------ /---| + | / /---- | + | / /--- | + | / /---- | + | / /--- | + | --- | + | / | + | / | + |/ | time + ---/----------------------------+------------------------ + |IDLE1-energy < IDLE2-energy | IDLE2-energy < IDLE1-energy + | + IDLE2-min-residency + + Graph 2: idle states min-residency example + + In graph 2 above, that takes into account idle states entry/exit energy + costs, it is clear that if the idle state residency time (i.e. time till next + wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state + choice energywise. + + This is mainly down to the fact that IDLE1 entry/exit energy costs are lower + than IDLE2. + + However, the lower power consumption (i.e. shallower energy curve slope) of + idle state IDLE2 implies that after a suitable time, IDLE2 becomes more energy + efficient. + + The time at which IDLE2 becomes more energy efficient than IDLE1 (and other + shallower states in a system with multiple idle states) is defined + IDLE2-min-residency and corresponds to the time when energy consumption of + IDLE1 and IDLE2 states breaks even. + + The definitions provided in this section underpin the idle states + properties specification that is the subject of the following sections. + + =========================================== + 5 - idle-states node + =========================================== + + The processor idle states are defined within the idle-states node, which is + a direct child of the cpus node [1] and provides a container where the + processor idle states, defined as device tree nodes, are listed. + + On ARM systems, it is a container of processor idle states nodes. If the + system does not provide CPU power management capabilities, or the processor + just supports idle_standby, an idle-states node is not required. + + =========================================== + 6 - References + =========================================== + + [1] ARM Linux Kernel documentation - CPUs bindings + Documentation/devicetree/bindings/arm/cpus.yaml + + [2] ARM Linux Kernel documentation - PSCI bindings + Documentation/devicetree/bindings/arm/psci.yaml + + [3] ARM Server Base System Architecture (SBSA) + http://infocenter.arm.com/help/index.jsp + + [4] ARM Architecture Reference Manuals + http://infocenter.arm.com/help/index.jsp + + [5] ARM Linux Kernel documentation - Booting AArch64 Linux + Documentation/arm64/booting.rst + + [6] RISC-V Linux Kernel documentation - CPUs bindings + Documentation/devicetree/bindings/riscv/cpus.yaml + + [7] RISC-V Supervisor Binary Interface (SBI) + http://github.com/riscv/riscv-sbi-doc/riscv-sbi.adoc + +properties: + $nodename: + const: idle-states + + entry-method: + description: | + Usage and definition depend on ARM architecture version. + + On ARM v8 64-bit this property is required. + On ARM 32-bit systems this property is optional + + This assumes that the "enable-method" property is set to "psci" in the cpu + node[5] that is responsible for setting up CPU idle management in the OS + implementation. + const: psci + +patternProperties: + "^(cpu|cluster)-": + type: object + description: | + Each state node represents an idle state description and must be defined + as follows. + + The idle state entered by executing the wfi instruction (idle_standby + SBSA,[3][4]) is considered standard on all ARM and RISC-V platforms and + therefore must not be listed. + + In addition to the properties listed above, a state node may require + additional properties specific to the entry-method defined in the + idle-states node. Please refer to the entry-method bindings + documentation for properties definitions. + + properties: + compatible: + enum: + - arm,idle-state + - riscv,idle-state + + arm,psci-suspend-param: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + power_state parameter to pass to the ARM PSCI suspend call. + + Device tree nodes that require usage of PSCI CPU_SUSPEND function + (i.e. idle states node with entry-method property is set to "psci") + must specify this property. + + riscv,sbi-suspend-param: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + suspend_type parameter to pass to the RISC-V SBI HSM suspend call. + + This property is required in idle state nodes of device tree meant + for RISC-V systems. For more details on the suspend_type parameter + refer the SBI specifiation v0.3 (or higher) [7]. + + local-timer-stop: + description: + If present the CPU local timer control logic is + lost on state entry, otherwise it is retained. + type: boolean + + entry-latency-us: + description: + Worst case latency in microseconds required to enter the idle state. + + exit-latency-us: + description: + Worst case latency in microseconds required to exit the idle state. + The exit-latency-us duration may be guaranteed only after + entry-latency-us has passed. + + min-residency-us: + description: + Minimum residency duration in microseconds, inclusive of preparation + and entry, for this idle state to be considered worthwhile energy wise + (refer to section 2 of this document for a complete description). + + wakeup-latency-us: + description: | + Maximum delay between the signaling of a wake-up event and the CPU + being able to execute normal code again. If omitted, this is assumed + to be equal to: + + entry-latency-us + exit-latency-us + + It is important to supply this value on systems where the duration of + PREP phase (see diagram 1, section 2) is non-neglibigle. In such + systems entry-latency-us + exit-latency-us will exceed + wakeup-latency-us by this duration. + + idle-state-name: + $ref: /schemas/types.yaml#/definitions/string + description: + A string used as a descriptive name for the idle state. + + additionalProperties: false + + required: + - compatible + - entry-latency-us + - exit-latency-us + - min-residency-us + +additionalProperties: false + +examples: + - | + + cpus { + #size-cells = <0>; + #address-cells = <2>; + + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x0>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x1>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + cpu@10000 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10000>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + cpu@10001 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10001>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + cpu@10100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + cpu@10101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + cpu@100000000 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x0>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + cpu@100000001 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x1>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + cpu@100000100 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + cpu@100000101 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + cpu@100010000 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x10000>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + cpu@100010001 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x10001>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + cpu@100010100 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x10100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + cpu@100010101 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x10101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + idle-states { + entry-method = "psci"; + + CPU_RETENTION_0_0: cpu-retention-0-0 { + compatible = "arm,idle-state"; + arm,psci-suspend-param = <0x0010000>; + entry-latency-us = <20>; + exit-latency-us = <40>; + min-residency-us = <80>; + }; + + CLUSTER_RETENTION_0: cluster-retention-0 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x1010000>; + entry-latency-us = <50>; + exit-latency-us = <100>; + min-residency-us = <250>; + wakeup-latency-us = <130>; + }; + + CPU_SLEEP_0_0: cpu-sleep-0-0 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x0010000>; + entry-latency-us = <250>; + exit-latency-us = <500>; + min-residency-us = <950>; + }; + + CLUSTER_SLEEP_0: cluster-sleep-0 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x1010000>; + entry-latency-us = <600>; + exit-latency-us = <1100>; + min-residency-us = <2700>; + wakeup-latency-us = <1500>; + }; + + CPU_RETENTION_1_0: cpu-retention-1-0 { + compatible = "arm,idle-state"; + arm,psci-suspend-param = <0x0010000>; + entry-latency-us = <20>; + exit-latency-us = <40>; + min-residency-us = <90>; + }; + + CLUSTER_RETENTION_1: cluster-retention-1 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x1010000>; + entry-latency-us = <50>; + exit-latency-us = <100>; + min-residency-us = <270>; + wakeup-latency-us = <100>; + }; + + CPU_SLEEP_1_0: cpu-sleep-1-0 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x0010000>; + entry-latency-us = <70>; + exit-latency-us = <100>; + min-residency-us = <300>; + wakeup-latency-us = <150>; + }; + + CLUSTER_SLEEP_1: cluster-sleep-1 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x1010000>; + entry-latency-us = <500>; + exit-latency-us = <1200>; + min-residency-us = <3500>; + wakeup-latency-us = <1300>; + }; + }; + }; + + - | + // Example 2 (ARM 32-bit, 8-cpu system, two clusters): + + cpus { + #size-cells = <0>; + #address-cells = <1>; + + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x0>; + cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; + }; + + cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x1>; + cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; + }; + + cpu@2 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x2>; + cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; + }; + + cpu@3 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x3>; + cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; + }; + + cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x100>; + cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; + }; + + cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x101>; + cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; + }; + + cpu@102 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x102>; + cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; + }; + + cpu@103 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x103>; + cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; + }; + + idle-states { + cpu_sleep_0_0: cpu-sleep-0-0 { + compatible = "arm,idle-state"; + local-timer-stop; + entry-latency-us = <200>; + exit-latency-us = <100>; + min-residency-us = <400>; + wakeup-latency-us = <250>; + }; + + cluster_sleep_0: cluster-sleep-0 { + compatible = "arm,idle-state"; + local-timer-stop; + entry-latency-us = <500>; + exit-latency-us = <1500>; + min-residency-us = <2500>; + wakeup-latency-us = <1700>; + }; + + cpu_sleep_1_0: cpu-sleep-1-0 { + compatible = "arm,idle-state"; + local-timer-stop; + entry-latency-us = <300>; + exit-latency-us = <500>; + min-residency-us = <900>; + wakeup-latency-us = <600>; + }; + + cluster_sleep_1: cluster-sleep-1 { + compatible = "arm,idle-state"; + local-timer-stop; + entry-latency-us = <800>; + exit-latency-us = <2000>; + min-residency-us = <6500>; + wakeup-latency-us = <2300>; + }; + }; + }; + + - | + // Example 3 (RISC-V 64-bit, 4-cpu systems, two clusters): + + cpus { + #size-cells = <0>; + #address-cells = <1>; + + cpu@0 { + device_type = "cpu"; + compatible = "riscv"; + reg = <0x0>; + riscv,isa = "rv64imafdc"; + mmu-type = "riscv,sv48"; + cpu-idle-states = <&CPU_RET_0_0 &CPU_NONRET_0_0 + &CLUSTER_RET_0 &CLUSTER_NONRET_0>; + + cpu_intc0: interrupt-controller { + #interrupt-cells = <1>; + compatible = "riscv,cpu-intc"; + interrupt-controller; + }; + }; + + cpu@1 { + device_type = "cpu"; + compatible = "riscv"; + reg = <0x1>; + riscv,isa = "rv64imafdc"; + mmu-type = "riscv,sv48"; + cpu-idle-states = <&CPU_RET_0_0 &CPU_NONRET_0_0 + &CLUSTER_RET_0 &CLUSTER_NONRET_0>; + + cpu_intc1: interrupt-controller { + #interrupt-cells = <1>; + compatible = "riscv,cpu-intc"; + interrupt-controller; + }; + }; + + cpu@10 { + device_type = "cpu"; + compatible = "riscv"; + reg = <0x10>; + riscv,isa = "rv64imafdc"; + mmu-type = "riscv,sv48"; + cpu-idle-states = <&CPU_RET_1_0 &CPU_NONRET_1_0 + &CLUSTER_RET_1 &CLUSTER_NONRET_1>; + + cpu_intc10: interrupt-controller { + #interrupt-cells = <1>; + compatible = "riscv,cpu-intc"; + interrupt-controller; + }; + }; + + cpu@11 { + device_type = "cpu"; + compatible = "riscv"; + reg = <0x11>; + riscv,isa = "rv64imafdc"; + mmu-type = "riscv,sv48"; + cpu-idle-states = <&CPU_RET_1_0 &CPU_NONRET_1_0 + &CLUSTER_RET_1 &CLUSTER_NONRET_1>; + + cpu_intc11: interrupt-controller { + #interrupt-cells = <1>; + compatible = "riscv,cpu-intc"; + interrupt-controller; + }; + }; + + idle-states { + CPU_RET_0_0: cpu-retentive-0-0 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x10000000>; + entry-latency-us = <20>; + exit-latency-us = <40>; + min-residency-us = <80>; + }; + + CPU_NONRET_0_0: cpu-nonretentive-0-0 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x90000000>; + entry-latency-us = <250>; + exit-latency-us = <500>; + min-residency-us = <950>; + }; + + CLUSTER_RET_0: cluster-retentive-0 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x11000000>; + local-timer-stop; + entry-latency-us = <50>; + exit-latency-us = <100>; + min-residency-us = <250>; + wakeup-latency-us = <130>; + }; + + CLUSTER_NONRET_0: cluster-nonretentive-0 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x91000000>; + local-timer-stop; + entry-latency-us = <600>; + exit-latency-us = <1100>; + min-residency-us = <2700>; + wakeup-latency-us = <1500>; + }; + + CPU_RET_1_0: cpu-retentive-1-0 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x10000010>; + entry-latency-us = <20>; + exit-latency-us = <40>; + min-residency-us = <80>; + }; + + CPU_NONRET_1_0: cpu-nonretentive-1-0 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x90000010>; + entry-latency-us = <250>; + exit-latency-us = <500>; + min-residency-us = <950>; + }; + + CLUSTER_RET_1: cluster-retentive-1 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x11000010>; + local-timer-stop; + entry-latency-us = <50>; + exit-latency-us = <100>; + min-residency-us = <250>; + wakeup-latency-us = <130>; + }; + + CLUSTER_NONRET_1: cluster-nonretentive-1 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x91000010>; + local-timer-stop; + entry-latency-us = <600>; + exit-latency-us = <1100>; + min-residency-us = <2700>; + wakeup-latency-us = <1500>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index aa5fb64d57eb..f62f646bc695 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -99,6 +99,12 @@ properties: - compatible - interrupt-controller + cpu-idle-states: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + description: | + List of phandles to idle state nodes supported + by this hart (see ./idle-states.yaml). + required: - riscv,isa - interrupt-controller -- cgit From 21d5929ff230635400d138df66b0b8dd38893c25 Mon Sep 17 00:00:00 2001 From: Richard Zhu Date: Thu, 3 Mar 2022 15:50:05 +0800 Subject: dt-bindings: imx6q-pcie: Add iMX8MM PCIe compatible string Add the i.MX8MM PCIe compatible string. Signed-off-by: Richard Zhu Reviewed-by: Lucas Stach Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/1646293805-18248-1-git-send-email-hongxing.zhu@nxp.com --- Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml index 643a6333b07b..36c8a06d17a0 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml @@ -25,6 +25,7 @@ properties: - fsl,imx6qp-pcie - fsl,imx7d-pcie - fsl,imx8mq-pcie + - fsl,imx8mm-pcie reg: items: -- cgit From 9be01ee2289bb3e8c8d17844076705b0b14b7164 Mon Sep 17 00:00:00 2001 From: Richard Zhu Date: Mon, 7 Mar 2022 17:07:31 +0800 Subject: dt-bindings: imx6q-pcie: Add iMX8MP PCIe compatible string Add i.MX8MP PCIe compatible string. Signed-off-by: Richard Zhu Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/1646644054-24421-5-git-send-email-hongxing.zhu@nxp.com --- Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml index 36c8a06d17a0..252e5b72aee0 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml @@ -26,6 +26,7 @@ properties: - fsl,imx7d-pcie - fsl,imx8mq-pcie - fsl,imx8mm-pcie + - fsl,imx8mp-pcie reg: items: -- cgit From b48b563626655fe1d43a79e5ceb9d6367f851edc Mon Sep 17 00:00:00 2001 From: Clément Léger Date: Fri, 4 Mar 2022 11:32:25 +0100 Subject: dt-bindings: net: mscc,vsc7514-switch: convert txt bindings to yaml MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Convert existing txt bindings to yaml format. Signed-off-by: Clément Léger Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220304103225.111428-1-clement.leger@bootlin.com --- .../bindings/net/mscc,vsc7514-switch.yaml | 191 +++++++++++++++++++++ .../devicetree/bindings/net/mscc-ocelot.txt | 83 --------- 2 files changed, 191 insertions(+), 83 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml delete mode 100644 Documentation/devicetree/bindings/net/mscc-ocelot.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml b/Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml new file mode 100644 index 000000000000..ee0a504bdb24 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml @@ -0,0 +1,191 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mscc,vsc7514-switch.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip VSC7514 Ethernet switch controller + +maintainers: + - Vladimir Oltean + - Claudiu Manoil + - Alexandre Belloni + +description: | + Bindings for the Microchip VSC7514 switch driver + + The VSC7514 switch driver handles up to 11 ports and can inject/extract + packets using CPU. Additionally, PTP is supported as well as FDMA for faster + packet extraction/injection. + +properties: + $nodename: + pattern: "^switch@[0-9a-f]+$" + + compatible: + const: mscc,vsc7514-switch + + reg: + items: + - description: system target + - description: rewriter target + - description: qs target + - description: PTP target + - description: Port0 target + - description: Port1 target + - description: Port2 target + - description: Port3 target + - description: Port4 target + - description: Port5 target + - description: Port6 target + - description: Port7 target + - description: Port8 target + - description: Port9 target + - description: Port10 target + - description: QSystem target + - description: Analyzer target + - description: S0 target + - description: S1 target + - description: S2 target + - description: fdma target + + reg-names: + items: + - const: sys + - const: rew + - const: qs + - const: ptp + - const: port0 + - const: port1 + - const: port2 + - const: port3 + - const: port4 + - const: port5 + - const: port6 + - const: port7 + - const: port8 + - const: port9 + - const: port10 + - const: qsys + - const: ana + - const: s0 + - const: s1 + - const: s2 + - const: fdma + + interrupts: + minItems: 1 + items: + - description: PTP ready + - description: register based extraction + - description: frame dma based extraction + + interrupt-names: + minItems: 1 + items: + - const: ptp_rdy + - const: xtr + - const: fdma + + ethernet-ports: + type: object + + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + additionalProperties: false + + patternProperties: + "^port@[0-9a-f]+$": + type: object + description: Ethernet ports handled by the switch + + $ref: ethernet-controller.yaml# + + unevaluatedProperties: false + + properties: + reg: + description: Switch port number + + phy-handle: true + + phy-mode: true + + fixed-link: true + + mac-address: true + + required: + - reg + - phy-mode + + oneOf: + - required: + - phy-handle + - required: + - fixed-link + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + - ethernet-ports + +additionalProperties: false + +examples: + - | + switch@1010000 { + compatible = "mscc,vsc7514-switch"; + reg = <0x1010000 0x10000>, + <0x1030000 0x10000>, + <0x1080000 0x100>, + <0x10e0000 0x10000>, + <0x11e0000 0x100>, + <0x11f0000 0x100>, + <0x1200000 0x100>, + <0x1210000 0x100>, + <0x1220000 0x100>, + <0x1230000 0x100>, + <0x1240000 0x100>, + <0x1250000 0x100>, + <0x1260000 0x100>, + <0x1270000 0x100>, + <0x1280000 0x100>, + <0x1800000 0x80000>, + <0x1880000 0x10000>, + <0x1040000 0x10000>, + <0x1050000 0x10000>, + <0x1060000 0x10000>, + <0x1a0 0x1c4>; + reg-names = "sys", "rew", "qs", "ptp", "port0", "port1", + "port2", "port3", "port4", "port5", "port6", + "port7", "port8", "port9", "port10", "qsys", + "ana", "s0", "s1", "s2", "fdma"; + interrupts = <18 21 16>; + interrupt-names = "ptp_rdy", "xtr", "fdma"; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port0: port@0 { + reg = <0>; + phy-handle = <&phy0>; + phy-mode = "internal"; + }; + port1: port@1 { + reg = <1>; + phy-handle = <&phy1>; + phy-mode = "internal"; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/net/mscc-ocelot.txt b/Documentation/devicetree/bindings/net/mscc-ocelot.txt deleted file mode 100644 index 3b6290b45ce5..000000000000 --- a/Documentation/devicetree/bindings/net/mscc-ocelot.txt +++ /dev/null @@ -1,83 +0,0 @@ -Microsemi Ocelot network Switch -=============================== - -The Microsemi Ocelot network switch can be found on Microsemi SoCs (VSC7513, -VSC7514) - -Required properties: -- compatible: Should be "mscc,vsc7514-switch" -- reg: Must contain an (offset, length) pair of the register set for each - entry in reg-names. -- reg-names: Must include the following entries: - - "sys" - - "rew" - - "qs" - - "ptp" (optional due to backward compatibility) - - "qsys" - - "ana" - - "portX" with X from 0 to the number of last port index available on that - switch -- interrupts: Should contain the switch interrupts for frame extraction, - frame injection and PTP ready. -- interrupt-names: should contain the interrupt names: "xtr", "inj". Can contain - "ptp_rdy" which is optional due to backward compatibility. -- ethernet-ports: A container for child nodes representing switch ports. - -The ethernet-ports container has the following properties - -Required properties: - -- #address-cells: Must be 1 -- #size-cells: Must be 0 - -Each port node must have the following mandatory properties: -- reg: Describes the port address in the switch - -Port nodes may also contain the following optional standardised -properties, described in binding documents: - -- phy-handle: Phandle to a PHY on an MDIO bus. See - Documentation/devicetree/bindings/net/ethernet.txt for details. - -Example: - - switch@1010000 { - compatible = "mscc,vsc7514-switch"; - reg = <0x1010000 0x10000>, - <0x1030000 0x10000>, - <0x1080000 0x100>, - <0x10e0000 0x10000>, - <0x11e0000 0x100>, - <0x11f0000 0x100>, - <0x1200000 0x100>, - <0x1210000 0x100>, - <0x1220000 0x100>, - <0x1230000 0x100>, - <0x1240000 0x100>, - <0x1250000 0x100>, - <0x1260000 0x100>, - <0x1270000 0x100>, - <0x1280000 0x100>, - <0x1800000 0x80000>, - <0x1880000 0x10000>; - reg-names = "sys", "rew", "qs", "ptp", "port0", "port1", - "port2", "port3", "port4", "port5", "port6", - "port7", "port8", "port9", "port10", "qsys", - "ana"; - interrupts = <18 21 22>; - interrupt-names = "ptp_rdy", "xtr", "inj"; - - ethernet-ports { - #address-cells = <1>; - #size-cells = <0>; - - port0: port@0 { - reg = <0>; - phy-handle = <&phy0>; - }; - port1: port@1 { - reg = <1>; - phy-handle = <&phy1>; - }; - }; - }; -- cgit From 7ea75dd386be6fc15763c4adba67b35e5f051b70 Mon Sep 17 00:00:00 2001 From: Sergiu Moga Date: Thu, 10 Mar 2022 13:45:52 +0200 Subject: dt-bindings: i2c: convert i2c-at91 to json-schema Convert I2C binding for Atmel/Microchip SoCs to Device Tree Schema format. Signed-off-by: Sergiu Moga Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220310114553.184763-3-sergiu.moga@microchip.com --- .../devicetree/bindings/i2c/atmel,at91sam-i2c.yaml | 140 +++++++++++++++++++++ Documentation/devicetree/bindings/i2c/i2c-at91.txt | 82 ------------ 2 files changed, 140 insertions(+), 82 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-at91.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml b/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml new file mode 100644 index 000000000000..a64b7d0ce6bf --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml @@ -0,0 +1,140 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/atmel,at91sam-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: I2C for Atmel/Microchip platforms + +maintainers: + - Alexandre Belloni + +properties: + compatible: + enum: + - atmel,at91rm9200-i2c + - atmel,at91sam9261-i2c + - atmel,at91sam9260-i2c + - atmel,at91sam9g20-i2c + - atmel,at91sam9g10-i2c + - atmel,at91sam9x5-i2c + - atmel,sama5d4-i2c + - atmel,sama5d2-i2c + - microchip,sam9x60-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + clocks: + maxItems: 1 + + clock-frequency: + default: 100000 + + dmas: + items: + - description: TX DMA Channel Specifier + - description: RX DMA Channel Specifier + + dma-names: + items: + - const: tx + - const: rx + + atmel,fifo-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Maximum number of data the RX and TX FIFOs can store for + FIFO capable I2C controllers. + + scl-gpios: true + + sda-gpios: true + +required: + - compatible + - reg + - interrupts + - "#address-cells" + - "#size-cells" + - clocks + +allOf: + - $ref: "i2c-controller.yaml" + - if: + properties: + compatible: + contains: + enum: + - atmel,sama5d4-i2c + - atmel,sama5d2-i2c + - microchip,sam9x60-i2c + then: + properties: + i2c-sda-hold-time-ns: + description: + TWD hold time + maxItems: 1 + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + + i2c0: i2c@fff84000 { + compatible = "atmel,at91sam9g20-i2c"; + reg = <0xfff84000 0x100>; + interrupts = <12 IRQ_TYPE_LEVEL_HIGH 6>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&twi0_clk>; + clock-frequency = <400000>; + + eeprom@50 { + compatible = "atmel,24c512"; + reg = <0x50>; + pagesize = <128>; + }; + }; + + i2c1: i2c@f8034600 { + compatible = "atmel,sama5d2-i2c"; + reg = <0xf8034600 0x100>; + interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>; + dmas = <&dma0 + (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)) + AT91_XDMAC_DT_PERID(11)>, + <&dma0 + (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)) + AT91_XDMAC_DT_PERID(12)>; + dma-names = "tx", "rx"; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&flx0>; + atmel,fifo-size = <16>; + i2c-sda-hold-time-ns = <336>; + pinctrl-names = "default", "gpio"; + pinctrl-0 = <&pinctrl_i2c0>; + pinctrl-1 = <&pinctrl_i2c0_gpio>; + sda-gpios = <&pioA 30 GPIO_ACTIVE_HIGH>; + scl-gpios = <&pioA 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + + eeprom@54 { + compatible = "atmel,24c02"; + reg = <0x54>; + pagesize = <16>; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt deleted file mode 100644 index 2015f50aed0f..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt +++ /dev/null @@ -1,82 +0,0 @@ -I2C for Atmel platforms - -Required properties : -- compatible : Must be one of: - "atmel,at91rm9200-i2c", - "atmel,at91sam9261-i2c", - "atmel,at91sam9260-i2c", - "atmel,at91sam9g20-i2c", - "atmel,at91sam9g10-i2c", - "atmel,at91sam9x5-i2c", - "atmel,sama5d4-i2c", - "atmel,sama5d2-i2c", - "microchip,sam9x60-i2c". -- reg: physical base address of the controller and length of memory mapped - region. -- interrupts: interrupt number to the cpu. -- #address-cells = <1>; -- #size-cells = <0>; -- clocks: phandles to input clocks. - -Optional properties: -- clock-frequency: Desired I2C bus frequency in Hz, otherwise defaults to 100000 -- dmas: A list of two dma specifiers, one for each entry in dma-names. -- dma-names: should contain "tx" and "rx". -- atmel,fifo-size: maximum number of data the RX and TX FIFOs can store for FIFO - capable I2C controllers. -- i2c-sda-hold-time-ns: TWD hold time, only available for: - "atmel,sama5d4-i2c", - "atmel,sama5d2-i2c", - "microchip,sam9x60-i2c". -- scl-gpios: specify the gpio related to SCL pin -- sda-gpios: specify the gpio related to SDA pin -- pinctrl: add extra pinctrl to configure i2c pins to gpio function for i2c - bus recovery, call it "gpio" state -- Child nodes conforming to i2c bus binding - - -Examples : - -i2c0: i2c@fff84000 { - compatible = "atmel,at91sam9g20-i2c"; - reg = <0xfff84000 0x100>; - interrupts = <12 4 6>; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&twi0_clk>; - clock-frequency = <400000>; - - 24c512@50 { - compatible = "atmel,24c512"; - reg = <0x50>; - pagesize = <128>; - } -} - -i2c0: i2c@f8034600 { - compatible = "atmel,sama5d2-i2c"; - reg = <0xf8034600 0x100>; - interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>; - dmas = <&dma0 - (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)) - AT91_XDMAC_DT_PERID(11)>, - <&dma0 - (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)) - AT91_XDMAC_DT_PERID(12)>; - dma-names = "tx", "rx"; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&flx0>; - atmel,fifo-size = <16>; - i2c-sda-hold-time-ns = <336>; - pinctrl-names = "default", "gpio"; - pinctrl-0 = <&pinctrl_i2c0>; - pinctrl-1 = <&pinctrl_i2c0_gpio>; - sda-gpios = <&pioA 30 GPIO_ACTIVE_HIGH>; - scl-gpios = <&pioA 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; - - wm8731: wm8731@1a { - compatible = "wm8731"; - reg = <0x1a>; - }; -}; -- cgit From 2a4013c0cc29929d957119972c36b0368a3b4023 Mon Sep 17 00:00:00 2001 From: Sergiu Moga Date: Thu, 10 Mar 2022 13:45:53 +0200 Subject: dt-bindings: i2c: at91: Add SAMA7G5 compatible strings list Add compatible strings list for SAMA7G5. Signed-off-by: Sergiu Moga Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220310114553.184763-4-sergiu.moga@microchip.com --- .../devicetree/bindings/i2c/atmel,at91sam-i2c.yaml | 26 +++++++++++++--------- 1 file changed, 16 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml b/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml index a64b7d0ce6bf..ea2303c0e143 100644 --- a/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml @@ -12,16 +12,21 @@ maintainers: properties: compatible: - enum: - - atmel,at91rm9200-i2c - - atmel,at91sam9261-i2c - - atmel,at91sam9260-i2c - - atmel,at91sam9g20-i2c - - atmel,at91sam9g10-i2c - - atmel,at91sam9x5-i2c - - atmel,sama5d4-i2c - - atmel,sama5d2-i2c - - microchip,sam9x60-i2c + oneOf: + - items: + - enum: + - atmel,at91rm9200-i2c + - atmel,at91sam9261-i2c + - atmel,at91sam9260-i2c + - atmel,at91sam9g20-i2c + - atmel,at91sam9g10-i2c + - atmel,at91sam9x5-i2c + - atmel,sama5d4-i2c + - atmel,sama5d2-i2c + - microchip,sam9x60-i2c + - items: + - const: microchip,sama7g5-i2c + - const: microchip,sam9x60-i2c reg: maxItems: 1 @@ -79,6 +84,7 @@ allOf: - atmel,sama5d4-i2c - atmel,sama5d2-i2c - microchip,sam9x60-i2c + - microchip,sama7g5-i2c then: properties: i2c-sda-hold-time-ns: -- cgit From c31b32fef8defb3f56ac969696f57acfbd054071 Mon Sep 17 00:00:00 2001 From: Emil Renner Berthing Date: Wed, 26 Jan 2022 18:39:50 +0100 Subject: dt-bindings: clock: Add starfive,jh7100-audclk bindings Add bindings for the audio clocks on the StarFive JH7100 RISC-V SoC. Signed-off-by: Emil Renner Berthing Link: https://lore.kernel.org/r/20220126173953.1016706-5-kernel@esmil.dk Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- .../bindings/clock/starfive,jh7100-audclk.yaml | 57 ++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/starfive,jh7100-audclk.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7100-audclk.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7100-audclk.yaml new file mode 100644 index 000000000000..8f49a1ae03f1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/starfive,jh7100-audclk.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/starfive,jh7100-audclk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7100 Audio Clock Generator + +maintainers: + - Emil Renner Berthing + +properties: + compatible: + const: starfive,jh7100-audclk + + reg: + maxItems: 1 + + clocks: + items: + - description: Audio source clock + - description: External 12.288MHz clock + - description: Domain 7 AHB bus clock + + clock-names: + items: + - const: audio_src + - const: audio_12288 + - const: dom7ahb_bus + + '#clock-cells': + const: 1 + description: + See for valid indices. + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include + + clock-controller@10480000 { + compatible = "starfive,jh7100-audclk"; + reg = <0x10480000 0x10000>; + clocks = <&clkgen JH7100_CLK_AUDIO_SRC>, + <&clkgen JH7100_CLK_AUDIO_12288>, + <&clkgen JH7100_CLK_DOM7AHB_BUS>; + clock-names = "audio_src", "audio_12288", "dom7ahb_bus"; + #clock-cells = <1>; + }; -- cgit From cac2ed0a1b0653d95e8714667385214b06f67c0f Mon Sep 17 00:00:00 2001 From: Manivannan Sadhasivam Date: Wed, 9 Mar 2022 20:45:40 +0530 Subject: dt-bindings: dvfs: Use MediaTek CPUFREQ HW as an example Qcom CPUFREQ HW don't have the support for generic performance domains yet. So use MediaTek CPUFREQ HW that has the support available in mainline. This also silences the below dtschema warnings for "cpufreq-qcom-hw.yaml": Documentation/devicetree/bindings/dvfs/performance-domain.example.dt.yaml: performance-controller@12340000: reg: [[305397760, 4096]] is too short From schema: Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml Documentation/devicetree/bindings/dvfs/performance-domain.example.dt.yaml: performance-controller@12340000: 'clocks' is a required property From schema: Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml Documentation/devicetree/bindings/dvfs/performance-domain.example.dt.yaml: performance-controller@12340000: 'clock-names' is a required property From schema: Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml Documentation/devicetree/bindings/dvfs/performance-domain.example.dt.yaml: performance-controller@12340000: '#freq-domain-cells' is a required property From schema: Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml Documentation/devicetree/bindings/dvfs/performance-domain.example.dt.yaml: performance-controller@12340000: '#performance-domain-cells' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml Cc: Hector Yuan Cc: Sudeep Holla Signed-off-by: Manivannan Sadhasivam Acked-by: Sudeep Holla Reviewed-by: Rob Herring Signed-off-by: Viresh Kumar --- .../devicetree/bindings/dvfs/performance-domain.yaml | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dvfs/performance-domain.yaml b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml index c8b91207f34d..9e0bcf1a89fe 100644 --- a/Documentation/devicetree/bindings/dvfs/performance-domain.yaml +++ b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml @@ -52,10 +52,16 @@ additionalProperties: true examples: - | - performance: performance-controller@12340000 { - compatible = "qcom,cpufreq-hw"; - reg = <0x12340000 0x1000>; - #performance-domain-cells = <1>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + performance: performance-controller@11bc00 { + compatible = "mediatek,cpufreq-hw"; + reg = <0 0x0011bc10 0 0x120>, <0 0x0011bd30 0 0x120>; + + #performance-domain-cells = <1>; + }; }; // The node above defines a performance controller that is a performance -- cgit From b7f2b0d3511a6bbf9387f08f370f9125663e18d8 Mon Sep 17 00:00:00 2001 From: Manivannan Sadhasivam Date: Wed, 9 Mar 2022 20:45:41 +0530 Subject: dt-bindings: cpufreq: cpufreq-qcom-hw: Convert to YAML bindings Convert Qualcomm cpufreq devicetree binding to YAML. Signed-off-by: Manivannan Sadhasivam Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Signed-off-by: Viresh Kumar --- .../bindings/cpufreq/cpufreq-qcom-hw.txt | 172 ------------------ .../bindings/cpufreq/cpufreq-qcom-hw.yaml | 201 +++++++++++++++++++++ 2 files changed, 201 insertions(+), 172 deletions(-) delete mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt deleted file mode 100644 index 9299028ee712..000000000000 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt +++ /dev/null @@ -1,172 +0,0 @@ -Qualcomm Technologies, Inc. CPUFREQ Bindings - -CPUFREQ HW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI) -SoCs to manage frequency in hardware. It is capable of controlling frequency -for multiple clusters. - -Properties: -- compatible - Usage: required - Value type: - Definition: must be "qcom,cpufreq-hw" or "qcom,cpufreq-epss". - -- clocks - Usage: required - Value type: From common clock binding. - Definition: clock handle for XO clock and GPLL0 clock. - -- clock-names - Usage: required - Value type: From common clock binding. - Definition: must be "xo", "alternate". - -- reg - Usage: required - Value type: - Definition: Addresses and sizes for the memory of the HW bases in - each frequency domain. -- reg-names - Usage: Optional - Value type: - Definition: Frequency domain name i.e. - "freq-domain0", "freq-domain1". - -- #freq-domain-cells: - Usage: required. - Definition: Number of cells in a freqency domain specifier. - -* Property qcom,freq-domain -Devices supporting freq-domain must set their "qcom,freq-domain" property with -phandle to a cpufreq_hw followed by the Domain ID(0/1) in the CPU DT node. - - -Example: - -Example 1: Dual-cluster, Quad-core per cluster. CPUs within a cluster switch -DCVS state together. - -/ { - cpus { - #address-cells = <2>; - #size-cells = <0>; - - CPU0: cpu@0 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x0>; - enable-method = "psci"; - next-level-cache = <&L2_0>; - qcom,freq-domain = <&cpufreq_hw 0>; - L2_0: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - L3_0: l3-cache { - compatible = "cache"; - }; - }; - }; - - CPU1: cpu@100 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x100>; - enable-method = "psci"; - next-level-cache = <&L2_100>; - qcom,freq-domain = <&cpufreq_hw 0>; - L2_100: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - }; - }; - - CPU2: cpu@200 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x200>; - enable-method = "psci"; - next-level-cache = <&L2_200>; - qcom,freq-domain = <&cpufreq_hw 0>; - L2_200: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - }; - }; - - CPU3: cpu@300 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x300>; - enable-method = "psci"; - next-level-cache = <&L2_300>; - qcom,freq-domain = <&cpufreq_hw 0>; - L2_300: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - }; - }; - - CPU4: cpu@400 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x400>; - enable-method = "psci"; - next-level-cache = <&L2_400>; - qcom,freq-domain = <&cpufreq_hw 1>; - L2_400: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - }; - }; - - CPU5: cpu@500 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x500>; - enable-method = "psci"; - next-level-cache = <&L2_500>; - qcom,freq-domain = <&cpufreq_hw 1>; - L2_500: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - }; - }; - - CPU6: cpu@600 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x600>; - enable-method = "psci"; - next-level-cache = <&L2_600>; - qcom,freq-domain = <&cpufreq_hw 1>; - L2_600: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - }; - }; - - CPU7: cpu@700 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x700>; - enable-method = "psci"; - next-level-cache = <&L2_700>; - qcom,freq-domain = <&cpufreq_hw 1>; - L2_700: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - }; - }; - }; - - soc { - cpufreq_hw: cpufreq@17d43000 { - compatible = "qcom,cpufreq-hw"; - reg = <0x17d43000 0x1400>, <0x17d45800 0x1400>; - reg-names = "freq-domain0", "freq-domain1"; - - clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>; - clock-names = "xo", "alternate"; - - #freq-domain-cells = <1>; - }; -} diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml new file mode 100644 index 000000000000..2f1b8b6852a0 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml @@ -0,0 +1,201 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/cpufreq/cpufreq-qcom-hw.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. CPUFREQ + +maintainers: + - Manivannan Sadhasivam + +description: | + + CPUFREQ HW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI) + SoCs to manage frequency in hardware. It is capable of controlling frequency + for multiple clusters. + +properties: + compatible: + oneOf: + - description: v1 of CPUFREQ HW + items: + - const: qcom,cpufreq-hw + + - description: v2 of CPUFREQ HW (EPSS) + items: + - enum: + - qcom,sm8250-cpufreq-epss + - const: qcom,cpufreq-epss + + reg: + minItems: 2 + items: + - description: Frequency domain 0 register region + - description: Frequency domain 1 register region + - description: Frequency domain 2 register region + + reg-names: + minItems: 2 + items: + - const: freq-domain0 + - const: freq-domain1 + - const: freq-domain2 + + clocks: + items: + - description: XO Clock + - description: GPLL0 Clock + + clock-names: + items: + - const: xo + - const: alternate + + '#freq-domain-cells': + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#freq-domain-cells' + +additionalProperties: false + +examples: + - | + #include + #include + + // Example 1: Dual-cluster, Quad-core per cluster. CPUs within a cluster + // switch DCVS state together. + cpus { + #address-cells = <2>; + #size-cells = <0>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x0>; + enable-method = "psci"; + next-level-cache = <&L2_0>; + qcom,freq-domain = <&cpufreq_hw 0>; + L2_0: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + L3_0: l3-cache { + compatible = "cache"; + }; + }; + }; + + CPU1: cpu@100 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x100>; + enable-method = "psci"; + next-level-cache = <&L2_100>; + qcom,freq-domain = <&cpufreq_hw 0>; + L2_100: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU2: cpu@200 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x200>; + enable-method = "psci"; + next-level-cache = <&L2_200>; + qcom,freq-domain = <&cpufreq_hw 0>; + L2_200: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU3: cpu@300 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x300>; + enable-method = "psci"; + next-level-cache = <&L2_300>; + qcom,freq-domain = <&cpufreq_hw 0>; + L2_300: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU4: cpu@400 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x400>; + enable-method = "psci"; + next-level-cache = <&L2_400>; + qcom,freq-domain = <&cpufreq_hw 1>; + L2_400: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU5: cpu@500 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x500>; + enable-method = "psci"; + next-level-cache = <&L2_500>; + qcom,freq-domain = <&cpufreq_hw 1>; + L2_500: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU6: cpu@600 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x600>; + enable-method = "psci"; + next-level-cache = <&L2_600>; + qcom,freq-domain = <&cpufreq_hw 1>; + L2_600: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU7: cpu@700 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x700>; + enable-method = "psci"; + next-level-cache = <&L2_700>; + qcom,freq-domain = <&cpufreq_hw 1>; + L2_700: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + }; + + soc { + #address-cells = <1>; + #size-cells = <1>; + + cpufreq@17d43000 { + compatible = "qcom,cpufreq-hw"; + reg = <0x17d43000 0x1400>, <0x17d45800 0x1400>; + reg-names = "freq-domain0", "freq-domain1"; + + clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>; + clock-names = "xo", "alternate"; + + #freq-domain-cells = <1>; + }; + }; +... -- cgit From ab1fd5abb75001d37e1fef5f310951b56f41ad58 Mon Sep 17 00:00:00 2001 From: Hector Martin Date: Thu, 10 Mar 2022 04:21:18 +0900 Subject: dt-bindings: interrupt-controller: apple,aic2: New binding for AICv2 This new incompatible revision of the AIC peripheral introduces multi-die support. This binding is based on apple,aic, but changes interrupt-cells to add a new die argument. Also adds a second reg entry to specify the offset of the event register. Inexplicably, the capability registers allow us to compute other register offsets, but not this one. This allows us to keep forward-compatibility with future SoCs that will likely implement different die counts, thus shifting the event register. Apple also specify the offset explicitly in their device tree... Reviewed-by: Rob Herring Signed-off-by: Hector Martin Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220309192123.152028-3-marcan@marcan.st --- .../bindings/interrupt-controller/apple,aic2.yaml | 98 ++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml new file mode 100644 index 000000000000..47a78a167aba --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/apple,aic2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Interrupt Controller 2 + +maintainers: + - Hector Martin + +description: | + The Apple Interrupt Controller 2 is a simple interrupt controller present on + Apple ARM SoC platforms starting with t600x (M1 Pro and Max). + + It provides the following features: + + - Level-triggered hardware IRQs wired to SoC blocks + - Single mask bit per IRQ + - Automatic masking on event delivery (auto-ack) + - Software triggering (ORed with hw line) + - Automatic prioritization (single event/ack register per CPU, lower IRQs = + higher priority) + - Automatic masking on ack + - Support for multiple dies + + This device also represents the FIQ interrupt sources on platforms using AIC, + which do not go through a discrete interrupt controller. It also handles + FIQ-based Fast IPIs. + +properties: + compatible: + items: + - const: apple,t6000-aic + - const: apple,aic2 + + interrupt-controller: true + + '#interrupt-cells': + const: 4 + description: | + The 1st cell contains the interrupt type: + - 0: Hardware IRQ + - 1: FIQ + + The 2nd cell contains the die ID. + + The next cell contains the interrupt number. + - HW IRQs: interrupt number + - FIQs: + - 0: physical HV timer + - 1: virtual HV timer + - 2: physical guest timer + - 3: virtual guest timer + + The last cell contains the interrupt flags. This is normally + IRQ_TYPE_LEVEL_HIGH (4). + + reg: + items: + - description: Address and size of the main AIC2 registers. + - description: Address and size of the AIC2 Event register. + + reg-names: + items: + - const: core + - const: event + + power-domains: + maxItems: 1 + +required: + - compatible + - '#interrupt-cells' + - interrupt-controller + - reg + - reg-names + +additionalProperties: false + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + aic: interrupt-controller@28e100000 { + compatible = "apple,t6000-aic", "apple,aic2"; + #interrupt-cells = <4>; + interrupt-controller; + reg = <0x2 0x8e100000 0x0 0xc000>, + <0x2 0x8e10c000 0x0 0x4>; + reg-names = "core", "event"; + }; + }; -- cgit From 6427c165275fe11634862149002c7867f25d02f6 Mon Sep 17 00:00:00 2001 From: Anton Ivanov Date: Tue, 4 Jan 2022 10:44:57 +0000 Subject: um: Document dtb command line option Add documentation for the dtb command line option and the ability to load/parse device trees. Signed-off-by: Anton Ivanov Reviewed-by: Vincent Whitchurch Signed-off-by: Richard Weinberger --- Documentation/virt/uml/user_mode_linux_howto_v2.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst index 2cafd3c3c6cb..81986fe014d4 100644 --- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst +++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst @@ -1189,6 +1189,26 @@ E.g. ``os_close_file()`` is just a wrapper around ``close()`` which ensures that the userspace function close does not clash with similarly named function(s) in the kernel part. +Using UML as a Test Platform +============================ + +UML is an excellent test platform for device driver development. As +with most things UML, "some user assembly may be required". It is +up to the user to build their emulation environment. UML at present +provides only the kernel infrastructure. + +Part of this infrastructure is the ability to load and parse fdt +device tree blobs as used in Arm or Open Firmware platforms. These +are supplied as an optional extra argument to the kernel command +line:: + + dtb=filename + +The device tree is loaded and parsed at boottime and is accessible by +drivers which query it. At this moment in time this facility is +intended solely for development purposes. UML's own devices do not +query the device tree. + Security Considerations ----------------------- -- cgit From 4ef5a0b2e1b806203831b0a7a044539f6627116a Mon Sep 17 00:00:00 2001 From: Vincent Whitchurch Date: Thu, 10 Mar 2022 13:42:30 +0100 Subject: docs: UML: Mention telnetd for port channel It is not obvious from the documentation that using the "port" channel for the console requires telnetd to be installed (see port_connection() in arch/um/drivers/port_user.c). Mention this, and the fact that UML will not boot until a client connects. Signed-off-by: Vincent Whitchurch Acked-by: Anton Ivanov Signed-off-by: Richard Weinberger --- Documentation/virt/uml/user_mode_linux_howto_v2.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst index 81986fe014d4..863f67b72c05 100644 --- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst +++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst @@ -664,7 +664,11 @@ one is input, the second one output. * The fd channel - use file descriptor numbers for input/output. Example: ``con1=fd:0,fd:1.`` -* The port channel - listen on TCP port number. Example: ``con1=port:4321`` +* The port channel - start a telnet server on TCP port number. Example: + ``con1=port:4321``. The host must have /usr/sbin/in.telnetd (usually part of + a telnetd package) and the port-helper from the UML utilities (see the + information for the xterm channel below). UML will not boot until a client + connects. * The pty and pts channels - use system pty/pts. -- cgit From 9c391cebedf59a13d2fb3176bc010edbffb317af Mon Sep 17 00:00:00 2001 From: AngeloGioacchino Del Regno Date: Thu, 17 Feb 2022 10:52:42 +0100 Subject: dt-bindings: dma: Convert mtk-uart-apdma to DT schema Convert the MediaTek UART APDMA Controller binding to DT schema. Signed-off-by: AngeloGioacchino Del Regno Acked-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220217095242.13761-1-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul --- .../devicetree/bindings/dma/mediatek,uart-dma.yaml | 122 +++++++++++++++++++++ .../devicetree/bindings/dma/mtk-uart-apdma.txt | 56 ---------- 2 files changed, 122 insertions(+), 56 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml delete mode 100644 Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml b/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml new file mode 100644 index 000000000000..54d68fc688b5 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml @@ -0,0 +1,122 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/mediatek,uart-dma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek UART APDMA controller + +maintainers: + - Long Cheng + +description: | + The MediaTek UART APDMA controller provides DMA capabilities + for the UART peripheral bus. + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + oneOf: + - items: + - enum: + - mediatek,mt2712-uart-dma + - mediatek,mt8516-uart-dma + - const: mediatek,mt6577-uart-dma + - enum: + - mediatek,mt6577-uart-dma + + reg: + minItems: 1 + maxItems: 16 + + interrupts: + description: | + TX, RX interrupt lines for each UART APDMA channel + minItems: 1 + maxItems: 16 + + clocks: + description: Must contain one entry for the APDMA main clock + maxItems: 1 + + clock-names: + const: apdma + + "#dma-cells": + const: 1 + description: | + The first cell specifies the UART APDMA channel number + + dma-requests: + description: | + Number of virtual channels of the UART APDMA controller + maximum: 16 + + mediatek,dma-33bits: + type: boolean + description: Enable 33-bits UART APDMA support + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +if: + not: + required: + - dma-requests +then: + properties: + interrupts: + maxItems: 8 + reg: + maxItems: 8 + +examples: + - | + #include + #include + soc { + #address-cells = <2>; + #size-cells = <2>; + + apdma: dma-controller@11000400 { + compatible = "mediatek,mt2712-uart-dma", + "mediatek,mt6577-uart-dma"; + reg = <0 0x11000400 0 0x80>, + <0 0x11000480 0 0x80>, + <0 0x11000500 0 0x80>, + <0 0x11000580 0 0x80>, + <0 0x11000600 0 0x80>, + <0 0x11000680 0 0x80>, + <0 0x11000700 0 0x80>, + <0 0x11000780 0 0x80>, + <0 0x11000800 0 0x80>, + <0 0x11000880 0 0x80>, + <0 0x11000900 0 0x80>, + <0 0x11000980 0 0x80>; + interrupts = , + , + , + , + , + , + , + , + , + , + , + ; + dma-requests = <12>; + clocks = <&pericfg CLK_PERI_AP_DMA>; + clock-names = "apdma"; + mediatek,dma-33bits; + #dma-cells = <1>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt b/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt deleted file mode 100644 index fef9c1eeb264..000000000000 --- a/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt +++ /dev/null @@ -1,56 +0,0 @@ -* Mediatek UART APDMA Controller - -Required properties: -- compatible should contain: - * "mediatek,mt2712-uart-dma" for MT2712 compatible APDMA - * "mediatek,mt6577-uart-dma" for MT6577 and all of the above - * "mediatek,mt8516-uart-dma", "mediatek,mt6577" for MT8516 SoC - -- reg: The base address of the APDMA register bank. - -- interrupts: A single interrupt specifier. - One interrupt per dma-requests, or 8 if no dma-requests property is present - -- dma-requests: The number of DMA channels - -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names: The APDMA clock for register accesses - -- mediatek,dma-33bits: Present if the DMA requires support - -Examples: - - apdma: dma-controller@11000400 { - compatible = "mediatek,mt2712-uart-dma", - "mediatek,mt6577-uart-dma"; - reg = <0 0x11000400 0 0x80>, - <0 0x11000480 0 0x80>, - <0 0x11000500 0 0x80>, - <0 0x11000580 0 0x80>, - <0 0x11000600 0 0x80>, - <0 0x11000680 0 0x80>, - <0 0x11000700 0 0x80>, - <0 0x11000780 0 0x80>, - <0 0x11000800 0 0x80>, - <0 0x11000880 0 0x80>, - <0 0x11000900 0 0x80>, - <0 0x11000980 0 0x80>; - interrupts = , - , - , - , - , - , - , - , - , - , - , - ; - dma-requests = <12>; - clocks = <&pericfg CLK_PERI_AP_DMA>; - clock-names = "apdma"; - mediatek,dma-33bits; - #dma-cells = <1>; - }; -- cgit From ff1d56cb2653e673859bc6233b71762de13c067a Mon Sep 17 00:00:00 2001 From: Jonathan Lemon Date: Thu, 10 Mar 2022 12:19:12 -0800 Subject: docs: ABI: Document new timecard sysfs nodes. Add sysfs nodes for the frequency generator and signal counters. Update SMA selector lists for these, and also add the new 'None', 'VCC' 'GND' selectors. Signed-off-by: Jonathan Lemon Signed-off-by: David S. Miller --- Documentation/ABI/testing/sysfs-timecard | 94 +++++++++++++++++++++++++++++++- 1 file changed, 93 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-timecard b/Documentation/ABI/testing/sysfs-timecard index 5bf78486a469..220478156297 100644 --- a/Documentation/ABI/testing/sysfs-timecard +++ b/Documentation/ABI/testing/sysfs-timecard @@ -37,8 +37,15 @@ Description: (RO) Set of available destinations (sinks) for a SMA PPS2 signal is sent to the PPS2 selector TS1 signal is sent to timestamper 1 TS2 signal is sent to timestamper 2 + TS3 signal is sent to timestamper 3 + TS4 signal is sent to timestamper 4 IRIG signal is sent to the IRIG-B module DCF signal is sent to the DCF module + FREQ1 signal is sent to frequency counter 1 + FREQ2 signal is sent to frequency counter 2 + FREQ3 signal is sent to frequency counter 3 + FREQ4 signal is sent to frequency counter 4 + None signal input is disabled ===== ================================================ What: /sys/class/timecard/ocpN/available_sma_outputs @@ -50,10 +57,16 @@ Description: (RO) Set of available sources for a SMA output signal. 10Mhz output is from the 10Mhz reference clock PHC output PPS is from the PHC clock MAC output PPS is from the Miniature Atomic Clock - GNSS output PPS is from the GNSS module + GNSS1 output PPS is from the first GNSS module GNSS2 output PPS is from the second GNSS module IRIG output is from the PHC, in IRIG-B format DCF output is from the PHC, in DCF format + GEN1 output is from frequency generator 1 + GEN2 output is from frequency generator 2 + GEN3 output is from frequency generator 3 + GEN4 output is from frequency generator 4 + GND output is GND + VCC output is VCC ===== ================================================ What: /sys/class/timecard/ocpN/clock_source @@ -75,6 +88,85 @@ Contact: Jonathan Lemon Description: (RO) Contains the current offset value used by the firmware for internal disciplining of the atomic clock. +What: /sys/class/timecard/ocpN/freqX +Date: March 2022 +Contact: Jonathan Lemon +Description: (RO) Optional directory containing the sysfs nodes for + frequency counter . + +What: /sys/class/timecard/ocpN/freqX/frequency +Date: March 2022 +Contact: Jonathan Lemon +Description: (RO) Contains the measured frequency over the specified + measurement period. + +What: /sys/class/timecard/ocpN/freqX/seconds +Date: March 2022 +Contact: Jonathan Lemon +Description: (RW) Specifies the number of seconds from 0-255 that the + frequency should be measured over. Write 0 to disable. + +What: /sys/class/timecard/ocpN/genX +Date: March 2022 +Contact: Jonathan Lemon +Description: (RO) Optional directory containing the sysfs nodes for + frequency generator . + +What: /sys/class/timecard/ocpN/genX/duty +Date: March 2022 +Contact: Jonathan Lemon +Description: (RO) Specifies the signal duty cycle as a percentage from 1-99. + +What: /sys/class/timecard/ocpN/genX/period +Date: March 2022 +Contact: Jonathan Lemon +Description: (RO) Specifies the signal period in nanoseconds. + +What: /sys/class/timecard/ocpN/genX/phase +Date: March 2022 +Contact: Jonathan Lemon +Description: (RO) Specifies the signal phase offset in nanoseconds. + +What: /sys/class/timecard/ocpN/genX/polarity +Date: March 2022 +Contact: Jonathan Lemon +Description: (RO) Specifies the signal polarity, either 1 or 0. + +What: /sys/class/timecard/ocpN/genX/running +Date: March 2022 +Contact: Jonathan Lemon +Description: (RO) Either 0 or 1, showing if the signal generator is running. + +What: /sys/class/timecard/ocpN/genX/start +Date: March 2022 +Contact: Jonathan Lemon +Description: (RO) Shows the time in . that the signal generator + started running. + +What: /sys/class/timecard/ocpN/genX/signal +Date: March 2022 +Contact: Jonathan Lemon +Description: (RW) Used to start the signal generator, and summarize + the current status. + + The signal generator may be started by writing the signal + period, followed by the optional signal values. If the + optional values are not provided, they default to the current + settings, which may be obtained from the other sysfs nodes. + + period [duty [phase [polarity]]] + + echo 500000000 > signal # 1/2 second period + echo 1000000 40 100 > signal + echo 0 > signal # turn off generator + + Period and phase are specified in nanoseconds. Duty cycle is + a percentage from 1-99. Polarity is 1 or 0. + + Reading this node will return: + + period duty phase polarity start_time + What: /sys/class/timecard/ocpN/gnss_sync Date: September 2021 Contact: Jonathan Lemon -- cgit From ee7f79a81a27c47088fe0af95788621644826d91 Mon Sep 17 00:00:00 2001 From: Trevor Wu Date: Tue, 8 Mar 2022 15:24:32 +0800 Subject: dt-bindings: mediatek: mt8195: add reset property Add required properties "resets" and "reset_names", which are used to specify audiosys hw reset for mt8195 afe driver. Signed-off-by: Trevor Wu Link: https://lore.kernel.org/r/20220308072435.22460-3-trevor.wu@mediatek.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml index 6d0975b33d15..4452a4070eff 100644 --- a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml +++ b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml @@ -19,6 +19,12 @@ properties: interrupts: maxItems: 1 + resets: + maxItems: 1 + + reset-names: + const: audiosys + memory-region: maxItems: 1 description: | @@ -127,6 +133,8 @@ required: - compatible - reg - interrupts + - resets + - reset-names - mediatek,topckgen - power-domains - clocks @@ -144,6 +152,8 @@ examples: compatible = "mediatek,mt8195-audio"; reg = <0x10890000 0x10000>; interrupts = ; + resets = <&watchdog 14>; + reset-names = "audiosys"; mediatek,topckgen = <&topckgen>; power-domains = <&spm 7>; //MT8195_POWER_DOMAIN_AUDIO memory-region = <&snd_dma_mem_reserved>; -- cgit From 1889421a891ff439b25495011b8b75f81660abca Mon Sep 17 00:00:00 2001 From: Kuldeep Singh Date: Wed, 9 Mar 2022 22:48:47 +0530 Subject: spi: Update clock-names property for arm pl022 PL022 has two input clocks named sspclk and apb_pclk. Current schema refers to two notations of sspclk which are indeed same and thus one can be dropped. Update clock-names property to reflect the same. Signed-off-by: Kuldeep Singh Link: https://lore.kernel.org/r/20220309171847.5345-1-singh.kuldeep87k@gmail.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-pl022.yaml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-pl022.yaml b/Documentation/devicetree/bindings/spi/spi-pl022.yaml index 6d633728fc2b..bda45ff3d294 100644 --- a/Documentation/devicetree/bindings/spi/spi-pl022.yaml +++ b/Documentation/devicetree/bindings/spi/spi-pl022.yaml @@ -38,9 +38,7 @@ properties: clock-names: items: - - enum: - - SSPCLK - - sspclk + - const: sspclk - const: apb_pclk pl022,autosuspend-delay: -- cgit From 1d9a770bc8f080267bba6b2169c87efb61f245c1 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 9 Mar 2022 19:35:52 -0600 Subject: dt-bindings: arm: Convert QEMU fw-cfg to DT schema Convert the QEMU fw-cfg binding to DT schema format. As this binding is also used on Risc-V now, drop any architecture references and move to a common location. The fw-cfg interface has also gained some DMA support which is coherent, so add the missing 'dma-coherent'. Signed-off-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Acked-by: Laszlo Ersek Link: https://lore.kernel.org/r/20220310013552.549590-1-robh@kernel.org --- Documentation/devicetree/bindings/arm/fw-cfg.txt | 38 --------------- .../bindings/firmware/qemu,fw-cfg-mmio.yaml | 54 ++++++++++++++++++++++ 2 files changed, 54 insertions(+), 38 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/fw-cfg.txt create mode 100644 Documentation/devicetree/bindings/firmware/qemu,fw-cfg-mmio.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fw-cfg.txt b/Documentation/devicetree/bindings/arm/fw-cfg.txt deleted file mode 100644 index fd54e1db2156..000000000000 --- a/Documentation/devicetree/bindings/arm/fw-cfg.txt +++ /dev/null @@ -1,38 +0,0 @@ -* QEMU Firmware Configuration bindings for ARM - -QEMU's arm-softmmu and aarch64-softmmu emulation / virtualization targets -provide the following Firmware Configuration interface on the "virt" machine -type: - -- A write-only, 16-bit wide selector (or control) register, -- a read-write, 64-bit wide data register. - -QEMU exposes the control and data register to ARM guests as memory mapped -registers; their location is communicated to the guest's UEFI firmware in the -DTB that QEMU places at the bottom of the guest's DRAM. - -The authoritative guest-side hardware interface documentation to the fw_cfg -device can be found in "docs/specs/fw_cfg.txt" in the QEMU source tree. - - -Required properties: - -- compatible: "qemu,fw-cfg-mmio". - -- reg: the MMIO region used by the device. - * Bytes 0x0 to 0x7 cover the data register. - * Bytes 0x8 to 0x9 cover the selector register. - * Further registers may be appended to the region in case of future interface - revisions / feature bits. - -Example: - -/ { - #size-cells = <0x2>; - #address-cells = <0x2>; - - fw-cfg@9020000 { - compatible = "qemu,fw-cfg-mmio"; - reg = <0x0 0x9020000 0x0 0xa>; - }; -}; diff --git a/Documentation/devicetree/bindings/firmware/qemu,fw-cfg-mmio.yaml b/Documentation/devicetree/bindings/firmware/qemu,fw-cfg-mmio.yaml new file mode 100644 index 000000000000..fcf0011b8e6d --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/qemu,fw-cfg-mmio.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/qemu,fw-cfg-mmio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: QEMU Firmware Configuration bindings + +maintainers: + - Rob Herring + +description: | + Various QEMU emulation / virtualization targets provide the following + Firmware Configuration interface on the "virt" machine type: + + - A write-only, 16-bit wide selector (or control) register, + - a read-write, 64-bit wide data register. + + QEMU exposes the control and data register to guests as memory mapped + registers; their location is communicated to the guest's UEFI firmware in the + DTB that QEMU places at the bottom of the guest's DRAM. + + The authoritative guest-side hardware interface documentation to the fw_cfg + device can be found in "docs/specs/fw_cfg.txt" in the QEMU source tree. + + +properties: + compatible: + const: qemu,fw-cfg-mmio + + reg: + maxItems: 1 + description: | + * Bytes 0x0 to 0x7 cover the data register. + * Bytes 0x8 to 0x9 cover the selector register. + * Further registers may be appended to the region in case of future interface + revisions / feature bits. + + dma-coherent: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + + fw-cfg@9020000 { + compatible = "qemu,fw-cfg-mmio"; + reg = <0x9020000 0xa>; + }; +... -- cgit From 37de81210f74c909e3d42c90fea3497a00ac618b Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 9 Mar 2022 20:12:24 -0600 Subject: dt-bindings: Add QEMU virt machine compatible The top level QEMU virt machine compatible, linux,dummy-virt, has been in use for a long time, but never documented. Add a schema for it. Signed-off-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220310021224.599398-1-robh@kernel.org --- .../devicetree/bindings/arm/linux,dummy-virt.yaml | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/linux,dummy-virt.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/linux,dummy-virt.yaml b/Documentation/devicetree/bindings/arm/linux,dummy-virt.yaml new file mode 100644 index 000000000000..c7c5eb48fc7e --- /dev/null +++ b/Documentation/devicetree/bindings/arm/linux,dummy-virt.yaml @@ -0,0 +1,20 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/linux,dummy-virt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: QEMU virt machine + +maintainers: + - Rob Herring + +properties: + $nodename: + const: "/" + compatible: + const: linux,dummy-virt + +additionalProperties: true + +... -- cgit From 9d6647762b9c6b555bc83d97d7c93be6057a990f Mon Sep 17 00:00:00 2001 From: Dai Ngo Date: Sat, 12 Feb 2022 10:12:52 -0800 Subject: fs/lock: documentation cleanup. Replace inode->i_lock with flc_lock. Update lock usage of lock_manager_operations' functions to reflect the changes in commit 6109c85037e5 ("locks: add a dedicated spinlock to protect i_flctx lists"). Signed-off-by: Dai Ngo Signed-off-by: Chuck Lever Reviewed-by: Jeff Layton --- Documentation/filesystems/locking.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 3f9b1497ebb8..aaca0b601819 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -438,13 +438,13 @@ prototypes:: locking rules: ====================== ============= ================= ========= -ops inode->i_lock blocked_lock_lock may block +ops flc_lock blocked_lock_lock may block ====================== ============= ================= ========= -lm_notify: yes yes no +lm_notify: no yes no lm_grant: no no no lm_break: yes no no lm_change yes no no -lm_breaker_owns_lease: no no no +lm_breaker_owns_lease: yes no no ====================== ============= ================= ========= buffer_head -- cgit From 2783a7f56f9980f61ca809b826bcd14dc77eb7b9 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Thu, 10 Mar 2022 10:05:12 -0600 Subject: dt-bindings: kbuild: Pass DT_SCHEMA_FILES to dt-validate In preparation for supporting validation of DTB files, the full processed schema will always be needed in order to extract type information from it. Therefore, the processed schema containing only what DT_SCHEMA_FILES specifies won't work. Instead, dt-validate has gained an option, -l or --limit, to specify which schema(s) to use for validation. As the command line option is new, we the minimum dtschema version must be updated. Cc: Masahiro Yamada Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220310160513.1708182-2-robh@kernel.org --- Documentation/devicetree/bindings/Makefile | 28 +++------------------------- 1 file changed, 3 insertions(+), 25 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index 29b5dbd0807e..2716f7b9e25e 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -6,7 +6,7 @@ DT_MK_SCHEMA ?= dt-mk-schema DT_SCHEMA_LINT := $(shell which yamllint || \ echo "warning: python package 'yamllint' not installed, skipping" >&2) -DT_SCHEMA_MIN_VERSION = 2021.2.1 +DT_SCHEMA_MIN_VERSION = 2022.3 PHONY += check_dtschema_version check_dtschema_version: @@ -25,9 +25,6 @@ quiet_cmd_extract_ex = DTEX $@ $(obj)/%.example.dts: $(src)/%.yaml check_dtschema_version FORCE $(call if_changed,extract_ex) -# Use full schemas when checking %.example.dts -DT_TMP_SCHEMA := $(obj)/processed-schema-examples.json - find_all_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \ -name 'processed-schema*' ! \ -name '*.example.dt.yaml' \) @@ -70,29 +67,10 @@ override DTC_FLAGS := \ # Disable undocumented compatible checks until warning free override DT_CHECKER_FLAGS ?= -$(obj)/processed-schema-examples.json: $(DT_DOCS) $(src)/.yamllint check_dtschema_version FORCE +$(obj)/processed-schema.json: $(DT_DOCS) $(src)/.yamllint check_dtschema_version FORCE $(call if_changed_rule,chkdt) -ifeq ($(DT_SCHEMA_FILES),) - -# Unless DT_SCHEMA_FILES is specified, use the full schema for dtbs_check too. -# Just copy processed-schema-examples.json - -$(obj)/processed-schema.json: $(obj)/processed-schema-examples.json FORCE - $(call if_changed,copy) - -else - -# If DT_SCHEMA_FILES is specified, use it for processed-schema.json - -$(obj)/processed-schema.json: DT_MK_SCHEMA_FLAGS := -u -$(obj)/processed-schema.json: $(CHK_DT_DOCS) check_dtschema_version FORCE - $(call if_changed,mk_schema) - -endif - -always-$(CHECK_DT_BINDING) += processed-schema-examples.json -always-$(CHECK_DTBS) += processed-schema.json +always-y += processed-schema.json always-$(CHECK_DT_BINDING) += $(patsubst $(srctree)/$(src)/%.yaml,%.example.dts, $(CHK_DT_DOCS)) always-$(CHECK_DT_BINDING) += $(patsubst $(srctree)/$(src)/%.yaml,%.example.dt.yaml, $(CHK_DT_DOCS)) -- cgit From ba900534f807f0b327c92d5141c85d2313e2d55c Mon Sep 17 00:00:00 2001 From: Jaegeuk Kim Date: Fri, 4 Mar 2022 09:40:05 -0800 Subject: f2fs: don't get FREEZE lock in f2fs_evict_inode in frozen fs Let's purge inode cache in order to avoid the below deadlock. [freeze test] shrinkder freeze_super - pwercpu_down_write(SB_FREEZE_FS) - super_cache_scan - down_read(&sb->s_umount) - prune_icache_sb - dispose_list - evict - f2fs_evict_inode thaw_super - down_write(&sb->s_umount); - __percpu_down_read(SB_FREEZE_FS) Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/ABI/testing/sysfs-fs-f2fs | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 58bf0dc83712..5a5f3c5445f6 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -458,6 +458,7 @@ Description: Show status of f2fs superblock in real time. 0x800 SBI_QUOTA_SKIP_FLUSH skip flushing quota in current CP 0x1000 SBI_QUOTA_NEED_REPAIR quota file may be corrupted 0x2000 SBI_IS_RESIZEFS resizefs is in process + 0x4000 SBI_IS_FREEZING freefs is in process ====== ===================== ================================= What: /sys/fs/f2fs//ckpt_thread_ioprio -- cgit From e23b2f54db1dcdde8302e4ada41805c8297fac27 Mon Sep 17 00:00:00 2001 From: Jesse Taube Date: Mon, 7 Mar 2022 14:34:14 +0000 Subject: dt-bindings: mmc: sunxi: add Allwinner F1c100s compatible The Allwinner F1C100 series contains two MMC controller blocks. From comparing the data sheets, they seem to be compatible with the one used in the Allwinner A20: the register layout is the same, and they use the same separate sample and output clocks design. The only difference is the missing reset line in the A20 version, but both the binding and the Linux driver make this optional, so it's still a fit. Add the new SoC specific name and require it to be paired with the A20 fallback name, as this is all the driver needs to care about. Signed-off-by: Jesse Taube Signed-off-by: Andre Przywara Acked-by: Rob Herring Acked-by: Samuel Holland Link: https://lore.kernel.org/r/20220307143421.1106209-8-andre.przywara@arm.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml index 94e2c6c4e4b7..7803597b6366 100644 --- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml @@ -59,6 +59,9 @@ properties: - items: - const: allwinner,sun50i-h616-mmc - const: allwinner,sun50i-a100-mmc + - items: + - const: allwinner,suniv-f1c100s-mmc + - const: allwinner,sun7i-a20-mmc reg: maxItems: 1 -- cgit From 380af29b8d7670c445965bd573ab219aff0c4c11 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Google)" Date: Thu, 10 Mar 2022 21:37:09 -0500 Subject: tracing: Add snapshot at end of kernel boot up Add ftrace_boot_snapshot kernel parameter that will take a snapshot at the end of boot up just before switching over to user space (it happens during the kernel freeing of init memory). This is useful when there's interesting data that can be collected from kernel start up, but gets overridden by user space start up code. With this option, the ring buffer content from the boot up traces gets saved in the snapshot at the end of boot up. This trace can be read from: /sys/kernel/tracing/snapshot Signed-off-by: Steven Rostedt (Google) --- Documentation/admin-guide/kernel-parameters.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index f5a27f067db9..f6b7ee64ace8 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1435,6 +1435,14 @@ as early as possible in order to facilitate early boot debugging. + ftrace_boot_snapshot + [FTRACE] On boot up, a snapshot will be taken of the + ftrace ring buffer that can be read at: + /sys/kernel/tracing/snapshot. + This is useful if you need tracing information from kernel + boot up that is likely to be overridden by user space + start up functionality. + ftrace_dump_on_oops[=orig_cpu] [FTRACE] will dump the trace buffers on oops. If no parameter is passed, ftrace will dump -- cgit From ef8795f3f1cef2b2d2cd5dfab3758a7601898bc9 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Thu, 10 Mar 2022 10:05:13 -0600 Subject: dt-bindings: kbuild: Use DTB files for validation Switch the DT validation to use DTB files directly instead of a DTS to YAML conversion. The original motivation for supporting validation on DTB files was to enable running validation on a running system (e.g. 'dt-validate /sys/firmware/fdt') or other cases where the original source DTS is not available. The YAML format was not without issues. Using DTBs with the schema type information solves some of those problems. The YAML format relies on the DTS source level information including bracketing of properties, size directives, and phandle tags all of which are lost in a DTB file. While standardizing the bracketing is a good thing, it does cause a lot of extra warnings and churn to fix them. Another issue has been signed types are not validated correctly as sign information is not propagated to YAML. Using the schema type information allows for proper handling of signed types. YAML also can't represent the full range of 64-bit integers as numbers are stored as floats by most/all parsers. The DTB validation works by decoding property values using the type information in the schemas themselves. The main corner case this does not work for is matrix types where neither dimension is fixed. For now, checking the dimensions in these cases are skipped. Signed-off-by: Rob Herring Tested-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20220310160513.1708182-3-robh@kernel.org --- Documentation/devicetree/bindings/Makefile | 7 +++---- Documentation/devicetree/bindings/writing-schema.rst | 17 +++++------------ 2 files changed, 8 insertions(+), 16 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index 2716f7b9e25e..e594e5898be0 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -26,8 +26,7 @@ $(obj)/%.example.dts: $(src)/%.yaml check_dtschema_version FORCE $(call if_changed,extract_ex) find_all_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \ - -name 'processed-schema*' ! \ - -name '*.example.dt.yaml' \) + -name 'processed-schema*' \) find_cmd = $(find_all_cmd) | grep -F "$(DT_SCHEMA_FILES)" CHK_DT_DOCS := $(shell $(find_cmd)) @@ -72,9 +71,9 @@ $(obj)/processed-schema.json: $(DT_DOCS) $(src)/.yamllint check_dtschema_version always-y += processed-schema.json always-$(CHECK_DT_BINDING) += $(patsubst $(srctree)/$(src)/%.yaml,%.example.dts, $(CHK_DT_DOCS)) -always-$(CHECK_DT_BINDING) += $(patsubst $(srctree)/$(src)/%.yaml,%.example.dt.yaml, $(CHK_DT_DOCS)) +always-$(CHECK_DT_BINDING) += $(patsubst $(srctree)/$(src)/%.yaml,%.example.dtb, $(CHK_DT_DOCS)) # Hack: avoid 'Argument list too long' error for 'make clean'. Remove most of # build artifacts here before they are processed by scripts/Makefile.clean clean-files = $(shell find $(obj) \( -name '*.example.dts' -o \ - -name '*.example.dt.yaml' \) -delete 2>/dev/null) + -name '*.example.dtb' \) -delete 2>/dev/null) diff --git a/Documentation/devicetree/bindings/writing-schema.rst b/Documentation/devicetree/bindings/writing-schema.rst index 3b00fe981494..95ecf55559e5 100644 --- a/Documentation/devicetree/bindings/writing-schema.rst +++ b/Documentation/devicetree/bindings/writing-schema.rst @@ -120,20 +120,13 @@ project can be installed with pip:: pip3 install dtschema -Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be -installed. Ensure they are in your PATH (~/.local/bin by default). - -dtc must also be built with YAML output support enabled. This requires that -libyaml and its headers be installed on the host system. For some distributions -that involves installing the development package, such as: - -Debian:: +Note that 'dtschema' installation requires 'swig' and Python development files +installed first. On Debian/Ubuntu systems:: - apt-get install libyaml-dev + apt install swig python3-dev -Fedora:: - - dnf -y install libyaml-devel +Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be +installed. Ensure they are in your PATH (~/.local/bin by default). Running checks ~~~~~~~~~~~~~~ -- cgit From 571c3496e3c20444d5a2a5d4c00e608f26339505 Mon Sep 17 00:00:00 2001 From: Sinthu Raja Date: Mon, 20 Sep 2021 18:01:52 +0530 Subject: dt-bindings: hwlock: omap: Remove redundant binding example The example includes a board-specific compatible property, this is wrong as the example should be board agnostic and should represent the particular binding. Also, the file includes two similar examples but with a different compatible. So, drop the entire second example Suggested-by: Bjorn Andersson Signed-off-by: Sinthu Raja Reviewed-by: Rob Herring Acked-by: Suman Anna Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210920123152.32751-1-sinthu.raja@ti.com --- .../bindings/hwlock/ti,omap-hwspinlock.yaml | 33 +--------------------- 1 file changed, 1 insertion(+), 32 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml index ae1b37dbee75..0a955c7b9706 100644 --- a/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml +++ b/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml @@ -39,39 +39,8 @@ additionalProperties: false examples: - | - /* OMAP4 SoCs */ - hwspinlock: spinlock@4a0f6000 { + spinlock@4a0f6000 { compatible = "ti,omap4-hwspinlock"; reg = <0x4a0f6000 0x1000>; #hwlock-cells = <1>; }; - - - | - / { - /* K3 AM65x SoCs */ - model = "Texas Instruments K3 AM654 SoC"; - compatible = "ti,am654-evm", "ti,am654"; - #address-cells = <2>; - #size-cells = <2>; - - bus@100000 { - compatible = "simple-bus"; - #address-cells = <2>; - #size-cells = <2>; - ranges = <0x00 0x00100000 0x00 0x00100000 0x00 0x00020000>, /* ctrl mmr */ - <0x00 0x30800000 0x00 0x30800000 0x00 0x0bc00000>; /* Main NavSS */ - - bus@30800000 { - compatible = "simple-mfd"; - #address-cells = <2>; - #size-cells = <2>; - ranges = <0x00 0x30800000 0x00 0x30800000 0x00 0x0bc00000>; - - spinlock@30e00000 { - compatible = "ti,am654-hwspinlock"; - reg = <0x00 0x30e00000 0x00 0x1000>; - #hwlock-cells = <1>; - }; - }; - }; - }; -- cgit From 54fc9851c0e0bec8012deaa87fe540d6e1739ac2 Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Tue, 8 Mar 2022 16:05:33 +0800 Subject: dt-bindings: interrupt-controller: Add Qualcomm MPM support It adds DT binding support for Qualcomm MPM interrupt controller. Reviewed-by: Rob Herring Signed-off-by: Shawn Guo Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220308080534.3384532-2-shawn.guo@linaro.org --- .../bindings/interrupt-controller/qcom,mpm.yaml | 96 ++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml b/Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml new file mode 100644 index 000000000000..509d20c091af --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/qcom,mpm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcom MPM Interrupt Controller + +maintainers: + - Shawn Guo + +description: + Qualcomm Technologies Inc. SoCs based on the RPM architecture have a + MSM Power Manager (MPM) that is in always-on domain. In addition to managing + resources during sleep, the hardware also has an interrupt controller that + monitors the interrupts when the system is asleep, wakes up the APSS when + one of these interrupts occur and replays it to GIC interrupt controller + after GIC becomes operational. + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + items: + - const: qcom,mpm + + reg: + maxItems: 1 + description: + Specifies the base address and size of vMPM registers in RPM MSG RAM. + + interrupts: + maxItems: 1 + description: + Specify the IRQ used by RPM to wakeup APSS. + + mboxes: + maxItems: 1 + description: + Specify the mailbox used to notify RPM for writing vMPM registers. + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + description: + The first cell is the MPM pin number for the interrupt, and the second + is the trigger type. + + qcom,mpm-pin-count: + description: + Specify the total MPM pin count that a SoC supports. + $ref: /schemas/types.yaml#/definitions/uint32 + + qcom,mpm-pin-map: + description: + A set of MPM pin numbers and the corresponding GIC SPIs. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: MPM pin number + - description: GIC SPI number for the MPM pin + +required: + - compatible + - reg + - interrupts + - mboxes + - interrupt-controller + - '#interrupt-cells' + - qcom,mpm-pin-count + - qcom,mpm-pin-map + +additionalProperties: false + +examples: + - | + #include + mpm: interrupt-controller@45f01b8 { + compatible = "qcom,mpm"; + interrupts = ; + reg = <0x45f01b8 0x1000>; + mboxes = <&apcs_glb 1>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&intc>; + qcom,mpm-pin-count = <96>; + qcom,mpm-pin-map = <2 275>, + <5 296>, + <12 422>, + <24 79>, + <86 183>, + <90 260>, + <91 260>; + }; -- cgit From 22335385157d6eedb659a4cd0c801d62bfe0881d Mon Sep 17 00:00:00 2001 From: Allen-KH Cheng Date: Fri, 25 Feb 2022 21:27:46 +0800 Subject: dt-bindings: remoteproc: mediatek: Add binding for mt8186 scp Add mt8186 compatible to binding document. Signed-off-by: Allen-KH Cheng Reviewed-by: AngeloGioacchino Del Regno Acked-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220225132747.31808-2-allen-kh.cheng@mediatek.com --- Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml index d21a25ee96e6..5b693a2d049c 100644 --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml @@ -17,6 +17,7 @@ properties: compatible: enum: - mediatek,mt8183-scp + - mediatek,mt8186-scp - mediatek,mt8192-scp - mediatek,mt8195-scp -- cgit From c13b780c4597e1e6cee3154053a196aa329b1367 Mon Sep 17 00:00:00 2001 From: Suman Anna Date: Sun, 13 Feb 2022 14:12:42 -0600 Subject: remoteproc: Change rproc_shutdown() to return a status The rproc_shutdown() function is currently not returning any error code, and any failures within rproc_stop() are not passed back to the users. Change the signature to return a success value back to the callers. The remoteproc sysfs and cdev interfaces are also updated to return back this status to userspace. Signed-off-by: Suman Anna Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220213201246.25952-2-s-anna@ti.com --- Documentation/staging/remoteproc.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/staging/remoteproc.rst b/Documentation/staging/remoteproc.rst index 9cccd3dd6a4b..348ee7e508ac 100644 --- a/Documentation/staging/remoteproc.rst +++ b/Documentation/staging/remoteproc.rst @@ -49,13 +49,14 @@ might also consider using dev_archdata for this). :: - void rproc_shutdown(struct rproc *rproc) + int rproc_shutdown(struct rproc *rproc) Power off a remote processor (previously booted with rproc_boot()). In case @rproc is still being used by an additional user(s), then this function will just decrement the power refcount and exit, without really powering off the device. +Returns 0 on success, and an appropriate error value otherwise. Every call to rproc_boot() must (eventually) be accompanied by a call to rproc_shutdown(). Calling rproc_shutdown() redundantly is a bug. -- cgit From 6f22931bbf7546d7a4bac35830b2918b4642b0e3 Mon Sep 17 00:00:00 2001 From: xu xin Date: Thu, 10 Mar 2022 23:10:11 +0800 Subject: Add Chinese translation for vm/ksm.rst Translate Documentation/vm/ksm.rst into Chinese. Update Documentation/translations/zh_CN/vm/index.rst. Reviewed-by: Yang Yang Reviewed-by: Alex Shi Reviewed-by: Yanteng Si Signed-off-by: xu xin Signed-off-by: Yanteng Si Link: https://lore.kernel.org/r/ceb82d6458cd79bc3b7060199db0c3518adc3b8b.1646899056.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/index.rst | 1 + Documentation/translations/zh_CN/vm/ksm.rst | 70 +++++++++++++++++++++++++++ 2 files changed, 71 insertions(+) create mode 100644 Documentation/translations/zh_CN/vm/ksm.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index 2f9834eb9475..a1d2f0356cc1 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -26,6 +26,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） damon/index free_page_reporting highmem + ksm TODOLIST: * arch_pgtable_helpers diff --git a/Documentation/translations/zh_CN/vm/ksm.rst b/Documentation/translations/zh_CN/vm/ksm.rst new file mode 100644 index 000000000000..83b0c73984da --- /dev/null +++ b/Documentation/translations/zh_CN/vm/ksm.rst @@ -0,0 +1,70 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/vm/ksm.rst + +:翻译: + + 徐鑫 xu xin + +============ +内核同页合并 +============ + +KSM 是一种节省内存的数据去重功能，由CONFIG_KSM=y启用，并在2.6.32版本时被添加 +到Linux内核。详见 ``mm/ksm.c`` 的实现，以及http://lwn.net/Articles/306704和 +https://lwn.net/Articles/330589 + +KSM的用户空间的接口在Documentation/translations/zh_CN/admin-guide/mm/ksm.rst +文档中有描述。 + +设计 +==== + +概述 +---- + +概述内容请见mm/ksm.c文档中的“DOC: Overview” + +逆映射 +------ +KSM维护着稳定树中的KSM页的逆映射信息。 + +当KSM页面的共享数小于 ``max_page_sharing`` 的虚拟内存区域(VMAs)时，则代表了 +KSM页的稳定树其中的节点指向了一个rmap_item结构体类型的列表。同时，这个KSM页 +的 ``page->mapping`` 指向了该稳定树节点。 + +如果共享数超过了阈值，KSM将给稳定树添加第二个维度。稳定树就变成链接一个或多 +个稳定树"副本"的"链"。每个副本都保留KSM页的逆映射信息，其中 ``page->mapping`` +指向该"副本"。 + +每个链以及链接到该链中的所有"副本"强制不变的是，它们代表了相同的写保护内存 +内容，尽管任中一个"副本"是由同一片内存区的不同的KSM复制页所指向的。 + +这样一来，相比与无限的逆映射链表，稳定树的查找计算复杂性不受影响。但在稳定树 +本身中不能有重复的KSM页面内容仍然是强制要求。 + +由 ``max_page_sharing`` 强制决定的数据去重限制是必要的，以此来避免虚拟内存 +rmap链表变得过大。rmap的遍历具有O(N)的复杂度，其中N是共享页面的rmap_项（即 +虚拟映射）的数量，而这个共享页面的节点数量又被 ``max_page_sharing`` 所限制。 +因此，这有效地将线性O(N)计算复杂度从rmap遍历中分散到不同的KSM页面上。ksmd进 +程在稳定节点"链"上的遍历也是O(N)，但这个N是稳定树"副本"的数量，而不是rmap项 +的数量，因此它对ksmd性能没有显著影响。实际上，最佳稳定树"副本"的候选节点将 +保留在"副本"列表的开头。 + +``max_page_sharing`` 的值设置得高了会促使更快的内存合并（因为将有更少的稳定 +树副本排队进入稳定节点chain->hlist）和更高的数据去重系数，但代价是在交换、压 +缩、NUMA平衡和页面迁移过程中可能导致KSM页的最大rmap遍历速度较慢。 + +``stable_node_dups/stable_node_chains`` 的比值还受 ``max_page_sharing`` 调控 +的影响，高比值可能意味着稳定节点dup中存在碎片，这可以通过在ksmd中引入碎片算 +法来解决，该算法将rmap项从一个稳定节点dup重定位到另一个稳定节点dup，以便释放 +那些仅包含极少rmap项的稳定节点"dup"，但这可能会增加ksmd进程的CPU使用率，并可 +能会减慢应用程序在KSM页面上的只读计算。 + +KSM会定期扫描稳定节点"链"中链接的所有稳定树"副本"，以便删减过时了的稳定节点。 +这种扫描的频率由 ``stable_node_chains_prune_millisecs`` 这个sysfs 接口定义。 + +参考 +==== +内核代码请见mm/ksm.c。 +涉及的函数(mm_slot ksm_scan stable_node rmap_item)。 -- cgit From f0abc76d7b8c2e1229bb5fee6f6bfffc01033b18 Mon Sep 17 00:00:00 2001 From: xu xin Date: Thu, 10 Mar 2022 23:10:12 +0800 Subject: zh_CN: Add translations for admin-guide/mm/ksm.rst Translate Documentation/admin-guide/mm/ksm.rst into Chinese. Reviewed-by: Yang Yang Reviewed-by: Alex Shi Reviewed-by: Yanteng Si Signed-off-by: xu xin Signed-off-by: Yanteng Si Link: https://lore.kernel.org/r/f987a3a2cbffaad64f6e2377a5e393d9afbb099c.1646899056.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/admin-guide/mm/ksm.rst | 148 +++++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 Documentation/translations/zh_CN/admin-guide/mm/ksm.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst b/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst new file mode 100644 index 000000000000..4829156ef1ae --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst @@ -0,0 +1,148 @@ +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/ksm.rst + +:翻译: + + 徐鑫 xu xin + + +============ +内核同页合并 +============ + + +概述 +==== + +KSM是一种能节省内存的数据去重功能，由CONFIG_KSM=y启用，并在2.6.32版本时被添 +加到Linux内核。详见 ``mm/ksm.c`` 的实现，以及http://lwn.net/Articles/306704 +和https://lwn.net/Articles/330589 + +KSM最初目的是为了与KVM（即著名的内核共享内存）一起使用而开发的，通过共享虚拟机 +之间的公共数据，将更多虚拟机放入物理内存。但它对于任何会生成多个相同数据实例的 +应用程序都是很有用的。 + +KSM的守护进程ksmd会定期扫描那些已注册的用户内存区域，查找内容相同的页面，这些 +页面可以被单个写保护页面替换（如果进程以后想要更新其内容，将自动复制）。使用： +引用:`sysfs intraface ` 接口来配置KSM守护程序在单个过程中所扫描的页 +数以及两个过程之间的间隔时间。 + +KSM只合并匿名（私有）页面，从不合并页缓存（文件）页面。KSM的合并页面最初只能被 +锁定在内核内存中，但现在可以就像其他用户页面一样被换出（但当它们被交换回来时共 +享会被破坏: ksmd必须重新发现它们的身份并再次合并）。 + +以madvise控制KSM +================ + +KSM仅在特定的地址空间区域时运行，即应用程序通过使用如下所示的madvise(2)系统调 +用来请求某块地址成为可能的合并候选者的地址空间:: + + int madvise(addr, length, MADV_MERGEABLE) + +应用程序当然也可以通过调用:: + + int madvise(addr, length, MADV_UNMERGEABLE) + +来取消该请求，并恢复为非共享页面：此时KSM将去除合并在该范围内的任何合并页。注意： +这个去除合并的调用可能突然需要的内存量超过实际可用的内存量-那么可能会出现EAGAIN +失败，但更可能会唤醒OOM killer。 + +如果KSM未被配置到正在运行的内核中，则madvise MADV_MERGEABLE 和 MADV_UNMERGEABLE +的调用只会以EINVAL 失败。如果正在运行的内核是用CONFIG_KSM=y方式构建的，那么这些 +调用通常会成功：即使KSM守护程序当前没有运行，MADV_MERGEABLE 仍然会在KSM守护程序 +启动时注册范围，即使该范围不能包含KSM实际可以合并的任何页面，即使MADV_UNMERGEABLE +应用于从未标记为MADV_MERGEABLE的范围。 + +如果一块内存区域必须被拆分为至少一个新的MADV_MERGEABLE区域或MADV_UNMERGEABLE区域， +当该进程将超过 ``vm.max_map_count`` 的设定，则madvise可能返回ENOMEM。（请参阅文档 +Documentation/admin-guide/sysctl/vm.rst）。 + +与其他madvise调用一样，它们在用户地址空间的映射区域上使用：如果指定的范围包含未 +映射的间隙（尽管在中间的映射区域工作），它们将报告ENOMEM，如果没有足够的内存用于 +内部结构，则可能会因EAGAIN而失败。 + +KSM守护进程sysfs接口 +==================== + +KSM守护进程可以由``/sys/kernel/mm/ksm/`` 中的sysfs文件控制，所有人都可以读取，但 +只能由root用户写入。各接口解释如下： + + +pages_to_scan + ksmd进程进入睡眠前要扫描的页数。 + 例如， ``echo 100 > /sys/kernel/mm/ksm/pages_to_scan`` + + 默认值：100（该值被选择用于演示目的） + +sleep_millisecs + ksmd在下次扫描前应休眠多少毫秒 + 例如， ``echo 20 > /sys/kernel/mm/ksm/sleep_millisecs`` + + 默认值：20（该值被选择用于演示目的） + +merge_across_nodes + 指定是否可以合并来自不同NUMA节点的页面。当设置为0时，ksm仅合并在物理上位 + 于同一NUMA节点的内存区域中的页面。这降低了访问共享页面的延迟。在有明显的 + NUMA距离上，具有更多节点的系统可能受益于设置该值为0时的更低延迟。而对于 + 需要对内存使用量最小化的较小系统来说，设置该值为1（默认设置）则可能会受 + 益于更大共享页面。在决定使用哪种设置之前，您可能希望比较系统在每种设置下 + 的性能。 ``merge_across_nodes`` 仅当系统中没有ksm共享页面时，才能被更改设 + 置：首先将接口`run` 设置为2从而对页进行去合并，然后在修改 + ``merge_across_nodes`` 后再将‘run’又设置为1，以根据新设置来重新合并。 + + 默认值：1（如早期的发布版本一样合并跨站点） + +run + * 设置为0可停止ksmd运行，但保留合并页面， + * 设置为1可运行ksmd，例如， ``echo 1 > /sys/kernel/mm/ksm/run`` ， + * 设置为2可停止ksmd运行，并且对所有目前已合并的页进行去合并，但保留可合并 + 区域以供下次运行。 + + 默认值：0（必须设置为1才能激活KSM，除非禁用了CONFIG_SYSFS） + +use_zero_pages + 指定是否应当特殊处理空页（即那些仅含zero的已分配页）。当该值设置为1时， + 空页与内核零页合并，而不是像通常情况下那样空页自身彼此合并。这可以根据 + 工作负载的不同，在具有着色零页的架构上可以提高性能。启用此设置时应小心， + 因为它可能会降低某些工作负载的KSM性能，比如，当待合并的候选页面的校验和 + 与空页面的校验和恰好匹配的时候。此设置可随时更改，仅对那些更改后再合并 + 的页面有效。 + + 默认值：0（如同早期版本的KSM正常表现） + +max_page_sharing + 单个KSM页面允许的最大共享站点数。这将强制执行重复数据消除限制，以避免涉 + 及遍历共享KSM页面的虚拟映射的虚拟内存操作的高延迟。最小值为2，因为新创 + 建的KSM页面将至少有两个共享者。该值越高，KSM合并内存的速度越快，去重 + 因子也越高，但是对于任何给定的KSM页面，虚拟映射的最坏情况遍历的速度也会 + 越慢。减慢了这种遍历速度就意味着在交换、压缩、NUMA平衡和页面迁移期间， + 某些虚拟内存操作将有更高的延迟，从而降低这些虚拟内存操作调用者的响应能力。 + 其他任务如果不涉及执行虚拟映射遍历的VM操作，其任务调度延迟不受此参数的影 + 响，因为这些遍历本身是调度友好的。 + +stable_node_chains_prune_millisecs + 指定KSM检查特定页面的元数据的频率（即那些达到过时信息数据去重限制标准的 + 页面）单位是毫秒。较小的毫秒值将以更低的延迟来释放KSM元数据，但它们将使 + ksmd在扫描期间使用更多CPU。如果还没有一个KSM页面达到 ``max_page_sharing`` + 标准，那就没有什么用。 + +KSM与MADV_MERGEABLE的工作有效性体现于 ``/sys/kernel/mm/ksm/`` 路径下的接口： + +pages_shared + 表示多少共享页正在被使用 +pages_sharing + 表示还有多少站点正在共享这些共享页，即节省了多少 +pages_unshared + 表示有多少页是唯一的，但被反复检查以进行合并 +pages_volatile + 表示有多少页因变化太快而无法放在tree中 +full_scans + 表示所有可合并区域已扫描多少次 +stable_node_chains + 达到 ``max_page_sharing`` 限制的KSM页数 +stable_node_dups + 重复的KSM页数 + +比值 ``pages_sharing/pages_shared`` 的最大值受限制于 ``max_page_sharing`` +的设定。要想增加该比值，则相应地要增加 ``max_page_sharing`` 的值。 -- cgit From 72e1bfd1b8e9d7648ffea85eeefbc1d784182acb Mon Sep 17 00:00:00 2001 From: xu xin Date: Thu, 10 Mar 2022 23:10:13 +0800 Subject: zh_CN: Add translation for admin-guide/mm/index.rst Translate Documentation/admin-guide/mm/index.rst into Chinese. Update Documentation/admin-guide/index.rst. Reviewed-by: Yang Yang Reviewed-by: Alex Shi Reviewed-by: Yanteng Si Signed-off-by: xu xin Signed-off-by: Yanteng Si Link: https://lore.kernel.org/r/2d695dac05efc012b99fbc7525be65a421c7de03.1646899056.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/admin-guide/index.rst | 2 +- .../translations/zh_CN/admin-guide/mm/index.rst | 49 ++++++++++++++++++++++ 2 files changed, 50 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/admin-guide/mm/index.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst index 548e57f4b3f1..763055f161dd 100644 --- a/Documentation/translations/zh_CN/admin-guide/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/index.rst @@ -69,6 +69,7 @@ Todolist: lockup-watchdogs unicode sysrq + mm/index Todolist: @@ -105,7 +106,6 @@ Todolist: LSM/index md media/index - mm/index module-signing mono namespaces/index diff --git a/Documentation/translations/zh_CN/admin-guide/mm/index.rst b/Documentation/translations/zh_CN/admin-guide/mm/index.rst new file mode 100644 index 000000000000..44f66a45859d --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/index.rst @@ -0,0 +1,49 @@ +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/index.rst + +:翻译: + + 徐鑫 xu xin + + +======== +内存管理 +======== + +Linux内存管理子系统，顾名思义，是负责系统中的内存管理。它包括了虚拟内存与请求 +分页的实现，内核内部结构和用户空间程序的内存分配、将文件映射到进程地址空间以 +及许多其他很酷的事情。 + +Linux内存管理是一个具有许多可配置设置的复杂系统, 且这些设置中的大多数都可以通 +过 ``/proc`` 文件系统获得，并且可以使用 ``sysctl`` 进行查询和调整。这些API接 +口被描述在Documentation/admin-guide/sysctl/vm.rst文件和 `man 5 proc`_ 中。 + +.. _man 5 proc: http://man7.org/linux/man-pages/man5/proc.5.html + +Linux内存管理有它自己的术语，如果你还不熟悉它，请考虑阅读下面参考： +:ref:`Documentation/admin-guide/mm/concepts.rst `. + +在此目录下，我们详细描述了如何与Linux内存管理中的各种机制交互。 + +.. toctree:: + :maxdepth: 1 + + ksm + +Todolist: +* concepts +* cma_debugfs +* damon/index +* hugetlbpage +* idle_page_tracking +* memory-hotplug +* nommu-mmap +* numa_memory_policy +* numaperf +* pagemap +* soft-dirty +* swap_numa +* transhuge +* userfaultfd +* zswap -- cgit From 841fdd0ac005036972c06ebe2e456a20eea8b9da Mon Sep 17 00:00:00 2001 From: Rakesh Pillai Date: Tue, 1 Feb 2022 16:22:02 +0530 Subject: dt-bindings: remoteproc: qcom: adsp: Convert binding to YAML Convert Qualcomm ADSP/CDSP Remoteproc devicetree binding to YAML. Reviewed-by: Rob Herring Reviewed-by: Stephen Boyd Signed-off-by: Rakesh Pillai Signed-off-by: Manikanta Pubbisetty Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/1643712724-12436-2-git-send-email-quic_mpubbise@quicinc.com --- .../bindings/remoteproc/qcom,hexagon-v56.txt | 140 ------------------ .../bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml | 161 +++++++++++++++++++++ .../bindings/remoteproc/qcom,sdm845-adsp-pil.yaml | 160 ++++++++++++++++++++ 3 files changed, 321 insertions(+), 140 deletions(-) delete mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt b/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt deleted file mode 100644 index 1337a3d93d35..000000000000 --- a/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt +++ /dev/null @@ -1,140 +0,0 @@ -Qualcomm Technology Inc. Hexagon v56 Peripheral Image Loader - -This document defines the binding for a component that loads and boots firmware -on the Qualcomm Technology Inc. Hexagon v56 core. - -- compatible: - Usage: required - Value type: - Definition: must be one of: - "qcom,qcs404-cdsp-pil", - "qcom,sdm845-adsp-pil" - -- reg: - Usage: required - Value type: - Definition: must specify the base address and size of the qdsp6ss register - -- interrupts-extended: - Usage: required - Value type: - Definition: must list the watchdog, fatal IRQs ready, handover and - stop-ack IRQs - -- interrupt-names: - Usage: required - Value type: - Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack" - -- clocks: - Usage: required - Value type: - Definition: List of phandles and clock specifier pairs for the Hexagon, - per clock-names below. - -- clock-names: - Usage: required for SDM845 ADSP - Value type: - Definition: List of clock input name strings sorted in the same - order as the clocks property. Definition must have - "xo", "sway_cbcr", "lpass_ahbs_aon_cbcr", - "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", "qdsp6ss_sleep" - and "qdsp6ss_core". - -- clock-names: - Usage: required for QCS404 CDSP - Value type: - Definition: List of clock input name strings sorted in the same - order as the clocks property. Definition must have - "xo", "sway", "tbu", "bimc", "ahb_aon", "q6ss_slave", - "q6ss_master", "q6_axim". - -- power-domains: - Usage: required - Value type: - Definition: reference to cx power domain node. - -- resets: - Usage: required - Value type: - Definition: reference to the list of resets for the Hexagon. - -- reset-names: - Usage: required for SDM845 ADSP - Value type: - Definition: must be "pdc_sync" and "cc_lpass" - -- reset-names: - Usage: required for QCS404 CDSP - Value type: - Definition: must be "restart" - -- qcom,halt-regs: - Usage: required - Value type: - Definition: a phandle reference to a syscon representing TCSR followed - by the offset within syscon for Hexagon halt register. - -- memory-region: - Usage: required - Value type: - Definition: reference to the reserved-memory for the firmware - -- qcom,smem-states: - Usage: required - Value type: - Definition: reference to the smem state for requesting the Hexagon to - shut down - -- qcom,smem-state-names: - Usage: required - Value type: - Definition: must be "stop" - - -= SUBNODES -The adsp node may have an subnode named "glink-edge" that describes the -communication edge, channels and devices related to the Hexagon. -See ../soc/qcom/qcom,glink.txt for details on how to describe these. - -= EXAMPLE -The following example describes the resources needed to boot control the -ADSP, as it is found on SDM845 boards. - - remoteproc@17300000 { - compatible = "qcom,sdm845-adsp-pil"; - reg = <0x17300000 0x40c>; - - interrupts-extended = <&intc GIC_SPI 162 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; - interrupt-names = "wdog", "fatal", "ready", - "handover", "stop-ack"; - - clocks = <&rpmhcc RPMH_CXO_CLK>, - <&gcc GCC_LPASS_SWAY_CLK>, - <&lpasscc LPASS_Q6SS_AHBS_AON_CLK>, - <&lpasscc LPASS_Q6SS_AHBM_AON_CLK>, - <&lpasscc LPASS_QDSP6SS_XO_CLK>, - <&lpasscc LPASS_QDSP6SS_SLEEP_CLK>, - <&lpasscc LPASS_QDSP6SS_CORE_CLK>; - clock-names = "xo", "sway_cbcr", - "lpass_ahbs_aon_cbcr", - "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", - "qdsp6ss_sleep", "qdsp6ss_core"; - - power-domains = <&rpmhpd SDM845_CX>; - - resets = <&pdc_reset PDC_AUDIO_SYNC_RESET>, - <&aoss_reset AOSS_CC_LPASS_RESTART>; - reset-names = "pdc_sync", "cc_lpass"; - - qcom,halt-regs = <&tcsr_mutex_regs 0x22000>; - - memory-region = <&pil_adsp_mem>; - - qcom,smem-states = <&adsp_smp2p_out 0>; - qcom,smem-state-names = "stop"; - }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml new file mode 100644 index 000000000000..31413cfe10db --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml @@ -0,0 +1,161 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,qcs404-cdsp-pil.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm QCS404 CDSP Peripheral Image Loader + +maintainers: + - Bjorn Andersson + +description: + This document defines the binding for a component that loads and boots firmware + on the Qualcomm Technology Inc. CDSP (Compute DSP). + +properties: + compatible: + enum: + - qcom,qcs404-cdsp-pil + + reg: + maxItems: 1 + description: + The base address and size of the qdsp6ss register + + interrupts: + items: + - description: Watchdog interrupt + - description: Fatal interrupt + - description: Ready interrupt + - description: Handover interrupt + - description: Stop acknowledge interrupt + + interrupt-names: + items: + - const: wdog + - const: fatal + - const: ready + - const: handover + - const: stop-ack + + clocks: + items: + - description: XO clock + - description: SWAY clock + - description: TBU clock + - description: BIMC clock + - description: AHB AON clock + - description: Q6SS SLAVE clock + - description: Q6SS MASTER clock + - description: Q6 AXIM clock + + clock-names: + items: + - const: xo + - const: sway + - const: tbu + - const: bimc + - const: ahb_aon + - const: q6ss_slave + - const: q6ss_master + - const: q6_axim + + power-domains: + items: + - description: CX power domain + + resets: + items: + - description: AOSS restart + + reset-names: + items: + - const: restart + + memory-region: + maxItems: 1 + description: Reference to the reserved-memory for the Hexagon core + + qcom,halt-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Phandle reference to a syscon representing TCSR followed by the + three offsets within syscon for q6, modem and nc halt registers. + + qcom,smem-states: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: States used by the AP to signal the Hexagon core + items: + - description: Stop the modem + + qcom,smem-state-names: + $ref: /schemas/types.yaml#/definitions/string + description: The names of the state bits used for SMP2P output + items: + - const: stop + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - power-domains + - resets + - reset-names + - qcom,halt-regs + - memory-region + - qcom,smem-states + - qcom,smem-state-names + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + remoteproc@b00000 { + compatible = "qcom,qcs404-cdsp-pil"; + reg = <0x00b00000 0x4040>; + + interrupts-extended = <&intc GIC_SPI 229 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "wdog", "fatal", "ready", + "handover", "stop-ack"; + + clocks = <&xo_board>, + <&gcc GCC_CDSP_CFG_AHB_CLK>, + <&gcc GCC_CDSP_TBU_CLK>, + <&gcc GCC_BIMC_CDSP_CLK>, + <&turingcc TURING_WRAPPER_AON_CLK>, + <&turingcc TURING_Q6SS_AHBS_AON_CLK>, + <&turingcc TURING_Q6SS_AHBM_AON_CLK>, + <&turingcc TURING_Q6SS_Q6_AXIM_CLK>; + clock-names = "xo", + "sway", + "tbu", + "bimc", + "ahb_aon", + "q6ss_slave", + "q6ss_master", + "q6_axim"; + + power-domains = <&rpmhpd SDM845_CX>; + + resets = <&gcc GCC_CDSP_RESTART>; + reset-names = "restart"; + + qcom,halt-regs = <&tcsr 0x19004>; + + memory-region = <&cdsp_fw_mem>; + + qcom,smem-states = <&cdsp_smp2p_out 0>; + qcom,smem-state-names = "stop"; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml new file mode 100644 index 000000000000..1535bbbe25da --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml @@ -0,0 +1,160 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,sdm845-adsp-pil.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SDM845 ADSP Peripheral Image Loader + +maintainers: + - Bjorn Andersson + +description: + This document defines the binding for a component that loads and boots firmware + on the Qualcomm Technology Inc. ADSP. + +properties: + compatible: + enum: + - qcom,sdm845-adsp-pil + + reg: + maxItems: 1 + description: + The base address and size of the qdsp6ss register + + interrupts: + items: + - description: Watchdog interrupt + - description: Fatal interrupt + - description: Ready interrupt + - description: Handover interrupt + - description: Stop acknowledge interrupt + + interrupt-names: + items: + - const: wdog + - const: fatal + - const: ready + - const: handover + - const: stop-ack + + clocks: + items: + - description: XO clock + - description: SWAY clock + - description: LPASS AHBS AON clock + - description: LPASS AHBM AON clock + - description: QDSP XO clock + - description: Q6SP6SS SLEEP clock + - description: Q6SP6SS CORE clock + + clock-names: + items: + - const: xo + - const: sway_cbcr + - const: lpass_ahbs_aon_cbcr + - const: lpass_ahbm_aon_cbcr + - const: qdsp6ss_xo + - const: qdsp6ss_sleep + - const: qdsp6ss_core + + power-domains: + items: + - description: CX power domain + + resets: + items: + - description: PDC AUDIO SYNC RESET + - description: CC LPASS restart + + reset-names: + items: + - const: pdc_sync + - const: cc_lpass + + memory-region: + maxItems: 1 + description: Reference to the reserved-memory for the Hexagon core + + qcom,halt-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Phandle reference to a syscon representing TCSR followed by the + three offsets within syscon for q6, modem and nc halt registers. + + qcom,smem-states: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: States used by the AP to signal the Hexagon core + items: + - description: Stop the modem + + qcom,smem-state-names: + $ref: /schemas/types.yaml#/definitions/string + description: The names of the state bits used for SMP2P output + items: + - const: stop + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - power-domains + - resets + - reset-names + - qcom,halt-regs + - memory-region + - qcom,smem-states + - qcom,smem-state-names + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + #include + #include + #include + remoteproc@17300000 { + compatible = "qcom,sdm845-adsp-pil"; + reg = <0x17300000 0x40c>; + + interrupts-extended = <&intc GIC_SPI 162 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "wdog", "fatal", "ready", + "handover", "stop-ack"; + + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_LPASS_SWAY_CLK>, + <&lpasscc LPASS_Q6SS_AHBS_AON_CLK>, + <&lpasscc LPASS_Q6SS_AHBM_AON_CLK>, + <&lpasscc LPASS_QDSP6SS_XO_CLK>, + <&lpasscc LPASS_QDSP6SS_SLEEP_CLK>, + <&lpasscc LPASS_QDSP6SS_CORE_CLK>; + clock-names = "xo", "sway_cbcr", + "lpass_ahbs_aon_cbcr", + "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", + "qdsp6ss_sleep", "qdsp6ss_core"; + + power-domains = <&rpmhpd SDM845_CX>; + + resets = <&pdc_reset PDC_AUDIO_SYNC_RESET>, + <&aoss_reset AOSS_CC_LPASS_RESTART>; + reset-names = "pdc_sync", "cc_lpass"; + + qcom,halt-regs = <&tcsr_mutex_regs 0x22000>; + + memory-region = <&pil_adsp_mem>; + + qcom,smem-states = <&adsp_smp2p_out 0>; + qcom,smem-state-names = "stop"; + }; -- cgit From 2630504894e8de12295dd4dc6062fd432765dcc5 Mon Sep 17 00:00:00 2001 From: Rakesh Pillai Date: Tue, 1 Feb 2022 16:22:03 +0530 Subject: dt-bindings: remoteproc: qcom: Add SC7280 WPSS support Add WPSS PIL loading support for SC7280 SoCs. Reviewed-by: Rob Herring Reviewed-by: Stephen Boyd Signed-off-by: Rakesh Pillai Signed-off-by: Manikanta Pubbisetty Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/1643712724-12436-3-git-send-email-quic_mpubbise@quicinc.com --- .../bindings/remoteproc/qcom,sc7280-wpss-pil.yaml | 219 +++++++++++++++++++++ 1 file changed, 219 insertions(+) create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml new file mode 100644 index 000000000000..2424de733ee4 --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml @@ -0,0 +1,219 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,sc7280-wpss-pil.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SC7280 WPSS Peripheral Image Loader + +maintainers: + - Bjorn Andersson + +description: + This document defines the binding for a component that loads and boots firmware + on the Qualcomm Technology Inc. WPSS. + +properties: + compatible: + enum: + - qcom,sc7280-wpss-pil + + reg: + maxItems: 1 + description: + The base address and size of the qdsp6ss register + + interrupts: + items: + - description: Watchdog interrupt + - description: Fatal interrupt + - description: Ready interrupt + - description: Handover interrupt + - description: Stop acknowledge interrupt + - description: Shutdown acknowledge interrupt + + interrupt-names: + items: + - const: wdog + - const: fatal + - const: ready + - const: handover + - const: stop-ack + - const: shutdown-ack + + clocks: + items: + - description: GCC WPSS AHB BDG Master clock + - description: GCC WPSS AHB clock + - description: GCC WPSS RSCP clock + - description: XO clock + + clock-names: + items: + - const: ahb_bdg + - const: ahb + - const: rscp + - const: xo + + power-domains: + items: + - description: CX power domain + - description: MX power domain + + power-domain-names: + items: + - const: cx + - const: mx + + resets: + items: + - description: AOSS restart + - description: PDC SYNC + + reset-names: + items: + - const: restart + - const: pdc_sync + + memory-region: + $ref: /schemas/types.yaml#/definitions/phandle + description: Reference to the reserved-memory for the Hexagon core + + firmware-name: + $ref: /schemas/types.yaml#/definitions/string + description: + The name of the firmware which should be loaded for this remote + processor. + + qcom,halt-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Phandle reference to a syscon representing TCSR followed by the + three offsets within syscon for q6, modem and nc halt registers. + + qcom,qmp: + $ref: /schemas/types.yaml#/definitions/phandle + description: Reference to the AOSS side-channel message RAM. + + qcom,smem-states: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: States used by the AP to signal the Hexagon core + items: + - description: Stop the modem + + qcom,smem-state-names: + $ref: /schemas/types.yaml#/definitions/string + description: The names of the state bits used for SMP2P output + items: + - const: stop + + glink-edge: + type: object + description: | + Qualcomm G-Link subnode which represents communication edge, channels + and devices related to the ADSP. + + properties: + interrupts: + items: + - description: IRQ from WPSS to GLINK + + mboxes: + items: + - description: Mailbox for communication between APPS and WPSS + + label: + description: The names of the state bits used for SMP2P output + items: + - const: wpss + + qcom,remote-pid: + $ref: /schemas/types.yaml#/definitions/uint32 + description: ID of the shared memory used by GLINK for communication with WPSS + maxItems: 1 + + required: + - interrupts + - mboxes + - label + - qcom,remote-pid + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - power-domains + - power-domain-names + - resets + - reset-names + - qcom,halt-regs + - memory-region + - qcom,qmp + - qcom,smem-states + - qcom,smem-state-names + - glink-edge + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + #include + #include + #include + remoteproc@8a00000 { + compatible = "qcom,sc7280-wpss-pil"; + reg = <0x08a00000 0x10000>; + + interrupts-extended = <&intc GIC_SPI 587 IRQ_TYPE_EDGE_RISING>, + <&wpss_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&wpss_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&wpss_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&wpss_smp2p_in 3 IRQ_TYPE_EDGE_RISING>, + <&wpss_smp2p_in 7 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "wdog", "fatal", "ready", "handover", + "stop-ack", "shutdown-ack"; + + clocks = <&gcc GCC_WPSS_AHB_BDG_MST_CLK>, + <&gcc GCC_WPSS_AHB_CLK>, + <&gcc GCC_WPSS_RSCP_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "ahb_bdg", "ahb", + "rscp", "xo"; + + power-domains = <&rpmhpd SC7280_CX>, + <&rpmhpd SC7280_MX>; + power-domain-names = "cx", "mx"; + + memory-region = <&wpss_mem>; + + qcom,qmp = <&aoss_qmp>; + + qcom,smem-states = <&wpss_smp2p_out 0>; + qcom,smem-state-names = "stop"; + + resets = <&aoss_reset AOSS_CC_WCSS_RESTART>, + <&pdc_reset PDC_WPSS_SYNC_RESET>; + reset-names = "restart", "pdc_sync"; + + qcom,halt-regs = <&tcsr_mutex 0x37000>; + + glink-edge { + interrupts-extended = <&ipcc IPCC_CLIENT_WPSS + IPCC_MPROC_SIGNAL_GLINK_QMP + IRQ_TYPE_EDGE_RISING>; + mboxes = <&ipcc IPCC_CLIENT_WPSS + IPCC_MPROC_SIGNAL_GLINK_QMP>; + + label = "wpss"; + qcom,remote-pid = <13>; + }; + }; -- cgit From bad0eb76dccade4f5a601944986b3e647b7cd443 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Thu, 10 Mar 2022 23:20:48 +0800 Subject: docs/zh_CN: Refactoring the admin-guide directory index The Todolist in the html document looks a mess, now give it a nice looking format. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/d410408ec13d6e9cff97da50a13d793a428e05cf.1646899089.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/admin-guide/index.rst | 122 ++++++++++----------- 1 file changed, 61 insertions(+), 61 deletions(-) (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst index 763055f161dd..be535ffaf4b0 100644 --- a/Documentation/translations/zh_CN/admin-guide/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/index.rst @@ -20,15 +20,15 @@ Linux 内核用户和管理员指南 Todolist: - kernel-parameters - devices - sysctl/index +* kernel-parameters +* devices +* sysctl/index 本节介绍CPU漏洞及其缓解措施。 Todolist: - hw-vuln/index +* hw-vuln/index 下面的一组文档，针对的是试图跟踪问题和bug的用户。 @@ -44,18 +44,18 @@ Todolist: Todolist: - reporting-bugs - ramoops - dynamic-debug-howto - kdump/index - perf/index +* reporting-bugs +* ramoops +* dynamic-debug-howto +* kdump/index +* perf/index 这是应用程序开发人员感兴趣的章节的开始。可以在这里找到涵盖内核ABI各个 方面的文档。 Todolist: - sysfs-rules +* sysfs-rules 本手册的其余部分包括各种指南，介绍如何根据您的喜好配置内核的特定行为。 @@ -73,57 +73,57 @@ Todolist: Todolist: - acpi/index - aoe/index - auxdisplay/index - bcache - binderfs - binfmt-misc - blockdev/index - bootconfig - braille-console - btmrvl - cgroup-v1/index - cgroup-v2 - cifs/index - dell_rbu - device-mapper/index - edid - efi-stub - ext4 - nfs/index - gpio/index - highuid - hw_random - initrd - iostats - java - jfs - kernel-per-CPU-kthreads - laptops/index - lcd-panel-cgram - ldm - LSM/index - md - media/index - module-signing - mono - namespaces/index - numastat - parport - perf-security - pm/index - pnp - rapidio - ras - rtc - serial-console - svga - thunderbolt - ufs - vga-softcursor - video-output - xfs +* acpi/index +* aoe/index +* auxdisplay/index +* bcache +* binderfs +* binfmt-misc +* blockdev/index +* bootconfig +* braille-console +* btmrvl +* cgroup-v1/index +* cgroup-v2 +* cifs/index +* dell_rbu +* device-mapper/index +* edid +* efi-stub +* ext4 +* nfs/index +* gpio/index +* highuid +* hw_random +* initrd +* iostats +* java +* jfs +* kernel-per-CPU-kthreads +* laptops/index +* lcd-panel-cgram +* ldm +* LSM/index +* md +* media/index +* module-signing +* mono +* namespaces/index +* numastat +* parport +* perf-security +* pm/index +* pnp +* rapidio +* ras +* rtc +* serial-console +* svga +* thunderbolt +* ufs +* vga-softcursor +* video-output +* xfs .. only:: subproject and html -- cgit From 496cc140279b4517a23f4534e468ec9c66283f4b Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Thu, 10 Mar 2022 23:20:49 +0800 Subject: docs/zh_CN: add admin-guide damon index translation Translate .../admin-guide/mm/damon/index.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/0251f09dc926972068329b87b0563dd432849497.1646899089.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../zh_CN/admin-guide/mm/damon/index.rst | 26 ++++++++++++++++++++++ .../translations/zh_CN/admin-guide/mm/index.rst | 2 +- 2 files changed, 27 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst new file mode 100644 index 000000000000..4581e1bc2506 --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst @@ -0,0 +1,26 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/damon/index.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + +============ +监测数据访问 +============ + +:doc:`DAMON ` 允许轻量级的数据访问监测。使用DAMON， +用户可以分析他们系统的内存访问模式，并优化它们。 + +.. toctree:: + :maxdepth: 2 + +Todolist: + +* start +* usage +* reclaim diff --git a/Documentation/translations/zh_CN/admin-guide/mm/index.rst b/Documentation/translations/zh_CN/admin-guide/mm/index.rst index 44f66a45859d..702271c5b683 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/index.rst @@ -29,12 +29,12 @@ Linux内存管理有它自己的术语，如果你还不熟悉它，请考虑阅 .. toctree:: :maxdepth: 1 + damon/index ksm Todolist: * concepts * cma_debugfs -* damon/index * hugetlbpage * idle_page_tracking * memory-hotplug -- cgit From 94b140b085972eccd557f8cf5e4944e5c1486418 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Thu, 10 Mar 2022 23:20:50 +0800 Subject: docs/zh_CN: add admin-guide damon start translation Translate Documentation/admin-guide/mm/damon/start.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/e6e328be018cbf5f9105adfdad56c951acbb8c8f.1646899089.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../zh_CN/admin-guide/mm/damon/index.rst | 4 +- .../zh_CN/admin-guide/mm/damon/start.rst | 132 +++++++++++++++++++++ 2 files changed, 135 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst index 4581e1bc2506..4aa122f375e3 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst @@ -19,8 +19,10 @@ .. toctree:: :maxdepth: 2 + start + Todolist: -* start + * usage * reclaim diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst new file mode 100644 index 000000000000..67d1b49481dc --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst @@ -0,0 +1,132 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/damon/start.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + +======== +入门指南 +======== + +本文通过演示DAMON的默认用户空间工具，简要地介绍了如何使用DAMON。请注意，为了简洁 +起见，本文档只描述了它的部分功能。更多细节请参考该工具的使用文档。 +`doc `_ . + + +前提条件 +======== + +内核 +---- + +首先，你要确保你当前系统中跑的内核构建时选定了这个功能选项 ``CONFIG_DAMON_*=y``. + + +用户空间工具 +------------ + +在演示中，我们将使用DAMON的默认用户空间工具，称为DAMON Operator（DAMO）。它可以在 +https://github.com/awslabs/damo找到。下面的例子假设DAMO在你的$PATH上。当然，但 +这并不是强制性的。 + +因为DAMO使用的是DAMON的debugfs接口(详情请参考 :doc:`usage` 中的使用方法) 你应该 +确保debugfs被挂载。手动挂载它，如下所示:: + + # mount -t debugfs none /sys/kernel/debug/ + +或者在你的 ``/etc/fstab`` 文件中添加以下一行，这样你的系统就可以在启动时自动挂载 +debugfs了:: + + debugfs /sys/kernel/debug debugfs defaults 0 0 + + +记录数据访问模式 +================ + +下面的命令记录了一个程序的内存访问模式，并将监测结果保存到文件中。 :: + + $ git clone https://github.com/sjp38/masim + $ cd masim; make; ./masim ./configs/zigzag.cfg & + $ sudo damo record -o damon.data $(pidof masim) + +命令的前两行下载了一个人工内存访问生成器程序并在后台运行。生成器将重复地逐一访问两个 +100 MiB大小的内存区域。你可以用你的真实工作负载来代替它。最后一行要求 ``damo`` 将 +访问模式记录在 ``damon.data`` 文件中。 + + +将记录的模式可视化 +================== + +你可以在heatmap中直观地看到这种模式，显示哪个内存区域（X轴）何时被访问（Y轴）以及访 +问的频率（数字）。:: + + $ sudo damo report heats --heatmap stdout + 22222222222222222222222222222222222222211111111111111111111111111111111111111100 + 44444444444444444444444444444444444444434444444444444444444444444444444444443200 + 44444444444444444444444444444444444444433444444444444444444444444444444444444200 + 33333333333333333333333333333333333333344555555555555555555555555555555555555200 + 33333333333333333333333333333333333344444444444444444444444444444444444444444200 + 22222222222222222222222222222222222223355555555555555555555555555555555555555200 + 00000000000000000000000000000000000000288888888888888888888888888888888888888400 + 00000000000000000000000000000000000000288888888888888888888888888888888888888400 + 33333333333333333333333333333333333333355555555555555555555555555555555555555200 + 88888888888888888888888888888888888888600000000000000000000000000000000000000000 + 88888888888888888888888888888888888888600000000000000000000000000000000000000000 + 33333333333333333333333333333333333333444444444444444444444444444444444444443200 + 00000000000000000000000000000000000000288888888888888888888888888888888888888400 + [...] + # access_frequency: 0 1 2 3 4 5 6 7 8 9 + # x-axis: space (139728247021568-139728453431248: 196.848 MiB) + # y-axis: time (15256597248362-15326899978162: 1 m 10.303 s) + # resolution: 80x40 (2.461 MiB and 1.758 s for each character) + +你也可以直观地看到工作集的大小分布，按大小排序。:: + + $ sudo damo report wss --range 0 101 10 + # + # target_id 18446632103789443072 + # avr: 107.708 MiB + 0 0 B | | + 10 95.328 MiB |**************************** | + 20 95.332 MiB |**************************** | + 30 95.340 MiB |**************************** | + 40 95.387 MiB |**************************** | + 50 95.387 MiB |**************************** | + 60 95.398 MiB |**************************** | + 70 95.398 MiB |**************************** | + 80 95.504 MiB |**************************** | + 90 190.703 MiB |********************************************************* | + 100 196.875 MiB |***********************************************************| + +在上述命令中使用 ``--sortby`` 选项，可以显示工作集的大小是如何按时间顺序变化的。:: + + $ sudo damo report wss --range 0 101 10 --sortby time + # + # target_id 18446632103789443072 + # avr: 107.708 MiB + 0 3.051 MiB | | + 10 190.703 MiB |***********************************************************| + 20 95.336 MiB |***************************** | + 30 95.328 MiB |***************************** | + 40 95.387 MiB |***************************** | + 50 95.332 MiB |***************************** | + 60 95.320 MiB |***************************** | + 70 95.398 MiB |***************************** | + 80 95.398 MiB |***************************** | + 90 95.340 MiB |***************************** | + 100 95.398 MiB |***************************** | + + +数据访问模式感知的内存管理 +========================== + +以下三个命令使每一个大小>=4K的内存区域在你的工作负载中没有被访问>=60秒，就会被换掉。 :: + + $ echo "#min-size max-size min-acc max-acc min-age max-age action" > test_scheme + $ echo "4K max 0 0 60s max pageout" >> test_scheme + $ damo schemes -c test_scheme -- cgit From 93b51a1019471839fbd528e39550cccbe000070b Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Thu, 10 Mar 2022 23:20:51 +0800 Subject: docs/zh_CN: add damon usage translation Translate .../admin-guide/mm/damon/usage.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/431f1c2a158c61a6556f58048cb54961ab7a8790.1646899089.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../zh_CN/admin-guide/mm/damon/index.rst | 2 +- .../zh_CN/admin-guide/mm/damon/usage.rst | 286 +++++++++++++++++++++ 2 files changed, 287 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst index 4aa122f375e3..bd1f1a551f0f 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst @@ -20,9 +20,9 @@ :maxdepth: 2 start + usage Todolist: -* usage * reclaim diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst new file mode 100644 index 000000000000..5d7533347216 --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst @@ -0,0 +1,286 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/damon/usage.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + +======== +详细用法 +======== + +DAMON 为不同的用户提供了下面三种接口。 + +- *DAMON用户空间工具。* + `这 `_ 为有这特权的人， 如系统管理员，希望有一个刚好 + 可以工作的人性化界面。 + 使用它，用户可以以人性化的方式使用DAMON的主要功能。不过，它可能不会为特殊情况进行高度调整。 + 它同时支持虚拟和物理地址空间的监测。更多细节，请参考它的 `使用文档 + `_。 +- *debugfs接口。* + :ref:`这 ` 是为那些希望更高级的使用DAMON的特权用户空间程序员准备的。 + 使用它，用户可以通过读取和写入特殊的debugfs文件来使用DAMON的主要功能。因此，你可以编写和使 + 用你个性化的DAMON debugfs包装程序，代替你读/写debugfs文件。 `DAMON用户空间工具 + `_ 就是这种程序的一个例子 它同时支持虚拟和物理地址 + 空间的监测。注意，这个界面只提供简单的监测结果 :ref:`统计 `。对于详细的监测 + 结果，DAMON提供了一个:ref:`跟踪点 `。 + +- *内核空间编程接口。* + :doc:`This ` 这是为内核空间程序员准备的。使用它，用户可以通过为你编写内 + 核空间的DAMON应用程序，最灵活有效地利用DAMON的每一个功能。你甚至可以为各种地址空间扩展DAMON。 + 详细情况请参考接口 :doc:`文件 `。 + + +debugfs接口 +=========== + +DAMON导出了八个文件, ``attrs``, ``target_ids``, ``init_regions``, +``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` 和 +``rm_contexts`` under its debugfs directory, ``/damon/``. + + +属性 +---- + +用户可以通过读取和写入 ``attrs`` 文件获得和设置 ``采样间隔`` 、 ``聚集间隔`` 、 ``区域更新间隔`` +以及监测目标区域的最小/最大数量。要详细了解监测属性，请参考 `:doc:/vm/damon/design` 。例如， +下面的命令将这些值设置为5ms、100ms、1000ms、10和1000，然后再次检查:: + + # cd /damon + # echo 5000 100000 1000000 10 1000 > attrs + # cat attrs + 5000 100000 1000000 10 1000 + + +目标ID +------ + +一些类型的地址空间支持多个监测目标。例如，虚拟内存地址空间的监测可以有多个进程作为监测目标。用户 +可以通过写入目标的相关id值来设置目标，并通过读取 ``target_ids`` 文件来获得当前目标的id。在监 +测虚拟地址空间的情况下，这些值应该是监测目标进程的pid。例如，下面的命令将pid为42和4242的进程设 +为监测目标，并再次检查:: + + # cd /damon + # echo 42 4242 > target_ids + # cat target_ids + 42 4242 + +用户还可以通过在文件中写入一个特殊的关键字 "paddr\n" 来监测系统的物理内存地址空间。因为物理地 +址空间监测不支持多个目标，读取文件会显示一个假值，即 ``42`` ，如下图所示:: + + # cd /damon + # echo paddr > target_ids + # cat target_ids + 42 + +请注意，设置目标ID并不启动监测。 + + +初始监测目标区域 +---------------- + +在虚拟地址空间监测的情况下，DAMON自动设置和更新监测的目标区域，这样就可以覆盖目标进程的整个 +内存映射。然而，用户可能希望将监测区域限制在特定的地址范围内，如堆、栈或特定的文件映射区域。 +或者，一些用户可以知道他们工作负载的初始访问模式，因此希望为“自适应区域调整”设置最佳初始区域。 + +相比之下，DAMON在物理内存监测的情况下不会自动设置和更新监测目标区域。因此，用户应该自己设置 +监测目标区域。 + +在这种情况下，用户可以通过在 ``init_regions`` 文件中写入适当的值，明确地设置他们想要的初 +始监测目标区域。输入的每一行应代表一个区域，形式如下:: + + + +目标idx应该是 ``target_ids`` 文件中目标的索引，从 ``0`` 开始，区域应该按照地址顺序传递。 +例如，下面的命令将设置几个地址范围， ``1-100`` 和 ``100-200`` 作为pid 42的初始监测目标 +区域，这是 ``target_ids`` 中的第一个（索引 ``0`` ），另外几个地址范围， ``20-40`` 和 +``50-100`` 作为pid 4242的地址，这是 ``target_ids`` 中的第二个（索引 ``1`` ）:: + + # cd /damon + # cat target_ids + 42 4242 + # echo "0 1 100 + 0 100 200 + 1 20 40 + 1 50 100" > init_regions + +请注意，这只是设置了初始的监测目标区域。在虚拟内存监测的情况下，DAMON会在一个 ``区域更新间隔`` +后自动更新区域的边界。因此，在这种情况下，如果用户不希望更新的话，应该把 ``区域的更新间隔`` 设 +置得足够大。 + + +方案 +---- + +对于通常的基于DAMON的数据访问感知的内存管理优化，用户只是希望系统对特定访问模式的内存区域应用内 +存管理操作。DAMON从用户那里接收这种形式化的操作方案，并将这些方案应用到目标进程中。 + +用户可以通过读取和写入 ``scheme`` debugfs文件来获得和设置这些方案。读取该文件还可以显示每个 +方案的统计数据。在文件中，每一个方案都应该在每一行中以下列形式表示出来:: + + + +你可以通过简单地在文件中写入一个空字符串来禁用方案。 + +目标访问模式 +~~~~~~~~~~~~ + +``<目标访问模式>`` 是由三个范围构成的，形式如下:: + + min-size max-size min-acc max-acc min-age max-age + +具体来说，区域大小的字节数（ `min-size` 和 `max-size` ），访问频率的每聚合区间的监测访问次 +数（ `min-acc` 和 `max-acc` ），区域年龄的聚合区间数（ `min-age` 和 `max-age` ）都被指定。 +请注意，这些范围是封闭区间。 + +动作 +~~~~ + +```` 是一个预定义的内存管理动作的整数，DAMON将应用于具有目标访问模式的区域。支持 +的数字和它们的含义如下:: + + - 0: Call ``madvise()`` for the region with ``MADV_WILLNEED`` + - 1: Call ``madvise()`` for the region with ``MADV_COLD`` + - 2: Call ``madvise()`` for the region with ``MADV_PAGEOUT`` + - 3: Call ``madvise()`` for the region with ``MADV_HUGEPAGE`` + - 4: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE`` + - 5: Do nothing but count the statistics + +配额 +~~~~ + +每个 ``动作`` 的最佳 ``目标访问模式`` 取决于工作负载，所以不容易找到。更糟糕的是，将某个 +动作的方案设置得过于激进会导致严重的开销。为了避免这种开销，用户可以通过下面表格中的 ```` +来限制方案的时间和大小配额:: + + + +这使得DAMON在 ```` 毫秒内，尽量只用 ```` 毫秒的时间对 ``目标访 +问模式`` 的内存区域应用动作，并在 ```` 内只对最多字节的内存区域应 +用动作。将 ```` 和 ```` 都设置为零，可以禁用配额限制。 + +当预计超过配额限制时，DAMON会根据 ``目标访问模式`` 的大小、访问频率和年龄，对发现的内存 +区域进行优先排序。为了实现个性化的优先级，用户可以在 ``<优先级权重>`` 中设置这三个属性的 +权重，具体形式如下:: + + + +水位 +~~~~ + +有些方案需要根据系统特定指标的当前值来运行，如自由内存比率。对于这种情况，用户可以为该条 +件指定水位。:: + + + +```` 是一个预定义的整数，用于要检查的度量。支持的数字和它们的含义如下。 + + - 0: 忽视水位 + - 1: 系统空闲内存率 (千分比) + +每隔 ``<检查间隔>`` 微秒检查一次公制的值。 + +如果该值高于 ``<高标>`` 或低于 ``<低标>`` ，该方案被停用。如果该值低于 ``<中标>`` ， +该方案将被激活。 + +统计数据 +~~~~~~~~ + +它还统计每个方案被尝试应用的区域的总数量和字节数，每个方案被成功应用的区域的两个数量，以 +及超过配额限制的总数量。这些统计数据可用于在线分析或调整方案。 + +统计数据可以通过读取方案文件来显示。读取该文件将显示你在每一行中输入的每个 ``方案`` ， +统计的五个数字将被加在每一行的末尾。 + +例子 +~~~~ + +下面的命令应用了一个方案：”如果一个大小为[4KiB, 8KiB]的内存区域在[10, 20]的聚合时间 +间隔内显示出每一个聚合时间间隔[0, 5]的访问量，请分页出该区域。对于分页，每秒最多只能使 +用10ms，而且每秒分页不能超过1GiB。在这一限制下，首先分页出具有较长年龄的内存区域。另外， +每5秒钟检查一次系统的可用内存率，当可用内存率低于50%时开始监测和分页，但如果可用内存率 +大于60%，或低于30%，则停止监测“:: + + # cd /damon + # scheme="4096 8192 0 5 10 20 2" # target access pattern and action + # scheme+=" 10 $((1024*1024*1024)) 1000" # quotas + # scheme+=" 0 0 100" # prioritization weights + # scheme+=" 1 5000000 600 500 300" # watermarks + # echo "$scheme" > schemes + + +开关 +---- + +除非你明确地启动监测，否则如上所述的文件设置不会产生效果。你可以通过写入和读取 ``monitor_on`` +文件来启动、停止和检查监测的当前状态。写入 ``on`` 该文件可以启动对有属性的目标的监测。写入 +``off`` 该文件则停止这些目标。如果每个目标进程被终止，DAMON也会停止。下面的示例命令开启、关 +闭和检查DAMON的状态:: + + # cd /damon + # echo on > monitor_on + # echo off > monitor_on + # cat monitor_on + off + +请注意，当监测开启时，你不能写到上述的debugfs文件。如果你在DAMON运行时写到这些文件，将会返 +回一个错误代码，如 ``-EBUSY`` 。 + + +监测线程PID +----------- + +DAMON通过一个叫做kdamond的内核线程来进行请求监测。你可以通过读取 ``kdamond_pid`` 文件获 +得该线程的 ``pid`` 。当监测被 ``关闭`` 时，读取该文件不会返回任何信息:: + + # cd /damon + # cat monitor_on + off + # cat kdamond_pid + none + # echo on > monitor_on + # cat kdamond_pid + 18594 + + +使用多个监测线程 +---------------- + +每个监测上下文都会创建一个 ``kdamond`` 线程。你可以使用 ``mk_contexts`` 和 ``rm_contexts`` +文件为多个 ``kdamond`` 需要的用例创建和删除监测上下文。 + +将新上下文的名称写入 ``mk_contexts`` 文件，在 ``DAMON debugfs`` 目录上创建一个该名称的目录。 +该目录将有该上下文的 ``DAMON debugfs`` 文件:: + + # cd /damon + # ls foo + # ls: cannot access 'foo': No such file or directory + # echo foo > mk_contexts + # ls foo + # attrs init_regions kdamond_pid schemes target_ids + +如果不再需要上下文，你可以通过把上下文的名字放到 ``rm_contexts`` 文件中来删除它和相应的目录:: + + # echo foo > rm_contexts + # ls foo + # ls: cannot access 'foo': No such file or directory + +注意， ``mk_contexts`` 、 ``rm_contexts`` 和 ``monitor_on`` 文件只在根目录下。 + + +监测结果的监测点 +================ + +DAMON通过一个tracepoint ``damon:damon_aggregated`` 提供监测结果. 当监测开启时，你可 +以记录追踪点事件，并使用追踪点支持工具如perf显示结果。比如说:: + + # echo on > monitor_on + # perf record -e damon:damon_aggregated & + # sleep 5 + # kill 9 $(pidof perf) + # echo off > monitor_on + # perf script -- cgit From ffce1439fe31590fdbacf17b638f2d62efebf02d Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Thu, 10 Mar 2022 23:20:52 +0800 Subject: docs/zh_CN: add damon reclaim translation Translate .../admin-guide/mm/damon/reclaim.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/0a436fa78814bb0a7b9c2f3049e544b1e1802560.1646899089.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- .../zh_CN/admin-guide/mm/damon/index.rst | 4 +- .../zh_CN/admin-guide/mm/damon/reclaim.rst | 232 +++++++++++++++++++++ 2 files changed, 234 insertions(+), 2 deletions(-) create mode 100644 Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst index bd1f1a551f0f..0c8276109fc0 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst @@ -21,8 +21,8 @@ start usage + reclaim + -Todolist: -* reclaim diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst new file mode 100644 index 000000000000..9e541578f38d --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst @@ -0,0 +1,232 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/damon/reclaim.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + +=============== +基于DAMON的回收 +=============== + +基于DAMON的回收（DAMON_RECLAIM）是一个静态的内核模块，旨在用于轻度内存压力下的主动和轻 +量级的回收。它的目的不是取代基于LRU列表的页面回收，而是有选择地用于不同程度的内存压力和要 +求。 + +哪些地方需要主动回收？ +====================== + +在一般的内存超量使用（over-committed systems，虚拟化相关术语）的系统上，主动回收冷页 +有助于节省内存和减少延迟高峰，这些延迟是由直接回收进程或kswapd的CPU消耗引起的，同时只产 +生最小的性能下降 [1]_ [2]_ 。 + +基于空闲页报告 [3]_ 的内存过度承诺的虚拟化系统就是很好的例子。在这样的系统中，客户机 +向主机报告他们的空闲内存，而主机则将报告的内存重新分配给其他客户。因此，系统的内存得到了充 +分的利用。然而，客户可能不那么节省内存，主要是因为一些内核子系统和用户空间应用程序被设计为 +使用尽可能多的内存。然后，客户机可能只向主机报告少量的内存是空闲的，导致系统的内存利用率下降。 +在客户中运行主动回收可以缓解这个问题。 + +它是如何工作的？ +================ + +DAMON_RECLAIM找到在特定时间内没有被访问的内存区域并分页。为了避免它在分页操作中消耗过多 +的CPU，可以配置一个速度限制。在这个速度限制下，它首先分页出那些没有被访问过的内存区域。系 +统管理员还可以配置在什么情况下这个方案应该自动激活和停用三个内存压力水位。 + +接口: 模块参数 +============== + +要使用这个功能，你首先要确保你的系统运行在一个以 ``CONFIG_DAMON_RECLAIM=y`` 构建的内 +核上。 + +为了让系统管理员启用或禁用它，并为给定的系统进行调整，DAMON_RECLAIM利用了模块参数。也就 +是说，你可以把 ``damon_reclaim.=`` 放在内核启动命令行上，或者把 +适当的值写入 ``/sys/modules/damon_reclaim/parameters/`` 文件。 + +注意，除 ``启用`` 外的参数值只在DAMON_RECLAIM启动时应用。因此，如果你想在运行时应用新 +的参数值，而DAMON_RECLAIM已经被启用，你应该通过 ``启用`` 的参数文件禁用和重新启用它。 +在重新启用之前，应将新的参数值写入适当的参数值中。 + +下面是每个参数的描述。 + +enable +------ + +启用或禁用DAMON_RECLAIM。 + +你可以通过把这个参数的值设置为 ``Y`` 来启用DAMON_RCLAIM，把它设置为 ``N`` 可以禁用 +DAMON_RECLAIM。注意，由于基于水位的激活条件，DAMON_RECLAIM不能进行真正的监测和回收。 +这一点请参考下面关于水位参数的描述。 + +min_age +------- + +识别冷内存区域的时间阈值，单位是微秒。 + +如果一个内存区域在这个时间或更长的时间内没有被访问，DAMON_RECLAIM会将该区域识别为冷的， +并回收它。 + +默认为120秒。 + +quota_ms +-------- + +回收的时间限制，以毫秒为单位。 + +DAMON_RECLAIM 试图在一个时间窗口（quota_reset_interval_ms）内只使用到这个时间，以 +尝试回收冷页。这可以用来限制DAMON_RECLAIM的CPU消耗。如果该值为零，则该限制被禁用。 + +默认为10ms。 + +quota_sz +-------- + +回收的内存大小限制，单位为字节。 + +DAMON_RECLAIM 收取在一个时间窗口（quota_reset_interval_ms）内试图回收的内存量，并 +使其不超过这个限制。这可以用来限制CPU和IO的消耗。如果该值为零，则限制被禁用。 + +默认情况下是128 MiB。 + +quota_reset_interval_ms +----------------------- + +时间/大小配额收取重置间隔，单位为毫秒。 + +时间（quota_ms）和大小（quota_sz）的配额的目标重置间隔。也就是说，DAMON_RECLAIM在 +尝试回收‘不’超过quota_ms毫秒或quota_sz字节的内存。 + +默认为1秒。 + +wmarks_interval +--------------- + +当DAMON_RECLAIM被启用但由于其水位规则而不活跃时，在检查水位之前的最小等待时间。 + +wmarks_high +----------- + +高水位的可用内存率（每千字节）。 + +如果系统的可用内存（以每千字节为单位）高于这个数值，DAMON_RECLAIM就会变得不活跃，所以 +它什么也不做，只是定期检查水位。 + +wmarks_mid +---------- + +中间水位的可用内存率（每千字节）。 + +如果系统的空闲内存（以每千字节为单位）在这个和低水位线之间，DAMON_RECLAIM就会被激活， +因此开始监测和回收。 + +wmarks_low +---------- + +低水位的可用内存率（每千字节）。 + +如果系统的空闲内存（以每千字节为单位）低于这个数值，DAMON_RECLAIM就会变得不活跃，所以 +它除了定期检查水位外什么都不做。在这种情况下，系统会退回到基于LRU列表的页面粒度回收逻辑。 + +sample_interval +--------------- + +监测的采样间隔，单位是微秒。 + +DAMON用于监测冷内存的采样间隔。更多细节请参考DAMON文档 (:doc:`usage`) 。 + +aggr_interval +------------- + +监测的聚集间隔，单位是微秒。 + +DAMON对冷内存监测的聚集间隔。更多细节请参考DAMON文档 (:doc:`usage`)。 + +min_nr_regions +-------------- + +监测区域的最小数量。 + +DAMON用于冷内存监测的最小监测区域数。这可以用来设置监测质量的下限。但是，设 +置的太高可能会导致监测开销的增加。更多细节请参考DAMON文档 (:doc:`usage`) 。 + +max_nr_regions +-------------- + +监测区域的最大数量。 + +DAMON用于冷内存监测的最大监测区域数。这可以用来设置监测开销的上限值。但是， +设置得太低可能会导致监测质量不好。更多细节请参考DAMON文档 (:doc:`usage`) 。 + +monitor_region_start +-------------------- + +目标内存区域的物理地址起点。 + +DAMON_RECLAIM将对其进行工作的内存区域的起始物理地址。也就是说，DAMON_RECLAIM +将在这个区域中找到冷的内存区域并进行回收。默认情况下，该区域使用最大系统内存区。 + +monitor_region_end +------------------ + +目标内存区域的结束物理地址。 + +DAMON_RECLAIM将对其进行工作的内存区域的末端物理地址。也就是说，DAMON_RECLAIM将 +在这个区域内找到冷的内存区域并进行回收。默认情况下，该区域使用最大系统内存区。 + +kdamond_pid +----------- + +DAMON线程的PID。 + +如果DAMON_RECLAIM被启用，这将成为工作线程的PID。否则，为-1。 + +nr_reclaim_tried_regions +------------------------ + +试图通过DAMON_RECLAIM回收的内存区域的数量。 + +bytes_reclaim_tried_regions +--------------------------- + +试图通过DAMON_RECLAIM回收的内存区域的总字节数。 + +nr_reclaimed_regions +-------------------- + +通过DAMON_RECLAIM成功回收的内存区域的数量。 + +bytes_reclaimed_regions +----------------------- + +通过DAMON_RECLAIM成功回收的内存区域的总字节数。 + +nr_quota_exceeds +---------------- + +超过时间/空间配额限制的次数。 + +例子 +==== + +下面的运行示例命令使DAMON_RECLAIM找到30秒或更长时间没有访问的内存区域并“回收”？ +为了避免DAMON_RECLAIM在分页操作中消耗过多的CPU时间，回收被限制在每秒1GiB以内。 +它还要求DAMON_RECLAIM在系统的可用内存率超过50%时不做任何事情，但如果它低于40%时 +就开始真正的工作。如果DAMON_RECLAIM没有取得进展，因此空闲内存率低于20%，它会要求 +DAMON_RECLAIM再次什么都不做，这样我们就可以退回到基于LRU列表的页面粒度回收了:: + + # cd /sys/modules/damon_reclaim/parameters + # echo 30000000 > min_age + # echo $((1 * 1024 * 1024 * 1024)) > quota_sz + # echo 1000 > quota_reset_interval_ms + # echo 500 > wmarks_high + # echo 400 > wmarks_mid + # echo 200 > wmarks_low + # echo Y > enabled + +.. [1] https://research.google/pubs/pub48551/ +.. [2] https://lwn.net/Articles/787611/ +.. [3] https://www.kernel.org/doc/html/latest/vm/free_page_reporting.html -- cgit From 89ee9301ac16d848d8dccf378d6ab3266fa80f62 Mon Sep 17 00:00:00 2001 From: Vincent Whitchurch Date: Thu, 10 Mar 2022 13:42:30 +0100 Subject: docs: UML: Mention telnetd for port channel It is not obvious from the documentation that using the "port" channel for the console requires telnetd to be installed (see port_connection() in arch/um/drivers/port_user.c). Mention this, and the fact that UML will not boot until a client connects. Signed-off-by: Vincent Whitchurch Acked-by: Anton Ivanov Link: https://lore.kernel.org/r/20220310124230.3069354-1-vincent.whitchurch@axis.com Signed-off-by: Jonathan Corbet --- Documentation/virt/uml/user_mode_linux_howto_v2.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst index 2cafd3c3c6cb..d5ad96c795f6 100644 --- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst +++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst @@ -664,7 +664,11 @@ one is input, the second one output. * The fd channel - use file descriptor numbers for input/output. Example: ``con1=fd:0,fd:1.`` -* The port channel - listen on TCP port number. Example: ``con1=port:4321`` +* The port channel - start a telnet server on TCP port number. Example: + ``con1=port:4321``. The host must have /usr/sbin/in.telnetd (usually part of + a telnetd package) and the port-helper from the UML utilities (see the + information for the xterm channel below). UML will not boot until a client + connects. * The pty and pts channels - use system pty/pts. -- cgit From 09055eb060a434bdafa3904cfc92d393b9438a64 Mon Sep 17 00:00:00 2001 From: Kewei Xu Date: Mon, 7 Mar 2022 11:36:48 +0800 Subject: dt-bindings: i2c: update bindings for MT8168 SoC Add a DT binding documentation for the MT8168 soc. Signed-off-by: Kewei Xu Reviewed-by: AngeloGioacchino Del Regno Acked-by: Krzysztof Kozlowski Reviewed-by: Qii Wang Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt index 88f74a3c81ec..026985b8f61a 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt @@ -12,6 +12,7 @@ Required properties: "mediatek,mt7622-i2c": for MediaTek MT7622 "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623 "mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek MT7629 + "mediatek,mt8168-i2c": for MediaTek MT8168 "mediatek,mt8173-i2c": for MediaTek MT8173 "mediatek,mt8183-i2c": for MediaTek MT8183 "mediatek,mt8186-i2c": for MediaTek MT8186 -- cgit From 33f588f8be651b968d058b67ea5e509ed9dd4e55 Mon Sep 17 00:00:00 2001 From: Wan Jiabing Date: Fri, 4 Mar 2022 18:03:15 +0800 Subject: docs: serial: fix a reference file name in driver.rst Fix the following 'make refcheckdocs' warning: Warning: Documentation/driver-api/serial/driver.rst references a file that doesn't exist: Documentation/driver-api/serial/tty.rst Signed-off-by: Wan Jiabing Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20220304100315.6732-1-wanjiabing@vivo.com Signed-off-by: Jonathan Corbet --- Documentation/driver-api/serial/driver.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/serial/driver.rst b/Documentation/driver-api/serial/driver.rst index 31bd4e16fb1f..06ec04ba086f 100644 --- a/Documentation/driver-api/serial/driver.rst +++ b/Documentation/driver-api/serial/driver.rst @@ -311,7 +311,7 @@ hardware. This call must not sleep set_ldisc(port,termios) - Notifier for discipline change. See Documentation/driver-api/serial/tty.rst. + Notifier for discipline change. See Documentation/tty/tty_ldisc.rst. Locking: caller holds tty_port->mutex -- cgit From ff1368763bb488783820c6ba68d73c03c562a9b7 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sun, 30 Jan 2022 16:36:37 -0800 Subject: Docs: ktap: add code-block type Fix multiple "code-block::" warnings by adding "none" as the type of code-block. Mends these warnings: Documentation/dev-tools/ktap.rst:71: WARNING: Error in "code-block" directive: 1 argument(s) required, 0 supplied. Documentation/dev-tools/ktap.rst:120: WARNING: Error in "code-block" directive: 1 argument(s) required, 0 supplied. Documentation/dev-tools/ktap.rst:126: WARNING: Error in "code-block" directive: 1 argument(s) required, 0 supplied. Documentation/dev-tools/ktap.rst:132: WARNING: Error in "code-block" directive: 1 argument(s) required, 0 supplied. Documentation/dev-tools/ktap.rst:139: WARNING: Error in "code-block" directive: 1 argument(s) required, 0 supplied. Documentation/dev-tools/ktap.rst:145: WARNING: Error in "code-block" directive: 1 argument(s) required, 0 supplied. Documentation/dev-tools/ktap.rst:195: WARNING: Error in "code-block" directive: 1 argument(s) required, 0 supplied. Documentation/dev-tools/ktap.rst:208: WARNING: Error in "code-block" directive: 1 argument(s) required, 0 supplied. Documentation/dev-tools/ktap.rst:238: WARNING: Error in "code-block" directive: 1 argument(s) required, 0 supplied. Fixes: a32fa6b2e8b4 ("Documentation: dev-tools: Add KTAP specification") Signed-off-by: Randy Dunlap Cc: Rae Moar Cc: David Gow Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Reviewed-by: Frank Rowand Reviewed-by: David Gow Link: https://lore.kernel.org/r/20220131003637.14274-1-rdunlap@infradead.org Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/ktap.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/ktap.rst b/Documentation/dev-tools/ktap.rst index d7fe05de40b4..5ee735c6687f 100644 --- a/Documentation/dev-tools/ktap.rst +++ b/Documentation/dev-tools/ktap.rst @@ -68,7 +68,7 @@ Test case result lines Test case result lines indicate the final status of a test. They are required and must have the format: -.. code-block:: +.. code-block:: none [][ # [] []] @@ -117,32 +117,32 @@ separator. Example result lines include: -.. code-block:: +.. code-block:: none ok 1 test_case_name The test "test_case_name" passed. -.. code-block:: +.. code-block:: none not ok 1 test_case_name The test "test_case_name" failed. -.. code-block:: +.. code-block:: none ok 1 test # SKIP necessary dependency unavailable The test "test" was SKIPPED with the diagnostic message "necessary dependency unavailable". -.. code-block:: +.. code-block:: none not ok 1 test # TIMEOUT 30 seconds The test "test" timed out, with diagnostic data "30 seconds". -.. code-block:: +.. code-block:: none ok 5 check return code # rcode=0 @@ -202,7 +202,7 @@ allowed to be either indented or not indented. An example of a test with two nested subtests: -.. code-block:: +.. code-block:: none KTAP version 1 1..1 @@ -215,7 +215,7 @@ An example of a test with two nested subtests: An example format with multiple levels of nested testing: -.. code-block:: +.. code-block:: none KTAP version 1 1..2 @@ -250,7 +250,7 @@ nested version line, uses a line of the form Example KTAP output -------------------- -.. code-block:: +.. code-block:: none KTAP version 1 1..1 -- cgit From f8669f1d6a86a6b17104ceca9340ded280307ac1 Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Wed, 9 Mar 2022 19:49:26 -0800 Subject: nvdimm/blk: Delete the block-aperture window driver Block Aperture Window support was an attempt to layer an error model over PMEM for platforms that did not support machine-check-recovery. However, it was abandoned before it ever shipped, and only ever existed in the ACPI specification. Meanwhile Linux has carried a large pile of dead code for non-shipping infrastructure. For years it has been off to the side out of the way, but now CXL and recent directions with DAX support have the potential to collide with this code. In preparation for adding discontiguous namespace support, a pre-requisite for the nvdimm subsystem to replace device-mapper for striping + concatenation use cases, delete BLK aperture support. On the obscure chance that some hardware vendor shipped support for this mode, note that the driver will still keep BLK space reserved in the label area. So an end user in this case would still have the opportunity to report the regression to get BLK-mode support restored without risking the data they have on that device. Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/164688416668.2879318.16903178375774275120.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams --- Documentation/driver-api/nvdimm/nvdimm.rst | 406 +++++++---------------------- 1 file changed, 88 insertions(+), 318 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/nvdimm/nvdimm.rst b/Documentation/driver-api/nvdimm/nvdimm.rst index 1d8302b89bd4..7917f6471092 100644 --- a/Documentation/driver-api/nvdimm/nvdimm.rst +++ b/Documentation/driver-api/nvdimm/nvdimm.rst @@ -14,10 +14,8 @@ Version 13 Overview Supporting Documents Git Trees - LIBNVDIMM PMEM and BLK - Why BLK? - PMEM vs BLK - BLK-REGIONs, PMEM-REGIONs, Atomic Sectors, and DAX + LIBNVDIMM PMEM + PMEM-REGIONs, Atomic Sectors, and DAX Example NVDIMM Platform LIBNVDIMM Kernel Device Model and LIBNDCTL Userspace API LIBNDCTL: Context @@ -53,19 +51,12 @@ PMEM: block device composed of PMEM is capable of DAX. A PMEM address range may span an interleave of several DIMMs. -BLK: - A set of one or more programmable memory mapped apertures provided - by a DIMM to access its media. This indirection precludes the - performance benefit of interleaving, but enables DIMM-bounded failure - modes. - DPA: DIMM Physical Address, is a DIMM-relative offset. With one DIMM in the system there would be a 1:1 system-physical-address:DPA association. Once more DIMMs are added a memory controller interleave must be decoded to determine the DPA associated with a given - system-physical-address. BLK capacity always has a 1:1 relationship - with a single-DIMM's DPA range. + system-physical-address. DAX: File system extensions to bypass the page cache and block layer to @@ -84,30 +75,30 @@ BTT: Block Translation Table: Persistent memory is byte addressable. Existing software may have an expectation that the power-fail-atomicity of writes is at least one sector, 512 bytes. The BTT is an indirection - table with atomic update semantics to front a PMEM/BLK block device + table with atomic update semantics to front a PMEM block device driver and present arbitrary atomic sector sizes. LABEL: Metadata stored on a DIMM device that partitions and identifies - (persistently names) storage between PMEM and BLK. It also partitions - BLK storage to host BTTs with different parameters per BLK-partition. - Note that traditional partition tables, GPT/MBR, are layered on top of a - BLK or PMEM device. + (persistently names) capacity allocated to different PMEM namespaces. It + also indicates whether an address abstraction like a BTT is applied to + the namepsace. Note that traditional partition tables, GPT/MBR, are + layered on top of a PMEM namespace, or an address abstraction like BTT + if present, but partition support is deprecated going forward. Overview ======== -The LIBNVDIMM subsystem provides support for three types of NVDIMMs, namely, -PMEM, BLK, and NVDIMM devices that can simultaneously support both PMEM -and BLK mode access. These three modes of operation are described by -the "NVDIMM Firmware Interface Table" (NFIT) in ACPI 6. While the LIBNVDIMM -implementation is generic and supports pre-NFIT platforms, it was guided -by the superset of capabilities need to support this ACPI 6 definition -for NVDIMM resources. The bulk of the kernel implementation is in place -to handle the case where DPA accessible via PMEM is aliased with DPA -accessible via BLK. When that occurs a LABEL is needed to reserve DPA -for exclusive access via one mode a time. +The LIBNVDIMM subsystem provides support for PMEM described by platform +firmware or a device driver. On ACPI based systems the platform firmware +conveys persistent memory resource via the ACPI NFIT "NVDIMM Firmware +Interface Table" in ACPI 6. While the LIBNVDIMM subsystem implementation +is generic and supports pre-NFIT platforms, it was guided by the +superset of capabilities need to support this ACPI 6 definition for +NVDIMM resources. The original implementation supported the +block-window-aperture capability described in the NFIT, but that support +has since been abandoned and never shipped in a product. Supporting Documents -------------------- @@ -125,107 +116,38 @@ Git Trees --------- LIBNVDIMM: - https://git.kernel.org/cgit/linux/kernel/git/djbw/nvdimm.git + https://git.kernel.org/cgit/linux/kernel/git/nvdimm/nvdimm.git LIBNDCTL: https://github.com/pmem/ndctl.git -PMEM: - https://github.com/01org/prd -LIBNVDIMM PMEM and BLK -====================== +LIBNVDIMM PMEM +============== Prior to the arrival of the NFIT, non-volatile memory was described to a system in various ad-hoc ways. Usually only the bare minimum was provided, namely, a single system-physical-address range where writes are expected to be durable after a system power loss. Now, the NFIT specification standardizes not only the description of PMEM, but also -BLK and platform message-passing entry points for control and -configuration. - -For each NVDIMM access method (PMEM, BLK), LIBNVDIMM provides a block -device driver: - - 1. PMEM (nd_pmem.ko): Drives a system-physical-address range. This - range is contiguous in system memory and may be interleaved (hardware - memory controller striped) across multiple DIMMs. When interleaved the - platform may optionally provide details of which DIMMs are participating - in the interleave. - - Note that while LIBNVDIMM describes system-physical-address ranges that may - alias with BLK access as ND_NAMESPACE_PMEM ranges and those without - alias as ND_NAMESPACE_IO ranges, to the nd_pmem driver there is no - distinction. The different device-types are an implementation detail - that userspace can exploit to implement policies like "only interface - with address ranges from certain DIMMs". It is worth noting that when - aliasing is present and a DIMM lacks a label, then no block device can - be created by default as userspace needs to do at least one allocation - of DPA to the PMEM range. In contrast ND_NAMESPACE_IO ranges, once - registered, can be immediately attached to nd_pmem. - - 2. BLK (nd_blk.ko): This driver performs I/O using a set of platform - defined apertures. A set of apertures will access just one DIMM. - Multiple windows (apertures) allow multiple concurrent accesses, much like - tagged-command-queuing, and would likely be used by different threads or - different CPUs. - - The NFIT specification defines a standard format for a BLK-aperture, but - the spec also allows for vendor specific layouts, and non-NFIT BLK - implementations may have other designs for BLK I/O. For this reason - "nd_blk" calls back into platform-specific code to perform the I/O. - - One such implementation is defined in the "Driver Writer's Guide" and "DSM - Interface Example". - - -Why BLK? -======== +platform message-passing entry points for control and configuration. + +PMEM (nd_pmem.ko): Drives a system-physical-address range. This range is +contiguous in system memory and may be interleaved (hardware memory controller +striped) across multiple DIMMs. When interleaved the platform may optionally +provide details of which DIMMs are participating in the interleave. + +It is worth noting that when the labeling capability is detected (a EFI +namespace label index block is found), then no block device is created +by default as userspace needs to do at least one allocation of DPA to +the PMEM range. In contrast ND_NAMESPACE_IO ranges, once registered, +can be immediately attached to nd_pmem. This latter mode is called +label-less or "legacy". + +PMEM-REGIONs, Atomic Sectors, and DAX +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -While PMEM provides direct byte-addressable CPU-load/store access to -NVDIMM storage, it does not provide the best system RAS (recovery, -availability, and serviceability) model. An access to a corrupted -system-physical-address address causes a CPU exception while an access -to a corrupted address through an BLK-aperture causes that block window -to raise an error status in a register. The latter is more aligned with -the standard error model that host-bus-adapter attached disks present. - -Also, if an administrator ever wants to replace a memory it is easier to -service a system at DIMM module boundaries. Compare this to PMEM where -data could be interleaved in an opaque hardware specific manner across -several DIMMs. - -PMEM vs BLK ------------ - -BLK-apertures solve these RAS problems, but their presence is also the -major contributing factor to the complexity of the ND subsystem. They -complicate the implementation because PMEM and BLK alias in DPA space. -Any given DIMM's DPA-range may contribute to one or more -system-physical-address sets of interleaved DIMMs, *and* may also be -accessed in its entirety through its BLK-aperture. Accessing a DPA -through a system-physical-address while simultaneously accessing the -same DPA through a BLK-aperture has undefined results. For this reason, -DIMMs with this dual interface configuration include a DSM function to -store/retrieve a LABEL. The LABEL effectively partitions the DPA-space -into exclusive system-physical-address and BLK-aperture accessible -regions. For simplicity a DIMM is allowed a PMEM "region" per each -interleave set in which it is a member. The remaining DPA space can be -carved into an arbitrary number of BLK devices with discontiguous -extents. - -BLK-REGIONs, PMEM-REGIONs, Atomic Sectors, and DAX -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -One of the few -reasons to allow multiple BLK namespaces per REGION is so that each -BLK-namespace can be configured with a BTT with unique atomic sector -sizes. While a PMEM device can host a BTT the LABEL specification does -not provide for a sector size to be specified for a PMEM namespace. - -This is due to the expectation that the primary usage model for PMEM is -via DAX, and the BTT is incompatible with DAX. However, for the cases -where an application or filesystem still needs atomic sector update -guarantees it can register a BTT on a PMEM device or partition. See +For the cases where an application or filesystem still needs atomic sector +update guarantees it can register a BTT on a PMEM device or partition. See LIBNVDIMM/NDCTL: Block Translation Table "btt" @@ -236,51 +158,40 @@ For the remainder of this document the following diagram will be referenced for any example sysfs layouts:: - (a) (b) DIMM BLK-REGION + (a) (b) DIMM +-------------------+--------+--------+--------+ - +------+ | pm0.0 | blk2.0 | pm1.0 | blk2.1 | 0 region2 + +------+ | pm0.0 | free | pm1.0 | free | 0 | imc0 +--+- - - region0- - - +--------+ +--------+ - +--+---+ | pm0.0 | blk3.0 | pm1.0 | blk3.1 | 1 region3 + +--+---+ | pm0.0 | free | pm1.0 | free | 1 | +-------------------+--------v v--------+ +--+---+ | | | cpu0 | region1 +--+---+ | | | +----------------------------^ ^--------+ - +--+---+ | blk4.0 | pm1.0 | blk4.0 | 2 region4 + +--+---+ | free | pm1.0 | free | 2 | imc1 +--+----------------------------| +--------+ - +------+ | blk5.0 | pm1.0 | blk5.0 | 3 region5 + +------+ | free | pm1.0 | free | 3 +----------------------------+--------+--------+ In this platform we have four DIMMs and two memory controllers in one -socket. Each unique interface (BLK or PMEM) to DPA space is identified -by a region device with a dynamically assigned id (REGION0 - REGION5). +socket. Each PMEM interleave set is identified by a region device with +a dynamically assigned id. 1. The first portion of DIMM0 and DIMM1 are interleaved as REGION0. A single PMEM namespace is created in the REGION0-SPA-range that spans most of DIMM0 and DIMM1 with a user-specified name of "pm0.0". Some of that - interleaved system-physical-address range is reclaimed as BLK-aperture - accessed space starting at DPA-offset (a) into each DIMM. In that - reclaimed space we create two BLK-aperture "namespaces" from REGION2 and - REGION3 where "blk2.0" and "blk3.0" are just human readable names that - could be set to any user-desired name in the LABEL. + interleaved system-physical-address range is left free for + another PMEM namespace to be defined. 2. In the last portion of DIMM0 and DIMM1 we have an interleaved system-physical-address range, REGION1, that spans those two DIMMs as well as DIMM2 and DIMM3. Some of REGION1 is allocated to a PMEM namespace - named "pm1.0", the rest is reclaimed in 4 BLK-aperture namespaces (for - each DIMM in the interleave set), "blk2.1", "blk3.1", "blk4.0", and - "blk5.0". - - 3. The portion of DIMM2 and DIMM3 that do not participate in the REGION1 - interleaved system-physical-address range (i.e. the DPA address past - offset (b) are also included in the "blk4.0" and "blk5.0" namespaces. - Note, that this example shows that BLK-aperture namespaces don't need to - be contiguous in DPA-space. + named "pm1.0". This bus is provided by the kernel under the device /sys/devices/platform/nfit_test.0 when the nfit_test.ko module from - tools/testing/nvdimm is loaded. This not only test LIBNVDIMM but the - acpi_nfit.ko driver as well. + tools/testing/nvdimm is loaded. This module is a unit test for + LIBNVDIMM and the acpi_nfit.ko driver. LIBNVDIMM Kernel Device Model and LIBNDCTL Userspace API @@ -469,17 +380,14 @@ identified by an "nfit_handle" a 32-bit value where: LIBNVDIMM/LIBNDCTL: Region -------------------------- -A generic REGION device is registered for each PMEM range or BLK-aperture -set. Per the example there are 6 regions: 2 PMEM and 4 BLK-aperture -sets on the "nfit_test.0" bus. The primary role of regions are to be a -container of "mappings". A mapping is a tuple of . +A generic REGION device is registered for each PMEM interleave-set / +range. Per the example there are 2 PMEM regions on the "nfit_test.0" +bus. The primary role of regions are to be a container of "mappings". A +mapping is a tuple of . -LIBNVDIMM provides a built-in driver for these REGION devices. This driver -is responsible for reconciling the aliased DPA mappings across all -regions, parsing the LABEL, if present, and then emitting NAMESPACE -devices with the resolved/exclusive DPA-boundaries for the nd_pmem or -nd_blk device driver to consume. +LIBNVDIMM provides a built-in driver for REGION devices. This driver +is responsible for all parsing LABELs, if present, and then emitting NAMESPACE +devices for the nd_pmem driver to consume. In addition to the generic attributes of "mapping"s, "interleave_ways" and "size" the REGION device also exports some convenience attributes. @@ -493,8 +401,6 @@ LIBNVDIMM: region:: struct nd_region *nvdimm_pmem_region_create(struct nvdimm_bus *nvdimm_bus, struct nd_region_desc *ndr_desc); - struct nd_region *nvdimm_blk_region_create(struct nvdimm_bus *nvdimm_bus, - struct nd_region_desc *ndr_desc); :: @@ -527,8 +433,9 @@ LIBNDCTL: region enumeration example ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sample region retrieval routines based on NFIT-unique data like -"spa_index" (interleave set id) for PMEM and "nfit_handle" (dimm id) for -BLK:: +"spa_index" (interleave set id). + +:: static struct ndctl_region *get_pmem_region_by_spa_index(struct ndctl_bus *bus, unsigned int spa_index) @@ -544,139 +451,23 @@ BLK:: return NULL; } - static struct ndctl_region *get_blk_region_by_dimm_handle(struct ndctl_bus *bus, - unsigned int handle) - { - struct ndctl_region *region; - - ndctl_region_foreach(bus, region) { - struct ndctl_mapping *map; - - if (ndctl_region_get_type(region) != ND_DEVICE_REGION_BLOCK) - continue; - ndctl_mapping_foreach(region, map) { - struct ndctl_dimm *dimm = ndctl_mapping_get_dimm(map); - - if (ndctl_dimm_get_handle(dimm) == handle) - return region; - } - } - return NULL; - } - - -Why Not Encode the Region Type into the Region Name? ----------------------------------------------------- - -At first glance it seems since NFIT defines just PMEM and BLK interface -types that we should simply name REGION devices with something derived -from those type names. However, the ND subsystem explicitly keeps the -REGION name generic and expects userspace to always consider the -region-attributes for four reasons: - - 1. There are already more than two REGION and "namespace" types. For - PMEM there are two subtypes. As mentioned previously we have PMEM where - the constituent DIMM devices are known and anonymous PMEM. For BLK - regions the NFIT specification already anticipates vendor specific - implementations. The exact distinction of what a region contains is in - the region-attributes not the region-name or the region-devtype. - - 2. A region with zero child-namespaces is a possible configuration. For - example, the NFIT allows for a DCR to be published without a - corresponding BLK-aperture. This equates to a DIMM that can only accept - control/configuration messages, but no i/o through a descendant block - device. Again, this "type" is advertised in the attributes ('mappings' - == 0) and the name does not tell you much. - - 3. What if a third major interface type arises in the future? Outside - of vendor specific implementations, it's not difficult to envision a - third class of interface type beyond BLK and PMEM. With a generic name - for the REGION level of the device-hierarchy old userspace - implementations can still make sense of new kernel advertised - region-types. Userspace can always rely on the generic region - attributes like "mappings", "size", etc and the expected child devices - named "namespace". This generic format of the device-model hierarchy - allows the LIBNVDIMM and LIBNDCTL implementations to be more uniform and - future-proof. - - 4. There are more robust mechanisms for determining the major type of a - region than a device name. See the next section, How Do I Determine the - Major Type of a Region? - -How Do I Determine the Major Type of a Region? ----------------------------------------------- - -Outside of the blanket recommendation of "use libndctl", or simply -looking at the kernel header (/usr/include/linux/ndctl.h) to decode the -"nstype" integer attribute, here are some other options. - -1. module alias lookup -^^^^^^^^^^^^^^^^^^^^^^ - - The whole point of region/namespace device type differentiation is to - decide which block-device driver will attach to a given LIBNVDIMM namespace. - One can simply use the modalias to lookup the resulting module. It's - important to note that this method is robust in the presence of a - vendor-specific driver down the road. If a vendor-specific - implementation wants to supplant the standard nd_blk driver it can with - minimal impact to the rest of LIBNVDIMM. - - In fact, a vendor may also want to have a vendor-specific region-driver - (outside of nd_region). For example, if a vendor defined its own LABEL - format it would need its own region driver to parse that LABEL and emit - the resulting namespaces. The output from module resolution is more - accurate than a region-name or region-devtype. - -2. udev -^^^^^^^ - - The kernel "devtype" is registered in the udev database:: - - # udevadm info --path=/devices/platform/nfit_test.0/ndbus0/region0 - P: /devices/platform/nfit_test.0/ndbus0/region0 - E: DEVPATH=/devices/platform/nfit_test.0/ndbus0/region0 - E: DEVTYPE=nd_pmem - E: MODALIAS=nd:t2 - E: SUBSYSTEM=nd - - # udevadm info --path=/devices/platform/nfit_test.0/ndbus0/region4 - P: /devices/platform/nfit_test.0/ndbus0/region4 - E: DEVPATH=/devices/platform/nfit_test.0/ndbus0/region4 - E: DEVTYPE=nd_blk - E: MODALIAS=nd:t3 - E: SUBSYSTEM=nd - - ...and is available as a region attribute, but keep in mind that the - "devtype" does not indicate sub-type variations and scripts should - really be understanding the other attributes. - -3. type specific attributes -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - As it currently stands a BLK-aperture region will never have a - "nfit/spa_index" attribute, but neither will a non-NFIT PMEM region. A - BLK region with a "mappings" value of 0 is, as mentioned above, a DIMM - that does not allow I/O. A PMEM region with a "mappings" value of zero - is a simple system-physical-address range. - LIBNVDIMM/LIBNDCTL: Namespace ----------------------------- -A REGION, after resolving DPA aliasing and LABEL specified boundaries, -surfaces one or more "namespace" devices. The arrival of a "namespace" -device currently triggers either the nd_blk or nd_pmem driver to load -and register a disk/block device. +A REGION, after resolving DPA aliasing and LABEL specified boundaries, surfaces +one or more "namespace" devices. The arrival of a "namespace" device currently +triggers the nd_pmem driver to load and register a disk/block device. LIBNVDIMM: namespace ^^^^^^^^^^^^^^^^^^^^ -Here is a sample layout from the three major types of NAMESPACE where -namespace0.0 represents DIMM-info-backed PMEM (note that it has a 'uuid' -attribute), namespace2.0 represents a BLK namespace (note it has a -'sector_size' attribute) that, and namespace6.0 represents an anonymous -PMEM namespace (note that has no 'uuid' attribute due to not support a -LABEL):: +Here is a sample layout from the 2 major types of NAMESPACE where namespace0.0 +represents DIMM-info-backed PMEM (note that it has a 'uuid' attribute), and +namespace1.0 represents an anonymous PMEM namespace (note that has no 'uuid' +attribute due to not support a LABEL) + +:: /sys/devices/platform/nfit_test.0/ndbus0/region0/namespace0.0 |-- alt_name @@ -691,20 +482,7 @@ LABEL):: |-- type |-- uevent `-- uuid - /sys/devices/platform/nfit_test.0/ndbus0/region2/namespace2.0 - |-- alt_name - |-- devtype - |-- dpa_extents - |-- force_raw - |-- modalias - |-- numa_node - |-- sector_size - |-- size - |-- subsystem -> ../../../../../../bus/nd - |-- type - |-- uevent - `-- uuid - /sys/devices/platform/nfit_test.1/ndbus1/region6/namespace6.0 + /sys/devices/platform/nfit_test.1/ndbus1/region1/namespace1.0 |-- block | `-- pmem0 |-- devtype @@ -786,9 +564,9 @@ Why the Term "namespace"? LIBNVDIMM/LIBNDCTL: Block Translation Table "btt" ------------------------------------------------- -A BTT (design document: https://pmem.io/2014/09/23/btt.html) is a stacked -block device driver that fronts either the whole block device or a -partition of a block device emitted by either a PMEM or BLK NAMESPACE. +A BTT (design document: https://pmem.io/2014/09/23/btt.html) is a +personality driver for a namespace that fronts entire namespace as an +'address abstraction'. LIBNVDIMM: btt layout ^^^^^^^^^^^^^^^^^^^^^ @@ -815,7 +593,9 @@ LIBNDCTL: btt creation example Similar to namespaces an idle BTT device is automatically created per region. Each time this "seed" btt device is configured and enabled a new seed is created. Creating a BTT configuration involves two steps of -finding and idle BTT and assigning it to consume a PMEM or BLK namespace:: +finding and idle BTT and assigning it to consume a namespace. + +:: static struct ndctl_btt *get_idle_btt(struct ndctl_region *region) { @@ -863,25 +643,15 @@ For the given example above, here is the view of the objects as seen by the LIBNDCTL API:: +---+ - |CTX| +---------+ +--------------+ +---------------+ - +-+-+ +-> REGION0 +---> NAMESPACE0.0 +--> PMEM8 "pm0.0" | - | | +---------+ +--------------+ +---------------+ - +-------+ | | +---------+ +--------------+ +---------------+ - | DIMM0 <-+ | +-> REGION1 +---> NAMESPACE1.0 +--> PMEM6 "pm1.0" | - +-------+ | | | +---------+ +--------------+ +---------------+ + |CTX| + +-+-+ + | + +-------+ | + | DIMM0 <-+ | +---------+ +--------------+ +---------------+ + +-------+ | | +-> REGION0 +---> NAMESPACE0.0 +--> PMEM8 "pm0.0" | | DIMM1 <-+ +-v--+ | +---------+ +--------------+ +---------------+ - +-------+ +-+BUS0+---> REGION2 +-+-> NAMESPACE2.0 +--> ND6 "blk2.0" | - | DIMM2 <-+ +----+ | +---------+ | +--------------+ +----------------------+ - +-------+ | | +-> NAMESPACE2.1 +--> ND5 "blk2.1" | BTT2 | - | DIMM3 <-+ | +--------------+ +----------------------+ - +-------+ | +---------+ +--------------+ +---------------+ - +-> REGION3 +-+-> NAMESPACE3.0 +--> ND4 "blk3.0" | - | +---------+ | +--------------+ +----------------------+ - | +-> NAMESPACE3.1 +--> ND3 "blk3.1" | BTT1 | - | +--------------+ +----------------------+ - | +---------+ +--------------+ +---------------+ - +-> REGION4 +---> NAMESPACE4.0 +--> ND2 "blk4.0" | - | +---------+ +--------------+ +---------------+ - | +---------+ +--------------+ +----------------------+ - +-> REGION5 +---> NAMESPACE5.0 +--> ND1 "blk5.0" | BTT0 | - +---------+ +--------------+ +---------------+------+ + +-------+ +-+BUS0+-| +---------+ +--------------+ +----------------------+ + | DIMM2 <-+ +----+ +-> REGION1 +---> NAMESPACE1.0 +--> PMEM6 "pm1.0" | BTT1 | + +-------+ | | +---------+ +--------------+ +---------------+------+ + | DIMM3 <-+ + +-------+ -- cgit From 7f4f25a6887c7d1381756deba882f6f6106433f6 Mon Sep 17 00:00:00 2001 From: Frank Wunderlich Date: Fri, 11 Mar 2022 22:03:52 +0100 Subject: dt-bindings: ata: ahci-platform: Convert DT bindings to yaml Create a yaml file for dtbs_check from the old txt binding. Signed-off-by: Frank Wunderlich Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220311210357.222830-2-linux@fw-web.de --- .../devicetree/bindings/ata/ahci-platform.txt | 79 --------- .../devicetree/bindings/ata/ahci-platform.yaml | 182 +++++++++++++++++++++ 2 files changed, 182 insertions(+), 79 deletions(-) delete mode 100644 Documentation/devicetree/bindings/ata/ahci-platform.txt create mode 100644 Documentation/devicetree/bindings/ata/ahci-platform.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt deleted file mode 100644 index 77091a277642..000000000000 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ /dev/null @@ -1,79 +0,0 @@ -* AHCI SATA Controller - -SATA nodes are defined to describe on-chip Serial ATA controllers. -Each SATA controller should have its own node. - -It is possible, but not required, to represent each port as a sub-node. -It allows to enable each port independently when dealing with multiple -PHYs. - -Required properties: -- compatible : compatible string, one of: - - "brcm,iproc-ahci" - - "hisilicon,hisi-ahci" - - "cavium,octeon-7130-ahci" - - "ibm,476gtr-ahci" - - "marvell,armada-380-ahci" - - "marvell,armada-3700-ahci" - - "snps,dwc-ahci" - - "snps,spear-ahci" - - "generic-ahci" -- interrupts : -- reg : - -Please note that when using "generic-ahci" you must also specify a SoC specific -compatible: - compatible = "manufacturer,soc-model-ahci", "generic-ahci"; - -Optional properties: -- dma-coherent : Present if dma operations are coherent -- clocks : a list of phandle + clock specifier pairs -- resets : a list of phandle + reset specifier pairs -- target-supply : regulator for SATA target power -- phy-supply : regulator for PHY power -- phys : reference to the SATA PHY node -- phy-names : must be "sata-phy" -- ahci-supply : regulator for AHCI controller -- ports-implemented : Mask that indicates which ports that the HBA supports - are available for software to use. Useful if PORTS_IMPL - is not programmed by the BIOS, which is true with - some embedded SOC's. - -Required properties when using sub-nodes: -- #address-cells : number of cells to encode an address -- #size-cells : number of cells representing the size of an address - -Sub-nodes required properties: -- reg : the port number -And at least one of the following properties: -- phys : reference to the SATA PHY node -- target-supply : regulator for SATA target power - -Examples: - sata@ffe08000 { - compatible = "snps,spear-ahci"; - reg = <0xffe08000 0x1000>; - interrupts = <115>; - }; - -With sub-nodes: - sata@f7e90000 { - compatible = "marvell,berlin2q-achi", "generic-ahci"; - reg = <0xe90000 0x1000>; - interrupts = ; - clocks = <&chip CLKID_SATA>; - #address-cells = <1>; - #size-cells = <0>; - - sata0: sata-port@0 { - reg = <0>; - phys = <&sata_phy 0>; - target-supply = <®_sata0>; - }; - - sata1: sata-port@1 { - reg = <1>; - phys = <&sata_phy 1>; - target-supply = <®_sata1>;; - }; - }; diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml new file mode 100644 index 000000000000..e71bfb04d7f1 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml @@ -0,0 +1,182 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/ahci-platform.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AHCI SATA Controller + +description: | + SATA nodes are defined to describe on-chip Serial ATA controllers. + Each SATA controller should have its own node. + + It is possible, but not required, to represent each port as a sub-node. + It allows to enable each port independently when dealing with multiple + PHYs. + +maintainers: + - Hans de Goede + - Jens Axboe + +select: + properties: + compatible: + contains: + enum: + - brcm,iproc-ahci + - cavium,octeon-7130-ahci + - hisilicon,hisi-ahci + - ibm,476gtr-ahci + - marvell,armada-3700-ahci + - marvell,armada-8k-ahci + - marvell,berlin2q-ahci + - snps,dwc-ahci + - snps,spear-ahci + required: + - compatible + +allOf: + - $ref: "sata-common.yaml#" + + +properties: + compatible: + oneOf: + - items: + - enum: + - brcm,iproc-ahci + - marvell,armada-8k-ahci + - marvell,berlin2-ahci + - marvell,berlin2q-ahci + - const: generic-ahci + - enum: + - cavium,octeon-7130-ahci + - hisilicon,hisi-ahci + - ibm,476gtr-ahci + - marvell,armada-3700-ahci + - snps,dwc-ahci + - snps,spear-ahci + + reg: + minItems: 1 + maxItems: 2 + + reg-names: + maxItems: 1 + + clocks: + description: + Clock IDs array as required by the controller. + minItems: 1 + maxItems: 3 + + clock-names: + description: + Names of clocks corresponding to IDs in the clock property. + minItems: 1 + maxItems: 3 + + interrupts: + maxItems: 1 + + ahci-supply: + description: + regulator for AHCI controller + + dma-coherent: true + + phy-supply: + description: + regulator for PHY power + + phys: + description: + List of all PHYs on this controller + maxItems: 1 + + phy-names: + description: + Name specifier for the PHYs + maxItems: 1 + + ports-implemented: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: | + Mask that indicates which ports that the HBA supports + are available for software to use. Useful if PORTS_IMPL + is not programmed by the BIOS, which is true with + some embedded SoCs. + maximum: 0x1f + + resets: + maxItems: 1 + + target-supply: + description: + regulator for SATA target power + +required: + - compatible + - reg + - interrupts + +patternProperties: + "^sata-port@[0-9a-f]+$": + type: object + additionalProperties: false + description: + Subnode with configuration of the Ports. + + properties: + reg: + maxItems: 1 + + phys: + maxItems: 1 + + phy-names: + maxItems: 1 + + target-supply: + description: + regulator for SATA target power + + required: + - reg + + anyOf: + - required: [ phys ] + - required: [ target-supply ] + +unevaluatedProperties: false + +examples: + - | + sata@ffe08000 { + compatible = "snps,spear-ahci"; + reg = <0xffe08000 0x1000>; + interrupts = <115>; + }; + - | + #include + #include + sata@f7e90000 { + compatible = "marvell,berlin2q-ahci", "generic-ahci"; + reg = <0xf7e90000 0x1000>; + interrupts = ; + clocks = <&chip CLKID_SATA>; + #address-cells = <1>; + #size-cells = <0>; + + sata0: sata-port@0 { + reg = <0>; + phys = <&sata_phy 0>; + target-supply = <®_sata0>; + }; + + sata1: sata-port@1 { + reg = <1>; + phys = <&sata_phy 1>; + target-supply = <®_sata1>; + }; + }; -- cgit From 3f5a539b35e45c53d6f0629b0e7312f10ad34052 Mon Sep 17 00:00:00 2001 From: Frank Wunderlich Date: Fri, 11 Mar 2022 22:03:55 +0100 Subject: dt-bindings: ata: ahci-platform: Add power-domains property Some SoC using power-domains property so add it here Signed-off-by: Frank Wunderlich Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220311210357.222830-5-linux@fw-web.de --- Documentation/devicetree/bindings/ata/ahci-platform.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml index e71bfb04d7f1..a02f6d12773e 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml +++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml @@ -108,6 +108,9 @@ properties: some embedded SoCs. maximum: 0x1f + power-domains: + maxItems: 1 + resets: maxItems: 1 -- cgit From 593adaa6459903728cb59392239f2c615b8dadbb Mon Sep 17 00:00:00 2001 From: Frank Wunderlich Date: Fri, 11 Mar 2022 22:03:56 +0100 Subject: dt-bindings: ata: ahci-platform: Add rk3568-dwc-ahci compatible Add SoC specific compatible for rk3568 ahci controller Signed-off-by: Frank Wunderlich Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220311210357.222830-6-linux@fw-web.de --- Documentation/devicetree/bindings/ata/ahci-platform.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml index a02f6d12773e..c146ab8e14e5 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml +++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml @@ -49,6 +49,10 @@ properties: - marvell,berlin2-ahci - marvell,berlin2q-ahci - const: generic-ahci + - items: + - enum: + - rockchip,rk3568-dwc-ahci + - const: snps,dwc-ahci - enum: - cavium,octeon-7130-ahci - hisilicon,hisi-ahci -- cgit From 00d5d031d3283e2b01d1f3a48fd3ca4c927107c5 Mon Sep 17 00:00:00 2001 From: Martin Povišer Date: Tue, 8 Feb 2022 19:34:09 +0100 Subject: dt-bindings: clock: Add Apple NCO MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The NCO block found on Apple SoCs is a programmable clock generator performing fractional division of a high frequency input clock. Reviewed-by: Mark Kettenis Reviewed-by: Rob Herring Signed-off-by: Martin Povišer Link: https://lore.kernel.org/r/20220208183411.61090-2-povik+lin@cutebit.org Signed-off-by: Stephen Boyd --- .../devicetree/bindings/clock/apple,nco.yaml | 62 ++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/apple,nco.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/apple,nco.yaml b/Documentation/devicetree/bindings/clock/apple,nco.yaml new file mode 100644 index 000000000000..74eab5c0d24a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/apple,nco.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/apple,nco.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple SoCs' NCO block + +maintainers: + - Martin Povišer + +description: | + The NCO (Numerically Controlled Oscillator) block found on Apple SoCs + such as the t8103 (M1) is a programmable clock generator performing + fractional division of a high frequency input clock. + + It carries a number of independent channels and is typically used for + generation of audio bitclocks. + +properties: + compatible: + items: + - enum: + - apple,t6000-nco + - apple,t8103-nco + - const: apple,nco + + clocks: + description: + Specifies the reference clock from which the output clocks + are derived through fractional division. + maxItems: 1 + + '#clock-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - '#clock-cells' + - reg + +additionalProperties: false + +examples: + - | + nco_clkref: clock-ref { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <900000000>; + clock-output-names = "nco-ref"; + }; + + nco: clock-controller@23b044000 { + compatible = "apple,t8103-nco", "apple,nco"; + reg = <0x3b044000 0x14000>; + #clock-cells = <1>; + clocks = <&nco_clkref>; + }; -- cgit From d76231e460fbaba7115212bf55f1eab35aba6223 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 9 Mar 2022 14:59:01 +0100 Subject: media: xc2028: rename the driver from tuner-xc2028 This is the only tuner driver that has "tuner-" on its name. Rename it, in order to match all the other tuner drivers. Signed-off-by: Mauro Carvalho Chehab --- Documentation/admin-guide/media/i2c-cardlist.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/media/i2c-cardlist.rst b/Documentation/admin-guide/media/i2c-cardlist.rst index db17f39b56cf..ef3b5fff3b01 100644 --- a/Documentation/admin-guide/media/i2c-cardlist.rst +++ b/Documentation/admin-guide/media/i2c-cardlist.rst @@ -284,7 +284,7 @@ tda9887 TDA 9885/6/7 analog IF demodulator tea5761 TEA 5761 radio tuner tea5767 TEA 5767 radio tuner tua9001 Infineon TUA9001 silicon tuner -tuner-xc2028 XCeive xc2028/xc3028 tuners +xc2028 XCeive xc2028/xc3028 tuners xc4000 Xceive XC4000 silicon tuner xc5000 Xceive XC5000 silicon tuner ============ ================================================== -- cgit From bcc8d70f912df5b3ad315155bcc0208b699d24d2 Mon Sep 17 00:00:00 2001 From: Adam Skladowski Date: Mon, 7 Mar 2022 20:17:22 +0100 Subject: dt-bindings: mailbox: Add compatible for the MSM8976 Add the mailbox compatible for the MSM8976 SoC. Signed-off-by: Adam Skladowski Acked-by: Krzysztof Kozlowski Signed-off-by: Jassi Brar --- Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 01e9d9155c83..3b5ba7ecc19d 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -21,6 +21,7 @@ properties: - qcom,msm8916-apcs-kpss-global - qcom,msm8939-apcs-kpss-global - qcom,msm8953-apcs-kpss-global + - qcom,msm8976-apcs-kpss-global - qcom,msm8994-apcs-kpss-global - qcom,msm8996-apcs-hmss-global - qcom,msm8998-apcs-hmss-global -- cgit From afa092e1e8824363d3174fef329c034445c111d5 Mon Sep 17 00:00:00 2001 From: Allen-KH Cheng Date: Fri, 25 Feb 2022 21:24:26 +0800 Subject: dt-bindings: mailbox: mtk,adsp-mbox: add mtk adsp-mbox document This patch adds document for mediatek adsp mbox Signed-off-by: Allen-KH Cheng Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Rob Herring Signed-off-by: Jassi Brar --- .../devicetree/bindings/mailbox/mtk,adsp-mbox.yaml | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml new file mode 100644 index 000000000000..fe454a1fba17 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/mtk,adsp-mbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek ADSP mailbox + +maintainers: + - Allen-KH Cheng + +description: | + The MTK ADSP mailbox Inter-Processor Communication (IPC) enables the SoC + to ommunicate with ADSP by passing messages through two mailbox channels. + The MTK ADSP mailbox IPC also provides the ability for one processor to + signal the other processor using interrupts. + +properties: + compatible: + items: + - const: mediatek,mt8195-adsp-mbox + + "#mbox-cells": + const: 0 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - "#mbox-cells" + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include + #include + + adsp_mailbox0:mailbox@10816000 { + compatible = "mediatek,mt8195-adsp-mbox"; + #mbox-cells = <0>; + reg = <0x10816000 0x1000>; + interrupts = ; + }; -- cgit From 960dcc1574c7432ad4ff42e8b153f098bdfd5c8d Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Mon, 7 Feb 2022 09:52:09 +0800 Subject: dt-bindings: mailbox: imx-mu: add i.MX8 SECO MU support Similar to i.MX8QM/QXP SCU, i.MX8 SECO MU is dedicated for communication between SECO and Cortex-A cores from hardware design, it could not be reused for other purpose. To use SECO MU more effectivly, add "fsl,imx8-mu-seco" compatile to support fast IPC. Acked-by: Rob Herring Signed-off-by: Peng Fan Signed-off-by: Jassi Brar --- Documentation/devicetree/bindings/mailbox/fsl,mu.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml index a337bcd80c4a..f865b806ae6a 100644 --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml @@ -28,6 +28,7 @@ properties: - const: fsl,imx7ulp-mu - const: fsl,imx8ulp-mu - const: fsl,imx8-mu-scu + - const: fsl,imx8-mu-seco - const: fsl,imx8ulp-mu-s4 - items: - enum: -- cgit From 6149a543adc7d7113dd47fc05eda973eefee5bf4 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Wed, 9 Mar 2022 18:03:41 +0800 Subject: dt-bindings: mailbox: imx-mu: add i.MX93 MU Add bindings for i.MX93 MU which derived from i.MX8ULP Reviewed-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Peng Fan Signed-off-by: Jassi Brar --- Documentation/devicetree/bindings/mailbox/fsl,mu.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml index f865b806ae6a..6d056d5e16bf 100644 --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml @@ -30,6 +30,9 @@ properties: - const: fsl,imx8-mu-scu - const: fsl,imx8-mu-seco - const: fsl,imx8ulp-mu-s4 + - items: + - const: fsl,imx93-mu + - const: fsl,imx8ulp-mu - items: - enum: - fsl,imx7s-mu -- cgit From 241aba6c1ebd2c326a371b8af84b1f096efd0506 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Wed, 9 Mar 2022 18:03:42 +0800 Subject: dt-bindings: mailbox: imx-mu: add i.MX93 S4 MU support Similar to i.MX8ULP S4 MU, i.MX93 MU is dedicated for communication between Sentinel and Cortex-A cores from hardware design, it could not be reused for other purpose. However i.MX93 S4 MU use separate tx/rx interrupt, so update interrupts and add interrupt-names property. Reviewed-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Peng Fan Signed-off-by: Jassi Brar --- .../devicetree/bindings/mailbox/fsl,mu.yaml | 31 +++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml index 6d056d5e16bf..7a86e7926dd2 100644 --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml @@ -29,6 +29,7 @@ properties: - const: fsl,imx8ulp-mu - const: fsl,imx8-mu-scu - const: fsl,imx8-mu-seco + - const: fsl,imx93-mu-s4 - const: fsl,imx8ulp-mu-s4 - items: - const: fsl,imx93-mu @@ -55,7 +56,14 @@ properties: maxItems: 1 interrupts: - maxItems: 1 + minItems: 1 + maxItems: 2 + + interrupt-names: + minItems: 1 + items: + - const: tx + - const: rx "#mbox-cells": description: | @@ -90,6 +98,27 @@ required: - interrupts - "#mbox-cells" +allOf: + - if: + properties: + compatible: + enum: + - fsl,imx93-mu-s4 + then: + properties: + interrupt-names: + minItems: 2 + interrupts: + minItems: 2 + + else: + properties: + interrupts: + maxItems: 1 + not: + required: + - interrupt-names + additionalProperties: false examples: -- cgit From 1b0d0f7c12d57763fe27200d0569c863f11d2b8a Mon Sep 17 00:00:00 2001 From: Rex-BC Chen Date: Wed, 23 Feb 2022 11:01:37 +0800 Subject: dt-bindings: mailbox: add definition for mt8186 Add definition of compatible and dt-binding header for mt8186. Signed-off-by: Rex-BC Chen Signed-off-by: Jassi Brar --- Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index 98fe37e8b17b..c2aeba63bd47 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -10,7 +10,8 @@ mailbox.txt for generic information about mailbox device-tree bindings. Required properties: - compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce", - "mediatek,mt8192-gce", "mediatek,mt8195-gce" or "mediatek,mt6779-gce". + "mediatek,mt8186-gce", "mediatek,mt8192-gce", "mediatek,mt8195-gce" or + "mediatek,mt6779-gce". - reg: Address range of the GCE unit - interrupts: The interrupt signal from the GCE block - clock: Clocks according to the common clock binding @@ -40,8 +41,9 @@ Optional properties for a client mutex node: defined in 'dt-bindings/gce/-gce.h'. Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h', -'dt-bindings/gce/mt8183-gce.h', 'dt-bindings/gce/mt8192-gce.h', -'dt-bindings/gce/mt8195-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. +'dt-bindings/gce/mt8183-gce.h', 'dt-bindings/gce/mt8186-gce.h' +'dt-bindings/gce/mt8192-gce.h', 'dt-bindings/gce/mt8195-gce.h' or +'dt-bindings/gce/mt6779-gce.h'. Such as sub-system ids, thread priority, event ids. Example: -- cgit From 688b0d8536e0e937f608a93cb6909e14389a0c45 Mon Sep 17 00:00:00 2001 From: lianzhi chang Date: Thu, 10 Mar 2022 09:44:15 +0800 Subject: doc: fixed a typo in ext4 documentation The unit of file system size should be TiB, not PiB Signed-off-by: lianzhi chang Link: https://lore.kernel.org/r/20220310014415.29937-1-changlianzhi@uniontech.com Signed-off-by: Theodore Ts'o --- Documentation/filesystems/ext4/blocks.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/ext4/blocks.rst b/Documentation/filesystems/ext4/blocks.rst index bd722ecd92d6..b0f80ea87c90 100644 --- a/Documentation/filesystems/ext4/blocks.rst +++ b/Documentation/filesystems/ext4/blocks.rst @@ -39,7 +39,7 @@ For 32-bit filesystems, limits are as follows: - 4TiB - 8TiB - 16TiB - - 256PiB + - 256TiB * - Blocks Per Block Group - 8,192 - 16,384 -- cgit From e8c07082a810fbb9db303a2b66b66b8d7e588b53 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Tue, 8 Mar 2022 22:56:14 +0100 Subject: Kbuild: move to -std=gnu11 During a patch discussion, Linus brought up the option of changing the C standard version from gnu89 to gnu99, which allows using variable declaration inside of a for() loop. While the C99, C11 and later standards introduce many other features, most of these are already available in gnu89 as GNU extensions as well. An earlier attempt to do this when gcc-5 started defaulting to -std=gnu11 failed because at the time that caused warnings about designated initializers with older compilers. Now that gcc-5.1 is the minimum compiler version used for building kernels, that is no longer a concern. Similarly, the behavior of 'inline' functions changes between gnu89 using gnu_inline behavior and gnu11 using standard c99+ behavior, but this was taken care of by defining 'inline' to include __attribute__((gnu_inline)) in order to allow building with clang a while ago. Nathan Chancellor reported a new -Wdeclaration-after-statement warning that appears in a system header on arm, this still needs a workaround. The differences between gnu99, gnu11, gnu1x and gnu17 are fairly minimal and mainly impact warnings at the -Wpedantic level that the kernel never enables. Between these, gnu11 is the newest version that is supported by all supported compiler versions, though it is only the default on gcc-5, while all other supported versions of gcc or clang default to gnu1x/gnu17. Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ Link: https://github.com/ClangBuiltLinux/linux/issues/1603 Suggested-by: Linus Torvalds Acked-by: Marco Elver Acked-by: Jani Nikula Acked-by: David Sterba Tested-by: Sedat Dilek Reviewed-by: Alex Shi Reviewed-by: Nick Desaulniers Reviewed-by: Miguel Ojeda Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Signed-off-by: Masahiro Yamada --- Documentation/process/programming-language.rst | 6 +++--- Documentation/translations/it_IT/process/programming-language.rst | 4 ++-- Documentation/translations/zh_CN/process/programming-language.rst | 3 +-- Documentation/translations/zh_TW/process/programming-language.rst | 3 +-- 4 files changed, 7 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/programming-language.rst b/Documentation/process/programming-language.rst index ec474a70a02f..5fc9160ca1fa 100644 --- a/Documentation/process/programming-language.rst +++ b/Documentation/process/programming-language.rst @@ -5,9 +5,9 @@ Programming Language The kernel is written in the C programming language [c-language]_. More precisely, the kernel is typically compiled with ``gcc`` [gcc]_ -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90 -(including some C99 features). ``clang`` [clang]_ is also supported, see -docs on :ref:`Building Linux with Clang/LLVM `. +under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11. +``clang`` [clang]_ is also supported, see docs on +:ref:`Building Linux with Clang/LLVM `. This dialect contains many extensions to the language [gnu-extensions]_, and many of them are used within the kernel as a matter of course. diff --git a/Documentation/translations/it_IT/process/programming-language.rst b/Documentation/translations/it_IT/process/programming-language.rst index 41db2598ce11..c1a9b481a6f9 100644 --- a/Documentation/translations/it_IT/process/programming-language.rst +++ b/Documentation/translations/it_IT/process/programming-language.rst @@ -10,8 +10,8 @@ Linguaggio di programmazione Il kernel è scritto nel linguaggio di programmazione C [it-c-language]_. Più precisamente, il kernel viene compilato con ``gcc`` [it-gcc]_ usando -l'opzione ``-std=gnu89`` [it-gcc-c-dialect-options]_: il dialetto GNU -dello standard ISO C90 (con l'aggiunta di alcune funzionalità da C99). +l'opzione ``-std=gnu11`` [it-gcc-c-dialect-options]_: il dialetto GNU +dello standard ISO C11. Linux supporta anche ``clang`` [it-clang]_, leggete la documentazione :ref:`Building Linux with Clang/LLVM `. diff --git a/Documentation/translations/zh_CN/process/programming-language.rst b/Documentation/translations/zh_CN/process/programming-language.rst index 2a47a1d2ec20..fabdc338dbfb 100644 --- a/Documentation/translations/zh_CN/process/programming-language.rst +++ b/Documentation/translations/zh_CN/process/programming-language.rst @@ -9,8 +9,7 @@ ============ 内核是用C语言 :ref:`c-language ` 编写的。更准确地说，内核通常是用 :ref:`gcc ` -在 ``-std=gnu89`` :ref:`gcc-c-dialect-options ` 下编译的：ISO C90的 GNU 方言（ -包括一些C99特性） +在 ``-std=gnu11`` :ref:`gcc-c-dialect-options ` 下编译的：ISO C11的 GNU 方言 这种方言包含对语言 :ref:`gnu-extensions ` 的许多扩展，当然，它们许多都在内核中使用。 diff --git a/Documentation/translations/zh_TW/process/programming-language.rst b/Documentation/translations/zh_TW/process/programming-language.rst index 54e3699eadf8..144bdaf81a41 100644 --- a/Documentation/translations/zh_TW/process/programming-language.rst +++ b/Documentation/translations/zh_TW/process/programming-language.rst @@ -12,8 +12,7 @@ ============ 內核是用C語言 :ref:`c-language ` 編寫的。更準確地說，內核通常是用 :ref:`gcc ` -在 ``-std=gnu89`` :ref:`gcc-c-dialect-options ` 下編譯的：ISO C90的 GNU 方言（ -包括一些C99特性） +在 ``-std=gnu11`` :ref:`gcc-c-dialect-options ` 下編譯的：ISO C11的 GNU 方言 這種方言包含對語言 :ref:`gnu-extensions ` 的許多擴展，當然，它們許多都在內核中使用。 -- cgit From 910f42bfe96783fc633196bd975731a420c7a066 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 11 Mar 2022 17:48:01 -0600 Subject: ASoC: dt-bindings: Fix patternProperties with fixed strings The simple-audio-card and renesas,rsnd bindings used 'patternProperties' with fixed strings to work-around a dtschema meta-schema limitation. This is now fixed and the schemas can be fixed to use 'properties' instead. Signed-off-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220311234802.417610-1-robh@kernel.org Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/renesas,rsnd.yaml | 16 ++++----- .../devicetree/bindings/sound/simple-card.yaml | 42 +++++++++++----------- 2 files changed, 28 insertions(+), 30 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index c2930d65728e..e17c0245f77a 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -123,9 +123,7 @@ properties: $ref: audio-graph-port.yaml# unevaluatedProperties: false -# use patternProperties to avoid naming "xxx,yyy" issue -patternProperties: - "^rcar_sound,dvc$": + rcar_sound,dvc: description: DVC subnode. type: object patternProperties: @@ -141,7 +139,7 @@ patternProperties: - dma-names additionalProperties: false - "^rcar_sound,mix$": + rcar_sound,mix: description: MIX subnode. type: object patternProperties: @@ -150,7 +148,7 @@ patternProperties: # no properties additionalProperties: false - "^rcar_sound,ctu$": + rcar_sound,ctu: description: CTU subnode. type: object patternProperties: @@ -159,7 +157,7 @@ patternProperties: # no properties additionalProperties: false - "^rcar_sound,src$": + rcar_sound,src: description: SRC subnode. type: object patternProperties: @@ -182,7 +180,7 @@ patternProperties: - dma-names additionalProperties: false - "^rcar_sound,ssiu$": + rcar_sound,ssiu: description: SSIU subnode. type: object patternProperties: @@ -202,7 +200,7 @@ patternProperties: - dma-names additionalProperties: false - "^rcar_sound,ssi$": + rcar_sound,ssi: description: SSI subnode. type: object patternProperties: @@ -239,7 +237,7 @@ patternProperties: additionalProperties: false # For DAI base - "^rcar_sound,dai$": + rcar_sound,dai: description: DAI subnode. type: object patternProperties: diff --git a/Documentation/devicetree/bindings/sound/simple-card.yaml b/Documentation/devicetree/bindings/sound/simple-card.yaml index 00597dc4f396..b261d49b9ddb 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.yaml +++ b/Documentation/devicetree/bindings/sound/simple-card.yaml @@ -167,45 +167,45 @@ properties: description: User specified audio sound card name. $ref: /schemas/types.yaml#/definitions/string -# use patternProperties to avoid naming "xxx,yyy" issue -patternProperties: - "^simple-audio-card,widgets$": + simple-audio-card,widgets: $ref: "#/definitions/widgets" - "^simple-audio-card,routing$": + simple-audio-card,routing: $ref: "#/definitions/routing" - "^simple-audio-card,cpu(@[0-9a-f]+)?": - $ref: "#/definitions/dai" - "^simple-audio-card,codec(@[0-9a-f]+)?": - $ref: "#/definitions/dai" # common properties - "^simple-audio-card,frame-master$": + simple-audio-card,frame-master: $ref: "#/definitions/frame-master" - "^simple-audio-card,bitclock-master$": + simple-audio-card,bitclock-master: $ref: "#/definitions/bitclock-master" - "^simple-audio-card,frame-inversion$": + simple-audio-card,frame-inversion: $ref: "#/definitions/frame-inversion" - "^simple-audio-card,bitclock-inversion$": + simple-audio-card,bitclock-inversion: $ref: "#/definitions/bitclock-inversion" - "^simple-audio-card,format$": + simple-audio-card,format: $ref: "#/definitions/format" - "^simple-audio-card,mclk-fs$": + simple-audio-card,mclk-fs: $ref: "#/definitions/mclk-fs" - "^simple-audio-card,aux-devs$": + simple-audio-card,aux-devs: $ref: "#/definitions/aux-devs" - "^simple-audio-card,convert-rate$": + simple-audio-card,convert-rate: $ref: "#/definitions/convert-rate" - "^simple-audio-card,convert-channels$": + simple-audio-card,convert-channels: $ref: "#/definitions/convert-channels" - "^simple-audio-card,prefix$": + simple-audio-card,prefix: $ref: "#/definitions/prefix" - "^simple-audio-card,pin-switches$": + simple-audio-card,pin-switches: $ref: "#/definitions/pin-switches" - "^simple-audio-card,hp-det-gpio$": + simple-audio-card,hp-det-gpio: maxItems: 1 - "^simple-audio-card,mic-det-gpio$": + simple-audio-card,mic-det-gpio: maxItems: 1 +patternProperties: + "^simple-audio-card,cpu(@[0-9a-f]+)?$": + $ref: "#/definitions/dai" + "^simple-audio-card,codec(@[0-9a-f]+)?$": + $ref: "#/definitions/dai" + "^simple-audio-card,dai-link(@[0-9a-f]+)?$": description: | Container for dai-link level properties and the CPU and CODEC sub-nodes. -- cgit From c553f22e0531f41bbf6fd0a06e98110c71f66bdf Mon Sep 17 00:00:00 2001 From: Ioana Ciornei Date: Fri, 11 Mar 2022 23:22:22 +0200 Subject: dt-bindings: phy: add bindings for Lynx 28G PHY Add device tree binding for the Lynx 28G SerDes PHY driver used on Layerscape based SoCs. Signed-off-by: Ioana Ciornei Reviewed-by: Krzysztof Kozlowski Signed-off-by: David S. Miller --- .../devicetree/bindings/phy/fsl,lynx-28g.yaml | 40 ++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml b/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml new file mode 100644 index 000000000000..4d91e2f4f247 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/fsl,lynx-28g.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Lynx 28G SerDes PHY binding + +maintainers: + - Ioana Ciornei + +properties: + compatible: + enum: + - fsl,lynx-28g + + reg: + maxItems: 1 + + "#phy-cells": + const: 1 + +required: + - compatible + - reg + - "#phy-cells" + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + serdes_1: phy@1ea0000 { + compatible = "fsl,lynx-28g"; + reg = <0x0 0x1ea0000 0x0 0x1e30>; + #phy-cells = <1>; + }; + }; -- cgit From d9a16830e10eafde6f0bce91047bb869c44425ab Mon Sep 17 00:00:00 2001 From: Rafał Miłecki Date: Wed, 16 Feb 2022 11:41:35 +0100 Subject: dt-bindings: mtd: partitions: convert BCM47xx to the json-schema MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This helps validating DTS files. Signed-off-by: Rafał Miłecki Reviewed-by: Rob Herring Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220216104135.31307-1-zajec5@gmail.com --- .../partitions/brcm,bcm947xx-cfe-partitions.txt | 42 ------------------- .../partitions/brcm,bcm947xx-cfe-partitions.yaml | 48 ++++++++++++++++++++++ 2 files changed, 48 insertions(+), 42 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.txt create mode 100644 Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.txt b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.txt deleted file mode 100644 index 1d61a029395e..000000000000 --- a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.txt +++ /dev/null @@ -1,42 +0,0 @@ -Broadcom BCM47xx Partitions -=========================== - -Broadcom is one of hardware manufacturers providing SoCs (BCM47xx) used in -home routers. Their BCM947xx boards using CFE bootloader have several partitions -without any on-flash partition table. On some devices their sizes and/or -meanings can also vary so fixed partitioning can't be used. - -Discovering partitions on these devices is possible thanks to having a special -header and/or magic signature at the beginning of each of them. They are also -block aligned which is important for determinig a size. - -Most of partitions use ASCII text based magic for determining a type. More -complex partitions (like TRX with its HDR0 magic) may include extra header -containing some details, including a length. - -A list of supported partitions includes: -1) Bootloader with Broadcom's CFE (Common Firmware Environment) -2) NVRAM with configuration/calibration data -3) Device manufacturer's data with some default values (e.g. SSIDs) -4) TRX firmware container which can hold up to 4 subpartitions -5) Backup TRX firmware used after failed upgrade - -As mentioned earlier, role of some partitions may depend on extra configuration. -For example both: main firmware and backup firmware use the same TRX format with -the same header. To distinguish currently used firmware a CFE's environment -variable "bootpartition" is used. - - -Devices using Broadcom partitions described above should should have flash node -with a subnode named "partitions" using following properties: - -Required properties: -- compatible : (required) must be "brcm,bcm947xx-cfe-partitions" - -Example: - -flash@0 { - partitions { - compatible = "brcm,bcm947xx-cfe-partitions"; - }; -}; diff --git a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.yaml new file mode 100644 index 000000000000..3484e06d6bcb --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/brcm,bcm947xx-cfe-partitions.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM47xx Partitions + +description: | + Broadcom is one of hardware manufacturers providing SoCs (BCM47xx) used in + home routers. Their BCM947xx boards using CFE bootloader have several + partitions without any on-flash partition table. On some devices their sizes + and/or meanings can also vary so fixed partitioning can't be used. + + Discovering partitions on these devices is possible thanks to having a special + header and/or magic signature at the beginning of each of them. They are also + block aligned which is important for determinig a size. + + Most of partitions use ASCII text based magic for determining a type. More + complex partitions (like TRX with its HDR0 magic) may include extra header + containing some details, including a length. + + A list of supported partitions includes: + 1) Bootloader with Broadcom's CFE (Common Firmware Environment) + 2) NVRAM with configuration/calibration data + 3) Device manufacturer's data with some default values (e.g. SSIDs) + 4) TRX firmware container which can hold up to 4 subpartitions + 5) Backup TRX firmware used after failed upgrade + + As mentioned earlier, role of some partitions may depend on extra + configuration. For example both: main firmware and backup firmware use the + same TRX format with the same header. To distinguish currently used firmware a + CFE's environment variable "bootpartition" is used. + +maintainers: + - Rafał Miłecki + +properties: + compatible: + const: brcm,bcm947xx-cfe-partitions + +additionalProperties: false + +examples: + - | + partitions { + compatible = "brcm,bcm947xx-cfe-partitions"; + }; -- cgit From 2e7e80f7e7e9dbbb3c2a85ee923ca32826052816 Mon Sep 17 00:00:00 2001 From: "Matthew Wilcox (Oracle)" Date: Wed, 9 Feb 2022 20:21:27 +0000 Subject: fs: Convert is_partially_uptodate to folios Since the uptodate property is maintained on a per-folio basis, the is_partially_uptodate method should also take a folio. Fix the types at the same time so it's clear that it returns true/false and takes the count in bytes, not blocks. Signed-off-by: Matthew Wilcox (Oracle) Tested-by: Damien Le Moal Acked-by: Damien Le Moal Tested-by: Mike Marshall # orangefs Tested-by: David Howells # afs --- Documentation/filesystems/locking.rst | 2 +- Documentation/filesystems/vfs.rst | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 3f9b1497ebb8..88b33524687f 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -258,7 +258,7 @@ prototypes:: int (*migratepage)(struct address_space *, struct page *, struct page *); void (*putback_page) (struct page *); int (*launder_page)(struct page *); - int (*is_partially_uptodate)(struct page *, unsigned long, unsigned long); + bool (*is_partially_uptodate)(struct folio *, size_t from, size_t count); int (*error_remove_page)(struct address_space *, struct page *); int (*swap_activate)(struct file *); int (*swap_deactivate)(struct file *); diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index bf5c48066fac..da3e7b470f0a 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -747,8 +747,8 @@ cache in your filesystem. The following members are defined: void (*putback_page) (struct page *); int (*launder_page) (struct page *); - int (*is_partially_uptodate) (struct page *, unsigned long, - unsigned long); + bool (*is_partially_uptodate) (struct folio *, size_t from, + size_t count); void (*is_dirty_writeback) (struct page *, bool *, bool *); int (*error_remove_page) (struct mapping *mapping, struct page *page); int (*swap_activate)(struct file *); @@ -937,9 +937,9 @@ cache in your filesystem. The following members are defined: ``is_partially_uptodate`` Called by the VM when reading a file through the pagecache when - the underlying blocksize != pagesize. If the required block is - up to date then the read can complete without needing the IO to - bring the whole page up to date. + the underlying blocksize is smaller than the size of the folio. + If the required block is up to date then the read can complete + without needing I/O to bring the whole page up to date. ``is_dirty_writeback`` Called by the VM when attempting to reclaim a page. The VM uses -- cgit From 338e953f1bd1a0ef4c86b5ab44735e1f6519d721 Mon Sep 17 00:00:00 2001 From: Guodong Liu Date: Wed, 16 Feb 2022 11:21:22 +0800 Subject: dt-bindings: pinctrl: mt8186: add pinctrl file and binding document 1. This patch adds pinctrl file for mt8186. 2. This patch adds mt8186 compatible node in binding document. Signed-off-by: Guodong Liu Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220216032124.28067-2-guodong.liu@mediatek.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/pinctrl-mt8186.yaml | 297 +++++++++++++++++++++ 1 file changed, 297 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml new file mode 100644 index 000000000000..8a2bb8608291 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml @@ -0,0 +1,297 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/pinctrl-mt8186.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT8186 Pin Controller + +maintainers: + - Sean Wang + +description: | + The Mediatek's Pin controller is used to control SoC pins. + +properties: + compatible: + const: mediatek,mt8186-pinctrl + + gpio-controller: true + + '#gpio-cells': + description: | + Number of cells in GPIO specifier. Since the generic GPIO binding is used, + the amount of cells must be specified as 2. See the below + mentioned gpio binding representation for description of particular cells. + const: 2 + + gpio-ranges: + maxItems: 1 + + reg: + description: | + Physical address base for gpio base registers. There are 8 different GPIO + physical address base in mt8186. + maxItems: 8 + + reg-names: + description: | + Gpio base register names. + items: + - const: iocfg0 + - const: iocfg_bm + - const: iocfg_bl + - const: iocfg_br + - const: iocfg_lm + - const: iocfg_rb + - const: iocfg_tl + - const: eint + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + interrupts: + description: The interrupt outputs to sysirq + maxItems: 1 + + mediatek,rsel-resistance-in-si-unit: + type: boolean + description: | + Identifying i2c pins pull up/down type which is RSEL. It can support + RSEL define or si unit value(ohm) to set different resistance. + +# PIN CONFIGURATION NODES +patternProperties: + '-pins$': + type: object + additionalProperties: false + patternProperties: + '^pins': + type: object + additionalProperties: false + description: | + A pinctrl node should contain at least one subnodes representing the + pinctrl groups available on the machine. Each subnode will list the + pins it needs, and how they should be configured, with regard to muxer + configuration, pullups, drive strength, input enable/disable and + input schmitt. + An example of using macro: + pincontroller { + /* GPIO0 set as multifunction GPIO0 */ + gpio-pins { + pins { + pinmux = ; + } + }; + /* GPIO128 set as multifunction SDA0 */ + i2c0-pins { + pins { + pinmux = ; + } + }; + }; + $ref: "pinmux-node.yaml" + + properties: + pinmux: + description: | + Integer array, represents gpio pin number and mux setting. + Supported pin number and mux varies for different SoCs, and are + defined as macros in dt-bindings/pinctrl/-pinfunc.h + directly. + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + + mediatek,drive-strength-adv: + description: | + Describe the specific driving setup property. + For I2C pins, the existing generic driving setup can only support + 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they + can support 0.125/0.25/0.5/1mA adjustment. If we enable specific + driving setup, the existing generic setup will be disabled. + The specific driving setup is controlled by E1E0EN. + When E1=0/E0=0, the strength is 0.125mA. + When E1=0/E0=1, the strength is 0.25mA. + When E1=1/E0=0, the strength is 0.5mA. + When E1=1/E0=1, the strength is 1mA. + EN is used to enable or disable the specific driving setup. + Valid arguments are described as below: + 0: (E1, E0, EN) = (0, 0, 0) + 1: (E1, E0, EN) = (0, 0, 1) + 2: (E1, E0, EN) = (0, 1, 0) + 3: (E1, E0, EN) = (0, 1, 1) + 4: (E1, E0, EN) = (1, 0, 0) + 5: (E1, E0, EN) = (1, 0, 1) + 6: (E1, E0, EN) = (1, 1, 0) + 7: (E1, E0, EN) = (1, 1, 1) + So the valid arguments are from 0 to 7. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + bias-pull-down: + oneOf: + - type: boolean + - enum: [100, 101, 102, 103] + description: mt8186 pull down PUPD/R0/R1 type define value. + - enum: [200, 201, 202, 203] + description: mt8186 pull down RSEL type define value. + - enum: [75000, 5000] + description: mt8186 pull down RSEL type si unit value(ohm). + description: | + For pull down type is normal, it don't need add RSEL & R1R0 define + and resistance value. + For pull down type is PUPD/R0/R1 type, it can add R1R0 define to + set different resistance. It can support "MTK_PUPD_SET_R1R0_00" & + "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" & + "MTK_PUPD_SET_R1R0_11" define in mt8186. + For pull down type is RSEL, it can add RSEL define & resistance + value(ohm) to set different resistance by identifying property + "mediatek,rsel-resistance-in-si-unit". + It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" + & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" + define in mt8186. It can also support resistance value(ohm) + "75000" & "5000" in mt8186. + An example of using RSEL define: + pincontroller { + i2c0_pin { + pins { + pinmux = ; + bias-pull-down = ; + } + }; + }; + An example of using si unit resistance value(ohm): + &pio { + mediatek,rsel-resistance-in-si-unit; + } + pincontroller { + i2c0_pin { + pins { + pinmux = ; + bias-pull-down = <75000>; + } + }; + }; + + bias-pull-up: + oneOf: + - type: boolean + - enum: [100, 101, 102, 103] + description: mt8186 pull up PUPD/R0/R1 type define value. + - enum: [200, 201, 202, 203] + description: mt8186 pull up RSEL type define value. + - enum: [1000, 5000, 10000, 75000] + description: mt8186 pull up RSEL type si unit value(ohm). + description: | + For pull up type is normal, it don't need add RSEL & R1R0 define + and resistance value. + For pull up type is PUPD/R0/R1 type, it can add R1R0 define to + set different resistance. It can support "MTK_PUPD_SET_R1R0_00" & + "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" & + "MTK_PUPD_SET_R1R0_11" define in mt8186. + For pull up type is RSEL, it can add RSEL define & resistance + value(ohm) to set different resistance by identifying property + "mediatek,rsel-resistance-in-si-unit". + It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" + & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" + define in mt8186. It can also support resistance value(ohm) + "1000" & "5000" & "10000" & "75000" in mt8186. + An example of using si unit resistance value(ohm): + &pio { + mediatek,rsel-resistance-in-si-unit; + } + pincontroller { + i2c0-pins { + pins { + pinmux = ; + bias-pull-up = <1000>; + } + }; + }; + + bias-disable: true + + output-high: true + + output-low: true + + input-enable: true + + input-disable: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + required: + - pinmux + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - '#interrupt-cells' + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include + #include + + pio: pinctrl@10005000 { + compatible = "mediatek,mt8186-pinctrl"; + reg = <0x10005000 0x1000>, + <0x10002000 0x0200>, + <0x10002200 0x0200>, + <0x10002400 0x0200>, + <0x10002600 0x0200>, + <0x10002A00 0x0200>, + <0x10002c00 0x0200>, + <0x1000b000 0x1000>; + reg-names = "iocfg0", "iocfg_bm", "iocfg_bl", + "iocfg_br", "iocfg_lm", "iocfg_rb", + "iocfg_tl", "eint"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pio 0 0 185>; + interrupt-controller; + interrupts = ; + #interrupt-cells = <2>; + + pio-pins { + pins { + pinmux = ; + output-low; + }; + }; + + spi0-pins { + pins-spi { + pinmux = , + , + ; + bias-disable; + }; + pins-spi-mi { + pinmux = ; + bias-pull-down; + }; + }; + + i2c0-pins { + pins { + pinmux = , + ; + bias-pull-up = ; + mediatek,drive-strength-adv = <7>; + }; + }; + }; -- cgit From 4ad8b50da86341aab5bb13f278fb6fd3f627fed9 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Mon, 28 Feb 2022 09:01:02 +0800 Subject: dt-bindings: pinctrl: imx93: Add pinctrl binding Add pinctrl binding doc for i.MX93 Signed-off-by: Peng Fan Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220228010103.2725893-1-peng.fan@oss.nxp.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/fsl,imx93-pinctrl.yaml | 85 ++++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml new file mode 100644 index 000000000000..66baa6082a4f --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/fsl,imx93-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale IMX93 IOMUX Controller + +maintainers: + - Peng Fan + +description: + Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory + for common binding part and usage. + +allOf: + - $ref: "pinctrl.yaml#" + +properties: + compatible: + const: fsl,imx93-iomuxc + + reg: + maxItems: 1 + +# Client device subnode's properties +patternProperties: + 'grp$': + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + + properties: + fsl,pins: + description: + each entry consists of 6 integers and represents the mux and config + setting for one pin. The first 5 integers are specified using a PIN_FUNC_ID macro, which can + be found in . The last + integer CONFIG is the pad setting value like pull-up on this pin. Please + refer to i.MX8M Plus Reference Manual for detailed CONFIG settings. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "mux_reg" indicates the offset of mux register. + - description: | + "conf_reg" indicates the offset of pad configuration register. + - description: | + "input_reg" indicates the offset of select input register. + - description: | + "mux_val" indicates the mux value to be applied. + - description: | + "input_val" indicates the select input value to be applied. + - description: | + "pad_setting" indicates the pad configuration value to be applied. + + + required: + - fsl,pins + + additionalProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + # Pinmux controller node + - | + iomuxc: pinctrl@443c0000 { + compatible = "fsl,imx93-iomuxc"; + reg = <0x30330000 0x10000>; + + pinctrl_uart3: uart3grp { + fsl,pins = + <0x48 0x1f8 0x41c 0x1 0x0 0x49>, + <0x4c 0x1fc 0x418 0x1 0x0 0x49>; + }; + }; + +... -- cgit From 1a1e33b3b57d3051cbbaa1efc885c611c0e68ea9 Mon Sep 17 00:00:00 2001 From: Jonathan Neuschäfer Date: Sat, 29 Jan 2022 12:52:23 +0100 Subject: dt-bindings: pinctrl: Add Nuvoton WPCM450 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This binding is heavily based on the one for NPCM7xx, because the hardware is similar. There are some notable differences, however: - The addresses of GPIO banks are not physical addresses but simple indices (0 to 7), because the GPIO registers are not laid out in convenient blocks. - Pinmux settings can explicitly specify that the GPIO mode is used. Certain pins support blink patterns in hardware. This is currently not modelled in the DT binding. Signed-off-by: Jonathan Neuschäfer Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220129115228.2257310-5-j.neuschaefer@gmx.net Signed-off-by: Linus Walleij --- .../bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml | 160 +++++++++++++++++++++ 1 file changed, 160 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml new file mode 100644 index 000000000000..47a56b83a610 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml @@ -0,0 +1,160 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/nuvoton,wpcm450-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton WPCM450 pin control and GPIO + +maintainers: + - Jonathan Neuschäfer + +properties: + compatible: + const: nuvoton,wpcm450-pinctrl + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + # There are three kinds of subnodes: + # 1. a GPIO controller node for each GPIO bank + # 2. a pinmux node configures pin muxing for a group of pins (e.g. rmii2) + # 3. a pinconf node configures properties of a single pin + + "^gpio@[0-7]$": + type: object + + description: + Eight GPIO banks (gpio@0 to gpio@7), that each contain between 14 and 18 + GPIOs. Some GPIOs support interrupts. + + properties: + reg: + minimum: 0 + maximum: 7 + + gpio-controller: true + + "#gpio-cells": + const: 2 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + interrupts: + maxItems: 3 + description: + The interrupts associated with this GPIO bank + + required: + - reg + - gpio-controller + - '#gpio-cells' + + "^mux-": + $ref: pinmux-node.yaml# + + properties: + groups: + description: + One or more groups of pins to mux to a certain function + items: + enum: [ smb3, smb4, smb5, scs1, scs2, scs3, smb0, smb1, smb2, bsp, + hsp1, hsp2, r1err, r1md, rmii2, r2err, r2md, kbcc, dvo, + clko, smi, uinc, gspi, mben, xcs2, xcs1, sdio, sspi, fi0, + fi1, fi2, fi3, fi4, fi5, fi6, fi7, fi8, fi9, fi10, fi11, + fi12, fi13, fi14, fi15, pwm0, pwm1, pwm2, pwm3, pwm4, pwm5, + pwm6, pwm7, hg0, hg1, hg2, hg3, hg4, hg5, hg6, hg7 ] + function: + description: + The function that a group of pins is muxed to + enum: [ smb3, smb4, smb5, scs1, scs2, scs3, smb0, smb1, smb2, bsp, + hsp1, hsp2, r1err, r1md, rmii2, r2err, r2md, kbcc, dvo0, + dvo1, dvo2, dvo3, dvo4, dvo5, dvo6, dvo7, clko, smi, uinc, + gspi, mben, xcs2, xcs1, sdio, sspi, fi0, fi1, fi2, fi3, fi4, + fi5, fi6, fi7, fi8, fi9, fi10, fi11, fi12, fi13, fi14, fi15, + pwm0, pwm1, pwm2, pwm3, pwm4, pwm5, pwm6, pwm7, hg0, hg1, + hg2, hg3, hg4, hg5, hg6, hg7, gpio ] + + dependencies: + groups: [ function ] + function: [ groups ] + + additionalProperties: false + + "^cfg-": + $ref: pincfg-node.yaml# + + properties: + pins: + description: + A list of pins to configure in certain ways, such as enabling + debouncing + items: + pattern: "^gpio1?[0-9]{1,2}$" + + input-debounce: true + + additionalProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include + #include + pinctrl: pinctrl@b8003000 { + compatible = "nuvoton,wpcm450-pinctrl"; + reg = <0xb8003000 0x1000>; + #address-cells = <1>; + #size-cells = <0>; + + gpio0: gpio@0 { + reg = <0>; + gpio-controller; + #gpio-cells = <2>; + interrupts = <2 IRQ_TYPE_LEVEL_HIGH>, + <3 IRQ_TYPE_LEVEL_HIGH>, + <4 IRQ_TYPE_LEVEL_HIGH>; + }; + + mux-rmii2 { + groups = "rmii2"; + function = "rmii2"; + }; + + pinmux_uid: mux-uid { + groups = "gspi", "sspi"; + function = "gpio"; + }; + + pinctrl_uid: cfg-uid { + pins = "gpio14"; + input-debounce = <1>; + }; + }; + + gpio-keys { + compatible = "gpio-keys"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uid>, <&pinmux_uid>; + + uid { + label = "UID"; + linux,code = <102>; + gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>; + }; + }; -- cgit From 69c3d58dc187061a041ae76190ad604dc27c13a3 Mon Sep 17 00:00:00 2001 From: Tinghan Shen Date: Wed, 16 Feb 2022 19:31:30 +0800 Subject: dt-bindings: pinctrl: mt8195: Add mediatek,drive-strength-adv property Extend driving support for I2C pins on SoC mt8195. This property is already documented in mediatek,mt8183-pinctrl.yaml. Signed-off-by: Tinghan Shen Reviewed-by: Rob Herring Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220216113131.13145-3-tinghan.shen@mediatek.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/pinctrl-mt8195.yaml | 35 ++++++++++++++++++++++ 1 file changed, 35 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml index 8299662c2c09..c5b755514c46 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml @@ -98,6 +98,32 @@ patternProperties: drive-strength: enum: [2, 4, 6, 8, 10, 12, 14, 16] + mediatek,drive-strength-adv: + description: | + Describe the specific driving setup property. + For I2C pins, the existing generic driving setup can only support + 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they + can support 0.125/0.25/0.5/1mA adjustment. If we enable specific + driving setup, the existing generic setup will be disabled. + The specific driving setup is controlled by E1E0EN. + When E1=0/E0=0, the strength is 0.125mA. + When E1=0/E0=1, the strength is 0.25mA. + When E1=1/E0=0, the strength is 0.5mA. + When E1=1/E0=1, the strength is 1mA. + EN is used to enable or disable the specific driving setup. + Valid arguments are described as below: + 0: (E1, E0, EN) = (0, 0, 0) + 1: (E1, E0, EN) = (0, 0, 1) + 2: (E1, E0, EN) = (0, 1, 0) + 3: (E1, E0, EN) = (0, 1, 1) + 4: (E1, E0, EN) = (1, 0, 0) + 5: (E1, E0, EN) = (1, 0, 1) + 6: (E1, E0, EN) = (1, 1, 0) + 7: (E1, E0, EN) = (1, 1, 1) + So the valid arguments are from 0 to 7. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4, 5, 6, 7] + bias-pull-down: oneOf: - type: boolean @@ -270,4 +296,13 @@ examples: bias-pull-down; }; }; + + i2c0-pins { + pins { + pinmux = , + ; + bias-disable; + mediatek,drive-strength-adv = <7>; + }; + }; }; -- cgit From d4d2f9668ffd1ca10d68b84c116acbbbc6ef55bc Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Tue, 8 Mar 2022 14:11:31 -0800 Subject: dt-bindings: pinctrl: qcom: Add sc8280xp TLMM binding The Qualcomm SC8280XP platform contains a single block of registers for the TLMM block. This provides pinconf and pinmux for 228 GPIOs, 2 UFS_RESET pins and one SDC interface. Signed-off-by: Bjorn Andersson Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220308221132.1423218-1-bjorn.andersson@linaro.org Signed-off-by: Linus Walleij --- .../bindings/pinctrl/qcom,sc8280xp-pinctrl.yaml | 151 +++++++++++++++++++++ 1 file changed, 151 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-pinctrl.yaml new file mode 100644 index 000000000000..87a381c9a19d --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-pinctrl.yaml @@ -0,0 +1,151 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sc8280xp-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. SC8280XP TLMM block + +maintainers: + - Bjorn Andersson + +description: | + This binding describes the Top Level Mode Multiplexer block found in the + SC8280XP platform. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,sc8280xp-tlmm + + reg: + maxItems: 1 + + interrupts: true + interrupt-controller: true + '#interrupt-cells': true + gpio-controller: true + gpio-reserved-ranges: true + '#gpio-cells': true + gpio-ranges: true + wakeup-parent: true + +required: + - compatible + - reg + +additionalProperties: false + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-sc8280xp-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-sc8280xp-tlmm-state" + +'$defs': + qcom-sc8280xp-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-1][0-9]|22[0-7])$" + - enum: [ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset, ufs1_reset ] + minItems: 1 + maxItems: 16 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ atest_char, atest_usb, audio_ref, cam_mclk, cci_async, cci_i2c, + cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4, + cci_timer5, cci_timer6, cci_timer7, cci_timer8, cci_timer9, + cmu_rng, cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist, + ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3, ddr_pxi4, ddr_pxi5, + ddr_pxi6, ddr_pxi7, dp2_hot, dp3_hot, edp0_lcd, edp1_lcd, + edp2_lcd, edp3_lcd, edp_hot, emac0_dll, emac0_mcg0, emac0_mcg1, + emac0_mcg2, emac0_mcg3, emac0_phy, emac0_ptp, emac1_dll0, + emac1_dll1, emac1_mcg0, emac1_mcg1, emac1_mcg2, emac1_mcg3, + emac1_phy, emac1_ptp, gcc_gp1, gcc_gp2, gcc_gp3, gcc_gp4, + gcc_gp5, gpio, hs1_mi2s, hs2_mi2s, hs3_mi2s, ibi_i3c, + jitter_bist, lpass_slimbus, mdp0_vsync0, mdp0_vsync1, + mdp0_vsync2, mdp0_vsync3, mdp0_vsync4, mdp0_vsync5, + mdp0_vsync6, mdp0_vsync7, mdp0_vsync8, mdp1_vsync0, + mdp1_vsync1, mdp1_vsync2, mdp1_vsync3, mdp1_vsync4, + mdp1_vsync5, mdp1_vsync6, mdp1_vsync7, mdp1_vsync8, mdp_vsync, + mi2s0_data0, mi2s0_data1, mi2s0_sck, mi2s0_ws, mi2s1_data0, + mi2s1_data1, mi2s1_sck, mi2s1_ws, mi2s2_data0, mi2s2_data1, + mi2s2_sck, mi2s2_ws, mi2s_mclk1, mi2s_mclk2, pcie2a_clkreq, + pcie2b_clkreq, pcie3a_clkreq, pcie3b_clkreq, pcie4_clkreq, + phase_flag, pll_bist, pll_clk, prng_rosc0, prng_rosc1, + prng_rosc2, prng_rosc3, qdss_cti, qdss_gpio, qspi, qspi_clk, + qspi_cs, qup0, qup1, qup2, qup3, qup4, qup5, qup6, qup7, qup8, + qup9, qup10, qup11, qup12, qup13, qup14, qup15, qup16, qup17, + qup18, qup19, qup20, qup21, qup22, qup23, rgmii_0, rgmii_1, + sd_write, sdc40, sdc42, sdc43, sdc4_clk, sdc4_cmd, tb_trig, + tgu, tsense_pwm1, tsense_pwm2, tsense_pwm3, tsense_pwm4, + usb0_dp, usb0_phy, usb0_sbrx, usb0_sbtx, usb0_usb4, usb1_dp, + usb1_phy, usb1_sbrx, usb1_sbtx, usb1_usb4, usb2phy_ac, + vsense_trigger ] + + bias-disable: true + bias-pull-down: true + bias-pull-up: true + drive-strength: true + input-enable: true + output-high: true + output-low: true + + required: + - pins + - function + + additionalProperties: false + +examples: + - | + #include + pinctrl@f100000 { + compatible = "qcom,sc8280xp-tlmm"; + reg = <0x0f100000 0x300000>; + interrupts = ; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-ranges = <&tlmm 0 0 230>; + + gpio-wo-subnode-state { + pins = "gpio1"; + function = "gpio"; + }; + + uart-w-subnodes-state { + rx { + pins = "gpio4"; + function = "qup14"; + bias-pull-up; + }; + + tx { + pins = "gpio5"; + function = "qup14"; + bias-disable; + }; + }; + }; +... -- cgit From da40a352db2bae470a3eea038cc53454c24e67f3 Mon Sep 17 00:00:00 2001 From: Leilk Liu Date: Tue, 15 Mar 2022 11:24:07 +0800 Subject: spi: Add compatible for MT7986 This patch adds dt-binding documentation for MT7986. Signed-off-by: Leilk Liu Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220315032411.2826-3-leilk.liu@mediatek.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml index ac9ff12ae27a..818130b11bb9 100644 --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml @@ -30,6 +30,10 @@ properties: - mediatek,mt8192-spi - mediatek,mt8195-spi - const: mediatek,mt6765-spi + - items: + - enum: + - mediatek,mt7986-spi-ipm + - const: mediatek,spi-ipm - items: - enum: - mediatek,mt2701-spi -- cgit From 128d1f8241d62ab014eef6dd4ef9bb977dbeadb2 Mon Sep 17 00:00:00 2001 From: "Matthew Wilcox (Oracle)" Date: Wed, 9 Feb 2022 20:21:32 +0000 Subject: fs: Add invalidate_folio() aops method This is used in preference to invalidatepage, if defined. Signed-off-by: Matthew Wilcox (Oracle) Tested-by: Damien Le Moal Acked-by: Damien Le Moal Tested-by: Mike Marshall # orangefs Tested-by: David Howells # afs --- Documentation/filesystems/locking.rst | 13 +++++++------ Documentation/filesystems/vfs.rst | 11 ++++++----- 2 files changed, 13 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 88b33524687f..29a045fd3860 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -250,6 +250,7 @@ prototypes:: loff_t pos, unsigned len, unsigned copied, struct page *page, void *fsdata); sector_t (*bmap)(struct address_space *, sector_t); + void (*invalidate_folio) (struct folio *, size_t start, size_t len); void (*invalidatepage) (struct page *, unsigned int, unsigned int); int (*releasepage) (struct page *, int); void (*freepage)(struct page *); @@ -278,6 +279,7 @@ readpages: no shared write_begin: locks the page exclusive write_end: yes, unlocks exclusive bmap: +invalidate_folio: yes exclusive invalidatepage: yes exclusive releasepage: yes freepage: yes @@ -370,13 +372,12 @@ not locked. filesystems and by the swapper. The latter will eventually go away. Please, keep it that way and don't breed new callers. -->invalidatepage() is called when the filesystem must attempt to drop +->invalidate_folio() is called when the filesystem must attempt to drop some or all of the buffers from the page when it is being truncated. It -returns zero on success. If ->invalidatepage is zero, the kernel uses -block_invalidatepage() instead. The filesystem must exclusively acquire -invalidate_lock before invalidating page cache in truncate / hole punch path -(and thus calling into ->invalidatepage) to block races between page cache -invalidation and page cache filling functions (fault, read, ...). +returns zero on success. The filesystem must exclusively acquire +invalidate_lock before invalidating page cache in truncate / hole punch +path (and thus calling into ->invalidate_folio) to block races between page +cache invalidation and page cache filling functions (fault, read, ...). ->releasepage() is called when the kernel is about to try to drop the buffers from the page in preparation for freeing it. It returns zero to diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index da3e7b470f0a..26c090cd8cf5 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -735,6 +735,7 @@ cache in your filesystem. The following members are defined: loff_t pos, unsigned len, unsigned copied, struct page *page, void *fsdata); sector_t (*bmap)(struct address_space *, sector_t); + void (*invalidate_folio) (struct folio *, size_t start, size_t len); void (*invalidatepage) (struct page *, unsigned int, unsigned int); int (*releasepage) (struct page *, int); void (*freepage)(struct page *); @@ -868,15 +869,15 @@ cache in your filesystem. The following members are defined: to find out where the blocks in the file are and uses those addresses directly. -``invalidatepage`` - If a page has PagePrivate set, then invalidatepage will be - called when part or all of the page is to be removed from the +``invalidate_folio`` + If a folio has private data, then invalidate_folio will be + called when part or all of the folio is to be removed from the address space. This generally corresponds to either a truncation, punch hole or a complete invalidation of the address space (in the latter case 'offset' will always be 0 and 'length' - will be PAGE_SIZE). Any private data associated with the page + will be folio_size()). Any private data associated with the page should be updated to reflect this truncation. If offset is 0 - and length is PAGE_SIZE, then the private data should be + and length is folio_size(), then the private data should be released, because the page must be able to be completely discarded. This may be done by calling the ->releasepage function, but in this case the release MUST succeed. -- cgit From f50015a596fa106bf642bd85fbf6e6b52cc913d0 Mon Sep 17 00:00:00 2001 From: "Matthew Wilcox (Oracle)" Date: Wed, 9 Feb 2022 20:21:51 +0000 Subject: fs: Remove aops->invalidatepage With all users migrated to ->invalidate_folio, remove the old operation. Signed-off-by: Matthew Wilcox (Oracle) Tested-by: Damien Le Moal Acked-by: Damien Le Moal Tested-by: Mike Marshall # orangefs Tested-by: David Howells # afs --- Documentation/filesystems/locking.rst | 2 -- Documentation/filesystems/vfs.rst | 1 - 2 files changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 29a045fd3860..8e9cbc0fb70f 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -251,7 +251,6 @@ prototypes:: struct page *page, void *fsdata); sector_t (*bmap)(struct address_space *, sector_t); void (*invalidate_folio) (struct folio *, size_t start, size_t len); - void (*invalidatepage) (struct page *, unsigned int, unsigned int); int (*releasepage) (struct page *, int); void (*freepage)(struct page *); int (*direct_IO)(struct kiocb *, struct iov_iter *iter); @@ -280,7 +279,6 @@ write_begin: locks the page exclusive write_end: yes, unlocks exclusive bmap: invalidate_folio: yes exclusive -invalidatepage: yes exclusive releasepage: yes freepage: yes direct_IO: diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index 26c090cd8cf5..28704831652c 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -736,7 +736,6 @@ cache in your filesystem. The following members are defined: struct page *page, void *fsdata); sector_t (*bmap)(struct address_space *, sector_t); void (*invalidate_folio) (struct folio *, size_t start, size_t len); - void (*invalidatepage) (struct page *, unsigned int, unsigned int); int (*releasepage) (struct page *, int); void (*freepage)(struct page *); ssize_t (*direct_IO)(struct kiocb *, struct iov_iter *iter); -- cgit From affa80e8c6a1df473694c2087259901872309cc4 Mon Sep 17 00:00:00 2001 From: "Matthew Wilcox (Oracle)" Date: Wed, 9 Feb 2022 20:21:52 +0000 Subject: fs: Add aops->launder_folio Since the only difference between ->launder_page and ->launder_folio is the type of the pointer, these can safely use a union without affecting bisectability. Signed-off-by: Matthew Wilcox (Oracle) Tested-by: Damien Le Moal Acked-by: Damien Le Moal Tested-by: Mike Marshall # orangefs Tested-by: David Howells # afs --- Documentation/filesystems/locking.rst | 10 +++++----- Documentation/filesystems/vfs.rst | 8 ++++---- 2 files changed, 9 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 8e9cbc0fb70f..dee512efb458 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -257,7 +257,7 @@ prototypes:: bool (*isolate_page) (struct page *, isolate_mode_t); int (*migratepage)(struct address_space *, struct page *, struct page *); void (*putback_page) (struct page *); - int (*launder_page)(struct page *); + int (*launder_folio)(struct folio *); bool (*is_partially_uptodate)(struct folio *, size_t from, size_t count); int (*error_remove_page)(struct address_space *, struct page *); int (*swap_activate)(struct file *); @@ -285,7 +285,7 @@ direct_IO: isolate_page: yes migratepage: yes (both) putback_page: yes -launder_page: yes +launder_folio: yes is_partially_uptodate: yes error_remove_page: yes swap_activate: no @@ -385,9 +385,9 @@ the kernel assumes that the fs has no private interest in the buffers. ->freepage() is called when the kernel is done dropping the page from the page cache. -->launder_page() may be called prior to releasing a page if -it is still found to be dirty. It returns zero if the page was successfully -cleaned, or an error value if not. Note that in order to prevent the page +->launder_folio() may be called prior to releasing a folio if +it is still found to be dirty. It returns zero if the folio was successfully +cleaned, or an error value if not. Note that in order to prevent the folio getting mapped back in and redirtied, it needs to be kept locked across the entire operation. diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index 28704831652c..c54ca4d88ed6 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -745,7 +745,7 @@ cache in your filesystem. The following members are defined: int (*migratepage) (struct page *, struct page *); /* put migration-failed page back to right list */ void (*putback_page) (struct page *); - int (*launder_page) (struct page *); + int (*launder_folio) (struct folio *); bool (*is_partially_uptodate) (struct folio *, size_t from, size_t count); @@ -930,9 +930,9 @@ cache in your filesystem. The following members are defined: ``putback_page`` Called by the VM when isolated page's migration fails. -``launder_page`` - Called before freeing a page - it writes back the dirty page. - To prevent redirtying the page, it is kept locked during the +``launder_folio`` + Called before freeing a folio - it writes back the dirty folio. + To prevent redirtying the folio, it is kept locked during the whole operation. ``is_partially_uptodate`` -- cgit From 6f31a5a261dbbe7bf7f585dfe81f8acd4b25ec3b Mon Sep 17 00:00:00 2001 From: "Matthew Wilcox (Oracle)" Date: Wed, 9 Feb 2022 20:22:00 +0000 Subject: fs: Add aops->dirty_folio This replaces ->set_page_dirty(). It returns a bool instead of an int and takes the address_space as a parameter instead of expecting the implementations to retrieve the address_space from the page. This is particularly important for filesystems which use FS_OPS for swap. Signed-off-by: Matthew Wilcox (Oracle) Tested-by: Damien Le Moal Acked-by: Damien Le Moal Tested-by: Mike Marshall # orangefs Tested-by: David Howells # afs --- Documentation/filesystems/locking.rst | 15 ++++++++------- Documentation/filesystems/vfs.rst | 16 ++++++++-------- 2 files changed, 16 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index dee512efb458..72fa12dabd39 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -239,7 +239,7 @@ prototypes:: int (*writepage)(struct page *page, struct writeback_control *wbc); int (*readpage)(struct file *, struct page *); int (*writepages)(struct address_space *, struct writeback_control *); - int (*set_page_dirty)(struct page *page); + bool (*dirty_folio)(struct address_space *, struct folio *folio); void (*readahead)(struct readahead_control *); int (*readpages)(struct file *filp, struct address_space *mapping, struct list_head *pages, unsigned nr_pages); @@ -264,7 +264,7 @@ prototypes:: int (*swap_deactivate)(struct file *); locking rules: - All except set_page_dirty and freepage may block + All except dirty_folio and freepage may block ====================== ======================== ========= =============== ops PageLocked(page) i_rwsem invalidate_lock @@ -272,7 +272,7 @@ ops PageLocked(page) i_rwsem invalidate_lock writepage: yes, unlocks (see below) readpage: yes, unlocks shared writepages: -set_page_dirty no +dirty_folio maybe readahead: yes, unlocks shared readpages: no shared write_begin: locks the page exclusive @@ -361,10 +361,11 @@ If nr_to_write is NULL, all dirty pages must be written. writepages should _only_ write pages which are present on mapping->io_pages. -->set_page_dirty() is called from various places in the kernel -when the target page is marked as needing writeback. It may be called -under spinlock (it cannot block) and is sometimes called with the page -not locked. +->dirty_folio() is called from various places in the kernel when +the target folio is marked as needing writeback. The folio cannot be +truncated because either the caller holds the folio lock, or the caller +has found the folio while holding the page table lock which will block +truncation. ->bmap() is currently used by legacy ioctl() (FIBMAP) provided by some filesystems and by the swapper. The latter will eventually go away. Please, diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index c54ca4d88ed6..d16bee420326 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -658,7 +658,7 @@ pages, however the address_space has finer control of write sizes. The read process essentially only requires 'readpage'. The write process is more complicated and uses write_begin/write_end or -set_page_dirty to write data into the address_space, and writepage and +dirty_folio to write data into the address_space, and writepage and writepages to writeback data to storage. Adding and removing pages to/from an address_space is protected by the @@ -724,7 +724,7 @@ cache in your filesystem. The following members are defined: int (*writepage)(struct page *page, struct writeback_control *wbc); int (*readpage)(struct file *, struct page *); int (*writepages)(struct address_space *, struct writeback_control *); - int (*set_page_dirty)(struct page *page); + bool (*dirty_folio)(struct address_space *, struct folio *); void (*readahead)(struct readahead_control *); int (*readpages)(struct file *filp, struct address_space *mapping, struct list_head *pages, unsigned nr_pages); @@ -793,13 +793,13 @@ cache in your filesystem. The following members are defined: This will choose pages from the address space that are tagged as DIRTY and will pass them to ->writepage. -``set_page_dirty`` - called by the VM to set a page dirty. This is particularly - needed if an address space attaches private data to a page, and - that data needs to be updated when a page is dirtied. This is +``dirty_folio`` + called by the VM to mark a folio as dirty. This is particularly + needed if an address space attaches private data to a folio, and + that data needs to be updated when a folio is dirtied. This is called, for example, when a memory mapped page gets modified. - If defined, it should set the PageDirty flag, and the - PAGECACHE_TAG_DIRTY tag in the radix tree. + If defined, it should set the folio dirty flag, and the + PAGECACHE_TAG_DIRTY search mark in i_pages. ``readahead`` Called by the VM to read pages associated with the address_space -- cgit From 8fb72b4a76933ae6f86725cc8e4a8190ba84d755 Mon Sep 17 00:00:00 2001 From: "Matthew Wilcox (Oracle)" Date: Wed, 9 Feb 2022 20:22:01 +0000 Subject: fscache: Convert fscache_set_page_dirty() to fscache_dirty_folio() Convert all users of fscache_set_page_dirty to use fscache_dirty_folio. Signed-off-by: Matthew Wilcox (Oracle) Tested-by: Damien Le Moal Acked-by: Damien Le Moal Tested-by: Mike Marshall # orangefs Tested-by: David Howells # afs --- Documentation/filesystems/caching/netfs-api.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/caching/netfs-api.rst b/Documentation/filesystems/caching/netfs-api.rst index f84e9ffdf0b4..5066113acad5 100644 --- a/Documentation/filesystems/caching/netfs-api.rst +++ b/Documentation/filesystems/caching/netfs-api.rst @@ -345,8 +345,9 @@ The following facilities are provided to manage this: To support this, the following functions are provided:: - int fscache_set_page_dirty(struct page *page, - struct fscache_cookie *cookie); + bool fscache_dirty_folio(struct address_space *mapping, + struct folio *folio, + struct fscache_cookie *cookie); void fscache_unpin_writeback(struct writeback_control *wbc, struct fscache_cookie *cookie); void fscache_clear_inode_writeback(struct fscache_cookie *cookie, @@ -354,7 +355,7 @@ To support this, the following functions are provided:: const void *aux); The *set* function is intended to be called from the filesystem's -``set_page_dirty`` address space operation. If ``I_PINNING_FSCACHE_WB`` is not +``dirty_folio`` address space operation. If ``I_PINNING_FSCACHE_WB`` is not set, it sets that flag and increments the use count on the cookie (the caller must already have called ``fscache_use_cookie()``). -- cgit From 801109b1a37ad99784e6370cc7e462596f505ea3 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Mar 2022 19:18:30 +0100 Subject: dt-bindings: usb: hcd: correct usb-device path The usb-device.yaml reference is absolute so it should use /schemas part in path. Fixes: 23bf6fc7046c ("dt-bindings: usb: convert usb-device.txt to YAML schema") Cc: Reported-by: Rob Herring Acked-by: Rob Herring Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220314181830.245853-1-krzysztof.kozlowski@canonical.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/usb-hcd.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml b/Documentation/devicetree/bindings/usb/usb-hcd.yaml index 56853c17af66..1dc3d5d7b44f 100644 --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml @@ -33,7 +33,7 @@ patternProperties: "^.*@[0-9a-f]{1,2}$": description: The hard wired USB devices type: object - $ref: /usb/usb-device.yaml + $ref: /schemas/usb/usb-device.yaml additionalProperties: true -- cgit From d600d31e37dc50c4a99f3e73f8b467ea33f1475f Mon Sep 17 00:00:00 2001 From: Alexander Stein Date: Fri, 18 Feb 2022 16:27:05 +0100 Subject: dt-bindings: usb: dwc3-imx8mp: Add imx8mp specific flags This adds bindings for features in the USB glue block. They allow setting polarity of PWR and OC as well as disabling port power control. Also permanently attached can be annotated as well. Additional IO address and clock are needed. Reviewed-by: Rob Herring Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20220218152707.2198357-3-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml | 31 +++++++++++++++++++--- 1 file changed, 27 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml index 974032b1fda0..01ab0f922ae8 100644 --- a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml @@ -15,9 +15,9 @@ properties: const: fsl,imx8mp-dwc3 reg: - maxItems: 1 - description: Address and length of the register set for the wrapper of - dwc3 core on the SOC. + items: + - description: Address and length of the register set for HSIO Block Control + - description: Address and length of the register set for the wrapper of dwc3 core on the SOC. "#address-cells": enum: [ 1, 2 ] @@ -49,6 +49,28 @@ properties: - const: hsio - const: suspend + fsl,permanently-attached: + type: boolean + description: + Indicates if the device atached to a downstream port is + permanently attached. + + fsl,disable-port-power-control: + type: boolean + description: + Indicates whether the host controller implementation includes port + power control. Defines Bit 3 in capability register (HCCPARAMS). + + fsl,over-current-active-low: + type: boolean + description: + Over current signal polarity is active low. + + fsl,power-active-low: + type: boolean + description: + Power pad (PWR) polarity is active low. + # Required child node: patternProperties: @@ -74,7 +96,8 @@ examples: #include usb3_0: usb@32f10100 { compatible = "fsl,imx8mp-dwc3"; - reg = <0x32f10100 0x8>; + reg = <0x32f10100 0x8>, + <0x381f0000 0x20>; clocks = <&clk IMX8MP_CLK_HSIO_ROOT>, <&clk IMX8MP_CLK_USB_ROOT>; clock-names = "hsio", "suspend"; -- cgit From 62a13a9c0046b2224af6aa6e39c54f89a06245d4 Mon Sep 17 00:00:00 2001 From: Michael Riesch Date: Mon, 28 Feb 2022 08:56:54 -0500 Subject: dt-bindings: usb: add rk3568 compatible to rockchip, dwc3 Add the compatible for the Rockchip RK3568 variant. Tested-by: Michael Riesch Signed-off-by: Michael Riesch Link: https://lore.kernel.org/r/20220228135700.1089526-4-pgwipeout@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml b/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml index 04077f2d7faf..b3798d94d2fd 100644 --- a/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml @@ -30,6 +30,7 @@ select: enum: - rockchip,rk3328-dwc3 - rockchip,rk3399-dwc3 + - rockchip,rk3568-dwc3 required: - compatible @@ -39,6 +40,7 @@ properties: - enum: - rockchip,rk3328-dwc3 - rockchip,rk3399-dwc3 + - rockchip,rk3568-dwc3 - const: snps,dwc3 reg: -- cgit From d635316ae92291083ae7a36014e29ed7b306cb04 Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira Date: Wed, 2 Mar 2022 20:01:27 +0100 Subject: rtla/osnoise: Add an option to set the threshold Add the -T/--threshold option to set the minimum threshold to be considered a noise to osnoise top and hist commands. Also update the man pages. Link: https://lkml.kernel.org/r/031861200ffdb24a1df4aa72c458706889a20d5d.1646247211.git.bristot@kernel.org Cc: Daniel Bristot de Oliveira Cc: Clark Williams Cc: Juri Lelli Cc: Jonathan Corbet Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Steven Rostedt (Google) --- Documentation/tools/rtla/common_osnoise_options.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/tools/rtla/common_osnoise_options.rst b/Documentation/tools/rtla/common_osnoise_options.rst index d556883e4e26..27f1493f7bc0 100644 --- a/Documentation/tools/rtla/common_osnoise_options.rst +++ b/Documentation/tools/rtla/common_osnoise_options.rst @@ -15,3 +15,8 @@ Stop the trace if the total sample is higher than the argument in microseconds. If **-T** is set, it will also save the trace to the output. + +**-T**, **--threshold** *us* + + Specify the minimum delta between two time reads to be considered noise. + The default threshold is *5 us*. -- cgit From 2b622edd5eb5a12c1203fdb353c2ce0681672571 Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira Date: Wed, 2 Mar 2022 20:01:28 +0100 Subject: rtla/osnoise: Add the automatic trace option Add the -a/--auto option. This option sets some commonly used options while debugging the system. It aims to help users produce reports in the field, reducing the number of arguments passed to the tool in the first approach to a problem. It is equivalent to setting osnoise/stop_tracing_us with the argument, setting tracing_thresh to 1 us, and saving the trace to osnoise_trace.txt file if the trace is stopped automatically. Link: https://lkml.kernel.org/r/ef04c961b227eb93a83cd0b54bfca45e1a381b77.1646247211.git.bristot@kernel.org Cc: Daniel Bristot de Oliveira Cc: Clark Williams Cc: Juri Lelli Cc: Jonathan Corbet Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Steven Rostedt (Google) --- Documentation/tools/rtla/common_osnoise_options.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/tools/rtla/common_osnoise_options.rst b/Documentation/tools/rtla/common_osnoise_options.rst index 27f1493f7bc0..f792ca58c211 100644 --- a/Documentation/tools/rtla/common_osnoise_options.rst +++ b/Documentation/tools/rtla/common_osnoise_options.rst @@ -1,3 +1,8 @@ +**-a**, **--auto** *us* + + Set the automatic trace mode. This mode sets some commonly used options + while debugging the system. It is equivalent to use **-s** *us* **-T 1 -t**. + **-p**, **--period** *us* Set the *osnoise* tracer period in microseconds. -- cgit From 173a3b014827955cefdf972ae673d94b60e31cf8 Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira Date: Wed, 2 Mar 2022 20:01:29 +0100 Subject: rtla/timerlat: Add the automatic trace option Add the -a/--auto option. This option sets some commonly used options while debugging the system. It aims to help users produce reports in the field, reducing the number of arguments passed to the tool in the first approach to a problem. It is equivalent to setting osnoise/stop_tracing_total_us and print_stack with the argument, and saving the trace to timerlat_trace.txt file if the trace is stopped automatically. Link: https://lkml.kernel.org/r/92438f7ef132c731f538cebdf77850300afe04a5.1646247211.git.bristot@kernel.org Cc: Daniel Bristot de Oliveira Cc: Clark Williams Cc: Juri Lelli Cc: Jonathan Corbet Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Steven Rostedt (Google) --- Documentation/tools/rtla/common_timerlat_options.rst | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/tools/rtla/common_timerlat_options.rst b/Documentation/tools/rtla/common_timerlat_options.rst index e9c1bfd55d48..14a24a121f5d 100644 --- a/Documentation/tools/rtla/common_timerlat_options.rst +++ b/Documentation/tools/rtla/common_timerlat_options.rst @@ -1,3 +1,10 @@ +**-a**, **--auto** *us* + + Set the automatic trace mode. This mode sets some commonly used options + while debugging the system. It is equivalent to use **-T** *us* **-s** *us* + **-t**. By default, *timerlat* tracer uses FIFO:95 for *timerlat* threads, + thus equilavent to **-P** *f:95*. + **-p**, **--period** *us* Set the *timerlat* tracer period in microseconds. -- cgit From 51d64c3a181938da8fb56404524e15776e9c6bf8 Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira Date: Wed, 2 Mar 2022 20:01:31 +0100 Subject: rtla: Add -e/--event support Add -e/--event option. This option enables an event in the trace (-t) session. The argument can be a specific event, e.g., -e sched:sched_switch, or all events of a system group, e.g., -e sched. Multiple -e are allowed. It is only active when -t or -a are set. This option is available for all current tools. Link: https://lkml.kernel.org/r/6a3b753be9b1e811953995f7f21a86918ad13390.1646247211.git.bristot@kernel.org Cc: Daniel Bristot de Oliveira Cc: Clark Williams Cc: Juri Lelli Cc: Jonathan Corbet Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Steven Rostedt (Google) --- Documentation/tools/rtla/common_options.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/tools/rtla/common_options.rst b/Documentation/tools/rtla/common_options.rst index 721790ad984e..89d783dc3304 100644 --- a/Documentation/tools/rtla/common_options.rst +++ b/Documentation/tools/rtla/common_options.rst @@ -14,6 +14,10 @@ Save the stopped trace to [*file|osnoise_trace.txt*]. +**-e**, **--event** *sys:event* + + Enable an event in the trace (**-t**) session. The argument can be a specific event, e.g., **-e** *sched:sched_switch*, or all events of a system group, e.g., **-e** *sched*. Multiple **-e** are allowed. It is only active when **-t** or **-a** are set. + **-P**, **--priority** *o:prio|r:prio|f:prio|d:runtime:period* Set scheduling parameters to the osnoise tracer threads, the format to set the priority are: -- cgit From 1a754893653f73724d007c2cf95cf6c47d5114c4 Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira Date: Wed, 2 Mar 2022 20:01:33 +0100 Subject: rtla: Add --trigger support Add --trigger option. This option enables a trace event trigger to the previous -e sys:event argument, allowing some advanced tracing options. For instance, in a system with CPUs 2:23 isolated, it is possible to get a stack trace of thread wakeup targeting those CPUs while running osnoise with the following command line: # osnoise top -c 2-23 -a 50 -e sched:sched_wakeup --trigger="stacktrace if target_cpu >= 2" This option is available for all current tools. Link: https://lkml.kernel.org/r/07d2983d5f71261d4da89dbaf02efcad100ab8ee.1646247211.git.bristot@kernel.org Cc: Daniel Bristot de Oliveira Cc: Clark Williams Cc: Juri Lelli Cc: Jonathan Corbet Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Steven Rostedt (Google) --- Documentation/tools/rtla/common_options.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/tools/rtla/common_options.rst b/Documentation/tools/rtla/common_options.rst index 89d783dc3304..e5870b944334 100644 --- a/Documentation/tools/rtla/common_options.rst +++ b/Documentation/tools/rtla/common_options.rst @@ -18,6 +18,9 @@ Enable an event in the trace (**-t**) session. The argument can be a specific event, e.g., **-e** *sched:sched_switch*, or all events of a system group, e.g., **-e** *sched*. Multiple **-e** are allowed. It is only active when **-t** or **-a** are set. +**--trigger** ** + Enable a trace event trigger to the previous **-e** *sys:event*. For further information about event trigger see https://www.kernel.org/doc/html/latest/trace/events.html#event-triggers. + **-P**, **--priority** *o:prio|r:prio|f:prio|d:runtime:period* Set scheduling parameters to the osnoise tracer threads, the format to set the priority are: -- cgit From 44f3a37d1d3eb10770c7fec4eb89495d37957a26 Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira Date: Wed, 2 Mar 2022 20:01:35 +0100 Subject: rtla: Add --filter support Add --filter option. This option enables a trace event filtering of the previous -e sys:event argument. This option is available for all current tools. Link: https://lkml.kernel.org/r/509d70b6348d3e5bcbf1f07ab725ce08d063149a.1646247211.git.bristot@kernel.org Cc: Daniel Bristot de Oliveira Cc: Clark Williams Cc: Juri Lelli Cc: Jonathan Corbet Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Steven Rostedt (Google) --- Documentation/tools/rtla/common_options.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/tools/rtla/common_options.rst b/Documentation/tools/rtla/common_options.rst index e5870b944334..afd45bae821f 100644 --- a/Documentation/tools/rtla/common_options.rst +++ b/Documentation/tools/rtla/common_options.rst @@ -18,6 +18,10 @@ Enable an event in the trace (**-t**) session. The argument can be a specific event, e.g., **-e** *sched:sched_switch*, or all events of a system group, e.g., **-e** *sched*. Multiple **-e** are allowed. It is only active when **-t** or **-a** are set. +**--filter** ** + + Filter the previous **-e** *sys:event* event with **. For further information about event filtering see https://www.kernel.org/doc/html/latest/trace/events.html#event-filtering. + **--trigger** ** Enable a trace event trigger to the previous **-e** *sys:event*. For further information about event trigger see https://www.kernel.org/doc/html/latest/trace/events.html#event-triggers. -- cgit From 761916fd02c2525139aca957b8a53fda1d8b3616 Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira Date: Wed, 2 Mar 2022 20:01:36 +0100 Subject: rtla/trace: Save event histogram output to a file The hist: trigger generates a histogram in the file sys/event/hist. If the hist: trigger is used, automatically save the histogram output of the event sys:event in the sys_event_hist.txt file. Link: https://lkml.kernel.org/r/b5c906af31d4e022ffe87fb0848fac5c089087c8.1646247211.git.bristot@kernel.org Cc: Daniel Bristot de Oliveira Cc: Clark Williams Cc: Juri Lelli Cc: Jonathan Corbet Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Steven Rostedt (Google) --- Documentation/tools/rtla/common_options.rst | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/tools/rtla/common_options.rst b/Documentation/tools/rtla/common_options.rst index afd45bae821f..af76df6205d4 100644 --- a/Documentation/tools/rtla/common_options.rst +++ b/Documentation/tools/rtla/common_options.rst @@ -23,7 +23,15 @@ Filter the previous **-e** *sys:event* event with **. For further information about event filtering see https://www.kernel.org/doc/html/latest/trace/events.html#event-filtering. **--trigger** ** - Enable a trace event trigger to the previous **-e** *sys:event*. For further information about event trigger see https://www.kernel.org/doc/html/latest/trace/events.html#event-triggers. + Enable a trace event trigger to the previous **-e** *sys:event*. + If the *hist:* trigger is activated, the output histogram will be automatically saved to a file named *system_event_hist.txt*. + For example, the command: + + rtla -t -e osnoise:irq_noise --trigger="hist:key=desc,duration/1000:sort=desc,duration/1000:vals=hitcount" + + Will automatically save the content of the histogram associated to *osnoise:irq_noise* event in *osnoise_irq_noise_hist.txt*. + + For further information about event trigger see https://www.kernel.org/doc/html/latest/trace/events.html#event-triggers. **-P**, **--priority** *o:prio|r:prio|f:prio|d:runtime:period* -- cgit From 7d0dc9576dc3817c483b408715e506c3e9f37bed Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira Date: Wed, 2 Mar 2022 20:01:39 +0100 Subject: rtla/timerlat: Add --dma-latency option Add the --dma-latency to set /dev/cpu_dma_latency to the specified value, this aims to avoid having exit from idle states latencies that could be influencing the analysis. Link: https://lkml.kernel.org/r/72ddb0d913459f13217086dadafad88a7c46dd28.1646247211.git.bristot@kernel.org Cc: Daniel Bristot de Oliveira Cc: Clark Williams Cc: Juri Lelli Cc: Jonathan Corbet Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Steven Rostedt (Google) --- Documentation/tools/rtla/common_timerlat_options.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/tools/rtla/common_timerlat_options.rst b/Documentation/tools/rtla/common_timerlat_options.rst index 14a24a121f5d..bacdea6de7a3 100644 --- a/Documentation/tools/rtla/common_timerlat_options.rst +++ b/Documentation/tools/rtla/common_timerlat_options.rst @@ -21,3 +21,8 @@ Save the stack trace at the *IRQ* if a *Thread* latency is higher than the argument in us. + +**--dma-latency** *us* + Set the /dev/cpu_dma_latency to *us*, aiming to bound exit from idle latencies. + *cyclictest* sets this value to *0* by default, use **--dma-latency** *0* to have + similar results. -- cgit From 0493692b40d02a74dfb6823754f31951ace2000b Mon Sep 17 00:00:00 2001 From: Zong Li Date: Fri, 4 Mar 2022 18:03:18 +0800 Subject: dt-bindings: change the macro name of prci in header files and example We currently change the macro name for fu540 and fu740 by adding the prefix respectively, the dt-bindings should be modified as well. Signed-off-by: Zong Li Acked-by: Rob Herring Acked-by: Palmer Dabbelt Link: https://lore.kernel.org/r/f9284873c2993a9952d9fe4f8dd5e89f20daab75.1646388139.git.zong.li@sifive.com Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/gpio/sifive,gpio.yaml | 2 +- Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml | 2 +- Documentation/devicetree/bindings/serial/sifive-serial.yaml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml index e04349567eeb..8d3c126fe164 100644 --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml @@ -80,7 +80,7 @@ examples: interrupts = <7>, <8>, <9>, <10>, <11>, <12>, <13>, <14>, <15>, <16>, <17>, <18>, <19>, <20>, <21>, <22>; reg = <0x10060000 0x1000>; - clocks = <&tlclk PRCI_CLK_TLCLK>; + clocks = <&tlclk FU540_PRCI_CLK_TLCLK>; gpio-controller; #gpio-cells = <2>; interrupt-controller; diff --git a/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml b/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml index 392f0ab488c2..195e6afeb169 100644 --- a/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml @@ -104,7 +104,7 @@ examples: <0x0 0x0 0x0 0x2 &plic0 58>, <0x0 0x0 0x0 0x3 &plic0 59>, <0x0 0x0 0x0 0x4 &plic0 60>; - clocks = <&prci PRCI_CLK_PCIE_AUX>; + clocks = <&prci FU740_PRCI_CLK_PCIE_AUX>; resets = <&prci 4>; pwren-gpios = <&gpio 5 0>; reset-gpios = <&gpio 8 0>; diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.yaml b/Documentation/devicetree/bindings/serial/sifive-serial.yaml index 09aae43f65a7..b0a8871e3641 100644 --- a/Documentation/devicetree/bindings/serial/sifive-serial.yaml +++ b/Documentation/devicetree/bindings/serial/sifive-serial.yaml @@ -59,7 +59,7 @@ examples: interrupt-parent = <&plic0>; interrupts = <80>; reg = <0x10010000 0x1000>; - clocks = <&prci PRCI_CLK_TLCLK>; + clocks = <&prci FU540_PRCI_CLK_TLCLK>; }; ... -- cgit From 26c1bc67aa2fff563223f02612191405a7fa7cb7 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Sat, 26 Feb 2022 05:07:21 +0100 Subject: dt-bindings: clk: rs9: Add Renesas 9-series I2C PCIe clock generator Add binding for Renesas 9-series PCIe clock generators. This binding is designed to support 9FGV/9DBV/9DMV/9FGL/9DML/9QXL/9SQ series I2C PCIe clock generators, currently the only tested and supported chip is 9FGV0241. Signed-off-by: Marek Vasut Cc: Michael Turquette Cc: Rob Herring Cc: Stephen Boyd Cc: devicetree@vger.kernel.org Link: https://lore.kernel.org/r/20220226040723.143705-1-marex@denx.de Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- .../devicetree/bindings/clock/renesas,9series.yaml | 97 ++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/renesas,9series.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,9series.yaml b/Documentation/devicetree/bindings/clock/renesas,9series.yaml new file mode 100644 index 000000000000..102eb95cb3fc --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,9series.yaml @@ -0,0 +1,97 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/renesas,9series.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for Renesas 9-series I2C PCIe clock generators + +description: | + The Renesas 9-series are I2C PCIe clock generators providing + from 1 to 20 output clocks. + + When referencing the provided clock in the DT using phandle + and clock specifier, the following mapping applies: + + - 9FGV0241: + 0 -- DIF0 + 1 -- DIF1 + +maintainers: + - Marek Vasut + +properties: + compatible: + enum: + - renesas,9fgv0241 + + reg: + description: I2C device address + enum: [ 0x68, 0x6a ] + + '#clock-cells': + const: 1 + + clocks: + items: + - description: XTal input clock + + renesas,out-amplitude-microvolt: + enum: [ 600000, 700000, 800000, 900000 ] + description: Output clock signal amplitude + + renesas,out-spread-spectrum: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 100000, 99750, 99500 ] + description: Output clock down spread in pcm (1/1000 of percent) + +patternProperties: + "^DIF[0-19]$": + type: object + description: + Description of one of the outputs (DIF0..DIF19). + + properties: + renesas,slew-rate: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 2000000, 3000000 ] + description: Output clock slew rate select in V/ns + + additionalProperties: false + +required: + - compatible + - reg + - clocks + - '#clock-cells' + +additionalProperties: false + +examples: + - | + /* 25MHz reference crystal */ + ref25: ref25m { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <25000000>; + }; + + i2c@0 { + reg = <0x0 0x100>; + #address-cells = <1>; + #size-cells = <0>; + + rs9: clock-generator@6a { + compatible = "renesas,9fgv0241"; + reg = <0x6a>; + #clock-cells = <1>; + + clocks = <&ref25m>; + + DIF0 { + renesas,slew-rate = <3000000>; + }; + }; + }; + +... -- cgit From faac509507e2341093c32b6607a82430bccfb78f Mon Sep 17 00:00:00 2001 From: lihongnan Date: Tue, 8 Mar 2022 11:41:39 +0800 Subject: Documentation/filesystem/dax: update DAX description on erofs Add missing erofs fsdax description since fsdax has been supported on erofs from Linux 5.15. Link: https://lore.kernel.org/r/20220308034139.93748-1-hongnan.li@linux.alibaba.com Reviewed-by: Gao Xiang Acked-by: Chao Yu Signed-off-by: lihongnan Signed-off-by: Gao Xiang --- Documentation/filesystems/dax.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/dax.rst b/Documentation/filesystems/dax.rst index e3b30429d703..c04609d8ee24 100644 --- a/Documentation/filesystems/dax.rst +++ b/Documentation/filesystems/dax.rst @@ -23,11 +23,11 @@ on it as usual. The `DAX` code currently only supports files with a block size equal to your kernel's `PAGE_SIZE`, so you may need to specify a block size when creating the filesystem. -Currently 4 filesystems support `DAX`: ext2, ext4, xfs and virtiofs. +Currently 5 filesystems support `DAX`: ext2, ext4, xfs, virtiofs and erofs. Enabling `DAX` on them is different. -Enabling DAX on ext2 --------------------- +Enabling DAX on ext2 and erofs +------------------------------ When mounting the filesystem, use the ``-o dax`` option on the command line or add 'dax' to the options in ``/etc/fstab``. This works to enable `DAX` on all files -- cgit From 150b6adda6b18e80c0d76ddd35577ad8ac3a3801 Mon Sep 17 00:00:00 2001 From: Biao Huang Date: Mon, 14 Mar 2022 15:57:11 +0800 Subject: net: dt-bindings: dwmac: Convert mediatek-dwmac to DT schema Convert mediatek-dwmac to DT schema, and delete old mediatek-dwmac.txt. And there are some changes in .yaml than .txt, others almost keep the same: 1. compatible "const: snps,dwmac-4.20". 2. delete "snps,reset-active-low;" in example, since driver remove this property long ago. 3. add "snps,reset-delay-us = <0 10000 10000>" in example. 4. the example is for rgmii interface, keep related properties only. Signed-off-by: Biao Huang Reviewed-by: Rob Herring Signed-off-by: David S. Miller --- .../devicetree/bindings/net/mediatek-dwmac.txt | 91 ------------ .../devicetree/bindings/net/mediatek-dwmac.yaml | 155 +++++++++++++++++++++ 2 files changed, 155 insertions(+), 91 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/mediatek-dwmac.txt create mode 100644 Documentation/devicetree/bindings/net/mediatek-dwmac.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.txt b/Documentation/devicetree/bindings/net/mediatek-dwmac.txt deleted file mode 100644 index afbcaebf062e..000000000000 --- a/Documentation/devicetree/bindings/net/mediatek-dwmac.txt +++ /dev/null @@ -1,91 +0,0 @@ -MediaTek DWMAC glue layer controller - -This file documents platform glue layer for stmmac. -Please see stmmac.txt for the other unchanged properties. - -The device node has following properties. - -Required properties: -- compatible: Should be "mediatek,mt2712-gmac" for MT2712 SoC -- reg: Address and length of the register set for the device -- interrupts: Should contain the MAC interrupts -- interrupt-names: Should contain a list of interrupt names corresponding to - the interrupts in the interrupts property, if available. - Should be "macirq" for the main MAC IRQ -- clocks: Must contain a phandle for each entry in clock-names. -- clock-names: The name of the clock listed in the clocks property. These are - "axi", "apb", "mac_main", "ptp_ref", "rmii_internal" for MT2712 SoC. -- mac-address: See ethernet.txt in the same directory -- phy-mode: See ethernet.txt in the same directory -- mediatek,pericfg: A phandle to the syscon node that control ethernet - interface and timing delay. - -Optional properties: -- mediatek,tx-delay-ps: TX clock delay macro value. Default is 0. - It should be defined for RGMII/MII interface. - It should be defined for RMII interface when the reference clock is from MT2712 SoC. -- mediatek,rx-delay-ps: RX clock delay macro value. Default is 0. - It should be defined for RGMII/MII interface. - It should be defined for RMII interface. -Both delay properties need to be a multiple of 170 for RGMII interface, -or will round down. Range 0~31*170. -Both delay properties need to be a multiple of 550 for MII/RMII interface, -or will round down. Range 0~31*550. - -- mediatek,rmii-rxc: boolean property, if present indicates that the RMII - reference clock, which is from external PHYs, is connected to RXC pin - on MT2712 SoC. - Otherwise, is connected to TXC pin. -- mediatek,rmii-clk-from-mac: boolean property, if present indicates that - MT2712 SoC provides the RMII reference clock, which outputs to TXC pin only. -- mediatek,txc-inverse: boolean property, if present indicates that - 1. tx clock will be inversed in MII/RGMII case, - 2. tx clock inside MAC will be inversed relative to reference clock - which is from external PHYs in RMII case, and it rarely happen. - 3. the reference clock, which outputs to TXC pin will be inversed in RMII case - when the reference clock is from MT2712 SoC. -- mediatek,rxc-inverse: boolean property, if present indicates that - 1. rx clock will be inversed in MII/RGMII case. - 2. reference clock will be inversed when arrived at MAC in RMII case, when - the reference clock is from external PHYs. - 3. the inside clock, which be sent to MAC, will be inversed in RMII case when - the reference clock is from MT2712 SoC. -- assigned-clocks: mac_main and ptp_ref clocks -- assigned-clock-parents: parent clocks of the assigned clocks - -Example: - eth: ethernet@1101c000 { - compatible = "mediatek,mt2712-gmac"; - reg = <0 0x1101c000 0 0x1300>; - interrupts = ; - interrupt-names = "macirq"; - phy-mode ="rgmii-rxid"; - mac-address = [00 55 7b b5 7d f7]; - clock-names = "axi", - "apb", - "mac_main", - "ptp_ref", - "rmii_internal"; - clocks = <&pericfg CLK_PERI_GMAC>, - <&pericfg CLK_PERI_GMAC_PCLK>, - <&topckgen CLK_TOP_ETHER_125M_SEL>, - <&topckgen CLK_TOP_ETHER_50M_SEL>, - <&topckgen CLK_TOP_ETHER_50M_RMII_SEL>; - assigned-clocks = <&topckgen CLK_TOP_ETHER_125M_SEL>, - <&topckgen CLK_TOP_ETHER_50M_SEL>, - <&topckgen CLK_TOP_ETHER_50M_RMII_SEL>; - assigned-clock-parents = <&topckgen CLK_TOP_ETHERPLL_125M>, - <&topckgen CLK_TOP_APLL1_D3>, - <&topckgen CLK_TOP_ETHERPLL_50M>; - power-domains = <&scpsys MT2712_POWER_DOMAIN_AUDIO>; - mediatek,pericfg = <&pericfg>; - mediatek,tx-delay-ps = <1530>; - mediatek,rx-delay-ps = <1530>; - mediatek,rmii-rxc; - mediatek,txc-inverse; - mediatek,rxc-inverse; - snps,txpbl = <1>; - snps,rxpbl = <1>; - snps,reset-gpio = <&pio 87 GPIO_ACTIVE_LOW>; - snps,reset-active-low; - }; diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml new file mode 100644 index 000000000000..8ad6e19661b8 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml @@ -0,0 +1,155 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mediatek-dwmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek DWMAC glue layer controller + +maintainers: + - Biao Huang + +description: + This file documents platform glue layer for stmmac. + +# We need a select here so we don't match all nodes with 'snps,dwmac' +select: + properties: + compatible: + contains: + enum: + - mediatek,mt2712-gmac + required: + - compatible + +allOf: + - $ref: "snps,dwmac.yaml#" + +properties: + compatible: + items: + - enum: + - mediatek,mt2712-gmac + - const: snps,dwmac-4.20a + + clocks: + items: + - description: AXI clock + - description: APB clock + - description: MAC Main clock + - description: PTP clock + - description: RMII reference clock provided by MAC + + clock-names: + items: + - const: axi + - const: apb + - const: mac_main + - const: ptp_ref + - const: rmii_internal + + mediatek,pericfg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle to the syscon node that control ethernet + interface and timing delay. + + mediatek,tx-delay-ps: + description: + The internal TX clock delay (provided by this driver) in nanoseconds. + For MT2712 RGMII interface, Allowed value need to be a multiple of 170, + or will round down. Range 0~31*170. + For MT2712 RMII/MII interface, Allowed value need to be a multiple of 550, + or will round down. Range 0~31*550. + + mediatek,rx-delay-ps: + description: + The internal RX clock delay (provided by this driver) in nanoseconds. + For MT2712 RGMII interface, Allowed value need to be a multiple of 170, + or will round down. Range 0~31*170. + For MT2712 RMII/MII interface, Allowed value need to be a multiple of 550, + or will round down. Range 0~31*550. + + mediatek,rmii-rxc: + type: boolean + description: + If present, indicates that the RMII reference clock, which is from external + PHYs, is connected to RXC pin. Otherwise, is connected to TXC pin. + + mediatek,rmii-clk-from-mac: + type: boolean + description: + If present, indicates that MAC provides the RMII reference clock, which + outputs to TXC pin only. + + mediatek,txc-inverse: + type: boolean + description: + If present, indicates that + 1. tx clock will be inversed in MII/RGMII case, + 2. tx clock inside MAC will be inversed relative to reference clock + which is from external PHYs in RMII case, and it rarely happen. + 3. the reference clock, which outputs to TXC pin will be inversed in RMII case + when the reference clock is from MAC. + + mediatek,rxc-inverse: + type: boolean + description: + If present, indicates that + 1. rx clock will be inversed in MII/RGMII case. + 2. reference clock will be inversed when arrived at MAC in RMII case, when + the reference clock is from external PHYs. + 3. the inside clock, which be sent to MAC, will be inversed in RMII case when + the reference clock is from MAC. + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - phy-mode + - mediatek,pericfg + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + #include + #include + + eth: ethernet@1101c000 { + compatible = "mediatek,mt2712-gmac", "snps,dwmac-4.20a"; + reg = <0x1101c000 0x1300>; + interrupts = ; + interrupt-names = "macirq"; + phy-mode ="rgmii-rxid"; + mac-address = [00 55 7b b5 7d f7]; + clock-names = "axi", + "apb", + "mac_main", + "ptp_ref", + "rmii_internal"; + clocks = <&pericfg CLK_PERI_GMAC>, + <&pericfg CLK_PERI_GMAC_PCLK>, + <&topckgen CLK_TOP_ETHER_125M_SEL>, + <&topckgen CLK_TOP_ETHER_50M_SEL>, + <&topckgen CLK_TOP_ETHER_50M_RMII_SEL>; + assigned-clocks = <&topckgen CLK_TOP_ETHER_125M_SEL>, + <&topckgen CLK_TOP_ETHER_50M_SEL>, + <&topckgen CLK_TOP_ETHER_50M_RMII_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_ETHERPLL_125M>, + <&topckgen CLK_TOP_APLL1_D3>, + <&topckgen CLK_TOP_ETHERPLL_50M>; + power-domains = <&scpsys MT2712_POWER_DOMAIN_AUDIO>; + mediatek,pericfg = <&pericfg>; + mediatek,tx-delay-ps = <1530>; + snps,txpbl = <1>; + snps,rxpbl = <1>; + snps,reset-gpio = <&pio 87 GPIO_ACTIVE_LOW>; + snps,reset-delays-us = <0 10000 10000>; + }; -- cgit From ee410d510032d3b059bc4b135cd56620b1db689a Mon Sep 17 00:00:00 2001 From: Biao Huang Date: Mon, 14 Mar 2022 15:57:13 +0800 Subject: net: dt-bindings: dwmac: add support for mt8195 Add binding document for the ethernet on mt8195. Signed-off-by: Biao Huang Reviewed-by: Rob Herring Signed-off-by: David S. Miller --- .../devicetree/bindings/net/mediatek-dwmac.yaml | 28 ++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml index 8ad6e19661b8..901944683322 100644 --- a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml @@ -19,6 +19,7 @@ select: contains: enum: - mediatek,mt2712-gmac + - mediatek,mt8195-gmac required: - compatible @@ -27,26 +28,35 @@ allOf: properties: compatible: - items: - - enum: - - mediatek,mt2712-gmac - - const: snps,dwmac-4.20a + oneOf: + - items: + - enum: + - mediatek,mt2712-gmac + - const: snps,dwmac-4.20a + - items: + - enum: + - mediatek,mt8195-gmac + - const: snps,dwmac-5.10a clocks: + minItems: 5 items: - description: AXI clock - description: APB clock - description: MAC Main clock - description: PTP clock - description: RMII reference clock provided by MAC + - description: MAC clock gate clock-names: + minItems: 5 items: - const: axi - const: apb - const: mac_main - const: ptp_ref - const: rmii_internal + - const: mac_cg mediatek,pericfg: $ref: /schemas/types.yaml#/definitions/phandle @@ -61,6 +71,8 @@ properties: or will round down. Range 0~31*170. For MT2712 RMII/MII interface, Allowed value need to be a multiple of 550, or will round down. Range 0~31*550. + For MT8195 RGMII/RMII/MII interface, Allowed value need to be a multiple of 290, + or will round down. Range 0~31*290. mediatek,rx-delay-ps: description: @@ -69,6 +81,8 @@ properties: or will round down. Range 0~31*170. For MT2712 RMII/MII interface, Allowed value need to be a multiple of 550, or will round down. Range 0~31*550. + For MT8195 RGMII/RMII/MII interface, Allowed value need to be a multiple + of 290, or will round down. Range 0~31*290. mediatek,rmii-rxc: type: boolean @@ -102,6 +116,12 @@ properties: 3. the inside clock, which be sent to MAC, will be inversed in RMII case when the reference clock is from MAC. + mediatek,mac-wol: + type: boolean + description: + If present, indicates that MAC supports WOL(Wake-On-LAN), and MAC WOL will be enabled. + Otherwise, PHY WOL is perferred. + required: - compatible - reg -- cgit From 16c02447f3e1d7f86829ef66ce294aac38bd6b4c Mon Sep 17 00:00:00 2001 From: Srinivas Pandruvada Date: Fri, 11 Mar 2022 14:14:13 -0800 Subject: Documentation: thermal: DPTF Documentation Document Intel Dynamic Platform and Thermal Framework (DPTF) ABI. Signed-off-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki --- Documentation/driver-api/thermal/index.rst | 1 + Documentation/driver-api/thermal/intel_dptf.rst | 272 ++++++++++++++++++++++++ 2 files changed, 273 insertions(+) create mode 100644 Documentation/driver-api/thermal/intel_dptf.rst (limited to 'Documentation') diff --git a/Documentation/driver-api/thermal/index.rst b/Documentation/driver-api/thermal/index.rst index 4cb0b9b6bfb8..030306ffa408 100644 --- a/Documentation/driver-api/thermal/index.rst +++ b/Documentation/driver-api/thermal/index.rst @@ -17,3 +17,4 @@ Thermal intel_powerclamp nouveau_thermal x86_pkg_temperature_thermal + intel_dptf diff --git a/Documentation/driver-api/thermal/intel_dptf.rst b/Documentation/driver-api/thermal/intel_dptf.rst new file mode 100644 index 000000000000..96668dca753a --- /dev/null +++ b/Documentation/driver-api/thermal/intel_dptf.rst @@ -0,0 +1,272 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============================================================== +Intel(R) Dynamic Platform and Thermal Framework Sysfs Interface +=============================================================== + +:Copyright: |copy| 2022 Intel Corporation + +:Author: Srinivas Pandruvada + +Introduction +------------ + +Intel(R) Dynamic Platform and Thermal Framework (DPTF) is a platform +level hardware/software solution for power and thermal management. + +As a container for multiple power/thermal technologies, DPTF provides +a coordinated approach for different policies to effect the hardware +state of a system. + +Since it is a platform level framework, this has several components. +Some parts of the technology is implemented in the firmware and uses +ACPI and PCI devices to expose various features for monitoring and +control. Linux has a set of kernel drivers exposing hardware interface +to user space. This allows user space thermal solutions like +"Linux Thermal Daemon" to read platform specific thermal and power +tables to deliver adequate performance while keeping the system under +thermal limits. + +DPTF ACPI Drivers interface +---------------------------- + +:file:`/sys/bus/platform/devices//uuids`, where +=INT3400|INTC1040|INTC1041|INTC10A0 + +``available_uuids`` (RO) + A set of UUIDs strings presenting available policies + which should be notified to the firmware when the + user space can support those policies. + + UUID strings: + + "42A441D6-AE6A-462b-A84B-4A8CE79027D3" : Passive 1 + + "3A95C389-E4B8-4629-A526-C52C88626BAE" : Active + + "97C68AE7-15FA-499c-B8C9-5DA81D606E0A" : Critical + + "63BE270F-1C11-48FD-A6F7-3AF253FF3E2D" : Adaptive performance + + "5349962F-71E6-431D-9AE8-0A635B710AEE" : Emergency call + + "9E04115A-AE87-4D1C-9500-0F3E340BFE75" : Passive 2 + + "F5A35014-C209-46A4-993A-EB56DE7530A1" : Power Boss + + "6ED722A7-9240-48A5-B479-31EEF723D7CF" : Virtual Sensor + + "16CAF1B7-DD38-40ED-B1C1-1B8A1913D531" : Cooling mode + + "BE84BABF-C4D4-403D-B495-3128FD44dAC1" : HDC + +``current_uuid`` (RW) + User space can write strings from available UUIDs, one at a + time. + +:file:`/sys/bus/platform/devices//`, where +=INT3400|INTC1040|INTC1041|INTC10A0 + +``imok`` (WO) + User space daemon write 1 to respond to firmware event + for sending keep alive notification. User space receives + THERMAL_EVENT_KEEP_ALIVE kobject uevent notification when + firmware calls for user space to respond with imok ACPI + method. + +``odvp*`` (RO) + Firmware thermal status variable values. Thermal tables + calls for different processing based on these variable + values. + +``data_vault`` (RO) + Binary thermal table. Refer to + https:/github.com/intel/thermal_daemon for decoding + thermal table. + + +ACPI Thermal Relationship table interface +------------------------------------------ + +:file:`/dev/acpi_thermal_rel` + + This device provides IOCTL interface to read standard ACPI + thermal relationship tables via ACPI methods _TRT and _ART. + These IOCTLs are defined in + drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.h + + IOCTLs: + + ACPI_THERMAL_GET_TRT_LEN: Get length of TRT table + + ACPI_THERMAL_GET_ART_LEN: Get length of ART table + + ACPI_THERMAL_GET_TRT_COUNT: Number of records in TRT table + + ACPI_THERMAL_GET_ART_COUNT: Number of records in ART table + + ACPI_THERMAL_GET_TRT: Read binary TRT table, length to read is + provided via argument to ioctl(). + + ACPI_THERMAL_GET_ART: Read binary ART table, length to read is + provided via argument to ioctl(). + +DPTF ACPI Sensor drivers +------------------------- + +DPTF Sensor drivers are presented as standard thermal sysfs thermal_zone. + + +DPTF ACPI Cooling drivers +-------------------------- + +DPTF cooling drivers are presented as standard thermal sysfs cooling_device. + + +DPTF Processor thermal PCI Driver interface +-------------------------------------------- + +:file:`/sys/bus/pci/devices/0000\:00\:04.0/power_limits/` + +Refer to Documentation/power/powercap/powercap.rst for powercap +ABI. + +``power_limit_0_max_uw`` (RO) + Maximum powercap sysfs constraint_0_power_limit_uw for Intel RAPL + +``power_limit_0_step_uw`` (RO) + Power limit increment/decrements for Intel RAPL constraint 0 power limit + +``power_limit_0_min_uw`` (RO) + Minimum powercap sysfs constraint_0_power_limit_uw for Intel RAPL + +``power_limit_0_tmin_us`` (RO) + Minimum powercap sysfs constraint_0_time_window_us for Intel RAPL + +``power_limit_0_tmax_us`` (RO) + Maximum powercap sysfs constraint_0_time_window_us for Intel RAPL + +``power_limit_1_max_uw`` (RO) + Maximum powercap sysfs constraint_1_power_limit_uw for Intel RAPL + +``power_limit_1_step_uw`` (RO) + Power limit increment/decrements for Intel RAPL constraint 1 power limit + +``power_limit_1_min_uw`` (RO) + Minimum powercap sysfs constraint_1_power_limit_uw for Intel RAPL + +``power_limit_1_tmin_us`` (RO) + Minimum powercap sysfs constraint_1_time_window_us for Intel RAPL + +``power_limit_1_tmax_us`` (RO) + Maximum powercap sysfs constraint_1_time_window_us for Intel RAPL + +:file:`/sys/bus/pci/devices/0000\:00\:04.0/` + +``tcc_offset_degree_celsius`` (RW) + TCC offset from the critical temperature where hardware will throttle + CPU. + +:file:`/sys/bus/pci/devices/0000\:00\:04.0/workload_request` + +``workload_available_types`` (RO) + Available workload types. User space can specify one of the workload type + it is currently executing via workload_type. For example: idle, bursty, + sustained etc. + +``workload_type`` (RW) + User space can specify any one of the available workload type using + this interface. + +DPTF Processor thermal RFIM interface +-------------------------------------------- + +RFIM interface allows adjustment of FIVR (Fully Integrated Voltage Regulator) +and DDR (Double Data Rate)frequencies to avoid RF interference with WiFi and 5G. + +Switching voltage regulators (VR) generate radiated EMI or RFI at the +fundamental frequency and its harmonics. Some harmonics may interfere +with very sensitive wireless receivers such as Wi-Fi and cellular that +are integrated into host systems like notebook PCs. One of mitigation +methods is requesting SOC integrated VR (IVR) switching frequency to a +small % and shift away the switching noise harmonic interference from +radio channels. OEM or ODMs can use the driver to control SOC IVR +operation within the range where it does not impact IVR performance. + +DRAM devices of DDR IO interface and their power plane can generate EMI +at the data rates. Similar to IVR control mechanism, Intel offers a +mechanism by which DDR data rates can be changed if several conditions +are met: there is strong RFI interference because of DDR; CPU power +management has no other restriction in changing DDR data rates; +PC ODMs enable this feature (real time DDR RFI Mitigation referred to as +DDR-RFIM) for Wi-Fi from BIOS. + + +FIVR attributes + +:file:`/sys/bus/pci/devices/0000\:00\:04.0/fivr/` + +``vco_ref_code_lo`` (RW) + The VCO reference code is an 11-bit field and controls the FIVR + switching frequency. This is the 3-bit LSB field. + +``vco_ref_code_hi`` (RW) + The VCO reference code is an 11-bit field and controls the FIVR + switching frequency. This is the 8-bit MSB field. + +``spread_spectrum_pct`` (RW) + Set the FIVR spread spectrum clocking percentage + +``spread_spectrum_clk_enable`` (RW) + Enable/disable of the FIVR spread spectrum clocking feature + +``rfi_vco_ref_code`` (RW) + This field is a read only status register which reflects the + current FIVR switching frequency + +``fivr_fffc_rev`` (RW) + This field indicated the revision of the FIVR HW. + + +DVFS attributes + +:file:`/sys/bus/pci/devices/0000\:00\:04.0/dvfs/` + +``rfi_restriction_run_busy`` (RW) + Request the restriction of specific DDR data rate and set this + value 1. Self reset to 0 after operation. + +``rfi_restriction_err_code`` (RW) + 0 :Request is accepted, 1:Feature disabled, + 2: the request restricts more points than it is allowed + +``rfi_restriction_data_rate_Delta`` (RW) + Restricted DDR data rate for RFI protection: Lower Limit + +``rfi_restriction_data_rate_Base`` (RW) + Restricted DDR data rate for RFI protection: Upper Limit + +``ddr_data_rate_point_0`` (RO) + DDR data rate selection 1st point + +``ddr_data_rate_point_1`` (RO) + DDR data rate selection 2nd point + +``ddr_data_rate_point_2`` (RO) + DDR data rate selection 3rd point + +``ddr_data_rate_point_3`` (RO) + DDR data rate selection 4th point + +``rfi_disable (RW)`` + Disable DDR rate change feature + +DPTF Power supply and Battery Interface +---------------------------------------- + +Refer to Documentation/ABI/testing/sysfs-platform-dptf + +DPTF Fan Control +---------------------------------------- + +Refer to Documentation/admin-guide/acpi/fan_performance_states.rst -- cgit From 2cb7b4890d6e7f20560dc251e7f8d3cc68b0d554 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Mon, 14 Mar 2022 23:00:04 -0700 Subject: devlink: expose instance locking and add locked port registering It should be familiar and beneficial to expose devlink instance lock to the drivers. This way drivers can block devlink from calling them during critical sections without breakneck locking. Add port helpers, port splitting callbacks will be the first target. Use 'devl_' prefix for "explicitly locked" API. Initial RFC used '__devlink' but that's too much typing. devl_lock_is_held() is not defined without lockdep, which is the same behavior as lockdep_is_held() itself. Reviewed-by: Leon Romanovsky Signed-off-by: Jakub Kicinski --- Documentation/networking/devlink/index.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst index 443123772f44..c17cdb079611 100644 --- a/Documentation/networking/devlink/index.rst +++ b/Documentation/networking/devlink/index.rst @@ -4,6 +4,22 @@ Linux Devlink Documentation devlink is an API to expose device information and resources not directly related to any device class, such as chip-wide/switch-ASIC-wide configuration. +Locking +------- + +Driver facing APIs are currently transitioning to allow more explicit +locking. Drivers can use the existing ``devlink_*`` set of APIs, or +new APIs prefixed by ``devl_*``. The older APIs handle all the locking +in devlink core, but don't allow registration of most sub-objects once +the main devlink object is itself registered. The newer ``devl_*`` APIs assume +the devlink instance lock is already held. Drivers can take the instance +lock by calling ``devl_lock()``. It is also held in most of the callbacks. +Eventually all callbacks will be invoked under the devlink instance lock, +refer to the use of the ``DEVLINK_NL_FLAG_NO_LOCK`` flag in devlink core +to find out which callbacks are not converted, yet. + +Drivers are encouraged to use the devlink instance lock for their own needs. + Interface documentation ----------------------- -- cgit From 7843d3c8e5e6887e79dd11c7b5311d9fec66cb76 Mon Sep 17 00:00:00 2001 From: Amit Kumar Mahapatra Date: Wed, 16 Mar 2022 22:41:05 +0530 Subject: dt-bindings: can: xilinx_can: Convert Xilinx CAN binding to YAML Convert Xilinx CAN binding documentation to YAML. Link: https://lore.kernel.org/all/20220316171105.17654-1-amit.kumar-mahapatra@xilinx.com Signed-off-by: Amit Kumar Mahapatra Reviewed-by: Krzysztof Kozlowski Signed-off-by: Marc Kleine-Budde --- .../devicetree/bindings/net/can/xilinx,can.yaml | 161 +++++++++++++++++++++ .../devicetree/bindings/net/can/xilinx_can.txt | 61 -------- 2 files changed, 161 insertions(+), 61 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/can/xilinx,can.yaml delete mode 100644 Documentation/devicetree/bindings/net/can/xilinx_can.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml new file mode 100644 index 000000000000..65af8183cb9c --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml @@ -0,0 +1,161 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/xilinx,can.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: + Xilinx Axi CAN/Zynq CANPS controller + +maintainers: + - Appana Durga Kedareswara rao + +properties: + compatible: + enum: + - xlnx,zynq-can-1.0 + - xlnx,axi-can-1.00.a + - xlnx,canfd-1.0 + - xlnx,canfd-2.0 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + maxItems: 2 + + power-domains: + maxItems: 1 + + tx-fifo-depth: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: CAN Tx fifo depth (Zynq, Axi CAN). + + rx-fifo-depth: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: CAN Rx fifo depth (Zynq, Axi CAN, CAN FD in sequential Rx mode) + + tx-mailbox-count: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: CAN Tx mailbox buffer count (CAN FD) + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +allOf: + - $ref: can-controller.yaml# + - if: + properties: + compatible: + contains: + enum: + - xlnx,zynq-can-1.0 + + then: + properties: + clock-names: + items: + - const: can_clk + - const: pclk + required: + - tx-fifo-depth + - rx-fifo-depth + + - if: + properties: + compatible: + contains: + enum: + - xlnx,axi-can-1.00.a + + then: + properties: + clock-names: + items: + - const: can_clk + - const: s_axi_aclk + required: + - tx-fifo-depth + - rx-fifo-depth + + - if: + properties: + compatible: + contains: + enum: + - xlnx,canfd-1.0 + - xlnx,canfd-2.0 + + then: + properties: + clock-names: + items: + - const: can_clk + - const: s_axi_aclk + required: + - tx-mailbox-count + - rx-fifo-depth + +examples: + - | + #include + + can@e0008000 { + compatible = "xlnx,zynq-can-1.0"; + reg = <0xe0008000 0x1000>; + clocks = <&clkc 19>, <&clkc 36>; + clock-names = "can_clk", "pclk"; + interrupts = ; + interrupt-parent = <&intc>; + tx-fifo-depth = <0x40>; + rx-fifo-depth = <0x40>; + }; + + - | + can@40000000 { + compatible = "xlnx,axi-can-1.00.a"; + reg = <0x40000000 0x10000>; + clocks = <&clkc 0>, <&clkc 1>; + clock-names = "can_clk", "s_axi_aclk"; + interrupt-parent = <&intc>; + interrupts = ; + tx-fifo-depth = <0x40>; + rx-fifo-depth = <0x40>; + }; + + - | + can@40000000 { + compatible = "xlnx,canfd-1.0"; + reg = <0x40000000 0x2000>; + clocks = <&clkc 0>, <&clkc 1>; + clock-names = "can_clk", "s_axi_aclk"; + interrupt-parent = <&intc>; + interrupts = ; + tx-mailbox-count = <0x20>; + rx-fifo-depth = <0x20>; + }; + + - | + can@ff060000 { + compatible = "xlnx,canfd-2.0"; + reg = <0xff060000 0x6000>; + clocks = <&clkc 0>, <&clkc 1>; + clock-names = "can_clk", "s_axi_aclk"; + interrupt-parent = <&intc>; + interrupts = ; + tx-mailbox-count = <0x20>; + rx-fifo-depth = <0x40>; + }; diff --git a/Documentation/devicetree/bindings/net/can/xilinx_can.txt b/Documentation/devicetree/bindings/net/can/xilinx_can.txt deleted file mode 100644 index 100cc40b8510..000000000000 --- a/Documentation/devicetree/bindings/net/can/xilinx_can.txt +++ /dev/null @@ -1,61 +0,0 @@ -Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings ---------------------------------------------------------- - -Required properties: -- compatible : Should be: - - "xlnx,zynq-can-1.0" for Zynq CAN controllers - - "xlnx,axi-can-1.00.a" for Axi CAN controllers - - "xlnx,canfd-1.0" for CAN FD controllers - - "xlnx,canfd-2.0" for CAN FD 2.0 controllers -- reg : Physical base address and size of the controller - registers map. -- interrupts : Property with a value describing the interrupt - number. -- clock-names : List of input clock names - - "can_clk", "pclk" (For CANPS), - - "can_clk", "s_axi_aclk" (For AXI CAN and CAN FD). - (See clock bindings for details). -- clocks : Clock phandles (see clock bindings for details). -- tx-fifo-depth : Can Tx fifo depth (Zynq, Axi CAN). -- rx-fifo-depth : Can Rx fifo depth (Zynq, Axi CAN, CAN FD in - sequential Rx mode). -- tx-mailbox-count : Can Tx mailbox buffer count (CAN FD). -- rx-mailbox-count : Can Rx mailbox buffer count (CAN FD in mailbox Rx - mode). - - -Example: - -For Zynq CANPS Dts file: - zynq_can_0: can@e0008000 { - compatible = "xlnx,zynq-can-1.0"; - clocks = <&clkc 19>, <&clkc 36>; - clock-names = "can_clk", "pclk"; - reg = <0xe0008000 0x1000>; - interrupts = <0 28 4>; - interrupt-parent = <&intc>; - tx-fifo-depth = <0x40>; - rx-fifo-depth = <0x40>; - }; -For Axi CAN Dts file: - axi_can_0: axi-can@40000000 { - compatible = "xlnx,axi-can-1.00.a"; - clocks = <&clkc 0>, <&clkc 1>; - clock-names = "can_clk","s_axi_aclk" ; - reg = <0x40000000 0x10000>; - interrupt-parent = <&intc>; - interrupts = <0 59 1>; - tx-fifo-depth = <0x40>; - rx-fifo-depth = <0x40>; - }; -For CAN FD Dts file: - canfd_0: canfd@40000000 { - compatible = "xlnx,canfd-1.0"; - clocks = <&clkc 0>, <&clkc 1>; - clock-names = "can_clk", "s_axi_aclk"; - reg = <0x40000000 0x2000>; - interrupt-parent = <&intc>; - interrupts = <0 59 1>; - tx-mailbox-count = <0x20>; - rx-fifo-depth = <0x20>; - }; -- cgit From b57b84968865780262f191cc95d688d7f82e681c Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Sat, 12 Mar 2022 15:07:51 +0800 Subject: docs: scheduler: Convert schedutil.txt to ReST All other scheduler documents have been converted to *.rst. Let's do the same for schedutil.txt. Also fixed some typos. Signed-off-by: Tang Yizhou Link: https://lore.kernel.org/r/20220312070751.16844-1-tangyizhou@huawei.com Signed-off-by: Jonathan Corbet --- Documentation/scheduler/index.rst | 1 + Documentation/scheduler/schedutil.rst | 173 ++++++++++++++++++++++++++++++++++ Documentation/scheduler/schedutil.txt | 169 --------------------------------- 3 files changed, 174 insertions(+), 169 deletions(-) create mode 100644 Documentation/scheduler/schedutil.rst delete mode 100644 Documentation/scheduler/schedutil.txt (limited to 'Documentation') diff --git a/Documentation/scheduler/index.rst b/Documentation/scheduler/index.rst index 88900aabdbf7..693eaac769a7 100644 --- a/Documentation/scheduler/index.rst +++ b/Documentation/scheduler/index.rst @@ -14,6 +14,7 @@ Linux Scheduler sched-domains sched-capacity sched-energy + schedutil sched-nice-design sched-rt-group sched-stats diff --git a/Documentation/scheduler/schedutil.rst b/Documentation/scheduler/schedutil.rst new file mode 100644 index 000000000000..32c7d69fc86c --- /dev/null +++ b/Documentation/scheduler/schedutil.rst @@ -0,0 +1,173 @@ +========= +Schedutil +========= + +.. note:: + + All this assumes a linear relation between frequency and work capacity, + we know this is flawed, but it is the best workable approximation. + + +PELT (Per Entity Load Tracking) +=============================== + +With PELT we track some metrics across the various scheduler entities, from +individual tasks to task-group slices to CPU runqueues. As the basis for this +we use an Exponentially Weighted Moving Average (EWMA), each period (1024us) +is decayed such that y^32 = 0.5. That is, the most recent 32ms contribute +half, while the rest of history contribute the other half. + +Specifically: + + ewma_sum(u) := u_0 + u_1*y + u_2*y^2 + ... + + ewma(u) = ewma_sum(u) / ewma_sum(1) + +Since this is essentially a progression of an infinite geometric series, the +results are composable, that is ewma(A) + ewma(B) = ewma(A+B). This property +is key, since it gives the ability to recompose the averages when tasks move +around. + +Note that blocked tasks still contribute to the aggregates (task-group slices +and CPU runqueues), which reflects their expected contribution when they +resume running. + +Using this we track 2 key metrics: 'running' and 'runnable'. 'Running' +reflects the time an entity spends on the CPU, while 'runnable' reflects the +time an entity spends on the runqueue. When there is only a single task these +two metrics are the same, but once there is contention for the CPU 'running' +will decrease to reflect the fraction of time each task spends on the CPU +while 'runnable' will increase to reflect the amount of contention. + +For more detail see: kernel/sched/pelt.c + + +Frequency / CPU Invariance +========================== + +Because consuming the CPU for 50% at 1GHz is not the same as consuming the CPU +for 50% at 2GHz, nor is running 50% on a LITTLE CPU the same as running 50% on +a big CPU, we allow architectures to scale the time delta with two ratios, one +Dynamic Voltage and Frequency Scaling (DVFS) ratio and one microarch ratio. + +For simple DVFS architectures (where software is in full control) we trivially +compute the ratio as:: + + f_cur + r_dvfs := ----- + f_max + +For more dynamic systems where the hardware is in control of DVFS we use +hardware counters (Intel APERF/MPERF, ARMv8.4-AMU) to provide us this ratio. +For Intel specifically, we use:: + + APERF + f_cur := ----- * P0 + MPERF + + 4C-turbo; if available and turbo enabled + f_max := { 1C-turbo; if turbo enabled + P0; otherwise + + f_cur + r_dvfs := min( 1, ----- ) + f_max + +We pick 4C turbo over 1C turbo to make it slightly more sustainable. + +r_cpu is determined as the ratio of highest performance level of the current +CPU vs the highest performance level of any other CPU in the system. + + r_tot = r_dvfs * r_cpu + +The result is that the above 'running' and 'runnable' metrics become invariant +of DVFS and CPU type. IOW. we can transfer and compare them between CPUs. + +For more detail see: + + - kernel/sched/pelt.h:update_rq_clock_pelt() + - arch/x86/kernel/smpboot.c:"APERF/MPERF frequency ratio computation." + - Documentation/scheduler/sched-capacity.rst:"1. CPU Capacity + 2. Task utilization" + + +UTIL_EST / UTIL_EST_FASTUP +========================== + +Because periodic tasks have their averages decayed while they sleep, even +though when running their expected utilization will be the same, they suffer a +(DVFS) ramp-up after they are running again. + +To alleviate this (a default enabled option) UTIL_EST drives an Infinite +Impulse Response (IIR) EWMA with the 'running' value on dequeue -- when it is +highest. A further default enabled option UTIL_EST_FASTUP modifies the IIR +filter to instantly increase and only decay on decrease. + +A further runqueue wide sum (of runnable tasks) is maintained of: + + util_est := \Sum_t max( t_running, t_util_est_ewma ) + +For more detail see: kernel/sched/fair.c:util_est_dequeue() + + +UCLAMP +====== + +It is possible to set effective u_min and u_max clamps on each CFS or RT task; +the runqueue keeps an max aggregate of these clamps for all running tasks. + +For more detail see: include/uapi/linux/sched/types.h + + +Schedutil / DVFS +================ + +Every time the scheduler load tracking is updated (task wakeup, task +migration, time progression) we call out to schedutil to update the hardware +DVFS state. + +The basis is the CPU runqueue's 'running' metric, which per the above it is +the frequency invariant utilization estimate of the CPU. From this we compute +a desired frequency like:: + + max( running, util_est ); if UTIL_EST + u_cfs := { running; otherwise + + clamp( u_cfs + u_rt , u_min, u_max ); if UCLAMP_TASK + u_clamp := { u_cfs + u_rt; otherwise + + u := u_clamp + u_irq + u_dl; [approx. see source for more detail] + + f_des := min( f_max, 1.25 u * f_max ) + +XXX IO-wait: when the update is due to a task wakeup from IO-completion we +boost 'u' above. + +This frequency is then used to select a P-state/OPP or directly munged into a +CPPC style request to the hardware. + +XXX: deadline tasks (Sporadic Task Model) allows us to calculate a hard f_min +required to satisfy the workload. + +Because these callbacks are directly from the scheduler, the DVFS hardware +interaction should be 'fast' and non-blocking. Schedutil supports +rate-limiting DVFS requests for when hardware interaction is slow and +expensive, this reduces effectiveness. + +For more information see: kernel/sched/cpufreq_schedutil.c + + +NOTES +===== + + - On low-load scenarios, where DVFS is most relevant, the 'running' numbers + will closely reflect utilization. + + - In saturated scenarios task movement will cause some transient dips, + suppose we have a CPU saturated with 4 tasks, then when we migrate a task + to an idle CPU, the old CPU will have a 'running' value of 0.75 while the + new CPU will gain 0.25. This is inevitable and time progression will + correct this. XXX do we still guarantee f_max due to no idle-time? + + - Much of the above is about avoiding DVFS dips, and independent DVFS domains + having to re-learn / ramp-up when load shifts. + diff --git a/Documentation/scheduler/schedutil.txt b/Documentation/scheduler/schedutil.txt deleted file mode 100644 index 78f6b91e2291..000000000000 --- a/Documentation/scheduler/schedutil.txt +++ /dev/null @@ -1,169 +0,0 @@ - - -NOTE; all this assumes a linear relation between frequency and work capacity, -we know this is flawed, but it is the best workable approximation. - - -PELT (Per Entity Load Tracking) -------------------------------- - -With PELT we track some metrics across the various scheduler entities, from -individual tasks to task-group slices to CPU runqueues. As the basis for this -we use an Exponentially Weighted Moving Average (EWMA), each period (1024us) -is decayed such that y^32 = 0.5. That is, the most recent 32ms contribute -half, while the rest of history contribute the other half. - -Specifically: - - ewma_sum(u) := u_0 + u_1*y + u_2*y^2 + ... - - ewma(u) = ewma_sum(u) / ewma_sum(1) - -Since this is essentially a progression of an infinite geometric series, the -results are composable, that is ewma(A) + ewma(B) = ewma(A+B). This property -is key, since it gives the ability to recompose the averages when tasks move -around. - -Note that blocked tasks still contribute to the aggregates (task-group slices -and CPU runqueues), which reflects their expected contribution when they -resume running. - -Using this we track 2 key metrics: 'running' and 'runnable'. 'Running' -reflects the time an entity spends on the CPU, while 'runnable' reflects the -time an entity spends on the runqueue. When there is only a single task these -two metrics are the same, but once there is contention for the CPU 'running' -will decrease to reflect the fraction of time each task spends on the CPU -while 'runnable' will increase to reflect the amount of contention. - -For more detail see: kernel/sched/pelt.c - - -Frequency- / CPU Invariance ---------------------------- - -Because consuming the CPU for 50% at 1GHz is not the same as consuming the CPU -for 50% at 2GHz, nor is running 50% on a LITTLE CPU the same as running 50% on -a big CPU, we allow architectures to scale the time delta with two ratios, one -Dynamic Voltage and Frequency Scaling (DVFS) ratio and one microarch ratio. - -For simple DVFS architectures (where software is in full control) we trivially -compute the ratio as: - - f_cur - r_dvfs := ----- - f_max - -For more dynamic systems where the hardware is in control of DVFS we use -hardware counters (Intel APERF/MPERF, ARMv8.4-AMU) to provide us this ratio. -For Intel specifically, we use: - - APERF - f_cur := ----- * P0 - MPERF - - 4C-turbo; if available and turbo enabled - f_max := { 1C-turbo; if turbo enabled - P0; otherwise - - f_cur - r_dvfs := min( 1, ----- ) - f_max - -We pick 4C turbo over 1C turbo to make it slightly more sustainable. - -r_cpu is determined as the ratio of highest performance level of the current -CPU vs the highest performance level of any other CPU in the system. - - r_tot = r_dvfs * r_cpu - -The result is that the above 'running' and 'runnable' metrics become invariant -of DVFS and CPU type. IOW. we can transfer and compare them between CPUs. - -For more detail see: - - - kernel/sched/pelt.h:update_rq_clock_pelt() - - arch/x86/kernel/smpboot.c:"APERF/MPERF frequency ratio computation." - - Documentation/scheduler/sched-capacity.rst:"1. CPU Capacity + 2. Task utilization" - - -UTIL_EST / UTIL_EST_FASTUP --------------------------- - -Because periodic tasks have their averages decayed while they sleep, even -though when running their expected utilization will be the same, they suffer a -(DVFS) ramp-up after they are running again. - -To alleviate this (a default enabled option) UTIL_EST drives an Infinite -Impulse Response (IIR) EWMA with the 'running' value on dequeue -- when it is -highest. A further default enabled option UTIL_EST_FASTUP modifies the IIR -filter to instantly increase and only decay on decrease. - -A further runqueue wide sum (of runnable tasks) is maintained of: - - util_est := \Sum_t max( t_running, t_util_est_ewma ) - -For more detail see: kernel/sched/fair.c:util_est_dequeue() - - -UCLAMP ------- - -It is possible to set effective u_min and u_max clamps on each CFS or RT task; -the runqueue keeps an max aggregate of these clamps for all running tasks. - -For more detail see: include/uapi/linux/sched/types.h - - -Schedutil / DVFS ----------------- - -Every time the scheduler load tracking is updated (task wakeup, task -migration, time progression) we call out to schedutil to update the hardware -DVFS state. - -The basis is the CPU runqueue's 'running' metric, which per the above it is -the frequency invariant utilization estimate of the CPU. From this we compute -a desired frequency like: - - max( running, util_est ); if UTIL_EST - u_cfs := { running; otherwise - - clamp( u_cfs + u_rt , u_min, u_max ); if UCLAMP_TASK - u_clamp := { u_cfs + u_rt; otherwise - - u := u_clamp + u_irq + u_dl; [approx. see source for more detail] - - f_des := min( f_max, 1.25 u * f_max ) - -XXX IO-wait; when the update is due to a task wakeup from IO-completion we -boost 'u' above. - -This frequency is then used to select a P-state/OPP or directly munged into a -CPPC style request to the hardware. - -XXX: deadline tasks (Sporadic Task Model) allows us to calculate a hard f_min -required to satisfy the workload. - -Because these callbacks are directly from the scheduler, the DVFS hardware -interaction should be 'fast' and non-blocking. Schedutil supports -rate-limiting DVFS requests for when hardware interaction is slow and -expensive, this reduces effectiveness. - -For more information see: kernel/sched/cpufreq_schedutil.c - - -NOTES ------ - - - On low-load scenarios, where DVFS is most relevant, the 'running' numbers - will closely reflect utilization. - - - In saturated scenarios task movement will cause some transient dips, - suppose we have a CPU saturated with 4 tasks, then when we migrate a task - to an idle CPU, the old CPU will have a 'running' value of 0.75 while the - new CPU will gain 0.25. This is inevitable and time progression will - correct this. XXX do we still guarantee f_max due to no idle-time? - - - Much of the above is about avoiding DVFS dips, and independent DVFS domains - having to re-learn / ramp-up when load shifts. - -- cgit From c01c2e435db8b62bd67a50e9622d59ca7c7953b7 Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Sat, 12 Mar 2022 15:26:42 +0800 Subject: docs/zh_CN: Add sched-nice-design Chinese translation Translate scheduler/sched-nice-design.rst into Chinese. Signed-off-by: Tang Yizhou Reviewed-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/20220312072642.23118-1-tangyizhou@huawei.com Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/scheduler/index.rst | 2 +- .../zh_CN/scheduler/sched-nice-design.rst | 99 ++++++++++++++++++++++ 2 files changed, 100 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/scheduler/sched-nice-design.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/scheduler/index.rst b/Documentation/translations/zh_CN/scheduler/index.rst index c020f8382785..12bf3bd02ccf 100644 --- a/Documentation/translations/zh_CN/scheduler/index.rst +++ b/Documentation/translations/zh_CN/scheduler/index.rst @@ -25,12 +25,12 @@ Linux调度器 sched-domains sched-capacity sched-energy + sched-nice-design sched-stats TODOList: sched-deadline - sched-nice-design sched-rt-group text_files diff --git a/Documentation/translations/zh_CN/scheduler/sched-nice-design.rst b/Documentation/translations/zh_CN/scheduler/sched-nice-design.rst new file mode 100644 index 000000000000..9107f0c0b979 --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/sched-nice-design.rst @@ -0,0 +1,99 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/sched-nice-design.rst + +:翻译: + + 唐艺舟 Tang Yizhou + +===================== +调度器nice值设计 +===================== + +本文档解释了新的Linux调度器中修改和精简后的nice级别的实现思路。 + +Linux的nice级别总是非常脆弱，人们持续不断地缠着我们，让nice +19的任务占用 +更少的CPU时间。 + +不幸的是，在旧的调度器中，这不是那么容易实现的（否则我们早就做到了），因为对 +nice级别的支持在历史上是与时间片长度耦合的，而时间片单位是由HZ滴答驱动的， +所以最小的时间片是1/HZ。 + +在O(1)调度器中（2003年），我们改变了负的nice级别，使它们比2.4内核更强 +（人们对这一变化很满意），而且我们还故意校正了线性时间片准则，使得nice +19 +的级别 _正好_ 是1 jiffy。为了让大家更好地理解它，时间片的图会是这样的（质量 +不佳的ASCII艺术提醒！）:: + + + A + \ | [timeslice length] + \ | + \ | + \ | + \ | + \|___100msecs + |^ . _ + | ^ . _ + | ^ . _ + -*----------------------------------*-----> [nice level] + -20 | +19 + | + | + +因此，如果有人真的想renice任务，相较线性规则，+19会给出更大的效果（改变 +ABI来扩展优先级的解决方案在早期就被放弃了）。 + +这种方法在一定程度上奏效了一段时间，但后来HZ=1000时，它导致1 jiffy为 +1ms，这意味着0.1%的CPU使用率，我们认为这有点过度。过度 _不是_ 因为它表示 +的CPU使用率过小，而是因为它引发了过于频繁（每毫秒1次）的重新调度（因此会 +破坏缓存，等等。请记住，硬件更弱、cache更小是很久以前的事了，当时人们在 +nice +19级别运行数量颇多的应用程序）。 + +因此，对于HZ=1000，我们将nice +19改为5毫秒，因为这感觉像是正确的最小 +粒度——这相当于5%的CPU利用率。但nice +19的根本的HZ敏感属性依然保持不变， +我们没有收到过关于nice +19在CPU利用率方面太 _弱_ 的任何抱怨，我们只收到 +过它（依然）太 _强_ 的抱怨 :-)。 + +总结一下：我们一直想让nice各级别一致性更强，但在HZ和jiffies的限制下，以及 +nice级别与时间片、调度粒度耦合是令人讨厌的设计，这一目标并不真正可行。 + +第二个关于Linux nice级别支持的抱怨是（不那么频繁，但仍然定期发生），它 +在原点周围的不对称性（你可以在上面的图片中看到），或者更准确地说：事实上 +nice级别的行为取决于 _绝对的_ nice级别，而nice应用程序接口本身从根本上 +说是“相对”的： + + int nice(int inc); + + asmlinkage long sys_nice(int increment) + +（第一个是glibc的应用程序接口，第二个是syscall的应用程序接口） +注意，“inc”是相对当前nice级别而言的，类似bash的“nice”命令等工具是这个 +相对性应用程序接口的镜像。 + +在旧的调度器中，举例来说，如果你以nice +1启动一个任务，并以nice +2启动 +另一个任务，这两个任务的CPU分配将取决于父外壳程序的nice级别——如果它是 +nice -10，那么CPU的分配不同于+5或+10。 + +第三个关于Linux nice级别支持的抱怨是，负数nice级别“不够有力”，以很多人 +不得不诉诸于实时调度优先级来运行音频（和其它多媒体）应用程序，比如 +SCHED_FIFO。但这也造成了其它问题：SCHED_FIFO未被证明是免于饥饿的，一个 +有问题的SCHED_FIFO应用程序也会锁住运行良好的系统。 + +v2.6.23版内核的新调度器解决了这三种类型的抱怨： + +为了解决第一个抱怨（nice级别不够“有力”），调度器与“时间片”、HZ的概念 +解耦（调度粒度被处理成一个和nice级别独立的概念），因此有可能实现更好、 +更一致的nice +19支持：在新的调度器中，nice +19的任务得到一个HZ无关的 +1.5%CPU使用率，而不是旧版调度器中3%-5%-9%的可变范围。 + +为了解决第二个抱怨（nice各级别不一致），新调度器令调用nice(1)对各任务的 +CPU利用率有相同的影响，无论其绝对nice级别如何。所以在新调度器上，运行一个 +nice +10和一个nice +11的任务会与运行一个nice -5和一个nice -4的任务的 +CPU利用率分割是相同的（一个会得到55%的CPU，另一个会得到45%）。这是为什么 +nice级别被改为“乘法”（或指数）——这样的话，不管你从哪个级别开始，“相对” +结果将总是一样的。 + +第三个抱怨（负数nice级别不够“有力”，并迫使音频应用程序在更危险的 +SCHED_FIFO调度策略下运行）几乎被新的调度器自动解决了：更强的负数级别 +具有重新校正nice级别动态范围的自动化副作用。 -- cgit From 75c05fabb873367d9e64f063dda8a310c4c58826 Mon Sep 17 00:00:00 2001 From: Mike Rapoport Date: Thu, 10 Mar 2022 10:27:36 +0200 Subject: docs/kernel-parameters: update description of mem= The existing description of mem= does not cover all the cases and differences between how architectures treat it. Extend the description to match the code. Signed-off-by: Mike Rapoport Link: https://lore.kernel.org/r/20220310082736.1346366-1-rppt@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/kernel-parameters.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index f5a27f067db9..5b84cca62990 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2827,6 +2827,9 @@ For details see: Documentation/admin-guide/hw-vuln/mds.rst + mem=nn[KMG] [HEXAGON] Set the memory size. + Must be specified, otherwise memory size will be 0. + mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory Amount of memory to be used in cases as follows: @@ -2834,6 +2837,13 @@ 2 when the kernel is not able to see the whole system memory; 3 memory that lies after 'mem=' boundary is excluded from the hypervisor, then assigned to KVM guests. + 4 to limit the memory available for kdump kernel. + + [ARC,MICROBLAZE] - the limit applies only to low memory, + high memory is not affected. + + [ARM64] - only limits memory covered by the linear + mapping. The NOMAP regions are not affected. [X86] Work as limiting max address. Use together with memmap= to avoid physical address space collisions. @@ -2844,6 +2854,14 @@ in above case 3, memory may need be hot added after boot if system memory of hypervisor is not sufficient. + mem=nn[KMG]@ss[KMG] + [ARM,MIPS] - override the memory layout reported by + firmware. + Define a memory region of size nn[KMG] starting at + ss[KMG]. + Multiple different regions can be specified with + multiple mem= parameters on the command line. + mem=nopentium [BUGS=X86-32] Disable usage of 4MB pages for kernel memory. -- cgit From aa457ff1b2be72c0d89ee2118769859e513e6fc8 Mon Sep 17 00:00:00 2001 From: Jeffrey Hugo Date: Mon, 7 Mar 2022 08:32:36 -0700 Subject: drm/doc: Clarify what ioctls can be used on render nodes The documentation for render nodes indicates that only "PRIME-related" ioctls are valid on render nodes, but the documentation does not clarify what that means. If the reader is not familiar with PRIME, they may beleive this to be only the ioctls with "PRIME" in the name and not other ioctls such as set of syncobj ioctls. Clarify the situation for the reader by referencing where the reader will find a current list of valid ioctls. Signed-off-by: Jeffrey Hugo Acked-by: Pekka Paalanen Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/1646667156-16366-1-git-send-email-quic_jhugo@quicinc.com --- Documentation/gpu/drm-uapi.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 199afb503ab1..ce47b4292481 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -148,7 +148,9 @@ clients together with the legacy drmAuth authentication procedure. If a driver advertises render node support, DRM core will create a separate render node called renderD. There will be one render node per device. No ioctls except PRIME-related ioctls will be allowed on -this node. Especially GEM_OPEN will be explicitly prohibited. Render +this node. Especially GEM_OPEN will be explicitly prohibited. For a +complete list of driver-independent ioctls that can be used on render +nodes, see the ioctls marked DRM_RENDER_ALLOW in drm_ioctl.c Render nodes are designed to avoid the buffer-leaks, which occur if clients guess the flink names or mmap offsets on the legacy interface. Additionally to this basic interface, drivers must mark their -- cgit From 270a95966881f25c17590e9702860fd1101cfb66 Mon Sep 17 00:00:00 2001 From: Chris Packham Date: Wed, 16 Mar 2022 10:52:06 +1300 Subject: dt-bindings: net: mvneta: Add marvell,armada-ac5-neta The out of band port on the 98DX2530 SoC is similar to the armada-3700 except it requires a slightly different MBUS window configuration. Add a new compatible string so this difference can be accounted for. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Signed-off-by: Paolo Abeni --- Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt index 691f886cfc4a..2bf31572b08d 100644 --- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt +++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt @@ -5,6 +5,7 @@ Required properties: "marvell,armada-370-neta" "marvell,armada-xp-neta" "marvell,armada-3700-neta" + "marvell,armada-ac5-neta" - reg: address and length of the register set for the device. - interrupts: interrupt for the device - phy: See ethernet.txt file in the same directory. -- cgit From dc3d879c6ffa25e90875237265898e49b2cabb7e Mon Sep 17 00:00:00 2001 From: Biju Das Date: Tue, 15 Mar 2022 15:32:58 +0000 Subject: dt-bindings: mmc: renesas,sdhi: Document RZ/G2UL SoC Document RZ/G2UL SDHI bindings. RZ/G2UL SDHI is almost identical to one found on the R-Car Gen3. No driver changes are required as generic compatible string "renesas,rcar-gen3-sdhi" will be used as a fallback. Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Acked-by: Wolfram Sang Link: https://lore.kernel.org/r/20220315153258.21097-1-biju.das.jz@bp.renesas.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml index 3b191fb89cf1..9ac4986988c5 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml @@ -57,6 +57,7 @@ properties: - renesas,sdhi-r8a77990 # R-Car E3 - renesas,sdhi-r8a77995 # R-Car D3 - renesas,sdhi-r8a779a0 # R-Car V3U + - renesas,sdhi-r9a07g043 # RZ/G2UL - renesas,sdhi-r9a07g044 # RZ/G2{L,LC} - renesas,sdhi-r9a07g054 # RZ/V2L - const: renesas,rcar-gen3-sdhi # R-Car Gen3 or RZ/G2 @@ -109,6 +110,7 @@ allOf: compatible: contains: enum: + - renesas,sdhi-r9a07g043 - renesas,sdhi-r9a07g044 - renesas,sdhi-r9a07g054 then: -- cgit From a1108dcd9373a98f7018aa4310076260b8ecfc0b Mon Sep 17 00:00:00 2001 From: David Anderson Date: Thu, 17 Mar 2022 19:49:59 +0800 Subject: erofs: rename ctime to mtime EROFS images should inherit modification time rather than change time, since users and host tooling have no easy way to control change time. To reflect the new timestamp meaning, i_ctime and i_ctime_nsec are renamed to i_mtime and i_mtime_nsec. Link: https://lore.kernel.org/r/20220311041829.3109511-1-dvander@google.com # v1 Signed-off-by: David Anderson [ Gao Xiang: update document as well. ] Reviewed-by: Chao Yu Link: https://lore.kernel.org/r/20220317114959.106787-1-hsiangkao@linux.alibaba.com # v2 Signed-off-by: Gao Xiang --- Documentation/filesystems/erofs.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst index 7119aa213be7..bef6d3040ce4 100644 --- a/Documentation/filesystems/erofs.rst +++ b/Documentation/filesystems/erofs.rst @@ -40,7 +40,7 @@ Here is the main features of EROFS: Inode metadata size 32 bytes 64 bytes Max file size 4 GB 16 EB (also limited by max. vol size) Max uids/gids 65536 4294967296 - File change time no yes (64 + 32-bit timestamp) + Per-inode timestamp no yes (64 + 32-bit timestamp) Max hardlinks 65536 4294967296 Metadata reserved 4 bytes 14 bytes ===================== ============ ===================================== -- cgit From f621eb13facb7681a79f4fec8ec6553ae160da76 Mon Sep 17 00:00:00 2001 From: Alex Williamson Date: Tue, 15 Mar 2022 11:29:57 -0600 Subject: vfio-pci: Provide reviewers and acceptance criteria for variant drivers Device specific extensions for devices exposed to userspace through the vfio-pci-core library open both new functionality and new risks. Here we attempt to provided formalized requirements and expectations to ensure that future drivers both collaborate in their interaction with existing host drivers, as well as receive additional reviews from community members with experience in this area. Acked-by: Shameer Kolothum Reviewed-by: Yishai Hadas Acked-by: Kevin Tian Reviewed-by: Cornelia Huck Acked-by: Jason Gunthorpe Link: https://lore.kernel.org/r/164736509088.181560.2887686123582116702.stgit@omen Signed-off-by: Alex Williamson --- Documentation/driver-api/index.rst | 1 + .../vfio-pci-device-specific-driver-acceptance.rst | 35 ++++++++++++++++++++++ .../maintainer/maintainer-entry-profile.rst | 1 + 3 files changed, 37 insertions(+) create mode 100644 Documentation/driver-api/vfio-pci-device-specific-driver-acceptance.rst (limited to 'Documentation') diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index c57c609ad2eb..a7b0223e2886 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -103,6 +103,7 @@ available subsections can be seen below. sync_file vfio-mediated-device vfio + vfio-pci-device-specific-driver-acceptance xilinx/index xillybus zorro diff --git a/Documentation/driver-api/vfio-pci-device-specific-driver-acceptance.rst b/Documentation/driver-api/vfio-pci-device-specific-driver-acceptance.rst new file mode 100644 index 000000000000..b7b99b876b50 --- /dev/null +++ b/Documentation/driver-api/vfio-pci-device-specific-driver-acceptance.rst @@ -0,0 +1,35 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Acceptance criteria for vfio-pci device specific driver variants +================================================================ + +Overview +-------- +The vfio-pci driver exists as a device agnostic driver using the +system IOMMU and relying on the robustness of platform fault +handling to provide isolated device access to userspace. While the +vfio-pci driver does include some device specific support, further +extensions for yet more advanced device specific features are not +sustainable. The vfio-pci driver has therefore split out +vfio-pci-core as a library that may be reused to implement features +requiring device specific knowledge, ex. saving and loading device +state for the purposes of supporting migration. + +In support of such features, it's expected that some device specific +variants may interact with parent devices (ex. SR-IOV PF in support of +a user assigned VF) or other extensions that may not be otherwise +accessible via the vfio-pci base driver. Authors of such drivers +should be diligent not to create exploitable interfaces via these +interactions or allow unchecked userspace data to have an effect +beyond the scope of the assigned device. + +New driver submissions are therefore requested to have approval via +sign-off/ack/review/etc for any interactions with parent drivers. +Additionally, drivers should make an attempt to provide sufficient +documentation for reviewers to understand the device specific +extensions, for example in the case of migration data, how is the +device state composed and consumed, which portions are not otherwise +available to the user via vfio-pci, what safeguards exist to validate +the data, etc. To that extent, authors should additionally expect to +require reviews from at least one of the listed reviewers, in addition +to the overall vfio maintainer. diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst index 5d5cc3acdf85..93b2ae6c34a9 100644 --- a/Documentation/maintainer/maintainer-entry-profile.rst +++ b/Documentation/maintainer/maintainer-entry-profile.rst @@ -103,3 +103,4 @@ to do something different in the near future. ../nvdimm/maintainer-entry-profile ../riscv/patch-acceptance ../driver-api/media/maintainer-entry-profile + ../driver-api/vfio-pci-device-specific-driver-acceptance -- cgit From d98af5f4552058a5c22030641ef79cee92c61f54 Mon Sep 17 00:00:00 2001 From: Daeho Jeong Date: Tue, 15 Mar 2022 21:14:14 -0700 Subject: f2fs: introduce gc_urgent_mid mode We need a mid level of gc urgent mode to do GC forcibly in a period of given gc_urgent_sleep_time, but not like using greedy GC approach and switching to SSR mode such as gc urgent high mode. This can be used for more aggressive periodic storage clean up. Signed-off-by: Daeho Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/ABI/testing/sysfs-fs-f2fs | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 5a5f3c5445f6..9b583dd0298b 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -297,11 +297,16 @@ Description: Shows current reserved blocks in system, it may be temporarily What: /sys/fs/f2fs//gc_urgent Date: August 2017 Contact: "Jaegeuk Kim" -Description: Do background GC aggressively when set. When gc_urgent = 1, - background thread starts to do GC by given gc_urgent_sleep_time - interval. When gc_urgent = 2, F2FS will lower the bar of - checking idle in order to process outstanding discard commands - and GC a little bit aggressively. It is set to 0 by default. +Description: Do background GC aggressively when set. Set to 0 by default. + gc urgent high(1): does GC forcibly in a period of given + gc_urgent_sleep_time and ignores I/O idling check. uses greedy + GC approach and turns SSR mode on. + gc urgent low(2): lowers the bar of checking I/O idling in + order to process outstanding discard commands and GC a + little bit aggressively. uses cost benefit GC approach. + gc urgent mid(3): does GC forcibly in a period of given + gc_urgent_sleep_time and executes a mid level of I/O idling check. + uses cost benefit GC approach. What: /sys/fs/f2fs//gc_urgent_sleep_time Date: August 2017 @@ -532,7 +537,7 @@ Date: July 2021 Contact: "Daeho Jeong" Description: Show how many segments have been reclaimed by GC during a specific GC mode (0: GC normal, 1: GC idle CB, 2: GC idle greedy, - 3: GC idle AT, 4: GC urgent high, 5: GC urgent low) + 3: GC idle AT, 4: GC urgent high, 5: GC urgent low 6: GC urgent mid) You can re-initialize this value to "0". What: /sys/fs/f2fs//gc_segment_mode -- cgit From daa83f744a31ca1c4f6cde7c4fcae0c89aa2dadc Mon Sep 17 00:00:00 2001 From: Christophe Branchereau Date: Fri, 11 Mar 2022 18:02:40 +0100 Subject: dt-bindings: display/panel: Add Leadtek ltk035c5444t Add binding for the leadtek ltk035c5444t, which is a 640x480 mipi-dbi over spi / 24-bit RGB panel based on the newvision NV03052C chipset. It is found in the Anbernic RG350M mips handheld. Signed-off-by: Christophe Branchereau Signed-off-by: Paul Cercueil Reviewed-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20220311170240.173846-5-cbranchereau@gmail.com --- .../display/panel/leadtek,ltk035c5444t.yaml | 59 ++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml new file mode 100644 index 000000000000..817a9bed7d5a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/leadtek,ltk035c5444t.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Leadtek ltk035c5444t 3.5" (640x480 pixels) 24-bit IPS LCD panel + +maintainers: + - Paul Cercueil + - Christophe Branchereau + +allOf: + - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +properties: + compatible: + const: leadtek,ltk035c5444t + + backlight: true + port: true + power-supply: true + reg: true + reset-gpios: true + +required: + - compatible + - power-supply + - reset-gpios + +unevaluatedProperties: false + +examples: + - | + #include + + spi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "leadtek,ltk035c5444t"; + reg = <0>; + + spi-3wire; + spi-max-frequency = <3125000>; + + reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>; + + backlight = <&backlight>; + power-supply = <&vcc>; + + port { + panel_input: endpoint { + remote-endpoint = <&panel_output>; + }; + }; + }; + }; -- cgit From aba09b44a985f963f3ce22132694161f79e18984 Mon Sep 17 00:00:00 2001 From: Masami Hiramatsu Date: Tue, 15 Mar 2022 23:02:22 +0900 Subject: docs: fprobe: Add fprobe description to ftrace-use.rst Add a documentation of fprobe for the user who needs this interface. Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (Google) Tested-by: Steven Rostedt (Google) Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/164735294272.1084943.12372175959382037397.stgit@devnote2 --- Documentation/trace/fprobe.rst | 174 +++++++++++++++++++++++++++++++++++++++++ Documentation/trace/index.rst | 1 + 2 files changed, 175 insertions(+) create mode 100644 Documentation/trace/fprobe.rst (limited to 'Documentation') diff --git a/Documentation/trace/fprobe.rst b/Documentation/trace/fprobe.rst new file mode 100644 index 000000000000..b64bec1ce144 --- /dev/null +++ b/Documentation/trace/fprobe.rst @@ -0,0 +1,174 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================== +Fprobe - Function entry/exit probe +================================== + +.. Author: Masami Hiramatsu + +Introduction +============ + +Fprobe is a function entry/exit probe mechanism based on ftrace. +Instead of using ftrace full feature, if you only want to attach callbacks +on function entry and exit, similar to the kprobes and kretprobes, you can +use fprobe. Compared with kprobes and kretprobes, fprobe gives faster +instrumentation for multiple functions with single handler. This document +describes how to use fprobe. + +The usage of fprobe +=================== + +The fprobe is a wrapper of ftrace (+ kretprobe-like return callback) to +attach callbacks to multiple function entry and exit. User needs to set up +the `struct fprobe` and pass it to `register_fprobe()`. + +Typically, `fprobe` data structure is initialized with the `entry_handler` +and/or `exit_handler` as below. + +.. code-block:: c + + struct fprobe fp = { + .entry_handler = my_entry_callback, + .exit_handler = my_exit_callback, + }; + +To enable the fprobe, call one of register_fprobe(), register_fprobe_ips(), and +register_fprobe_syms(). These functions register the fprobe with different types +of parameters. + +The register_fprobe() enables a fprobe by function-name filters. +E.g. this enables @fp on "func*()" function except "func2()".:: + + register_fprobe(&fp, "func*", "func2"); + +The register_fprobe_ips() enables a fprobe by ftrace-location addresses. +E.g. + +.. code-block:: c + + unsigned long ips[] = { 0x.... }; + + register_fprobe_ips(&fp, ips, ARRAY_SIZE(ips)); + +And the register_fprobe_syms() enables a fprobe by symbol names. +E.g. + +.. code-block:: c + + char syms[] = {"func1", "func2", "func3"}; + + register_fprobe_syms(&fp, syms, ARRAY_SIZE(syms)); + +To disable (remove from functions) this fprobe, call:: + + unregister_fprobe(&fp); + +You can temporally (soft) disable the fprobe by:: + + disable_fprobe(&fp); + +and resume by:: + + enable_fprobe(&fp); + +The above is defined by including the header:: + + #include + +Same as ftrace, the registered callbacks will start being called some time +after the register_fprobe() is called and before it returns. See +:file:`Documentation/trace/ftrace.rst`. + +Also, the unregister_fprobe() will guarantee that the both enter and exit +handlers are no longer being called by functions after unregister_fprobe() +returns as same as unregister_ftrace_function(). + +The fprobe entry/exit handler +============================= + +The prototype of the entry/exit callback function is as follows: + +.. code-block:: c + + void callback_func(struct fprobe *fp, unsigned long entry_ip, struct pt_regs *regs); + +Note that both entry and exit callbacks have same ptototype. The @entry_ip is +saved at function entry and passed to exit handler. + +@fp + This is the address of `fprobe` data structure related to this handler. + You can embed the `fprobe` to your data structure and get it by + container_of() macro from @fp. The @fp must not be NULL. + +@entry_ip + This is the ftrace address of the traced function (both entry and exit). + Note that this may not be the actual entry address of the function but + the address where the ftrace is instrumented. + +@regs + This is the `pt_regs` data structure at the entry and exit. Note that + the instruction pointer of @regs may be different from the @entry_ip + in the entry_handler. If you need traced instruction pointer, you need + to use @entry_ip. On the other hand, in the exit_handler, the instruction + pointer of @regs is set to the currect return address. + +Share the callbacks with kprobes +================================ + +Since the recursion safeness of the fprobe (and ftrace) is a bit different +from the kprobes, this may cause an issue if user wants to run the same +code from the fprobe and the kprobes. + +Kprobes has per-cpu 'current_kprobe' variable which protects the kprobe +handler from recursion in all cases. On the other hand, fprobe uses +only ftrace_test_recursion_trylock(). This allows interrupt context to +call another (or same) fprobe while the fprobe user handler is running. + +This is not a matter if the common callback code has its own recursion +detection, or it can handle the recursion in the different contexts +(normal/interrupt/NMI.) +But if it relies on the 'current_kprobe' recursion lock, it has to check +kprobe_running() and use kprobe_busy_*() APIs. + +Fprobe has FPROBE_FL_KPROBE_SHARED flag to do this. If your common callback +code will be shared with kprobes, please set FPROBE_FL_KPROBE_SHARED +*before* registering the fprobe, like: + +.. code-block:: c + + fprobe.flags = FPROBE_FL_KPROBE_SHARED; + + register_fprobe(&fprobe, "func*", NULL); + +This will protect your common callback from the nested call. + +The missed counter +================== + +The `fprobe` data structure has `fprobe::nmissed` counter field as same as +kprobes. +This counter counts up when; + + - fprobe fails to take ftrace_recursion lock. This usually means that a function + which is traced by other ftrace users is called from the entry_handler. + + - fprobe fails to setup the function exit because of the shortage of rethook + (the shadow stack for hooking the function return.) + +The `fprobe::nmissed` field counts up in both cases. Therefore, the former +skips both of entry and exit callback and the latter skips the exit +callback, but in both case the counter will increase by 1. + +Note that if you set the FTRACE_OPS_FL_RECURSION and/or FTRACE_OPS_FL_RCU to +`fprobe::ops::flags` (ftrace_ops::flags) when registering the fprobe, this +counter may not work correctly, because ftrace skips the fprobe function which +increase the counter. + + +Functions and structures +======================== + +.. kernel-doc:: include/linux/fprobe.h +.. kernel-doc:: kernel/trace/fprobe.c + diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst index 3769b9b7aed8..b9f3757f8269 100644 --- a/Documentation/trace/index.rst +++ b/Documentation/trace/index.rst @@ -9,6 +9,7 @@ Linux Tracing Technologies tracepoint-analysis ftrace ftrace-uses + fprobe kprobes kprobetrace uprobetracer -- cgit From 238c84f71120f41c45301359902a912a19370f3d Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sun, 13 Mar 2022 11:18:16 +0100 Subject: media: platform: rename exynos4-is/ to samsung/exynos4-is/ As the end goal is to have platform drivers split by vendor, rename exynos4-is/ to samsung/exynos4-is/. Signed-off-by: Mauro Carvalho Chehab --- Documentation/admin-guide/media/fimc.rst | 2 +- Documentation/driver-api/media/drivers/fimc-devel.rst | 14 +++++++------- 2 files changed, 8 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/media/fimc.rst b/Documentation/admin-guide/media/fimc.rst index 56b149d9a527..267ef52fe387 100644 --- a/Documentation/admin-guide/media/fimc.rst +++ b/Documentation/admin-guide/media/fimc.rst @@ -14,7 +14,7 @@ data from LCD controller (FIMD) through the SoC internal writeback data path. There are multiple FIMC instances in the SoCs (up to 4), having slightly different capabilities, like pixel alignment constraints, rotator availability, LCD writeback support, etc. The driver is located at -drivers/media/platform/exynos4-is directory. +drivers/media/platform/samsung/exynos4-is directory. Supported SoCs -------------- diff --git a/Documentation/driver-api/media/drivers/fimc-devel.rst b/Documentation/driver-api/media/drivers/fimc-devel.rst index 956e3a9901f8..4c6b7c8be19f 100644 --- a/Documentation/driver-api/media/drivers/fimc-devel.rst +++ b/Documentation/driver-api/media/drivers/fimc-devel.rst @@ -12,22 +12,22 @@ Files partitioning - media device driver - drivers/media/platform/exynos4-is/media-dev.[ch] + drivers/media/platform/samsung/exynos4-is/media-dev.[ch] - camera capture video device driver - drivers/media/platform/exynos4-is/fimc-capture.c + drivers/media/platform/samsung/exynos4-is/fimc-capture.c - MIPI-CSI2 receiver subdev - drivers/media/platform/exynos4-is/mipi-csis.[ch] + drivers/media/platform/samsung/exynos4-is/mipi-csis.[ch] - video post-processor (mem-to-mem) - drivers/media/platform/exynos4-is/fimc-core.c + drivers/media/platform/samsung/exynos4-is/fimc-core.c - common files - drivers/media/platform/exynos4-is/fimc-core.h - drivers/media/platform/exynos4-is/fimc-reg.h - drivers/media/platform/exynos4-is/regs-fimc.h + drivers/media/platform/samsung/exynos4-is/fimc-core.h + drivers/media/platform/samsung/exynos4-is/fimc-reg.h + drivers/media/platform/samsung/exynos4-is/regs-fimc.h -- cgit From d24a170bde6543fa2879d3c422b7874716cdf038 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sun, 13 Mar 2022 11:18:19 +0100 Subject: media: platform: rename davinci/ to ti/davinci/ As the end goal is to have platform drivers split by vendor, rename davinci/ to ti/davinci/. Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab --- .../driver-api/media/drivers/davinci-vpbe-devel.rst | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst b/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst index f0961672e6a3..4e87bdbc7ae4 100644 --- a/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst +++ b/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst @@ -7,22 +7,22 @@ File partitioning ----------------- V4L2 display device driver - drivers/media/platform/davinci/vpbe_display.c - drivers/media/platform/davinci/vpbe_display.h + drivers/media/platform/ti/davinci/vpbe_display.c + drivers/media/platform/ti/davinci/vpbe_display.h VPBE display controller - drivers/media/platform/davinci/vpbe.c - drivers/media/platform/davinci/vpbe.h + drivers/media/platform/ti/davinci/vpbe.c + drivers/media/platform/ti/davinci/vpbe.h VPBE venc sub device driver - drivers/media/platform/davinci/vpbe_venc.c - drivers/media/platform/davinci/vpbe_venc.h - drivers/media/platform/davinci/vpbe_venc_regs.h + drivers/media/platform/ti/davinci/vpbe_venc.c + drivers/media/platform/ti/davinci/vpbe_venc.h + drivers/media/platform/ti/davinci/vpbe_venc_regs.h VPBE osd driver - drivers/media/platform/davinci/vpbe_osd.c - drivers/media/platform/davinci/vpbe_osd.h - drivers/media/platform/davinci/vpbe_osd_regs.h + drivers/media/platform/ti/davinci/vpbe_osd.c + drivers/media/platform/ti/davinci/vpbe_osd.h + drivers/media/platform/ti/davinci/vpbe_osd_regs.h To be done ---------- -- cgit From ceafdaac46ea2c623a64eabaed64abd2fe7cb76f Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sun, 13 Mar 2022 11:18:20 +0100 Subject: media: platform: rename omap3isp/ to ti/omap3isp/ As the end goal is to have platform drivers split by vendor, rename omap3isp/ to ti/omap3isp/. Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab --- Documentation/admin-guide/media/omap3isp.rst | 2 +- Documentation/admin-guide/media/omap4_camera.rst | 2 +- Documentation/driver-api/media/v4l2-event.rst | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/media/omap3isp.rst b/Documentation/admin-guide/media/omap3isp.rst index bc447bbec7ce..f32e7375a1a2 100644 --- a/Documentation/admin-guide/media/omap3isp.rst +++ b/Documentation/admin-guide/media/omap3isp.rst @@ -17,7 +17,7 @@ Introduction ------------ This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP) -driver located under drivers/media/platform/omap3isp. The original driver was +driver located under drivers/media/platform/ti/omap3isp. The original driver was written by Texas Instruments but since that it has been rewritten (twice) at Nokia. diff --git a/Documentation/admin-guide/media/omap4_camera.rst b/Documentation/admin-guide/media/omap4_camera.rst index 24db4222d36d..2ada9b1e6897 100644 --- a/Documentation/admin-guide/media/omap4_camera.rst +++ b/Documentation/admin-guide/media/omap4_camera.rst @@ -25,7 +25,7 @@ As of Revision AB, the ISS is described in detail in section 8. This driver is supporting **only** the CSI2-A/B interfaces for now. It makes use of the Media Controller framework [#f2]_, and inherited most of the -code from OMAP3 ISP driver (found under drivers/media/platform/omap3isp/\*), +code from OMAP3 ISP driver (found under drivers/media/platform/ti/omap3isp/\*), except that it doesn't need an IOMMU now for ISS buffers memory mapping. Supports usage of MMAP buffers only (for now). diff --git a/Documentation/driver-api/media/v4l2-event.rst b/Documentation/driver-api/media/v4l2-event.rst index 5b8254eba7da..52d4fbc5d819 100644 --- a/Documentation/driver-api/media/v4l2-event.rst +++ b/Documentation/driver-api/media/v4l2-event.rst @@ -167,7 +167,7 @@ The first event type in the class is reserved for future use, so the first available event type is 'class base + 1'. An example on how the V4L2 events may be used can be found in the OMAP -3 ISP driver (``drivers/media/platform/omap3isp``). +3 ISP driver (``drivers/media/platform/ti/omap3isp``). A subdev can directly send an event to the :c:type:`v4l2_device` notify function with ``V4L2_DEVICE_NOTIFY_EVENT``. This allows the bridge to map -- cgit From f1b7d5ffc257915d0baf58aa8515cf3f70c93c77 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Tue, 8 Mar 2022 09:25:56 +0100 Subject: media: pixfmt-yuv-planar.rst: fix PIX_FMT labels Two labels used _ instead of - so were never found and one new PIX_FMT was missing the label altogether. This led to these warnings: Documentation/output/videodev2.h.rst:6: WARNING: undefined label: v4l2-pix-fmt-nv12m-8l128 Documentation/output/videodev2.h.rst:6: WARNING: undefined label: v4l2-pix-fmt-nv12m-10be-8l128 Documentation/output/videodev2.h.rst:6: WARNING: undefined label: v4l2-pix-fmt-mm21 Signed-off-by: Hans Verkuil Fixes: 72a74c8f0a0d ("media: add nv12m_8l128 and nv12m_10be_8l128 video format.") Reported-by: Stephen Rothwell Acked-by: Nicolas Dufresne Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst index cc3e4b5791c5..8dff5906639b 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst @@ -257,8 +257,9 @@ of the luma plane. .. _V4L2-PIX-FMT-NV12-4L4: .. _V4L2-PIX-FMT-NV12-16L16: .. _V4L2-PIX-FMT-NV12-32L32: -.. _V4L2_PIX_FMT_NV12M_8L128: -.. _V4L2_PIX_FMT_NV12M_10BE_8L128: +.. _V4L2-PIX-FMT-NV12M-8L128: +.. _V4L2-PIX-FMT-NV12M-10BE-8L128: +.. _V4L2-PIX-FMT-MM21: Tiled NV12 ---------- -- cgit From 6a19114b8e7f1e24d80b0812e26d78d7ae1ec6dd Mon Sep 17 00:00:00 2001 From: David Howells Date: Thu, 17 Feb 2022 10:01:23 +0000 Subject: netfs: Rename netfs_read_*request to netfs_io_*request Rename netfs_read_*request to netfs_io_*request so that the same structures can be used for the write helpers too. perl -p -i -e 's/netfs_read_(request|subrequest)/netfs_io_$1/g' \ `git grep -l 'netfs_read_\(sub\|\)request'` perl -p -i -e 's/nr_rd_ops/nr_outstanding/g' \ `git grep -l nr_rd_ops` perl -p -i -e 's/nr_wr_ops/nr_copy_ops/g' \ `git grep -l nr_wr_ops` perl -p -i -e 's/netfs_read_source/netfs_io_source/g' \ `git grep -l 'netfs_read_source'` perl -p -i -e 's/netfs_io_request_ops/netfs_request_ops/g' \ `git grep -l 'netfs_io_request_ops'` perl -p -i -e 's/init_rreq/init_request/g' \ `git grep -l 'init_rreq'` Signed-off-by: David Howells Reviewed-by: Jeff Layton cc: linux-cachefs@redhat.com Link: https://lore.kernel.org/r/164622988070.3564931.7089670190434315183.stgit@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/164678195157.1200972.366609966927368090.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/164692891535.2099075.18435198075367420588.stgit@warthog.procyon.org.uk/ # v3 --- Documentation/filesystems/netfs_library.rst | 40 ++++++++++++++--------------- 1 file changed, 20 insertions(+), 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index 4f373a8ec47b..a997e2d4321d 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -71,11 +71,11 @@ Read Helper Functions Three read helpers are provided:: void netfs_readahead(struct readahead_control *ractl, - const struct netfs_read_request_ops *ops, + const struct netfs_request_ops *ops, void *netfs_priv); int netfs_readpage(struct file *file, struct folio *folio, - const struct netfs_read_request_ops *ops, + const struct netfs_request_ops *ops, void *netfs_priv); int netfs_write_begin(struct file *file, struct address_space *mapping, @@ -84,7 +84,7 @@ Three read helpers are provided:: unsigned int flags, struct folio **_folio, void **_fsdata, - const struct netfs_read_request_ops *ops, + const struct netfs_request_ops *ops, void *netfs_priv); Each corresponds to a VM operation, with the addition of a couple of parameters @@ -116,7 +116,7 @@ occurs, the request will get partially completed if sufficient data is read. Additionally, there is:: - * void netfs_subreq_terminated(struct netfs_read_subrequest *subreq, + * void netfs_subreq_terminated(struct netfs_io_subrequest *subreq, ssize_t transferred_or_error, bool was_async); @@ -132,7 +132,7 @@ Read Helper Structures The read helpers make use of a couple of structures to maintain the state of the read. The first is a structure that manages a read request as a whole:: - struct netfs_read_request { + struct netfs_io_request { struct inode *inode; struct address_space *mapping; struct netfs_cache_resources cache_resources; @@ -140,7 +140,7 @@ the read. The first is a structure that manages a read request as a whole:: loff_t start; size_t len; loff_t i_size; - const struct netfs_read_request_ops *netfs_ops; + const struct netfs_request_ops *netfs_ops; unsigned int debug_id; ... }; @@ -187,8 +187,8 @@ The above fields are the ones the netfs can use. They are: The second structure is used to manage individual slices of the overall read request:: - struct netfs_read_subrequest { - struct netfs_read_request *rreq; + struct netfs_io_subrequest { + struct netfs_io_request *rreq; loff_t start; size_t len; size_t transferred; @@ -244,23 +244,23 @@ Read Helper Operations The network filesystem must provide the read helpers with a table of operations through which it can issue requests and negotiate:: - struct netfs_read_request_ops { - void (*init_rreq)(struct netfs_read_request *rreq, struct file *file); + struct netfs_request_ops { + void (*init_request)(struct netfs_io_request *rreq, struct file *file); bool (*is_cache_enabled)(struct inode *inode); - int (*begin_cache_operation)(struct netfs_read_request *rreq); - void (*expand_readahead)(struct netfs_read_request *rreq); - bool (*clamp_length)(struct netfs_read_subrequest *subreq); - void (*issue_op)(struct netfs_read_subrequest *subreq); - bool (*is_still_valid)(struct netfs_read_request *rreq); + int (*begin_cache_operation)(struct netfs_io_request *rreq); + void (*expand_readahead)(struct netfs_io_request *rreq); + bool (*clamp_length)(struct netfs_io_subrequest *subreq); + void (*issue_op)(struct netfs_io_subrequest *subreq); + bool (*is_still_valid)(struct netfs_io_request *rreq); int (*check_write_begin)(struct file *file, loff_t pos, unsigned len, struct folio *folio, void **_fsdata); - void (*done)(struct netfs_read_request *rreq); + void (*done)(struct netfs_io_request *rreq); void (*cleanup)(struct address_space *mapping, void *netfs_priv); }; The operations are as follows: - * ``init_rreq()`` + * ``init_request()`` [Optional] This is called to initialise the request structure. It is given the file for reference and can modify the ->netfs_priv value. @@ -420,12 +420,12 @@ The network filesystem's ->begin_cache_operation() method is called to set up a cache and this must call into the cache to do the work. If using fscache, for example, the cache would call:: - int fscache_begin_read_operation(struct netfs_read_request *rreq, + int fscache_begin_read_operation(struct netfs_io_request *rreq, struct fscache_cookie *cookie); passing in the request pointer and the cookie corresponding to the file. -The netfs_read_request object contains a place for the cache to hang its +The netfs_io_request object contains a place for the cache to hang its state:: struct netfs_cache_resources { @@ -443,7 +443,7 @@ operation table looks like the following:: void (*expand_readahead)(struct netfs_cache_resources *cres, loff_t *_start, size_t *_len, loff_t i_size); - enum netfs_read_source (*prepare_read)(struct netfs_read_subrequest *subreq, + enum netfs_io_source (*prepare_read)(struct netfs_io_subrequest *subreq, loff_t i_size); int (*read)(struct netfs_cache_resources *cres, -- cgit From f18a378580a761c8559b7d90afaa157269559c05 Mon Sep 17 00:00:00 2001 From: David Howells Date: Thu, 17 Feb 2022 10:14:32 +0000 Subject: netfs: Finish off rename of netfs_read_request to netfs_io_request Adjust helper function names and comments after mass rename of struct netfs_read_*request to struct netfs_io_*request. Changes ======= ver #2) - Make the changes in the docs also. Signed-off-by: David Howells Reviewed-by: Jeff Layton cc: linux-cachefs@redhat.com Link: https://lore.kernel.org/r/164622992433.3564931.6684311087845150271.stgit@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/164678196111.1200972.5001114956865989528.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/164692892567.2099075.13895804222087028813.stgit@warthog.procyon.org.uk/ # v3 --- Documentation/filesystems/netfs_library.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index a997e2d4321d..4eb7e7b7b0fc 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -250,7 +250,7 @@ through which it can issue requests and negotiate:: int (*begin_cache_operation)(struct netfs_io_request *rreq); void (*expand_readahead)(struct netfs_io_request *rreq); bool (*clamp_length)(struct netfs_io_subrequest *subreq); - void (*issue_op)(struct netfs_io_subrequest *subreq); + void (*issue_read)(struct netfs_io_subrequest *subreq); bool (*is_still_valid)(struct netfs_io_request *rreq); int (*check_write_begin)(struct file *file, loff_t pos, unsigned len, struct folio *folio, void **_fsdata); @@ -305,7 +305,7 @@ The operations are as follows: This should return 0 on success and an error code on error. - * ``issue_op()`` + * ``issue_read()`` [Required] The helpers use this to dispatch a subrequest to the server for reading. In the subrequest, ->start, ->len and ->transferred indicate what -- cgit From bc899ee1c898e520574ff4d99356eb2e724a9265 Mon Sep 17 00:00:00 2001 From: David Howells Date: Tue, 29 Jun 2021 22:37:05 +0100 Subject: netfs: Add a netfs inode context Add a netfs_i_context struct that should be included in the network filesystem's own inode struct wrapper, directly after the VFS's inode struct, e.g.: struct my_inode { struct { /* These must be contiguous */ struct inode vfs_inode; struct netfs_i_context netfs_ctx; }; }; The netfs_i_context struct so far contains a single field for the network filesystem to use - the cache cookie: struct netfs_i_context { ... struct fscache_cookie *cache; }; Three functions are provided to help with this: (1) void netfs_i_context_init(struct inode *inode, const struct netfs_request_ops *ops); Initialise the netfs context and set the operations. (2) struct netfs_i_context *netfs_i_context(struct inode *inode); Find the netfs context from the VFS inode. (3) struct inode *netfs_inode(struct netfs_i_context *ctx); Find the VFS inode from the netfs context. Changes ======= ver #4) - Fix netfs_is_cache_enabled() to check cookie->cache_priv to see if a cache is present[3]. - Fix netfs_skip_folio_read() to zero out all of the page, not just some of it[3]. ver #3) - Split out the bit to move ceph cap-getting on readahead into ceph_init_request()[1]. - Stick in a comment to the netfs inode structs indicating the contiguity requirements[2]. ver #2) - Adjust documentation to match. - Use "#if IS_ENABLED()" in netfs_i_cookie(), not "#ifdef". - Move the cap check from ceph_readahead() to ceph_init_request() to be called from netfslib. - Remove ceph_readahead() and use netfs_readahead() directly instead. Signed-off-by: David Howells Acked-by: Jeff Layton cc: linux-cachefs@redhat.com Link: https://lore.kernel.org/r/8af0d47f17d89c06bbf602496dd845f2b0bf25b3.camel@kernel.org/ [1] Link: https://lore.kernel.org/r/beaf4f6a6c2575ed489adb14b257253c868f9a5c.camel@kernel.org/ [2] Link: https://lore.kernel.org/r/3536452.1647421585@warthog.procyon.org.uk/ [3] Link: https://lore.kernel.org/r/164622984545.3564931.15691742939278418580.stgit@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/164678213320.1200972.16807551936267647470.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/164692909854.2099075.9535537286264248057.stgit@warthog.procyon.org.uk/ # v3 Link: https://lore.kernel.org/r/306388.1647595110@warthog.procyon.org.uk/ # v4 --- Documentation/filesystems/netfs_library.rst | 101 ++++++++++++++++++++-------- 1 file changed, 72 insertions(+), 29 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index 4eb7e7b7b0fc..9c8bc5666b46 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -7,6 +7,8 @@ Network Filesystem Helper Library .. Contents: - Overview. + - Per-inode context. + - Inode context helper functions. - Buffered read helpers. - Read helper functions. - Read helper structures. @@ -28,6 +30,69 @@ Note that the library module doesn't link against local caching directly, so access must be provided by the netfs. +Per-Inode Context +================= + +The network filesystem helper library needs a place to store a bit of state for +its use on each netfs inode it is helping to manage. To this end, a context +structure is defined:: + + struct netfs_i_context { + const struct netfs_request_ops *ops; + struct fscache_cookie *cache; + }; + +A network filesystem that wants to use netfs lib must place one of these +directly after the VFS ``struct inode`` it allocates, usually as part of its +own struct. This can be done in a way similar to the following:: + + struct my_inode { + struct { + /* These must be contiguous */ + struct inode vfs_inode; + struct netfs_i_context netfs_ctx; + }; + ... + }; + +This allows netfslib to find its state by simple offset from the inode pointer, +thereby allowing the netfslib helper functions to be pointed to directly by the +VFS/VM operation tables. + +The structure contains the following fields: + + * ``ops`` + + The set of operations provided by the network filesystem to netfslib. + + * ``cache`` + + Local caching cookie, or NULL if no caching is enabled. This field does not + exist if fscache is disabled. + + +Inode Context Helper Functions +------------------------------ + +To help deal with the per-inode context, a number helper functions are +provided. Firstly, a function to perform basic initialisation on a context and +set the operations table pointer:: + + void netfs_i_context_init(struct inode *inode, + const struct netfs_request_ops *ops); + +then two functions to cast between the VFS inode structure and the netfs +context:: + + struct netfs_i_context *netfs_i_context(struct inode *inode); + struct inode *netfs_inode(struct netfs_i_context *ctx); + +and finally, a function to get the cache cookie pointer from the context +attached to an inode (or NULL if fscache is disabled):: + + struct fscache_cookie *netfs_i_cookie(struct inode *inode); + + Buffered Read Helpers ===================== @@ -70,38 +135,22 @@ Read Helper Functions Three read helpers are provided:: - void netfs_readahead(struct readahead_control *ractl, - const struct netfs_request_ops *ops, - void *netfs_priv); + void netfs_readahead(struct readahead_control *ractl); int netfs_readpage(struct file *file, - struct folio *folio, - const struct netfs_request_ops *ops, - void *netfs_priv); + struct page *page); int netfs_write_begin(struct file *file, struct address_space *mapping, loff_t pos, unsigned int len, unsigned int flags, struct folio **_folio, - void **_fsdata, - const struct netfs_request_ops *ops, - void *netfs_priv); - -Each corresponds to a VM operation, with the addition of a couple of parameters -for the use of the read helpers: + void **_fsdata); - * ``ops`` - - A table of operations through which the helpers can talk to the filesystem. - - * ``netfs_priv`` +Each corresponds to a VM address space operation. These operations use the +state in the per-inode context. - Filesystem private data (can be NULL). - -Both of these values will be stored into the read request structure. - -For ->readahead() and ->readpage(), the network filesystem should just jump -into the corresponding read helper; whereas for ->write_begin(), it may be a +For ->readahead() and ->readpage(), the network filesystem just point directly +at the corresponding read helper; whereas for ->write_begin(), it may be a little more complicated as the network filesystem might want to flush conflicting writes or track dirty data and needs to put the acquired folio if an error occurs after calling the helper. @@ -246,7 +295,6 @@ through which it can issue requests and negotiate:: struct netfs_request_ops { void (*init_request)(struct netfs_io_request *rreq, struct file *file); - bool (*is_cache_enabled)(struct inode *inode); int (*begin_cache_operation)(struct netfs_io_request *rreq); void (*expand_readahead)(struct netfs_io_request *rreq); bool (*clamp_length)(struct netfs_io_subrequest *subreq); @@ -265,11 +313,6 @@ The operations are as follows: [Optional] This is called to initialise the request structure. It is given the file for reference and can modify the ->netfs_priv value. - * ``is_cache_enabled()`` - - [Required] This is called by netfs_write_begin() to ask if the file is being - cached. It should return true if it is being cached and false otherwise. - * ``begin_cache_operation()`` [Optional] This is called to ask the network filesystem to call into the -- cgit From 3be01750d7ac5803ad6fa76801d4d80b3814229f Mon Sep 17 00:00:00 2001 From: David Howells Date: Mon, 7 Mar 2022 21:57:24 +0000 Subject: netfs: Rename read_helper.c to io.c Rename the read_helper.c file to io.c before splitting out the buffered read functions and some other bits. Changes ======= ver #2) - Rename read_helper.c before splitting. Signed-off-by: David Howells Reviewed-by: Jeff Layton cc: linux-cachefs@redhat.com Link: https://lore.kernel.org/r/164678216109.1200972.16567696909952495832.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/164692918076.2099075.8120961172717347610.stgit@warthog.procyon.org.uk/ # v3 --- Documentation/filesystems/netfs_library.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index 9c8bc5666b46..69f00179fdfe 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -605,4 +605,5 @@ API Function Reference ====================== .. kernel-doc:: include/linux/netfs.h -.. kernel-doc:: fs/netfs/read_helper.c +.. kernel-doc:: fs/netfs/buffered_read.c +.. kernel-doc:: fs/netfs/io.c -- cgit From 06384573a3e8335ac6797577e545c33dbf91b490 Mon Sep 17 00:00:00 2001 From: Mark Pearson Date: Thu, 17 Mar 2022 17:40:07 -0400 Subject: Documentation: syfs-class-firmware-attributes: Lenovo Certificate support Certificate based authentication is available as an alternative to password based authentication. The WMI commands are cryptographically signed using a separate signing server and will be verified by the BIOS before being accepted. This commit details the fields that are needed to support that implementation. At present the changes are intended for Lenovo platforms, but have been designed to keep them as flexible as possible for future implementations from other vendors. Signed-off-by: Mark Pearson Link: https://lore.kernel.org/r/20220317214008.3459-1-markpearson@lenovo.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede --- .../ABI/testing/sysfs-class-firmware-attributes | 45 ++++++++++++++++++++++ 1 file changed, 45 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes index 13e31c6a0e9c..05820365f1ec 100644 --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes @@ -246,6 +246,51 @@ Description: that is being referenced (e.g hdd0, hdd1 etc) This attribute defaults to device 0. + certificate: + signature: + save_signature: + These attributes are used for certificate based authentication. This is + used in conjunction with a signing server as an alternative to password + based authentication. + The user writes to the attribute(s) with a BASE64 encoded string obtained + from the signing server. + The attributes can be displayed to check the stored value. + + Some usage examples: + Installing a certificate to enable feature: + echo authentication/Admin/current_password + echo > authentication/Admin/certificate + + Updating the installed certificate: + echo > authentication/Admin/signature + echo > authentication/Admin/certificate + + Removing the installed certificate: + echo > authentication/Admin/signature + echo '' > authentication/Admin/certificate + + Changing a BIOS setting: + echo > authentication/Admin/signature + echo > authentication/Admin/save_signature + echo Enable > attribute/PasswordBeep/current_value + + You cannot enable certificate authentication if a supervisor password + has not been set. + Clearing the certificate results in no bios-admin authentication method + being configured allowing anyone to make changes. + After any of these operations the system must reboot for the changes to + take effect. + + certificate_thumbprint: + Read only attribute used to display the MD5, SHA1 and SHA256 thumbprints + for the certificate installed in the BIOS. + + certificate_to_password: + Write only attribute used to switch from certificate based authentication + back to password based. + Usage: + echo > authentication/Admin/signature + echo > authentication/Admin/certificate_to_password What: /sys/class/firmware-attributes/*/attributes/pending_reboot -- cgit From 02a64ef64c4efb3707e670cdde27afe352c7c143 Mon Sep 17 00:00:00 2001 From: Vincent Whitchurch Date: Fri, 11 Mar 2022 10:45:14 +0100 Subject: dt-bindings: serial: samsung: Add ARTPEC-8 UART Add a compatible for the UART on the ARTPEC-8 SoC. This hardware block is closely related to the variants used on the Exynos chips. The register layout is identical to Exynos850 et al but the fifo size is different (64 bytes in each direction for all instances). Reviewed-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Signed-off-by: Vincent Whitchurch Link: https://lore.kernel.org/r/20220311094515.3223023-2-vincent.whitchurch@axis.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml index 6aceba4a5f79..d4688e317fc5 100644 --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml @@ -20,6 +20,7 @@ properties: items: - enum: - apple,s5l-uart + - axis,artpec8-uart - samsung,s3c2410-uart - samsung,s3c2412-uart - samsung,s3c2440-uart @@ -111,6 +112,7 @@ allOf: contains: enum: - apple,s5l-uart + - axis,artpec8-uart - samsung,exynos4210-uart - samsung,exynos5433-uart then: -- cgit From ac484005767bb50cc76e56e26fdbb25a097e5bf8 Mon Sep 17 00:00:00 2001 From: Allen-KH Cheng Date: Wed, 16 Feb 2022 20:00:25 +0800 Subject: dt-bindings: usb: mtk-xhci: add compatible for mt8186 Add compatible for mt8186 Acked-by: Rob Herring Acked-by: Chunfeng Yun Signed-off-by: Allen-KH Cheng Link: https://lore.kernel.org/r/20220216120025.29860-1-allen-kh.cheng@mediatek.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml index 41efb51638d1..084d7135b2d9 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml @@ -30,6 +30,7 @@ properties: - mediatek,mt7629-xhci - mediatek,mt8173-xhci - mediatek,mt8183-xhci + - mediatek,mt8186-xhci - mediatek,mt8192-xhci - mediatek,mt8195-xhci - const: mediatek,mtk-xhci -- cgit From cd9363018269636b4905012a5fc8706cfc7aa116 Mon Sep 17 00:00:00 2001 From: Vincent Shih Date: Fri, 25 Feb 2022 17:58:19 +0000 Subject: nvmem: dt-bindings: Fix the error of dt-bindings check 1. Remove the unnecessary header file for dt-binding check 2. Replace OTPRX with 0x15 since it is not defined here. 3. Modify the name of the node of the clock driver. Fixes: 8fb29b450182 ("dt-bindings: nvmem: Add bindings doc for Sunplus OCOTP driver") Reported-by: Rob Herring Signed-off-by: Vincent Shih Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220225175822.8293-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml index 4b28f37dfb67..a7644ebbc2ca 100644 --- a/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml +++ b/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml @@ -60,13 +60,11 @@ unevaluatedProperties: false examples: - | - #include - otp: otp@9c00af00 { compatible = "sunplus,sp7021-ocotp"; reg = <0x9c00af00 0x34>, <0x9c00af80 0x58>; reg-names = "hb_gpio", "otprx"; - clocks = <&clks OTPRX>; + clocks = <&clkc 0x15>; #address-cells = <1>; #size-cells = <1>; -- cgit From 82a05d81d82bbe00f58be6c32ec57a59e07e0c05 Mon Sep 17 00:00:00 2001 From: Rafał Miłecki Date: Fri, 25 Feb 2022 17:58:21 +0000 Subject: dt-bindings: nvmem: make "reg" property optional MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Most NVMEM providers have cells at hardcoded addresses however there are some exceptions. Some devices store cells layout in internal structs using custom formats. It's important to allow NVMEM consumers to still reference such NVMEM cells. Making "reg" optional allows defining NVMEM cells by their names only and using them with phandles. Reviewed-by: Rob Herring Signed-off-by: Rafał Miłecki Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220225175822.8293-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/nvmem/nvmem.yaml | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml index 43ed7e32e5ac..3bb349c634cb 100644 --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml @@ -60,9 +60,6 @@ patternProperties: description: Size in bit within the address range specified by reg. - required: - - reg - additionalProperties: true examples: -- cgit From 084973e944bec21804f8afb0515b25434438699a Mon Sep 17 00:00:00 2001 From: Rafał Miłecki Date: Fri, 25 Feb 2022 17:58:22 +0000 Subject: dt-bindings: nvmem: brcm,nvram: add basic NVMEM cells MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit NVRAM doesn't have cells at hardcoded addresses. They are stored in internal struct (custom & dynamic format). It's still important to define relevant cells in DT so NVMEM consumers can reference them. Update binding to allow including basic cells as NVMEM device subnodes. Reviewed-by: Rob Herring Signed-off-by: Rafał Miłecki Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220225175822.8293-5-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/nvmem/brcm,nvram.yaml | 25 ++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml index 8c3f0cd22821..25033de3ef6b 100644 --- a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml +++ b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml @@ -14,6 +14,8 @@ description: | NVRAM can be accessed on Broadcom BCM47xx MIPS and Northstar ARM Cortex-A9 devices usiong I/O mapped memory. + NVRAM variables can be defined as NVMEM device subnodes. + maintainers: - Rafał Miłecki @@ -27,11 +29,30 @@ properties: reg: maxItems: 1 + board_id: + type: object + description: Board identification name + + et0macaddr: + type: object + description: First Ethernet interface's MAC address + + et1macaddr: + type: object + description: Second Ethernet interface's MAC address + + et2macaddr: + type: object + description: Third Ethernet interface's MAC address + unevaluatedProperties: false examples: - | nvram@1eff0000 { - compatible = "brcm,nvram"; - reg = <0x1eff0000 0x10000>; + compatible = "brcm,nvram"; + reg = <0x1eff0000 0x10000>; + + mac: et0macaddr { + }; }; -- cgit From fb42387b2e46cd2b1a5aee9a8c7ffc6eaf2df4eb Mon Sep 17 00:00:00 2001 From: Jeya R Date: Mon, 14 Feb 2022 16:09:54 +0000 Subject: dt-bindings: misc: add property to support non-secure DSP Add property to set DSP domain as non-secure. ADSP/MDSP/SDSP are by default secured, where as CDSP can be either be secured/unsecured. non-secured Compute DSP would allow users to load unsigned process and run hexagon instructions, but limiting access to secured hardware within the DSP. Based on this flag device nodes for secured and unsecured are created. Acked-by: Rob Herring Signed-off-by: Jeya R Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220214161002.6831-5-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/misc/qcom,fastrpc.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt b/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt index 2a1827ab50d2..f9a01e2b4c96 100644 --- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt +++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt @@ -17,6 +17,11 @@ other tasks. Definition: should specify the dsp domain name this fastrpc corresponds to. must be one of this: "adsp", "mdsp", "sdsp", "cdsp" +- qcom,non-secure-domain: + Usage: required + Value type: + Definition: Property to specify that dsp domain is non-secure. + - #address-cells Usage: required Value type: -- cgit From 87ccc14ee640ee32c43796d3db4f46b12353debc Mon Sep 17 00:00:00 2001 From: Vamsi Krishna Gattupalli Date: Mon, 14 Feb 2022 16:09:57 +0000 Subject: dt-bindings: misc: add fastrpc domain vmid property Add fastrpc domain virtual machine IDs property. This property is used to setup memory protection for remote processor. Acked-by: Rob Herring Signed-off-by: Vamsi Krishna Gattupalli Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220214161002.6831-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/misc/qcom,fastrpc.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt b/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt index f9a01e2b4c96..5ec124b138a6 100644 --- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt +++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt @@ -22,6 +22,11 @@ other tasks. Value type: Definition: Property to specify that dsp domain is non-secure. +- qcom,vmids: + Usage: optional + Value type: + Definition: Virtual machine IDs for remote processor. + - #address-cells Usage: required Value type: -- cgit From 615f3eea0d5f70524d071528e8c1aeaa6ccb73e3 Mon Sep 17 00:00:00 2001 From: Bagas Sanjaya Date: Mon, 14 Mar 2022 18:33:25 +0700 Subject: Documentation: add note block surrounding security patch note Security patches have different handling than rest of patches for review. Enclose note paragraph about such patches in `.. note::` block. Cc: Sasha Levin Cc: Jonathan Corbet Cc: linux-kernel@vger.kernel.org Signed-off-by: Bagas Sanjaya Link: https://lore.kernel.org/r/20220314113329.485372-2-bagasdotme@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/process/stable-kernel-rules.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 003c865e9c21..691d70525466 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -35,7 +35,9 @@ Rules on what kind of patches are accepted, and which ones are not, into the Procedure for submitting patches to the -stable tree ---------------------------------------------------- - - Security patches should not be handled (solely) by the -stable review +.. note:: + + Security patches should not be handled (solely) by the -stable review process but should follow the procedures in :ref:`Documentation/admin-guide/security-bugs.rst `. -- cgit From 587d39b260c4d090166314d64be70b1f6a26b0b5 Mon Sep 17 00:00:00 2001 From: Bagas Sanjaya Date: Mon, 14 Mar 2022 18:33:28 +0700 Subject: Documentation: add link to stable release candidate tree There is also stable release candidate tree. Mention it, however with a warning that the tree is for testing purposes. Cc: Greg Kroah-Hartman Cc: Sasha Levin Cc: Jonathan Corbet Cc: stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Bagas Sanjaya Link: https://lore.kernel.org/r/20220314113329.485372-5-bagasdotme@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/process/stable-kernel-rules.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 691d70525466..ffe9440bfbca 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -172,6 +172,15 @@ Trees https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git + - The release candidate of all stable kernel versions can be found at: + + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/ + + .. warning:: + The -stable-rc tree is a snapshot in time of the stable-queue tree and + will change frequently, hence will be rebased often. It should only be + used for testing purposes (e.g. to be consumed by CI systems). + Review committee ---------------- -- cgit From 555d44932c67e617d89bc13c81c7efac5b51fcfa Mon Sep 17 00:00:00 2001 From: Bagas Sanjaya Date: Mon, 14 Mar 2022 18:33:29 +0700 Subject: Documentation: update stable tree link The link to stable tree is redirected to https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git. Update accordingly. Cc: Greg Kroah-Hartman Cc: Sasha Levin Cc: Jonathan Corbet Cc: stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Bagas Sanjaya Link: https://lore.kernel.org/r/20220314113329.485372-6-bagasdotme@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/process/stable-kernel-rules.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index ffe9440bfbca..f2e8a9a6208c 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -170,7 +170,7 @@ Trees - The finalized and tagged releases of all stable kernels can be found in separate branches per version at: - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git - The release candidate of all stable kernel versions can be found at: -- cgit From 88d99e870143199ba5bf42701dca06ce1d1388f0 Mon Sep 17 00:00:00 2001 From: Bagas Sanjaya Date: Mon, 14 Mar 2022 18:33:27 +0700 Subject: Documentation: update stable review cycle documentation In recent times, the review cycle for stable releases have been changed. In particular, there is release candidate phase between ACKing patches and new stable release. Also, in case of failed submissions (fail to apply to stable tree), manual backport (Option 3) have to be submitted instead. Update the release cycle documentation on stable-kernel-rules.rst to reflect the above. Cc: Sasha Levin Cc: Jonathan Corbet Cc: linux-kernel@vger.kernel.org Signed-off-by: Bagas Sanjaya Link: https://lore.kernel.org/r/20220314113329.485372-4-bagasdotme@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/process/stable-kernel-rules.rst | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index f2e8a9a6208c..c61865e91f52 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -83,8 +83,8 @@ it to be applied to. :ref:`option_2` and :ref:`option_3` are more useful if the patch isn't deemed worthy at the time it is applied to a public git tree (for instance, because it deserves more regression testing first). :ref:`option_3` is especially -useful if the patch needs some special handling to apply to an older kernel -(e.g., if API's have changed in the meantime). +useful if the original upstream patch needs to be backported (for example +the backport needs some special handling due to e.g. API changes). Note that for :ref:`option_3`, if the patch deviates from the original upstream patch (for example because it had to be backported) this must be very @@ -153,8 +153,17 @@ Review cycle - If the patch is rejected by a member of the committee, or linux-kernel members object to the patch, bringing up issues that the maintainers and members did not realize, the patch will be dropped from the queue. - - At the end of the review cycle, the ACKed patches will be added to the - latest -stable release, and a new -stable release will happen. + - The ACKed patches will be posted again as part of release candidate (-rc) + to be tested by developers and testers. + - Usually only one -rc release is made, however if there are any outstanding + issues, some patches may be modified or dropped or additional patches may + be queued. Additional -rc releases are then released and tested until no + issues are found. + - Responding to the -rc releases can be done on the mailing list by sending + a "Tested-by:" email with any testing information desired. The "Tested-by:" + tags will be collected and added to the release commit. + - At the end of the review cycle, the new -stable release will be released + containing all the queued and tested patches. - Security patches will be accepted into the -stable tree directly from the security kernel team, and not go through the normal review cycle. Contact the kernel security team for more details on this procedure. -- cgit From e34855b99696433a26d86179552553c6c6fa69b8 Mon Sep 17 00:00:00 2001 From: Rohit Agarwal Date: Wed, 16 Mar 2022 11:37:12 +0530 Subject: regulator: dt-bindings: Add PMX65 compatibles Add PMX65 compatibles for PMIC found in SDX65 platform. Signed-off-by: Rohit Agarwal Link: https://lore.kernel.org/r/1647410837-22537-2-git-send-email-quic_rohiagar@quicinc.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml index 5c73d3f639c7..e28ee9e46788 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml @@ -48,6 +48,7 @@ description: | For PMI8998, bob For PMR735A, smps1 - smps3, ldo1 - ldo7 For PMX55, smps1 - smps7, ldo1 - ldo16 + For PMX65, smps1 - smps8, ldo1 - ldo21 properties: compatible: @@ -70,6 +71,7 @@ properties: - qcom,pmm8155au-rpmh-regulators - qcom,pmr735a-rpmh-regulators - qcom,pmx55-rpmh-regulators + - qcom,pmx65-rpmh-regulators qcom,pmic-id: description: | -- cgit From 9c1666831817ce56482a1f1fd1fbb65dbc8acaab Mon Sep 17 00:00:00 2001 From: Namjae Jeon Date: Fri, 4 Feb 2022 07:30:01 +0900 Subject: Documentation: ksmbd: update Feature Status table As RDMA connection with Windows client becomes possible, change SMB direct to Supported from Partially Supported in the Feature Status table. It also adds new RSS mode support. Signed-off-by: Namjae Jeon Signed-off-by: Steve French --- Documentation/filesystems/cifs/ksmbd.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/cifs/ksmbd.rst b/Documentation/filesystems/cifs/ksmbd.rst index b0d354fd8066..1af600db2e70 100644 --- a/Documentation/filesystems/cifs/ksmbd.rst +++ b/Documentation/filesystems/cifs/ksmbd.rst @@ -82,10 +82,10 @@ Signing Update Supported. Pre-authentication integrity Supported. SMB3 encryption(CCM, GCM) Supported. (CCM and GCM128 supported, GCM256 in progress) -SMB direct(RDMA) Partially Supported. SMB3 Multi-channel is - required to connect to Windows client. +SMB direct(RDMA) Supported. SMB3 Multi-channel Partially Supported. Planned to implement replay/retry mechanisms for future. +Receive Side Scaling mode Supported. SMB3.1.1 POSIX extension Supported. ACLs Partially Supported. only DACLs available, SACLs (auditing) is planned for the future. For -- cgit From dba529605f55e7eee725dd8e48a70f95ecdd612c Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Thu, 17 Mar 2022 23:58:40 +0100 Subject: dt-bindings: gnss: Rewrite common bindings in YAML This rewrites the text-based GNSS common bindings to use a YAML schema. Cc: devicetree@vger.kernel.org Reviewed-by: Krzysztof Kozlowski Signed-off-by: Linus Walleij Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220317225844.1262643-1-linus.walleij@linaro.org --- .../devicetree/bindings/gnss/gnss-common.yaml | 55 ++++++++++++++++++++++ Documentation/devicetree/bindings/gnss/gnss.txt | 37 --------------- 2 files changed, 55 insertions(+), 37 deletions(-) create mode 100644 Documentation/devicetree/bindings/gnss/gnss-common.yaml delete mode 100644 Documentation/devicetree/bindings/gnss/gnss.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gnss/gnss-common.yaml b/Documentation/devicetree/bindings/gnss/gnss-common.yaml new file mode 100644 index 000000000000..963b926e30a7 --- /dev/null +++ b/Documentation/devicetree/bindings/gnss/gnss-common.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gnss/gnss-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common Properties for Global Navigation Satellite Systems (GNSS) + receiver devices + +maintainers: + - Johan Hovold + +description: | + This document defines device tree properties common to Global Navigation + Satellite System receivers. + +properties: + $nodename: + pattern: "^gnss(@.*)?$" + + lna-supply: + description: A separate regulator supplying power for the Low Noise + Amplifier (LNA). This is an amplifier connected between the GNSS + device and the receiver antenna. + + enable-gpios: + description: A GPIO line that will enable the GNSS receiver when + asserted. If this line is active low, the GPIO phandle should + consequently be tagged with the GPIO_ACTIVE_LOW flag so the operating + system can rely on asserting the line to enable the GNSS device. + maxItems: 1 + + timepulse-gpios: + description: When a timepulse is provided to the GNSS device using a + GPIO line, this is used. + maxItems: 1 + + current-speed: + description: The baudrate in bits per second of the device as it comes + online, current active speed. + $ref: /schemas/types.yaml#/definitions/uint32 + +additionalProperties: true + +examples: + - | + #include + serial { + gnss { + compatible = "u-blox,neo-8"; + vcc-supply = <&gnss_reg>; + timepulse-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; + current-speed = <4800>; + }; + }; diff --git a/Documentation/devicetree/bindings/gnss/gnss.txt b/Documentation/devicetree/bindings/gnss/gnss.txt deleted file mode 100644 index d6dc9c0d8249..000000000000 --- a/Documentation/devicetree/bindings/gnss/gnss.txt +++ /dev/null @@ -1,37 +0,0 @@ -GNSS Receiver DT binding - -This documents the binding structure and common properties for GNSS receiver -devices. - -A GNSS receiver node is a node named "gnss" and typically resides on a serial -bus (e.g. UART, I2C or SPI). - -Please refer to the following documents for generic properties: - - Documentation/devicetree/bindings/serial/serial.yaml - Documentation/devicetree/bindings/spi/spi-bus.txt - -Required properties: - -- compatible : A string reflecting the vendor and specific device the node - represents - -Optional properties: -- lna-supply : Separate supply for an LNA -- enable-gpios : GPIO used to enable the device -- timepulse-gpios : Time pulse GPIO - -Example: - -serial@1234 { - compatible = "ns16550a"; - - gnss { - compatible = "u-blox,neo-8"; - - vcc-supply = <&gnss_reg>; - timepulse-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; - - current-speed = <4800>; - }; -}; -- cgit From 069e6bc6dba532604050f559a5c06fb1525cec04 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Thu, 17 Mar 2022 23:58:41 +0100 Subject: dt-bindings: gnss: Modify u-blox to use common bindings This modifies the existing U-Blox GNSS bindings to reference the common GNSS YAML bindings. Fixed an unrelated whitespace error while at it. Cc: devicetree@vger.kernel.org Cc: Krzysztof Kozlowski Signed-off-by: Linus Walleij Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220317225844.1262643-2-linus.walleij@linaro.org --- Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml b/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml index 396101a223e7..35a760cfd343 100644 --- a/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml +++ b/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml @@ -6,6 +6,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: U-blox GNSS Receiver Device Tree Bindings +allOf: + - $ref: gnss-common.yaml# + maintainers: - Johan Hovold @@ -29,27 +32,20 @@ properties: description: > Main voltage regulator - timepulse-gpios: - maxItems: 1 - description: > - Time pulse GPIO - u-blox,extint-gpios: maxItems: 1 description: > GPIO connected to the "external interrupt" input pin - + v-bckp-supply: description: > Backup voltage regulator - current-speed: true - required: - compatible - vcc-supply -additionalProperties: false +unevaluatedProperties: false examples: - | -- cgit From 5505409e423f61c981d84f53dee2a93bf3ba5913 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Thu, 17 Mar 2022 23:58:42 +0100 Subject: dt-bindings: gnss: Rewrite sirfstar binding in YAML This rewrites the SiRFstar DT bindings in YAML. Cc: devicetree@vger.kernel.org Cc: Krzysztof Kozlowski Signed-off-by: Linus Walleij Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220317225844.1262643-3-linus.walleij@linaro.org --- .../devicetree/bindings/gnss/sirfstar.txt | 46 --------------- .../devicetree/bindings/gnss/sirfstar.yaml | 68 ++++++++++++++++++++++ 2 files changed, 68 insertions(+), 46 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gnss/sirfstar.txt create mode 100644 Documentation/devicetree/bindings/gnss/sirfstar.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gnss/sirfstar.txt b/Documentation/devicetree/bindings/gnss/sirfstar.txt deleted file mode 100644 index f4252b6b660b..000000000000 --- a/Documentation/devicetree/bindings/gnss/sirfstar.txt +++ /dev/null @@ -1,46 +0,0 @@ -SiRFstar-based GNSS Receiver DT binding - -SiRFstar chipsets are used in GNSS-receiver modules produced by several -vendors and can use UART, SPI or I2C interfaces. - -Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic -properties. - -Required properties: - -- compatible : Must be one of - - "fastrax,uc430" - "linx,r4" - "wi2wi,w2sg0004" - "wi2wi,w2sg0008i" - "wi2wi,w2sg0084i" - -- vcc-supply : Main voltage regulator (pin name: 3V3_IN, VCC, VDD) - -Required properties (I2C): -- reg : I2C slave address - -Required properties (SPI): -- reg : SPI chip select address - -Optional properties: - -- sirf,onoff-gpios : GPIO used to power on and off device (pin name: ON_OFF) -- sirf,wakeup-gpios : GPIO used to determine device power state - (pin name: RFPWRUP, WAKEUP) -- timepulse-gpios : Time pulse GPIO (pin name: 1PPS, TM) - -Example: - -serial@1234 { - compatible = "ns16550a"; - - gnss { - compatible = "wi2wi,w2sg0084i"; - - vcc-supply = <&gnss_reg>; - sirf,onoff-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; - sirf,wakeup-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>; - }; -}; diff --git a/Documentation/devicetree/bindings/gnss/sirfstar.yaml b/Documentation/devicetree/bindings/gnss/sirfstar.yaml new file mode 100644 index 000000000000..1178d4b32a5c --- /dev/null +++ b/Documentation/devicetree/bindings/gnss/sirfstar.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gnss/sirfstar.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SiRFstar GNSS Receiver Device Tree Bindings + +maintainers: + - Johan Hovold + +description: + The SiRFstar GNSS receivers have incarnated over the years in different + chips, starting from the SiRFstarIII which was a chip that was introduced in + 2004 and used in a lot of dedicated GPS devices. In 2009 SiRF was acquired + by CSR (Cambridge Silicon Radio) and in 2012 the CSR GPS business was + acquired by Samsung, while some products remained with CSR. In 2014 CSR + was acquired by Qualcomm who still sell some of the SiRF products. + + SiRF chips can be used over UART, I2C or SPI buses. + +allOf: + - $ref: gnss-common.yaml# + +properties: + compatible: + enum: + - fastrax,uc430 + - linx,r4 + - wi2wi,w2sg0004 + - wi2wi,w2sg0008i + - wi2wi,w2sg0084i + + reg: + description: + The I2C Address, SPI chip select address. Not required on UART buses. + + vcc-supply: + description: + Main voltage regulator, pin names such as 3V3_IN, VCC, VDD. + + sirf,onoff-gpios: + maxItems: 1 + description: GPIO used to power on and off device, pin name ON_OFF. + + sirf,wakeup-gpios: + maxItems: 1 + description: GPIO used to determine device power state, pin names such + as RFPWRUP, WAKEUP. + +required: + - compatible + - vcc-supply + +unevaluatedProperties: false + +examples: + - | + #include + serial { + gnss { + compatible = "wi2wi,w2sg0084i"; + vcc-supply = <&gnss_vcc_reg>; + sirf,onoff-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; + sirf,wakeup-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>; + current-speed = <38400>; + }; + }; -- cgit From 094b10cb795a85e2f90f03c24b030888ab2f1fa3 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Thu, 17 Mar 2022 23:58:43 +0100 Subject: dt-bindings: gnss: Add two more chips The CSR GSD4t is a CSR product using the SiRFstarIV core, and the CSR CSRG05TA03-ICJE-R is a CSR product using the SiRFstarV core. These chips have a SRESETN line that can be pulled low to hard reset the chip and in some designs this is connected to a GPIO, so add this as an optional property. Update the example with a reset line so users see that it need to be tagged as active low. Cc: devicetree@vger.kernel.org Cc: Krzysztof Kozlowski Signed-off-by: Linus Walleij Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220317225844.1262643-4-linus.walleij@linaro.org --- Documentation/devicetree/bindings/gnss/sirfstar.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gnss/sirfstar.yaml b/Documentation/devicetree/bindings/gnss/sirfstar.yaml index 1178d4b32a5c..991599cdaa6b 100644 --- a/Documentation/devicetree/bindings/gnss/sirfstar.yaml +++ b/Documentation/devicetree/bindings/gnss/sirfstar.yaml @@ -25,6 +25,8 @@ allOf: properties: compatible: enum: + - csr,gsd4t + - csr,csrg05ta03-icje-r - fastrax,uc430 - linx,r4 - wi2wi,w2sg0004 @@ -39,6 +41,11 @@ properties: description: Main voltage regulator, pin names such as 3V3_IN, VCC, VDD. + reset-gpios: + maxItems: 1 + description: An optional active low reset line, should be flagged with + GPIO_ACTIVE_LOW. + sirf,onoff-gpios: maxItems: 1 description: GPIO used to power on and off device, pin name ON_OFF. @@ -61,6 +68,7 @@ examples: gnss { compatible = "wi2wi,w2sg0084i"; vcc-supply = <&gnss_vcc_reg>; + reset-gpios = <&gpio0 15 GPIO_ACTIVE_LOW>; sirf,onoff-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; sirf,wakeup-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>; current-speed = <38400>; -- cgit From 6ac02df3fff71ddacc71e2ae79b73c16873b41c5 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 9 Mar 2022 19:35:27 -0600 Subject: dt-bindings: virtio,mmio: Allow setting devices 'dma-coherent' 'virtio,mmio' devices are always coherent within a guest. As Arm DTs are default non-coherent, the 'dma-coherent' property needs to be set on the virtio device to mark them as such. This aligns with the QEMU 'virt' machine DTB. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220310013528.549030-1-robh@kernel.org --- Documentation/devicetree/bindings/virtio/mmio.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml b/Documentation/devicetree/bindings/virtio/mmio.yaml index 4b7a0273181c..10c22b5bd16a 100644 --- a/Documentation/devicetree/bindings/virtio/mmio.yaml +++ b/Documentation/devicetree/bindings/virtio/mmio.yaml @@ -20,6 +20,8 @@ properties: reg: maxItems: 1 + dma-coherent: true + interrupts: maxItems: 1 -- cgit From 6d8491910fcd3324d0f0ece3bd68e85ead3a04d7 Mon Sep 17 00:00:00 2001 From: Oliver Upton Date: Tue, 1 Mar 2022 06:03:47 +0000 Subject: KVM: x86: Introduce KVM_CAP_DISABLE_QUIRKS2 KVM_CAP_DISABLE_QUIRKS is irrevocably broken. The capability does not advertise the set of quirks which may be disabled to userspace, so it is impossible to predict the behavior of KVM. Worse yet, KVM_CAP_DISABLE_QUIRKS will tolerate any value for cap->args[0], meaning it fails to reject attempts to set invalid quirk bits. The only valid workaround for the quirky quirks API is to add a new CAP. Actually advertise the set of quirks that can be disabled to userspace so it can predict KVM's behavior. Reject values for cap->args[0] that contain invalid bits. Finally, add documentation for the new capability and describe the existing quirks. Signed-off-by: Oliver Upton Message-Id: <20220301060351.442881-5-oupton@google.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 50 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 55efa82e37eb..07a45474abe9 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7083,6 +7083,56 @@ resource that is controlled with the H_SET_MODE hypercall. This capability allows a guest kernel to use a better-performance mode for handling interrupts and system calls. +7.31 KVM_CAP_DISABLE_QUIRKS2 +---------------------------- + +:Capability: KVM_CAP_DISABLE_QUIRKS2 +:Parameters: args[0] - set of KVM quirks to disable +:Architectures: x86 +:Type: vm + +This capability, if enabled, will cause KVM to disable some behavior +quirks. + +Calling KVM_CHECK_EXTENSION for this capability returns a bitmask of +quirks that can be disabled in KVM. + +The argument to KVM_ENABLE_CAP for this capability is a bitmask of +quirks to disable, and must be a subset of the bitmask returned by +KVM_CHECK_EXTENSION. + +The valid bits in cap.args[0] are: + +=================================== ============================================ + KVM_X86_QUIRK_LINT0_REENABLED By default, the reset value for the LVT + LINT0 register is 0x700 (APIC_MODE_EXTINT). + When this quirk is disabled, the reset value + is 0x10000 (APIC_LVT_MASKED). + + KVM_X86_QUIRK_CD_NW_CLEARED By default, KVM clears CR0.CD and CR0.NW. + When this quirk is disabled, KVM does not + change the value of CR0.CD and CR0.NW. + + KVM_X86_QUIRK_LAPIC_MMIO_HOLE By default, the MMIO LAPIC interface is + available even when configured for x2APIC + mode. When this quirk is disabled, KVM + disables the MMIO LAPIC interface if the + LAPIC is in x2APIC mode. + + KVM_X86_QUIRK_OUT_7E_INC_RIP By default, KVM pre-increments %rip before + exiting to userspace for an OUT instruction + to port 0x7e. When this quirk is disabled, + KVM does not pre-increment %rip before + exiting to userspace. + + KVM_X86_QUIRK_MISC_ENABLE_NO_MWAIT When this quirk is disabled, KVM sets + CPUID.01H:ECX[bit 3] (MONITOR/MWAIT) if + IA32_MISC_ENABLE[bit 18] (MWAIT) is set. + Additionally, when this quirk is disabled, + KVM clears CPUID.01H:ECX[bit 3] if + IA32_MISC_ENABLE[bit 18] is cleared. +=================================== ============================================ + 8. Other capabilities. ====================== -- cgit From 5232c63f46fdd779303527ec36c518cc1e9c6b4e Mon Sep 17 00:00:00 2001 From: "Matthew Wilcox (Oracle)" Date: Thu, 6 Jan 2022 16:46:43 -0500 Subject: mm: Make compound_pincount always available Move compound_pincount from the third page to the second page, which means it's available for all compound pages. That lets us delete hpage_pincount_available(). On 32-bit systems, there isn't enough space for both compound_pincount and compound_nr in the second page (it would collide with page->private, which is in use for pages in the swap cache), so revert the optimisation of storing both compound_order and compound_nr on 32-bit systems. Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: John Hubbard Reviewed-by: Christoph Hellwig Reviewed-by: Jason Gunthorpe Reviewed-by: William Kucharski --- Documentation/core-api/pin_user_pages.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/pin_user_pages.rst b/Documentation/core-api/pin_user_pages.rst index fcf605be43d0..b18416f4500f 100644 --- a/Documentation/core-api/pin_user_pages.rst +++ b/Documentation/core-api/pin_user_pages.rst @@ -55,18 +55,18 @@ flags the caller provides. The caller is required to pass in a non-null struct pages* array, and the function then pins pages by incrementing each by a special value: GUP_PIN_COUNTING_BIAS. -For huge pages (and in fact, any compound page of more than 2 pages), the -GUP_PIN_COUNTING_BIAS scheme is not used. Instead, an exact form of pin counting -is achieved, by using the 3rd struct page in the compound page. A new struct -page field, hpage_pinned_refcount, has been added in order to support this. +For compound pages, the GUP_PIN_COUNTING_BIAS scheme is not used. Instead, +an exact form of pin counting is achieved, by using the 2nd struct page +in the compound page. A new struct page field, compound_pincount, has +been added in order to support this. This approach for compound pages avoids the counting upper limit problems that are discussed below. Those limitations would have been aggravated severely by huge pages, because each tail page adds a refcount to the head page. And in -fact, testing revealed that, without a separate hpage_pinned_refcount field, +fact, testing revealed that, without a separate compound_pincount field, page overflows were seen in some huge page stress tests. -This also means that huge pages and compound pages (of order > 1) do not suffer +This also means that huge pages and compound pages do not suffer from the false positives problem that is mentioned below.:: Function @@ -264,9 +264,9 @@ place.) Other diagnostics ================= -dump_page() has been enhanced slightly, to handle these new counting fields, and -to better report on compound pages in general. Specifically, for compound pages -with order > 1, the exact (hpage_pinned_refcount) pincount is reported. +dump_page() has been enhanced slightly, to handle these new counting +fields, and to better report on compound pages in general. Specifically, +for compound pages, the exact (compound_pincount) pincount is reported. References ========== -- cgit From 3f9a07558f1e3420c9319f39606f06fe3ebc865e Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 16 Mar 2022 14:08:57 +0100 Subject: dt-bindings: gpio: pca95xx: drop useless consumer example Consumer examples in the bindings of resource providers are trivial, useless and duplication of code. Remove the example code for consumer Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220316130858.93455-1-krzysztof.kozlowski@canonical.com --- Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml index b6a6e742b66d..dc0fc8fc4839 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml @@ -190,14 +190,6 @@ examples: "chg-status+red", "green", "blue", "en-esata", "fault1", "p26", "p27"; }; - - ts3a227@3b { - compatible = "ti,ts3a227e"; - reg = <0x3b>; - interrupt-parent = <&gpio99>; - interrupts = <14 IRQ_TYPE_EDGE_RISING>; - ti,micbias = <0>; /* 2.1V */ - }; }; - | -- cgit From 23b1f18326ec3f6966ac8851b20b6d3d22380520 Mon Sep 17 00:00:00 2001 From: Atish Patra Date: Fri, 18 Feb 2022 16:46:59 -0800 Subject: Documentation: riscv: Remove the old documentation The existing pmu documentation describes the limitation of perf infrastructure in RISC-V ISA and limited feature set of perf in RISC-V. However, SBI PMU extension and sscofpmf extension(ISA extension) allows to implement most of the required features of perf. Remove the old documentation which is not accurate anymore. Reviewed-by: Anup Patel Signed-off-by: Atish Patra Signed-off-by: Atish Patra Signed-off-by: Palmer Dabbelt --- Documentation/riscv/pmu.rst | 255 -------------------------------------------- 1 file changed, 255 deletions(-) delete mode 100644 Documentation/riscv/pmu.rst (limited to 'Documentation') diff --git a/Documentation/riscv/pmu.rst b/Documentation/riscv/pmu.rst deleted file mode 100644 index acb216b99c26..000000000000 --- a/Documentation/riscv/pmu.rst +++ /dev/null @@ -1,255 +0,0 @@ -=================================== -Supporting PMUs on RISC-V platforms -=================================== - -Alan Kao , Mar 2018 - -Introduction ------------- - -As of this writing, perf_event-related features mentioned in The RISC-V ISA -Privileged Version 1.10 are as follows: -(please check the manual for more details) - -* [m|s]counteren -* mcycle[h], cycle[h] -* minstret[h], instret[h] -* mhpeventx, mhpcounterx[h] - -With such function set only, porting perf would require a lot of work, due to -the lack of the following general architectural performance monitoring features: - -* Enabling/Disabling counters - Counters are just free-running all the time in our case. -* Interrupt caused by counter overflow - No such feature in the spec. -* Interrupt indicator - It is not possible to have many interrupt ports for all counters, so an - interrupt indicator is required for software to tell which counter has - just overflowed. -* Writing to counters - There will be an SBI to support this since the kernel cannot modify the - counters [1]. Alternatively, some vendor considers to implement - hardware-extension for M-S-U model machines to write counters directly. - -This document aims to provide developers a quick guide on supporting their -PMUs in the kernel. The following sections briefly explain perf' mechanism -and todos. - -You may check previous discussions here [1][2]. Also, it might be helpful -to check the appendix for related kernel structures. - - -1. Initialization ------------------ - -*riscv_pmu* is a global pointer of type *struct riscv_pmu*, which contains -various methods according to perf's internal convention and PMU-specific -parameters. One should declare such instance to represent the PMU. By default, -*riscv_pmu* points to a constant structure *riscv_base_pmu*, which has very -basic support to a baseline QEMU model. - -Then he/she can either assign the instance's pointer to *riscv_pmu* so that -the minimal and already-implemented logic can be leveraged, or invent his/her -own *riscv_init_platform_pmu* implementation. - -In other words, existing sources of *riscv_base_pmu* merely provide a -reference implementation. Developers can flexibly decide how many parts they -can leverage, and in the most extreme case, they can customize every function -according to their needs. - - -2. Event Initialization ------------------------ - -When a user launches a perf command to monitor some events, it is first -interpreted by the userspace perf tool into multiple *perf_event_open* -system calls, and then each of them calls to the body of *event_init* -member function that was assigned in the previous step. In *riscv_base_pmu*'s -case, it is *riscv_event_init*. - -The main purpose of this function is to translate the event provided by user -into bitmap, so that HW-related control registers or counters can directly be -manipulated. The translation is based on the mappings and methods provided in -*riscv_pmu*. - -Note that some features can be done in this stage as well: - -(1) interrupt setting, which is stated in the next section; -(2) privilege level setting (user space only, kernel space only, both); -(3) destructor setting. Normally it is sufficient to apply *riscv_destroy_event*; -(4) tweaks for non-sampling events, which will be utilized by functions such as - *perf_adjust_period*, usually something like the follows:: - - if (!is_sampling_event(event)) { - hwc->sample_period = x86_pmu.max_period; - hwc->last_period = hwc->sample_period; - local64_set(&hwc->period_left, hwc->sample_period); - } - -In the case of *riscv_base_pmu*, only (3) is provided for now. - - -3. Interrupt ------------- - -3.1. Interrupt Initialization - -This often occurs at the beginning of the *event_init* method. In common -practice, this should be a code segment like:: - - int x86_reserve_hardware(void) - { - int err = 0; - - if (!atomic_inc_not_zero(&pmc_refcount)) { - mutex_lock(&pmc_reserve_mutex); - if (atomic_read(&pmc_refcount) == 0) { - if (!reserve_pmc_hardware()) - err = -EBUSY; - else - reserve_ds_buffers(); - } - if (!err) - atomic_inc(&pmc_refcount); - mutex_unlock(&pmc_reserve_mutex); - } - - return err; - } - -And the magic is in *reserve_pmc_hardware*, which usually does atomic -operations to make implemented IRQ accessible from some global function pointer. -*release_pmc_hardware* serves the opposite purpose, and it is used in event -destructors mentioned in previous section. - -(Note: From the implementations in all the architectures, the *reserve/release* -pair are always IRQ settings, so the *pmc_hardware* seems somehow misleading. -It does NOT deal with the binding between an event and a physical counter, -which will be introduced in the next section.) - -3.2. IRQ Structure - -Basically, a IRQ runs the following pseudo code:: - - for each hardware counter that triggered this overflow - - get the event of this counter - - // following two steps are defined as *read()*, - // check the section Reading/Writing Counters for details. - count the delta value since previous interrupt - update the event->count (# event occurs) by adding delta, and - event->hw.period_left by subtracting delta - - if the event overflows - sample data - set the counter appropriately for the next overflow - - if the event overflows again - too frequently, throttle this event - fi - fi - - end for - -However as of this writing, none of the RISC-V implementations have designed an -interrupt for perf, so the details are to be completed in the future. - -4. Reading/Writing Counters ---------------------------- - -They seem symmetric but perf treats them quite differently. For reading, there -is a *read* interface in *struct pmu*, but it serves more than just reading. -According to the context, the *read* function not only reads the content of the -counter (event->count), but also updates the left period to the next interrupt -(event->hw.period_left). - -But the core of perf does not need direct write to counters. Writing counters -is hidden behind the abstraction of 1) *pmu->start*, literally start counting so one -has to set the counter to a good value for the next interrupt; 2) inside the IRQ -it should set the counter to the same resonable value. - -Reading is not a problem in RISC-V but writing would need some effort, since -counters are not allowed to be written by S-mode. - - -5. add()/del()/start()/stop() ------------------------------ - -Basic idea: add()/del() adds/deletes events to/from a PMU, and start()/stop() -starts/stop the counter of some event in the PMU. All of them take the same -arguments: *struct perf_event *event* and *int flag*. - -Consider perf as a state machine, then you will find that these functions serve -as the state transition process between those states. -Three states (event->hw.state) are defined: - -* PERF_HES_STOPPED: the counter is stopped -* PERF_HES_UPTODATE: the event->count is up-to-date -* PERF_HES_ARCH: arch-dependent usage ... we don't need this for now - -A normal flow of these state transitions are as follows: - -* A user launches a perf event, resulting in calling to *event_init*. -* When being context-switched in, *add* is called by the perf core, with a flag - PERF_EF_START, which means that the event should be started after it is added. - At this stage, a general event is bound to a physical counter, if any. - The state changes to PERF_HES_STOPPED and PERF_HES_UPTODATE, because it is now - stopped, and the (software) event count does not need updating. - - - *start* is then called, and the counter is enabled. - With flag PERF_EF_RELOAD, it writes an appropriate value to the counter (check - previous section for detail). - Nothing is written if the flag does not contain PERF_EF_RELOAD. - The state now is reset to none, because it is neither stopped nor updated - (the counting already started) - -* When being context-switched out, *del* is called. It then checks out all the - events in the PMU and calls *stop* to update their counts. - - - *stop* is called by *del* - and the perf core with flag PERF_EF_UPDATE, and it often shares the same - subroutine as *read* with the same logic. - The state changes to PERF_HES_STOPPED and PERF_HES_UPTODATE, again. - - - Life cycle of these two pairs: *add* and *del* are called repeatedly as - tasks switch in-and-out; *start* and *stop* is also called when the perf core - needs a quick stop-and-start, for instance, when the interrupt period is being - adjusted. - -Current implementation is sufficient for now and can be easily extended to -features in the future. - -A. Related Structures ---------------------- - -* struct pmu: include/linux/perf_event.h -* struct riscv_pmu: arch/riscv/include/asm/perf_event.h - - Both structures are designed to be read-only. - - *struct pmu* defines some function pointer interfaces, and most of them take - *struct perf_event* as a main argument, dealing with perf events according to - perf's internal state machine (check kernel/events/core.c for details). - - *struct riscv_pmu* defines PMU-specific parameters. The naming follows the - convention of all other architectures. - -* struct perf_event: include/linux/perf_event.h -* struct hw_perf_event - - The generic structure that represents perf events, and the hardware-related - details. - -* struct riscv_hw_events: arch/riscv/include/asm/perf_event.h - - The structure that holds the status of events, has two fixed members: - the number of events and the array of the events. - -References ----------- - -[1] https://github.com/riscv/riscv-linux/pull/124 - -[2] https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/f19TmCNP6yA -- cgit From 09f724e196e5b84b578d558d755638dd802800d8 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 18 Mar 2022 17:20:43 +0100 Subject: dt-bindings: dmaengine: sifive,fu540-c000: include generic schema Include generic dma-controller.yaml schema, which enforces node naming and other generic properties. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220318162044.169350-1-krzysztof.kozlowski@canonical.com --- Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml index 75ad898c59bc..47c46af25536 100644 --- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml +++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml @@ -22,6 +22,9 @@ description: | https://static.dev.sifive.com/FU540-C000-v1.0.pdf +allOf: + - $ref: "dma-controller.yaml#" + properties: compatible: items: @@ -41,13 +44,12 @@ required: - compatible - reg - interrupts - - '#dma-cells' -additionalProperties: false +unevaluatedProperties: false examples: - | - dma@3000000 { + dma-controller@3000000 { compatible = "sifive,fu540-c000-pdma"; reg = <0x3000000 0x8000>; interrupts = <23>, <24>, <25>, <26>, <27>, <28>, <29>, <30>; -- cgit From a2e4b5adfdf85d4a94af8a7a9f44e3ee254fd77e Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Fri, 18 Mar 2022 21:13:22 +0100 Subject: dt-bindings: net: mscc-miim: add lan966x compatible The MDIO controller has support to release the internal PHYs from reset by specifying a second memory resource. This is different between the currently supported SparX-5 and the LAN966x. Add a new compatible to distinguish between these two. Signed-off-by: Michael Walle Acked-by: Horatiu Vultur Signed-off-by: Jakub Kicinski --- Documentation/devicetree/bindings/net/mscc-miim.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/mscc-miim.txt b/Documentation/devicetree/bindings/net/mscc-miim.txt index 7104679cf59d..70e0cb1ee485 100644 --- a/Documentation/devicetree/bindings/net/mscc-miim.txt +++ b/Documentation/devicetree/bindings/net/mscc-miim.txt @@ -2,7 +2,7 @@ Microsemi MII Management Controller (MIIM) / MDIO ================================================= Properties: -- compatible: must be "mscc,ocelot-miim" +- compatible: must be "mscc,ocelot-miim" or "microchip,lan966x-miim" - reg: The base address of the MDIO bus controller register bank. Optionally, a second register bank can be defined if there is an associated reset register for internal PHYs -- cgit From 3d8fa7a22dcd54ccfdcea6ed0d9badbdb8594274 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Mon, 21 Mar 2022 14:33:13 +0100 Subject: dt-bindings: ufs: qcom: Add SM6350 compatible string Document the compatible for the UFS found on SM6350. Signed-off-by: Luca Weiss Reviewed-by: Krzysztof Kozlowski Reviewed-by: Alim Akhtar Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220321133318.99406-2-luca.weiss@fairphone.com --- Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml index 5b3a2157f7e5..dcd32c10205a 100644 --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml @@ -27,6 +27,7 @@ properties: - qcom,msm8996-ufshc - qcom,msm8998-ufshc - qcom,sdm845-ufshc + - qcom,sm6350-ufshc - qcom,sm8150-ufshc - qcom,sm8250-ufshc - qcom,sm8350-ufshc @@ -125,6 +126,7 @@ allOf: contains: enum: - qcom,sdm845-ufshc + - qcom,sm6350-ufshc - qcom,sm8150-ufshc then: properties: -- cgit From ef248d9bd616b04df8be25539a4dc5db4b6c56f4 Mon Sep 17 00:00:00 2001 From: Matt Kramer Date: Tue, 22 Mar 2022 13:48:17 -0700 Subject: ALSA: hda/realtek: Add alc256-samsung-headphone fixup This fixes the near-silence of the headphone jack on the ALC256-based Samsung Galaxy Book Flex Alpha (NP730QCJ). The magic verbs were found through trial and error, using known ALC298 hacks as inspiration. The fixup is auto-enabled only when the NP730QCJ is detected. It can be manually enabled using model=alc256-samsung-headphone. Signed-off-by: Matt Kramer Link: https://lore.kernel.org/r/3168355.aeNJFYEL58@linus Signed-off-by: Takashi Iwai --- Documentation/sound/hd-audio/models.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sound/hd-audio/models.rst b/Documentation/sound/hd-audio/models.rst index d25335993e55..9b52f50a6854 100644 --- a/Documentation/sound/hd-audio/models.rst +++ b/Documentation/sound/hd-audio/models.rst @@ -261,6 +261,10 @@ alc-sense-combo huawei-mbx-stereo Enable initialization verbs for Huawei MBX stereo speakers; might be risky, try this at your own risk +alc298-samsung-headphone + Samsung laptops with ALC298 +alc256-samsung-headphone + Samsung laptops with ALC256 ALC66x/67x/892 ============== -- cgit From 84dacdbd5352bfef82423760fa2e8bffaeef9e05 Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Tue, 22 Mar 2022 14:38:51 -0700 Subject: mm: document and polish read-ahead code Add some "big-picture" documentation for read-ahead and polish the code to make it fit this documentation. The meaning of ->async_size is clarified to match its name. i.e. Any request to ->readahead() has a sync part and an async part. The caller will wait for the sync pages to complete, but will not wait for the async pages. The first async page is still marked PG_readahead Note that the current function names page_cache_sync_ra() and page_cache_async_ra() are misleading. All ra request are partly sync and partly async, so either part can be empty. A page_cache_sync_ra() request will usually set ->async_size non-zero, implying it is not all synchronous. When a non-zero req_count is passed to page_cache_async_ra(), the implication is that some prefix of the request is synchronous, though the calculation made there is incorrect - I haven't tried to fix it. Link: https://lkml.kernel.org/r/164549983734.9187.11586890887006601405.stgit@noble.brown Signed-off-by: NeilBrown Cc: Anna Schumaker Cc: Chao Yu Cc: Darrick J. Wong Cc: Ilya Dryomov Cc: Jaegeuk Kim Cc: Jan Kara Cc: Jeff Layton Cc: Jens Axboe Cc: Lars Ellenberg Cc: Miklos Szeredi Cc: Paolo Valente Cc: Philipp Reisner Cc: Ryusuke Konishi Cc: Trond Myklebust Cc: Wu Fengguang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/core-api/mm-api.rst | 19 +++++++++++++++++-- Documentation/filesystems/vfs.rst | 16 ++++++++++------ 2 files changed, 27 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/mm-api.rst b/Documentation/core-api/mm-api.rst index 395835f9289f..f5b2f92822c8 100644 --- a/Documentation/core-api/mm-api.rst +++ b/Documentation/core-api/mm-api.rst @@ -58,15 +58,30 @@ Virtually Contiguous Mappings File Mapping and Page Cache =========================== -.. kernel-doc:: mm/readahead.c - :export: +Filemap +------- .. kernel-doc:: mm/filemap.c :export: +Readahead +--------- + +.. kernel-doc:: mm/readahead.c + :doc: Readahead Overview + +.. kernel-doc:: mm/readahead.c + :export: + +Writeback +--------- + .. kernel-doc:: mm/page-writeback.c :export: +Truncate +-------- + .. kernel-doc:: mm/truncate.c :export: diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index bf5c48066fac..b4a0baa46dcc 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -806,12 +806,16 @@ cache in your filesystem. The following members are defined: object. The pages are consecutive in the page cache and are locked. The implementation should decrement the page refcount after starting I/O on each page. Usually the page will be - unlocked by the I/O completion handler. If the filesystem decides - to stop attempting I/O before reaching the end of the readahead - window, it can simply return. The caller will decrement the page - refcount and unlock the remaining pages for you. Set PageUptodate - if the I/O completes successfully. Setting PageError on any page - will be ignored; simply unlock the page if an I/O error occurs. + unlocked by the I/O completion handler. The set of pages are + divided into some sync pages followed by some async pages, + rac->ra->async_size gives the number of async pages. The + filesystem should attempt to read all sync pages but may decide + to stop once it reaches the async pages. If it does decide to + stop attempting I/O, it can simply return. The caller will + remove the remaining pages from the address space, unlock them + and decrement the page refcount. Set PageUptodate if the I/O + completes successfully. Setting PageError on any page will be + ignored; simply unlock the page if an I/O error occurs. ``readpages`` called by the VM to read pages associated with the address_space -- cgit From a8c49af3be5f0b4e105ef678bcf14ef102c270be Mon Sep 17 00:00:00 2001 From: Yosry Ahmed Date: Tue, 22 Mar 2022 14:40:10 -0700 Subject: memcg: add per-memcg total kernel memory stat Currently memcg stats show several types of kernel memory: kernel stack, page tables, sock, vmalloc, and slab. However, there are other allocations with __GFP_ACCOUNT (or supersets such as GFP_KERNEL_ACCOUNT) that are not accounted in any of those stats, a few examples are: - various kvm allocations (e.g. allocated pages to create vcpus) - io_uring - tmp_page in pipes during pipe_write() - bpf ringbuffers - unix sockets Keeping track of the total kernel memory is essential for the ease of migration from cgroup v1 to v2 as there are large discrepancies between v1's kmem.usage_in_bytes and the sum of the available kernel memory stats in v2. Adding separate memcg stats for all __GFP_ACCOUNT kernel allocations is an impractical maintenance burden as there a lot of those all over the kernel code, with more use cases likely to show up in the future. Therefore, add a "kernel" memcg stat that is analogous to kmem page counter, with added benefits such as using rstat infrastructure which aggregates stats more efficiently. Additionally, this provides a lighter alternative in case the legacy kmem is deprecated in the future [yosryahmed@google.com: v2] Link: https://lkml.kernel.org/r/20220203193856.972500-1-yosryahmed@google.com Link: https://lkml.kernel.org/r/20220201200823.3283171-1-yosryahmed@google.com Signed-off-by: Yosry Ahmed Acked-by: Shakeel Butt Acked-by: Johannes Weiner Cc: Michal Hocko Cc: Muchun Song Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/cgroup-v2.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 5aa368d165da..69d7a6983f78 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1301,6 +1301,11 @@ PAGE_SIZE multiple when read back. Amount of memory used to cache filesystem data, including tmpfs and shared memory. + kernel (npn) + Amount of total kernel memory, including + (kernel_stack, pagetables, percpu, vmalloc, slab) in + addition to other kernel memory use cases. + kernel_stack Amount of memory allocated to kernel stacks. -- cgit From 2343e88d238f5de973d609d861c505890f94f22e Mon Sep 17 00:00:00 2001 From: Sebastian Andrzej Siewior Date: Tue, 22 Mar 2022 14:40:38 -0700 Subject: mm/memcg: disable threshold event handlers on PREEMPT_RT MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit During the integration of PREEMPT_RT support, the code flow around memcg_check_events() resulted in `twisted code'. Moving the code around and avoiding then would then lead to an additional local-irq-save section within memcg_check_events(). While looking better, it adds a local-irq-save section to code flow which is usually within an local-irq-off block on non-PREEMPT_RT configurations. The threshold event handler is a deprecated memcg v1 feature. Instead of trying to get it to work under PREEMPT_RT just disable it. There should be no users on PREEMPT_RT. From that perspective it makes even less sense to get it to work under PREEMPT_RT while having zero users. Make memory.soft_limit_in_bytes and cgroup.event_control return -EOPNOTSUPP on PREEMPT_RT. Make an empty memcg_check_events() and memcg_write_event_control() which return only -EOPNOTSUPP on PREEMPT_RT. Document that the two knobs are disabled on PREEMPT_RT. Link: https://lkml.kernel.org/r/20220226204144.1008339-3-bigeasy@linutronix.de Suggested-by: Michal Hocko Suggested-by: Michal Koutný Signed-off-by: Sebastian Andrzej Siewior Acked-by: Roman Gushchin Acked-by: Johannes Weiner Reviewed-by: Shakeel Butt Acked-by: Michal Hocko Cc: kernel test robot Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Vladimir Davydov Cc: Waiman Long Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/cgroup-v1/memory.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst index faac50149a22..2cc502a75ef6 100644 --- a/Documentation/admin-guide/cgroup-v1/memory.rst +++ b/Documentation/admin-guide/cgroup-v1/memory.rst @@ -64,6 +64,7 @@ Brief summary of control files. threads cgroup.procs show list of processes cgroup.event_control an interface for event_fd() + This knob is not available on CONFIG_PREEMPT_RT systems. memory.usage_in_bytes show current usage for memory (See 5.5 for details) memory.memsw.usage_in_bytes show current usage for memory+Swap @@ -75,6 +76,7 @@ Brief summary of control files. memory.max_usage_in_bytes show max memory usage recorded memory.memsw.max_usage_in_bytes show max memory+Swap usage recorded memory.soft_limit_in_bytes set/show soft limit of memory usage + This knob is not available on CONFIG_PREEMPT_RT systems. memory.stat show various statistics memory.use_hierarchy set/show hierarchical account enabled This knob is deprecated and shouldn't be -- cgit From 8b9f3ac5b01db85c6cf74c2c3a71280cc3045c9c Mon Sep 17 00:00:00 2001 From: Muchun Song Date: Tue, 22 Mar 2022 14:41:00 -0700 Subject: fs: introduce alloc_inode_sb() to allocate filesystems specific inode The allocated inode cache is supposed to be added to its memcg list_lru which should be allocated as well in advance. That can be done by kmem_cache_alloc_lru() which allocates object and list_lru. The file systems is main user of it. So introduce alloc_inode_sb() to allocate file system specific inodes and set up the inode reclaim context properly. The file system is supposed to use alloc_inode_sb() to allocate inodes. In later patches, we will convert all users to the new API. Link: https://lkml.kernel.org/r/20220228122126.37293-4-songmuchun@bytedance.com Signed-off-by: Muchun Song Reviewed-by: Roman Gushchin Cc: Alex Shi Cc: Anna Schumaker Cc: Chao Yu Cc: Dave Chinner Cc: Fam Zheng Cc: Jaegeuk Kim Cc: Johannes Weiner Cc: Kari Argillander Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Qi Zheng Cc: Shakeel Butt Cc: Theodore Ts'o Cc: Trond Myklebust Cc: Vladimir Davydov Cc: Vlastimil Babka Cc: Wei Yang Cc: Xiongchun Duan Cc: Yang Shi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/porting.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst index bf19fd6b86e7..7c1583dbeb59 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -45,6 +45,12 @@ typically between calling iget_locked() and unlocking the inode. At some point that will become mandatory. +**mandatory** + +The foo_inode_info should always be allocated through alloc_inode_sb() rather +than kmem_cache_alloc() or kmalloc() related to set up the inode reclaim context +correctly. + --- **mandatory** -- cgit From e7d324850bfcb30df563d144c0363cc44595277d Mon Sep 17 00:00:00 2001 From: Muchun Song Date: Tue, 22 Mar 2022 14:45:00 -0700 Subject: mm: hugetlb: free the 2nd vmemmap page associated with each HugeTLB page Patch series "Free the 2nd vmemmap page associated with each HugeTLB page", v7. This series can minimize the overhead of struct page for 2MB HugeTLB pages significantly. It further reduces the overhead of struct page by 12.5% for a 2MB HugeTLB compared to the previous approach, which means 2GB per 1TB HugeTLB. It is a nice gain. Comments and reviews are welcome. Thanks. The main implementation and details can refer to the commit log of patch 1. In this series, I have changed the following four helpers, the following table shows the impact of the overhead of those helpers. +------------------+-----------------------+ | APIs | head page | tail page | +------------------+-----------+-----------+ | PageHead() | Y | N | +------------------+-----------+-----------+ | PageTail() | Y | N | +------------------+-----------+-----------+ | PageCompound() | N | N | +------------------+-----------+-----------+ | compound_head() | Y | N | +------------------+-----------+-----------+ Y: Overhead is increased. N: Overhead is _NOT_ increased. It shows that the overhead of those helpers on a tail page don't change between "hugetlb_free_vmemmap=on" and "hugetlb_free_vmemmap=off". But the overhead on a head page will be increased when "hugetlb_free_vmemmap=on" (except PageCompound()). So I believe that Matthew Wilcox's folio series will help with this. The users of PageHead() and PageTail() are much less than compound_head() and most users of PageTail() are VM_BUG_ON(), so I have done some tests about the overhead of compound_head() on head pages. I have tested the overhead of calling compound_head() on a head page, which is 2.11ns (Measure the call time of 10 million times compound_head(), and then average). For a head page whose address is not aligned with PAGE_SIZE or a non-compound page, the overhead of compound_head() is 2.54ns which is increased by 20%. For a head page whose address is aligned with PAGE_SIZE, the overhead of compound_head() is 2.97ns which is increased by 40%. Most pages are the former. I do not think the overhead is significant since the overhead of compound_head() itself is low. This patch (of 5): This patch minimizes the overhead of struct page for 2MB HugeTLB pages significantly. It further reduces the overhead of struct page by 12.5% for a 2MB HugeTLB compared to the previous approach, which means 2GB per 1TB HugeTLB (2MB type). After the feature of "Free sonme vmemmap pages of HugeTLB page" is enabled, the mapping of the vmemmap addresses associated with a 2MB HugeTLB page becomes the figure below. HugeTLB struct pages(8 pages) page frame(8 pages) +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+---> PG_head | | | 0 | -------------> | 0 | | | +-----------+ +-----------+ | | | 1 | -------------> | 1 | | | +-----------+ +-----------+ | | | 2 | ----------------^ ^ ^ ^ ^ ^ | | +-----------+ | | | | | | | | 3 | ------------------+ | | | | | | +-----------+ | | | | | | | 4 | --------------------+ | | | | 2MB | +-----------+ | | | | | | 5 | ----------------------+ | | | | +-----------+ | | | | | 6 | ------------------------+ | | | +-----------+ | | | | 7 | --------------------------+ | | +-----------+ | | | | | | +-----------+ As we can see, the 2nd vmemmap page frame (indexed by 1) is reused and remaped. However, the 2nd vmemmap page frame is also can be freed to the buddy allocator, then we can change the mapping from the figure above to the figure below. HugeTLB struct pages(8 pages) page frame(8 pages) +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+---> PG_head | | | 0 | -------------> | 0 | | | +-----------+ +-----------+ | | | 1 | ---------------^ ^ ^ ^ ^ ^ ^ | | +-----------+ | | | | | | | | | 2 | -----------------+ | | | | | | | +-----------+ | | | | | | | | 3 | -------------------+ | | | | | | +-----------+ | | | | | | | 4 | ---------------------+ | | | | 2MB | +-----------+ | | | | | | 5 | -----------------------+ | | | | +-----------+ | | | | | 6 | -------------------------+ | | | +-----------+ | | | | 7 | ---------------------------+ | | +-----------+ | | | | | | +-----------+ After we do this, all tail vmemmap pages (1-7) are mapped to the head vmemmap page frame (0). In other words, there are more than one page struct with PG_head associated with each HugeTLB page. We __know__ that there is only one head page struct, the tail page structs with PG_head are fake head page structs. We need an approach to distinguish between those two different types of page structs so that compound_head(), PageHead() and PageTail() can work properly if the parameter is the tail page struct but with PG_head. The following code snippet describes how to distinguish between real and fake head page struct. if (test_bit(PG_head, &page->flags)) { unsigned long head = READ_ONCE(page[1].compound_head); if (head & 1) { if (head == (unsigned long)page + 1) ==> head page struct else ==> tail page struct } else ==> head page struct } We can safely access the field of the @page[1] with PG_head because the @page is a compound page composed with at least two contiguous pages. [songmuchun@bytedance.com: restore lost comment changes] Link: https://lkml.kernel.org/r/20211101031651.75851-1-songmuchun@bytedance.com Link: https://lkml.kernel.org/r/20211101031651.75851-2-songmuchun@bytedance.com Signed-off-by: Muchun Song Reviewed-by: Barry Song Cc: Mike Kravetz Cc: Oscar Salvador Cc: Michal Hocko Cc: David Hildenbrand Cc: Chen Huang Cc: Bodeddula Balasubramaniam Cc: Jonathan Corbet Cc: Matthew Wilcox Cc: Xiongchun Duan Cc: Fam Zheng Cc: Qi Zheng Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/kernel-parameters.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 7123524a86b8..bc39497f5788 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1625,7 +1625,7 @@ [KNL] Reguires CONFIG_HUGETLB_PAGE_FREE_VMEMMAP enabled. Allows heavy hugetlb users to free up some more - memory (6 * PAGE_SIZE for each 2MB hugetlb page). + memory (7 * PAGE_SIZE for each 2MB hugetlb page). Format: { on | off (default) } on: enable the feature -- cgit From c574bbe917036c8968b984c82c7b13194fe5ce98 Mon Sep 17 00:00:00 2001 From: Huang Ying Date: Tue, 22 Mar 2022 14:46:23 -0700 Subject: NUMA balancing: optimize page placement for memory tiering system With the advent of various new memory types, some machines will have multiple types of memory, e.g. DRAM and PMEM (persistent memory). The memory subsystem of these machines can be called memory tiering system, because the performance of the different types of memory are usually different. In such system, because of the memory accessing pattern changing etc, some pages in the slow memory may become hot globally. So in this patch, the NUMA balancing mechanism is enhanced to optimize the page placement among the different memory types according to hot/cold dynamically. In a typical memory tiering system, there are CPUs, fast memory and slow memory in each physical NUMA node. The CPUs and the fast memory will be put in one logical node (called fast memory node), while the slow memory will be put in another (faked) logical node (called slow memory node). That is, the fast memory is regarded as local while the slow memory is regarded as remote. So it's possible for the recently accessed pages in the slow memory node to be promoted to the fast memory node via the existing NUMA balancing mechanism. The original NUMA balancing mechanism will stop to migrate pages if the free memory of the target node becomes below the high watermark. This is a reasonable policy if there's only one memory type. But this makes the original NUMA balancing mechanism almost do not work to optimize page placement among different memory types. Details are as follows. It's the common cases that the working-set size of the workload is larger than the size of the fast memory nodes. Otherwise, it's unnecessary to use the slow memory at all. So, there are almost always no enough free pages in the fast memory nodes, so that the globally hot pages in the slow memory node cannot be promoted to the fast memory node. To solve the issue, we have 2 choices as follows, a. Ignore the free pages watermark checking when promoting hot pages from the slow memory node to the fast memory node. This will create some memory pressure in the fast memory node, thus trigger the memory reclaiming. So that, the cold pages in the fast memory node will be demoted to the slow memory node. b. Define a new watermark called wmark_promo which is higher than wmark_high, and have kswapd reclaiming pages until free pages reach such watermark. The scenario is as follows: when we want to promote hot-pages from a slow memory to a fast memory, but fast memory's free pages would go lower than high watermark with such promotion, we wake up kswapd with wmark_promo watermark in order to demote cold pages and free us up some space. So, next time we want to promote hot-pages we might have a chance of doing so. The choice "a" may create high memory pressure in the fast memory node. If the memory pressure of the workload is high, the memory pressure may become so high that the memory allocation latency of the workload is influenced, e.g. the direct reclaiming may be triggered. The choice "b" works much better at this aspect. If the memory pressure of the workload is high, the hot pages promotion will stop earlier because its allocation watermark is higher than that of the normal memory allocation. So in this patch, choice "b" is implemented. A new zone watermark (WMARK_PROMO) is added. Which is larger than the high watermark and can be controlled via watermark_scale_factor. In addition to the original page placement optimization among sockets, the NUMA balancing mechanism is extended to be used to optimize page placement according to hot/cold among different memory types. So the sysctl user space interface (numa_balancing) is extended in a backward compatible way as follow, so that the users can enable/disable these functionality individually. The sysctl is converted from a Boolean value to a bits field. The definition of the flags is, - 0: NUMA_BALANCING_DISABLED - 1: NUMA_BALANCING_NORMAL - 2: NUMA_BALANCING_MEMORY_TIERING We have tested the patch with the pmbench memory accessing benchmark with the 80:20 read/write ratio and the Gauss access address distribution on a 2 socket Intel server with Optane DC Persistent Memory Model. The test results shows that the pmbench score can improve up to 95.9%. Thanks Andrew Morton to help fix the document format error. Link: https://lkml.kernel.org/r/20220221084529.1052339-3-ying.huang@intel.com Signed-off-by: "Huang, Ying" Tested-by: Baolin Wang Reviewed-by: Baolin Wang Acked-by: Johannes Weiner Reviewed-by: Oscar Salvador Reviewed-by: Yang Shi Cc: Michal Hocko Cc: Rik van Riel Cc: Mel Gorman Cc: Peter Zijlstra Cc: Dave Hansen Cc: Zi Yan Cc: Wei Xu Cc: Shakeel Butt Cc: zhongjiang-ali Cc: Randy Dunlap Cc: Feng Tang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/sysctl/kernel.rst | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index d359bcfadd39..fdfd2b684822 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -595,16 +595,23 @@ Documentation/admin-guide/kernel-parameters.rst). numa_balancing ============== -Enables/disables automatic page fault based NUMA memory -balancing. Memory is moved automatically to nodes -that access it often. +Enables/disables and configures automatic page fault based NUMA memory +balancing. Memory is moved automatically to nodes that access it often. +The value to set can be the result of ORing the following: -Enables/disables automatic NUMA memory balancing. On NUMA machines, there -is a performance penalty if remote memory is accessed by a CPU. When this -feature is enabled the kernel samples what task thread is accessing memory -by periodically unmapping pages and later trapping a page fault. At the -time of the page fault, it is determined if the data being accessed should -be migrated to a local memory node. += ================================= +0 NUMA_BALANCING_DISABLED +1 NUMA_BALANCING_NORMAL +2 NUMA_BALANCING_MEMORY_TIERING += ================================= + +Or NUMA_BALANCING_NORMAL to optimize page placement among different +NUMA nodes to reduce remote accessing. On NUMA machines, there is a +performance penalty if remote memory is accessed by a CPU. When this +feature is enabled the kernel samples what task thread is accessing +memory by periodically unmapping pages and later trapping a page +fault. At the time of the page fault, it is determined if the data +being accessed should be migrated to a local memory node. The unmapping of pages and trapping faults incur additional overhead that ideally is offset by improved memory locality but there is no universal @@ -615,6 +622,10 @@ faults may be controlled by the `numa_balancing_scan_period_min_ms, numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms, numa_balancing_scan_size_mb`_, and numa_balancing_settle_count sysctls. +Or NUMA_BALANCING_MEMORY_TIERING to optimize page placement among +different types of memory (represented as different NUMA nodes) to +place the hot pages in the fast memory. This is implemented based on +unmapping and page fault too. numa_balancing_scan_period_min_ms, numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms, numa_balancing_scan_size_mb =============================================================================================================================== -- cgit From cb325ddde5616219848ac0e100a781919a0ce55b Mon Sep 17 00:00:00 2001 From: "Maciej S. Szmigiero" Date: Tue, 22 Mar 2022 14:47:43 -0700 Subject: mm/zswap.c: allow handling just same-value filled pages Zswap has an ability to efficiently store same-value filled pages, which can be turned on and off using the "same_filled_pages_enabled" parameter. However, there is currently no way to enable just this (lightweight) functionality, while not making use of the whole compressed page storage machinery. Add a "non_same_filled_pages_enabled" parameter which allows disabling handling of pages that aren't same-value filled. This way zswap can be run in such lightweight same-value filled pages only mode. Link: https://lkml.kernel.org/r/7dbafa963e8bab43608189abbe2067f4b9287831.1641247624.git.maciej.szmigiero@oracle.com Signed-off-by: Maciej S. Szmigiero Cc: Seth Jennings Cc: Dan Streetman Cc: Vitaly Wool Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/mm/zswap.rst | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/mm/zswap.rst b/Documentation/admin-guide/mm/zswap.rst index 8edb8d578caf..6e6f7b0d6562 100644 --- a/Documentation/admin-guide/mm/zswap.rst +++ b/Documentation/admin-guide/mm/zswap.rst @@ -130,9 +130,25 @@ attribute, e.g.:: echo 1 > /sys/module/zswap/parameters/same_filled_pages_enabled When zswap same-filled page identification is disabled at runtime, it will stop -checking for the same-value filled pages during store operation. However, the -existing pages which are marked as same-value filled pages remain stored -unchanged in zswap until they are either loaded or invalidated. +checking for the same-value filled pages during store operation. +In other words, every page will be then considered non-same-value filled. +However, the existing pages which are marked as same-value filled pages remain +stored unchanged in zswap until they are either loaded or invalidated. + +In some circumstances it might be advantageous to make use of just the zswap +ability to efficiently store same-filled pages without enabling the whole +compressed page storage. +In this case the handling of non-same-value pages by zswap (enabled by default) +can be disabled by setting the ``non_same_filled_pages_enabled`` attribute +to 0, e.g. ``zswap.non_same_filled_pages_enabled=0``. +It can also be enabled and disabled at runtime using the sysfs +``non_same_filled_pages_enabled`` attribute, e.g.:: + + echo 1 > /sys/module/zswap/parameters/non_same_filled_pages_enabled + +Disabling both ``zswap.same_filled_pages_enabled`` and +``zswap.non_same_filled_pages_enabled`` effectively disables accepting any new +pages by zswap. To prevent zswap from shrinking pool when zswap is full and there's a high pressure on swap (this will result in flipping pages in and out zswap pool -- cgit From 737b6a10ac19e41877aa1911bf6b361a72a88ad9 Mon Sep 17 00:00:00 2001 From: Marco Elver Date: Tue, 22 Mar 2022 14:48:25 -0700 Subject: kfence: allow use of a deferrable timer Allow the use of a deferrable timer, which does not force CPU wake-ups when the system is idle. A consequence is that the sample interval becomes very unpredictable, to the point that it is not guaranteed that the KFENCE KUnit test still passes. Nevertheless, on power-constrained systems this may be preferable, so let's give the user the option should they accept the above trade-off. Link: https://lkml.kernel.org/r/20220308141415.3168078-1-elver@google.com Signed-off-by: Marco Elver Reviewed-by: Alexander Potapenko Cc: Dmitry Vyukov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dev-tools/kfence.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kfence.rst b/Documentation/dev-tools/kfence.rst index ac6b89d1a8c3..936f6aaa75c8 100644 --- a/Documentation/dev-tools/kfence.rst +++ b/Documentation/dev-tools/kfence.rst @@ -41,6 +41,18 @@ guarded by KFENCE. The default is configurable via the Kconfig option ``CONFIG_KFENCE_SAMPLE_INTERVAL``. Setting ``kfence.sample_interval=0`` disables KFENCE. +The sample interval controls a timer that sets up KFENCE allocations. By +default, to keep the real sample interval predictable, the normal timer also +causes CPU wake-ups when the system is completely idle. This may be undesirable +on power-constrained systems. The boot parameter ``kfence.deferrable=1`` +instead switches to a "deferrable" timer which does not force CPU wake-ups on +idle systems, at the risk of unpredictable sample intervals. The default is +configurable via the Kconfig option ``CONFIG_KFENCE_DEFERRABLE``. + +.. warning:: + The KUnit test suite is very likely to fail when using a deferrable timer + since it currently causes very unpredictable sample intervals. + The KFENCE memory pool is of fixed size, and if the pool is exhausted, no further KFENCE allocations occur. With ``CONFIG_KFENCE_NUM_OBJECTS`` (default 255), the number of available guarded objects can be controlled. Each object -- cgit From 8041c87b915b9b7ecb2870f1c529a75aaa2483be Mon Sep 17 00:00:00 2001 From: SeongJae Park Date: Tue, 22 Mar 2022 14:48:34 -0700 Subject: Docs/admin-guide/mm/damon/usage: update for changed initail_regions file input A previous commit made init_regions debugfs file to use target index instead of target id for specifying the target of the init regions. This commit updates the usage document to reflect the change. Link: https://lkml.kernel.org/r/20211230100723.2238-3-sj@kernel.org Signed-off-by: SeongJae Park Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/mm/damon/usage.rst | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index 59b84904a854..1e06435b8ff6 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -108,19 +108,23 @@ In such cases, users can explicitly set the initial monitoring target regions as they want, by writing proper values to the ``init_regions`` file. Each line of the input should represent one region in below form.:: - + -The ``target id`` should already in ``target_ids`` file, and the regions should -be passed in address order. For example, below commands will set a couple of -address ranges, ``1-100`` and ``100-200`` as the initial monitoring target -region of process 42, and another couple of address ranges, ``20-40`` and -``50-100`` as that of process 4242.:: +The ``target idx`` should be the index of the target in ``target_ids`` file, +starting from ``0``, and the regions should be passed in address order. For +example, below commands will set a couple of address ranges, ``1-100`` and +``100-200`` as the initial monitoring target region of pid 42, which is the +first one (index ``0``) in ``target_ids``, and another couple of address +ranges, ``20-40`` and ``50-100`` as that of pid 4242, which is the second one +(index ``1``) in ``target_ids``.:: # cd /damon - # echo "42 1 100 - 42 100 200 - 4242 20 40 - 4242 50 100" > init_regions + # cat target_ids + 42 4242 + # echo "0 1 100 + 0 100 200 + 1 20 40 + 1 50 100" > init_regions Note that this sets the initial monitoring target regions only. In case of virtual memory monitoring, DAMON will automatically updates the boundary of the -- cgit From 561f4fc4972443f1273f7abbd8270fd949e6584b Mon Sep 17 00:00:00 2001 From: SeongJae Park Date: Tue, 22 Mar 2022 14:49:12 -0700 Subject: Docs/vm/damon: call low level monitoring primitives the operations Patch series "Docs/damon: Update documents for better consistency". Some of DAMON document are not properly updated for latest version. This patchset updates such parts. This patch (of 3): DAMON code calls the low level monitoring primitives implementations the monitoring operations. The documentation would have no problem at still calling those primitives implementation because there is no real difference in the concepts, but making it more consistent with the code would make it better. This commit therefore convert sentences in the doc specifically pointing the implementations of the primitives to call it monitoring operations. Link: https://lkml.kernel.org/r/20220222170100.17068-1-sj@kernel.org Link: https://lkml.kernel.org/r/20220222170100.17068-2-sj@kernel.org Signed-off-by: SeongJae Park Cc: Jonathan Corbet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/damon/design.rst | 24 ++++++++++++------------ Documentation/vm/damon/faq.rst | 2 +- 2 files changed, 13 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/damon/design.rst b/Documentation/vm/damon/design.rst index 210f0f50efd8..c406983aeb31 100644 --- a/Documentation/vm/damon/design.rst +++ b/Documentation/vm/damon/design.rst @@ -13,12 +13,13 @@ primitives that dependent on and optimized for the target address space. On the other hand, the accuracy and overhead tradeoff mechanism, which is the core of DAMON, is in the pure logic space. DAMON separates the two parts in different layers and defines its interface to allow various low level -primitives implementations configurable with the core logic. +primitives implementations configurable with the core logic. We call the low +level primitives implementations monitoring operations. Due to this separated design and the configurable interface, users can extend -DAMON for any address space by configuring the core logics with appropriate low -level primitive implementations. If appropriate one is not provided, users can -implement the primitives on their own. +DAMON for any address space by configuring the core logics with appropriate +monitoring operations. If appropriate one is not provided, users can implement +the operations on their own. For example, physical memory, virtual memory, swap space, those for specific processes, NUMA nodes, files, and backing memory devices would be supportable. @@ -26,25 +27,24 @@ Also, if some architectures or devices support special optimized access check primitives, those will be easily configurable. -Reference Implementations of Address Space Specific Primitives -============================================================== +Reference Implementations of Address Space Specific Monitoring Operations +========================================================================= -The low level primitives for the fundamental access monitoring are defined in -two parts: +The monitoring operations are defined in two parts: 1. Identification of the monitoring target address range for the address space. 2. Access check of specific address range in the target space. -DAMON currently provides the implementations of the primitives for the physical +DAMON currently provides the implementations of the operations for the physical and virtual address spaces. Below two subsections describe how those work. VMA-based Target Address Range Construction ------------------------------------------- -This is only for the virtual address space primitives implementation. That for -the physical address space simply asks users to manually set the monitoring -target address ranges. +This is only for the virtual address space monitoring operations +implementation. That for the physical address space simply asks users to +manually set the monitoring target address ranges. Only small parts in the super-huge virtual address space of the processes are mapped to the physical memory and accessed. Thus, tracking the unmapped diff --git a/Documentation/vm/damon/faq.rst b/Documentation/vm/damon/faq.rst index 11aea40eb328..dde7e2414ee6 100644 --- a/Documentation/vm/damon/faq.rst +++ b/Documentation/vm/damon/faq.rst @@ -31,7 +31,7 @@ Does DAMON support virtual memory only? ======================================= No. The core of the DAMON is address space independent. The address space -specific low level primitive parts including monitoring target regions +specific monitoring operations including monitoring target regions constructions and actual access checks can be implemented and configured on the DAMON core by the users. In this way, DAMON users can monitor any address space with any access check technique. -- cgit From 742cc2bfce5a94ad629a3a0bd408ef61c8be2826 Mon Sep 17 00:00:00 2001 From: SeongJae Park Date: Tue, 22 Mar 2022 14:49:15 -0700 Subject: Docs/vm/damon/design: update DAMON-Idle Page Tracking interference handling In DAMON's early development stage before it be merged in the mainline, it was first designed to work exclusively with Idle page tracking to avoid any interference between each other. Later, but still before be merged in the mainline, because Idle page tracking is fully under the control of sysadmins, we made the resolving of conflict as the responsibility of sysadmins. The document is not updated for the change, though. This commit updates the document for that. Link: https://lkml.kernel.org/r/20220222170100.17068-3-sj@kernel.org Signed-off-by: SeongJae Park Cc: Jonathan Corbet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/damon/design.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/damon/design.rst b/Documentation/vm/damon/design.rst index c406983aeb31..bba89632e924 100644 --- a/Documentation/vm/damon/design.rst +++ b/Documentation/vm/damon/design.rst @@ -84,9 +84,10 @@ table having a mapping to the address. In this way, the implementations find and clear the bit(s) for next sampling target address and checks whether the bit(s) set again after one sampling period. This could disturb other kernel subsystems using the Accessed bits, namely Idle page tracking and the reclaim -logic. To avoid such disturbances, DAMON makes it mutually exclusive with Idle -page tracking and uses ``PG_idle`` and ``PG_young`` page flags to solve the -conflict with the reclaim logic, as Idle page tracking does. +logic. DAMON does nothing to avoid disturbing Idle page tracking, so handling +the interference is the responsibility of sysadmins. However, it solves the +conflict with the reclaim logic using ``PG_idle`` and ``PG_young`` page flags, +as Idle page tracking does. Address Space Independent Core Mechanisms -- cgit From 4c1f287f8c80268a870d8a51012ac4adf8fcbec5 Mon Sep 17 00:00:00 2001 From: SeongJae Park Date: Tue, 22 Mar 2022 14:49:18 -0700 Subject: Docs/damon: update outdated term 'regions update interval' Before DAMON is merged in the mainline, the concept of 'regions update interval' has generalized to be used as the time interval for update of any monitoring operations related data structure, but the document has not updated properly. This commit updates the document for better consistency. Link: https://lkml.kernel.org/r/20220222170100.17068-4-sj@kernel.org Signed-off-by: SeongJae Park Cc: Jonathan Corbet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/mm/damon/usage.rst | 6 +++--- Documentation/vm/damon/design.rst | 12 +++++++----- 2 files changed, 10 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index 1e06435b8ff6..b6ec650873b2 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -47,7 +47,7 @@ Attributes ---------- Users can get and set the ``sampling interval``, ``aggregation interval``, -``regions update interval``, and min/max number of monitoring target regions by +``update interval``, and min/max number of monitoring target regions by reading from and writing to the ``attrs`` file. To know about the monitoring attributes in detail, please refer to the :doc:`/vm/damon/design`. For example, below commands set those values to 5 ms, 100 ms, 1,000 ms, 10 and @@ -128,8 +128,8 @@ ranges, ``20-40`` and ``50-100`` as that of pid 4242, which is the second one Note that this sets the initial monitoring target regions only. In case of virtual memory monitoring, DAMON will automatically updates the boundary of the -regions after one ``regions update interval``. Therefore, users should set the -``regions update interval`` large enough in this case, if they don't want the +regions after one ``update interval``. Therefore, users should set the +``update interval`` large enough in this case, if they don't want the update. diff --git a/Documentation/vm/damon/design.rst b/Documentation/vm/damon/design.rst index bba89632e924..0cff6fac6b7e 100644 --- a/Documentation/vm/damon/design.rst +++ b/Documentation/vm/damon/design.rst @@ -95,8 +95,8 @@ Address Space Independent Core Mechanisms Below four sections describe each of the DAMON core mechanisms and the five monitoring attributes, ``sampling interval``, ``aggregation interval``, -``regions update interval``, ``minimum number of regions``, and ``maximum -number of regions``. +``update interval``, ``minimum number of regions``, and ``maximum number of +regions``. Access Frequency Monitoring @@ -169,6 +169,8 @@ The monitoring target address range could dynamically changed. For example, virtual memory could be dynamically mapped and unmapped. Physical memory could be hot-plugged. -As the changes could be quite frequent in some cases, DAMON checks the dynamic -memory mapping changes and applies it to the abstracted target area only for -each of a user-specified time interval (``regions update interval``). +As the changes could be quite frequent in some cases, DAMON allows the +monitoring operations to check dynamic changes including memory mapping changes +and applies it to monitoring operations-related data structures such as the +abstracted monitoring target memory area only for each of a user-specified time +interval (``update interval``). -- cgit From b18402726bd10e122c65eecc244ca1cdcb868cc8 Mon Sep 17 00:00:00 2001 From: SeongJae Park Date: Tue, 22 Mar 2022 14:49:55 -0700 Subject: Docs/admin-guide/mm/damon/usage: document DAMON sysfs interface This commit adds detailed usage of DAMON sysfs interface in the admin-guide document for DAMON. Link: https://lkml.kernel.org/r/20220228081314.5770-13-sj@kernel.org Signed-off-by: SeongJae Park Cc: David Rientjes Cc: Greg Kroah-Hartman Cc: Jonathan Corbet Cc: Shuah Khan Cc: Xin Hao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/mm/damon/usage.rst | 350 ++++++++++++++++++++++++++- 1 file changed, 344 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index b6ec650873b2..592ea9a50881 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -4,7 +4,7 @@ Detailed Usages =============== -DAMON provides below three interfaces for different users. +DAMON provides below interfaces for different users. - *DAMON user space tool.* `This `_ is for privileged people such as @@ -14,17 +14,21 @@ DAMON provides below three interfaces for different users. virtual and physical address spaces monitoring. For more detail, please refer to its `usage document `_. -- *debugfs interface.* - :ref:`This ` is for privileged user space programmers who +- *sysfs interface.* + :ref:`This ` is for privileged user space programmers who want more optimized use of DAMON. Using this, users can use DAMON’s major - features by reading from and writing to special debugfs files. Therefore, - you can write and use your personalized DAMON debugfs wrapper programs that - reads/writes the debugfs files instead of you. The `DAMON user space tool + features by reading from and writing to special sysfs files. Therefore, + you can write and use your personalized DAMON sysfs wrapper programs that + reads/writes the sysfs files instead of you. The `DAMON user space tool `_ is one example of such programs. It supports both virtual and physical address spaces monitoring. Note that this interface provides only simple :ref:`statistics ` for the monitoring results. For detailed monitoring results, DAMON provides a :ref:`tracepoint `. +- *debugfs interface.* + :ref:`This ` is almost identical to :ref:`sysfs interface + `. This will be removed after next LTS kernel is released, + so users should move to the :ref:`sysfs interface `. - *Kernel Space Programming Interface.* :doc:`This ` is for kernel space programmers. Using this, users can utilize every feature of DAMON most flexibly and efficiently by @@ -32,6 +36,340 @@ DAMON provides below three interfaces for different users. DAMON for various address spaces. For detail, please refer to the interface :doc:`document `. +.. _sysfs_interface: + +sysfs Interface +=============== + +DAMON sysfs interface is built when ``CONFIG_DAMON_SYSFS`` is defined. It +creates multiple directories and files under its sysfs directory, +``/kernel/mm/damon/``. You can control DAMON by writing to and reading +from the files under the directory. + +For a short example, users can monitor the virtual address space of a given +workload as below. :: + + # cd /sys/kernel/mm/damon/admin/ + # echo 1 > kdamonds/nr && echo 1 > kdamonds/0/contexts/nr + # echo vaddr > kdamonds/0/contexts/0/operations + # echo 1 > kdamonds/0/contexts/0/targets/nr + # echo $(pidof ) > kdamonds/0/contexts/0/targets/0/pid + # echo on > kdamonds/0/state + +Files Hierarchy +--------------- + +The files hierarchy of DAMON sysfs interface is shown below. In the below +figure, parents-children relations are represented with indentations, each +directory is having ``/`` suffix, and files in each directory are separated by +comma (","). :: + + /sys/kernel/mm/damon/admin + │ kdamonds/nr_kdamonds + │ │ 0/state,pid + │ │ │ contexts/nr_contexts + │ │ │ │ 0/operations + │ │ │ │ │ monitoring_attrs/ + │ │ │ │ │ │ intervals/sample_us,aggr_us,update_us + │ │ │ │ │ │ nr_regions/min,max + │ │ │ │ │ targets/nr_targets + │ │ │ │ │ │ 0/pid_target + │ │ │ │ │ │ │ regions/nr_regions + │ │ │ │ │ │ │ │ 0/start,end + │ │ │ │ │ │ │ │ ... + │ │ │ │ │ │ ... + │ │ │ │ │ schemes/nr_schemes + │ │ │ │ │ │ 0/action + │ │ │ │ │ │ │ access_pattern/ + │ │ │ │ │ │ │ │ sz/min,max + │ │ │ │ │ │ │ │ nr_accesses/min,max + │ │ │ │ │ │ │ │ age/min,max + │ │ │ │ │ │ │ quotas/ms,bytes,reset_interval_ms + │ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil + │ │ │ │ │ │ │ watermarks/metric,interval_us,high,mid,low + │ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds + │ │ │ │ │ │ ... + │ │ │ │ ... + │ │ ... + +Root +---- + +The root of the DAMON sysfs interface is ``/kernel/mm/damon/``, and it +has one directory named ``admin``. The directory contains the files for +privileged user space programs' control of DAMON. User space tools or deamons +having the root permission could use this directory. + +kdamonds/ +--------- + +The monitoring-related information including request specifications and results +are called DAMON context. DAMON executes each context with a kernel thread +called kdamond, and multiple kdamonds could run in parallel. + +Under the ``admin`` directory, one directory, ``kdamonds``, which has files for +controlling the kdamonds exist. In the beginning, this directory has only one +file, ``nr_kdamonds``. Writing a number (``N``) to the file creates the number +of child directories named ``0`` to ``N-1``. Each directory represents each +kdamond. + +kdamonds// +------------- + +In each kdamond directory, two files (``state`` and ``pid``) and one directory +(``contexts``) exist. + +Reading ``state`` returns ``on`` if the kdamond is currently running, or +``off`` if it is not running. Writing ``on`` or ``off`` makes the kdamond be +in the state. Writing ``update_schemes_stats`` to ``state`` file updates the +contents of stats files for each DAMON-based operation scheme of the kdamond. +For details of the stats, please refer to :ref:`stats section +`. + +If the state is ``on``, reading ``pid`` shows the pid of the kdamond thread. + +``contexts`` directory contains files for controlling the monitoring contexts +that this kdamond will execute. + +kdamonds//contexts/ +---------------------- + +In the beginning, this directory has only one file, ``nr_contexts``. Writing a +number (``N``) to the file creates the number of child directories named as +``0`` to ``N-1``. Each directory represents each monitoring context. At the +moment, only one context per kdamond is supported, so only ``0`` or ``1`` can +be written to the file. + +contexts// +------------- + +In each context directory, one file (``operations``) and three directories +(``monitoring_attrs``, ``targets``, and ``schemes``) exist. + +DAMON supports multiple types of monitoring operations, including those for +virtual address space and the physical address space. You can set and get what +type of monitoring operations DAMON will use for the context by writing one of +below keywords to, and reading from the file. + + - vaddr: Monitor virtual address spaces of specific processes + - paddr: Monitor the physical address space of the system + +contexts//monitoring_attrs/ +------------------------------ + +Files for specifying attributes of the monitoring including required quality +and efficiency of the monitoring are in ``monitoring_attrs`` directory. +Specifically, two directories, ``intervals`` and ``nr_regions`` exist in this +directory. + +Under ``intervals`` directory, three files for DAMON's sampling interval +(``sample_us``), aggregation interval (``aggr_us``), and update interval +(``update_us``) exist. You can set and get the values in micro-seconds by +writing to and reading from the files. + +Under ``nr_regions`` directory, two files for the lower-bound and upper-bound +of DAMON's monitoring regions (``min`` and ``max``, respectively), which +controls the monitoring overhead, exist. You can set and get the values by +writing to and rading from the files. + +For more details about the intervals and monitoring regions range, please refer +to the Design document (:doc:`/vm/damon/design`). + +contexts//targets/ +--------------------- + +In the beginning, this directory has only one file, ``nr_targets``. Writing a +number (``N``) to the file creates the number of child directories named ``0`` +to ``N-1``. Each directory represents each monitoring target. + +targets// +------------ + +In each target directory, one file (``pid_target``) and one directory +(``regions``) exist. + +If you wrote ``vaddr`` to the ``contexts//operations``, each target should +be a process. You can specify the process to DAMON by writing the pid of the +process to the ``pid_target`` file. + +targets//regions +------------------- + +When ``vaddr`` monitoring operations set is being used (``vaddr`` is written to +the ``contexts//operations`` file), DAMON automatically sets and updates the +monitoring target regions so that entire memory mappings of target processes +can be covered. However, users could want to set the initial monitoring region +to specific address ranges. + +In contrast, DAMON do not automatically sets and updates the monitoring target +regions when ``paddr`` monitoring operations set is being used (``paddr`` is +written to the ``contexts//operations``). Therefore, users should set the +monitoring target regions by themselves in the case. + +For such cases, users can explicitly set the initial monitoring target regions +as they want, by writing proper values to the files under this directory. + +In the beginning, this directory has only one file, ``nr_regions``. Writing a +number (``N``) to the file creates the number of child directories named ``0`` +to ``N-1``. Each directory represents each initial monitoring target region. + +regions// +------------ + +In each region directory, you will find two files (``start`` and ``end``). You +can set and get the start and end addresses of the initial monitoring target +region by writing to and reading from the files, respectively. + +contexts//schemes/ +--------------------- + +For usual DAMON-based data access aware memory management optimizations, users +would normally want the system to apply a memory management action to a memory +region of a specific access pattern. DAMON receives such formalized operation +schemes from the user and applies those to the target memory regions. Users +can get and set the schemes by reading from and writing to files under this +directory. + +In the beginning, this directory has only one file, ``nr_schemes``. Writing a +number (``N``) to the file creates the number of child directories named ``0`` +to ``N-1``. Each directory represents each DAMON-based operation scheme. + +schemes// +------------ + +In each scheme directory, four directories (``access_pattern``, ``quotas``, +``watermarks``, and ``stats``) and one file (``action``) exist. + +The ``action`` file is for setting and getting what action you want to apply to +memory regions having specific access pattern of the interest. The keywords +that can be written to and read from the file and their meaning are as below. + + - ``willneed``: Call ``madvise()`` for the region with ``MADV_WILLNEED`` + - ``cold``: Call ``madvise()`` for the region with ``MADV_COLD`` + - ``pageout``: Call ``madvise()`` for the region with ``MADV_PAGEOUT`` + - ``hugepage``: Call ``madvise()`` for the region with ``MADV_HUGEPAGE`` + - ``nohugepage``: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE`` + - ``stat``: Do nothing but count the statistics + +schemes//access_pattern/ +--------------------------- + +The target access pattern of each DAMON-based operation scheme is constructed +with three ranges including the size of the region in bytes, number of +monitored accesses per aggregate interval, and number of aggregated intervals +for the age of the region. + +Under the ``access_pattern`` directory, three directories (``sz``, +``nr_accesses``, and ``age``) each having two files (``min`` and ``max``) +exist. You can set and get the access pattern for the given scheme by writing +to and reading from the ``min`` and ``max`` files under ``sz``, +``nr_accesses``, and ``age`` directories, respectively. + +schemes//quotas/ +------------------- + +Optimal ``target access pattern`` for each ``action`` is workload dependent, so +not easy to find. Worse yet, setting a scheme of some action too aggressive +can cause severe overhead. To avoid such overhead, users can limit time and +size quota for each scheme. In detail, users can ask DAMON to try to use only +up to specific time (``time quota``) for applying the action, and to apply the +action to only up to specific amount (``size quota``) of memory regions having +the target access pattern within a given time interval (``reset interval``). + +When the quota limit is expected to be exceeded, DAMON prioritizes found memory +regions of the ``target access pattern`` based on their size, access frequency, +and age. For personalized prioritization, users can set the weights for the +three properties. + +Under ``quotas`` directory, three files (``ms``, ``bytes``, +``reset_interval_ms``) and one directory (``weights``) having three files +(``sz_permil``, ``nr_accesses_permil``, and ``age_permil``) in it exist. + +You can set the ``time quota`` in milliseconds, ``size quota`` in bytes, and +``reset interval`` in milliseconds by writing the values to the three files, +respectively. You can also set the prioritization weights for size, access +frequency, and age in per-thousand unit by writing the values to the three +files under the ``weights`` directory. + +schemes//watermarks/ +----------------------- + +To allow easy activation and deactivation of each scheme based on system +status, DAMON provides a feature called watermarks. The feature receives five +values called ``metric``, ``interval``, ``high``, ``mid``, and ``low``. The +``metric`` is the system metric such as free memory ratio that can be measured. +If the metric value of the system is higher than the value in ``high`` or lower +than ``low`` at the memoent, the scheme is deactivated. If the value is lower +than ``mid``, the scheme is activated. + +Under the watermarks directory, five files (``metric``, ``interval_us``, +``high``, ``mid``, and ``low``) for setting each value exist. You can set and +get the five values by writing to the files, respectively. + +Keywords and meanings of those that can be written to the ``metric`` file are +as below. + + - none: Ignore the watermarks + - free_mem_rate: System's free memory rate (per thousand) + +The ``interval`` should written in microseconds unit. + +.. _sysfs_schemes_stats: + +schemes//stats/ +------------------ + +DAMON counts the total number and bytes of regions that each scheme is tried to +be applied, the two numbers for the regions that each scheme is successfully +applied, and the total number of the quota limit exceeds. This statistics can +be used for online analysis or tuning of the schemes. + +The statistics can be retrieved by reading the files under ``stats`` directory +(``nr_tried``, ``sz_tried``, ``nr_applied``, ``sz_applied``, and +``qt_exceeds``), respectively. The files are not updated in real time, so you +should ask DAMON sysfs interface to updte the content of the files for the +stats by writing a special keyword, ``update_schemes_stats`` to the relevant +``kdamonds//state`` file. + +Example +~~~~~~~ + +Below commands applies a scheme saying "If a memory region of size in [4KiB, +8KiB] is showing accesses per aggregate interval in [0, 5] for aggregate +interval in [10, 20], page out the region. For the paging out, use only up to +10ms per second, and also don't page out more than 1GiB per second. Under the +limitation, page out memory regions having longer age first. Also, check the +free memory rate of the system every 5 seconds, start the monitoring and paging +out when the free memory rate becomes lower than 50%, but stop it if the free +memory rate becomes larger than 60%, or lower than 30%". :: + + # cd /kernel/mm/damon/admin + # # populate directories + # echo 1 > kdamonds/nr_kdamonds; echo 1 > kdamonds/0/contexts/nr_contexts; + # echo 1 > kdamonds/0/contexts/0/schemes/nr_schemes + # cd kdamonds/0/contexts/0/schemes/0 + # # set the basic access pattern and the action + # echo 4096 > access_patterns/sz/min + # echo 8192 > access_patterns/sz/max + # echo 0 > access_patterns/nr_accesses/min + # echo 5 > access_patterns/nr_accesses/max + # echo 10 > access_patterns/age/min + # echo 20 > access_patterns/age/max + # echo pageout > action + # # set quotas + # echo 10 > quotas/ms + # echo $((1024*1024*1024)) > quotas/bytes + # echo 1000 > quotas/reset_interval_ms + # # set watermark + # echo free_mem_rate > watermarks/metric + # echo 5000000 > watermarks/interval_us + # echo 600 > watermarks/high + # echo 500 > watermarks/mid + # echo 300 > watermarks/low + +Please note that it's highly recommended to use user space tools like `damo +`_ rather than manually reading and writing +the files as above. Above is only for an example. .. _debugfs_interface: -- cgit From f968c6a4c66ec25e97ca8801eada103abfe9b295 Mon Sep 17 00:00:00 2001 From: SeongJae Park Date: Tue, 22 Mar 2022 14:49:58 -0700 Subject: Docs/ABI/testing: add DAMON sysfs interface ABI document This commit adds DAMON sysfs interface ABI document under Documentation/ABI/testing. Link: https://lkml.kernel.org/r/20220228081314.5770-14-sj@kernel.org Signed-off-by: SeongJae Park Cc: David Rientjes Cc: Greg Kroah-Hartman Cc: Jonathan Corbet Cc: Shuah Khan Cc: Xin Hao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/ABI/testing/sysfs-kernel-mm-damon | 274 ++++++++++++++++++++++++ 1 file changed, 274 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-kernel-mm-damon (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon new file mode 100644 index 000000000000..9e282065cbcf --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon @@ -0,0 +1,274 @@ +what: /sys/kernel/mm/damon/ +Date: Mar 2022 +Contact: SeongJae Park +Description: Interface for Data Access MONitoring (DAMON). Contains files + for controlling DAMON. For more details on DAMON itself, + please refer to Documentation/admin-guide/mm/damon/index.rst. + +What: /sys/kernel/mm/damon/admin/ +Date: Mar 2022 +Contact: SeongJae Park +Description: Interface for privileged users of DAMON. Contains files for + controlling DAMON that aimed to be used by privileged users. + +What: /sys/kernel/mm/damon/admin/kdamonds/nr_kdamonds +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing a number 'N' to this file creates the number of + directories for controlling each DAMON worker thread (kdamond) + named '0' to 'N-1' under the kdamonds/ directory. + +What: /sys/kernel/mm/damon/admin/kdamonds//state +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing 'on' or 'off' to this file makes the kdamond starts or + stops, respectively. Reading the file returns the keywords + based on the current status. Writing 'update_schemes_stats' to + the file updates contents of schemes stats files of the + kdamond. + +What: /sys/kernel/mm/damon/admin/kdamonds//pid +Date: Mar 2022 +Contact: SeongJae Park +Description: Reading this file returns the pid of the kdamond if it is + running. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts/nr_contexts +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing a number 'N' to this file creates the number of + directories for controlling each DAMON context named '0' to + 'N-1' under the contexts/ directory. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//operations +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing a keyword for a monitoring operations set ('vaddr' for + virtual address spaces monitoring, and 'paddr' for the physical + address space monitoring) to this file makes the context to use + the operations set. Reading the file returns the keyword for + the operations set the context is set to use. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//monitoring_attrs/intervals/sample_us +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing a value to this file sets the sampling interval of the + DAMON context in microseconds as the value. Reading this file + returns the value. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//monitoring_attrs/intervals/aggr_us +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing a value to this file sets the aggregation interval of + the DAMON context in microseconds as the value. Reading this + file returns the value. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//monitoring_attrs/intervals/update_us +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing a value to this file sets the update interval of the + DAMON context in microseconds as the value. Reading this file + returns the value. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//monitoring_attrs/nr_regions/min + +WDate: Mar 2022 +Contact: SeongJae Park +Description: Writing a value to this file sets the minimum number of + monitoring regions of the DAMON context as the value. Reading + this file returns the value. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//monitoring_attrs/nr_regions/max +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing a value to this file sets the maximum number of + monitoring regions of the DAMON context as the value. Reading + this file returns the value. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//targets/nr_targets +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing a number 'N' to this file creates the number of + directories for controlling each DAMON target of the context + named '0' to 'N-1' under the contexts/ directory. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//targets//pid_target +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the pid of + the target process if the context is for virtual address spaces + monitoring, respectively. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//targets//regions/nr_regions +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing a number 'N' to this file creates the number of + directories for setting each DAMON target memory region of the + context named '0' to 'N-1' under the regions/ directory. In + case of the virtual address space monitoring, DAMON + automatically sets the target memory region based on the target + processes' mappings. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//targets//regions//start +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the start + address of the monitoring region. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//targets//regions//end +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the end + address of the monitoring region. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes/nr_schemes +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing a number 'N' to this file creates the number of + directories for controlling each DAMON-based operation scheme + of the context named '0' to 'N-1' under the schemes/ directory. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//action +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the action + of the scheme. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//access_pattern/sz/min +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the mimimum + size of the scheme's target regions in bytes. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//access_pattern/sz/max +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the maximum + size of the scheme's target regions in bytes. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//access_pattern/nr_accesses/min +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the manimum + 'nr_accesses' of the scheme's target regions. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//access_pattern/nr_accesses/max +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the maximum + 'nr_accesses' of the scheme's target regions. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//access_pattern/age/min +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the minimum + 'age' of the scheme's target regions. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//access_pattern/age/max +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the maximum + 'age' of the scheme's target regions. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/ms +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the time + quota of the scheme in milliseconds. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/bytes +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the size + quota of the scheme in bytes. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/reset_interval_ms +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the quotas + charge reset interval of the scheme in milliseconds. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/weights/sz_permil +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the + under-quota limit regions prioritization weight for 'size' in + permil. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/weights/nr_accesses_permil +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the + under-quota limit regions prioritization weight for + 'nr_accesses' in permil. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//quotas/weights/age_permil +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the + under-quota limit regions prioritization weight for 'age' in + permil. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//watermarks/metric +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the metric + of the watermarks for the scheme. The writable/readable + keywords for this file are 'none' for disabling the watermarks + feature, or 'free_mem_rate' for the system's global free memory + rate in permil. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//watermarks/interval_us +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the metric + check interval of the watermarks for the scheme in + microseconds. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//watermarks/high +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the high + watermark of the scheme in permil. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//watermarks/mid +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the mid + watermark of the scheme in permil. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//watermarks/low +Date: Mar 2022 +Contact: SeongJae Park +Description: Writing to and reading from this file sets and gets the low + watermark of the scheme in permil. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//stats/nr_tried +Date: Mar 2022 +Contact: SeongJae Park +Description: Reading this file returns the number of regions that the action + of the scheme has tried to be applied. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//stats/sz_tried +Date: Mar 2022 +Contact: SeongJae Park +Description: Reading this file returns the total size of regions that the + action of the scheme has tried to be applied in bytes. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//stats/nr_applied +Date: Mar 2022 +Contact: SeongJae Park +Description: Reading this file returns the number of regions that the action + of the scheme has successfully applied. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//stats/sz_applied +Date: Mar 2022 +Contact: SeongJae Park +Description: Reading this file returns the total size of regions that the + action of the scheme has successfully applied in bytes. + +What: /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes//stats/qt_exceeds +Date: Mar 2022 +Contact: SeongJae Park +Description: Reading this file returns the number of the exceed events of + the scheme's quotas. -- cgit From 9876ef1d7ea038a9d0a6cb850cc8b12f9098dc45 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Mon, 28 Feb 2022 16:15:37 -0600 Subject: dt-bindings: Add compatibles for undocumented trivial syscons 'intel,lgm-syscon', 'marvell,armada-3700-usb2-host-misc', 'mediatek,mt8135-pctl-a-syscfg', and 'mediatek,mt8135-pctl-b-syscfg' are all used in DT binding examples and/or dts files, but are not documented. Add them to syscon.yaml as they are all trivial cases. Signed-off-by: Rob Herring Reviewed-by: Matthias Brugger Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220228221537.1700071-1-robh@kernel.org --- Documentation/devicetree/bindings/mfd/syscon.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index eeac1cbc5a17..29d4a97f7108 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -44,6 +44,10 @@ properties: - hisilicon,hi6220-sramctrl - hisilicon,pcie-sas-subctrl - hisilicon,peri-subctrl + - intel,lgm-syscon + - marvell,armada-3700-usb2-host-misc + - mediatek,mt8135-pctl-a-syscfg + - mediatek,mt8135-pctl-b-syscfg - microchip,sparx5-cpu-syscon - mstar,msc313-pmsleep - rockchip,px30-qos -- cgit From e7391b021e3f7bac37ec485f2ed1ca6787a800a7 Mon Sep 17 00:00:00 2001 From: Rafał Miłecki Date: Wed, 16 Feb 2022 12:29:28 +0100 Subject: dt-bindings: mfd: brcm,cru: Rename pinctrl node MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This matches pinctrl.yaml requirement and fixes: Documentation/devicetree/bindings/mfd/brcm,cru.example.dt.yaml: pin-controller@1c0: $nodename:0: 'pin-controller@1c0' does not match '^(pinctrl|pinmux)(@[0-9a-f]+)?$' From schema: Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml Signed-off-by: Rafał Miłecki Reviewed-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220216112928.5330-1-zajec5@gmail.com --- Documentation/devicetree/bindings/mfd/brcm,cru.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml index be4a2df71c25..b85819fbb07c 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml @@ -39,7 +39,7 @@ patternProperties: '^phy@[a-f0-9]+$': $ref: ../phy/bcm-ns-usb2-phy.yaml - '^pin-controller@[a-f0-9]+$': + '^pinctrl@[a-f0-9]+$': $ref: ../pinctrl/brcm,ns-pinmux.yaml '^syscon@[a-f0-9]+$': @@ -94,7 +94,7 @@ examples: reg = <0x180 0x4>; }; - pin-controller@1c0 { + pinctrl@1c0 { compatible = "brcm,bcm4708-pinmux"; reg = <0x1c0 0x24>; reg-names = "cru_gpio_control"; -- cgit From d99460ed5cdcc28feba6b992630b04650e410902 Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Sun, 13 Mar 2022 01:31:22 +0100 Subject: dt-bindings: mfd: syscon: Add microchip,lan966x-cpu-syscon compatible Add the Microchip LAN966x CPU system registers compatible. Signed-off-by: Michael Walle Acked-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220313003122.19155-1-michael@walle.cc --- Documentation/devicetree/bindings/mfd/syscon.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index 29d4a97f7108..13baa452cc9d 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -48,6 +48,7 @@ properties: - marvell,armada-3700-usb2-host-misc - mediatek,mt8135-pctl-a-syscfg - mediatek,mt8135-pctl-b-syscfg + - microchip,lan966x-cpu-syscon - microchip,sparx5-cpu-syscon - mstar,msc313-pmsleep - rockchip,px30-qos -- cgit From eb74f47bb6b0c0494d7c90491ee321f3b699f93f Mon Sep 17 00:00:00 2001 From: Alexandre Belloni Date: Tue, 8 Mar 2022 16:57:35 +0100 Subject: dt-bindings: rtc: at91: rename rtt bindings file atmel,at91sam9-rtc is a confusing name for this file as it is documenting the RTT used as an RTC and not the other regular RTC (atmel,at91rm9200-rtc and atmel,at91sam9x5-rtc) Signed-off-by: Alexandre Belloni Acked-by: Nicolas Ferre Link: https://lore.kernel.org/r/20220308155735.54146-1-alexandre.belloni@bootlin.com --- .../bindings/rtc/atmel,at91sam9-rtc.yaml | 69 ---------------------- .../bindings/rtc/atmel,at91sam9260-rtt.yaml | 69 ++++++++++++++++++++++ 2 files changed, 69 insertions(+), 69 deletions(-) delete mode 100644 Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.yaml create mode 100644 Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.yaml b/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.yaml deleted file mode 100644 index e5c3c384e172..000000000000 --- a/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.yaml +++ /dev/null @@ -1,69 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/rtc/atmel,at91sam9-rtc.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Atmel AT91 RTT Device Tree Bindings - -allOf: - - $ref: "rtc.yaml#" - -maintainers: - - Alexandre Belloni - -properties: - compatible: - oneOf: - - items: - - const: atmel,at91sam9260-rtt - - items: - - const: microchip,sam9x60-rtt - - const: atmel,at91sam9260-rtt - - items: - - const: microchip,sama7g5-rtt - - const: microchip,sam9x60-rtt - - const: atmel,at91sam9260-rtt - - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - - clocks: - maxItems: 1 - - atmel,rtt-rtc-time-reg: - $ref: /schemas/types.yaml#/definitions/phandle-array - items: - - items: - - description: Phandle to the GPBR node. - - description: Offset within the GPBR block. - description: - Should encode the GPBR register used to store the time base when the - RTT is used as an RTC. The first cell should point to the GPBR node - and the second one encodes the offset within the GPBR block (or in - other words, the GPBR register used to store the time base). - -required: - - compatible - - reg - - interrupts - - clocks - - atmel,rtt-rtc-time-reg - -unevaluatedProperties: false - -examples: - - | - #include - - rtc@fffffd20 { - compatible = "atmel,at91sam9260-rtt"; - reg = <0xfffffd20 0x10>; - interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>; - clocks = <&clk32k>; - atmel,rtt-rtc-time-reg = <&gpbr 0x0>; - }; diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml b/Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml new file mode 100644 index 000000000000..0ef1b7ff4a77 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/atmel,at91sam9260-rtt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel AT91 RTT Device Tree Bindings + +allOf: + - $ref: "rtc.yaml#" + +maintainers: + - Alexandre Belloni + +properties: + compatible: + oneOf: + - items: + - const: atmel,at91sam9260-rtt + - items: + - const: microchip,sam9x60-rtt + - const: atmel,at91sam9260-rtt + - items: + - const: microchip,sama7g5-rtt + - const: microchip,sam9x60-rtt + - const: atmel,at91sam9260-rtt + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + atmel,rtt-rtc-time-reg: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: Phandle to the GPBR node. + - description: Offset within the GPBR block. + description: + Should encode the GPBR register used to store the time base when the + RTT is used as an RTC. The first cell should point to the GPBR node + and the second one encodes the offset within the GPBR block (or in + other words, the GPBR register used to store the time base). + +required: + - compatible + - reg + - interrupts + - clocks + - atmel,rtt-rtc-time-reg + +unevaluatedProperties: false + +examples: + - | + #include + + rtc@fffffd20 { + compatible = "atmel,at91sam9260-rtt"; + reg = <0xfffffd20 0x10>; + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>; + clocks = <&clk32k>; + atmel,rtt-rtc-time-reg = <&gpbr 0x0>; + }; -- cgit From 5db1c2dbc04c161d9e6b3f93457452e2ee904bde Mon Sep 17 00:00:00 2001 From: Rafał Miłecki Date: Mon, 28 Feb 2022 14:12:50 +0100 Subject: dt-bindings: nvmem: add U-Boot environment variables binding MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit U-Boot uses environment variables for storing device setup data. It usually needs to be accessed by a bootloader, kernel and often user-space. This binding allows describing environment data located in a raw flash partition. It's treated as NVMEM device and can be reused later for other storage devices. Using DT should be cleaner than hardcoding & duplicating such info in multiple places. Bootloader & kernel can share DTS and user-space can try reading it too or just have correct data exposed by a kernel. A custom "compatible" string allows system to automatically load relevant NVMEM driver but phandle can be also used for reading raw location. Signed-off-by: Rafał Miłecki Reviewed-by: Tom Rini Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220228131250.16943-1-zajec5@gmail.com --- .../devicetree/bindings/nvmem/u-boot,env.yaml | 62 ++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvmem/u-boot,env.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml new file mode 100644 index 000000000000..e70b2a60cb9a --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/u-boot,env.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: U-Boot environment variables + +description: | + U-Boot uses environment variables to store device parameters and + configuration. They may be used for booting process, setup or keeping end user + info. + + Data is stored using U-Boot specific formats (variant specific header and NUL + separated key-value pairs). + + Environment data can be stored on various storage entities, e.g.: + 1. Raw flash partition + 2. UBI volume + + This binding allows marking storage device (as containing env data) and + specifying used format. + + Right now only flash partition case is covered but it may be extended to e.g. + UBI volumes in the future. + +maintainers: + - Rafał Miłecki + +properties: + compatible: + oneOf: + - description: A standalone env data block + const: u-boot,env + - description: Two redundant blocks with active one flagged + const: u-boot,env-redundant-bool + - description: Two redundant blocks with active having higher counter + const: u-boot,env-redundant-count + + reg: + maxItems: 1 + +additionalProperties: false + +examples: + - | + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + reg = <0x0 0x40000>; + label = "u-boot"; + read-only; + }; + + env: partition@40000 { + compatible = "u-boot,env"; + reg = <0x40000 0x10000>; + }; + }; -- cgit From 6b49f3409a090c8e9d1f46ff2705c479b45a54d4 Mon Sep 17 00:00:00 2001 From: Nathan Chancellor Date: Tue, 15 Mar 2022 13:25:43 -0700 Subject: dt-bindings: kbuild: Make DT_SCHEMA_LINT a recursive variable A recent change added a warning when yamllint is not installed, as it is needed for 'make dt_binding_check'. However, it also changed DT_SCHEMA_LINT to be a simple make variable, which is evaluated when a Makefile is evaluated. This causes a warning when running 'make clean', as Documentation/devicetree/bindings/Makefile has a "clean-files" variable: $ make -s clean which: no yamllint in (...) warning: python package 'yamllint' not installed, skipping Make DT_SCHEMA_LINT a recursive variable so it is evaluated only when it is used. The warning still triggers when 'make dt_binding_check' is run. Fixes: b3e664a7f449 ("dt-bindings: kbuild: Print a warning if yamllint is not found") Signed-off-by: Nathan Chancellor Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220315202542.2071351-1-nathan@kernel.org --- Documentation/devicetree/bindings/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index e594e5898be0..c9953f86b19d 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -3,7 +3,7 @@ DT_DOC_CHECKER ?= dt-doc-validate DT_EXTRACT_EX ?= dt-extract-example DT_MK_SCHEMA ?= dt-mk-schema -DT_SCHEMA_LINT := $(shell which yamllint || \ +DT_SCHEMA_LINT = $(shell which yamllint || \ echo "warning: python package 'yamllint' not installed, skipping" >&2) DT_SCHEMA_MIN_VERSION = 2022.3 -- cgit From ada8d8d337ee970860c9844126e634df8076aa11 Mon Sep 17 00:00:00 2001 From: Tom Rix Date: Mon, 21 Mar 2022 15:04:08 -0700 Subject: nvdimm/blk: Fix title level make htmldocs fails with Sphinx parallel build error: docutils.utils.SystemMessage: ...nvdimm.rst:146: (SEVERE/4) Title level inconsistent: PMEM-REGIONs, Atomic Sectors, and DAX ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The PMEM vs BLK section was removed without changing the PMEM-REGIONS... title line. Replace '^' with '_'. Fixes: f8669f1d6a86 ("nvdimm/blk: Delete the block-aperture window driver") Signed-off-by: Tom Rix Link: https://lore.kernel.org/r/20220321220408.2381974-1-trix@redhat.com Signed-off-by: Dan Williams --- Documentation/driver-api/nvdimm/nvdimm.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/nvdimm/nvdimm.rst b/Documentation/driver-api/nvdimm/nvdimm.rst index 7917f6471092..be8587a558e1 100644 --- a/Documentation/driver-api/nvdimm/nvdimm.rst +++ b/Documentation/driver-api/nvdimm/nvdimm.rst @@ -15,7 +15,7 @@ Version 13 Supporting Documents Git Trees LIBNVDIMM PMEM - PMEM-REGIONs, Atomic Sectors, and DAX + PMEM-REGIONs, Atomic Sectors, and DAX Example NVDIMM Platform LIBNVDIMM Kernel Device Model and LIBNDCTL Userspace API LIBNDCTL: Context @@ -144,7 +144,7 @@ can be immediately attached to nd_pmem. This latter mode is called label-less or "legacy". PMEM-REGIONs, Atomic Sectors, and DAX -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +------------------------------------- For the cases where an application or filesystem still needs atomic sector update guarantees it can register a BTT on a PMEM device or partition. See -- cgit From 179fd6ba3bacbf7b19cbdf9b14be109d54318394 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 23 Mar 2022 16:05:32 -0700 Subject: Documentation/sparse: add hints about __CHECKER__ Several attributes depend on __CHECKER__, but previously there was no clue in the tree about when __CHECKER__ might be defined. Add hints at the most common places (__kernel, __user, __iomem, __bitwise) and in the sparse documentation. Link: https://lkml.kernel.org/r/20220310220927.245704-3-helgaas@kernel.org Signed-off-by: Bjorn Helgaas Cc: Jonathan Corbet Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: "Michael S . Tsirkin" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dev-tools/sparse.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/dev-tools/sparse.rst b/Documentation/dev-tools/sparse.rst index 02102be7ff49..dc791c8d84d1 100644 --- a/Documentation/dev-tools/sparse.rst +++ b/Documentation/dev-tools/sparse.rst @@ -100,3 +100,5 @@ have already built it. The optional make variable CF can be used to pass arguments to sparse. The build system passes -Wbitwise to sparse automatically. + +Note that sparse defines the __CHECKER__ preprocessor symbol. -- cgit From b2377d4b94519dd84364a82ba14c79c50ac34fa9 Mon Sep 17 00:00:00 2001 From: Tiezhu Yang Date: Wed, 23 Mar 2022 16:06:45 -0700 Subject: docs: kdump: update description about sysfs file system support Patch series "Update doc and fix some issues about kdump", v2. This patch (of 5): After commit 6a108a14fa35 ("kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT"), "Configure standard kernel features (for small systems)" is not exist, we should use "Configure standard kernel features (expert users)" now. Link: https://lkml.kernel.org/r/1644324666-15947-1-git-send-email-yangtiezhu@loongson.cn Link: https://lkml.kernel.org/r/1644324666-15947-2-git-send-email-yangtiezhu@loongson.cn Signed-off-by: Tiezhu Yang Acked-by: Baoquan He Cc: Baoquan He Cc: Jonathan Corbet Cc: Marco Elver Cc: Andrey Ryabinin Cc: Xuefeng Li Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/kdump/kdump.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst index cb30ca3df27c..d187df2f76ae 100644 --- a/Documentation/admin-guide/kdump/kdump.rst +++ b/Documentation/admin-guide/kdump/kdump.rst @@ -146,9 +146,9 @@ System kernel config options CONFIG_SYSFS=y Note that "sysfs file system support" might not appear in the "Pseudo - filesystems" menu if "Configure standard kernel features (for small - systems)" is not enabled in "General Setup." In this case, check the - .config file itself to ensure that sysfs is turned on, as follows:: + filesystems" menu if "Configure standard kernel features (expert users)" + is not enabled in "General Setup." In this case, check the .config file + itself to ensure that sysfs is turned on, as follows:: grep 'CONFIG_SYSFS' .config -- cgit From ae6694c1aa8f97c20b448622e4d6ba9adeca082d Mon Sep 17 00:00:00 2001 From: Tiezhu Yang Date: Wed, 23 Mar 2022 16:06:48 -0700 Subject: docs: kdump: add scp example to write out the dump file Except cp and makedumpfile, add scp example to write out the dump file. Link: https://lkml.kernel.org/r/1644324666-15947-3-git-send-email-yangtiezhu@loongson.cn Signed-off-by: Tiezhu Yang Acked-by: Baoquan He Cc: Andrey Ryabinin Cc: Jonathan Corbet Cc: Marco Elver Cc: Xuefeng Li Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/kdump/kdump.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst index d187df2f76ae..a748e7eb4429 100644 --- a/Documentation/admin-guide/kdump/kdump.rst +++ b/Documentation/admin-guide/kdump/kdump.rst @@ -533,6 +533,10 @@ the following command:: cp /proc/vmcore +or use scp to write out the dump file between hosts on a network, e.g:: + + scp /proc/vmcore remote_username@remote_ip: + You can also use makedumpfile utility to write out the dump file with specified options to filter out unwanted contents, e.g:: -- cgit From a1ff1de00db21ecb956213f046b79741b64c6b65 Mon Sep 17 00:00:00 2001 From: "Guilherme G. Piccoli" Date: Wed, 23 Mar 2022 16:07:03 -0700 Subject: docs: sysctl/kernel: add missing bit to panic_print Patch series "Some improvements on panic_print". This is a mix of a documentation fix with some additions to the "panic_print" syscall / parameter. The goal here is being able to collect all CPUs backtraces during a panic event and also to enable "panic_print" in a kdump event - details of the reasoning and design choices in the patches. This patch (of 3): Commit de6da1e8bcf0 ("panic: add an option to replay all the printk message in buffer") added a new bit to the sysctl/kernel parameter "panic_print", but the documentation was added only in kernel-parameters.txt, not in the sysctl guide. Fix it here by adding bit 5 to sysctl admin-guide documentation. [rdunlap@infradead.org: fix table format warning] Link: https://lkml.kernel.org/r/20220109055635.6999-1-rdunlap@infradead.org Link: https://lkml.kernel.org/r/20211109202848.610874-1-gpiccoli@igalia.com Link: https://lkml.kernel.org/r/20211109202848.610874-2-gpiccoli@igalia.com Fixes: de6da1e8bcf0 ("panic: add an option to replay all the printk message in buffer") Signed-off-by: Guilherme G. Piccoli Reviewed-by: Feng Tang Cc: Luis Chamberlain Cc: Kees Cook Cc: Iurii Zaikin Cc: Samuel Iglesias Gonsalvez Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/sysctl/kernel.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index d359bcfadd39..0f86e9f93129 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -795,6 +795,7 @@ bit 1 print system memory info bit 2 print timer info bit 3 print locks info if ``CONFIG_LOCKDEP`` is on bit 4 print ftrace buffer +bit 5 print all printk messages in buffer ===== ============================================ So for example to print tasks and memory info on panic, user can:: -- cgit From 8d470a45d1a65e6a308aeee5da7f5b37d3303c04 Mon Sep 17 00:00:00 2001 From: "Guilherme G. Piccoli" Date: Wed, 23 Mar 2022 16:07:06 -0700 Subject: panic: add option to dump all CPUs backtraces in panic_print Currently the "panic_print" parameter/sysctl allows some interesting debug information to be printed during a panic event. This is useful for example in cases the user cannot kdump due to resource limits, or if the user collects panic logs in a serial output (or pstore) and prefers a fast reboot instead of a kdump. Happens that currently there's no way to see all CPUs backtraces in a panic using "panic_print" on architectures that support that. We do have "oops_all_cpu_backtrace" sysctl, but although partially overlapping in the functionality, they are orthogonal in nature: "panic_print" is a panic tuning (and we have panics without oopses, like direct calls to panic() or maybe other paths that don't go through oops_enter() function), and the original purpose of "oops_all_cpu_backtrace" is to provide more information on oopses for cases in which the users desire to continue running the kernel even after an oops, i.e., used in non-panic scenarios. So, we hereby introduce an additional bit for "panic_print" to allow dumping the CPUs backtraces during a panic event. Link: https://lkml.kernel.org/r/20211109202848.610874-3-gpiccoli@igalia.com Signed-off-by: Guilherme G. Piccoli Reviewed-by: Feng Tang Cc: Iurii Zaikin Cc: Kees Cook Cc: Luis Chamberlain Cc: Samuel Iglesias Gonsalvez Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/kernel-parameters.txt | 1 + Documentation/admin-guide/sysctl/kernel.rst | 1 + 2 files changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 7123524a86b8..6287f6be4a98 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3726,6 +3726,7 @@ bit 3: print locks info if CONFIG_LOCKDEP is on bit 4: print ftrace buffer bit 5: print all printk messages in buffer + bit 6: print all CPUs backtrace (if available in the arch) panic_on_taint= Bitmask for conditionally calling panic() in add_taint() Format: [,nousertaint] diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 0f86e9f93129..cfd6c20ce42e 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -796,6 +796,7 @@ bit 2 print timer info bit 3 print locks info if ``CONFIG_LOCKDEP`` is on bit 4 print ftrace buffer bit 5 print all printk messages in buffer +bit 6 print all CPUs backtrace (if available in the arch) ===== ============================================ So for example to print tasks and memory info on panic, user can:: -- cgit From f953f140f318a641c443b0b8c618155ed90a7a10 Mon Sep 17 00:00:00 2001 From: "Guilherme G. Piccoli" Date: Wed, 23 Mar 2022 16:07:09 -0700 Subject: panic: move panic_print before kmsg dumpers The panic_print setting allows users to collect more information in a panic event, like memory stats, tasks, CPUs backtraces, etc. This is an interesting debug mechanism, but currently the print event happens *after* kmsg_dump(), meaning that pstore, for example, cannot collect a dmesg with the panic_print extra information. This patch changes that in 2 steps: (a) The panic_print setting allows to replay the existing kernel log buffer to the console (bit 5), besides the extra information dump. This functionality makes sense only at the end of the panic() function. So, we hereby allow to distinguish the two situations by a new boolean parameter in the function panic_print_sys_info(). (b) With the above change, we can safely call panic_print_sys_info() before kmsg_dump(), allowing to dump the extra information when using pstore or other kmsg dumpers. The additional messages from panic_print could overwrite the oldest messages when the buffer is full. The only reasonable solution is to use a large enough log buffer, hence we added an advice into the kernel parameters documentation about that. Link: https://lkml.kernel.org/r/20220214141308.841525-1-gpiccoli@igalia.com Signed-off-by: Guilherme G. Piccoli Acked-by: Baoquan He Reviewed-by: Petr Mladek Reviewed-by: Sergey Senozhatsky Cc: Feng Tang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/admin-guide/kernel-parameters.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 6287f6be4a98..a18e30a95931 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3727,6 +3727,10 @@ bit 4: print ftrace buffer bit 5: print all printk messages in buffer bit 6: print all CPUs backtrace (if available in the arch) + *Be aware* that this option may print a _lot_ of lines, + so there are risks of losing older messages in the log. + Use this option carefully, maybe worth to setup a + bigger log buffer with "log_buf_len" along with this. panic_on_taint= Bitmask for conditionally calling panic() in add_taint() Format: [,nousertaint] -- cgit From cc2f2df48a17980e815fa09a43b81861f7ebad85 Mon Sep 17 00:00:00 2001 From: Nicolas Belin Date: Wed, 16 Mar 2022 14:57:31 +0100 Subject: dt-bindings: display: bridge: it66121: Add audio support Update the ITE bridge HDMI it66121 bindings in order to support audio. Signed-off-by: Nicolas Belin Acked-by: Rob Herring Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20220316135733.173950-2-nbelin@baylibre.com --- Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml index 6ec1d5fbb8bc..c6e81f532215 100644 --- a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml @@ -38,6 +38,9 @@ properties: interrupts: maxItems: 1 + "#sound-dai-cells": + const: 0 + ports: $ref: /schemas/graph.yaml#/properties/ports -- cgit From 05241de1f69eb7f56b0a5e0bec96a7752fad1b2f Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Thu, 24 Mar 2022 14:55:36 +0300 Subject: dt-bindings: display/msm: another fix for the dpu-qcm2290 example Make dpu-qcm2290 example really follow the defined schema: - Drop qcom,mdss compatible. It's only used for MDP5 devices. - Change display controller name to display-controller as specified in the yaml Reported-by: Rob Herring Cc: Loic Poulain Fixes: 164f69d9d45a ("dt-bindings: msm: disp: add yaml schemas for QCM2290 DPU bindings") Signed-off-by: Dmitry Baryshkov Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220324115536.2090818-1-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark --- Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml index d31483a78eab..6fb7e321f011 100644 --- a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml +++ b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml @@ -160,7 +160,7 @@ examples: mdss: mdss@5e00000 { #address-cells = <1>; #size-cells = <1>; - compatible = "qcom,qcm2290-mdss", "qcom,mdss"; + compatible = "qcom,qcm2290-mdss"; reg = <0x05e00000 0x1000>; reg-names = "mdss"; power-domains = <&dispcc MDSS_GDSC>; @@ -180,7 +180,7 @@ examples: <&apps_smmu 0x421 0x0>; ranges; - mdss_mdp: mdp@5e01000 { + mdss_mdp: display-controller@5e01000 { compatible = "qcom,qcm2290-dpu"; reg = <0x05e01000 0x8f000>, <0x05eb0000 0x2008>; -- cgit From f164935f6f15b2e3496eab7d6aed293a6a98d221 Mon Sep 17 00:00:00 2001 From: Arınç ÜNAL Date: Thu, 10 Mar 2022 17:05:42 +0300 Subject: dt-bindings: pinctrl: rt2880: add missing pin groups and functions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the missing pin groups: jtag, wdt Add the missing functions: i2s, jtag, pcie refclk, pcie rst, pcm, spdif2, spdif3, wdt refclk, wdt rst Sort pin groups and functions in alphabetical order. Fix a typo. Signed-off-by: Arınç ÜNAL Acked-by: Rob Herring Acked-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20220310140542.7483-1-arinc.unal@arinc9.com Signed-off-by: Linus Walleij --- .../devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml index f0c52feb24d7..9de8b0c075e2 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml @@ -10,7 +10,7 @@ maintainers: - Sergio Paracuellos description: - The rt2880 pinmux can only set the muxing of pin groups. muxing indiviual pins + The rt2880 pinmux can only set the muxing of pin groups. Muxing indiviual pins is not supported. There is no pinconf support. properties: @@ -29,12 +29,13 @@ patternProperties: properties: groups: description: Name of the pin group to use for the functions. - enum: [i2c, spi, uart1, uart2, uart3, rgmii1, rgmii2, mdio, - pcie, sdhci] + enum: [i2c, jtag, mdio, pcie, rgmii1, rgmii2, sdhci, spi, + uart1, uart2, uart3, wdt] function: description: The mux function to select - enum: [gpio, i2c, spi, uart1, uart2, uart3, rgmii1, rgmii2, - mdio, nand1, nand2, sdhci] + enum: [gpio, i2c, i2s, jtag, mdio, nand1, nand2, pcie refclk, + pcie rst, pcm, rgmii1, rgmii2, sdhci, spdif2, spdif3, + spi, uart1, uart2, uart3, wdt refclk, wdt rst] required: - groups -- cgit From 6ed23c312ab13486935b4449744ec2721587ed0b Mon Sep 17 00:00:00 2001 From: Joel Stanley Date: Fri, 4 Mar 2022 10:33:10 +1030 Subject: dt-bindings: pinctrl: aspeed: Update gfx node in example The example needs updating to match the to be added yaml bindings for the gfx node. Signed-off-by: Joel Stanley Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20220304000311.970267-2-joel@jms.id.au Signed-off-by: Linus Walleij --- .../bindings/pinctrl/aspeed,ast2500-pinctrl.yaml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml index d316cc082107..9969997c2f1b 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml @@ -73,6 +73,7 @@ additionalProperties: false examples: - | + #include apb { compatible = "simple-bus"; #address-cells = <1>; @@ -82,6 +83,8 @@ examples: syscon: scu@1e6e2000 { compatible = "aspeed,ast2500-scu", "syscon", "simple-mfd"; reg = <0x1e6e2000 0x1a8>; + #clock-cells = <1>; + #reset-cells = <1>; pinctrl: pinctrl { compatible = "aspeed,ast2500-pinctrl"; @@ -102,6 +105,12 @@ examples: gfx: display@1e6e6000 { compatible = "aspeed,ast2500-gfx", "syscon"; reg = <0x1e6e6000 0x1000>; + reg-io-width = <4>; + clocks = <&syscon ASPEED_CLK_GATE_D1CLK>; + resets = <&syscon ASPEED_RESET_CRT1>; + interrupts = <0x19>; + syscon = <&syscon>; + memory-region = <&gfx_memory>; }; }; @@ -128,3 +137,10 @@ examples: }; }; }; + + gfx_memory: framebuffer { + size = <0x01000000>; + alignment = <0x01000000>; + compatible = "shared-dma-pool"; + reusable; + }; -- cgit From 168a0abf05a8da919397552d9cd2a798c4104e8a Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Tue, 15 Mar 2022 12:11:06 +0300 Subject: pinctrl: qcom-pmic-gpio: Add support for pm8450 PM8450 provides 4 GPIOs. Add a compatible entry for this GPIO block. Signed-off-by: Dmitry Baryshkov Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220315091106.613153-1-dmitry.baryshkov@linaro.org Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml index 9400b665a46f..fe2bcf0694d9 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -36,6 +36,7 @@ properties: - qcom,pm8350-gpio - qcom,pm8350b-gpio - qcom,pm8350c-gpio + - qcom,pm8450-gpio - qcom,pm8916-gpio - qcom,pm8917-gpio - qcom,pm8921-gpio -- cgit From adbf85aaf7da509e666dc33eca5b907080d8d9fd Mon Sep 17 00:00:00 2001 From: Ansuel Smith Date: Wed, 23 Mar 2022 20:42:48 +0100 Subject: dt-bindings: clock: fix dt_binding_check error for qcom,gcc-other.yaml qcom,gcc-other Documentation lacks a '|' for the description. This cause dt_binding_check to incorrectly parse "See also:" as a new value. Add the missing '|' to correctly parse the description. Fixes: a03965ed1310 ("dt-bindings: clock: split qcom,gcc.yaml to common and specific schema") Signed-off-by: Ansuel Smith Link: https://lore.kernel.org/r/20220323194248.26970-1-ansuelsmth@gmail.com Reviewed-by: Krzysztof Kozlowski Reported-by: Rob Herring Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml index 4dc0274dbd6b..6c45e0f85494 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml @@ -10,7 +10,7 @@ maintainers: - Stephen Boyd - Taniya Das -description: +description: | Qualcomm global clock control module which supports the clocks, resets and power domains. -- cgit From 57f2b54a937987847e666aaf56d207aa457adee6 Mon Sep 17 00:00:00 2001 From: Shenghong Han Date: Thu, 24 Mar 2022 18:08:56 -0700 Subject: Documentation/vm/page_owner.rst: update the documentation Update the documentation of ``page_owner``. [akpm@linux-foundation.org: small grammatical tweaks] Link: https://lkml.kernel.org/r/20211214134736.2569-1-hanshenghong2019@email.szu.edu.cn Signed-off-by: Shenghong Han Cc: Jonathan Corbet Cc: Vlastimil Babka Cc: Georgi Djakov Cc: Liam Mark Cc: Tang Bin Cc: Zhang Shengju Cc: Zhenliang Wei Cc: Xiaoming Ni Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/page_owner.rst | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index 905555e3e483..6420097a1f7d 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -97,7 +97,7 @@ Usage The ``page_owner_sort`` tool ignores ``PFN`` rows, puts the remaining rows in buf, uses regexp to extract the page order value, counts the times - and pages of buf, and finally sorts them according to the times. + and pages of buf, and finally sorts them according to the parameter(s). See the result about who allocated each page in the ``sorted_page_owner.txt``. General output:: @@ -107,4 +107,23 @@ Usage // Detailed stack By default, ``page_owner_sort`` is sorted according to the times of buf. - If you want to sort by the pages nums of buf, use the ``-m`` parameter. + If you want to sort by the page nums of buf, use the ``-m`` parameter. + The detailed parameters are: + + fundamental function: + + Sort: + -a Sort by memory allocation time. + -m Sort by total memory. + -p Sort by pid. + -r Sort by memory release time. + -s Sort by stack trace. + -t Sort by times (default). + + additional function: + + Cull: + -c Cull by comparing stacktrace instead of total block. + + Filter: + -f Filter out the information of blocks whose memory has not been released. -- cgit From 2e9449856b94bb89bc826695bf8d6d21547e7209 Mon Sep 17 00:00:00 2001 From: Shuah Khan Date: Thu, 24 Mar 2022 18:08:59 -0700 Subject: Documentation/vm/page_owner.rst: fix unexpected indentation warns Fix Unexpected indentation warns in page_owner: Documentation/vm/page_owner.rst:92: WARNING: Unexpected indentation. Documentation/vm/page_owner.rst:96: WARNING: Unexpected indentation. Documentation/vm/page_owner.rst:107: WARNING: Unexpected indentation. Link: https://lkml.kernel.org/r/20211215001929.47866-1-skhan@linuxfoundation.org Signed-off-by: Shuah Khan Cc: Jonathan Corbet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/page_owner.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index 6420097a1f7d..6591e518819f 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -89,11 +89,11 @@ Usage Page allocated via order XXX, ... PFN XXX ... - // Detailed stack + // Detailed stack Page allocated via order XXX, ... PFN XXX ... - // Detailed stack + // Detailed stack The ``page_owner_sort`` tool ignores ``PFN`` rows, puts the remaining rows in buf, uses regexp to extract the page order value, counts the times @@ -104,7 +104,7 @@ Usage XXX times, XXX pages: Page allocated via order XXX, ... - // Detailed stack + // Detailed stack By default, ``page_owner_sort`` is sorted according to the times of buf. If you want to sort by the page nums of buf, use the ``-m`` parameter. -- cgit From 59d7cb27d528eae2f060d548dcd14d292b19fda3 Mon Sep 17 00:00:00 2001 From: Jiajian Ye Date: Thu, 24 Mar 2022 18:09:20 -0700 Subject: tools/vm/page_owner_sort.c: fix comments Two adjustments are made: 1. Correct a grammatical error: replace the "what" in "Do the job what you want to debug" with "that". 2. Replace "has not been" with "has been" in the description of the -f option: According to Commit b1c9ba071e7d ("tools/vm/page_owner_sort.c: fix the instructions for use"), the description of the "-f" option is "Filter out the information of blocks whose memory has been released." Link: https://lkml.kernel.org/r/20220301151438.166118-1-yejiajian2018@email.szu.edu.cn Signed-off-by: Jiajian Ye Cc: Stephen Rothwell Cc: Yinan Zhang Cc: Yixuan Cao Cc: Zhenliang Wei Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/page_owner.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index 6591e518819f..2ddb632d847b 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -78,7 +78,7 @@ Usage 2) Enable page owner: add "page_owner=on" to boot cmdline. -3) Do the job what you want to debug +3) Do the job that you want to debug. 4) Analyze information from page owner:: @@ -126,4 +126,4 @@ Usage -c Cull by comparing stacktrace instead of total block. Filter: - -f Filter out the information of blocks whose memory has not been released. + -f Filter out the information of blocks whose memory has been released. -- cgit From cf3c2c8678a0b21052d00b64d7a5903f3b1d1197 Mon Sep 17 00:00:00 2001 From: Jiajian Ye Date: Thu, 24 Mar 2022 18:09:26 -0700 Subject: tools/vm/page_owner_sort.c: support sorting by tgid and update documentation When the "page owner" information is read, the information sorted by TGID is expected. As a result, the following adjustments have been made: 1. Add a new -P option to sort the information of blocks by TGID in ascending order. 2. Adjust the order of member variables in block_list strust to avoid one 4 byte hole. 3. Add -P option explanation in the document. Link: https://lkml.kernel.org/r/20220301151438.166118-3-yejiajian2018@email.szu.edu.cn Signed-off-by: Jiajian Ye Cc: Stephen Rothwell Cc: Yixuan Cao Cc: Zhenliang Wei Cc: Yinan Zhang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/page_owner.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index 2ddb632d847b..941543a797fe 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -116,6 +116,7 @@ Usage -a Sort by memory allocation time. -m Sort by total memory. -p Sort by pid. + -P Sort by tgid. -r Sort by memory release time. -s Sort by stack trace. -t Sort by times (default). -- cgit From 194d52d771b8f7cf5bcf0f81f87dd76e492c355c Mon Sep 17 00:00:00 2001 From: Jiajian Ye Date: Thu, 24 Mar 2022 18:09:31 -0700 Subject: tools/vm/page_owner_sort: support for sorting by task command name When viewing page owner information, we may also need to the block to be sorted by task command name. Therefore, the following adjustments are made: 1. Add a member variable to record task command name of block. 2. Add a new -n option to sort the information of blocks by task command name. 3. Add -n option explanation in the document. Link: https://lkml.kernel.org/r/20220306030640.43054-2-yejiajian2018@email.szu.edu.cn Signed-off-by: Jiajian Ye Cc: Stephen Rothwell Cc: Sean Anderson Cc: Yixuan Cao Cc: Zhenliang Wei Cc: Cc: Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/page_owner.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index 941543a797fe..d658436a5e09 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -117,6 +117,7 @@ Usage -m Sort by total memory. -p Sort by pid. -P Sort by tgid. + -n Sort by task command name. -r Sort by memory release time. -s Sort by stack trace. -t Sort by times (default). -- cgit From 8ea8613a616aff184df9e3ea2d3ec39d90832867 Mon Sep 17 00:00:00 2001 From: Jiajian Ye Date: Thu, 24 Mar 2022 18:09:34 -0700 Subject: tools/vm/page_owner_sort.c: support for selecting by PID, TGID or task command name When viewing page owner information, we may also need to select the blocks by PID, TGID or task command name, which helps to get more accurate page allocation information as needed. Therefore, following adjustments are made: 1. Add three new options, including --pid, --tgid and --name, to support the selection of information blocks by a specific pid, tgid and task command name. In addtion, multiple options are allowed to be used at the same time. ./page_owner_sort [input] [output] --pid ./page_owner_sort [input] [output] --tgid ./page_owner_sort [input] [output] --name Assuming a scenario when a multi-threaded program, ./demo (PID = 5280), is running, and ./demo creates a child process (PID = 5281). $ps PID TTY TIME CMD 5215 pts/0 00:00:00 bash 5280 pts/0 00:00:00 ./demo 5281 pts/0 00:00:00 ./demo 5282 pts/0 00:00:00 ps It would be better to filter out the records with tgid=5280 and the task name "demo" when debugging the parent process, and the specific usage is ./page_owner_sort [input] [output] --tgid 5280 --name demo 2. Add explanations of three new options, including --pid, --tgid and --name, to the document. This work is coauthored by Shenghong Han , Yixuan Cao , Yinan Zhang , Chongxi Zhao , Yuhong Feng . Link: https://lkml.kernel.org/r/1646835223-7584-1-git-send-email-yejiajian2018@email.szu.edu.cn Signed-off-by: Jiajian Ye Cc: Sean Anderson Cc: Stephen Rothwell Cc: Zhenliang Wei Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/page_owner.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index d658436a5e09..3dd31fe06c05 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -129,3 +129,8 @@ Usage Filter: -f Filter out the information of blocks whose memory has been released. + + Select: + --pid Select by pid. + --tgid Select by tgid. + --name Select by task command name. -- cgit From 9c8a0a8e599f4a949ef18207ba495fb557dd1016 Mon Sep 17 00:00:00 2001 From: Jiajian Ye Date: Thu, 24 Mar 2022 18:09:38 -0700 Subject: tools/vm/page_owner_sort.c: support for user-defined culling rules When viewing page owner information, we may want to cull blocks of information with our own rules. So it is important to enhance culling function to provide the support for customizing culling rules. Therefore, following adjustments are made: 1. Add --cull option to support the culling of blocks of information with user-defined culling rules. ./page_owner_sort --cull= ./page_owner_sort --cull is a single argument in the form of a comma-separated list to specify individual culling rules, by the sequence of keys k1,k2, .... Mixed use of abbreviated and complete-form of keys is allowed. For reference, please see the document(Documentation/vm/page_owner.rst). Now, assuming two blocks in the input file are as follows: Page allocated via order 0, mask xxxx, pid 1, tgid 1 (task_name_demo) PFN xxxx prep_new_page+0xd0/0xf8 get_page_from_freelist+0x4a0/0x1290 __alloc_pages+0x168/0x340 alloc_pages+0xb0/0x158 Page allocated via order 0, mask xxxx, pid 32, tgid 32 (task_name_demo) PFN xxxx prep_new_page+0xd0/0xf8 get_page_from_freelist+0x4a0/0x1290 __alloc_pages+0x168/0x340 alloc_pages+0xb0/0x158 If we want to cull the blocks by stacktrace and task command name, we can use this command: ./page_owner_sort --cull=stacktrace,name The output would be like: 2 times, 2 pages, task_comm_name: task_name_demo prep_new_page+0xd0/0xf8 get_page_from_freelist+0x4a0/0x1290 __alloc_pages+0x168/0x340 alloc_pages+0xb0/0x158 As we can see, these two blocks are culled successfully, for they share the same pid and task command name. However, if we want to cull the blocks by pid, stacktrace and task command name, we can this command: ./page_owner_sort --cull=stacktrace,name,pid The output would be like: 1 times, 1 pages, PID 1, task_comm_name: task_name_demo prep_new_page+0xd0/0xf8 get_page_from_freelist+0x4a0/0x1290 __alloc_pages+0x168/0x340 alloc_pages+0xb0/0x158 1 times, 1 pages, PID 32, task_comm_name: task_name_demo prep_new_page+0xd0/0xf8 get_page_from_freelist+0x4a0/0x1290 __alloc_pages+0x168/0x340 alloc_pages+0xb0/0x158 As we can see, these two blocks are failed to cull, for their PIDs are different. 2. Add explanations of --cull options to the document. This work is coauthored by Yixuan Cao Shenghong Han Yinan Zhang Chongxi Zhao Yuhong Feng Link: https://lkml.kernel.org/r/20220312145834.624-1-yejiajian2018@email.szu.edu.cn Signed-off-by: Jiajian Ye Cc: Yixuan Cao Cc: Shenghong Han Cc: Yinan Zhang Cc: Chongxi Zhao Cc: Yuhong Feng Cc: Stephen Rothwell Cc: Sean Anderson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/page_owner.rst | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index 3dd31fe06c05..c4de6f8dabe9 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -126,11 +126,38 @@ Usage Cull: -c Cull by comparing stacktrace instead of total block. + --cull + Specify culling rules.Culling syntax is key[,key[,...]].Choose a + multi-letter key from the **STANDARD FORMAT SPECIFIERS** section. + + + is a single argument in the form of a comma-separated list, + which offers a way to specify individual culling rules. The recognized + keywords are described in the **STANDARD FORMAT SPECIFIERS** section below. + can be specified by the sequence of keys k1,k2, ..., as described in + the STANDARD SORT KEYS section below. Mixed use of abbreviated and + complete-form of keys is allowed. + + + Examples: + ./page_owner_sort --cull=stacktrace + ./page_owner_sort --cull=st,pid,name + ./page_owner_sort --cull=n,f Filter: -f Filter out the information of blocks whose memory has been released. Select: - --pid Select by pid. + --pid Select by pid. --tgid Select by tgid. --name Select by task command name. + +STANDARD FORMAT SPECIFIERS +========================== + + KEY LONG DESCRIPTION + p pid process ID + tg tgid thread group ID + n name task command name + f free whether the page has been released or not + st stacktrace stace trace of the page allocation -- cgit From 8479d7b5be2fecaed2b78331c3bf443cc19dfcf5 Mon Sep 17 00:00:00 2001 From: Andrey Konovalov Date: Thu, 24 Mar 2022 18:11:56 -0700 Subject: kasan: documentation updates Update KASAN documentation: - Bump Clang version requirement for HW_TAGS as ARM64_MTE depends on AS_HAS_LSE_ATOMICS as of commit 2decad92f4731 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is set atomically"), which requires Clang 12. - Add description of the new kasan.vmalloc command line flag. - Mention that SW_TAGS and HW_TAGS modes now support vmalloc tagging. - Explicitly say that the "Shadow memory" section is only applicable to software KASAN modes. - Mention that shadow-based KASAN_VMALLOC is supported on arm64. Link: https://lkml.kernel.org/r/a61189128fa3f9fbcfd9884ff653d401864b8e74.1643047180.git.andreyknvl@google.com Signed-off-by: Andrey Konovalov Acked-by: Marco Elver Cc: Alexander Potapenko Cc: Andrey Ryabinin Cc: Catalin Marinas Cc: Dmitry Vyukov Cc: Evgenii Stepanov Cc: Mark Rutland Cc: Peter Collingbourne Cc: Vincenzo Frascino Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dev-tools/kasan.rst | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index 8089c559d339..7614a1fc30fa 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -30,7 +30,7 @@ Software tag-based KASAN mode is only supported in Clang. The hardware KASAN mode (#3) relies on hardware to perform the checks but still requires a compiler version that supports memory tagging instructions. -This mode is supported in GCC 10+ and Clang 11+. +This mode is supported in GCC 10+ and Clang 12+. Both software KASAN modes work with SLUB and SLAB memory allocators, while the hardware tag-based KASAN currently only supports SLUB. @@ -206,6 +206,9 @@ additional boot parameters that allow disabling KASAN or controlling features: Asymmetric mode: a bad access is detected synchronously on reads and asynchronously on writes. +- ``kasan.vmalloc=off`` or ``=on`` disables or enables tagging of vmalloc + allocations (default: ``on``). + - ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack traces collection (default: ``on``). @@ -279,8 +282,8 @@ Software tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently reserved to tag freed memory regions. -Software tag-based KASAN currently only supports tagging of slab and page_alloc -memory. +Software tag-based KASAN currently only supports tagging of slab, page_alloc, +and vmalloc memory. Hardware tag-based KASAN ~~~~~~~~~~~~~~~~~~~~~~~~ @@ -303,8 +306,8 @@ Hardware tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently reserved to tag freed memory regions. -Hardware tag-based KASAN currently only supports tagging of slab and page_alloc -memory. +Hardware tag-based KASAN currently only supports tagging of slab, page_alloc, +and VM_ALLOC-based vmalloc memory. If the hardware does not support MTE (pre ARMv8.5), hardware tag-based KASAN will not be enabled. In this case, all KASAN boot parameters are ignored. @@ -319,6 +322,8 @@ checking gets disabled. Shadow memory ------------- +The contents of this section are only applicable to software KASAN modes. + The kernel maps memory in several different parts of the address space. The range of kernel virtual addresses is large: there is not enough real memory to support a real shadow region for every address that could be @@ -349,7 +354,7 @@ CONFIG_KASAN_VMALLOC With ``CONFIG_KASAN_VMALLOC``, KASAN can cover vmalloc space at the cost of greater memory usage. Currently, this is supported on x86, -riscv, s390, and powerpc. +arm64, riscv, s390, and powerpc. This works by hooking into vmalloc and vmap and dynamically allocating real shadow memory to back the mappings. -- cgit From 3b1db05cee0738166cdd0f335ea93e8b0ecf6e08 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 1 Mar 2022 13:03:59 -0600 Subject: dt-bindings: clock: renesas: Make example 'clocks' parsable 'clocks' in the example is not parsable with the 0 phandle value because the number of #clock-cells is unknown in the previous entry. Solve this by adding the clock provider node. Only 'cpg_clocks' is needed as the examples are built with fixups which can be used to identify phandles. This is in preparation to support schema validation on .dtb files. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220301190400.1644150-1-robh@kernel.org Acked-by: Geert Uytterhoeven Reviewed-by: Geert Uytterhoeven Acked-by: Geert Uytterhoeven Signed-off-by: Stephen Boyd --- .../devicetree/bindings/clock/renesas,cpg-div6-clock.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml index c55a7c494e01..2197c952e21d 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml @@ -51,6 +51,18 @@ additionalProperties: false examples: - | #include + + cpg_clocks: cpg_clocks@e6150000 { + compatible = "renesas,r8a73a4-cpg-clocks"; + reg = <0xe6150000 0x10000>; + clocks = <&extal1_clk>, <&extal2_clk>; + #clock-cells = <1>; + clock-output-names = "main", "pll0", "pll1", "pll2", + "pll2s", "pll2h", "z", "z2", + "i", "m3", "b", "m1", "m2", + "zx", "zs", "hp"; + }; + sdhi2_clk: sdhi2_clk@e615007c { compatible = "renesas,r8a73a4-div6-clock", "renesas,cpg-div6-clock"; reg = <0xe615007c 4>; -- cgit From ec8b55780508044b19a6084d2a6a9bd8b96f1b0a Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 16 Mar 2022 14:08:58 +0100 Subject: dt-bindings: clock: drop useless consumer example Consumer examples in the bindings of resource providers are trivial, useless and duplication of code. Remove the example code for consumer Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220316130858.93455-2-krzysztof.kozlowski@canonical.com Acked-by: Rob Herring Signed-off-by: Stephen Boyd --- .../devicetree/bindings/clock/bitmain,bm1880-clk.yaml | 12 ------------ Documentation/devicetree/bindings/clock/idt,versaclock5.yaml | 7 ------- Documentation/devicetree/bindings/clock/imx1-clock.yaml | 9 --------- Documentation/devicetree/bindings/clock/imx21-clock.yaml | 9 --------- Documentation/devicetree/bindings/clock/imx23-clock.yaml | 9 --------- Documentation/devicetree/bindings/clock/imx25-clock.yaml | 8 -------- Documentation/devicetree/bindings/clock/imx27-clock.yaml | 9 --------- Documentation/devicetree/bindings/clock/imx28-clock.yaml | 9 --------- Documentation/devicetree/bindings/clock/imx31-clock.yaml | 8 -------- Documentation/devicetree/bindings/clock/imx35-clock.yaml | 8 -------- .../devicetree/bindings/clock/imx7ulp-pcc-clock.yaml | 11 ----------- .../devicetree/bindings/clock/imx7ulp-scg-clock.yaml | 11 ----------- Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml | 11 ----------- Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml | 8 -------- .../devicetree/bindings/clock/nvidia,tegra124-car.yaml | 7 ------- .../devicetree/bindings/clock/nvidia,tegra20-car.yaml | 7 ------- 16 files changed, 143 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml index 228c9313df53..f0f9392470a6 100644 --- a/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml +++ b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml @@ -61,16 +61,4 @@ examples: #clock-cells = <1>; }; - # Example UART controller node that consumes clock generated by the clock controller: - - | - uart0: serial@58018000 { - compatible = "snps,dw-apb-uart"; - reg = <0x58018000 0x2000>; - clocks = <&clk 45>, <&clk 46>; - clock-names = "baudclk", "apb_pclk"; - interrupts = <0 9 4>; - reg-shift = <2>; - reg-io-width = <4>; - }; - ... diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml index ffd6ae0eed64..be66f1e8b547 100644 --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml @@ -191,11 +191,4 @@ examples: }; }; - /* Consumer referencing the 5P49V5923 pin OUT1 */ - consumer { - /* ... */ - clocks = <&vc5 1>; - /* ... */ - }; - ... diff --git a/Documentation/devicetree/bindings/clock/imx1-clock.yaml b/Documentation/devicetree/bindings/clock/imx1-clock.yaml index f4833a29b79e..56f524780b1a 100644 --- a/Documentation/devicetree/bindings/clock/imx1-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx1-clock.yaml @@ -40,12 +40,3 @@ examples: compatible = "fsl,imx1-ccm"; reg = <0x0021b000 0x1000>; }; - - pwm@208000 { - #pwm-cells = <2>; - compatible = "fsl,imx1-pwm"; - reg = <0x00208000 0x1000>; - interrupts = <34>; - clocks = <&clks IMX1_CLK_DUMMY>, <&clks IMX1_CLK_PER1>; - clock-names = "ipg", "per"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx21-clock.yaml b/Documentation/devicetree/bindings/clock/imx21-clock.yaml index 518ad9a4733c..e2d50544700a 100644 --- a/Documentation/devicetree/bindings/clock/imx21-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx21-clock.yaml @@ -40,12 +40,3 @@ examples: reg = <0x10027000 0x800>; #clock-cells = <1>; }; - - serial@1000a000 { - compatible = "fsl,imx21-uart"; - reg = <0x1000a000 0x1000>; - interrupts = <20>; - clocks = <&clks IMX21_CLK_UART1_IPG_GATE>, - <&clks IMX21_CLK_PER1>; - clock-names = "ipg", "per"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx23-clock.yaml b/Documentation/devicetree/bindings/clock/imx23-clock.yaml index 5e296a00e14f..7e890ab9c77d 100644 --- a/Documentation/devicetree/bindings/clock/imx23-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx23-clock.yaml @@ -83,12 +83,3 @@ examples: reg = <0x80040000 0x2000>; #clock-cells = <1>; }; - - serial@8006c000 { - compatible = "fsl,imx23-auart"; - reg = <0x8006c000 0x2000>; - interrupts = <24>; - clocks = <&clks 32>; - dmas = <&dma_apbx 6>, <&dma_apbx 7>; - dma-names = "rx", "tx"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx25-clock.yaml b/Documentation/devicetree/bindings/clock/imx25-clock.yaml index 2a2b10778e72..1792e138984b 100644 --- a/Documentation/devicetree/bindings/clock/imx25-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx25-clock.yaml @@ -176,11 +176,3 @@ examples: interrupts = <31>; #clock-cells = <1>; }; - - serial@43f90000 { - compatible = "fsl,imx25-uart", "fsl,imx21-uart"; - reg = <0x43f90000 0x4000>; - interrupts = <45>; - clocks = <&clks 79>, <&clks 50>; - clock-names = "ipg", "per"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.yaml b/Documentation/devicetree/bindings/clock/imx27-clock.yaml index 160268f24487..99925aa22a4c 100644 --- a/Documentation/devicetree/bindings/clock/imx27-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx27-clock.yaml @@ -44,12 +44,3 @@ examples: interrupts = <31>; #clock-cells = <1>; }; - - serial@1000a000 { - compatible = "fsl,imx27-uart", "fsl,imx21-uart"; - reg = <0x1000a000 0x1000>; - interrupts = <20>; - clocks = <&clks IMX27_CLK_UART1_IPG_GATE>, - <&clks IMX27_CLK_PER1_GATE>; - clock-names = "ipg", "per"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx28-clock.yaml b/Documentation/devicetree/bindings/clock/imx28-clock.yaml index f831b780f951..a542d680b1ca 100644 --- a/Documentation/devicetree/bindings/clock/imx28-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx28-clock.yaml @@ -106,12 +106,3 @@ examples: reg = <0x80040000 0x2000>; #clock-cells = <1>; }; - - serial@8006a000 { - compatible = "fsl,imx28-auart"; - reg = <0x8006a000 0x2000>; - interrupts = <112>; - dmas = <&dma_apbx 8>, <&dma_apbx 9>; - dma-names = "rx", "tx"; - clocks = <&clks 45>; - }; diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.yaml b/Documentation/devicetree/bindings/clock/imx31-clock.yaml index d2336261c922..168c8ada5e81 100644 --- a/Documentation/devicetree/bindings/clock/imx31-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx31-clock.yaml @@ -110,11 +110,3 @@ examples: interrupts = <31>, <53>; #clock-cells = <1>; }; - - serial@43f90000 { - compatible = "fsl,imx31-uart", "fsl,imx21-uart"; - reg = <0x43f90000 0x4000>; - interrupts = <45>; - clocks = <&clks 10>, <&clks 30>; - clock-names = "ipg", "per"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx35-clock.yaml b/Documentation/devicetree/bindings/clock/imx35-clock.yaml index 3e20ccaf8131..6415bb6a8d04 100644 --- a/Documentation/devicetree/bindings/clock/imx35-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx35-clock.yaml @@ -129,11 +129,3 @@ examples: interrupts = <31>; #clock-cells = <1>; }; - - mmc@53fb4000 { - compatible = "fsl,imx35-esdhc"; - reg = <0x53fb4000 0x4000>; - interrupts = <7>; - clocks = <&clks 9>, <&clks 8>, <&clks 43>; - clock-names = "ipg", "ahb", "per"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml b/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml index 7caf5cee9199..739c3378f8c8 100644 --- a/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml @@ -108,14 +108,3 @@ examples: "upll", "sosc_bus_clk", "firc_bus_clk", "rosc", "spll_bus_clk"; }; - - mmc@40380000 { - compatible = "fsl,imx7ulp-usdhc"; - reg = <0x40380000 0x10000>; - interrupts = ; - clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, - <&scg1 IMX7ULP_CLK_NIC1_DIV>, - <&pcc2 IMX7ULP_CLK_USDHC1>; - clock-names ="ipg", "ahb", "per"; - bus-width = <4>; - }; diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml b/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml index ee8efb4ed599..d06344d7e34f 100644 --- a/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml @@ -86,14 +86,3 @@ examples: "firc", "upll"; #clock-cells = <1>; }; - - mmc@40380000 { - compatible = "fsl,imx7ulp-usdhc"; - reg = <0x40380000 0x10000>; - interrupts = ; - clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, - <&scg1 IMX7ULP_CLK_NIC1_DIV>, - <&pcc2 IMX7ULP_CLK_USDHC1>; - clock-names ="ipg", "ahb", "per"; - bus-width = <4>; - }; diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml index 0f6fe365ebf3..cb80105b3c70 100644 --- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml +++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml @@ -101,14 +101,3 @@ examples: "sdhc0_lpcg_ahb_clk"; power-domains = <&pd IMX_SC_R_SDHC_0>; }; - - mmc@5b010000 { - compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc"; - interrupts = ; - reg = <0x5b010000 0x10000>; - clocks = <&sdhc0_lpcg IMX_LPCG_CLK_4>, - <&sdhc0_lpcg IMX_LPCG_CLK_5>, - <&sdhc0_lpcg IMX_LPCG_CLK_0>; - clock-names = "ipg", "ahb", "per"; - power-domains = <&pd IMX_SC_R_SDHC_0>; - }; diff --git a/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml b/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml index 35fd08c143f4..03fc5c1a2939 100644 --- a/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml @@ -57,11 +57,3 @@ examples: clock-names = "osc"; #clock-cells = <1>; }; - - lpuart1: serial@40184000 { - compatible = "fsl,imxrt1050-lpuart"; - reg = <0x40184000 0x4000>; - interrupts = <20>; - clocks = <&clks IMXRT1050_CLK_LPUART1>; - clock-names = "ipg"; - }; diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml index ec7ab1483652..1b2181f6d440 100644 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml @@ -106,10 +106,3 @@ examples: #clock-cells = <1>; #reset-cells = <1>; }; - - usb-controller@c5004000 { - compatible = "nvidia,tegra20-ehci"; - reg = <0xc5004000 0x4000>; - clocks = <&car TEGRA124_CLK_USB2>; - resets = <&car TEGRA124_CLK_USB2>; - }; diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml index f832abb7f11a..bee2dd4b29bf 100644 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml @@ -97,10 +97,3 @@ examples: power-domains = <&domain>; }; }; - - usb-controller@c5004000 { - compatible = "nvidia,tegra20-ehci"; - reg = <0xc5004000 0x4000>; - clocks = <&car TEGRA20_CLK_USB2>; - resets = <&car TEGRA20_CLK_USB2>; - }; -- cgit From 64a8f92fd783e750cdb81af75942dcd53bbf61bd Mon Sep 17 00:00:00 2001 From: Christian König Date: Fri, 11 Mar 2022 10:27:53 +0100 Subject: dma-buf: add dma_fence_unwrap v2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add a general purpose helper to deep dive into dma_fence_chain/dma_fence_array structures and iterate over all the fences in them. This is useful when we need to flatten out all fences in those structures. v2: some selftests cleanup, improved function naming and documentation Signed-off-by: Christian König Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220311110244.1245-1-christian.koenig@amd.com --- Documentation/driver-api/dma-buf.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 55006678394a..36a76cbe9095 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -185,6 +185,12 @@ DMA Fence Chain .. kernel-doc:: include/linux/dma-fence-chain.h :internal: +DMA Fence unwrap +~~~~~~~~~~~~~~~~ + +.. kernel-doc:: include/linux/dma-fence-unwrap.h + :internal: + DMA Fence uABI/Sync File ~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit From d97c68d178fbf8aaaf21b69b446f2dfb13909316 Mon Sep 17 00:00:00 2001 From: "Jason A. Donenfeld" Date: Tue, 22 Mar 2022 21:43:12 -0600 Subject: random: treat bootloader trust toggle the same way as cpu trust toggle If CONFIG_RANDOM_TRUST_CPU is set, the RNG initializes using RDRAND. But, the user can disable (or enable) this behavior by setting `random.trust_cpu=0/1` on the kernel command line. This allows system builders to do reasonable things while avoiding howls from tinfoil hatters. (Or vice versa.) CONFIG_RANDOM_TRUST_BOOTLOADER is basically the same thing, but regards the seed passed via EFI or device tree, which might come from RDRAND or a TPM or somewhere else. In order to allow distros to more easily enable this while avoiding those same howls (or vice versa), this commit adds the corresponding `random.trust_bootloader=0/1` toggle. Cc: Theodore Ts'o Cc: Graham Christensen Reviewed-by: Ard Biesheuvel Reviewed-by: Dominik Brodowski Link: https://github.com/NixOS/nixpkgs/pull/165355 Signed-off-by: Jason A. Donenfeld --- Documentation/admin-guide/kernel-parameters.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index b7ccaa2ea867..3f1cc5e317ed 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4427,6 +4427,12 @@ fully seed the kernel's CRNG. Default is controlled by CONFIG_RANDOM_TRUST_CPU. + random.trust_bootloader={on,off} + [KNL] Enable or disable trusting the use of a + seed passed by the bootloader (if available) to + fully seed the kernel's CRNG. Default is controlled + by CONFIG_RANDOM_TRUST_BOOTLOADER. + randomize_kstack_offset= [KNL] Enable or disable kernel stack offset randomization, which provides roughly 5 bits of -- cgit From 7000ef38052b219583f17a10ef2e7ca99b5e585e Mon Sep 17 00:00:00 2001 From: Jan Engelhardt Date: Wed, 23 Mar 2022 11:26:02 +0100 Subject: Documentation: amd-pstate: grammar and sentence structure updates Signed-off-by: Jan Engelhardt Reviewed-by: Randy Dunlap Signed-off-by: Rafael J. Wysocki --- Documentation/admin-guide/pm/amd-pstate.rst | 135 ++++++++++++++-------------- 1 file changed, 67 insertions(+), 68 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst index 2f066df4ee9c..c83db37695da 100644 --- a/Documentation/admin-guide/pm/amd-pstate.rst +++ b/Documentation/admin-guide/pm/amd-pstate.rst @@ -19,7 +19,7 @@ Linux kernel. The new mechanism is based on Collaborative Processor Performance Control (CPPC) which provides finer grain frequency management than legacy ACPI hardware P-States. Current AMD CPU/APU platforms are using the ACPI P-states driver to manage CPU frequency and clocks with switching -only in 3 P-states. CPPC replaces the ACPI P-states controls, allows a +only in 3 P-states. CPPC replaces the ACPI P-states controls and allows a flexible, low-latency interface for the Linux kernel to directly communicate the performance hints to hardware. @@ -27,7 +27,7 @@ communicate the performance hints to hardware. ``ondemand``, etc. to manage the performance hints which are provided by CPPC hardware functionality that internally follows the hardware specification (for details refer to AMD64 Architecture Programmer's Manual -Volume 2: System Programming [1]_). Currently ``amd-pstate`` supports basic +Volume 2: System Programming [1]_). Currently, ``amd-pstate`` supports basic frequency control function according to kernel governors on some of the Zen2 and Zen3 processors, and we will implement more AMD specific functions in future after we verify them on the hardware and SBIOS. @@ -41,9 +41,9 @@ continuous, abstract, and unit-less performance value in a scale that is not tied to a specific performance state / frequency. This is an ACPI standard [2]_ which software can specify application performance goals and hints as a relative target to the infrastructure limits. AMD processors -provides the low latency register model (MSR) instead of AML code +provide the low latency register model (MSR) instead of an AML code interpreter for performance adjustments. ``amd-pstate`` will initialize a -``struct cpufreq_driver`` instance ``amd_pstate_driver`` with the callbacks +``struct cpufreq_driver`` instance, ``amd_pstate_driver``, with the callbacks to manage each performance update behavior. :: Highest Perf ------>+-----------------------+ +-----------------------+ @@ -91,26 +91,26 @@ AMD CPPC Performance Capability Highest Performance (RO) ......................... -It is the absolute maximum performance an individual processor may reach, +This is the absolute maximum performance an individual processor may reach, assuming ideal conditions. This performance level may not be sustainable for long durations and may only be achievable if other platform components -are in a specific state; for example, it may require other processors be in +are in a specific state; for example, it may require other processors to be in an idle state. This would be equivalent to the highest frequencies supported by the processor. Nominal (Guaranteed) Performance (RO) ...................................... -It is the maximum sustained performance level of the processor, assuming -ideal operating conditions. In absence of an external constraint (power, -thermal, etc.) this is the performance level the processor is expected to +This is the maximum sustained performance level of the processor, assuming +ideal operating conditions. In the absence of an external constraint (power, +thermal, etc.), this is the performance level the processor is expected to be able to maintain continuously. All cores/processors are expected to be able to sustain their nominal performance state simultaneously. Lowest non-linear Performance (RO) ................................... -It is the lowest performance level at which nonlinear power savings are +This is the lowest performance level at which nonlinear power savings are achieved, for example, due to the combined effects of voltage and frequency scaling. Above this threshold, lower performance levels should be generally more energy efficient than higher performance levels. This register @@ -119,7 +119,7 @@ effectively conveys the most efficient performance level to ``amd-pstate``. Lowest Performance (RO) ........................ -It is the absolute lowest performance level of the processor. Selecting a +This is the absolute lowest performance level of the processor. Selecting a performance level lower than the lowest nonlinear performance level may cause an efficiency penalty but should reduce the instantaneous power consumption of the processor. @@ -149,14 +149,14 @@ a relative number. This can be expressed as percentage of nominal performance (infrastructure max). Below the nominal sustained performance level, desired performance expresses the average performance level of the processor subject to hardware. Above the nominal performance level, -processor must provide at least nominal performance requested and go higher +the processor must provide at least nominal performance requested and go higher if current operating conditions allow. Energy Performance Preference (EPP) (RW) ......................................... -Provides a hint to the hardware if software wants to bias toward performance -(0x0) or energy efficiency (0xff). +This attribute provides a hint to the hardware if software wants to bias +toward performance (0x0) or energy efficiency (0xff). Key Governors Support @@ -173,35 +173,34 @@ operating frequencies supported by the hardware. Users can check the ``amd-pstate`` mainly supports ``schedutil`` and ``ondemand`` for dynamic frequency control. It is to fine tune the processor configuration on ``amd-pstate`` to the ``schedutil`` with CPU CFS scheduler. ``amd-pstate`` -registers adjust_perf callback to implement the CPPC similar performance -update behavior. It is initialized by ``sugov_start`` and then populate the -CPU's update_util_data pointer to assign ``sugov_update_single_perf`` as -the utilization update callback function in CPU scheduler. CPU scheduler -will call ``cpufreq_update_util`` and assign the target performance -according to the ``struct sugov_cpu`` that utilization update belongs to. -Then ``amd-pstate`` updates the desired performance according to the CPU +registers the adjust_perf callback to implement performance update behavior +similar to CPPC. It is initialized by ``sugov_start`` and then populates the +CPU's update_util_data pointer to assign ``sugov_update_single_perf`` as the +utilization update callback function in the CPU scheduler. The CPU scheduler +will call ``cpufreq_update_util`` and assigns the target performance according +to the ``struct sugov_cpu`` that the utilization update belongs to. +Then, ``amd-pstate`` updates the desired performance according to the CPU scheduler assigned. Processor Support ======================= -The ``amd-pstate`` initialization will fail if the _CPC in ACPI SBIOS is -not existed at the detected processor, and it uses ``acpi_cpc_valid`` to -check the _CPC existence. All Zen based processors support legacy ACPI -hardware P-States function, so while the ``amd-pstate`` fails to be -initialized, the kernel will fall back to initialize ``acpi-cpufreq`` -driver. +The ``amd-pstate`` initialization will fail if the ``_CPC`` entry in the ACPI +SBIOS does not exist in the detected processor. It uses ``acpi_cpc_valid`` +to check the existence of ``_CPC``. All Zen based processors support the legacy +ACPI hardware P-States function, so when ``amd-pstate`` fails initialization, +the kernel will fall back to initialize the ``acpi-cpufreq`` driver. There are two types of hardware implementations for ``amd-pstate``: one is `Full MSR Support `_ and another is `Shared Memory Support -`_. It can use :c:macro:`X86_FEATURE_CPPC` feature flag (for -details refer to Processor Programming Reference (PPR) for AMD Family -19h Model 51h, Revision A1 Processors [3]_) to indicate the different -types. ``amd-pstate`` is to register different ``static_call`` instances -for different hardware implementations. +`_. It can use the :c:macro:`X86_FEATURE_CPPC` feature flag to +indicate the different types. (For details, refer to the Processor Programming +Reference (PPR) for AMD Family 19h Model 51h, Revision A1 Processors [3]_.) +``amd-pstate`` is to register different ``static_call`` instances for different +hardware implementations. -Currently, some of Zen2 and Zen3 processors support ``amd-pstate``. In the +Currently, some of the Zen2 and Zen3 processors support ``amd-pstate``. In the future, it will be supported on more and more AMD processors. Full MSR Support @@ -210,18 +209,18 @@ Full MSR Support Some new Zen3 processors such as Cezanne provide the MSR registers directly while the :c:macro:`X86_FEATURE_CPPC` CPU feature flag is set. ``amd-pstate`` can handle the MSR register to implement the fast switch -function in ``CPUFreq`` that can shrink latency of frequency control on the -interrupt context. The functions with ``pstate_xxx`` prefix represent the -operations of MSR registers. +function in ``CPUFreq`` that can reduce the latency of frequency control in +interrupt context. The functions with a ``pstate_xxx`` prefix represent the +operations on MSR registers. Shared Memory Support ---------------------- -If :c:macro:`X86_FEATURE_CPPC` CPU feature flag is not set, that means the -processor supports shared memory solution. In this case, ``amd-pstate`` +If the :c:macro:`X86_FEATURE_CPPC` CPU feature flag is not set, the +processor supports the shared memory solution. In this case, ``amd-pstate`` uses the ``cppc_acpi`` helper methods to implement the callback functions -that defined on ``static_call``. The functions with ``cppc_xxx`` prefix -represent the operations of acpi cppc helpers for shared memory solution. +that are defined on ``static_call``. The functions with the ``cppc_xxx`` prefix +represent the operations of ACPI CPPC helpers for the shared memory solution. AMD P-States and ACPI hardware P-States always can be supported in one @@ -234,7 +233,7 @@ User Space Interface in ``sysfs`` ================================== ``amd-pstate`` exposes several global attributes (files) in ``sysfs`` to -control its functionality at the system level. They located in the +control its functionality at the system level. They are located in the ``/sys/devices/system/cpu/cpufreq/policyX/`` directory and affect all CPUs. :: root@hr-test1:/home/ray# ls /sys/devices/system/cpu/cpufreq/policy0/*amd* @@ -246,38 +245,38 @@ control its functionality at the system level. They located in the ``amd_pstate_highest_perf / amd_pstate_max_freq`` Maximum CPPC performance and CPU frequency that the driver is allowed to -set in percent of the maximum supported CPPC performance level (the highest +set, in percent of the maximum supported CPPC performance level (the highest performance supported in `AMD CPPC Performance Capability `_). -In some of ASICs, the highest CPPC performance is not the one in the _CPC -table, so we need to expose it to sysfs. If boost is not active but -supported, this maximum frequency will be larger than the one in +In some ASICs, the highest CPPC performance is not the one in the ``_CPC`` +table, so we need to expose it to sysfs. If boost is not active, but +still supported, this maximum frequency will be larger than the one in ``cpuinfo``. This attribute is read-only. ``amd_pstate_lowest_nonlinear_freq`` -The lowest non-linear CPPC CPU frequency that the driver is allowed to set -in percent of the maximum supported CPPC performance level (Please see the +The lowest non-linear CPPC CPU frequency that the driver is allowed to set, +in percent of the maximum supported CPPC performance level. (Please see the lowest non-linear performance in `AMD CPPC Performance Capability -`_). +`_.) This attribute is read-only. -For other performance and frequency values, we can read them back from +Other performance and frequency values can be read back from ``/sys/devices/system/cpu/cpuX/acpi_cppc/``, see :ref:`cppc_sysfs`. ``amd-pstate`` vs ``acpi-cpufreq`` ====================================== -On majority of AMD platforms supported by ``acpi-cpufreq``, the ACPI tables -provided by the platform firmware used for CPU performance scaling, but -only provides 3 P-states on AMD processors. -However, on modern AMD APU and CPU series, it provides the collaborative -processor performance control according to ACPI protocol and customize this -for AMD platforms. That is fine-grain and continuous frequency range +On the majority of AMD platforms supported by ``acpi-cpufreq``, the ACPI tables +provided by the platform firmware are used for CPU performance scaling, but +only provide 3 P-states on AMD processors. +However, on modern AMD APU and CPU series, hardware provides the Collaborative +Processor Performance Control according to the ACPI protocol and customizes this +for AMD platforms. That is, fine-grained and continuous frequency ranges instead of the legacy hardware P-states. ``amd-pstate`` is the kernel -module which supports the new AMD P-States mechanism on most of future AMD -platforms. The AMD P-States mechanism will be the more performance and energy +module which supports the new AMD P-States mechanism on most of the future AMD +platforms. The AMD P-States mechanism is the more performance and energy efficiency frequency management method on AMD processors. Kernel Module Options for ``amd-pstate`` @@ -287,25 +286,25 @@ Kernel Module Options for ``amd-pstate`` Use a module param (shared_mem) to enable related processors manually with **amd_pstate.shared_mem=1**. Due to the performance issue on the processors with `Shared Memory Support -`_, so we disable it for the moment and will enable this by default -once we address performance issue on this solution. +`_, we disable it presently and will re-enable this by default +once we address performance issue with this solution. -The way to check whether current processor is `Full MSR Support `_ +To check whether the current processor is using `Full MSR Support `_ or `Shared Memory Support `_ : :: ray@hr-test1:~$ lscpu | grep cppc Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm -If CPU Flags have cppc, then this processor supports `Full MSR Support -`_. Otherwise it supports `Shared Memory Support `_. +If the CPU flags have ``cppc``, then this processor supports `Full MSR Support +`_. Otherwise, it supports `Shared Memory Support `_. ``cpupower`` tool support for ``amd-pstate`` =============================================== -``amd-pstate`` is supported on ``cpupower`` tool that can be used to dump the frequency -information. And it is in progress to support more and more operations for new -``amd-pstate`` module with this tool. :: +``amd-pstate`` is supported by the ``cpupower`` tool, which can be used to dump +frequency information. Development is in progress to support more and more +operations for the new ``amd-pstate`` module with this tool. :: root@hr-test1:/home/ray# cpupower frequency-info analyzing CPU 0: @@ -336,10 +335,10 @@ Trace Events -------------- There are two static trace events that can be used for ``amd-pstate`` -diagnostics. One of them is the cpu_frequency trace event generally used +diagnostics. One of them is the ``cpu_frequency`` trace event generally used by ``CPUFreq``, and the other one is the ``amd_pstate_perf`` trace event specific to ``amd-pstate``. The following sequence of shell commands can -be used to enable them and see their output (if the kernel is generally +be used to enable them and see their output (if the kernel is configured to support event tracing). :: root@hr-test1:/home/ray# cd /sys/kernel/tracing/ @@ -364,7 +363,7 @@ configured to support event tracing). :: -0 [003] d.s.. 4995.980971: amd_pstate_perf: amd_min_perf=85 amd_des_perf=85 amd_max_perf=166 cpu_id=3 changed=false fast_switch=true -0 [011] d.s.. 4995.980996: amd_pstate_perf: amd_min_perf=85 amd_des_perf=85 amd_max_perf=166 cpu_id=11 changed=false fast_switch=true -The cpu_frequency trace event will be triggered either by the ``schedutil`` scaling +The ``cpu_frequency`` trace event will be triggered either by the ``schedutil`` scaling governor (for the policies it is attached to), or by the ``CPUFreq`` core (for the policies with other scaling governors). -- cgit From 8d6451b9a51b555be2c9a6c326a980b2de00741a Mon Sep 17 00:00:00 2001 From: "Guilherme G. Piccoli" Date: Mon, 21 Mar 2022 11:41:33 -0300 Subject: Documentation: Fix duplicate statement about raw_spinlock_t type Unless it was duplicate on purpose, to emphasize that a raw_spinlock_t is always a spinning lock regardless of PREEMPT_RT or kernel config, it's a bit odd that this text is duplicate. So, this patch just clean it up, keeping the consistency with the other sections of the text. Cc: Thomas Gleixner Fixes: 919e9e6395cf ("Documentation: Add lock ordering and nesting documentation") Signed-off-by: Guilherme G. Piccoli Link: https://lore.kernel.org/r/20220321144133.49804-1-gpiccoli@igalia.com Signed-off-by: Jonathan Corbet --- Documentation/locking/locktypes.rst | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/locking/locktypes.rst b/Documentation/locking/locktypes.rst index bfa75ea1b66a..9933faad4771 100644 --- a/Documentation/locking/locktypes.rst +++ b/Documentation/locking/locktypes.rst @@ -211,9 +211,6 @@ raw_spinlock_t and spinlock_t raw_spinlock_t -------------- -raw_spinlock_t is a strict spinning lock implementation regardless of the -kernel configuration including PREEMPT_RT enabled kernels. - raw_spinlock_t is a strict spinning lock implementation in all kernels, including PREEMPT_RT kernels. Use raw_spinlock_t only in real critical core code, low-level interrupt handling and places where disabling -- cgit From bddac7c1e02ba47f0570e494c9289acea3062cc1 Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Sat, 26 Mar 2022 10:42:04 -0700 Subject: Revert "swiotlb: rework "fix info leak with DMA_FROM_DEVICE"" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This reverts commit aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13. It turns out this breaks at least the ath9k wireless driver, and possibly others. What the ath9k driver does on packet receive is to set up the DMA transfer with: int ath_rx_init(..) .. bf->bf_buf_addr = dma_map_single(sc->dev, skb->data, common->rx_bufsize, DMA_FROM_DEVICE); and then the receive logic (through ath_rx_tasklet()) will fetch incoming packets static bool ath_edma_get_buffers(..) .. dma_sync_single_for_cpu(sc->dev, bf->bf_buf_addr, common->rx_bufsize, DMA_FROM_DEVICE); ret = ath9k_hw_process_rxdesc_edma(ah, rs, skb->data); if (ret == -EINPROGRESS) { /*let device gain the buffer again*/ dma_sync_single_for_device(sc->dev, bf->bf_buf_addr, common->rx_bufsize, DMA_FROM_DEVICE); return false; } and it's worth noting how that first DMA sync: dma_sync_single_for_cpu(..DMA_FROM_DEVICE); is there to make sure the CPU can read the DMA buffer (possibly by copying it from the bounce buffer area, or by doing some cache flush). The iommu correctly turns that into a "copy from bounce bufer" so that the driver can look at the state of the packets. In the meantime, the device may continue to write to the DMA buffer, but we at least have a snapshot of the state due to that first DMA sync. But that _second_ DMA sync: dma_sync_single_for_device(..DMA_FROM_DEVICE); is telling the DMA mapping that the CPU wasn't interested in the area because the packet wasn't there. In the case of a DMA bounce buffer, that is a no-op. Note how it's not a sync for the CPU (the "for_device()" part), and it's not a sync for data written by the CPU (the "DMA_FROM_DEVICE" part). Or rather, it _should_ be a no-op. That's what commit aa6f8dcbab47 broke: it made the code bounce the buffer unconditionally, and changed the DMA_FROM_DEVICE to just unconditionally and illogically be DMA_TO_DEVICE. [ Side note: purely within the confines of the swiotlb driver it wasn't entirely illogical: The reason it did that odd DMA_FROM_DEVICE -> DMA_TO_DEVICE conversion thing is because inside the swiotlb driver, it uses just a swiotlb_bounce() helper that doesn't care about the whole distinction of who the sync is for - only which direction to bounce. So it took the "sync for device" to mean that the CPU must have been the one writing, and thought it meant DMA_TO_DEVICE. ] Also note how the commentary in that commit was wrong, probably due to that whole confusion, claiming that the commit makes the swiotlb code "bounce unconditionally (that is, also when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale data from the swiotlb buffer" which is nonsensical for two reasons: - that "also when dir == DMA_TO_DEVICE" is nonsensical, as that was exactly when it always did - and should do - the bounce. - since this is a sync for the device (not for the CPU), we're clearly fundamentally not coping back stale data from the bounce buffers at all, because we'd be copying *to* the bounce buffers. So that commit was just very confused. It confused the direction of the synchronization (to the device, not the cpu) with the direction of the DMA (from the device). Reported-and-bisected-by: Oleksandr Natalenko Reported-by: Olha Cherevyk Cc: Halil Pasic Cc: Christoph Hellwig Cc: Kalle Valo Cc: Robin Murphy Cc: Toke Høiland-Jørgensen Cc: Maxime Bizon Cc: Johannes Berg Signed-off-by: Linus Torvalds --- Documentation/core-api/dma-attributes.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/core-api/dma-attributes.rst b/Documentation/core-api/dma-attributes.rst index 1887d92e8e92..17706dc91ec9 100644 --- a/Documentation/core-api/dma-attributes.rst +++ b/Documentation/core-api/dma-attributes.rst @@ -130,3 +130,11 @@ accesses to DMA buffers in both privileged "supervisor" and unprivileged subsystem that the buffer is fully accessible at the elevated privilege level (and ideally inaccessible or at least read-only at the lesser-privileged levels). + +DMA_ATTR_OVERWRITE +------------------ + +This is a hint to the DMA-mapping subsystem that the device is expected to +overwrite the entire mapped size, thus the caller does not require any of the +previous buffer contents to be preserved. This allows bounce-buffering +implementations to optimise DMA_FROM_DEVICE transfers. -- cgit From 7198d62c6687df98d8709503ec4107656dd2cd4d Mon Sep 17 00:00:00 2001 From: Thanh Quan Date: Tue, 18 Jan 2022 18:09:02 +0100 Subject: dt-bindings: watchdog: renesas-wdt: Document r8a779f0 support Document support for the Watchdog Timer (WDT) Controller in the Renesas R-Car S4-8 (R8A779F0) SoC. Signed-off-by: Thanh Quan Signed-off-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Acked-by: Rob Herring Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/cca61a83ae82ecf5c23eb28e30c39f2f661f0e02.1642525158.git.geert+renesas@glider.be Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck --- Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml index 91a98ccd4226..d060438e1402 100644 --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml @@ -55,6 +55,11 @@ properties: - renesas,r8a779a0-wdt # R-Car V3U - const: renesas,rcar-gen3-wdt # R-Car Gen3 and RZ/G2 + - items: + - enum: + - renesas,r8a779f0-wdt # R-Car S4-8 + - const: renesas,rcar-gen4-wdt # R-Car Gen4 + reg: maxItems: 1 -- cgit From 901c7280ca0d5e2b4a8929fbe0bfb007ac2a6544 Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Mon, 28 Mar 2022 11:37:05 -0700 Subject: Reinstate some of "swiotlb: rework "fix info leak with DMA_FROM_DEVICE"" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Halil Pasic points out [1] that the full revert of that commit (revert in bddac7c1e02b), and that a partial revert that only reverts the problematic case, but still keeps some of the cleanups is probably better.  And that partial revert [2] had already been verified by Oleksandr Natalenko to also fix the issue, I had just missed that in the long discussion. So let's reinstate the cleanups from commit aa6f8dcbab47 ("swiotlb: rework "fix info leak with DMA_FROM_DEVICE""), and effectively only revert the part that caused problems. Link: https://lore.kernel.org/all/20220328013731.017ae3e3.pasic@linux.ibm.com/ [1] Link: https://lore.kernel.org/all/20220324055732.GB12078@lst.de/ [2] Link: https://lore.kernel.org/all/4386660.LvFx2qVVIh@natalenko.name/ [3] Suggested-by: Halil Pasic Tested-by: Oleksandr Natalenko Cc: Christoph Hellwig" Signed-off-by: Linus Torvalds --- Documentation/core-api/dma-attributes.rst | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/core-api/dma-attributes.rst b/Documentation/core-api/dma-attributes.rst index 17706dc91ec9..1887d92e8e92 100644 --- a/Documentation/core-api/dma-attributes.rst +++ b/Documentation/core-api/dma-attributes.rst @@ -130,11 +130,3 @@ accesses to DMA buffers in both privileged "supervisor" and unprivileged subsystem that the buffer is fully accessible at the elevated privilege level (and ideally inaccessible or at least read-only at the lesser-privileged levels). - -DMA_ATTR_OVERWRITE ------------------- - -This is a hint to the DMA-mapping subsystem that the device is expected to -overwrite the entire mapped size, thus the caller does not require any of the -previous buffer contents to be preserved. This allows bounce-buffering -implementations to optimise DMA_FROM_DEVICE transfers. -- cgit From d987d5ae51ecfa75e61f4de56c7e2bb77be57fea Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Sat, 26 Mar 2022 16:48:39 +0900 Subject: docs: kfigure.py: Don't warn of missing PDF converter in 'make htmldocs' SVG -> PDF conversion is not required in "make htmldocs". It is pointless to always warn of a missing converter. Demote the log message in setupTools() to verbose. For "make pdfdocs" (or "make latexdocs"), promote the dynamic message of "include SVG raw" to a warn. Expand the message and recommend installing Inkscape or ImageMagick. Fixes: 8ccd05697a9d ("docs: sphinx/kfigure.py: Use inkscape(1) for SVG -> PDF conversion") Signed-off-by: Akira Yokosawa Cc: Jonathan Corbet Cc: Mauro Carvalho Chehab Cc: linux-doc@vger.kernel.org Acked-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/c80e1481-10d4-7151-fe59-e846259eb0d4@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/sphinx/kfigure.py | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sphinx/kfigure.py b/Documentation/sphinx/kfigure.py index 24d2b2addcce..cefdbb7e7523 100644 --- a/Documentation/sphinx/kfigure.py +++ b/Documentation/sphinx/kfigure.py @@ -212,7 +212,7 @@ def setupTools(app): if convert_cmd: kernellog.verbose(app, "use convert(1) from: " + convert_cmd) else: - kernellog.warn(app, + kernellog.verbose(app, "Neither inkscape(1) nor convert(1) found.\n" "For SVG to PDF conversion, " "install either Inkscape (https://inkscape.org/) (preferred) or\n" @@ -296,8 +296,10 @@ def convert_image(img_node, translator, src_fname=None): if translator.builder.format == 'latex': if not inkscape_cmd and convert_cmd is None: - kernellog.verbose(app, - "no SVG to PDF conversion available / include SVG raw.") + kernellog.warn(app, + "no SVG to PDF conversion available / include SVG raw." + "\nIncluding large raw SVGs can cause xelatex error." + "\nInstall Inkscape (preferred) or ImageMagick.") img_node.replace_self(file2literal(src_fname)) else: dst_fname = path.join(translator.builder.outdir, fname + '.pdf') -- cgit From 85999f03147e73fc5c0a0a3c0db1fad368ca75e4 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 26 Mar 2022 11:27:20 +0100 Subject: docs: kernel_feat.py: add build dependencies Ensure that the feature files will be regenerated if any changes happen at the Documentation/features files that were processed by gen_feat.pl. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/5cdf7a8300019129dcc09d4c2557f75908754445.1648290305.git.mchehab@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/sphinx/kernel_feat.py | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sphinx/kernel_feat.py b/Documentation/sphinx/kernel_feat.py index 8138d69a6987..27b701ed3681 100644 --- a/Documentation/sphinx/kernel_feat.py +++ b/Documentation/sphinx/kernel_feat.py @@ -33,6 +33,7 @@ u""" import codecs import os +import re import subprocess import sys @@ -82,7 +83,7 @@ class KernelFeat(Directive): env = doc.settings.env cwd = path.dirname(doc.current_source) - cmd = "get_feat.pl rest --dir " + cmd = "get_feat.pl rest --enable-fname --dir " cmd += self.arguments[0] if len(self.arguments) > 1: @@ -102,7 +103,22 @@ class KernelFeat(Directive): shell_env["srctree"] = srctree lines = self.runCmd(cmd, shell=True, cwd=cwd, env=shell_env) - nodeList = self.nestedParse(lines, fname) + + line_regex = re.compile("^\.\. FILE (\S+)$") + + out_lines = "" + + for line in lines.split("\n"): + match = line_regex.search(line) + if match: + fname = match.group(1) + + # Add the file to Sphinx build dependencies + env.note_dependency(os.path.abspath(fname)) + else: + out_lines += line + "\n" + + nodeList = self.nestedParse(out_lines, fname) return nodeList def runCmd(self, cmd, **kwargs): -- cgit From b4541803d858dc058e6ba5f1817ab89af95c9c21 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 26 Mar 2022 11:27:21 +0100 Subject: docs: kernel_abi.py: add sphinx build dependencies Ensure that Sphinx-build will handle the files parsed by get_abi.pl as dependencies. This way, if they are touched, the ABI output will be regenerated. Reported-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/10bc3d3bc74f514a539cd3b48b9d287d2b6f99e2.1648290305.git.mchehab@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/sphinx/kernel_abi.py | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sphinx/kernel_abi.py b/Documentation/sphinx/kernel_abi.py index 4392b3cb4020..efab9b14a9f5 100644 --- a/Documentation/sphinx/kernel_abi.py +++ b/Documentation/sphinx/kernel_abi.py @@ -128,6 +128,7 @@ class KernelCmd(Directive): return out def nestedParse(self, lines, fname): + env = self.state.document.settings.env content = ViewList() node = nodes.section() @@ -154,6 +155,9 @@ class KernelCmd(Directive): self.do_parse(content, node) content = ViewList() + # Add the file to Sphinx build dependencies + env.note_dependency(os.path.abspath(f)) + f = new_f # sphinx counts lines from 0 -- cgit From bcf0a536bff913f3c77c4c469bff13fd9ebeb1e9 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 26 Mar 2022 11:27:22 +0100 Subject: docs: kernel_include.py: add sphinx build dependencies The files included by kernel-include should be added as build dependencies, in order for sphinx-build to rebuild the corresponding docs if any changes at the included file happens. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/d30fc4fa422a13b7e1623d690945c46b58a55e79.1648290305.git.mchehab@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/sphinx/kernel_include.py | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sphinx/kernel_include.py b/Documentation/sphinx/kernel_include.py index f523aa68a36b..abe768088377 100755 --- a/Documentation/sphinx/kernel_include.py +++ b/Documentation/sphinx/kernel_include.py @@ -59,6 +59,7 @@ class KernelInclude(Include): u"""KernelInclude (``kernel-include``) directive""" def run(self): + env = self.state.document.settings.env path = os.path.realpath( os.path.expandvars(self.arguments[0])) @@ -70,6 +71,8 @@ class KernelInclude(Include): self.arguments[0] = path + env.note_dependency(os.path.abspath(path)) + #return super(KernelInclude, self).run() # won't work, see HINTs in _run() return self._run() -- cgit From 92b6de17b21cf74448d2397ef92d5ca856c6419f Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 26 Mar 2022 11:27:23 +0100 Subject: scripts/get_abi: change the file/line number meta info In order to make it more standard and ReST compatible, change the meta-tag used with --enable-lineno from: #define LINENO to .. LINENO In practice, no functional changes. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/125ffd31fbc77ad9eee4d6906e1830b8162fa6ca.1648290305.git.mchehab@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/sphinx/kernel_abi.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sphinx/kernel_abi.py b/Documentation/sphinx/kernel_abi.py index efab9b14a9f5..b5feb5b1d905 100644 --- a/Documentation/sphinx/kernel_abi.py +++ b/Documentation/sphinx/kernel_abi.py @@ -138,7 +138,7 @@ class KernelCmd(Directive): code_block += "\n " + l lines = code_block + "\n\n" - line_regex = re.compile("^#define LINENO (\S+)\#([0-9]+)$") + line_regex = re.compile("^\.\. LINENO (\S+)\#([0-9]+)$") ln = 0 n = 0 f = fname -- cgit From b79dfef0e2fcf41c736e7012c59d1260aa60f075 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 26 Mar 2022 11:27:24 +0100 Subject: scripts/kernel-doc: change the line number meta info In order to make it more standard and ReST compatible, change the meta-tag used with --enable-lineno from: #define LINENO to .. LINENO In practice, no functional changes. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/40725032b5a4a33db740bf1de397523af958ff8a.1648290305.git.mchehab@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/sphinx/kerneldoc.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sphinx/kerneldoc.py b/Documentation/sphinx/kerneldoc.py index 8189c33b9dda..9395892c7ba3 100644 --- a/Documentation/sphinx/kerneldoc.py +++ b/Documentation/sphinx/kerneldoc.py @@ -130,7 +130,7 @@ class KernelDocDirective(Directive): result = ViewList() lineoffset = 0; - line_regex = re.compile("^#define LINENO ([0-9]+)$") + line_regex = re.compile("^\.\. LINENO ([0-9]+)$") for line in lines: match = line_regex.search(line) if match: -- cgit From 9df072c73b9891e44f7f59f3b7c8f852b4485e80 Mon Sep 17 00:00:00 2001 From: David Gow Date: Sat, 26 Mar 2022 13:44:15 +0800 Subject: Documentation: kunit: Fix cross-referencing warnings The Architecture chapter of the KUnit documentation tried to include copies of the kernel-doc for a couple of things, despite these already existing in the API documentation. This lead to some warnings: architecture:31: ./include/kunit/test.h:3: WARNING: Duplicate C declaration, also defined at dev-tools/kunit/api/test:66. Declaration is '.. c:struct:: kunit_case'. architecture:163: ./include/kunit/test.h:1217: WARNING: Duplicate C declaration, also defined at dev-tools/kunit/api/test:1217. Declaration is '.. c:macro:: KUNIT_ARRAY_PARAM'. architecture.rst:3: WARNING: Duplicate C declaration, also defined at dev-tools/kunit/api/test:66. Declaration is '.. c:struct:: kunit_case'. architecture.rst:1217: WARNING: Duplicate C declaration, also defined at dev-tools/kunit/api/test:1217. Declaration is '.. c:macro:: KUNIT_ARRAY_PARAM'. Get rid of these, and cleanup the mentions of the struct and macro in question so that sphinx generates a link to the existing copy of the documentation in the api/test document. Fixes: bc145b370c11 ("Documentation: KUnit: Added KUnit Architecture") Signed-off-by: David Gow Reviewed-by: Brendan Higgins Tested-by: Brendan Higgins Link: https://lore.kernel.org/r/20220326054414.637293-1-davidgow@google.com Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/kunit/architecture.rst | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/architecture.rst b/Documentation/dev-tools/kunit/architecture.rst index aa2cea821e25..ff9c85a0bff2 100644 --- a/Documentation/dev-tools/kunit/architecture.rst +++ b/Documentation/dev-tools/kunit/architecture.rst @@ -26,10 +26,7 @@ The fundamental unit in KUnit is the test case. The KUnit test cases are grouped into KUnit suites. A KUnit test case is a function with type signature ``void (*)(struct kunit *test)``. These test case functions are wrapped in a struct called -``struct kunit_case``. For code, see: - -.. kernel-doc:: include/kunit/test.h - :identifiers: kunit_case +struct kunit_case. .. note: ``generate_params`` is optional for non-parameterized tests. @@ -152,18 +149,12 @@ Parameterized Tests Each KUnit parameterized test is associated with a collection of parameters. The test is invoked multiple times, once for each parameter value and the parameter is stored in the ``param_value`` field. -The test case includes a ``KUNIT_CASE_PARAM()`` macro that accepts a +The test case includes a KUNIT_CASE_PARAM() macro that accepts a generator function. The generator function is passed the previous parameter and returns the next parameter. It also provides a macro to generate common-case generators based on arrays. -For code, see: - -.. kernel-doc:: include/kunit/test.h - :identifiers: KUNIT_ARRAY_PARAM - - kunit_tool (Command Line Test Harness) ====================================== -- cgit From dcb09a08d8d4052f8e8567ae2baddfbaf1d9c11f Mon Sep 17 00:00:00 2001 From: "jason-jh.lin" Date: Wed, 9 Mar 2022 21:46:59 +0800 Subject: Revert "dt-bindings: display: mediatek: add ethdr definition for mt8195" This reverts commit e7dcfe64204a5cd9a74a9ca7d9c7a22434dc7fe5. Because examples property of mediatek,ethdr.yaml should base on [1][2]. Reverting it until [1][2] are applied. [1] dt-bindings: mediatek: mt8195: Add binding for MM IOMMU https://patchwork.kernel.org/project/linux-mediatek/patch/20220217113453.13658-2-yong.wu@mediatek.com/ [2] dt-bindings: reset: mt8195: add vdosys1 reset control bit https://patchwork.kernel.org/project/linux-mediatek/patch/20220222100741.30138-5-nancy.lin@mediatek.com/ Signed-off-by: jason-jh.lin Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220309134702.9942-2-jason-jh.lin@mediatek.com --- .../bindings/display/mediatek/mediatek,ethdr.yaml | 147 --------------------- 1 file changed, 147 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml deleted file mode 100644 index 131eed5eeeb7..000000000000 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml +++ /dev/null @@ -1,147 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/display/mediatek/mediatek,ethdr.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Mediatek Ethdr Device Tree Bindings - -maintainers: - - Chun-Kuang Hu - - Philipp Zabel - -description: | - ETHDR is designed for HDR video and graphics conversion in the external display path. - It handles multiple HDR input types and performs tone mapping, color space/color - format conversion, and then combine different layers, output the required HDR or - SDR signal to the subsequent display path. This engine is composed of two video - frontends, two graphic frontends, one video backend and a mixer. ETHDR has two - DMA function blocks, DS and ADL. These two function blocks read the pre-programmed - registers from DRAM and set them to HW in the v-blanking period. - -properties: - compatible: - items: - - const: mediatek,mt8195-disp-ethdr - reg: - maxItems: 7 - reg-names: - items: - - const: mixer - - const: vdo_fe0 - - const: vdo_fe1 - - const: gfx_fe0 - - const: gfx_fe1 - - const: vdo_be - - const: adl_ds - interrupts: - minItems: 1 - iommus: - description: The compatible property is DMA function blocks. - Should point to the respective IOMMU block with master port as argument, - see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for - details. - minItems: 1 - maxItems: 2 - clocks: - items: - - description: mixer clock - - description: video frontend 0 clock - - description: video frontend 1 clock - - description: graphic frontend 0 clock - - description: graphic frontend 1 clock - - description: video backend clock - - description: autodownload and menuload clock - - description: video frontend 0 async clock - - description: video frontend 1 async clock - - description: graphic frontend 0 async clock - - description: graphic frontend 1 async clock - - description: video backend async clock - - description: ethdr top clock - clock-names: - items: - - const: mixer - - const: vdo_fe0 - - const: vdo_fe1 - - const: gfx_fe0 - - const: gfx_fe1 - - const: vdo_be - - const: adl_ds - - const: vdo_fe0_async - - const: vdo_fe1_async - - const: gfx_fe0_async - - const: gfx_fe1_async - - const: vdo_be_async - - const: ethdr_top - power-domains: - maxItems: 1 - resets: - maxItems: 5 - mediatek,gce-client-reg: - $ref: /schemas/types.yaml#/definitions/phandle-array - description: The register of display function block to be set by gce. - There are 4 arguments in this property, gce node, subsys id, offset and - register size. The subsys id is defined in the gce header of each chips - include/include/dt-bindings/gce/-gce.h, mapping to the register of - display function block. - -required: - - compatible - - reg - - clocks - - clock-names - - interrupts - - power-domains - -additionalProperties: false - -examples: - - | - - disp_ethdr@1c114000 { - compatible = "mediatek,mt8195-disp-ethdr"; - reg = <0 0x1c114000 0 0x1000>, - <0 0x1c115000 0 0x1000>, - <0 0x1c117000 0 0x1000>, - <0 0x1c119000 0 0x1000>, - <0 0x1c11A000 0 0x1000>, - <0 0x1c11B000 0 0x1000>, - <0 0x1c11C000 0 0x1000>; - reg-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", - "vdo_be", "adl_ds"; - mediatek,gce-client-reg = <&gce0 SUBSYS_1c11XXXX 0x4000 0x1000>, - <&gce0 SUBSYS_1c11XXXX 0x5000 0x1000>, - <&gce0 SUBSYS_1c11XXXX 0x7000 0x1000>, - <&gce0 SUBSYS_1c11XXXX 0x9000 0x1000>, - <&gce0 SUBSYS_1c11XXXX 0xA000 0x1000>, - <&gce0 SUBSYS_1c11XXXX 0xB000 0x1000>, - <&gce0 SUBSYS_1c11XXXX 0xC000 0x1000>; - clocks = <&vdosys1 CLK_VDO1_DISP_MIXER>, - <&vdosys1 CLK_VDO1_HDR_VDO_FE0>, - <&vdosys1 CLK_VDO1_HDR_VDO_FE1>, - <&vdosys1 CLK_VDO1_HDR_GFX_FE0>, - <&vdosys1 CLK_VDO1_HDR_GFX_FE1>, - <&vdosys1 CLK_VDO1_HDR_VDO_BE>, - <&vdosys1 CLK_VDO1_26M_SLOW>, - <&vdosys1 CLK_VDO1_HDR_VDO_FE0_DL_ASYNC>, - <&vdosys1 CLK_VDO1_HDR_VDO_FE1_DL_ASYNC>, - <&vdosys1 CLK_VDO1_HDR_GFX_FE0_DL_ASYNC>, - <&vdosys1 CLK_VDO1_HDR_GFX_FE1_DL_ASYNC>, - <&vdosys1 CLK_VDO1_HDR_VDO_BE_DL_ASYNC>, - <&topckgen CLK_TOP_ETHDR_SEL>; - clock-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", - "vdo_be", "adl_ds", "vdo_fe0_async", "vdo_fe1_async", - "gfx_fe0_async", "gfx_fe1_async","vdo_be_async", - "ethdr_top"; - power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; - iommus = <&iommu_vpp M4U_PORT_L3_HDR_DS>, - <&iommu_vpp M4U_PORT_L3_HDR_ADL>; - interrupts = ; /* disp mixer */ - resets = <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0_DL_ASYNC>, - <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1_DL_ASYNC>, - <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0_DL_ASYNC>, - <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1_DL_ASYNC>, - <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE_DL_ASYNC>; - }; - -... -- cgit From ab487888d5dfb37b71a256114e8fa6fafdbb3163 Mon Sep 17 00:00:00 2001 From: AngeloGioacchino Del Regno Date: Wed, 9 Mar 2022 21:47:00 +0800 Subject: dt-bindings: display: mediatek, mutex: Fix mediatek, gce-events type The mediatek,gce-events property needs as value an array of uint32 corresponding to the CMDQ events to listen to, and not any phandle. Fixes: 4ed545e7d100 ("dt-bindings: display: mediatek: disp: split each block to individual yaml") Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: jason-jh.lin Acked-by: Rob Herring Acked-by: Chun-Kuang Hu Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220309134702.9942-3-jason-jh.lin@mediatek.com --- Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml index 6eca525eced0..842ba7b07a34 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml @@ -58,7 +58,7 @@ properties: The event id which is mapping to the specific hardware event signal to gce. The event id is defined in the gce header include/dt-bindings/gce/-gce.h of each chips. - $ref: /schemas/types.yaml#/definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/uint32-array required: - compatible -- cgit From 10f17b2054a7ab3b86a8d333d99146fff3e9c728 Mon Sep 17 00:00:00 2001 From: AngeloGioacchino Del Regno Date: Wed, 9 Mar 2022 21:47:01 +0800 Subject: dt-bindings: display: mediatek, ovl: Fix 'iommu' required property typo The property is called 'iommus' and not 'iommu'. Fix this typo. Fixes: 4ed545e7d100 ("dt-bindings: display: mediatek: disp: split each block to individual yaml") Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: jason-jh.lin Acked-by: Rob Herring Acked-by: Chun-Kuang Hu Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220309134702.9942-4-jason-jh.lin@mediatek.com --- Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml index 93d5c68a2dbd..fc691d00c60e 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -75,7 +75,7 @@ required: - interrupts - power-domains - clocks - - iommu + - iommus additionalProperties: false -- cgit From bff4e302a6679b0df8ac950979faabbc8f3ae961 Mon Sep 17 00:00:00 2001 From: AngeloGioacchino Del Regno Date: Wed, 9 Mar 2022 21:47:02 +0800 Subject: dt-bindings: display: mediatek: Fix examples on new bindings To avoid failure of dt_binding_check perform a slight refactoring of the examples: the main block is kept, but that required fixing the address and size cells, plus the inclusion of missing dt-bindings headers, required to parse some of the values assigned to various properties. Fixes: 4ed545e7d100 ("dt-bindings: display: mediatek: disp: split each block to individual yaml") Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: jason-jh.lin Reviewed-by: Rob Herring Acked-by: Chun-Kuang Hu Tested-by: jason-jh.lin Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220309134702.9942-5-jason-jh.lin@mediatek.com --- .../bindings/display/mediatek/mediatek,aal.yaml | 23 ++++++---- .../bindings/display/mediatek/mediatek,ccorr.yaml | 23 ++++++---- .../bindings/display/mediatek/mediatek,color.yaml | 23 ++++++---- .../bindings/display/mediatek/mediatek,dither.yaml | 23 ++++++---- .../bindings/display/mediatek/mediatek,dpi.yaml | 3 +- .../bindings/display/mediatek/mediatek,dsc.yaml | 23 ++++++---- .../bindings/display/mediatek/mediatek,gamma.yaml | 23 ++++++---- .../bindings/display/mediatek/mediatek,merge.yaml | 49 ++++++++++------------ .../bindings/display/mediatek/mediatek,mutex.yaml | 25 +++++++---- .../bindings/display/mediatek/mediatek,od.yaml | 14 +++++-- .../bindings/display/mediatek/mediatek,ovl-2l.yaml | 26 ++++++++---- .../bindings/display/mediatek/mediatek,ovl.yaml | 26 ++++++++---- .../display/mediatek/mediatek,postmask.yaml | 23 ++++++---- .../bindings/display/mediatek/mediatek,rdma.yaml | 28 +++++++++---- .../bindings/display/mediatek/mediatek,split.yaml | 17 +++++--- .../bindings/display/mediatek/mediatek,ufoe.yaml | 19 ++++++--- .../bindings/display/mediatek/mediatek,wdma.yaml | 26 ++++++++---- 17 files changed, 260 insertions(+), 134 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index 225f9dd726d2..61f0ed1e388f 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -66,12 +66,21 @@ additionalProperties: false examples: - | + #include + #include + #include + #include - aal@14015000 { - compatible = "mediatek,mt8173-disp-aal"; - reg = <0 0x14015000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_AAL>; - mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + aal@14015000 { + compatible = "mediatek,mt8173-disp-aal"; + reg = <0 0x14015000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_AAL>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml index 6894b6999412..0ed53b6238f0 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -65,12 +65,21 @@ additionalProperties: false examples: - | + #include + #include + #include + #include - ccorr0: ccorr@1400f000 { - compatible = "mediatek,mt8183-disp-ccorr"; - reg = <0 0x1400f000 0 0x1000>; - interrupts = ; - power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; - clocks = <&mmsys CLK_MM_DISP_CCORR0>; - mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xf000 0x1000>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + ccorr0: ccorr@1400f000 { + compatible = "mediatek,mt8183-disp-ccorr"; + reg = <0 0x1400f000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; + clocks = <&mmsys CLK_MM_DISP_CCORR0>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xf000 0x1000>; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index bc83155b3b4c..3ad842eb5668 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -75,12 +75,21 @@ additionalProperties: false examples: - | + #include + #include + #include + #include - color0: color@14013000 { - compatible = "mediatek,mt8173-disp-color"; - reg = <0 0x14013000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_COLOR0>; - mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x3000 0x1000>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + color0: color@14013000 { + compatible = "mediatek,mt8173-disp-color"; + reg = <0 0x14013000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_COLOR0>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x3000 0x1000>; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml index 9d89297f5f1d..6657549af165 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml @@ -65,12 +65,21 @@ additionalProperties: false examples: - | + #include + #include + #include + #include - dither0: dither@14012000 { - compatible = "mediatek,mt8183-disp-dither"; - reg = <0 0x14012000 0 0x1000>; - interrupts = ; - power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; - clocks = <&mmsys CLK_MM_DISP_DITHER0>; - mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x2000 0x1000>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + dither0: dither@14012000 { + compatible = "mediatek,mt8183-disp-dither"; + reg = <0 0x14012000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; + clocks = <&mmsys CLK_MM_DISP_DITHER0>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x2000 0x1000>; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml index dd2896a40ff0..843f89d6053f 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml @@ -70,8 +70,7 @@ examples: - | #include #include - #include - #include + dpi0: dpi@1401d000 { compatible = "mediatek,mt8173-dpi"; reg = <0x1401d000 0x1000>; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml index 1ec083eff824..49248864514b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml @@ -60,12 +60,21 @@ additionalProperties: false examples: - | + #include + #include + #include + #include - dsc0: disp_dsc_wrap@1c009000 { - compatible = "mediatek,mt8195-disp-dsc"; - reg = <0 0x1c009000 0 0x1000>; - interrupts = ; - power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; - clocks = <&vdosys0 CLK_VDO0_DSC_WRAP0>; - mediatek,gce-client-reg = <&gce1 SUBSYS_1c00XXXX 0x9000 0x1000>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + dsc0: disp_dsc_wrap@1c009000 { + compatible = "mediatek,mt8195-disp-dsc"; + reg = <0 0x1c009000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; + clocks = <&vdosys0 CLK_VDO0_DSC_WRAP0>; + mediatek,gce-client-reg = <&gce1 SUBSYS_1c00XXXX 0x9000 0x1000>; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml index 247baad147b3..78442339314f 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -66,12 +66,21 @@ additionalProperties: false examples: - | + #include + #include + #include + #include - gamma@14016000 { - compatible = "mediatek,mt8173-disp-gamma"; - reg = <0 0x14016000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_GAMMA>; - mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x6000 0x1000>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + gamma@14016000 { + compatible = "mediatek,mt8173-disp-gamma"; + reg = <0 0x14016000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_GAMMA>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x6000 0x1000>; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml index d5cd69b7f501..d635c5dcb68b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml @@ -38,18 +38,16 @@ properties: Documentation/devicetree/bindings/power/power-domain.yaml for details. clocks: + minItems: 1 maxItems: 2 - items: - - description: MERGE Clock - - description: MERGE Async Clock - Controlling the synchronous process between MERGE and other display - function blocks cross clock domain. clock-names: - maxItems: 2 - items: - - const: merge - - const: merge_async + oneOf: + - items: + - const: merge + - items: + - const: merge + - const: merge_async mediatek,merge-fifo-en: description: @@ -88,23 +86,20 @@ additionalProperties: false examples: - | - - merge@14017000 { - compatible = "mediatek,mt8173-disp-merge"; - reg = <0 0x14017000 0 0x1000>; - power-domains = <&spm MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_MERGE>; + #include + #include + #include + + soc { + #address-cells = <2>; + #size-cells = <2>; + + merge@14017000 { + compatible = "mediatek,mt8173-disp-merge"; + reg = <0 0x14017000 0 0x1000>; + power-domains = <&spm MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_MERGE>; + clock-names = "merge"; + }; }; - merge5: disp_vpp_merge5@1c110000 { - compatible = "mediatek,mt8195-disp-merge"; - reg = <0 0x1c110000 0 0x1000>; - interrupts = ; - clocks = <&vdosys1 CLK_VDO1_VPP_MERGE4>, - <&vdosys1 CLK_VDO1_MERGE4_DL_ASYNC>; - clock-names = "merge","merge_async"; - power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; - mediatek,gce-client-reg = <&gce1 SUBSYS_1c11XXXX 0x0000 0x1000>; - mediatek,merge-fifo-en = <1>; - resets = <&vdosys1 MT8195_VDOSYS1_SW0_RST_B_MERGE4_DL_ASYNC>; - }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml index 842ba7b07a34..00e6a1041a9b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml @@ -71,13 +71,22 @@ additionalProperties: false examples: - | + #include + #include + #include + #include - mutex: mutex@14020000 { - compatible = "mediatek,mt8173-disp-mutex"; - reg = <0 0x14020000 0 0x1000>; - interrupts = ; - power-domains = <&spm MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_MUTEX_32K>; - mediatek,gce-events = , - ; + soc { + #address-cells = <2>; + #size-cells = <2>; + + mutex: mutex@14020000 { + compatible = "mediatek,mt8173-disp-mutex"; + reg = <0 0x14020000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_MUTEX_32K>; + mediatek,gce-events = , + ; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml index 7519db315217..853fcb9db2be 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml @@ -45,9 +45,15 @@ additionalProperties: false examples: - | + #include - od@14023000 { - compatible = "mediatek,mt8173-disp-od"; - reg = <0 0x14023000 0 0x1000>; - clocks = <&mmsys CLK_MM_DISP_OD>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + od@14023000 { + compatible = "mediatek,mt8173-disp-od"; + reg = <0 0x14023000 0 0x1000>; + clocks = <&mmsys CLK_MM_DISP_OD>; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml index e3cef99d0f98..da999ba53b7c 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml @@ -66,13 +66,23 @@ additionalProperties: false examples: - | + #include + #include + #include + #include + #include - ovl_2l0: ovl@14009000 { - compatible = "mediatek,mt8183-disp-ovl-2l"; - reg = <0 0x14009000 0 0x1000>; - interrupts = ; - power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; - clocks = <&mmsys CLK_MM_DISP_OVL0_2L>; - iommus = <&iommu M4U_PORT_DISP_2L_OVL0_LARB0>; - mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x9000 0x1000>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + ovl_2l0: ovl@14009000 { + compatible = "mediatek,mt8183-disp-ovl-2l"; + reg = <0 0x14009000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; + clocks = <&mmsys CLK_MM_DISP_OVL0_2L>; + iommus = <&iommu M4U_PORT_DISP_2L_OVL0_LARB0>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x9000 0x1000>; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml index fc691d00c60e..f77094e61443 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -81,13 +81,23 @@ additionalProperties: false examples: - | + #include + #include + #include + #include + #include - ovl0: ovl@1400c000 { - compatible = "mediatek,mt8173-disp-ovl"; - reg = <0 0x1400c000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_OVL0>; - iommus = <&iommu M4U_PORT_DISP_OVL0>; - mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xc000 0x1000>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + ovl0: ovl@1400c000 { + compatible = "mediatek,mt8173-disp-ovl"; + reg = <0 0x1400c000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_OVL0>; + iommus = <&iommu M4U_PORT_DISP_OVL0>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xc000 0x1000>; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml index 6ac1da2e8871..2d769422e29f 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml @@ -58,12 +58,21 @@ additionalProperties: false examples: - | + #include + #include + #include + #include - postmask0: postmask@1400d000 { - compatible = "mediatek,mt8192-disp-postmask"; - reg = <0 0x1400d000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8192_POWER_DOMAIN_DISP>; - clocks = <&mmsys CLK_MM_DISP_POSTMASK0>; - mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xd000 0x1000>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + postmask0: postmask@1400d000 { + compatible = "mediatek,mt8192-disp-postmask"; + reg = <0 0x1400d000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8192_POWER_DOMAIN_DISP>; + clocks = <&mmsys CLK_MM_DISP_POSTMASK0>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xd000 0x1000>; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml index b56e22fbcd52..e8c72afa0630 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml @@ -94,14 +94,24 @@ additionalProperties: false examples: - | + #include + #include + #include + #include + #include - rdma0: rdma@1400e000 { - compatible = "mediatek,mt8173-disp-rdma"; - reg = <0 0x1400e000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_RDMA0>; - iommus = <&iommu M4U_PORT_DISP_RDMA0>; - mediatek,rdma-fifosize = <8192>; - mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xe000 0x1000>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + rdma0: rdma@1400e000 { + compatible = "mediatek,mt8173-disp-rdma"; + reg = <0 0x1400e000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_RDMA0>; + iommus = <&iommu M4U_PORT_DISP_RDMA0>; + mediatek,rdma-fifo-size = <8192>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xe000 0x1000>; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml index 4f08e89c1067..35ace1f322e8 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml @@ -49,10 +49,17 @@ additionalProperties: false examples: - | + #include + #include - split0: split@14018000 { - compatible = "mediatek,mt8173-disp-split"; - reg = <0 0x14018000 0 0x1000>; - power-domains = <&spm MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_SPLIT0>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + split0: split@14018000 { + compatible = "mediatek,mt8173-disp-split"; + reg = <0 0x14018000 0 0x1000>; + power-domains = <&spm MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_SPLIT0>; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml index 6e8748529e73..b8bb135fe96b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml @@ -51,11 +51,18 @@ additionalProperties: false examples: - | + #include + #include + #include + soc { + #address-cells = <2>; + #size-cells = <2>; - ufoe@1401a000 { - compatible = "mediatek,mt8173-disp-ufoe"; - reg = <0 0x1401a000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_UFOE>; + ufoe@1401a000 { + compatible = "mediatek,mt8173-disp-ufoe"; + reg = <0 0x1401a000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_UFOE>; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml index f9f00a518edf..7d7cc1ab526b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml @@ -64,13 +64,23 @@ additionalProperties: false examples: - | + #include + #include + #include + #include + #include - wdma0: wdma@14011000 { - compatible = "mediatek,mt8173-disp-wdma"; - reg = <0 0x14011000 0 0x1000>; - interrupts = ; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_WDMA0>; - iommus = <&iommu M4U_PORT_DISP_WDMA0>; - mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x1000 0x1000>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + wdma0: wdma@14011000 { + compatible = "mediatek,mt8173-disp-wdma"; + reg = <0 0x14011000 0 0x1000>; + interrupts = ; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_WDMA0>; + iommus = <&iommu M4U_PORT_DISP_WDMA0>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x1000 0x1000>; + }; }; -- cgit From 09a2fb41ba67dcb45f259efd1d2baafe4a6be1a7 Mon Sep 17 00:00:00 2001 From: Biao Huang Date: Thu, 24 Mar 2022 09:21:12 +0800 Subject: dt-bindings: net: snps,dwmac: modify available values of PBL PBL can be any of the following values: 1, 2, 4, 8, 16 or 32 according to the datasheet, so modify available values of PBL in snps,dwmac.yaml. Signed-off-by: Biao Huang Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220324012112.7016-2-biao.huang@mediatek.com --- Documentation/devicetree/bindings/net/snps,dwmac.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 7eb43707e601..2d5248f5b919 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -340,21 +340,21 @@ allOf: description: Programmable Burst Length (tx and rx) $ref: /schemas/types.yaml#/definitions/uint32 - enum: [2, 4, 8] + enum: [1, 2, 4, 8, 16, 32] snps,txpbl: description: Tx Programmable Burst Length. If set, DMA tx will use this value rather than snps,pbl. $ref: /schemas/types.yaml#/definitions/uint32 - enum: [2, 4, 8] + enum: [1, 2, 4, 8, 16, 32] snps,rxpbl: description: Rx Programmable Burst Length. If set, DMA rx will use this value rather than snps,pbl. $ref: /schemas/types.yaml#/definitions/uint32 - enum: [2, 4, 8] + enum: [1, 2, 4, 8, 16, 32] snps,no-pbl-x8: $ref: /schemas/types.yaml#/definitions/flag -- cgit From a50e431bbc6fc5768ed26be5fab5b149b7b8b1fe Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 1 Mar 2022 17:35:00 -0600 Subject: dt-bindings: media: mediatek,vcodec: Fix addressing cell sizes 'dma-ranges' in the example is written for cell sizes of 2 cells, but the schema and example specify sizes of 1 cell. As the h/w has a bus address of >32-bits, cell sizes of 2 is correct. Update the schema's '#address-cells' and '#size-cells' to be 2 and adjust the example throughout. There's no error currently because dtc only checks 'dma-ranges' is a correct multiple number of cells (3) and the schema checking is based on bracketing of entries. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220301233501.2110047-1-robh@kernel.org --- .../media/mediatek,vcodec-subdev-decoder.yaml | 122 +++++++++++---------- 1 file changed, 64 insertions(+), 58 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml index d587fc3e39fb..7687be0f50aa 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml @@ -72,10 +72,10 @@ properties: Describes the physical address space of IOMMU maps to memory. "#address-cells": - const: 1 + const: 2 "#size-cells": - const: 1 + const: 2 ranges: true @@ -205,61 +205,67 @@ examples: #include #include - video-codec@16000000 { - compatible = "mediatek,mt8192-vcodec-dec"; - mediatek,scp = <&scp>; - iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>; - dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x16000000 0x40000>; - reg = <0x16000000 0x1000>; /* VDEC_SYS */ - vcodec-lat@10000 { - compatible = "mediatek,mtk-vcodec-lat"; - reg = <0x10000 0x800>; - interrupts = ; - iommus = <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD_EXT>, - <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD2_EXT>, - <&iommu0 M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT>, - <&iommu0 M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT>, - <&iommu0 M4U_PORT_L5_VDEC_LAT0_TILE_EXT>, - <&iommu0 M4U_PORT_L5_VDEC_LAT0_WDMA_EXT>, - <&iommu0 M4U_PORT_L5_VDEC_LAT0_RG_CTRL_DMA_EXT>, - <&iommu0 M4U_PORT_L5_VDEC_UFO_ENC_EXT>; - clocks = <&topckgen CLK_TOP_VDEC_SEL>, - <&vdecsys_soc CLK_VDEC_SOC_VDEC>, - <&vdecsys_soc CLK_VDEC_SOC_LAT>, - <&vdecsys_soc CLK_VDEC_SOC_LARB1>, - <&topckgen CLK_TOP_MAINPLL_D4>; - clock-names = "sel", "soc-vdec", "soc-lat", "vdec", "top"; - assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; - assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; - power-domains = <&spm MT8192_POWER_DOMAIN_VDEC>; - }; - - vcodec-core@25000 { - compatible = "mediatek,mtk-vcodec-core"; - reg = <0x25000 0x1000>; - interrupts = ; - iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>, - <&iommu0 M4U_PORT_L4_VDEC_UFO_EXT>, - <&iommu0 M4U_PORT_L4_VDEC_PP_EXT>, - <&iommu0 M4U_PORT_L4_VDEC_PRED_RD_EXT>, - <&iommu0 M4U_PORT_L4_VDEC_PRED_WR_EXT>, - <&iommu0 M4U_PORT_L4_VDEC_PPWRAP_EXT>, - <&iommu0 M4U_PORT_L4_VDEC_TILE_EXT>, - <&iommu0 M4U_PORT_L4_VDEC_VLD_EXT>, - <&iommu0 M4U_PORT_L4_VDEC_VLD2_EXT>, - <&iommu0 M4U_PORT_L4_VDEC_AVC_MV_EXT>, - <&iommu0 M4U_PORT_L4_VDEC_RG_CTRL_DMA_EXT>; - clocks = <&topckgen CLK_TOP_VDEC_SEL>, - <&vdecsys CLK_VDEC_VDEC>, - <&vdecsys CLK_VDEC_LAT>, - <&vdecsys CLK_VDEC_LARB1>, - <&topckgen CLK_TOP_MAINPLL_D4>; - clock-names = "sel", "soc-vdec", "soc-lat", "vdec", "top"; - assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; - assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; - power-domains = <&spm MT8192_POWER_DOMAIN_VDEC2>; + bus@16000000 { + #address-cells = <2>; + #size-cells = <2>; + ranges = <0 0x16000000 0x16000000 0 0x40000>; + + video-codec@16000000 { + compatible = "mediatek,mt8192-vcodec-dec"; + mediatek,scp = <&scp>; + iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>; + dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; + #address-cells = <2>; + #size-cells = <2>; + ranges = <0 0 0 0x16000000 0 0x40000>; + reg = <0 0x16000000 0 0x1000>; /* VDEC_SYS */ + vcodec-lat@10000 { + compatible = "mediatek,mtk-vcodec-lat"; + reg = <0 0x10000 0 0x800>; + interrupts = ; + iommus = <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD2_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_TILE_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_WDMA_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_RG_CTRL_DMA_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_UFO_ENC_EXT>; + clocks = <&topckgen CLK_TOP_VDEC_SEL>, + <&vdecsys_soc CLK_VDEC_SOC_VDEC>, + <&vdecsys_soc CLK_VDEC_SOC_LAT>, + <&vdecsys_soc CLK_VDEC_SOC_LARB1>, + <&topckgen CLK_TOP_MAINPLL_D4>; + clock-names = "sel", "soc-vdec", "soc-lat", "vdec", "top"; + assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; + power-domains = <&spm MT8192_POWER_DOMAIN_VDEC>; + }; + + vcodec-core@25000 { + compatible = "mediatek,mtk-vcodec-core"; + reg = <0 0x25000 0 0x1000>; + interrupts = ; + iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_UFO_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_PP_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_PRED_RD_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_PRED_WR_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_PPWRAP_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_TILE_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_VLD_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_VLD2_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_AVC_MV_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_RG_CTRL_DMA_EXT>; + clocks = <&topckgen CLK_TOP_VDEC_SEL>, + <&vdecsys CLK_VDEC_VDEC>, + <&vdecsys CLK_VDEC_LAT>, + <&vdecsys CLK_VDEC_LARB1>, + <&topckgen CLK_TOP_MAINPLL_D4>; + clock-names = "sel", "soc-vdec", "soc-lat", "vdec", "top"; + assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; + power-domains = <&spm MT8192_POWER_DOMAIN_VDEC2>; + }; }; }; -- cgit From 22a41e9a5044bf3519f05b4a00e99af34bfeb40c Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 25 Mar 2022 16:56:52 -0500 Subject: dt-bindings: Fix missing '/schemas' in $ref paths Absolute paths in $ref should always begin with '/schemas'. The tools mostly work with it omitted, but for correctness the path should be everything except the hostname as that is taken from the schema's $id value. This scheme is defined in the json-schema spec. Cc: Hector Martin Cc: Sven Peter Cc: Andrew Lunn Cc: Vivien Didelot Cc: Florian Fainelli Cc: Vladimir Oltean Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Mark Brown Cc: Chunfeng Yun Cc: Greg Kroah-Hartman Cc: Mukesh Savaliya Cc: Akash Asthana Cc: Bayi Cheng Cc: Chuanhong Guo Cc: Min Guo Cc: netdev@vger.kernel.org Cc: linux-spi@vger.kernel.org Cc: linux-usb@vger.kernel.org Signed-off-by: Rob Herring Acked-by: Jakub Kicinski Acked-by: Mark Brown Link: https://lore.kernel.org/r/20220325215652.525383-1-robh@kernel.org --- Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml | 2 +- Documentation/devicetree/bindings/net/dsa/dsa-port.yaml | 2 +- Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml | 2 +- Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml | 2 +- Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml | 2 +- Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml | 2 +- Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml | 4 ++-- Documentation/devicetree/bindings/usb/mediatek,musb.yaml | 2 +- 8 files changed, 9 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml b/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml index b6b5d3a912b3..0dc957a56d35 100644 --- a/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml +++ b/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml @@ -42,7 +42,7 @@ patternProperties: description: The individual power management domains within this controller type: object - $ref: /power/apple,pmgr-pwrstate.yaml# + $ref: /schemas/power/apple,pmgr-pwrstate.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml index a6b6b36a3f81..09317e16cb5d 100644 --- a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml +++ b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml @@ -15,7 +15,7 @@ description: Ethernet switch port Description allOf: - - $ref: "http://devicetree.org/schemas/net/ethernet-controller.yaml#" + - $ref: /schemas/net/ethernet-controller.yaml# properties: reg: diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index a776cd37c297..95fcb43675d6 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -103,7 +103,7 @@ patternProperties: supports up to 50MHz, up to four chip selects, programmable data path from 4 bits to 32 bits and numerous protocol variants. - $ref: /spi/spi-controller.yaml# + $ref: /schemas/spi/spi-controller.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml index be3cc7faed53..41e60fe4b09f 100644 --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml @@ -18,7 +18,7 @@ description: | capability of this controller. allOf: - - $ref: /spi/spi-controller.yaml# + - $ref: /schemas/spi/spi-controller.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml index 055524fe8327..5a60fba14bba 100644 --- a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml @@ -16,7 +16,7 @@ description: The QSPI controller allows SPI protocol communication in single, as NOR flash. allOf: - - $ref: /spi/spi-controller.yaml# + - $ref: /schemas/spi/spi-controller.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml b/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml index fe014020da69..a3ab1a1f1eb4 100644 --- a/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml +++ b/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml @@ -44,7 +44,7 @@ description: | compatibility. allOf: - - $ref: /spi/spi-controller.yaml# + - $ref: /schemas/spi/spi-controller.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml index 77db1233516e..df766f8de872 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml @@ -132,7 +132,7 @@ properties: default: host connector: - $ref: /connector/usb-connector.yaml# + $ref: /schemas/connector/usb-connector.yaml# description: Connector for dual role switch, especially for "gpio-usb-b-connector" type: object @@ -191,7 +191,7 @@ properties: patternProperties: "^usb@[0-9a-f]+$": type: object - $ref: /usb/mediatek,mtk-xhci.yaml# + $ref: /schemas/usb/mediatek,mtk-xhci.yaml# description: The xhci should be added as subnode to mtu3 as shown in the following example if the host mode is enabled. diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml index 03d62d60ce5f..11a33f9b1f17 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml @@ -63,7 +63,7 @@ properties: maxItems: 1 connector: - $ref: /connector/usb-connector.yaml# + $ref: /schemas/connector/usb-connector.yaml# description: Connector for dual role switch type: object -- cgit From fd04847372ba86347066c536ba99bc3c1f351334 Mon Sep 17 00:00:00 2001 From: José Roberto de Souza Date: Fri, 25 Mar 2022 11:38:32 -0700 Subject: docs: gpu: i915.rst: Fix DRRS documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit intel_drrs_enable() and intel_drrs_disable() were renamed to intel_drrs_activate() and intel_drrs_deactivate() in commit 54903c7a6b40 ("drm/i915: s/enable/active/ for DRRS") and it is causing warnings when generating the kernel documentation. But as for a while DRRS has its own file, so here just let the tool generate the documentation for all exported and documented functions in intel_drrs.c. Cc: Ville Syrjälä Cc: Rodrigo Vivi Signed-off-by: José Roberto de Souza Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220325183832.146472-1-jose.souza@intel.com --- Documentation/gpu/i915.rst | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index bcaefc952764..0f08693d05cd 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -187,19 +187,7 @@ Display Refresh Rate Switching (DRRS) :doc: Display Refresh Rate Switching (DRRS) .. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c - :functions: intel_drrs_enable - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c - :functions: intel_drrs_disable - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c - :functions: intel_drrs_invalidate - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c - :functions: intel_drrs_flush - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c - :functions: intel_drrs_init + :internal: DPIO ---- -- cgit From e9611bf9d24a259193290f6ac8d33844a054c8f7 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Tue, 22 Mar 2022 12:07:19 +0100 Subject: Documentation: kvm: fixes for locking.rst Separate the various locks clearly, and include the new names of blocked_vcpu_on_cpu_lock and blocked_vcpu_on_cpu. Signed-off-by: Paolo Bonzini Message-Id: <20220322110720.222499-2-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/locking.rst | 28 +++++++++++++++++++--------- 1 file changed, 19 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index 5d27da356836..6c9aa4f49608 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -210,32 +210,41 @@ time it will be set using the Dirty tracking mechanism described above. 3. Reference ------------ -:Name: kvm_lock +``kvm_lock`` +^^^^^^^^^^^^ + :Type: mutex :Arch: any :Protects: - vm_list -:Name: kvm_count_lock +``kvm_count_lock`` +^^^^^^^^^^^^^^^^^^ + :Type: raw_spinlock_t :Arch: any :Protects: - hardware virtualization enable/disable :Comment: 'raw' because hardware enabling/disabling must be atomic /wrt migration. -:Name: kvm_arch::tsc_write_lock -:Type: raw_spinlock + +``kvm_arch::tsc_write_lock`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +:Type: raw_spinlock_t :Arch: x86 :Protects: - kvm_arch::{last_tsc_write,last_tsc_nsec,last_tsc_offset} - tsc offset in vmcb :Comment: 'raw' because updating the tsc offsets must not be preempted. -:Name: kvm->mmu_lock -:Type: spinlock_t +``kvm->mmu_lock`` +^^^^^^^^^^^^^^^^^ +:Type: spinlock_t or rwlock_t :Arch: any :Protects: -shadow page/shadow tlb entry :Comment: it is a spinlock since it is used in mmu notifier. -:Name: kvm->srcu +``kvm->srcu`` +^^^^^^^^^^^^^ :Type: srcu lock :Arch: any :Protects: - kvm->memslots @@ -246,10 +255,11 @@ time it will be set using the Dirty tracking mechanism described above. The srcu index can be stored in kvm_vcpu->srcu_idx per vcpu if it is needed by multiple functions. -:Name: blocked_vcpu_on_cpu_lock +``wakeup_vcpus_on_cpu_lock`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :Type: spinlock_t :Arch: x86 -:Protects: blocked_vcpu_on_cpu +:Protects: wakeup_vcpus_on_cpu :Comment: This is a per-CPU lock and it is used for VT-d posted-interrupts. When VT-d posted-interrupts is supported and the VM has assigned devices, we put the blocked vCPU on the list blocked_vcpu_on_cpu -- cgit From 99a17b77704a44a89ec22509d73b1727763f2930 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Tue, 22 Mar 2022 12:07:20 +0100 Subject: Documentation: kvm: include new locks kvm->mn_invalidate_lock and kvm->slots_arch_lock were not included in the documentation, add them. Signed-off-by: Paolo Bonzini Message-Id: <20220322110720.222499-3-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/locking.rst | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index 6c9aa4f49608..845a561629f1 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -226,6 +226,12 @@ time it will be set using the Dirty tracking mechanism described above. :Comment: 'raw' because hardware enabling/disabling must be atomic /wrt migration. +``kvm->mn_invalidate_lock`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +:Type: spinlock_t +:Arch: any +:Protects: mn_active_invalidate_count, mn_memslots_update_rcuwait ``kvm_arch::tsc_write_lock`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -255,6 +261,15 @@ time it will be set using the Dirty tracking mechanism described above. The srcu index can be stored in kvm_vcpu->srcu_idx per vcpu if it is needed by multiple functions. +``kvm->slots_arch_lock`` +^^^^^^^^^^^^^^^^^^^^^^^^ +:Type: mutex +:Arch: any (only needed on x86 though) +:Protects: any arch-specific fields of memslots that have to be modified + in a ``kvm->srcu`` read-side critical section. +:Comment: must be held before reading the pointer to the current memslots, + until after all changes to the memslots are complete + ``wakeup_vcpus_on_cpu_lock`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :Type: spinlock_t -- cgit From daec8d408308ee7322d86cdd2dc3332e9cdbedf9 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Tue, 22 Mar 2022 12:07:10 +0100 Subject: Documentation: KVM: add separate directories for architecture-specific documentation ARM already has an arm/ subdirectory, but s390 and x86 do not even though they have a relatively large number of files specific to them. Create new directories in Documentation/virt/kvm for these two architectures as well. While at it, group the API documentation and the developer documentation in the table of contents. Signed-off-by: Paolo Bonzini Message-Id: <20220322110712.222449-2-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/amd-memory-encryption.rst | 445 -------------- Documentation/virt/kvm/cpuid.rst | 124 ---- Documentation/virt/kvm/halt-polling.rst | 140 ----- Documentation/virt/kvm/hypercalls.rst | 192 ------ Documentation/virt/kvm/index.rst | 26 +- Documentation/virt/kvm/mmu.rst | 480 --------------- Documentation/virt/kvm/msr.rst | 391 ------------- Documentation/virt/kvm/nested-vmx.rst | 244 -------- Documentation/virt/kvm/running-nested-guests.rst | 276 --------- Documentation/virt/kvm/s390-diag.rst | 119 ---- Documentation/virt/kvm/s390-pv-boot.rst | 84 --- Documentation/virt/kvm/s390-pv.rst | 116 ---- Documentation/virt/kvm/s390/index.rst | 12 + Documentation/virt/kvm/s390/s390-diag.rst | 119 ++++ Documentation/virt/kvm/s390/s390-pv-boot.rst | 84 +++ Documentation/virt/kvm/s390/s390-pv.rst | 116 ++++ Documentation/virt/kvm/timekeeping.rst | 645 --------------------- .../virt/kvm/x86/amd-memory-encryption.rst | 445 ++++++++++++++ Documentation/virt/kvm/x86/cpuid.rst | 124 ++++ Documentation/virt/kvm/x86/halt-polling.rst | 140 +++++ Documentation/virt/kvm/x86/hypercalls.rst | 192 ++++++ Documentation/virt/kvm/x86/index.rst | 18 + Documentation/virt/kvm/x86/mmu.rst | 480 +++++++++++++++ Documentation/virt/kvm/x86/msr.rst | 391 +++++++++++++ Documentation/virt/kvm/x86/nested-vmx.rst | 244 ++++++++ .../virt/kvm/x86/running-nested-guests.rst | 276 +++++++++ Documentation/virt/kvm/x86/timekeeping.rst | 645 +++++++++++++++++++++ 27 files changed, 3293 insertions(+), 3275 deletions(-) delete mode 100644 Documentation/virt/kvm/amd-memory-encryption.rst delete mode 100644 Documentation/virt/kvm/cpuid.rst delete mode 100644 Documentation/virt/kvm/halt-polling.rst delete mode 100644 Documentation/virt/kvm/hypercalls.rst delete mode 100644 Documentation/virt/kvm/mmu.rst delete mode 100644 Documentation/virt/kvm/msr.rst delete mode 100644 Documentation/virt/kvm/nested-vmx.rst delete mode 100644 Documentation/virt/kvm/running-nested-guests.rst delete mode 100644 Documentation/virt/kvm/s390-diag.rst delete mode 100644 Documentation/virt/kvm/s390-pv-boot.rst delete mode 100644 Documentation/virt/kvm/s390-pv.rst create mode 100644 Documentation/virt/kvm/s390/index.rst create mode 100644 Documentation/virt/kvm/s390/s390-diag.rst create mode 100644 Documentation/virt/kvm/s390/s390-pv-boot.rst create mode 100644 Documentation/virt/kvm/s390/s390-pv.rst delete mode 100644 Documentation/virt/kvm/timekeeping.rst create mode 100644 Documentation/virt/kvm/x86/amd-memory-encryption.rst create mode 100644 Documentation/virt/kvm/x86/cpuid.rst create mode 100644 Documentation/virt/kvm/x86/halt-polling.rst create mode 100644 Documentation/virt/kvm/x86/hypercalls.rst create mode 100644 Documentation/virt/kvm/x86/index.rst create mode 100644 Documentation/virt/kvm/x86/mmu.rst create mode 100644 Documentation/virt/kvm/x86/msr.rst create mode 100644 Documentation/virt/kvm/x86/nested-vmx.rst create mode 100644 Documentation/virt/kvm/x86/running-nested-guests.rst create mode 100644 Documentation/virt/kvm/x86/timekeeping.rst (limited to 'Documentation') diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst b/Documentation/virt/kvm/amd-memory-encryption.rst deleted file mode 100644 index 1c6847fff304..000000000000 --- a/Documentation/virt/kvm/amd-memory-encryption.rst +++ /dev/null @@ -1,445 +0,0 @@ -====================================== -Secure Encrypted Virtualization (SEV) -====================================== - -Overview -======== - -Secure Encrypted Virtualization (SEV) is a feature found on AMD processors. - -SEV is an extension to the AMD-V architecture which supports running -virtual machines (VMs) under the control of a hypervisor. When enabled, -the memory contents of a VM will be transparently encrypted with a key -unique to that VM. - -The hypervisor can determine the SEV support through the CPUID -instruction. The CPUID function 0x8000001f reports information related -to SEV:: - - 0x8000001f[eax]: - Bit[1] indicates support for SEV - ... - [ecx]: - Bits[31:0] Number of encrypted guests supported simultaneously - -If support for SEV is present, MSR 0xc001_0010 (MSR_AMD64_SYSCFG) and MSR 0xc001_0015 -(MSR_K7_HWCR) can be used to determine if it can be enabled:: - - 0xc001_0010: - Bit[23] 1 = memory encryption can be enabled - 0 = memory encryption can not be enabled - - 0xc001_0015: - Bit[0] 1 = memory encryption can be enabled - 0 = memory encryption can not be enabled - -When SEV support is available, it can be enabled in a specific VM by -setting the SEV bit before executing VMRUN.:: - - VMCB[0x90]: - Bit[1] 1 = SEV is enabled - 0 = SEV is disabled - -SEV hardware uses ASIDs to associate a memory encryption key with a VM. -Hence, the ASID for the SEV-enabled guests must be from 1 to a maximum value -defined in the CPUID 0x8000001f[ecx] field. - -SEV Key Management -================== - -The SEV guest key management is handled by a separate processor called the AMD -Secure Processor (AMD-SP). Firmware running inside the AMD-SP provides a secure -key management interface to perform common hypervisor activities such as -encrypting bootstrap code, snapshot, migrating and debugging the guest. For more -information, see the SEV Key Management spec [api-spec]_ - -The main ioctl to access SEV is KVM_MEMORY_ENCRYPT_OP. If the argument -to KVM_MEMORY_ENCRYPT_OP is NULL, the ioctl returns 0 if SEV is enabled -and ``ENOTTY` if it is disabled (on some older versions of Linux, -the ioctl runs normally even with a NULL argument, and therefore will -likely return ``EFAULT``). If non-NULL, the argument to KVM_MEMORY_ENCRYPT_OP -must be a struct kvm_sev_cmd:: - - struct kvm_sev_cmd { - __u32 id; - __u64 data; - __u32 error; - __u32 sev_fd; - }; - - -The ``id`` field contains the subcommand, and the ``data`` field points to -another struct containing arguments specific to command. The ``sev_fd`` -should point to a file descriptor that is opened on the ``/dev/sev`` -device, if needed (see individual commands). - -On output, ``error`` is zero on success, or an error code. Error codes -are defined in ````. - -KVM implements the following commands to support common lifecycle events of SEV -guests, such as launching, running, snapshotting, migrating and decommissioning. - -1. KVM_SEV_INIT ---------------- - -The KVM_SEV_INIT command is used by the hypervisor to initialize the SEV platform -context. In a typical workflow, this command should be the first command issued. - -The firmware can be initialized either by using its own non-volatile storage or -the OS can manage the NV storage for the firmware using the module parameter -``init_ex_path``. The file specified by ``init_ex_path`` must exist. To create -a new NV storage file allocate the file with 32KB bytes of 0xFF as required by -the SEV spec. - -Returns: 0 on success, -negative on error - -2. KVM_SEV_LAUNCH_START ------------------------ - -The KVM_SEV_LAUNCH_START command is used for creating the memory encryption -context. To create the encryption context, user must provide a guest policy, -the owner's public Diffie-Hellman (PDH) key and session information. - -Parameters: struct kvm_sev_launch_start (in/out) - -Returns: 0 on success, -negative on error - -:: - - struct kvm_sev_launch_start { - __u32 handle; /* if zero then firmware creates a new handle */ - __u32 policy; /* guest's policy */ - - __u64 dh_uaddr; /* userspace address pointing to the guest owner's PDH key */ - __u32 dh_len; - - __u64 session_addr; /* userspace address which points to the guest session information */ - __u32 session_len; - }; - -On success, the 'handle' field contains a new handle and on error, a negative value. - -KVM_SEV_LAUNCH_START requires the ``sev_fd`` field to be valid. - -For more details, see SEV spec Section 6.2. - -3. KVM_SEV_LAUNCH_UPDATE_DATA ------------------------------ - -The KVM_SEV_LAUNCH_UPDATE_DATA is used for encrypting a memory region. It also -calculates a measurement of the memory contents. The measurement is a signature -of the memory contents that can be sent to the guest owner as an attestation -that the memory was encrypted correctly by the firmware. - -Parameters (in): struct kvm_sev_launch_update_data - -Returns: 0 on success, -negative on error - -:: - - struct kvm_sev_launch_update { - __u64 uaddr; /* userspace address to be encrypted (must be 16-byte aligned) */ - __u32 len; /* length of the data to be encrypted (must be 16-byte aligned) */ - }; - -For more details, see SEV spec Section 6.3. - -4. KVM_SEV_LAUNCH_MEASURE -------------------------- - -The KVM_SEV_LAUNCH_MEASURE command is used to retrieve the measurement of the -data encrypted by the KVM_SEV_LAUNCH_UPDATE_DATA command. The guest owner may -wait to provide the guest with confidential information until it can verify the -measurement. Since the guest owner knows the initial contents of the guest at -boot, the measurement can be verified by comparing it to what the guest owner -expects. - -If len is zero on entry, the measurement blob length is written to len and -uaddr is unused. - -Parameters (in): struct kvm_sev_launch_measure - -Returns: 0 on success, -negative on error - -:: - - struct kvm_sev_launch_measure { - __u64 uaddr; /* where to copy the measurement */ - __u32 len; /* length of measurement blob */ - }; - -For more details on the measurement verification flow, see SEV spec Section 6.4. - -5. KVM_SEV_LAUNCH_FINISH ------------------------- - -After completion of the launch flow, the KVM_SEV_LAUNCH_FINISH command can be -issued to make the guest ready for the execution. - -Returns: 0 on success, -negative on error - -6. KVM_SEV_GUEST_STATUS ------------------------ - -The KVM_SEV_GUEST_STATUS command is used to retrieve status information about a -SEV-enabled guest. - -Parameters (out): struct kvm_sev_guest_status - -Returns: 0 on success, -negative on error - -:: - - struct kvm_sev_guest_status { - __u32 handle; /* guest handle */ - __u32 policy; /* guest policy */ - __u8 state; /* guest state (see enum below) */ - }; - -SEV guest state: - -:: - - enum { - SEV_STATE_INVALID = 0; - SEV_STATE_LAUNCHING, /* guest is currently being launched */ - SEV_STATE_SECRET, /* guest is being launched and ready to accept the ciphertext data */ - SEV_STATE_RUNNING, /* guest is fully launched and running */ - SEV_STATE_RECEIVING, /* guest is being migrated in from another SEV machine */ - SEV_STATE_SENDING /* guest is getting migrated out to another SEV machine */ - }; - -7. KVM_SEV_DBG_DECRYPT ----------------------- - -The KVM_SEV_DEBUG_DECRYPT command can be used by the hypervisor to request the -firmware to decrypt the data at the given memory region. - -Parameters (in): struct kvm_sev_dbg - -Returns: 0 on success, -negative on error - -:: - - struct kvm_sev_dbg { - __u64 src_uaddr; /* userspace address of data to decrypt */ - __u64 dst_uaddr; /* userspace address of destination */ - __u32 len; /* length of memory region to decrypt */ - }; - -The command returns an error if the guest policy does not allow debugging. - -8. KVM_SEV_DBG_ENCRYPT ----------------------- - -The KVM_SEV_DEBUG_ENCRYPT command can be used by the hypervisor to request the -firmware to encrypt the data at the given memory region. - -Parameters (in): struct kvm_sev_dbg - -Returns: 0 on success, -negative on error - -:: - - struct kvm_sev_dbg { - __u64 src_uaddr; /* userspace address of data to encrypt */ - __u64 dst_uaddr; /* userspace address of destination */ - __u32 len; /* length of memory region to encrypt */ - }; - -The command returns an error if the guest policy does not allow debugging. - -9. KVM_SEV_LAUNCH_SECRET ------------------------- - -The KVM_SEV_LAUNCH_SECRET command can be used by the hypervisor to inject secret -data after the measurement has been validated by the guest owner. - -Parameters (in): struct kvm_sev_launch_secret - -Returns: 0 on success, -negative on error - -:: - - struct kvm_sev_launch_secret { - __u64 hdr_uaddr; /* userspace address containing the packet header */ - __u32 hdr_len; - - __u64 guest_uaddr; /* the guest memory region where the secret should be injected */ - __u32 guest_len; - - __u64 trans_uaddr; /* the hypervisor memory region which contains the secret */ - __u32 trans_len; - }; - -10. KVM_SEV_GET_ATTESTATION_REPORT ----------------------------------- - -The KVM_SEV_GET_ATTESTATION_REPORT command can be used by the hypervisor to query the attestation -report containing the SHA-256 digest of the guest memory and VMSA passed through the KVM_SEV_LAUNCH -commands and signed with the PEK. The digest returned by the command should match the digest -used by the guest owner with the KVM_SEV_LAUNCH_MEASURE. - -If len is zero on entry, the measurement blob length is written to len and -uaddr is unused. - -Parameters (in): struct kvm_sev_attestation - -Returns: 0 on success, -negative on error - -:: - - struct kvm_sev_attestation_report { - __u8 mnonce[16]; /* A random mnonce that will be placed in the report */ - - __u64 uaddr; /* userspace address where the report should be copied */ - __u32 len; - }; - -11. KVM_SEV_SEND_START ----------------------- - -The KVM_SEV_SEND_START command can be used by the hypervisor to create an -outgoing guest encryption context. - -If session_len is zero on entry, the length of the guest session information is -written to session_len and all other fields are not used. - -Parameters (in): struct kvm_sev_send_start - -Returns: 0 on success, -negative on error - -:: - - struct kvm_sev_send_start { - __u32 policy; /* guest policy */ - - __u64 pdh_cert_uaddr; /* platform Diffie-Hellman certificate */ - __u32 pdh_cert_len; - - __u64 plat_certs_uaddr; /* platform certificate chain */ - __u32 plat_certs_len; - - __u64 amd_certs_uaddr; /* AMD certificate */ - __u32 amd_certs_len; - - __u64 session_uaddr; /* Guest session information */ - __u32 session_len; - }; - -12. KVM_SEV_SEND_UPDATE_DATA ----------------------------- - -The KVM_SEV_SEND_UPDATE_DATA command can be used by the hypervisor to encrypt the -outgoing guest memory region with the encryption context creating using -KVM_SEV_SEND_START. - -If hdr_len or trans_len are zero on entry, the length of the packet header and -transport region are written to hdr_len and trans_len respectively, and all -other fields are not used. - -Parameters (in): struct kvm_sev_send_update_data - -Returns: 0 on success, -negative on error - -:: - - struct kvm_sev_launch_send_update_data { - __u64 hdr_uaddr; /* userspace address containing the packet header */ - __u32 hdr_len; - - __u64 guest_uaddr; /* the source memory region to be encrypted */ - __u32 guest_len; - - __u64 trans_uaddr; /* the destination memory region */ - __u32 trans_len; - }; - -13. KVM_SEV_SEND_FINISH ------------------------- - -After completion of the migration flow, the KVM_SEV_SEND_FINISH command can be -issued by the hypervisor to delete the encryption context. - -Returns: 0 on success, -negative on error - -14. KVM_SEV_SEND_CANCEL ------------------------- - -After completion of SEND_START, but before SEND_FINISH, the source VMM can issue the -SEND_CANCEL command to stop a migration. This is necessary so that a cancelled -migration can restart with a new target later. - -Returns: 0 on success, -negative on error - -15. KVM_SEV_RECEIVE_START -------------------------- - -The KVM_SEV_RECEIVE_START command is used for creating the memory encryption -context for an incoming SEV guest. To create the encryption context, the user must -provide a guest policy, the platform public Diffie-Hellman (PDH) key and session -information. - -Parameters: struct kvm_sev_receive_start (in/out) - -Returns: 0 on success, -negative on error - -:: - - struct kvm_sev_receive_start { - __u32 handle; /* if zero then firmware creates a new handle */ - __u32 policy; /* guest's policy */ - - __u64 pdh_uaddr; /* userspace address pointing to the PDH key */ - __u32 pdh_len; - - __u64 session_uaddr; /* userspace address which points to the guest session information */ - __u32 session_len; - }; - -On success, the 'handle' field contains a new handle and on error, a negative value. - -For more details, see SEV spec Section 6.12. - -16. KVM_SEV_RECEIVE_UPDATE_DATA -------------------------------- - -The KVM_SEV_RECEIVE_UPDATE_DATA command can be used by the hypervisor to copy -the incoming buffers into the guest memory region with encryption context -created during the KVM_SEV_RECEIVE_START. - -Parameters (in): struct kvm_sev_receive_update_data - -Returns: 0 on success, -negative on error - -:: - - struct kvm_sev_launch_receive_update_data { - __u64 hdr_uaddr; /* userspace address containing the packet header */ - __u32 hdr_len; - - __u64 guest_uaddr; /* the destination guest memory region */ - __u32 guest_len; - - __u64 trans_uaddr; /* the incoming buffer memory region */ - __u32 trans_len; - }; - -17. KVM_SEV_RECEIVE_FINISH --------------------------- - -After completion of the migration flow, the KVM_SEV_RECEIVE_FINISH command can be -issued by the hypervisor to make the guest ready for execution. - -Returns: 0 on success, -negative on error - -References -========== - - -See [white-paper]_, [api-spec]_, [amd-apm]_ and [kvm-forum]_ for more info. - -.. [white-paper] http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf -.. [api-spec] https://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf -.. [amd-apm] https://support.amd.com/TechDocs/24593.pdf (section 15.34) -.. [kvm-forum] https://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf diff --git a/Documentation/virt/kvm/cpuid.rst b/Documentation/virt/kvm/cpuid.rst deleted file mode 100644 index bda3e3e737d7..000000000000 --- a/Documentation/virt/kvm/cpuid.rst +++ /dev/null @@ -1,124 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -============== -KVM CPUID bits -============== - -:Author: Glauber Costa - -A guest running on a kvm host, can check some of its features using -cpuid. This is not always guaranteed to work, since userspace can -mask-out some, or even all KVM-related cpuid features before launching -a guest. - -KVM cpuid functions are: - -function: KVM_CPUID_SIGNATURE (0x40000000) - -returns:: - - eax = 0x40000001 - ebx = 0x4b4d564b - ecx = 0x564b4d56 - edx = 0x4d - -Note that this value in ebx, ecx and edx corresponds to the string "KVMKVMKVM". -The value in eax corresponds to the maximum cpuid function present in this leaf, -and will be updated if more functions are added in the future. -Note also that old hosts set eax value to 0x0. This should -be interpreted as if the value was 0x40000001. -This function queries the presence of KVM cpuid leafs. - -function: define KVM_CPUID_FEATURES (0x40000001) - -returns:: - - ebx, ecx - eax = an OR'ed group of (1 << flag) - -where ``flag`` is defined as below: - -================================== =========== ================================ -flag value meaning -================================== =========== ================================ -KVM_FEATURE_CLOCKSOURCE 0 kvmclock available at msrs - 0x11 and 0x12 - -KVM_FEATURE_NOP_IO_DELAY 1 not necessary to perform delays - on PIO operations - -KVM_FEATURE_MMU_OP 2 deprecated - -KVM_FEATURE_CLOCKSOURCE2 3 kvmclock available at msrs - 0x4b564d00 and 0x4b564d01 - -KVM_FEATURE_ASYNC_PF 4 async pf can be enabled by - writing to msr 0x4b564d02 - -KVM_FEATURE_STEAL_TIME 5 steal time can be enabled by - writing to msr 0x4b564d03 - -KVM_FEATURE_PV_EOI 6 paravirtualized end of interrupt - handler can be enabled by - writing to msr 0x4b564d04 - -KVM_FEATURE_PV_UNHALT 7 guest checks this feature bit - before enabling paravirtualized - spinlock support - -KVM_FEATURE_PV_TLB_FLUSH 9 guest checks this feature bit - before enabling paravirtualized - tlb flush - -KVM_FEATURE_ASYNC_PF_VMEXIT 10 paravirtualized async PF VM EXIT - can be enabled by setting bit 2 - when writing to msr 0x4b564d02 - -KVM_FEATURE_PV_SEND_IPI 11 guest checks this feature bit - before enabling paravirtualized - send IPIs - -KVM_FEATURE_POLL_CONTROL 12 host-side polling on HLT can - be disabled by writing - to msr 0x4b564d05. - -KVM_FEATURE_PV_SCHED_YIELD 13 guest checks this feature bit - before using paravirtualized - sched yield. - -KVM_FEATURE_ASYNC_PF_INT 14 guest checks this feature bit - before using the second async - pf control msr 0x4b564d06 and - async pf acknowledgment msr - 0x4b564d07. - -KVM_FEATURE_MSI_EXT_DEST_ID 15 guest checks this feature bit - before using extended destination - ID bits in MSI address bits 11-5. - -KVM_FEATURE_HC_MAP_GPA_RANGE 16 guest checks this feature bit before - using the map gpa range hypercall - to notify the page state change - -KVM_FEATURE_MIGRATION_CONTROL 17 guest checks this feature bit before - using MSR_KVM_MIGRATION_CONTROL - -KVM_FEATURE_CLOCKSOURCE_STABLE_BIT 24 host will warn if no guest-side - per-cpu warps are expected in - kvmclock -================================== =========== ================================ - -:: - - edx = an OR'ed group of (1 << flag) - -Where ``flag`` here is defined as below: - -================== ============ ================================= -flag value meaning -================== ============ ================================= -KVM_HINTS_REALTIME 0 guest checks this feature bit to - determine that vCPUs are never - preempted for an unlimited time - allowing optimizations -================== ============ ================================= diff --git a/Documentation/virt/kvm/halt-polling.rst b/Documentation/virt/kvm/halt-polling.rst deleted file mode 100644 index 4922e4a15f18..000000000000 --- a/Documentation/virt/kvm/halt-polling.rst +++ /dev/null @@ -1,140 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -=========================== -The KVM halt polling system -=========================== - -The KVM halt polling system provides a feature within KVM whereby the latency -of a guest can, under some circumstances, be reduced by polling in the host -for some time period after the guest has elected to no longer run by cedeing. -That is, when a guest vcpu has ceded, or in the case of powerpc when all of the -vcpus of a single vcore have ceded, the host kernel polls for wakeup conditions -before giving up the cpu to the scheduler in order to let something else run. - -Polling provides a latency advantage in cases where the guest can be run again -very quickly by at least saving us a trip through the scheduler, normally on -the order of a few micro-seconds, although performance benefits are workload -dependant. In the event that no wakeup source arrives during the polling -interval or some other task on the runqueue is runnable the scheduler is -invoked. Thus halt polling is especially useful on workloads with very short -wakeup periods where the time spent halt polling is minimised and the time -savings of not invoking the scheduler are distinguishable. - -The generic halt polling code is implemented in: - - virt/kvm/kvm_main.c: kvm_vcpu_block() - -The powerpc kvm-hv specific case is implemented in: - - arch/powerpc/kvm/book3s_hv.c: kvmppc_vcore_blocked() - -Halt Polling Interval -===================== - -The maximum time for which to poll before invoking the scheduler, referred to -as the halt polling interval, is increased and decreased based on the perceived -effectiveness of the polling in an attempt to limit pointless polling. -This value is stored in either the vcpu struct: - - kvm_vcpu->halt_poll_ns - -or in the case of powerpc kvm-hv, in the vcore struct: - - kvmppc_vcore->halt_poll_ns - -Thus this is a per vcpu (or vcore) value. - -During polling if a wakeup source is received within the halt polling interval, -the interval is left unchanged. In the event that a wakeup source isn't -received during the polling interval (and thus schedule is invoked) there are -two options, either the polling interval and total block time[0] were less than -the global max polling interval (see module params below), or the total block -time was greater than the global max polling interval. - -In the event that both the polling interval and total block time were less than -the global max polling interval then the polling interval can be increased in -the hope that next time during the longer polling interval the wake up source -will be received while the host is polling and the latency benefits will be -received. The polling interval is grown in the function grow_halt_poll_ns() and -is multiplied by the module parameters halt_poll_ns_grow and -halt_poll_ns_grow_start. - -In the event that the total block time was greater than the global max polling -interval then the host will never poll for long enough (limited by the global -max) to wakeup during the polling interval so it may as well be shrunk in order -to avoid pointless polling. The polling interval is shrunk in the function -shrink_halt_poll_ns() and is divided by the module parameter -halt_poll_ns_shrink, or set to 0 iff halt_poll_ns_shrink == 0. - -It is worth noting that this adjustment process attempts to hone in on some -steady state polling interval but will only really do a good job for wakeups -which come at an approximately constant rate, otherwise there will be constant -adjustment of the polling interval. - -[0] total block time: - the time between when the halt polling function is - invoked and a wakeup source received (irrespective of - whether the scheduler is invoked within that function). - -Module Parameters -================= - -The kvm module has 3 tuneable module parameters to adjust the global max -polling interval as well as the rate at which the polling interval is grown and -shrunk. These variables are defined in include/linux/kvm_host.h and as module -parameters in virt/kvm/kvm_main.c, or arch/powerpc/kvm/book3s_hv.c in the -powerpc kvm-hv case. - -+-----------------------+---------------------------+-------------------------+ -|Module Parameter | Description | Default Value | -+-----------------------+---------------------------+-------------------------+ -|halt_poll_ns | The global max polling | KVM_HALT_POLL_NS_DEFAULT| -| | interval which defines | | -| | the ceiling value of the | | -| | polling interval for | (per arch value) | -| | each vcpu. | | -+-----------------------+---------------------------+-------------------------+ -|halt_poll_ns_grow | The value by which the | 2 | -| | halt polling interval is | | -| | multiplied in the | | -| | grow_halt_poll_ns() | | -| | function. | | -+-----------------------+---------------------------+-------------------------+ -|halt_poll_ns_grow_start| The initial value to grow | 10000 | -| | to from zero in the | | -| | grow_halt_poll_ns() | | -| | function. | | -+-----------------------+---------------------------+-------------------------+ -|halt_poll_ns_shrink | The value by which the | 0 | -| | halt polling interval is | | -| | divided in the | | -| | shrink_halt_poll_ns() | | -| | function. | | -+-----------------------+---------------------------+-------------------------+ - -These module parameters can be set from the debugfs files in: - - /sys/module/kvm/parameters/ - -Note: that these module parameters are system wide values and are not able to - be tuned on a per vm basis. - -Further Notes -============= - -- Care should be taken when setting the halt_poll_ns module parameter as a large value - has the potential to drive the cpu usage to 100% on a machine which would be almost - entirely idle otherwise. This is because even if a guest has wakeups during which very - little work is done and which are quite far apart, if the period is shorter than the - global max polling interval (halt_poll_ns) then the host will always poll for the - entire block time and thus cpu utilisation will go to 100%. - -- Halt polling essentially presents a trade off between power usage and latency and - the module parameters should be used to tune the affinity for this. Idle cpu time is - essentially converted to host kernel time with the aim of decreasing latency when - entering the guest. - -- Halt polling will only be conducted by the host when no other tasks are runnable on - that cpu, otherwise the polling will cease immediately and schedule will be invoked to - allow that other task to run. Thus this doesn't allow a guest to denial of service the - cpu. diff --git a/Documentation/virt/kvm/hypercalls.rst b/Documentation/virt/kvm/hypercalls.rst deleted file mode 100644 index e56fa8b9cfca..000000000000 --- a/Documentation/virt/kvm/hypercalls.rst +++ /dev/null @@ -1,192 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -=================== -Linux KVM Hypercall -=================== - -X86: - KVM Hypercalls have a three-byte sequence of either the vmcall or the vmmcall - instruction. The hypervisor can replace it with instructions that are - guaranteed to be supported. - - Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively. - The hypercall number should be placed in rax and the return value will be - placed in rax. No other registers will be clobbered unless explicitly stated - by the particular hypercall. - -S390: - R2-R7 are used for parameters 1-6. In addition, R1 is used for hypercall - number. The return value is written to R2. - - S390 uses diagnose instruction as hypercall (0x500) along with hypercall - number in R1. - - For further information on the S390 diagnose call as supported by KVM, - refer to Documentation/virt/kvm/s390-diag.rst. - -PowerPC: - It uses R3-R10 and hypercall number in R11. R4-R11 are used as output registers. - Return value is placed in R3. - - KVM hypercalls uses 4 byte opcode, that are patched with 'hypercall-instructions' - property inside the device tree's /hypervisor node. - For more information refer to Documentation/virt/kvm/ppc-pv.rst - -MIPS: - KVM hypercalls use the HYPCALL instruction with code 0 and the hypercall - number in $2 (v0). Up to four arguments may be placed in $4-$7 (a0-a3) and - the return value is placed in $2 (v0). - -KVM Hypercalls Documentation -============================ - -The template for each hypercall is: -1. Hypercall name. -2. Architecture(s) -3. Status (deprecated, obsolete, active) -4. Purpose - -1. KVM_HC_VAPIC_POLL_IRQ ------------------------- - -:Architecture: x86 -:Status: active -:Purpose: Trigger guest exit so that the host can check for pending - interrupts on reentry. - -2. KVM_HC_MMU_OP ----------------- - -:Architecture: x86 -:Status: deprecated. -:Purpose: Support MMU operations such as writing to PTE, - flushing TLB, release PT. - -3. KVM_HC_FEATURES ------------------- - -:Architecture: PPC -:Status: active -:Purpose: Expose hypercall availability to the guest. On x86 platforms, cpuid - used to enumerate which hypercalls are available. On PPC, either - device tree based lookup ( which is also what EPAPR dictates) - OR KVM specific enumeration mechanism (which is this hypercall) - can be used. - -4. KVM_HC_PPC_MAP_MAGIC_PAGE ----------------------------- - -:Architecture: PPC -:Status: active -:Purpose: To enable communication between the hypervisor and guest there is a - shared page that contains parts of supervisor visible register state. - The guest can map this shared page to access its supervisor register - through memory using this hypercall. - -5. KVM_HC_KICK_CPU ------------------- - -:Architecture: x86 -:Status: active -:Purpose: Hypercall used to wakeup a vcpu from HLT state -:Usage example: - A vcpu of a paravirtualized guest that is busywaiting in guest - kernel mode for an event to occur (ex: a spinlock to become available) can - execute HLT instruction once it has busy-waited for more than a threshold - time-interval. Execution of HLT instruction would cause the hypervisor to put - the vcpu to sleep until occurrence of an appropriate event. Another vcpu of the - same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall, - specifying APIC ID (a1) of the vcpu to be woken up. An additional argument (a0) - is used in the hypercall for future use. - - -6. KVM_HC_CLOCK_PAIRING ------------------------ -:Architecture: x86 -:Status: active -:Purpose: Hypercall used to synchronize host and guest clocks. - -Usage: - -a0: guest physical address where host copies -"struct kvm_clock_offset" structure. - -a1: clock_type, ATM only KVM_CLOCK_PAIRING_WALLCLOCK (0) -is supported (corresponding to the host's CLOCK_REALTIME clock). - - :: - - struct kvm_clock_pairing { - __s64 sec; - __s64 nsec; - __u64 tsc; - __u32 flags; - __u32 pad[9]; - }; - - Where: - * sec: seconds from clock_type clock. - * nsec: nanoseconds from clock_type clock. - * tsc: guest TSC value used to calculate sec/nsec pair - * flags: flags, unused (0) at the moment. - -The hypercall lets a guest compute a precise timestamp across -host and guest. The guest can use the returned TSC value to -compute the CLOCK_REALTIME for its clock, at the same instant. - -Returns KVM_EOPNOTSUPP if the host does not use TSC clocksource, -or if clock type is different than KVM_CLOCK_PAIRING_WALLCLOCK. - -6. KVM_HC_SEND_IPI ------------------- - -:Architecture: x86 -:Status: active -:Purpose: Send IPIs to multiple vCPUs. - -- a0: lower part of the bitmap of destination APIC IDs -- a1: higher part of the bitmap of destination APIC IDs -- a2: the lowest APIC ID in bitmap -- a3: APIC ICR - -The hypercall lets a guest send multicast IPIs, with at most 128 -128 destinations per hypercall in 64-bit mode and 64 vCPUs per -hypercall in 32-bit mode. The destinations are represented by a -bitmap contained in the first two arguments (a0 and a1). Bit 0 of -a0 corresponds to the APIC ID in the third argument (a2), bit 1 -corresponds to the APIC ID a2+1, and so on. - -Returns the number of CPUs to which the IPIs were delivered successfully. - -7. KVM_HC_SCHED_YIELD ---------------------- - -:Architecture: x86 -:Status: active -:Purpose: Hypercall used to yield if the IPI target vCPU is preempted - -a0: destination APIC ID - -:Usage example: When sending a call-function IPI-many to vCPUs, yield if - any of the IPI target vCPUs was preempted. - -8. KVM_HC_MAP_GPA_RANGE -------------------------- -:Architecture: x86 -:Status: active -:Purpose: Request KVM to map a GPA range with the specified attributes. - -a0: the guest physical address of the start page -a1: the number of (4kb) pages (must be contiguous in GPA space) -a2: attributes - - Where 'attributes' : - * bits 3:0 - preferred page size encoding 0 = 4kb, 1 = 2mb, 2 = 1gb, etc... - * bit 4 - plaintext = 0, encrypted = 1 - * bits 63:5 - reserved (must be zero) - -**Implementation note**: this hypercall is implemented in userspace via -the KVM_CAP_EXIT_HYPERCALL capability. Userspace must enable that capability -before advertising KVM_FEATURE_HC_MAP_GPA_RANGE in the guest CPUID. In -addition, if the guest supports KVM_FEATURE_MIGRATION_CONTROL, userspace -must also set up an MSR filter to process writes to MSR_KVM_MIGRATION_CONTROL. diff --git a/Documentation/virt/kvm/index.rst b/Documentation/virt/kvm/index.rst index b6833c7bb474..e0a2c74e1043 100644 --- a/Documentation/virt/kvm/index.rst +++ b/Documentation/virt/kvm/index.rst @@ -8,25 +8,13 @@ KVM :maxdepth: 2 api - amd-memory-encryption - cpuid - halt-polling - hypercalls - locking - mmu - msr - nested-vmx - ppc-pv - s390-diag - s390-pv - s390-pv-boot - timekeeping - vcpu-requests - - review-checklist + devices/index arm/index + s390/index + ppc-pv + x86/index - devices/index - - running-nested-guests + locking + vcpu-requests + review-checklist diff --git a/Documentation/virt/kvm/mmu.rst b/Documentation/virt/kvm/mmu.rst deleted file mode 100644 index 5b1ebad24c77..000000000000 --- a/Documentation/virt/kvm/mmu.rst +++ /dev/null @@ -1,480 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -====================== -The x86 kvm shadow mmu -====================== - -The mmu (in arch/x86/kvm, files mmu.[ch] and paging_tmpl.h) is responsible -for presenting a standard x86 mmu to the guest, while translating guest -physical addresses to host physical addresses. - -The mmu code attempts to satisfy the following requirements: - -- correctness: - the guest should not be able to determine that it is running - on an emulated mmu except for timing (we attempt to comply - with the specification, not emulate the characteristics of - a particular implementation such as tlb size) -- security: - the guest must not be able to touch host memory not assigned - to it -- performance: - minimize the performance penalty imposed by the mmu -- scaling: - need to scale to large memory and large vcpu guests -- hardware: - support the full range of x86 virtualization hardware -- integration: - Linux memory management code must be in control of guest memory - so that swapping, page migration, page merging, transparent - hugepages, and similar features work without change -- dirty tracking: - report writes to guest memory to enable live migration - and framebuffer-based displays -- footprint: - keep the amount of pinned kernel memory low (most memory - should be shrinkable) -- reliability: - avoid multipage or GFP_ATOMIC allocations - -Acronyms -======== - -==== ==================================================================== -pfn host page frame number -hpa host physical address -hva host virtual address -gfn guest frame number -gpa guest physical address -gva guest virtual address -ngpa nested guest physical address -ngva nested guest virtual address -pte page table entry (used also to refer generically to paging structure - entries) -gpte guest pte (referring to gfns) -spte shadow pte (referring to pfns) -tdp two dimensional paging (vendor neutral term for NPT and EPT) -==== ==================================================================== - -Virtual and real hardware supported -=================================== - -The mmu supports first-generation mmu hardware, which allows an atomic switch -of the current paging mode and cr3 during guest entry, as well as -two-dimensional paging (AMD's NPT and Intel's EPT). The emulated hardware -it exposes is the traditional 2/3/4 level x86 mmu, with support for global -pages, pae, pse, pse36, cr0.wp, and 1GB pages. Emulated hardware also -able to expose NPT capable hardware on NPT capable hosts. - -Translation -=========== - -The primary job of the mmu is to program the processor's mmu to translate -addresses for the guest. Different translations are required at different -times: - -- when guest paging is disabled, we translate guest physical addresses to - host physical addresses (gpa->hpa) -- when guest paging is enabled, we translate guest virtual addresses, to - guest physical addresses, to host physical addresses (gva->gpa->hpa) -- when the guest launches a guest of its own, we translate nested guest - virtual addresses, to nested guest physical addresses, to guest physical - addresses, to host physical addresses (ngva->ngpa->gpa->hpa) - -The primary challenge is to encode between 1 and 3 translations into hardware -that support only 1 (traditional) and 2 (tdp) translations. When the -number of required translations matches the hardware, the mmu operates in -direct mode; otherwise it operates in shadow mode (see below). - -Memory -====== - -Guest memory (gpa) is part of the user address space of the process that is -using kvm. Userspace defines the translation between guest addresses and user -addresses (gpa->hva); note that two gpas may alias to the same hva, but not -vice versa. - -These hvas may be backed using any method available to the host: anonymous -memory, file backed memory, and device memory. Memory might be paged by the -host at any time. - -Events -====== - -The mmu is driven by events, some from the guest, some from the host. - -Guest generated events: - -- writes to control registers (especially cr3) -- invlpg/invlpga instruction execution -- access to missing or protected translations - -Host generated events: - -- changes in the gpa->hpa translation (either through gpa->hva changes or - through hva->hpa changes) -- memory pressure (the shrinker) - -Shadow pages -============ - -The principal data structure is the shadow page, 'struct kvm_mmu_page'. A -shadow page contains 512 sptes, which can be either leaf or nonleaf sptes. A -shadow page may contain a mix of leaf and nonleaf sptes. - -A nonleaf spte allows the hardware mmu to reach the leaf pages and -is not related to a translation directly. It points to other shadow pages. - -A leaf spte corresponds to either one or two translations encoded into -one paging structure entry. These are always the lowest level of the -translation stack, with optional higher level translations left to NPT/EPT. -Leaf ptes point at guest pages. - -The following table shows translations encoded by leaf ptes, with higher-level -translations in parentheses: - - Non-nested guests:: - - nonpaging: gpa->hpa - paging: gva->gpa->hpa - paging, tdp: (gva->)gpa->hpa - - Nested guests:: - - non-tdp: ngva->gpa->hpa (*) - tdp: (ngva->)ngpa->gpa->hpa - - (*) the guest hypervisor will encode the ngva->gpa translation into its page - tables if npt is not present - -Shadow pages contain the following information: - role.level: - The level in the shadow paging hierarchy that this shadow page belongs to. - 1=4k sptes, 2=2M sptes, 3=1G sptes, etc. - role.direct: - If set, leaf sptes reachable from this page are for a linear range. - Examples include real mode translation, large guest pages backed by small - host pages, and gpa->hpa translations when NPT or EPT is active. - The linear range starts at (gfn << PAGE_SHIFT) and its size is determined - by role.level (2MB for first level, 1GB for second level, 0.5TB for third - level, 256TB for fourth level) - If clear, this page corresponds to a guest page table denoted by the gfn - field. - role.quadrant: - When role.has_4_byte_gpte=1, the guest uses 32-bit gptes while the host uses 64-bit - sptes. That means a guest page table contains more ptes than the host, - so multiple shadow pages are needed to shadow one guest page. - For first-level shadow pages, role.quadrant can be 0 or 1 and denotes the - first or second 512-gpte block in the guest page table. For second-level - page tables, each 32-bit gpte is converted to two 64-bit sptes - (since each first-level guest page is shadowed by two first-level - shadow pages) so role.quadrant takes values in the range 0..3. Each - quadrant maps 1GB virtual address space. - role.access: - Inherited guest access permissions from the parent ptes in the form uwx. - Note execute permission is positive, not negative. - role.invalid: - The page is invalid and should not be used. It is a root page that is - currently pinned (by a cpu hardware register pointing to it); once it is - unpinned it will be destroyed. - role.has_4_byte_gpte: - Reflects the size of the guest PTE for which the page is valid, i.e. '0' - if direct map or 64-bit gptes are in use, '1' if 32-bit gptes are in use. - role.efer_nx: - Contains the value of efer.nx for which the page is valid. - role.cr0_wp: - Contains the value of cr0.wp for which the page is valid. - role.smep_andnot_wp: - Contains the value of cr4.smep && !cr0.wp for which the page is valid - (pages for which this is true are different from other pages; see the - treatment of cr0.wp=0 below). - role.smap_andnot_wp: - Contains the value of cr4.smap && !cr0.wp for which the page is valid - (pages for which this is true are different from other pages; see the - treatment of cr0.wp=0 below). - role.smm: - Is 1 if the page is valid in system management mode. This field - determines which of the kvm_memslots array was used to build this - shadow page; it is also used to go back from a struct kvm_mmu_page - to a memslot, through the kvm_memslots_for_spte_role macro and - __gfn_to_memslot. - role.ad_disabled: - Is 1 if the MMU instance cannot use A/D bits. EPT did not have A/D - bits before Haswell; shadow EPT page tables also cannot use A/D bits - if the L1 hypervisor does not enable them. - gfn: - Either the guest page table containing the translations shadowed by this - page, or the base page frame for linear translations. See role.direct. - spt: - A pageful of 64-bit sptes containing the translations for this page. - Accessed by both kvm and hardware. - The page pointed to by spt will have its page->private pointing back - at the shadow page structure. - sptes in spt point either at guest pages, or at lower-level shadow pages. - Specifically, if sp1 and sp2 are shadow pages, then sp1->spt[n] may point - at __pa(sp2->spt). sp2 will point back at sp1 through parent_pte. - The spt array forms a DAG structure with the shadow page as a node, and - guest pages as leaves. - gfns: - An array of 512 guest frame numbers, one for each present pte. Used to - perform a reverse map from a pte to a gfn. When role.direct is set, any - element of this array can be calculated from the gfn field when used, in - this case, the array of gfns is not allocated. See role.direct and gfn. - root_count: - A counter keeping track of how many hardware registers (guest cr3 or - pdptrs) are now pointing at the page. While this counter is nonzero, the - page cannot be destroyed. See role.invalid. - parent_ptes: - The reverse mapping for the pte/ptes pointing at this page's spt. If - parent_ptes bit 0 is zero, only one spte points at this page and - parent_ptes points at this single spte, otherwise, there exists multiple - sptes pointing at this page and (parent_ptes & ~0x1) points at a data - structure with a list of parent sptes. - unsync: - If true, then the translations in this page may not match the guest's - translation. This is equivalent to the state of the tlb when a pte is - changed but before the tlb entry is flushed. Accordingly, unsync ptes - are synchronized when the guest executes invlpg or flushes its tlb by - other means. Valid for leaf pages. - unsync_children: - How many sptes in the page point at pages that are unsync (or have - unsynchronized children). - unsync_child_bitmap: - A bitmap indicating which sptes in spt point (directly or indirectly) at - pages that may be unsynchronized. Used to quickly locate all unsychronized - pages reachable from a given page. - clear_spte_count: - Only present on 32-bit hosts, where a 64-bit spte cannot be written - atomically. The reader uses this while running out of the MMU lock - to detect in-progress updates and retry them until the writer has - finished the write. - write_flooding_count: - A guest may write to a page table many times, causing a lot of - emulations if the page needs to be write-protected (see "Synchronized - and unsynchronized pages" below). Leaf pages can be unsynchronized - so that they do not trigger frequent emulation, but this is not - possible for non-leafs. This field counts the number of emulations - since the last time the page table was actually used; if emulation - is triggered too frequently on this page, KVM will unmap the page - to avoid emulation in the future. - -Reverse map -=========== - -The mmu maintains a reverse mapping whereby all ptes mapping a page can be -reached given its gfn. This is used, for example, when swapping out a page. - -Synchronized and unsynchronized pages -===================================== - -The guest uses two events to synchronize its tlb and page tables: tlb flushes -and page invalidations (invlpg). - -A tlb flush means that we need to synchronize all sptes reachable from the -guest's cr3. This is expensive, so we keep all guest page tables write -protected, and synchronize sptes to gptes when a gpte is written. - -A special case is when a guest page table is reachable from the current -guest cr3. In this case, the guest is obliged to issue an invlpg instruction -before using the translation. We take advantage of that by removing write -protection from the guest page, and allowing the guest to modify it freely. -We synchronize modified gptes when the guest invokes invlpg. This reduces -the amount of emulation we have to do when the guest modifies multiple gptes, -or when the a guest page is no longer used as a page table and is used for -random guest data. - -As a side effect we have to resynchronize all reachable unsynchronized shadow -pages on a tlb flush. - - -Reaction to events -================== - -- guest page fault (or npt page fault, or ept violation) - -This is the most complicated event. The cause of a page fault can be: - - - a true guest fault (the guest translation won't allow the access) (*) - - access to a missing translation - - access to a protected translation - - when logging dirty pages, memory is write protected - - synchronized shadow pages are write protected (*) - - access to untranslatable memory (mmio) - - (*) not applicable in direct mode - -Handling a page fault is performed as follows: - - - if the RSV bit of the error code is set, the page fault is caused by guest - accessing MMIO and cached MMIO information is available. - - - walk shadow page table - - check for valid generation number in the spte (see "Fast invalidation of - MMIO sptes" below) - - cache the information to vcpu->arch.mmio_gva, vcpu->arch.mmio_access and - vcpu->arch.mmio_gfn, and call the emulator - - - If both P bit and R/W bit of error code are set, this could possibly - be handled as a "fast page fault" (fixed without taking the MMU lock). See - the description in Documentation/virt/kvm/locking.rst. - - - if needed, walk the guest page tables to determine the guest translation - (gva->gpa or ngpa->gpa) - - - if permissions are insufficient, reflect the fault back to the guest - - - determine the host page - - - if this is an mmio request, there is no host page; cache the info to - vcpu->arch.mmio_gva, vcpu->arch.mmio_access and vcpu->arch.mmio_gfn - - - walk the shadow page table to find the spte for the translation, - instantiating missing intermediate page tables as necessary - - - If this is an mmio request, cache the mmio info to the spte and set some - reserved bit on the spte (see callers of kvm_mmu_set_mmio_spte_mask) - - - try to unsynchronize the page - - - if successful, we can let the guest continue and modify the gpte - - - emulate the instruction - - - if failed, unshadow the page and let the guest continue - - - update any translations that were modified by the instruction - -invlpg handling: - - - walk the shadow page hierarchy and drop affected translations - - try to reinstantiate the indicated translation in the hope that the - guest will use it in the near future - -Guest control register updates: - -- mov to cr3 - - - look up new shadow roots - - synchronize newly reachable shadow pages - -- mov to cr0/cr4/efer - - - set up mmu context for new paging mode - - look up new shadow roots - - synchronize newly reachable shadow pages - -Host translation updates: - - - mmu notifier called with updated hva - - look up affected sptes through reverse map - - drop (or update) translations - -Emulating cr0.wp -================ - -If tdp is not enabled, the host must keep cr0.wp=1 so page write protection -works for the guest kernel, not guest guest userspace. When the guest -cr0.wp=1, this does not present a problem. However when the guest cr0.wp=0, -we cannot map the permissions for gpte.u=1, gpte.w=0 to any spte (the -semantics require allowing any guest kernel access plus user read access). - -We handle this by mapping the permissions to two possible sptes, depending -on fault type: - -- kernel write fault: spte.u=0, spte.w=1 (allows full kernel access, - disallows user access) -- read fault: spte.u=1, spte.w=0 (allows full read access, disallows kernel - write access) - -(user write faults generate a #PF) - -In the first case there are two additional complications: - -- if CR4.SMEP is enabled: since we've turned the page into a kernel page, - the kernel may now execute it. We handle this by also setting spte.nx. - If we get a user fetch or read fault, we'll change spte.u=1 and - spte.nx=gpte.nx back. For this to work, KVM forces EFER.NX to 1 when - shadow paging is in use. -- if CR4.SMAP is disabled: since the page has been changed to a kernel - page, it can not be reused when CR4.SMAP is enabled. We set - CR4.SMAP && !CR0.WP into shadow page's role to avoid this case. Note, - here we do not care the case that CR4.SMAP is enabled since KVM will - directly inject #PF to guest due to failed permission check. - -To prevent an spte that was converted into a kernel page with cr0.wp=0 -from being written by the kernel after cr0.wp has changed to 1, we make -the value of cr0.wp part of the page role. This means that an spte created -with one value of cr0.wp cannot be used when cr0.wp has a different value - -it will simply be missed by the shadow page lookup code. A similar issue -exists when an spte created with cr0.wp=0 and cr4.smep=0 is used after -changing cr4.smep to 1. To avoid this, the value of !cr0.wp && cr4.smep -is also made a part of the page role. - -Large pages -=========== - -The mmu supports all combinations of large and small guest and host pages. -Supported page sizes include 4k, 2M, 4M, and 1G. 4M pages are treated as -two separate 2M pages, on both guest and host, since the mmu always uses PAE -paging. - -To instantiate a large spte, four constraints must be satisfied: - -- the spte must point to a large host page -- the guest pte must be a large pte of at least equivalent size (if tdp is - enabled, there is no guest pte and this condition is satisfied) -- if the spte will be writeable, the large page frame may not overlap any - write-protected pages -- the guest page must be wholly contained by a single memory slot - -To check the last two conditions, the mmu maintains a ->disallow_lpage set of -arrays for each memory slot and large page size. Every write protected page -causes its disallow_lpage to be incremented, thus preventing instantiation of -a large spte. The frames at the end of an unaligned memory slot have -artificially inflated ->disallow_lpages so they can never be instantiated. - -Fast invalidation of MMIO sptes -=============================== - -As mentioned in "Reaction to events" above, kvm will cache MMIO -information in leaf sptes. When a new memslot is added or an existing -memslot is changed, this information may become stale and needs to be -invalidated. This also needs to hold the MMU lock while walking all -shadow pages, and is made more scalable with a similar technique. - -MMIO sptes have a few spare bits, which are used to store a -generation number. The global generation number is stored in -kvm_memslots(kvm)->generation, and increased whenever guest memory info -changes. - -When KVM finds an MMIO spte, it checks the generation number of the spte. -If the generation number of the spte does not equal the global generation -number, it will ignore the cached MMIO information and handle the page -fault through the slow path. - -Since only 18 bits are used to store generation-number on mmio spte, all -pages are zapped when there is an overflow. - -Unfortunately, a single memory access might access kvm_memslots(kvm) multiple -times, the last one happening when the generation number is retrieved and -stored into the MMIO spte. Thus, the MMIO spte might be created based on -out-of-date information, but with an up-to-date generation number. - -To avoid this, the generation number is incremented again after synchronize_srcu -returns; thus, bit 63 of kvm_memslots(kvm)->generation set to 1 only during a -memslot update, while some SRCU readers might be using the old copy. We do not -want to use an MMIO sptes created with an odd generation number, and we can do -this without losing a bit in the MMIO spte. The "update in-progress" bit of the -generation is not stored in MMIO spte, and is so is implicitly zero when the -generation is extracted out of the spte. If KVM is unlucky and creates an MMIO -spte while an update is in-progress, the next access to the spte will always be -a cache miss. For example, a subsequent access during the update window will -miss due to the in-progress flag diverging, while an access after the update -window closes will have a higher generation number (as compared to the spte). - - -Further reading -=============== - -- NPT presentation from KVM Forum 2008 - https://www.linux-kvm.org/images/c/c8/KvmForum2008%24kdf2008_21.pdf diff --git a/Documentation/virt/kvm/msr.rst b/Documentation/virt/kvm/msr.rst deleted file mode 100644 index 9315fc385fb0..000000000000 --- a/Documentation/virt/kvm/msr.rst +++ /dev/null @@ -1,391 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -================= -KVM-specific MSRs -================= - -:Author: Glauber Costa , Red Hat Inc, 2010 - -KVM makes use of some custom MSRs to service some requests. - -Custom MSRs have a range reserved for them, that goes from -0x4b564d00 to 0x4b564dff. There are MSRs outside this area, -but they are deprecated and their use is discouraged. - -Custom MSR list ---------------- - -The current supported Custom MSR list is: - -MSR_KVM_WALL_CLOCK_NEW: - 0x4b564d00 - -data: - 4-byte alignment physical address of a memory area which must be - in guest RAM. This memory is expected to hold a copy of the following - structure:: - - struct pvclock_wall_clock { - u32 version; - u32 sec; - u32 nsec; - } __attribute__((__packed__)); - - whose data will be filled in by the hypervisor. The hypervisor is only - guaranteed to update this data at the moment of MSR write. - Users that want to reliably query this information more than once have - to write more than once to this MSR. Fields have the following meanings: - - version: - guest has to check version before and after grabbing - time information and check that they are both equal and even. - An odd version indicates an in-progress update. - - sec: - number of seconds for wallclock at time of boot. - - nsec: - number of nanoseconds for wallclock at time of boot. - - In order to get the current wallclock time, the system_time from - MSR_KVM_SYSTEM_TIME_NEW needs to be added. - - Note that although MSRs are per-CPU entities, the effect of this - particular MSR is global. - - Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid - leaf prior to usage. - -MSR_KVM_SYSTEM_TIME_NEW: - 0x4b564d01 - -data: - 4-byte aligned physical address of a memory area which must be in - guest RAM, plus an enable bit in bit 0. This memory is expected to hold - a copy of the following structure:: - - struct pvclock_vcpu_time_info { - u32 version; - u32 pad0; - u64 tsc_timestamp; - u64 system_time; - u32 tsc_to_system_mul; - s8 tsc_shift; - u8 flags; - u8 pad[2]; - } __attribute__((__packed__)); /* 32 bytes */ - - whose data will be filled in by the hypervisor periodically. Only one - write, or registration, is needed for each VCPU. The interval between - updates of this structure is arbitrary and implementation-dependent. - The hypervisor may update this structure at any time it sees fit until - anything with bit0 == 0 is written to it. - - Fields have the following meanings: - - version: - guest has to check version before and after grabbing - time information and check that they are both equal and even. - An odd version indicates an in-progress update. - - tsc_timestamp: - the tsc value at the current VCPU at the time - of the update of this structure. Guests can subtract this value - from current tsc to derive a notion of elapsed time since the - structure update. - - system_time: - a host notion of monotonic time, including sleep - time at the time this structure was last updated. Unit is - nanoseconds. - - tsc_to_system_mul: - multiplier to be used when converting - tsc-related quantity to nanoseconds - - tsc_shift: - shift to be used when converting tsc-related - quantity to nanoseconds. This shift will ensure that - multiplication with tsc_to_system_mul does not overflow. - A positive value denotes a left shift, a negative value - a right shift. - - The conversion from tsc to nanoseconds involves an additional - right shift by 32 bits. With this information, guests can - derive per-CPU time by doing:: - - time = (current_tsc - tsc_timestamp) - if (tsc_shift >= 0) - time <<= tsc_shift; - else - time >>= -tsc_shift; - time = (time * tsc_to_system_mul) >> 32 - time = time + system_time - - flags: - bits in this field indicate extended capabilities - coordinated between the guest and the hypervisor. Availability - of specific flags has to be checked in 0x40000001 cpuid leaf. - Current flags are: - - - +-----------+--------------+----------------------------------+ - | flag bit | cpuid bit | meaning | - +-----------+--------------+----------------------------------+ - | | | time measures taken across | - | 0 | 24 | multiple cpus are guaranteed to | - | | | be monotonic | - +-----------+--------------+----------------------------------+ - | | | guest vcpu has been paused by | - | 1 | N/A | the host | - | | | See 4.70 in api.txt | - +-----------+--------------+----------------------------------+ - - Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid - leaf prior to usage. - - -MSR_KVM_WALL_CLOCK: - 0x11 - -data and functioning: - same as MSR_KVM_WALL_CLOCK_NEW. Use that instead. - - This MSR falls outside the reserved KVM range and may be removed in the - future. Its usage is deprecated. - - Availability of this MSR must be checked via bit 0 in 0x4000001 cpuid - leaf prior to usage. - -MSR_KVM_SYSTEM_TIME: - 0x12 - -data and functioning: - same as MSR_KVM_SYSTEM_TIME_NEW. Use that instead. - - This MSR falls outside the reserved KVM range and may be removed in the - future. Its usage is deprecated. - - Availability of this MSR must be checked via bit 0 in 0x4000001 cpuid - leaf prior to usage. - - The suggested algorithm for detecting kvmclock presence is then:: - - if (!kvm_para_available()) /* refer to cpuid.txt */ - return NON_PRESENT; - - flags = cpuid_eax(0x40000001); - if (flags & 3) { - msr_kvm_system_time = MSR_KVM_SYSTEM_TIME_NEW; - msr_kvm_wall_clock = MSR_KVM_WALL_CLOCK_NEW; - return PRESENT; - } else if (flags & 0) { - msr_kvm_system_time = MSR_KVM_SYSTEM_TIME; - msr_kvm_wall_clock = MSR_KVM_WALL_CLOCK; - return PRESENT; - } else - return NON_PRESENT; - -MSR_KVM_ASYNC_PF_EN: - 0x4b564d02 - -data: - Asynchronous page fault (APF) control MSR. - - Bits 63-6 hold 64-byte aligned physical address of a 64 byte memory area - which must be in guest RAM and must be zeroed. This memory is expected - to hold a copy of the following structure:: - - struct kvm_vcpu_pv_apf_data { - /* Used for 'page not present' events delivered via #PF */ - __u32 flags; - - /* Used for 'page ready' events delivered via interrupt notification */ - __u32 token; - - __u8 pad[56]; - __u32 enabled; - }; - - Bits 5-4 of the MSR are reserved and should be zero. Bit 0 is set to 1 - when asynchronous page faults are enabled on the vcpu, 0 when disabled. - Bit 1 is 1 if asynchronous page faults can be injected when vcpu is in - cpl == 0. Bit 2 is 1 if asynchronous page faults are delivered to L1 as - #PF vmexits. Bit 2 can be set only if KVM_FEATURE_ASYNC_PF_VMEXIT is - present in CPUID. Bit 3 enables interrupt based delivery of 'page ready' - events. Bit 3 can only be set if KVM_FEATURE_ASYNC_PF_INT is present in - CPUID. - - 'Page not present' events are currently always delivered as synthetic - #PF exception. During delivery of these events APF CR2 register contains - a token that will be used to notify the guest when missing page becomes - available. Also, to make it possible to distinguish between real #PF and - APF, first 4 bytes of 64 byte memory location ('flags') will be written - to by the hypervisor at the time of injection. Only first bit of 'flags' - is currently supported, when set, it indicates that the guest is dealing - with asynchronous 'page not present' event. If during a page fault APF - 'flags' is '0' it means that this is regular page fault. Guest is - supposed to clear 'flags' when it is done handling #PF exception so the - next event can be delivered. - - Note, since APF 'page not present' events use the same exception vector - as regular page fault, guest must reset 'flags' to '0' before it does - something that can generate normal page fault. - - Bytes 5-7 of 64 byte memory location ('token') will be written to by the - hypervisor at the time of APF 'page ready' event injection. The content - of these bytes is a token which was previously delivered as 'page not - present' event. The event indicates the page in now available. Guest is - supposed to write '0' to 'token' when it is done handling 'page ready' - event and to write 1' to MSR_KVM_ASYNC_PF_ACK after clearing the location; - writing to the MSR forces KVM to re-scan its queue and deliver the next - pending notification. - - Note, MSR_KVM_ASYNC_PF_INT MSR specifying the interrupt vector for 'page - ready' APF delivery needs to be written to before enabling APF mechanism - in MSR_KVM_ASYNC_PF_EN or interrupt #0 can get injected. The MSR is - available if KVM_FEATURE_ASYNC_PF_INT is present in CPUID. - - Note, previously, 'page ready' events were delivered via the same #PF - exception as 'page not present' events but this is now deprecated. If - bit 3 (interrupt based delivery) is not set APF events are not delivered. - - If APF is disabled while there are outstanding APFs, they will - not be delivered. - - Currently 'page ready' APF events will be always delivered on the - same vcpu as 'page not present' event was, but guest should not rely on - that. - -MSR_KVM_STEAL_TIME: - 0x4b564d03 - -data: - 64-byte alignment physical address of a memory area which must be - in guest RAM, plus an enable bit in bit 0. This memory is expected to - hold a copy of the following structure:: - - struct kvm_steal_time { - __u64 steal; - __u32 version; - __u32 flags; - __u8 preempted; - __u8 u8_pad[3]; - __u32 pad[11]; - } - - whose data will be filled in by the hypervisor periodically. Only one - write, or registration, is needed for each VCPU. The interval between - updates of this structure is arbitrary and implementation-dependent. - The hypervisor may update this structure at any time it sees fit until - anything with bit0 == 0 is written to it. Guest is required to make sure - this structure is initialized to zero. - - Fields have the following meanings: - - version: - a sequence counter. In other words, guest has to check - this field before and after grabbing time information and make - sure they are both equal and even. An odd version indicates an - in-progress update. - - flags: - At this point, always zero. May be used to indicate - changes in this structure in the future. - - steal: - the amount of time in which this vCPU did not run, in - nanoseconds. Time during which the vcpu is idle, will not be - reported as steal time. - - preempted: - indicate the vCPU who owns this struct is running or - not. Non-zero values mean the vCPU has been preempted. Zero - means the vCPU is not preempted. NOTE, it is always zero if the - the hypervisor doesn't support this field. - -MSR_KVM_EOI_EN: - 0x4b564d04 - -data: - Bit 0 is 1 when PV end of interrupt is enabled on the vcpu; 0 - when disabled. Bit 1 is reserved and must be zero. When PV end of - interrupt is enabled (bit 0 set), bits 63-2 hold a 4-byte aligned - physical address of a 4 byte memory area which must be in guest RAM and - must be zeroed. - - The first, least significant bit of 4 byte memory location will be - written to by the hypervisor, typically at the time of interrupt - injection. Value of 1 means that guest can skip writing EOI to the apic - (using MSR or MMIO write); instead, it is sufficient to signal - EOI by clearing the bit in guest memory - this location will - later be polled by the hypervisor. - Value of 0 means that the EOI write is required. - - It is always safe for the guest to ignore the optimization and perform - the APIC EOI write anyway. - - Hypervisor is guaranteed to only modify this least - significant bit while in the current VCPU context, this means that - guest does not need to use either lock prefix or memory ordering - primitives to synchronise with the hypervisor. - - However, hypervisor can set and clear this memory bit at any time: - therefore to make sure hypervisor does not interrupt the - guest and clear the least significant bit in the memory area - in the window between guest testing it to detect - whether it can skip EOI apic write and between guest - clearing it to signal EOI to the hypervisor, - guest must both read the least significant bit in the memory area and - clear it using a single CPU instruction, such as test and clear, or - compare and exchange. - -MSR_KVM_POLL_CONTROL: - 0x4b564d05 - - Control host-side polling. - -data: - Bit 0 enables (1) or disables (0) host-side HLT polling logic. - - KVM guests can request the host not to poll on HLT, for example if - they are performing polling themselves. - -MSR_KVM_ASYNC_PF_INT: - 0x4b564d06 - -data: - Second asynchronous page fault (APF) control MSR. - - Bits 0-7: APIC vector for delivery of 'page ready' APF events. - Bits 8-63: Reserved - - Interrupt vector for asynchnonous 'page ready' notifications delivery. - The vector has to be set up before asynchronous page fault mechanism - is enabled in MSR_KVM_ASYNC_PF_EN. The MSR is only available if - KVM_FEATURE_ASYNC_PF_INT is present in CPUID. - -MSR_KVM_ASYNC_PF_ACK: - 0x4b564d07 - -data: - Asynchronous page fault (APF) acknowledgment. - - When the guest is done processing 'page ready' APF event and 'token' - field in 'struct kvm_vcpu_pv_apf_data' is cleared it is supposed to - write '1' to bit 0 of the MSR, this causes the host to re-scan its queue - and check if there are more notifications pending. The MSR is available - if KVM_FEATURE_ASYNC_PF_INT is present in CPUID. - -MSR_KVM_MIGRATION_CONTROL: - 0x4b564d08 - -data: - This MSR is available if KVM_FEATURE_MIGRATION_CONTROL is present in - CPUID. Bit 0 represents whether live migration of the guest is allowed. - - When a guest is started, bit 0 will be 0 if the guest has encrypted - memory and 1 if the guest does not have encrypted memory. If the - guest is communicating page encryption status to the host using the - ``KVM_HC_MAP_GPA_RANGE`` hypercall, it can set bit 0 in this MSR to - allow live migration of the guest. diff --git a/Documentation/virt/kvm/nested-vmx.rst b/Documentation/virt/kvm/nested-vmx.rst deleted file mode 100644 index ac2095d41f02..000000000000 --- a/Documentation/virt/kvm/nested-vmx.rst +++ /dev/null @@ -1,244 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -========== -Nested VMX -========== - -Overview ---------- - -On Intel processors, KVM uses Intel's VMX (Virtual-Machine eXtensions) -to easily and efficiently run guest operating systems. Normally, these guests -*cannot* themselves be hypervisors running their own guests, because in VMX, -guests cannot use VMX instructions. - -The "Nested VMX" feature adds this missing capability - of running guest -hypervisors (which use VMX) with their own nested guests. It does so by -allowing a guest to use VMX instructions, and correctly and efficiently -emulating them using the single level of VMX available in the hardware. - -We describe in much greater detail the theory behind the nested VMX feature, -its implementation and its performance characteristics, in the OSDI 2010 paper -"The Turtles Project: Design and Implementation of Nested Virtualization", -available at: - - https://www.usenix.org/events/osdi10/tech/full_papers/Ben-Yehuda.pdf - - -Terminology ------------ - -Single-level virtualization has two levels - the host (KVM) and the guests. -In nested virtualization, we have three levels: The host (KVM), which we call -L0, the guest hypervisor, which we call L1, and its nested guest, which we -call L2. - - -Running nested VMX ------------------- - -The nested VMX feature is enabled by default since Linux kernel v4.20. For -older Linux kernel, it can be enabled by giving the "nested=1" option to the -kvm-intel module. - - -No modifications are required to user space (qemu). However, qemu's default -emulated CPU type (qemu64) does not list the "VMX" CPU feature, so it must be -explicitly enabled, by giving qemu one of the following options: - - - cpu host (emulated CPU has all features of the real CPU) - - - cpu qemu64,+vmx (add just the vmx feature to a named CPU type) - - -ABIs ----- - -Nested VMX aims to present a standard and (eventually) fully-functional VMX -implementation for the a guest hypervisor to use. As such, the official -specification of the ABI that it provides is Intel's VMX specification, -namely volume 3B of their "Intel 64 and IA-32 Architectures Software -Developer's Manual". Not all of VMX's features are currently fully supported, -but the goal is to eventually support them all, starting with the VMX features -which are used in practice by popular hypervisors (KVM and others). - -As a VMX implementation, nested VMX presents a VMCS structure to L1. -As mandated by the spec, other than the two fields revision_id and abort, -this structure is *opaque* to its user, who is not supposed to know or care -about its internal structure. Rather, the structure is accessed through the -VMREAD and VMWRITE instructions. -Still, for debugging purposes, KVM developers might be interested to know the -internals of this structure; This is struct vmcs12 from arch/x86/kvm/vmx.c. - -The name "vmcs12" refers to the VMCS that L1 builds for L2. In the code we -also have "vmcs01", the VMCS that L0 built for L1, and "vmcs02" is the VMCS -which L0 builds to actually run L2 - how this is done is explained in the -aforementioned paper. - -For convenience, we repeat the content of struct vmcs12 here. If the internals -of this structure changes, this can break live migration across KVM versions. -VMCS12_REVISION (from vmx.c) should be changed if struct vmcs12 or its inner -struct shadow_vmcs is ever changed. - -:: - - typedef u64 natural_width; - struct __packed vmcs12 { - /* According to the Intel spec, a VMCS region must start with - * these two user-visible fields */ - u32 revision_id; - u32 abort; - - u32 launch_state; /* set to 0 by VMCLEAR, to 1 by VMLAUNCH */ - u32 padding[7]; /* room for future expansion */ - - u64 io_bitmap_a; - u64 io_bitmap_b; - u64 msr_bitmap; - u64 vm_exit_msr_store_addr; - u64 vm_exit_msr_load_addr; - u64 vm_entry_msr_load_addr; - u64 tsc_offset; - u64 virtual_apic_page_addr; - u64 apic_access_addr; - u64 ept_pointer; - u64 guest_physical_address; - u64 vmcs_link_pointer; - u64 guest_ia32_debugctl; - u64 guest_ia32_pat; - u64 guest_ia32_efer; - u64 guest_pdptr0; - u64 guest_pdptr1; - u64 guest_pdptr2; - u64 guest_pdptr3; - u64 host_ia32_pat; - u64 host_ia32_efer; - u64 padding64[8]; /* room for future expansion */ - natural_width cr0_guest_host_mask; - natural_width cr4_guest_host_mask; - natural_width cr0_read_shadow; - natural_width cr4_read_shadow; - natural_width dead_space[4]; /* Last remnants of cr3_target_value[0-3]. */ - natural_width exit_qualification; - natural_width guest_linear_address; - natural_width guest_cr0; - natural_width guest_cr3; - natural_width guest_cr4; - natural_width guest_es_base; - natural_width guest_cs_base; - natural_width guest_ss_base; - natural_width guest_ds_base; - natural_width guest_fs_base; - natural_width guest_gs_base; - natural_width guest_ldtr_base; - natural_width guest_tr_base; - natural_width guest_gdtr_base; - natural_width guest_idtr_base; - natural_width guest_dr7; - natural_width guest_rsp; - natural_width guest_rip; - natural_width guest_rflags; - natural_width guest_pending_dbg_exceptions; - natural_width guest_sysenter_esp; - natural_width guest_sysenter_eip; - natural_width host_cr0; - natural_width host_cr3; - natural_width host_cr4; - natural_width host_fs_base; - natural_width host_gs_base; - natural_width host_tr_base; - natural_width host_gdtr_base; - natural_width host_idtr_base; - natural_width host_ia32_sysenter_esp; - natural_width host_ia32_sysenter_eip; - natural_width host_rsp; - natural_width host_rip; - natural_width paddingl[8]; /* room for future expansion */ - u32 pin_based_vm_exec_control; - u32 cpu_based_vm_exec_control; - u32 exception_bitmap; - u32 page_fault_error_code_mask; - u32 page_fault_error_code_match; - u32 cr3_target_count; - u32 vm_exit_controls; - u32 vm_exit_msr_store_count; - u32 vm_exit_msr_load_count; - u32 vm_entry_controls; - u32 vm_entry_msr_load_count; - u32 vm_entry_intr_info_field; - u32 vm_entry_exception_error_code; - u32 vm_entry_instruction_len; - u32 tpr_threshold; - u32 secondary_vm_exec_control; - u32 vm_instruction_error; - u32 vm_exit_reason; - u32 vm_exit_intr_info; - u32 vm_exit_intr_error_code; - u32 idt_vectoring_info_field; - u32 idt_vectoring_error_code; - u32 vm_exit_instruction_len; - u32 vmx_instruction_info; - u32 guest_es_limit; - u32 guest_cs_limit; - u32 guest_ss_limit; - u32 guest_ds_limit; - u32 guest_fs_limit; - u32 guest_gs_limit; - u32 guest_ldtr_limit; - u32 guest_tr_limit; - u32 guest_gdtr_limit; - u32 guest_idtr_limit; - u32 guest_es_ar_bytes; - u32 guest_cs_ar_bytes; - u32 guest_ss_ar_bytes; - u32 guest_ds_ar_bytes; - u32 guest_fs_ar_bytes; - u32 guest_gs_ar_bytes; - u32 guest_ldtr_ar_bytes; - u32 guest_tr_ar_bytes; - u32 guest_interruptibility_info; - u32 guest_activity_state; - u32 guest_sysenter_cs; - u32 host_ia32_sysenter_cs; - u32 padding32[8]; /* room for future expansion */ - u16 virtual_processor_id; - u16 guest_es_selector; - u16 guest_cs_selector; - u16 guest_ss_selector; - u16 guest_ds_selector; - u16 guest_fs_selector; - u16 guest_gs_selector; - u16 guest_ldtr_selector; - u16 guest_tr_selector; - u16 host_es_selector; - u16 host_cs_selector; - u16 host_ss_selector; - u16 host_ds_selector; - u16 host_fs_selector; - u16 host_gs_selector; - u16 host_tr_selector; - }; - - -Authors -------- - -These patches were written by: - - Abel Gordon, abelg il.ibm.com - - Nadav Har'El, nyh il.ibm.com - - Orit Wasserman, oritw il.ibm.com - - Ben-Ami Yassor, benami il.ibm.com - - Muli Ben-Yehuda, muli il.ibm.com - -With contributions by: - - Anthony Liguori, aliguori us.ibm.com - - Mike Day, mdday us.ibm.com - - Michael Factor, factor il.ibm.com - - Zvi Dubitzky, dubi il.ibm.com - -And valuable reviews by: - - Avi Kivity, avi redhat.com - - Gleb Natapov, gleb redhat.com - - Marcelo Tosatti, mtosatti redhat.com - - Kevin Tian, kevin.tian intel.com - - and others. diff --git a/Documentation/virt/kvm/running-nested-guests.rst b/Documentation/virt/kvm/running-nested-guests.rst deleted file mode 100644 index bd70c69468ae..000000000000 --- a/Documentation/virt/kvm/running-nested-guests.rst +++ /dev/null @@ -1,276 +0,0 @@ -============================== -Running nested guests with KVM -============================== - -A nested guest is the ability to run a guest inside another guest (it -can be KVM-based or a different hypervisor). The straightforward -example is a KVM guest that in turn runs on a KVM guest (the rest of -this document is built on this example):: - - .----------------. .----------------. - | | | | - | L2 | | L2 | - | (Nested Guest) | | (Nested Guest) | - | | | | - |----------------'--'----------------| - | | - | L1 (Guest Hypervisor) | - | KVM (/dev/kvm) | - | | - .------------------------------------------------------. - | L0 (Host Hypervisor) | - | KVM (/dev/kvm) | - |------------------------------------------------------| - | Hardware (with virtualization extensions) | - '------------------------------------------------------' - -Terminology: - -- L0 – level-0; the bare metal host, running KVM - -- L1 – level-1 guest; a VM running on L0; also called the "guest - hypervisor", as it itself is capable of running KVM. - -- L2 – level-2 guest; a VM running on L1, this is the "nested guest" - -.. note:: The above diagram is modelled after the x86 architecture; - s390x, ppc64 and other architectures are likely to have - a different design for nesting. - - For example, s390x always has an LPAR (LogicalPARtition) - hypervisor running on bare metal, adding another layer and - resulting in at least four levels in a nested setup — L0 (bare - metal, running the LPAR hypervisor), L1 (host hypervisor), L2 - (guest hypervisor), L3 (nested guest). - - This document will stick with the three-level terminology (L0, - L1, and L2) for all architectures; and will largely focus on - x86. - - -Use Cases ---------- - -There are several scenarios where nested KVM can be useful, to name a -few: - -- As a developer, you want to test your software on different operating - systems (OSes). Instead of renting multiple VMs from a Cloud - Provider, using nested KVM lets you rent a large enough "guest - hypervisor" (level-1 guest). This in turn allows you to create - multiple nested guests (level-2 guests), running different OSes, on - which you can develop and test your software. - -- Live migration of "guest hypervisors" and their nested guests, for - load balancing, disaster recovery, etc. - -- VM image creation tools (e.g. ``virt-install``, etc) often run - their own VM, and users expect these to work inside a VM. - -- Some OSes use virtualization internally for security (e.g. to let - applications run safely in isolation). - - -Enabling "nested" (x86) ------------------------ - -From Linux kernel v4.20 onwards, the ``nested`` KVM parameter is enabled -by default for Intel and AMD. (Though your Linux distribution might -override this default.) - -In case you are running a Linux kernel older than v4.19, to enable -nesting, set the ``nested`` KVM module parameter to ``Y`` or ``1``. To -persist this setting across reboots, you can add it in a config file, as -shown below: - -1. On the bare metal host (L0), list the kernel modules and ensure that - the KVM modules:: - - $ lsmod | grep -i kvm - kvm_intel 133627 0 - kvm 435079 1 kvm_intel - -2. Show information for ``kvm_intel`` module:: - - $ modinfo kvm_intel | grep -i nested - parm: nested:bool - -3. For the nested KVM configuration to persist across reboots, place the - below in ``/etc/modprobed/kvm_intel.conf`` (create the file if it - doesn't exist):: - - $ cat /etc/modprobe.d/kvm_intel.conf - options kvm-intel nested=y - -4. Unload and re-load the KVM Intel module:: - - $ sudo rmmod kvm-intel - $ sudo modprobe kvm-intel - -5. Verify if the ``nested`` parameter for KVM is enabled:: - - $ cat /sys/module/kvm_intel/parameters/nested - Y - -For AMD hosts, the process is the same as above, except that the module -name is ``kvm-amd``. - - -Additional nested-related kernel parameters (x86) -------------------------------------------------- - -If your hardware is sufficiently advanced (Intel Haswell processor or -higher, which has newer hardware virt extensions), the following -additional features will also be enabled by default: "Shadow VMCS -(Virtual Machine Control Structure)", APIC Virtualization on your bare -metal host (L0). Parameters for Intel hosts:: - - $ cat /sys/module/kvm_intel/parameters/enable_shadow_vmcs - Y - - $ cat /sys/module/kvm_intel/parameters/enable_apicv - Y - - $ cat /sys/module/kvm_intel/parameters/ept - Y - -.. note:: If you suspect your L2 (i.e. nested guest) is running slower, - ensure the above are enabled (particularly - ``enable_shadow_vmcs`` and ``ept``). - - -Starting a nested guest (x86) ------------------------------ - -Once your bare metal host (L0) is configured for nesting, you should be -able to start an L1 guest with:: - - $ qemu-kvm -cpu host [...] - -The above will pass through the host CPU's capabilities as-is to the -gues); or for better live migration compatibility, use a named CPU -model supported by QEMU. e.g.:: - - $ qemu-kvm -cpu Haswell-noTSX-IBRS,vmx=on - -then the guest hypervisor will subsequently be capable of running a -nested guest with accelerated KVM. - - -Enabling "nested" (s390x) -------------------------- - -1. On the host hypervisor (L0), enable the ``nested`` parameter on - s390x:: - - $ rmmod kvm - $ modprobe kvm nested=1 - -.. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive - with the ``nested`` paramter — i.e. to be able to enable - ``nested``, the ``hpage`` parameter *must* be disabled. - -2. The guest hypervisor (L1) must be provided with the ``sie`` CPU - feature — with QEMU, this can be done by using "host passthrough" - (via the command-line ``-cpu host``). - -3. Now the KVM module can be loaded in the L1 (guest hypervisor):: - - $ modprobe kvm - - -Live migration with nested KVM ------------------------------- - -Migrating an L1 guest, with a *live* nested guest in it, to another -bare metal host, works as of Linux kernel 5.3 and QEMU 4.2.0 for -Intel x86 systems, and even on older versions for s390x. - -On AMD systems, once an L1 guest has started an L2 guest, the L1 guest -should no longer be migrated or saved (refer to QEMU documentation on -"savevm"/"loadvm") until the L2 guest shuts down. Attempting to migrate -or save-and-load an L1 guest while an L2 guest is running will result in -undefined behavior. You might see a ``kernel BUG!`` entry in ``dmesg``, a -kernel 'oops', or an outright kernel panic. Such a migrated or loaded L1 -guest can no longer be considered stable or secure, and must be restarted. -Migrating an L1 guest merely configured to support nesting, while not -actually running L2 guests, is expected to function normally even on AMD -systems but may fail once guests are started. - -Migrating an L2 guest is always expected to succeed, so all the following -scenarios should work even on AMD systems: - -- Migrating a nested guest (L2) to another L1 guest on the *same* bare - metal host. - -- Migrating a nested guest (L2) to another L1 guest on a *different* - bare metal host. - -- Migrating a nested guest (L2) to a bare metal host. - -Reporting bugs from nested setups ------------------------------------ - -Debugging "nested" problems can involve sifting through log files across -L0, L1 and L2; this can result in tedious back-n-forth between the bug -reporter and the bug fixer. - -- Mention that you are in a "nested" setup. If you are running any kind - of "nesting" at all, say so. Unfortunately, this needs to be called - out because when reporting bugs, people tend to forget to even - *mention* that they're using nested virtualization. - -- Ensure you are actually running KVM on KVM. Sometimes people do not - have KVM enabled for their guest hypervisor (L1), which results in - them running with pure emulation or what QEMU calls it as "TCG", but - they think they're running nested KVM. Thus confusing "nested Virt" - (which could also mean, QEMU on KVM) with "nested KVM" (KVM on KVM). - -Information to collect (generic) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The following is not an exhaustive list, but a very good starting point: - - - Kernel, libvirt, and QEMU version from L0 - - - Kernel, libvirt and QEMU version from L1 - - - QEMU command-line of L1 -- when using libvirt, you'll find it here: - ``/var/log/libvirt/qemu/instance.log`` - - - QEMU command-line of L2 -- as above, when using libvirt, get the - complete libvirt-generated QEMU command-line - - - ``cat /sys/cpuinfo`` from L0 - - - ``cat /sys/cpuinfo`` from L1 - - - ``lscpu`` from L0 - - - ``lscpu`` from L1 - - - Full ``dmesg`` output from L0 - - - Full ``dmesg`` output from L1 - -x86-specific info to collect -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Both the below commands, ``x86info`` and ``dmidecode``, should be -available on most Linux distributions with the same name: - - - Output of: ``x86info -a`` from L0 - - - Output of: ``x86info -a`` from L1 - - - Output of: ``dmidecode`` from L0 - - - Output of: ``dmidecode`` from L1 - -s390x-specific info to collect -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Along with the earlier mentioned generic details, the below is -also recommended: - - - ``/proc/sysinfo`` from L1; this will also include the info from L0 diff --git a/Documentation/virt/kvm/s390-diag.rst b/Documentation/virt/kvm/s390-diag.rst deleted file mode 100644 index ca85f030eb0b..000000000000 --- a/Documentation/virt/kvm/s390-diag.rst +++ /dev/null @@ -1,119 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -============================= -The s390 DIAGNOSE call on KVM -============================= - -KVM on s390 supports the DIAGNOSE call for making hypercalls, both for -native hypercalls and for selected hypercalls found on other s390 -hypervisors. - -Note that bits are numbered as by the usual s390 convention (most significant -bit on the left). - - -General remarks ---------------- - -DIAGNOSE calls by the guest cause a mandatory intercept. This implies -all supported DIAGNOSE calls need to be handled by either KVM or its -userspace. - -All DIAGNOSE calls supported by KVM use the RS-a format:: - - -------------------------------------- - | '83' | R1 | R3 | B2 | D2 | - -------------------------------------- - 0 8 12 16 20 31 - -The second-operand address (obtained by the base/displacement calculation) -is not used to address data. Instead, bits 48-63 of this address specify -the function code, and bits 0-47 are ignored. - -The supported DIAGNOSE function codes vary by the userspace used. For -DIAGNOSE function codes not specific to KVM, please refer to the -documentation for the s390 hypervisors defining them. - - -DIAGNOSE function code 'X'500' - KVM virtio functions ------------------------------------------------------ - -If the function code specifies 0x500, various virtio-related functions -are performed. - -General register 1 contains the virtio subfunction code. Supported -virtio subfunctions depend on KVM's userspace. Generally, userspace -provides either s390-virtio (subcodes 0-2) or virtio-ccw (subcode 3). - -Upon completion of the DIAGNOSE instruction, general register 2 contains -the function's return code, which is either a return code or a subcode -specific value. - -Subcode 0 - s390-virtio notification and early console printk - Handled by userspace. - -Subcode 1 - s390-virtio reset - Handled by userspace. - -Subcode 2 - s390-virtio set status - Handled by userspace. - -Subcode 3 - virtio-ccw notification - Handled by either userspace or KVM (ioeventfd case). - - General register 2 contains a subchannel-identification word denoting - the subchannel of the virtio-ccw proxy device to be notified. - - General register 3 contains the number of the virtqueue to be notified. - - General register 4 contains a 64bit identifier for KVM usage (the - kvm_io_bus cookie). If general register 4 does not contain a valid - identifier, it is ignored. - - After completion of the DIAGNOSE call, general register 2 may contain - a 64bit identifier (in the kvm_io_bus cookie case), or a negative - error value, if an internal error occurred. - - See also the virtio standard for a discussion of this hypercall. - - -DIAGNOSE function code 'X'501 - KVM breakpoint ----------------------------------------------- - -If the function code specifies 0x501, breakpoint functions may be performed. -This function code is handled by userspace. - -This diagnose function code has no subfunctions and uses no parameters. - - -DIAGNOSE function code 'X'9C - Voluntary Time Slice Yield ---------------------------------------------------------- - -General register 1 contains the target CPU address. - -In a guest of a hypervisor like LPAR, KVM or z/VM using shared host CPUs, -DIAGNOSE with function code 0x9c may improve system performance by -yielding the host CPU on which the guest CPU is running to be assigned -to another guest CPU, preferably the logical CPU containing the specified -target CPU. - - -DIAG 'X'9C forwarding -+++++++++++++++++++++ - -The guest may send a DIAGNOSE 0x9c in order to yield to a certain -other vcpu. An example is a Linux guest that tries to yield to the vcpu -that is currently holding a spinlock, but not running. - -However, on the host the real cpu backing the vcpu may itself not be -running. -Forwarding the DIAGNOSE 0x9c initially sent by the guest to yield to -the backing cpu will hopefully cause that cpu, and thus subsequently -the guest's vcpu, to be scheduled. - - -diag9c_forwarding_hz - KVM kernel parameter allowing to specify the maximum number of DIAGNOSE - 0x9c forwarding per second in the purpose of avoiding a DIAGNOSE 0x9c - forwarding storm. - A value of 0 turns the forwarding off. diff --git a/Documentation/virt/kvm/s390-pv-boot.rst b/Documentation/virt/kvm/s390-pv-boot.rst deleted file mode 100644 index 73a6083cb5e7..000000000000 --- a/Documentation/virt/kvm/s390-pv-boot.rst +++ /dev/null @@ -1,84 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -====================================== -s390 (IBM Z) Boot/IPL of Protected VMs -====================================== - -Summary -------- -The memory of Protected Virtual Machines (PVMs) is not accessible to -I/O or the hypervisor. In those cases where the hypervisor needs to -access the memory of a PVM, that memory must be made accessible. -Memory made accessible to the hypervisor will be encrypted. See -Documentation/virt/kvm/s390-pv.rst for details." - -On IPL (boot) a small plaintext bootloader is started, which provides -information about the encrypted components and necessary metadata to -KVM to decrypt the protected virtual machine. - -Based on this data, KVM will make the protected virtual machine known -to the Ultravisor (UV) and instruct it to secure the memory of the -PVM, decrypt the components and verify the data and address list -hashes, to ensure integrity. Afterwards KVM can run the PVM via the -SIE instruction which the UV will intercept and execute on KVM's -behalf. - -As the guest image is just like an opaque kernel image that does the -switch into PV mode itself, the user can load encrypted guest -executables and data via every available method (network, dasd, scsi, -direct kernel, ...) without the need to change the boot process. - - -Diag308 -------- -This diagnose instruction is the basic mechanism to handle IPL and -related operations for virtual machines. The VM can set and retrieve -IPL information blocks, that specify the IPL method/devices and -request VM memory and subsystem resets, as well as IPLs. - -For PVMs this concept has been extended with new subcodes: - -Subcode 8: Set an IPL Information Block of type 5 (information block -for PVMs) -Subcode 9: Store the saved block in guest memory -Subcode 10: Move into Protected Virtualization mode - -The new PV load-device-specific-parameters field specifies all data -that is necessary to move into PV mode. - -* PV Header origin -* PV Header length -* List of Components composed of - * AES-XTS Tweak prefix - * Origin - * Size - -The PV header contains the keys and hashes, which the UV will use to -decrypt and verify the PV, as well as control flags and a start PSW. - -The components are for instance an encrypted kernel, kernel parameters -and initrd. The components are decrypted by the UV. - -After the initial import of the encrypted data, all defined pages will -contain the guest content. All non-specified pages will start out as -zero pages on first access. - - -When running in protected virtualization mode, some subcodes will result in -exceptions or return error codes. - -Subcodes 4 and 7, which specify operations that do not clear the guest -memory, will result in specification exceptions. This is because the -UV will clear all memory when a secure VM is removed, and therefore -non-clearing IPL subcodes are not allowed. - -Subcodes 8, 9, 10 will result in specification exceptions. -Re-IPL into a protected mode is only possible via a detour into non -protected mode. - -Keys ----- -Every CEC will have a unique public key to enable tooling to build -encrypted images. -See `s390-tools `_ -for the tooling. diff --git a/Documentation/virt/kvm/s390-pv.rst b/Documentation/virt/kvm/s390-pv.rst deleted file mode 100644 index 8e41a3b63fa5..000000000000 --- a/Documentation/virt/kvm/s390-pv.rst +++ /dev/null @@ -1,116 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -========================================= -s390 (IBM Z) Ultravisor and Protected VMs -========================================= - -Summary -------- -Protected virtual machines (PVM) are KVM VMs that do not allow KVM to -access VM state like guest memory or guest registers. Instead, the -PVMs are mostly managed by a new entity called Ultravisor (UV). The UV -provides an API that can be used by PVMs and KVM to request management -actions. - -Each guest starts in non-protected mode and then may make a request to -transition into protected mode. On transition, KVM registers the guest -and its VCPUs with the Ultravisor and prepares everything for running -it. - -The Ultravisor will secure and decrypt the guest's boot memory -(i.e. kernel/initrd). It will safeguard state changes like VCPU -starts/stops and injected interrupts while the guest is running. - -As access to the guest's state, such as the SIE state description, is -normally needed to be able to run a VM, some changes have been made in -the behavior of the SIE instruction. A new format 4 state description -has been introduced, where some fields have different meanings for a -PVM. SIE exits are minimized as much as possible to improve speed and -reduce exposed guest state. - - -Interrupt injection -------------------- -Interrupt injection is safeguarded by the Ultravisor. As KVM doesn't -have access to the VCPUs' lowcores, injection is handled via the -format 4 state description. - -Machine check, external, IO and restart interruptions each can be -injected on SIE entry via a bit in the interrupt injection control -field (offset 0x54). If the guest cpu is not enabled for the interrupt -at the time of injection, a validity interception is recognized. The -format 4 state description contains fields in the interception data -block where data associated with the interrupt can be transported. - -Program and Service Call exceptions have another layer of -safeguarding; they can only be injected for instructions that have -been intercepted into KVM. The exceptions need to be a valid outcome -of an instruction emulation by KVM, e.g. we can never inject a -addressing exception as they are reported by SIE since KVM has no -access to the guest memory. - - -Mask notification interceptions -------------------------------- -KVM cannot intercept lctl(g) and lpsw(e) anymore in order to be -notified when a PVM enables a certain class of interrupt. As a -replacement, two new interception codes have been introduced: One -indicating that the contents of CRs 0, 6, or 14 have been changed, -indicating different interruption subclasses; and one indicating that -PSW bit 13 has been changed, indicating that a machine check -intervention was requested and those are now enabled. - -Instruction emulation ---------------------- -With the format 4 state description for PVMs, the SIE instruction already -interprets more instructions than it does with format 2. It is not able -to interpret every instruction, but needs to hand some tasks to KVM; -therefore, the SIE and the ultravisor safeguard emulation inputs and outputs. - -The control structures associated with SIE provide the Secure -Instruction Data Area (SIDA), the Interception Parameters (IP) and the -Secure Interception General Register Save Area. Guest GRs and most of -the instruction data, such as I/O data structures, are filtered. -Instruction data is copied to and from the SIDA when needed. Guest -GRs are put into / retrieved from the Secure Interception General -Register Save Area. - -Only GR values needed to emulate an instruction will be copied into this -save area and the real register numbers will be hidden. - -The Interception Parameters state description field still contains -the bytes of the instruction text, but with pre-set register values -instead of the actual ones. I.e. each instruction always uses the same -instruction text, in order not to leak guest instruction text. -This also implies that the register content that a guest had in r -may be in r from the hypervisor's point of view. - -The Secure Instruction Data Area contains instruction storage -data. Instruction data, i.e. data being referenced by an instruction -like the SCCB for sclp, is moved via the SIDA. When an instruction is -intercepted, the SIE will only allow data and program interrupts for -this instruction to be moved to the guest via the two data areas -discussed before. Other data is either ignored or results in validity -interceptions. - - -Instruction emulation interceptions ------------------------------------ -There are two types of SIE secure instruction intercepts: the normal -and the notification type. Normal secure instruction intercepts will -make the guest pending for instruction completion of the intercepted -instruction type, i.e. on SIE entry it is attempted to complete -emulation of the instruction with the data provided by KVM. That might -be a program exception or instruction completion. - -The notification type intercepts inform KVM about guest environment -changes due to guest instruction interpretation. Such an interception -is recognized, for example, for the store prefix instruction to provide -the new lowcore location. On SIE reentry, any KVM data in the data areas -is ignored and execution continues as if the guest instruction had -completed. For that reason KVM is not allowed to inject a program -interrupt. - -Links ------ -`KVM Forum 2019 presentation `_ diff --git a/Documentation/virt/kvm/s390/index.rst b/Documentation/virt/kvm/s390/index.rst new file mode 100644 index 000000000000..605f488f0cc5 --- /dev/null +++ b/Documentation/virt/kvm/s390/index.rst @@ -0,0 +1,12 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================== +KVM for s390 systems +==================== + +.. toctree:: + :maxdepth: 2 + + s390-diag + s390-pv + s390-pv-boot diff --git a/Documentation/virt/kvm/s390/s390-diag.rst b/Documentation/virt/kvm/s390/s390-diag.rst new file mode 100644 index 000000000000..ca85f030eb0b --- /dev/null +++ b/Documentation/virt/kvm/s390/s390-diag.rst @@ -0,0 +1,119 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================= +The s390 DIAGNOSE call on KVM +============================= + +KVM on s390 supports the DIAGNOSE call for making hypercalls, both for +native hypercalls and for selected hypercalls found on other s390 +hypervisors. + +Note that bits are numbered as by the usual s390 convention (most significant +bit on the left). + + +General remarks +--------------- + +DIAGNOSE calls by the guest cause a mandatory intercept. This implies +all supported DIAGNOSE calls need to be handled by either KVM or its +userspace. + +All DIAGNOSE calls supported by KVM use the RS-a format:: + + -------------------------------------- + | '83' | R1 | R3 | B2 | D2 | + -------------------------------------- + 0 8 12 16 20 31 + +The second-operand address (obtained by the base/displacement calculation) +is not used to address data. Instead, bits 48-63 of this address specify +the function code, and bits 0-47 are ignored. + +The supported DIAGNOSE function codes vary by the userspace used. For +DIAGNOSE function codes not specific to KVM, please refer to the +documentation for the s390 hypervisors defining them. + + +DIAGNOSE function code 'X'500' - KVM virtio functions +----------------------------------------------------- + +If the function code specifies 0x500, various virtio-related functions +are performed. + +General register 1 contains the virtio subfunction code. Supported +virtio subfunctions depend on KVM's userspace. Generally, userspace +provides either s390-virtio (subcodes 0-2) or virtio-ccw (subcode 3). + +Upon completion of the DIAGNOSE instruction, general register 2 contains +the function's return code, which is either a return code or a subcode +specific value. + +Subcode 0 - s390-virtio notification and early console printk + Handled by userspace. + +Subcode 1 - s390-virtio reset + Handled by userspace. + +Subcode 2 - s390-virtio set status + Handled by userspace. + +Subcode 3 - virtio-ccw notification + Handled by either userspace or KVM (ioeventfd case). + + General register 2 contains a subchannel-identification word denoting + the subchannel of the virtio-ccw proxy device to be notified. + + General register 3 contains the number of the virtqueue to be notified. + + General register 4 contains a 64bit identifier for KVM usage (the + kvm_io_bus cookie). If general register 4 does not contain a valid + identifier, it is ignored. + + After completion of the DIAGNOSE call, general register 2 may contain + a 64bit identifier (in the kvm_io_bus cookie case), or a negative + error value, if an internal error occurred. + + See also the virtio standard for a discussion of this hypercall. + + +DIAGNOSE function code 'X'501 - KVM breakpoint +---------------------------------------------- + +If the function code specifies 0x501, breakpoint functions may be performed. +This function code is handled by userspace. + +This diagnose function code has no subfunctions and uses no parameters. + + +DIAGNOSE function code 'X'9C - Voluntary Time Slice Yield +--------------------------------------------------------- + +General register 1 contains the target CPU address. + +In a guest of a hypervisor like LPAR, KVM or z/VM using shared host CPUs, +DIAGNOSE with function code 0x9c may improve system performance by +yielding the host CPU on which the guest CPU is running to be assigned +to another guest CPU, preferably the logical CPU containing the specified +target CPU. + + +DIAG 'X'9C forwarding ++++++++++++++++++++++ + +The guest may send a DIAGNOSE 0x9c in order to yield to a certain +other vcpu. An example is a Linux guest that tries to yield to the vcpu +that is currently holding a spinlock, but not running. + +However, on the host the real cpu backing the vcpu may itself not be +running. +Forwarding the DIAGNOSE 0x9c initially sent by the guest to yield to +the backing cpu will hopefully cause that cpu, and thus subsequently +the guest's vcpu, to be scheduled. + + +diag9c_forwarding_hz + KVM kernel parameter allowing to specify the maximum number of DIAGNOSE + 0x9c forwarding per second in the purpose of avoiding a DIAGNOSE 0x9c + forwarding storm. + A value of 0 turns the forwarding off. diff --git a/Documentation/virt/kvm/s390/s390-pv-boot.rst b/Documentation/virt/kvm/s390/s390-pv-boot.rst new file mode 100644 index 000000000000..73a6083cb5e7 --- /dev/null +++ b/Documentation/virt/kvm/s390/s390-pv-boot.rst @@ -0,0 +1,84 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================== +s390 (IBM Z) Boot/IPL of Protected VMs +====================================== + +Summary +------- +The memory of Protected Virtual Machines (PVMs) is not accessible to +I/O or the hypervisor. In those cases where the hypervisor needs to +access the memory of a PVM, that memory must be made accessible. +Memory made accessible to the hypervisor will be encrypted. See +Documentation/virt/kvm/s390-pv.rst for details." + +On IPL (boot) a small plaintext bootloader is started, which provides +information about the encrypted components and necessary metadata to +KVM to decrypt the protected virtual machine. + +Based on this data, KVM will make the protected virtual machine known +to the Ultravisor (UV) and instruct it to secure the memory of the +PVM, decrypt the components and verify the data and address list +hashes, to ensure integrity. Afterwards KVM can run the PVM via the +SIE instruction which the UV will intercept and execute on KVM's +behalf. + +As the guest image is just like an opaque kernel image that does the +switch into PV mode itself, the user can load encrypted guest +executables and data via every available method (network, dasd, scsi, +direct kernel, ...) without the need to change the boot process. + + +Diag308 +------- +This diagnose instruction is the basic mechanism to handle IPL and +related operations for virtual machines. The VM can set and retrieve +IPL information blocks, that specify the IPL method/devices and +request VM memory and subsystem resets, as well as IPLs. + +For PVMs this concept has been extended with new subcodes: + +Subcode 8: Set an IPL Information Block of type 5 (information block +for PVMs) +Subcode 9: Store the saved block in guest memory +Subcode 10: Move into Protected Virtualization mode + +The new PV load-device-specific-parameters field specifies all data +that is necessary to move into PV mode. + +* PV Header origin +* PV Header length +* List of Components composed of + * AES-XTS Tweak prefix + * Origin + * Size + +The PV header contains the keys and hashes, which the UV will use to +decrypt and verify the PV, as well as control flags and a start PSW. + +The components are for instance an encrypted kernel, kernel parameters +and initrd. The components are decrypted by the UV. + +After the initial import of the encrypted data, all defined pages will +contain the guest content. All non-specified pages will start out as +zero pages on first access. + + +When running in protected virtualization mode, some subcodes will result in +exceptions or return error codes. + +Subcodes 4 and 7, which specify operations that do not clear the guest +memory, will result in specification exceptions. This is because the +UV will clear all memory when a secure VM is removed, and therefore +non-clearing IPL subcodes are not allowed. + +Subcodes 8, 9, 10 will result in specification exceptions. +Re-IPL into a protected mode is only possible via a detour into non +protected mode. + +Keys +---- +Every CEC will have a unique public key to enable tooling to build +encrypted images. +See `s390-tools `_ +for the tooling. diff --git a/Documentation/virt/kvm/s390/s390-pv.rst b/Documentation/virt/kvm/s390/s390-pv.rst new file mode 100644 index 000000000000..8e41a3b63fa5 --- /dev/null +++ b/Documentation/virt/kvm/s390/s390-pv.rst @@ -0,0 +1,116 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================================= +s390 (IBM Z) Ultravisor and Protected VMs +========================================= + +Summary +------- +Protected virtual machines (PVM) are KVM VMs that do not allow KVM to +access VM state like guest memory or guest registers. Instead, the +PVMs are mostly managed by a new entity called Ultravisor (UV). The UV +provides an API that can be used by PVMs and KVM to request management +actions. + +Each guest starts in non-protected mode and then may make a request to +transition into protected mode. On transition, KVM registers the guest +and its VCPUs with the Ultravisor and prepares everything for running +it. + +The Ultravisor will secure and decrypt the guest's boot memory +(i.e. kernel/initrd). It will safeguard state changes like VCPU +starts/stops and injected interrupts while the guest is running. + +As access to the guest's state, such as the SIE state description, is +normally needed to be able to run a VM, some changes have been made in +the behavior of the SIE instruction. A new format 4 state description +has been introduced, where some fields have different meanings for a +PVM. SIE exits are minimized as much as possible to improve speed and +reduce exposed guest state. + + +Interrupt injection +------------------- +Interrupt injection is safeguarded by the Ultravisor. As KVM doesn't +have access to the VCPUs' lowcores, injection is handled via the +format 4 state description. + +Machine check, external, IO and restart interruptions each can be +injected on SIE entry via a bit in the interrupt injection control +field (offset 0x54). If the guest cpu is not enabled for the interrupt +at the time of injection, a validity interception is recognized. The +format 4 state description contains fields in the interception data +block where data associated with the interrupt can be transported. + +Program and Service Call exceptions have another layer of +safeguarding; they can only be injected for instructions that have +been intercepted into KVM. The exceptions need to be a valid outcome +of an instruction emulation by KVM, e.g. we can never inject a +addressing exception as they are reported by SIE since KVM has no +access to the guest memory. + + +Mask notification interceptions +------------------------------- +KVM cannot intercept lctl(g) and lpsw(e) anymore in order to be +notified when a PVM enables a certain class of interrupt. As a +replacement, two new interception codes have been introduced: One +indicating that the contents of CRs 0, 6, or 14 have been changed, +indicating different interruption subclasses; and one indicating that +PSW bit 13 has been changed, indicating that a machine check +intervention was requested and those are now enabled. + +Instruction emulation +--------------------- +With the format 4 state description for PVMs, the SIE instruction already +interprets more instructions than it does with format 2. It is not able +to interpret every instruction, but needs to hand some tasks to KVM; +therefore, the SIE and the ultravisor safeguard emulation inputs and outputs. + +The control structures associated with SIE provide the Secure +Instruction Data Area (SIDA), the Interception Parameters (IP) and the +Secure Interception General Register Save Area. Guest GRs and most of +the instruction data, such as I/O data structures, are filtered. +Instruction data is copied to and from the SIDA when needed. Guest +GRs are put into / retrieved from the Secure Interception General +Register Save Area. + +Only GR values needed to emulate an instruction will be copied into this +save area and the real register numbers will be hidden. + +The Interception Parameters state description field still contains +the bytes of the instruction text, but with pre-set register values +instead of the actual ones. I.e. each instruction always uses the same +instruction text, in order not to leak guest instruction text. +This also implies that the register content that a guest had in r +may be in r from the hypervisor's point of view. + +The Secure Instruction Data Area contains instruction storage +data. Instruction data, i.e. data being referenced by an instruction +like the SCCB for sclp, is moved via the SIDA. When an instruction is +intercepted, the SIE will only allow data and program interrupts for +this instruction to be moved to the guest via the two data areas +discussed before. Other data is either ignored or results in validity +interceptions. + + +Instruction emulation interceptions +----------------------------------- +There are two types of SIE secure instruction intercepts: the normal +and the notification type. Normal secure instruction intercepts will +make the guest pending for instruction completion of the intercepted +instruction type, i.e. on SIE entry it is attempted to complete +emulation of the instruction with the data provided by KVM. That might +be a program exception or instruction completion. + +The notification type intercepts inform KVM about guest environment +changes due to guest instruction interpretation. Such an interception +is recognized, for example, for the store prefix instruction to provide +the new lowcore location. On SIE reentry, any KVM data in the data areas +is ignored and execution continues as if the guest instruction had +completed. For that reason KVM is not allowed to inject a program +interrupt. + +Links +----- +`KVM Forum 2019 presentation `_ diff --git a/Documentation/virt/kvm/timekeeping.rst b/Documentation/virt/kvm/timekeeping.rst deleted file mode 100644 index 21ae7efa29ba..000000000000 --- a/Documentation/virt/kvm/timekeeping.rst +++ /dev/null @@ -1,645 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -====================================================== -Timekeeping Virtualization for X86-Based Architectures -====================================================== - -:Author: Zachary Amsden -:Copyright: (c) 2010, Red Hat. All rights reserved. - -.. Contents - - 1) Overview - 2) Timing Devices - 3) TSC Hardware - 4) Virtualization Problems - -1. Overview -=========== - -One of the most complicated parts of the X86 platform, and specifically, -the virtualization of this platform is the plethora of timing devices available -and the complexity of emulating those devices. In addition, virtualization of -time introduces a new set of challenges because it introduces a multiplexed -division of time beyond the control of the guest CPU. - -First, we will describe the various timekeeping hardware available, then -present some of the problems which arise and solutions available, giving -specific recommendations for certain classes of KVM guests. - -The purpose of this document is to collect data and information relevant to -timekeeping which may be difficult to find elsewhere, specifically, -information relevant to KVM and hardware-based virtualization. - -2. Timing Devices -================= - -First we discuss the basic hardware devices available. TSC and the related -KVM clock are special enough to warrant a full exposition and are described in -the following section. - -2.1. i8254 - PIT ----------------- - -One of the first timer devices available is the programmable interrupt timer, -or PIT. The PIT has a fixed frequency 1.193182 MHz base clock and three -channels which can be programmed to deliver periodic or one-shot interrupts. -These three channels can be configured in different modes and have individual -counters. Channel 1 and 2 were not available for general use in the original -IBM PC, and historically were connected to control RAM refresh and the PC -speaker. Now the PIT is typically integrated as part of an emulated chipset -and a separate physical PIT is not used. - -The PIT uses I/O ports 0x40 - 0x43. Access to the 16-bit counters is done -using single or multiple byte access to the I/O ports. There are 6 modes -available, but not all modes are available to all timers, as only timer 2 -has a connected gate input, required for modes 1 and 5. The gate line is -controlled by port 61h, bit 0, as illustrated in the following diagram:: - - -------------- ---------------- - | | | | - | 1.1932 MHz|---------->| CLOCK OUT | ---------> IRQ 0 - | Clock | | | | - -------------- | +->| GATE TIMER 0 | - | ---------------- - | - | ---------------- - | | | - |------>| CLOCK OUT | ---------> 66.3 KHZ DRAM - | | | (aka /dev/null) - | +->| GATE TIMER 1 | - | ---------------- - | - | ---------------- - | | | - |------>| CLOCK OUT | ---------> Port 61h, bit 5 - | | | - Port 61h, bit 0 -------->| GATE TIMER 2 | \_.---- ____ - ---------------- _| )--|LPF|---Speaker - / *---- \___/ - Port 61h, bit 1 ---------------------------------/ - -The timer modes are now described. - -Mode 0: Single Timeout. - This is a one-shot software timeout that counts down - when the gate is high (always true for timers 0 and 1). When the count - reaches zero, the output goes high. - -Mode 1: Triggered One-shot. - The output is initially set high. When the gate - line is set high, a countdown is initiated (which does not stop if the gate is - lowered), during which the output is set low. When the count reaches zero, - the output goes high. - -Mode 2: Rate Generator. - The output is initially set high. When the countdown - reaches 1, the output goes low for one count and then returns high. The value - is reloaded and the countdown automatically resumes. If the gate line goes - low, the count is halted. If the output is low when the gate is lowered, the - output automatically goes high (this only affects timer 2). - -Mode 3: Square Wave. - This generates a high / low square wave. The count - determines the length of the pulse, which alternates between high and low - when zero is reached. The count only proceeds when gate is high and is - automatically reloaded on reaching zero. The count is decremented twice at - each clock to generate a full high / low cycle at the full periodic rate. - If the count is even, the clock remains high for N/2 counts and low for N/2 - counts; if the clock is odd, the clock is high for (N+1)/2 counts and low - for (N-1)/2 counts. Only even values are latched by the counter, so odd - values are not observed when reading. This is the intended mode for timer 2, - which generates sine-like tones by low-pass filtering the square wave output. - -Mode 4: Software Strobe. - After programming this mode and loading the counter, - the output remains high until the counter reaches zero. Then the output - goes low for 1 clock cycle and returns high. The counter is not reloaded. - Counting only occurs when gate is high. - -Mode 5: Hardware Strobe. - After programming and loading the counter, the - output remains high. When the gate is raised, a countdown is initiated - (which does not stop if the gate is lowered). When the counter reaches zero, - the output goes low for 1 clock cycle and then returns high. The counter is - not reloaded. - -In addition to normal binary counting, the PIT supports BCD counting. The -command port, 0x43 is used to set the counter and mode for each of the three -timers. - -PIT commands, issued to port 0x43, using the following bit encoding:: - - Bit 7-4: Command (See table below) - Bit 3-1: Mode (000 = Mode 0, 101 = Mode 5, 11X = undefined) - Bit 0 : Binary (0) / BCD (1) - -Command table:: - - 0000 - Latch Timer 0 count for port 0x40 - sample and hold the count to be read in port 0x40; - additional commands ignored until counter is read; - mode bits ignored. - - 0001 - Set Timer 0 LSB mode for port 0x40 - set timer to read LSB only and force MSB to zero; - mode bits set timer mode - - 0010 - Set Timer 0 MSB mode for port 0x40 - set timer to read MSB only and force LSB to zero; - mode bits set timer mode - - 0011 - Set Timer 0 16-bit mode for port 0x40 - set timer to read / write LSB first, then MSB; - mode bits set timer mode - - 0100 - Latch Timer 1 count for port 0x41 - as described above - 0101 - Set Timer 1 LSB mode for port 0x41 - as described above - 0110 - Set Timer 1 MSB mode for port 0x41 - as described above - 0111 - Set Timer 1 16-bit mode for port 0x41 - as described above - - 1000 - Latch Timer 2 count for port 0x42 - as described above - 1001 - Set Timer 2 LSB mode for port 0x42 - as described above - 1010 - Set Timer 2 MSB mode for port 0x42 - as described above - 1011 - Set Timer 2 16-bit mode for port 0x42 as described above - - 1101 - General counter latch - Latch combination of counters into corresponding ports - Bit 3 = Counter 2 - Bit 2 = Counter 1 - Bit 1 = Counter 0 - Bit 0 = Unused - - 1110 - Latch timer status - Latch combination of counter mode into corresponding ports - Bit 3 = Counter 2 - Bit 2 = Counter 1 - Bit 1 = Counter 0 - - The output of ports 0x40-0x42 following this command will be: - - Bit 7 = Output pin - Bit 6 = Count loaded (0 if timer has expired) - Bit 5-4 = Read / Write mode - 01 = MSB only - 10 = LSB only - 11 = LSB / MSB (16-bit) - Bit 3-1 = Mode - Bit 0 = Binary (0) / BCD mode (1) - -2.2. RTC --------- - -The second device which was available in the original PC was the MC146818 real -time clock. The original device is now obsolete, and usually emulated by the -system chipset, sometimes by an HPET and some frankenstein IRQ routing. - -The RTC is accessed through CMOS variables, which uses an index register to -control which bytes are read. Since there is only one index register, read -of the CMOS and read of the RTC require lock protection (in addition, it is -dangerous to allow userspace utilities such as hwclock to have direct RTC -access, as they could corrupt kernel reads and writes of CMOS memory). - -The RTC generates an interrupt which is usually routed to IRQ 8. The interrupt -can function as a periodic timer, an additional once a day alarm, and can issue -interrupts after an update of the CMOS registers by the MC146818 is complete. -The type of interrupt is signalled in the RTC status registers. - -The RTC will update the current time fields by battery power even while the -system is off. The current time fields should not be read while an update is -in progress, as indicated in the status register. - -The clock uses a 32.768kHz crystal, so bits 6-4 of register A should be -programmed to a 32kHz divider if the RTC is to count seconds. - -This is the RAM map originally used for the RTC/CMOS:: - - Location Size Description - ------------------------------------------ - 00h byte Current second (BCD) - 01h byte Seconds alarm (BCD) - 02h byte Current minute (BCD) - 03h byte Minutes alarm (BCD) - 04h byte Current hour (BCD) - 05h byte Hours alarm (BCD) - 06h byte Current day of week (BCD) - 07h byte Current day of month (BCD) - 08h byte Current month (BCD) - 09h byte Current year (BCD) - 0Ah byte Register A - bit 7 = Update in progress - bit 6-4 = Divider for clock - 000 = 4.194 MHz - 001 = 1.049 MHz - 010 = 32 kHz - 10X = test modes - 110 = reset / disable - 111 = reset / disable - bit 3-0 = Rate selection for periodic interrupt - 000 = periodic timer disabled - 001 = 3.90625 uS - 010 = 7.8125 uS - 011 = .122070 mS - 100 = .244141 mS - ... - 1101 = 125 mS - 1110 = 250 mS - 1111 = 500 mS - 0Bh byte Register B - bit 7 = Run (0) / Halt (1) - bit 6 = Periodic interrupt enable - bit 5 = Alarm interrupt enable - bit 4 = Update-ended interrupt enable - bit 3 = Square wave interrupt enable - bit 2 = BCD calendar (0) / Binary (1) - bit 1 = 12-hour mode (0) / 24-hour mode (1) - bit 0 = 0 (DST off) / 1 (DST enabled) - OCh byte Register C (read only) - bit 7 = interrupt request flag (IRQF) - bit 6 = periodic interrupt flag (PF) - bit 5 = alarm interrupt flag (AF) - bit 4 = update interrupt flag (UF) - bit 3-0 = reserved - ODh byte Register D (read only) - bit 7 = RTC has power - bit 6-0 = reserved - 32h byte Current century BCD (*) - (*) location vendor specific and now determined from ACPI global tables - -2.3. APIC ---------- - -On Pentium and later processors, an on-board timer is available to each CPU -as part of the Advanced Programmable Interrupt Controller. The APIC is -accessed through memory-mapped registers and provides interrupt service to each -CPU, used for IPIs and local timer interrupts. - -Although in theory the APIC is a safe and stable source for local interrupts, -in practice, many bugs and glitches have occurred due to the special nature of -the APIC CPU-local memory-mapped hardware. Beware that CPU errata may affect -the use of the APIC and that workarounds may be required. In addition, some of -these workarounds pose unique constraints for virtualization - requiring either -extra overhead incurred from extra reads of memory-mapped I/O or additional -functionality that may be more computationally expensive to implement. - -Since the APIC is documented quite well in the Intel and AMD manuals, we will -avoid repetition of the detail here. It should be pointed out that the APIC -timer is programmed through the LVT (local vector timer) register, is capable -of one-shot or periodic operation, and is based on the bus clock divided down -by the programmable divider register. - -2.4. HPET ---------- - -HPET is quite complex, and was originally intended to replace the PIT / RTC -support of the X86 PC. It remains to be seen whether that will be the case, as -the de facto standard of PC hardware is to emulate these older devices. Some -systems designated as legacy free may support only the HPET as a hardware timer -device. - -The HPET spec is rather loose and vague, requiring at least 3 hardware timers, -but allowing implementation freedom to support many more. It also imposes no -fixed rate on the timer frequency, but does impose some extremal values on -frequency, error and slew. - -In general, the HPET is recommended as a high precision (compared to PIT /RTC) -time source which is independent of local variation (as there is only one HPET -in any given system). The HPET is also memory-mapped, and its presence is -indicated through ACPI tables by the BIOS. - -Detailed specification of the HPET is beyond the current scope of this -document, as it is also very well documented elsewhere. - -2.5. Offboard Timers --------------------- - -Several cards, both proprietary (watchdog boards) and commonplace (e1000) have -timing chips built into the cards which may have registers which are accessible -to kernel or user drivers. To the author's knowledge, using these to generate -a clocksource for a Linux or other kernel has not yet been attempted and is in -general frowned upon as not playing by the agreed rules of the game. Such a -timer device would require additional support to be virtualized properly and is -not considered important at this time as no known operating system does this. - -3. TSC Hardware -=============== - -The TSC or time stamp counter is relatively simple in theory; it counts -instruction cycles issued by the processor, which can be used as a measure of -time. In practice, due to a number of problems, it is the most complicated -timekeeping device to use. - -The TSC is represented internally as a 64-bit MSR which can be read with the -RDMSR, RDTSC, or RDTSCP (when available) instructions. In the past, hardware -limitations made it possible to write the TSC, but generally on old hardware it -was only possible to write the low 32-bits of the 64-bit counter, and the upper -32-bits of the counter were cleared. Now, however, on Intel processors family -0Fh, for models 3, 4 and 6, and family 06h, models e and f, this restriction -has been lifted and all 64-bits are writable. On AMD systems, the ability to -write the TSC MSR is not an architectural guarantee. - -The TSC is accessible from CPL-0 and conditionally, for CPL > 0 software by -means of the CR4.TSD bit, which when enabled, disables CPL > 0 TSC access. - -Some vendors have implemented an additional instruction, RDTSCP, which returns -atomically not just the TSC, but an indicator which corresponds to the -processor number. This can be used to index into an array of TSC variables to -determine offset information in SMP systems where TSCs are not synchronized. -The presence of this instruction must be determined by consulting CPUID feature -bits. - -Both VMX and SVM provide extension fields in the virtualization hardware which -allows the guest visible TSC to be offset by a constant. Newer implementations -promise to allow the TSC to additionally be scaled, but this hardware is not -yet widely available. - -3.1. TSC synchronization ------------------------- - -The TSC is a CPU-local clock in most implementations. This means, on SMP -platforms, the TSCs of different CPUs may start at different times depending -on when the CPUs are powered on. Generally, CPUs on the same die will share -the same clock, however, this is not always the case. - -The BIOS may attempt to resynchronize the TSCs during the poweron process and -the operating system or other system software may attempt to do this as well. -Several hardware limitations make the problem worse - if it is not possible to -write the full 64-bits of the TSC, it may be impossible to match the TSC in -newly arriving CPUs to that of the rest of the system, resulting in -unsynchronized TSCs. This may be done by BIOS or system software, but in -practice, getting a perfectly synchronized TSC will not be possible unless all -values are read from the same clock, which generally only is possible on single -socket systems or those with special hardware support. - -3.2. TSC and CPU hotplug ------------------------- - -As touched on already, CPUs which arrive later than the boot time of the system -may not have a TSC value that is synchronized with the rest of the system. -Either system software, BIOS, or SMM code may actually try to establish the TSC -to a value matching the rest of the system, but a perfect match is usually not -a guarantee. This can have the effect of bringing a system from a state where -TSC is synchronized back to a state where TSC synchronization flaws, however -small, may be exposed to the OS and any virtualization environment. - -3.3. TSC and multi-socket / NUMA --------------------------------- - -Multi-socket systems, especially large multi-socket systems are likely to have -individual clocksources rather than a single, universally distributed clock. -Since these clocks are driven by different crystals, they will not have -perfectly matched frequency, and temperature and electrical variations will -cause the CPU clocks, and thus the TSCs to drift over time. Depending on the -exact clock and bus design, the drift may or may not be fixed in absolute -error, and may accumulate over time. - -In addition, very large systems may deliberately slew the clocks of individual -cores. This technique, known as spread-spectrum clocking, reduces EMI at the -clock frequency and harmonics of it, which may be required to pass FCC -standards for telecommunications and computer equipment. - -It is recommended not to trust the TSCs to remain synchronized on NUMA or -multiple socket systems for these reasons. - -3.4. TSC and C-states ---------------------- - -C-states, or idling states of the processor, especially C1E and deeper sleep -states may be problematic for TSC as well. The TSC may stop advancing in such -a state, resulting in a TSC which is behind that of other CPUs when execution -is resumed. Such CPUs must be detected and flagged by the operating system -based on CPU and chipset identifications. - -The TSC in such a case may be corrected by catching it up to a known external -clocksource. - -3.5. TSC frequency change / P-states ------------------------------------- - -To make things slightly more interesting, some CPUs may change frequency. They -may or may not run the TSC at the same rate, and because the frequency change -may be staggered or slewed, at some points in time, the TSC rate may not be -known other than falling within a range of values. In this case, the TSC will -not be a stable time source, and must be calibrated against a known, stable, -external clock to be a usable source of time. - -Whether the TSC runs at a constant rate or scales with the P-state is model -dependent and must be determined by inspecting CPUID, chipset or vendor -specific MSR fields. - -In addition, some vendors have known bugs where the P-state is actually -compensated for properly during normal operation, but when the processor is -inactive, the P-state may be raised temporarily to service cache misses from -other processors. In such cases, the TSC on halted CPUs could advance faster -than that of non-halted processors. AMD Turion processors are known to have -this problem. - -3.6. TSC and STPCLK / T-states ------------------------------- - -External signals given to the processor may also have the effect of stopping -the TSC. This is typically done for thermal emergency power control to prevent -an overheating condition, and typically, there is no way to detect that this -condition has happened. - -3.7. TSC virtualization - VMX ------------------------------ - -VMX provides conditional trapping of RDTSC, RDMSR, WRMSR and RDTSCP -instructions, which is enough for full virtualization of TSC in any manner. In -addition, VMX allows passing through the host TSC plus an additional TSC_OFFSET -field specified in the VMCS. Special instructions must be used to read and -write the VMCS field. - -3.8. TSC virtualization - SVM ------------------------------ - -SVM provides conditional trapping of RDTSC, RDMSR, WRMSR and RDTSCP -instructions, which is enough for full virtualization of TSC in any manner. In -addition, SVM allows passing through the host TSC plus an additional offset -field specified in the SVM control block. - -3.9. TSC feature bits in Linux ------------------------------- - -In summary, there is no way to guarantee the TSC remains in perfect -synchronization unless it is explicitly guaranteed by the architecture. Even -if so, the TSCs in multi-sockets or NUMA systems may still run independently -despite being locally consistent. - -The following feature bits are used by Linux to signal various TSC attributes, -but they can only be taken to be meaningful for UP or single node systems. - -========================= ======================================= -X86_FEATURE_TSC The TSC is available in hardware -X86_FEATURE_RDTSCP The RDTSCP instruction is available -X86_FEATURE_CONSTANT_TSC The TSC rate is unchanged with P-states -X86_FEATURE_NONSTOP_TSC The TSC does not stop in C-states -X86_FEATURE_TSC_RELIABLE TSC sync checks are skipped (VMware) -========================= ======================================= - -4. Virtualization Problems -========================== - -Timekeeping is especially problematic for virtualization because a number of -challenges arise. The most obvious problem is that time is now shared between -the host and, potentially, a number of virtual machines. Thus the virtual -operating system does not run with 100% usage of the CPU, despite the fact that -it may very well make that assumption. It may expect it to remain true to very -exacting bounds when interrupt sources are disabled, but in reality only its -virtual interrupt sources are disabled, and the machine may still be preempted -at any time. This causes problems as the passage of real time, the injection -of machine interrupts and the associated clock sources are no longer completely -synchronized with real time. - -This same problem can occur on native hardware to a degree, as SMM mode may -steal cycles from the naturally on X86 systems when SMM mode is used by the -BIOS, but not in such an extreme fashion. However, the fact that SMM mode may -cause similar problems to virtualization makes it a good justification for -solving many of these problems on bare metal. - -4.1. Interrupt clocking ------------------------ - -One of the most immediate problems that occurs with legacy operating systems -is that the system timekeeping routines are often designed to keep track of -time by counting periodic interrupts. These interrupts may come from the PIT -or the RTC, but the problem is the same: the host virtualization engine may not -be able to deliver the proper number of interrupts per second, and so guest -time may fall behind. This is especially problematic if a high interrupt rate -is selected, such as 1000 HZ, which is unfortunately the default for many Linux -guests. - -There are three approaches to solving this problem; first, it may be possible -to simply ignore it. Guests which have a separate time source for tracking -'wall clock' or 'real time' may not need any adjustment of their interrupts to -maintain proper time. If this is not sufficient, it may be necessary to inject -additional interrupts into the guest in order to increase the effective -interrupt rate. This approach leads to complications in extreme conditions, -where host load or guest lag is too much to compensate for, and thus another -solution to the problem has risen: the guest may need to become aware of lost -ticks and compensate for them internally. Although promising in theory, the -implementation of this policy in Linux has been extremely error prone, and a -number of buggy variants of lost tick compensation are distributed across -commonly used Linux systems. - -Windows uses periodic RTC clocking as a means of keeping time internally, and -thus requires interrupt slewing to keep proper time. It does use a low enough -rate (ed: is it 18.2 Hz?) however that it has not yet been a problem in -practice. - -4.2. TSC sampling and serialization ------------------------------------ - -As the highest precision time source available, the cycle counter of the CPU -has aroused much interest from developers. As explained above, this timer has -many problems unique to its nature as a local, potentially unstable and -potentially unsynchronized source. One issue which is not unique to the TSC, -but is highlighted because of its very precise nature is sampling delay. By -definition, the counter, once read is already old. However, it is also -possible for the counter to be read ahead of the actual use of the result. -This is a consequence of the superscalar execution of the instruction stream, -which may execute instructions out of order. Such execution is called -non-serialized. Forcing serialized execution is necessary for precise -measurement with the TSC, and requires a serializing instruction, such as CPUID -or an MSR read. - -Since CPUID may actually be virtualized by a trap and emulate mechanism, this -serialization can pose a performance issue for hardware virtualization. An -accurate time stamp counter reading may therefore not always be available, and -it may be necessary for an implementation to guard against "backwards" reads of -the TSC as seen from other CPUs, even in an otherwise perfectly synchronized -system. - -4.3. Timespec aliasing ----------------------- - -Additionally, this lack of serialization from the TSC poses another challenge -when using results of the TSC when measured against another time source. As -the TSC is much higher precision, many possible values of the TSC may be read -while another clock is still expressing the same value. - -That is, you may read (T,T+10) while external clock C maintains the same value. -Due to non-serialized reads, you may actually end up with a range which -fluctuates - from (T-1.. T+10). Thus, any time calculated from a TSC, but -calibrated against an external value may have a range of valid values. -Re-calibrating this computation may actually cause time, as computed after the -calibration, to go backwards, compared with time computed before the -calibration. - -This problem is particularly pronounced with an internal time source in Linux, -the kernel time, which is expressed in the theoretically high resolution -timespec - but which advances in much larger granularity intervals, sometimes -at the rate of jiffies, and possibly in catchup modes, at a much larger step. - -This aliasing requires care in the computation and recalibration of kvmclock -and any other values derived from TSC computation (such as TSC virtualization -itself). - -4.4. Migration --------------- - -Migration of a virtual machine raises problems for timekeeping in two ways. -First, the migration itself may take time, during which interrupts cannot be -delivered, and after which, the guest time may need to be caught up. NTP may -be able to help to some degree here, as the clock correction required is -typically small enough to fall in the NTP-correctable window. - -An additional concern is that timers based off the TSC (or HPET, if the raw bus -clock is exposed) may now be running at different rates, requiring compensation -in some way in the hypervisor by virtualizing these timers. In addition, -migrating to a faster machine may preclude the use of a passthrough TSC, as a -faster clock cannot be made visible to a guest without the potential of time -advancing faster than usual. A slower clock is less of a problem, as it can -always be caught up to the original rate. KVM clock avoids these problems by -simply storing multipliers and offsets against the TSC for the guest to convert -back into nanosecond resolution values. - -4.5. Scheduling ---------------- - -Since scheduling may be based on precise timing and firing of interrupts, the -scheduling algorithms of an operating system may be adversely affected by -virtualization. In theory, the effect is random and should be universally -distributed, but in contrived as well as real scenarios (guest device access, -causes of virtualization exits, possible context switch), this may not always -be the case. The effect of this has not been well studied. - -In an attempt to work around this, several implementations have provided a -paravirtualized scheduler clock, which reveals the true amount of CPU time for -which a virtual machine has been running. - -4.6. Watchdogs --------------- - -Watchdog timers, such as the lock detector in Linux may fire accidentally when -running under hardware virtualization due to timer interrupts being delayed or -misinterpretation of the passage of real time. Usually, these warnings are -spurious and can be ignored, but in some circumstances it may be necessary to -disable such detection. - -4.7. Delays and precision timing --------------------------------- - -Precise timing and delays may not be possible in a virtualized system. This -can happen if the system is controlling physical hardware, or issues delays to -compensate for slower I/O to and from devices. The first issue is not solvable -in general for a virtualized system; hardware control software can't be -adequately virtualized without a full real-time operating system, which would -require an RT aware virtualization platform. - -The second issue may cause performance problems, but this is unlikely to be a -significant issue. In many cases these delays may be eliminated through -configuration or paravirtualization. - -4.8. Covert channels and leaks ------------------------------- - -In addition to the above problems, time information will inevitably leak to the -guest about the host in anything but a perfect implementation of virtualized -time. This may allow the guest to infer the presence of a hypervisor (as in a -red-pill type detection), and it may allow information to leak between guests -by using CPU utilization itself as a signalling channel. Preventing such -problems would require completely isolated virtual time which may not track -real time any longer. This may be useful in certain security or QA contexts, -but in general isn't recommended for real-world deployment scenarios. diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst new file mode 100644 index 000000000000..1c6847fff304 --- /dev/null +++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst @@ -0,0 +1,445 @@ +====================================== +Secure Encrypted Virtualization (SEV) +====================================== + +Overview +======== + +Secure Encrypted Virtualization (SEV) is a feature found on AMD processors. + +SEV is an extension to the AMD-V architecture which supports running +virtual machines (VMs) under the control of a hypervisor. When enabled, +the memory contents of a VM will be transparently encrypted with a key +unique to that VM. + +The hypervisor can determine the SEV support through the CPUID +instruction. The CPUID function 0x8000001f reports information related +to SEV:: + + 0x8000001f[eax]: + Bit[1] indicates support for SEV + ... + [ecx]: + Bits[31:0] Number of encrypted guests supported simultaneously + +If support for SEV is present, MSR 0xc001_0010 (MSR_AMD64_SYSCFG) and MSR 0xc001_0015 +(MSR_K7_HWCR) can be used to determine if it can be enabled:: + + 0xc001_0010: + Bit[23] 1 = memory encryption can be enabled + 0 = memory encryption can not be enabled + + 0xc001_0015: + Bit[0] 1 = memory encryption can be enabled + 0 = memory encryption can not be enabled + +When SEV support is available, it can be enabled in a specific VM by +setting the SEV bit before executing VMRUN.:: + + VMCB[0x90]: + Bit[1] 1 = SEV is enabled + 0 = SEV is disabled + +SEV hardware uses ASIDs to associate a memory encryption key with a VM. +Hence, the ASID for the SEV-enabled guests must be from 1 to a maximum value +defined in the CPUID 0x8000001f[ecx] field. + +SEV Key Management +================== + +The SEV guest key management is handled by a separate processor called the AMD +Secure Processor (AMD-SP). Firmware running inside the AMD-SP provides a secure +key management interface to perform common hypervisor activities such as +encrypting bootstrap code, snapshot, migrating and debugging the guest. For more +information, see the SEV Key Management spec [api-spec]_ + +The main ioctl to access SEV is KVM_MEMORY_ENCRYPT_OP. If the argument +to KVM_MEMORY_ENCRYPT_OP is NULL, the ioctl returns 0 if SEV is enabled +and ``ENOTTY` if it is disabled (on some older versions of Linux, +the ioctl runs normally even with a NULL argument, and therefore will +likely return ``EFAULT``). If non-NULL, the argument to KVM_MEMORY_ENCRYPT_OP +must be a struct kvm_sev_cmd:: + + struct kvm_sev_cmd { + __u32 id; + __u64 data; + __u32 error; + __u32 sev_fd; + }; + + +The ``id`` field contains the subcommand, and the ``data`` field points to +another struct containing arguments specific to command. The ``sev_fd`` +should point to a file descriptor that is opened on the ``/dev/sev`` +device, if needed (see individual commands). + +On output, ``error`` is zero on success, or an error code. Error codes +are defined in ````. + +KVM implements the following commands to support common lifecycle events of SEV +guests, such as launching, running, snapshotting, migrating and decommissioning. + +1. KVM_SEV_INIT +--------------- + +The KVM_SEV_INIT command is used by the hypervisor to initialize the SEV platform +context. In a typical workflow, this command should be the first command issued. + +The firmware can be initialized either by using its own non-volatile storage or +the OS can manage the NV storage for the firmware using the module parameter +``init_ex_path``. The file specified by ``init_ex_path`` must exist. To create +a new NV storage file allocate the file with 32KB bytes of 0xFF as required by +the SEV spec. + +Returns: 0 on success, -negative on error + +2. KVM_SEV_LAUNCH_START +----------------------- + +The KVM_SEV_LAUNCH_START command is used for creating the memory encryption +context. To create the encryption context, user must provide a guest policy, +the owner's public Diffie-Hellman (PDH) key and session information. + +Parameters: struct kvm_sev_launch_start (in/out) + +Returns: 0 on success, -negative on error + +:: + + struct kvm_sev_launch_start { + __u32 handle; /* if zero then firmware creates a new handle */ + __u32 policy; /* guest's policy */ + + __u64 dh_uaddr; /* userspace address pointing to the guest owner's PDH key */ + __u32 dh_len; + + __u64 session_addr; /* userspace address which points to the guest session information */ + __u32 session_len; + }; + +On success, the 'handle' field contains a new handle and on error, a negative value. + +KVM_SEV_LAUNCH_START requires the ``sev_fd`` field to be valid. + +For more details, see SEV spec Section 6.2. + +3. KVM_SEV_LAUNCH_UPDATE_DATA +----------------------------- + +The KVM_SEV_LAUNCH_UPDATE_DATA is used for encrypting a memory region. It also +calculates a measurement of the memory contents. The measurement is a signature +of the memory contents that can be sent to the guest owner as an attestation +that the memory was encrypted correctly by the firmware. + +Parameters (in): struct kvm_sev_launch_update_data + +Returns: 0 on success, -negative on error + +:: + + struct kvm_sev_launch_update { + __u64 uaddr; /* userspace address to be encrypted (must be 16-byte aligned) */ + __u32 len; /* length of the data to be encrypted (must be 16-byte aligned) */ + }; + +For more details, see SEV spec Section 6.3. + +4. KVM_SEV_LAUNCH_MEASURE +------------------------- + +The KVM_SEV_LAUNCH_MEASURE command is used to retrieve the measurement of the +data encrypted by the KVM_SEV_LAUNCH_UPDATE_DATA command. The guest owner may +wait to provide the guest with confidential information until it can verify the +measurement. Since the guest owner knows the initial contents of the guest at +boot, the measurement can be verified by comparing it to what the guest owner +expects. + +If len is zero on entry, the measurement blob length is written to len and +uaddr is unused. + +Parameters (in): struct kvm_sev_launch_measure + +Returns: 0 on success, -negative on error + +:: + + struct kvm_sev_launch_measure { + __u64 uaddr; /* where to copy the measurement */ + __u32 len; /* length of measurement blob */ + }; + +For more details on the measurement verification flow, see SEV spec Section 6.4. + +5. KVM_SEV_LAUNCH_FINISH +------------------------ + +After completion of the launch flow, the KVM_SEV_LAUNCH_FINISH command can be +issued to make the guest ready for the execution. + +Returns: 0 on success, -negative on error + +6. KVM_SEV_GUEST_STATUS +----------------------- + +The KVM_SEV_GUEST_STATUS command is used to retrieve status information about a +SEV-enabled guest. + +Parameters (out): struct kvm_sev_guest_status + +Returns: 0 on success, -negative on error + +:: + + struct kvm_sev_guest_status { + __u32 handle; /* guest handle */ + __u32 policy; /* guest policy */ + __u8 state; /* guest state (see enum below) */ + }; + +SEV guest state: + +:: + + enum { + SEV_STATE_INVALID = 0; + SEV_STATE_LAUNCHING, /* guest is currently being launched */ + SEV_STATE_SECRET, /* guest is being launched and ready to accept the ciphertext data */ + SEV_STATE_RUNNING, /* guest is fully launched and running */ + SEV_STATE_RECEIVING, /* guest is being migrated in from another SEV machine */ + SEV_STATE_SENDING /* guest is getting migrated out to another SEV machine */ + }; + +7. KVM_SEV_DBG_DECRYPT +---------------------- + +The KVM_SEV_DEBUG_DECRYPT command can be used by the hypervisor to request the +firmware to decrypt the data at the given memory region. + +Parameters (in): struct kvm_sev_dbg + +Returns: 0 on success, -negative on error + +:: + + struct kvm_sev_dbg { + __u64 src_uaddr; /* userspace address of data to decrypt */ + __u64 dst_uaddr; /* userspace address of destination */ + __u32 len; /* length of memory region to decrypt */ + }; + +The command returns an error if the guest policy does not allow debugging. + +8. KVM_SEV_DBG_ENCRYPT +---------------------- + +The KVM_SEV_DEBUG_ENCRYPT command can be used by the hypervisor to request the +firmware to encrypt the data at the given memory region. + +Parameters (in): struct kvm_sev_dbg + +Returns: 0 on success, -negative on error + +:: + + struct kvm_sev_dbg { + __u64 src_uaddr; /* userspace address of data to encrypt */ + __u64 dst_uaddr; /* userspace address of destination */ + __u32 len; /* length of memory region to encrypt */ + }; + +The command returns an error if the guest policy does not allow debugging. + +9. KVM_SEV_LAUNCH_SECRET +------------------------ + +The KVM_SEV_LAUNCH_SECRET command can be used by the hypervisor to inject secret +data after the measurement has been validated by the guest owner. + +Parameters (in): struct kvm_sev_launch_secret + +Returns: 0 on success, -negative on error + +:: + + struct kvm_sev_launch_secret { + __u64 hdr_uaddr; /* userspace address containing the packet header */ + __u32 hdr_len; + + __u64 guest_uaddr; /* the guest memory region where the secret should be injected */ + __u32 guest_len; + + __u64 trans_uaddr; /* the hypervisor memory region which contains the secret */ + __u32 trans_len; + }; + +10. KVM_SEV_GET_ATTESTATION_REPORT +---------------------------------- + +The KVM_SEV_GET_ATTESTATION_REPORT command can be used by the hypervisor to query the attestation +report containing the SHA-256 digest of the guest memory and VMSA passed through the KVM_SEV_LAUNCH +commands and signed with the PEK. The digest returned by the command should match the digest +used by the guest owner with the KVM_SEV_LAUNCH_MEASURE. + +If len is zero on entry, the measurement blob length is written to len and +uaddr is unused. + +Parameters (in): struct kvm_sev_attestation + +Returns: 0 on success, -negative on error + +:: + + struct kvm_sev_attestation_report { + __u8 mnonce[16]; /* A random mnonce that will be placed in the report */ + + __u64 uaddr; /* userspace address where the report should be copied */ + __u32 len; + }; + +11. KVM_SEV_SEND_START +---------------------- + +The KVM_SEV_SEND_START command can be used by the hypervisor to create an +outgoing guest encryption context. + +If session_len is zero on entry, the length of the guest session information is +written to session_len and all other fields are not used. + +Parameters (in): struct kvm_sev_send_start + +Returns: 0 on success, -negative on error + +:: + + struct kvm_sev_send_start { + __u32 policy; /* guest policy */ + + __u64 pdh_cert_uaddr; /* platform Diffie-Hellman certificate */ + __u32 pdh_cert_len; + + __u64 plat_certs_uaddr; /* platform certificate chain */ + __u32 plat_certs_len; + + __u64 amd_certs_uaddr; /* AMD certificate */ + __u32 amd_certs_len; + + __u64 session_uaddr; /* Guest session information */ + __u32 session_len; + }; + +12. KVM_SEV_SEND_UPDATE_DATA +---------------------------- + +The KVM_SEV_SEND_UPDATE_DATA command can be used by the hypervisor to encrypt the +outgoing guest memory region with the encryption context creating using +KVM_SEV_SEND_START. + +If hdr_len or trans_len are zero on entry, the length of the packet header and +transport region are written to hdr_len and trans_len respectively, and all +other fields are not used. + +Parameters (in): struct kvm_sev_send_update_data + +Returns: 0 on success, -negative on error + +:: + + struct kvm_sev_launch_send_update_data { + __u64 hdr_uaddr; /* userspace address containing the packet header */ + __u32 hdr_len; + + __u64 guest_uaddr; /* the source memory region to be encrypted */ + __u32 guest_len; + + __u64 trans_uaddr; /* the destination memory region */ + __u32 trans_len; + }; + +13. KVM_SEV_SEND_FINISH +------------------------ + +After completion of the migration flow, the KVM_SEV_SEND_FINISH command can be +issued by the hypervisor to delete the encryption context. + +Returns: 0 on success, -negative on error + +14. KVM_SEV_SEND_CANCEL +------------------------ + +After completion of SEND_START, but before SEND_FINISH, the source VMM can issue the +SEND_CANCEL command to stop a migration. This is necessary so that a cancelled +migration can restart with a new target later. + +Returns: 0 on success, -negative on error + +15. KVM_SEV_RECEIVE_START +------------------------- + +The KVM_SEV_RECEIVE_START command is used for creating the memory encryption +context for an incoming SEV guest. To create the encryption context, the user must +provide a guest policy, the platform public Diffie-Hellman (PDH) key and session +information. + +Parameters: struct kvm_sev_receive_start (in/out) + +Returns: 0 on success, -negative on error + +:: + + struct kvm_sev_receive_start { + __u32 handle; /* if zero then firmware creates a new handle */ + __u32 policy; /* guest's policy */ + + __u64 pdh_uaddr; /* userspace address pointing to the PDH key */ + __u32 pdh_len; + + __u64 session_uaddr; /* userspace address which points to the guest session information */ + __u32 session_len; + }; + +On success, the 'handle' field contains a new handle and on error, a negative value. + +For more details, see SEV spec Section 6.12. + +16. KVM_SEV_RECEIVE_UPDATE_DATA +------------------------------- + +The KVM_SEV_RECEIVE_UPDATE_DATA command can be used by the hypervisor to copy +the incoming buffers into the guest memory region with encryption context +created during the KVM_SEV_RECEIVE_START. + +Parameters (in): struct kvm_sev_receive_update_data + +Returns: 0 on success, -negative on error + +:: + + struct kvm_sev_launch_receive_update_data { + __u64 hdr_uaddr; /* userspace address containing the packet header */ + __u32 hdr_len; + + __u64 guest_uaddr; /* the destination guest memory region */ + __u32 guest_len; + + __u64 trans_uaddr; /* the incoming buffer memory region */ + __u32 trans_len; + }; + +17. KVM_SEV_RECEIVE_FINISH +-------------------------- + +After completion of the migration flow, the KVM_SEV_RECEIVE_FINISH command can be +issued by the hypervisor to make the guest ready for execution. + +Returns: 0 on success, -negative on error + +References +========== + + +See [white-paper]_, [api-spec]_, [amd-apm]_ and [kvm-forum]_ for more info. + +.. [white-paper] http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf +.. [api-spec] https://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf +.. [amd-apm] https://support.amd.com/TechDocs/24593.pdf (section 15.34) +.. [kvm-forum] https://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf diff --git a/Documentation/virt/kvm/x86/cpuid.rst b/Documentation/virt/kvm/x86/cpuid.rst new file mode 100644 index 000000000000..bda3e3e737d7 --- /dev/null +++ b/Documentation/virt/kvm/x86/cpuid.rst @@ -0,0 +1,124 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============== +KVM CPUID bits +============== + +:Author: Glauber Costa + +A guest running on a kvm host, can check some of its features using +cpuid. This is not always guaranteed to work, since userspace can +mask-out some, or even all KVM-related cpuid features before launching +a guest. + +KVM cpuid functions are: + +function: KVM_CPUID_SIGNATURE (0x40000000) + +returns:: + + eax = 0x40000001 + ebx = 0x4b4d564b + ecx = 0x564b4d56 + edx = 0x4d + +Note that this value in ebx, ecx and edx corresponds to the string "KVMKVMKVM". +The value in eax corresponds to the maximum cpuid function present in this leaf, +and will be updated if more functions are added in the future. +Note also that old hosts set eax value to 0x0. This should +be interpreted as if the value was 0x40000001. +This function queries the presence of KVM cpuid leafs. + +function: define KVM_CPUID_FEATURES (0x40000001) + +returns:: + + ebx, ecx + eax = an OR'ed group of (1 << flag) + +where ``flag`` is defined as below: + +================================== =========== ================================ +flag value meaning +================================== =========== ================================ +KVM_FEATURE_CLOCKSOURCE 0 kvmclock available at msrs + 0x11 and 0x12 + +KVM_FEATURE_NOP_IO_DELAY 1 not necessary to perform delays + on PIO operations + +KVM_FEATURE_MMU_OP 2 deprecated + +KVM_FEATURE_CLOCKSOURCE2 3 kvmclock available at msrs + 0x4b564d00 and 0x4b564d01 + +KVM_FEATURE_ASYNC_PF 4 async pf can be enabled by + writing to msr 0x4b564d02 + +KVM_FEATURE_STEAL_TIME 5 steal time can be enabled by + writing to msr 0x4b564d03 + +KVM_FEATURE_PV_EOI 6 paravirtualized end of interrupt + handler can be enabled by + writing to msr 0x4b564d04 + +KVM_FEATURE_PV_UNHALT 7 guest checks this feature bit + before enabling paravirtualized + spinlock support + +KVM_FEATURE_PV_TLB_FLUSH 9 guest checks this feature bit + before enabling paravirtualized + tlb flush + +KVM_FEATURE_ASYNC_PF_VMEXIT 10 paravirtualized async PF VM EXIT + can be enabled by setting bit 2 + when writing to msr 0x4b564d02 + +KVM_FEATURE_PV_SEND_IPI 11 guest checks this feature bit + before enabling paravirtualized + send IPIs + +KVM_FEATURE_POLL_CONTROL 12 host-side polling on HLT can + be disabled by writing + to msr 0x4b564d05. + +KVM_FEATURE_PV_SCHED_YIELD 13 guest checks this feature bit + before using paravirtualized + sched yield. + +KVM_FEATURE_ASYNC_PF_INT 14 guest checks this feature bit + before using the second async + pf control msr 0x4b564d06 and + async pf acknowledgment msr + 0x4b564d07. + +KVM_FEATURE_MSI_EXT_DEST_ID 15 guest checks this feature bit + before using extended destination + ID bits in MSI address bits 11-5. + +KVM_FEATURE_HC_MAP_GPA_RANGE 16 guest checks this feature bit before + using the map gpa range hypercall + to notify the page state change + +KVM_FEATURE_MIGRATION_CONTROL 17 guest checks this feature bit before + using MSR_KVM_MIGRATION_CONTROL + +KVM_FEATURE_CLOCKSOURCE_STABLE_BIT 24 host will warn if no guest-side + per-cpu warps are expected in + kvmclock +================================== =========== ================================ + +:: + + edx = an OR'ed group of (1 << flag) + +Where ``flag`` here is defined as below: + +================== ============ ================================= +flag value meaning +================== ============ ================================= +KVM_HINTS_REALTIME 0 guest checks this feature bit to + determine that vCPUs are never + preempted for an unlimited time + allowing optimizations +================== ============ ================================= diff --git a/Documentation/virt/kvm/x86/halt-polling.rst b/Documentation/virt/kvm/x86/halt-polling.rst new file mode 100644 index 000000000000..4922e4a15f18 --- /dev/null +++ b/Documentation/virt/kvm/x86/halt-polling.rst @@ -0,0 +1,140 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================== +The KVM halt polling system +=========================== + +The KVM halt polling system provides a feature within KVM whereby the latency +of a guest can, under some circumstances, be reduced by polling in the host +for some time period after the guest has elected to no longer run by cedeing. +That is, when a guest vcpu has ceded, or in the case of powerpc when all of the +vcpus of a single vcore have ceded, the host kernel polls for wakeup conditions +before giving up the cpu to the scheduler in order to let something else run. + +Polling provides a latency advantage in cases where the guest can be run again +very quickly by at least saving us a trip through the scheduler, normally on +the order of a few micro-seconds, although performance benefits are workload +dependant. In the event that no wakeup source arrives during the polling +interval or some other task on the runqueue is runnable the scheduler is +invoked. Thus halt polling is especially useful on workloads with very short +wakeup periods where the time spent halt polling is minimised and the time +savings of not invoking the scheduler are distinguishable. + +The generic halt polling code is implemented in: + + virt/kvm/kvm_main.c: kvm_vcpu_block() + +The powerpc kvm-hv specific case is implemented in: + + arch/powerpc/kvm/book3s_hv.c: kvmppc_vcore_blocked() + +Halt Polling Interval +===================== + +The maximum time for which to poll before invoking the scheduler, referred to +as the halt polling interval, is increased and decreased based on the perceived +effectiveness of the polling in an attempt to limit pointless polling. +This value is stored in either the vcpu struct: + + kvm_vcpu->halt_poll_ns + +or in the case of powerpc kvm-hv, in the vcore struct: + + kvmppc_vcore->halt_poll_ns + +Thus this is a per vcpu (or vcore) value. + +During polling if a wakeup source is received within the halt polling interval, +the interval is left unchanged. In the event that a wakeup source isn't +received during the polling interval (and thus schedule is invoked) there are +two options, either the polling interval and total block time[0] were less than +the global max polling interval (see module params below), or the total block +time was greater than the global max polling interval. + +In the event that both the polling interval and total block time were less than +the global max polling interval then the polling interval can be increased in +the hope that next time during the longer polling interval the wake up source +will be received while the host is polling and the latency benefits will be +received. The polling interval is grown in the function grow_halt_poll_ns() and +is multiplied by the module parameters halt_poll_ns_grow and +halt_poll_ns_grow_start. + +In the event that the total block time was greater than the global max polling +interval then the host will never poll for long enough (limited by the global +max) to wakeup during the polling interval so it may as well be shrunk in order +to avoid pointless polling. The polling interval is shrunk in the function +shrink_halt_poll_ns() and is divided by the module parameter +halt_poll_ns_shrink, or set to 0 iff halt_poll_ns_shrink == 0. + +It is worth noting that this adjustment process attempts to hone in on some +steady state polling interval but will only really do a good job for wakeups +which come at an approximately constant rate, otherwise there will be constant +adjustment of the polling interval. + +[0] total block time: + the time between when the halt polling function is + invoked and a wakeup source received (irrespective of + whether the scheduler is invoked within that function). + +Module Parameters +================= + +The kvm module has 3 tuneable module parameters to adjust the global max +polling interval as well as the rate at which the polling interval is grown and +shrunk. These variables are defined in include/linux/kvm_host.h and as module +parameters in virt/kvm/kvm_main.c, or arch/powerpc/kvm/book3s_hv.c in the +powerpc kvm-hv case. + ++-----------------------+---------------------------+-------------------------+ +|Module Parameter | Description | Default Value | ++-----------------------+---------------------------+-------------------------+ +|halt_poll_ns | The global max polling | KVM_HALT_POLL_NS_DEFAULT| +| | interval which defines | | +| | the ceiling value of the | | +| | polling interval for | (per arch value) | +| | each vcpu. | | ++-----------------------+---------------------------+-------------------------+ +|halt_poll_ns_grow | The value by which the | 2 | +| | halt polling interval is | | +| | multiplied in the | | +| | grow_halt_poll_ns() | | +| | function. | | ++-----------------------+---------------------------+-------------------------+ +|halt_poll_ns_grow_start| The initial value to grow | 10000 | +| | to from zero in the | | +| | grow_halt_poll_ns() | | +| | function. | | ++-----------------------+---------------------------+-------------------------+ +|halt_poll_ns_shrink | The value by which the | 0 | +| | halt polling interval is | | +| | divided in the | | +| | shrink_halt_poll_ns() | | +| | function. | | ++-----------------------+---------------------------+-------------------------+ + +These module parameters can be set from the debugfs files in: + + /sys/module/kvm/parameters/ + +Note: that these module parameters are system wide values and are not able to + be tuned on a per vm basis. + +Further Notes +============= + +- Care should be taken when setting the halt_poll_ns module parameter as a large value + has the potential to drive the cpu usage to 100% on a machine which would be almost + entirely idle otherwise. This is because even if a guest has wakeups during which very + little work is done and which are quite far apart, if the period is shorter than the + global max polling interval (halt_poll_ns) then the host will always poll for the + entire block time and thus cpu utilisation will go to 100%. + +- Halt polling essentially presents a trade off between power usage and latency and + the module parameters should be used to tune the affinity for this. Idle cpu time is + essentially converted to host kernel time with the aim of decreasing latency when + entering the guest. + +- Halt polling will only be conducted by the host when no other tasks are runnable on + that cpu, otherwise the polling will cease immediately and schedule will be invoked to + allow that other task to run. Thus this doesn't allow a guest to denial of service the + cpu. diff --git a/Documentation/virt/kvm/x86/hypercalls.rst b/Documentation/virt/kvm/x86/hypercalls.rst new file mode 100644 index 000000000000..e56fa8b9cfca --- /dev/null +++ b/Documentation/virt/kvm/x86/hypercalls.rst @@ -0,0 +1,192 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================== +Linux KVM Hypercall +=================== + +X86: + KVM Hypercalls have a three-byte sequence of either the vmcall or the vmmcall + instruction. The hypervisor can replace it with instructions that are + guaranteed to be supported. + + Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively. + The hypercall number should be placed in rax and the return value will be + placed in rax. No other registers will be clobbered unless explicitly stated + by the particular hypercall. + +S390: + R2-R7 are used for parameters 1-6. In addition, R1 is used for hypercall + number. The return value is written to R2. + + S390 uses diagnose instruction as hypercall (0x500) along with hypercall + number in R1. + + For further information on the S390 diagnose call as supported by KVM, + refer to Documentation/virt/kvm/s390-diag.rst. + +PowerPC: + It uses R3-R10 and hypercall number in R11. R4-R11 are used as output registers. + Return value is placed in R3. + + KVM hypercalls uses 4 byte opcode, that are patched with 'hypercall-instructions' + property inside the device tree's /hypervisor node. + For more information refer to Documentation/virt/kvm/ppc-pv.rst + +MIPS: + KVM hypercalls use the HYPCALL instruction with code 0 and the hypercall + number in $2 (v0). Up to four arguments may be placed in $4-$7 (a0-a3) and + the return value is placed in $2 (v0). + +KVM Hypercalls Documentation +============================ + +The template for each hypercall is: +1. Hypercall name. +2. Architecture(s) +3. Status (deprecated, obsolete, active) +4. Purpose + +1. KVM_HC_VAPIC_POLL_IRQ +------------------------ + +:Architecture: x86 +:Status: active +:Purpose: Trigger guest exit so that the host can check for pending + interrupts on reentry. + +2. KVM_HC_MMU_OP +---------------- + +:Architecture: x86 +:Status: deprecated. +:Purpose: Support MMU operations such as writing to PTE, + flushing TLB, release PT. + +3. KVM_HC_FEATURES +------------------ + +:Architecture: PPC +:Status: active +:Purpose: Expose hypercall availability to the guest. On x86 platforms, cpuid + used to enumerate which hypercalls are available. On PPC, either + device tree based lookup ( which is also what EPAPR dictates) + OR KVM specific enumeration mechanism (which is this hypercall) + can be used. + +4. KVM_HC_PPC_MAP_MAGIC_PAGE +---------------------------- + +:Architecture: PPC +:Status: active +:Purpose: To enable communication between the hypervisor and guest there is a + shared page that contains parts of supervisor visible register state. + The guest can map this shared page to access its supervisor register + through memory using this hypercall. + +5. KVM_HC_KICK_CPU +------------------ + +:Architecture: x86 +:Status: active +:Purpose: Hypercall used to wakeup a vcpu from HLT state +:Usage example: + A vcpu of a paravirtualized guest that is busywaiting in guest + kernel mode for an event to occur (ex: a spinlock to become available) can + execute HLT instruction once it has busy-waited for more than a threshold + time-interval. Execution of HLT instruction would cause the hypervisor to put + the vcpu to sleep until occurrence of an appropriate event. Another vcpu of the + same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall, + specifying APIC ID (a1) of the vcpu to be woken up. An additional argument (a0) + is used in the hypercall for future use. + + +6. KVM_HC_CLOCK_PAIRING +----------------------- +:Architecture: x86 +:Status: active +:Purpose: Hypercall used to synchronize host and guest clocks. + +Usage: + +a0: guest physical address where host copies +"struct kvm_clock_offset" structure. + +a1: clock_type, ATM only KVM_CLOCK_PAIRING_WALLCLOCK (0) +is supported (corresponding to the host's CLOCK_REALTIME clock). + + :: + + struct kvm_clock_pairing { + __s64 sec; + __s64 nsec; + __u64 tsc; + __u32 flags; + __u32 pad[9]; + }; + + Where: + * sec: seconds from clock_type clock. + * nsec: nanoseconds from clock_type clock. + * tsc: guest TSC value used to calculate sec/nsec pair + * flags: flags, unused (0) at the moment. + +The hypercall lets a guest compute a precise timestamp across +host and guest. The guest can use the returned TSC value to +compute the CLOCK_REALTIME for its clock, at the same instant. + +Returns KVM_EOPNOTSUPP if the host does not use TSC clocksource, +or if clock type is different than KVM_CLOCK_PAIRING_WALLCLOCK. + +6. KVM_HC_SEND_IPI +------------------ + +:Architecture: x86 +:Status: active +:Purpose: Send IPIs to multiple vCPUs. + +- a0: lower part of the bitmap of destination APIC IDs +- a1: higher part of the bitmap of destination APIC IDs +- a2: the lowest APIC ID in bitmap +- a3: APIC ICR + +The hypercall lets a guest send multicast IPIs, with at most 128 +128 destinations per hypercall in 64-bit mode and 64 vCPUs per +hypercall in 32-bit mode. The destinations are represented by a +bitmap contained in the first two arguments (a0 and a1). Bit 0 of +a0 corresponds to the APIC ID in the third argument (a2), bit 1 +corresponds to the APIC ID a2+1, and so on. + +Returns the number of CPUs to which the IPIs were delivered successfully. + +7. KVM_HC_SCHED_YIELD +--------------------- + +:Architecture: x86 +:Status: active +:Purpose: Hypercall used to yield if the IPI target vCPU is preempted + +a0: destination APIC ID + +:Usage example: When sending a call-function IPI-many to vCPUs, yield if + any of the IPI target vCPUs was preempted. + +8. KVM_HC_MAP_GPA_RANGE +------------------------- +:Architecture: x86 +:Status: active +:Purpose: Request KVM to map a GPA range with the specified attributes. + +a0: the guest physical address of the start page +a1: the number of (4kb) pages (must be contiguous in GPA space) +a2: attributes + + Where 'attributes' : + * bits 3:0 - preferred page size encoding 0 = 4kb, 1 = 2mb, 2 = 1gb, etc... + * bit 4 - plaintext = 0, encrypted = 1 + * bits 63:5 - reserved (must be zero) + +**Implementation note**: this hypercall is implemented in userspace via +the KVM_CAP_EXIT_HYPERCALL capability. Userspace must enable that capability +before advertising KVM_FEATURE_HC_MAP_GPA_RANGE in the guest CPUID. In +addition, if the guest supports KVM_FEATURE_MIGRATION_CONTROL, userspace +must also set up an MSR filter to process writes to MSR_KVM_MIGRATION_CONTROL. diff --git a/Documentation/virt/kvm/x86/index.rst b/Documentation/virt/kvm/x86/index.rst new file mode 100644 index 000000000000..55ede8e070b6 --- /dev/null +++ b/Documentation/virt/kvm/x86/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================== +KVM for x86 systems +=================== + +.. toctree:: + :maxdepth: 2 + + amd-memory-encryption + cpuid + halt-polling + hypercalls + mmu + msr + nested-vmx + running-nested-guests + timekeeping diff --git a/Documentation/virt/kvm/x86/mmu.rst b/Documentation/virt/kvm/x86/mmu.rst new file mode 100644 index 000000000000..5b1ebad24c77 --- /dev/null +++ b/Documentation/virt/kvm/x86/mmu.rst @@ -0,0 +1,480 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================== +The x86 kvm shadow mmu +====================== + +The mmu (in arch/x86/kvm, files mmu.[ch] and paging_tmpl.h) is responsible +for presenting a standard x86 mmu to the guest, while translating guest +physical addresses to host physical addresses. + +The mmu code attempts to satisfy the following requirements: + +- correctness: + the guest should not be able to determine that it is running + on an emulated mmu except for timing (we attempt to comply + with the specification, not emulate the characteristics of + a particular implementation such as tlb size) +- security: + the guest must not be able to touch host memory not assigned + to it +- performance: + minimize the performance penalty imposed by the mmu +- scaling: + need to scale to large memory and large vcpu guests +- hardware: + support the full range of x86 virtualization hardware +- integration: + Linux memory management code must be in control of guest memory + so that swapping, page migration, page merging, transparent + hugepages, and similar features work without change +- dirty tracking: + report writes to guest memory to enable live migration + and framebuffer-based displays +- footprint: + keep the amount of pinned kernel memory low (most memory + should be shrinkable) +- reliability: + avoid multipage or GFP_ATOMIC allocations + +Acronyms +======== + +==== ==================================================================== +pfn host page frame number +hpa host physical address +hva host virtual address +gfn guest frame number +gpa guest physical address +gva guest virtual address +ngpa nested guest physical address +ngva nested guest virtual address +pte page table entry (used also to refer generically to paging structure + entries) +gpte guest pte (referring to gfns) +spte shadow pte (referring to pfns) +tdp two dimensional paging (vendor neutral term for NPT and EPT) +==== ==================================================================== + +Virtual and real hardware supported +=================================== + +The mmu supports first-generation mmu hardware, which allows an atomic switch +of the current paging mode and cr3 during guest entry, as well as +two-dimensional paging (AMD's NPT and Intel's EPT). The emulated hardware +it exposes is the traditional 2/3/4 level x86 mmu, with support for global +pages, pae, pse, pse36, cr0.wp, and 1GB pages. Emulated hardware also +able to expose NPT capable hardware on NPT capable hosts. + +Translation +=========== + +The primary job of the mmu is to program the processor's mmu to translate +addresses for the guest. Different translations are required at different +times: + +- when guest paging is disabled, we translate guest physical addresses to + host physical addresses (gpa->hpa) +- when guest paging is enabled, we translate guest virtual addresses, to + guest physical addresses, to host physical addresses (gva->gpa->hpa) +- when the guest launches a guest of its own, we translate nested guest + virtual addresses, to nested guest physical addresses, to guest physical + addresses, to host physical addresses (ngva->ngpa->gpa->hpa) + +The primary challenge is to encode between 1 and 3 translations into hardware +that support only 1 (traditional) and 2 (tdp) translations. When the +number of required translations matches the hardware, the mmu operates in +direct mode; otherwise it operates in shadow mode (see below). + +Memory +====== + +Guest memory (gpa) is part of the user address space of the process that is +using kvm. Userspace defines the translation between guest addresses and user +addresses (gpa->hva); note that two gpas may alias to the same hva, but not +vice versa. + +These hvas may be backed using any method available to the host: anonymous +memory, file backed memory, and device memory. Memory might be paged by the +host at any time. + +Events +====== + +The mmu is driven by events, some from the guest, some from the host. + +Guest generated events: + +- writes to control registers (especially cr3) +- invlpg/invlpga instruction execution +- access to missing or protected translations + +Host generated events: + +- changes in the gpa->hpa translation (either through gpa->hva changes or + through hva->hpa changes) +- memory pressure (the shrinker) + +Shadow pages +============ + +The principal data structure is the shadow page, 'struct kvm_mmu_page'. A +shadow page contains 512 sptes, which can be either leaf or nonleaf sptes. A +shadow page may contain a mix of leaf and nonleaf sptes. + +A nonleaf spte allows the hardware mmu to reach the leaf pages and +is not related to a translation directly. It points to other shadow pages. + +A leaf spte corresponds to either one or two translations encoded into +one paging structure entry. These are always the lowest level of the +translation stack, with optional higher level translations left to NPT/EPT. +Leaf ptes point at guest pages. + +The following table shows translations encoded by leaf ptes, with higher-level +translations in parentheses: + + Non-nested guests:: + + nonpaging: gpa->hpa + paging: gva->gpa->hpa + paging, tdp: (gva->)gpa->hpa + + Nested guests:: + + non-tdp: ngva->gpa->hpa (*) + tdp: (ngva->)ngpa->gpa->hpa + + (*) the guest hypervisor will encode the ngva->gpa translation into its page + tables if npt is not present + +Shadow pages contain the following information: + role.level: + The level in the shadow paging hierarchy that this shadow page belongs to. + 1=4k sptes, 2=2M sptes, 3=1G sptes, etc. + role.direct: + If set, leaf sptes reachable from this page are for a linear range. + Examples include real mode translation, large guest pages backed by small + host pages, and gpa->hpa translations when NPT or EPT is active. + The linear range starts at (gfn << PAGE_SHIFT) and its size is determined + by role.level (2MB for first level, 1GB for second level, 0.5TB for third + level, 256TB for fourth level) + If clear, this page corresponds to a guest page table denoted by the gfn + field. + role.quadrant: + When role.has_4_byte_gpte=1, the guest uses 32-bit gptes while the host uses 64-bit + sptes. That means a guest page table contains more ptes than the host, + so multiple shadow pages are needed to shadow one guest page. + For first-level shadow pages, role.quadrant can be 0 or 1 and denotes the + first or second 512-gpte block in the guest page table. For second-level + page tables, each 32-bit gpte is converted to two 64-bit sptes + (since each first-level guest page is shadowed by two first-level + shadow pages) so role.quadrant takes values in the range 0..3. Each + quadrant maps 1GB virtual address space. + role.access: + Inherited guest access permissions from the parent ptes in the form uwx. + Note execute permission is positive, not negative. + role.invalid: + The page is invalid and should not be used. It is a root page that is + currently pinned (by a cpu hardware register pointing to it); once it is + unpinned it will be destroyed. + role.has_4_byte_gpte: + Reflects the size of the guest PTE for which the page is valid, i.e. '0' + if direct map or 64-bit gptes are in use, '1' if 32-bit gptes are in use. + role.efer_nx: + Contains the value of efer.nx for which the page is valid. + role.cr0_wp: + Contains the value of cr0.wp for which the page is valid. + role.smep_andnot_wp: + Contains the value of cr4.smep && !cr0.wp for which the page is valid + (pages for which this is true are different from other pages; see the + treatment of cr0.wp=0 below). + role.smap_andnot_wp: + Contains the value of cr4.smap && !cr0.wp for which the page is valid + (pages for which this is true are different from other pages; see the + treatment of cr0.wp=0 below). + role.smm: + Is 1 if the page is valid in system management mode. This field + determines which of the kvm_memslots array was used to build this + shadow page; it is also used to go back from a struct kvm_mmu_page + to a memslot, through the kvm_memslots_for_spte_role macro and + __gfn_to_memslot. + role.ad_disabled: + Is 1 if the MMU instance cannot use A/D bits. EPT did not have A/D + bits before Haswell; shadow EPT page tables also cannot use A/D bits + if the L1 hypervisor does not enable them. + gfn: + Either the guest page table containing the translations shadowed by this + page, or the base page frame for linear translations. See role.direct. + spt: + A pageful of 64-bit sptes containing the translations for this page. + Accessed by both kvm and hardware. + The page pointed to by spt will have its page->private pointing back + at the shadow page structure. + sptes in spt point either at guest pages, or at lower-level shadow pages. + Specifically, if sp1 and sp2 are shadow pages, then sp1->spt[n] may point + at __pa(sp2->spt). sp2 will point back at sp1 through parent_pte. + The spt array forms a DAG structure with the shadow page as a node, and + guest pages as leaves. + gfns: + An array of 512 guest frame numbers, one for each present pte. Used to + perform a reverse map from a pte to a gfn. When role.direct is set, any + element of this array can be calculated from the gfn field when used, in + this case, the array of gfns is not allocated. See role.direct and gfn. + root_count: + A counter keeping track of how many hardware registers (guest cr3 or + pdptrs) are now pointing at the page. While this counter is nonzero, the + page cannot be destroyed. See role.invalid. + parent_ptes: + The reverse mapping for the pte/ptes pointing at this page's spt. If + parent_ptes bit 0 is zero, only one spte points at this page and + parent_ptes points at this single spte, otherwise, there exists multiple + sptes pointing at this page and (parent_ptes & ~0x1) points at a data + structure with a list of parent sptes. + unsync: + If true, then the translations in this page may not match the guest's + translation. This is equivalent to the state of the tlb when a pte is + changed but before the tlb entry is flushed. Accordingly, unsync ptes + are synchronized when the guest executes invlpg or flushes its tlb by + other means. Valid for leaf pages. + unsync_children: + How many sptes in the page point at pages that are unsync (or have + unsynchronized children). + unsync_child_bitmap: + A bitmap indicating which sptes in spt point (directly or indirectly) at + pages that may be unsynchronized. Used to quickly locate all unsychronized + pages reachable from a given page. + clear_spte_count: + Only present on 32-bit hosts, where a 64-bit spte cannot be written + atomically. The reader uses this while running out of the MMU lock + to detect in-progress updates and retry them until the writer has + finished the write. + write_flooding_count: + A guest may write to a page table many times, causing a lot of + emulations if the page needs to be write-protected (see "Synchronized + and unsynchronized pages" below). Leaf pages can be unsynchronized + so that they do not trigger frequent emulation, but this is not + possible for non-leafs. This field counts the number of emulations + since the last time the page table was actually used; if emulation + is triggered too frequently on this page, KVM will unmap the page + to avoid emulation in the future. + +Reverse map +=========== + +The mmu maintains a reverse mapping whereby all ptes mapping a page can be +reached given its gfn. This is used, for example, when swapping out a page. + +Synchronized and unsynchronized pages +===================================== + +The guest uses two events to synchronize its tlb and page tables: tlb flushes +and page invalidations (invlpg). + +A tlb flush means that we need to synchronize all sptes reachable from the +guest's cr3. This is expensive, so we keep all guest page tables write +protected, and synchronize sptes to gptes when a gpte is written. + +A special case is when a guest page table is reachable from the current +guest cr3. In this case, the guest is obliged to issue an invlpg instruction +before using the translation. We take advantage of that by removing write +protection from the guest page, and allowing the guest to modify it freely. +We synchronize modified gptes when the guest invokes invlpg. This reduces +the amount of emulation we have to do when the guest modifies multiple gptes, +or when the a guest page is no longer used as a page table and is used for +random guest data. + +As a side effect we have to resynchronize all reachable unsynchronized shadow +pages on a tlb flush. + + +Reaction to events +================== + +- guest page fault (or npt page fault, or ept violation) + +This is the most complicated event. The cause of a page fault can be: + + - a true guest fault (the guest translation won't allow the access) (*) + - access to a missing translation + - access to a protected translation + - when logging dirty pages, memory is write protected + - synchronized shadow pages are write protected (*) + - access to untranslatable memory (mmio) + + (*) not applicable in direct mode + +Handling a page fault is performed as follows: + + - if the RSV bit of the error code is set, the page fault is caused by guest + accessing MMIO and cached MMIO information is available. + + - walk shadow page table + - check for valid generation number in the spte (see "Fast invalidation of + MMIO sptes" below) + - cache the information to vcpu->arch.mmio_gva, vcpu->arch.mmio_access and + vcpu->arch.mmio_gfn, and call the emulator + + - If both P bit and R/W bit of error code are set, this could possibly + be handled as a "fast page fault" (fixed without taking the MMU lock). See + the description in Documentation/virt/kvm/locking.rst. + + - if needed, walk the guest page tables to determine the guest translation + (gva->gpa or ngpa->gpa) + + - if permissions are insufficient, reflect the fault back to the guest + + - determine the host page + + - if this is an mmio request, there is no host page; cache the info to + vcpu->arch.mmio_gva, vcpu->arch.mmio_access and vcpu->arch.mmio_gfn + + - walk the shadow page table to find the spte for the translation, + instantiating missing intermediate page tables as necessary + + - If this is an mmio request, cache the mmio info to the spte and set some + reserved bit on the spte (see callers of kvm_mmu_set_mmio_spte_mask) + + - try to unsynchronize the page + + - if successful, we can let the guest continue and modify the gpte + + - emulate the instruction + + - if failed, unshadow the page and let the guest continue + + - update any translations that were modified by the instruction + +invlpg handling: + + - walk the shadow page hierarchy and drop affected translations + - try to reinstantiate the indicated translation in the hope that the + guest will use it in the near future + +Guest control register updates: + +- mov to cr3 + + - look up new shadow roots + - synchronize newly reachable shadow pages + +- mov to cr0/cr4/efer + + - set up mmu context for new paging mode + - look up new shadow roots + - synchronize newly reachable shadow pages + +Host translation updates: + + - mmu notifier called with updated hva + - look up affected sptes through reverse map + - drop (or update) translations + +Emulating cr0.wp +================ + +If tdp is not enabled, the host must keep cr0.wp=1 so page write protection +works for the guest kernel, not guest guest userspace. When the guest +cr0.wp=1, this does not present a problem. However when the guest cr0.wp=0, +we cannot map the permissions for gpte.u=1, gpte.w=0 to any spte (the +semantics require allowing any guest kernel access plus user read access). + +We handle this by mapping the permissions to two possible sptes, depending +on fault type: + +- kernel write fault: spte.u=0, spte.w=1 (allows full kernel access, + disallows user access) +- read fault: spte.u=1, spte.w=0 (allows full read access, disallows kernel + write access) + +(user write faults generate a #PF) + +In the first case there are two additional complications: + +- if CR4.SMEP is enabled: since we've turned the page into a kernel page, + the kernel may now execute it. We handle this by also setting spte.nx. + If we get a user fetch or read fault, we'll change spte.u=1 and + spte.nx=gpte.nx back. For this to work, KVM forces EFER.NX to 1 when + shadow paging is in use. +- if CR4.SMAP is disabled: since the page has been changed to a kernel + page, it can not be reused when CR4.SMAP is enabled. We set + CR4.SMAP && !CR0.WP into shadow page's role to avoid this case. Note, + here we do not care the case that CR4.SMAP is enabled since KVM will + directly inject #PF to guest due to failed permission check. + +To prevent an spte that was converted into a kernel page with cr0.wp=0 +from being written by the kernel after cr0.wp has changed to 1, we make +the value of cr0.wp part of the page role. This means that an spte created +with one value of cr0.wp cannot be used when cr0.wp has a different value - +it will simply be missed by the shadow page lookup code. A similar issue +exists when an spte created with cr0.wp=0 and cr4.smep=0 is used after +changing cr4.smep to 1. To avoid this, the value of !cr0.wp && cr4.smep +is also made a part of the page role. + +Large pages +=========== + +The mmu supports all combinations of large and small guest and host pages. +Supported page sizes include 4k, 2M, 4M, and 1G. 4M pages are treated as +two separate 2M pages, on both guest and host, since the mmu always uses PAE +paging. + +To instantiate a large spte, four constraints must be satisfied: + +- the spte must point to a large host page +- the guest pte must be a large pte of at least equivalent size (if tdp is + enabled, there is no guest pte and this condition is satisfied) +- if the spte will be writeable, the large page frame may not overlap any + write-protected pages +- the guest page must be wholly contained by a single memory slot + +To check the last two conditions, the mmu maintains a ->disallow_lpage set of +arrays for each memory slot and large page size. Every write protected page +causes its disallow_lpage to be incremented, thus preventing instantiation of +a large spte. The frames at the end of an unaligned memory slot have +artificially inflated ->disallow_lpages so they can never be instantiated. + +Fast invalidation of MMIO sptes +=============================== + +As mentioned in "Reaction to events" above, kvm will cache MMIO +information in leaf sptes. When a new memslot is added or an existing +memslot is changed, this information may become stale and needs to be +invalidated. This also needs to hold the MMU lock while walking all +shadow pages, and is made more scalable with a similar technique. + +MMIO sptes have a few spare bits, which are used to store a +generation number. The global generation number is stored in +kvm_memslots(kvm)->generation, and increased whenever guest memory info +changes. + +When KVM finds an MMIO spte, it checks the generation number of the spte. +If the generation number of the spte does not equal the global generation +number, it will ignore the cached MMIO information and handle the page +fault through the slow path. + +Since only 18 bits are used to store generation-number on mmio spte, all +pages are zapped when there is an overflow. + +Unfortunately, a single memory access might access kvm_memslots(kvm) multiple +times, the last one happening when the generation number is retrieved and +stored into the MMIO spte. Thus, the MMIO spte might be created based on +out-of-date information, but with an up-to-date generation number. + +To avoid this, the generation number is incremented again after synchronize_srcu +returns; thus, bit 63 of kvm_memslots(kvm)->generation set to 1 only during a +memslot update, while some SRCU readers might be using the old copy. We do not +want to use an MMIO sptes created with an odd generation number, and we can do +this without losing a bit in the MMIO spte. The "update in-progress" bit of the +generation is not stored in MMIO spte, and is so is implicitly zero when the +generation is extracted out of the spte. If KVM is unlucky and creates an MMIO +spte while an update is in-progress, the next access to the spte will always be +a cache miss. For example, a subsequent access during the update window will +miss due to the in-progress flag diverging, while an access after the update +window closes will have a higher generation number (as compared to the spte). + + +Further reading +=============== + +- NPT presentation from KVM Forum 2008 + https://www.linux-kvm.org/images/c/c8/KvmForum2008%24kdf2008_21.pdf diff --git a/Documentation/virt/kvm/x86/msr.rst b/Documentation/virt/kvm/x86/msr.rst new file mode 100644 index 000000000000..9315fc385fb0 --- /dev/null +++ b/Documentation/virt/kvm/x86/msr.rst @@ -0,0 +1,391 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================= +KVM-specific MSRs +================= + +:Author: Glauber Costa , Red Hat Inc, 2010 + +KVM makes use of some custom MSRs to service some requests. + +Custom MSRs have a range reserved for them, that goes from +0x4b564d00 to 0x4b564dff. There are MSRs outside this area, +but they are deprecated and their use is discouraged. + +Custom MSR list +--------------- + +The current supported Custom MSR list is: + +MSR_KVM_WALL_CLOCK_NEW: + 0x4b564d00 + +data: + 4-byte alignment physical address of a memory area which must be + in guest RAM. This memory is expected to hold a copy of the following + structure:: + + struct pvclock_wall_clock { + u32 version; + u32 sec; + u32 nsec; + } __attribute__((__packed__)); + + whose data will be filled in by the hypervisor. The hypervisor is only + guaranteed to update this data at the moment of MSR write. + Users that want to reliably query this information more than once have + to write more than once to this MSR. Fields have the following meanings: + + version: + guest has to check version before and after grabbing + time information and check that they are both equal and even. + An odd version indicates an in-progress update. + + sec: + number of seconds for wallclock at time of boot. + + nsec: + number of nanoseconds for wallclock at time of boot. + + In order to get the current wallclock time, the system_time from + MSR_KVM_SYSTEM_TIME_NEW needs to be added. + + Note that although MSRs are per-CPU entities, the effect of this + particular MSR is global. + + Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid + leaf prior to usage. + +MSR_KVM_SYSTEM_TIME_NEW: + 0x4b564d01 + +data: + 4-byte aligned physical address of a memory area which must be in + guest RAM, plus an enable bit in bit 0. This memory is expected to hold + a copy of the following structure:: + + struct pvclock_vcpu_time_info { + u32 version; + u32 pad0; + u64 tsc_timestamp; + u64 system_time; + u32 tsc_to_system_mul; + s8 tsc_shift; + u8 flags; + u8 pad[2]; + } __attribute__((__packed__)); /* 32 bytes */ + + whose data will be filled in by the hypervisor periodically. Only one + write, or registration, is needed for each VCPU. The interval between + updates of this structure is arbitrary and implementation-dependent. + The hypervisor may update this structure at any time it sees fit until + anything with bit0 == 0 is written to it. + + Fields have the following meanings: + + version: + guest has to check version before and after grabbing + time information and check that they are both equal and even. + An odd version indicates an in-progress update. + + tsc_timestamp: + the tsc value at the current VCPU at the time + of the update of this structure. Guests can subtract this value + from current tsc to derive a notion of elapsed time since the + structure update. + + system_time: + a host notion of monotonic time, including sleep + time at the time this structure was last updated. Unit is + nanoseconds. + + tsc_to_system_mul: + multiplier to be used when converting + tsc-related quantity to nanoseconds + + tsc_shift: + shift to be used when converting tsc-related + quantity to nanoseconds. This shift will ensure that + multiplication with tsc_to_system_mul does not overflow. + A positive value denotes a left shift, a negative value + a right shift. + + The conversion from tsc to nanoseconds involves an additional + right shift by 32 bits. With this information, guests can + derive per-CPU time by doing:: + + time = (current_tsc - tsc_timestamp) + if (tsc_shift >= 0) + time <<= tsc_shift; + else + time >>= -tsc_shift; + time = (time * tsc_to_system_mul) >> 32 + time = time + system_time + + flags: + bits in this field indicate extended capabilities + coordinated between the guest and the hypervisor. Availability + of specific flags has to be checked in 0x40000001 cpuid leaf. + Current flags are: + + + +-----------+--------------+----------------------------------+ + | flag bit | cpuid bit | meaning | + +-----------+--------------+----------------------------------+ + | | | time measures taken across | + | 0 | 24 | multiple cpus are guaranteed to | + | | | be monotonic | + +-----------+--------------+----------------------------------+ + | | | guest vcpu has been paused by | + | 1 | N/A | the host | + | | | See 4.70 in api.txt | + +-----------+--------------+----------------------------------+ + + Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid + leaf prior to usage. + + +MSR_KVM_WALL_CLOCK: + 0x11 + +data and functioning: + same as MSR_KVM_WALL_CLOCK_NEW. Use that instead. + + This MSR falls outside the reserved KVM range and may be removed in the + future. Its usage is deprecated. + + Availability of this MSR must be checked via bit 0 in 0x4000001 cpuid + leaf prior to usage. + +MSR_KVM_SYSTEM_TIME: + 0x12 + +data and functioning: + same as MSR_KVM_SYSTEM_TIME_NEW. Use that instead. + + This MSR falls outside the reserved KVM range and may be removed in the + future. Its usage is deprecated. + + Availability of this MSR must be checked via bit 0 in 0x4000001 cpuid + leaf prior to usage. + + The suggested algorithm for detecting kvmclock presence is then:: + + if (!kvm_para_available()) /* refer to cpuid.txt */ + return NON_PRESENT; + + flags = cpuid_eax(0x40000001); + if (flags & 3) { + msr_kvm_system_time = MSR_KVM_SYSTEM_TIME_NEW; + msr_kvm_wall_clock = MSR_KVM_WALL_CLOCK_NEW; + return PRESENT; + } else if (flags & 0) { + msr_kvm_system_time = MSR_KVM_SYSTEM_TIME; + msr_kvm_wall_clock = MSR_KVM_WALL_CLOCK; + return PRESENT; + } else + return NON_PRESENT; + +MSR_KVM_ASYNC_PF_EN: + 0x4b564d02 + +data: + Asynchronous page fault (APF) control MSR. + + Bits 63-6 hold 64-byte aligned physical address of a 64 byte memory area + which must be in guest RAM and must be zeroed. This memory is expected + to hold a copy of the following structure:: + + struct kvm_vcpu_pv_apf_data { + /* Used for 'page not present' events delivered via #PF */ + __u32 flags; + + /* Used for 'page ready' events delivered via interrupt notification */ + __u32 token; + + __u8 pad[56]; + __u32 enabled; + }; + + Bits 5-4 of the MSR are reserved and should be zero. Bit 0 is set to 1 + when asynchronous page faults are enabled on the vcpu, 0 when disabled. + Bit 1 is 1 if asynchronous page faults can be injected when vcpu is in + cpl == 0. Bit 2 is 1 if asynchronous page faults are delivered to L1 as + #PF vmexits. Bit 2 can be set only if KVM_FEATURE_ASYNC_PF_VMEXIT is + present in CPUID. Bit 3 enables interrupt based delivery of 'page ready' + events. Bit 3 can only be set if KVM_FEATURE_ASYNC_PF_INT is present in + CPUID. + + 'Page not present' events are currently always delivered as synthetic + #PF exception. During delivery of these events APF CR2 register contains + a token that will be used to notify the guest when missing page becomes + available. Also, to make it possible to distinguish between real #PF and + APF, first 4 bytes of 64 byte memory location ('flags') will be written + to by the hypervisor at the time of injection. Only first bit of 'flags' + is currently supported, when set, it indicates that the guest is dealing + with asynchronous 'page not present' event. If during a page fault APF + 'flags' is '0' it means that this is regular page fault. Guest is + supposed to clear 'flags' when it is done handling #PF exception so the + next event can be delivered. + + Note, since APF 'page not present' events use the same exception vector + as regular page fault, guest must reset 'flags' to '0' before it does + something that can generate normal page fault. + + Bytes 5-7 of 64 byte memory location ('token') will be written to by the + hypervisor at the time of APF 'page ready' event injection. The content + of these bytes is a token which was previously delivered as 'page not + present' event. The event indicates the page in now available. Guest is + supposed to write '0' to 'token' when it is done handling 'page ready' + event and to write 1' to MSR_KVM_ASYNC_PF_ACK after clearing the location; + writing to the MSR forces KVM to re-scan its queue and deliver the next + pending notification. + + Note, MSR_KVM_ASYNC_PF_INT MSR specifying the interrupt vector for 'page + ready' APF delivery needs to be written to before enabling APF mechanism + in MSR_KVM_ASYNC_PF_EN or interrupt #0 can get injected. The MSR is + available if KVM_FEATURE_ASYNC_PF_INT is present in CPUID. + + Note, previously, 'page ready' events were delivered via the same #PF + exception as 'page not present' events but this is now deprecated. If + bit 3 (interrupt based delivery) is not set APF events are not delivered. + + If APF is disabled while there are outstanding APFs, they will + not be delivered. + + Currently 'page ready' APF events will be always delivered on the + same vcpu as 'page not present' event was, but guest should not rely on + that. + +MSR_KVM_STEAL_TIME: + 0x4b564d03 + +data: + 64-byte alignment physical address of a memory area which must be + in guest RAM, plus an enable bit in bit 0. This memory is expected to + hold a copy of the following structure:: + + struct kvm_steal_time { + __u64 steal; + __u32 version; + __u32 flags; + __u8 preempted; + __u8 u8_pad[3]; + __u32 pad[11]; + } + + whose data will be filled in by the hypervisor periodically. Only one + write, or registration, is needed for each VCPU. The interval between + updates of this structure is arbitrary and implementation-dependent. + The hypervisor may update this structure at any time it sees fit until + anything with bit0 == 0 is written to it. Guest is required to make sure + this structure is initialized to zero. + + Fields have the following meanings: + + version: + a sequence counter. In other words, guest has to check + this field before and after grabbing time information and make + sure they are both equal and even. An odd version indicates an + in-progress update. + + flags: + At this point, always zero. May be used to indicate + changes in this structure in the future. + + steal: + the amount of time in which this vCPU did not run, in + nanoseconds. Time during which the vcpu is idle, will not be + reported as steal time. + + preempted: + indicate the vCPU who owns this struct is running or + not. Non-zero values mean the vCPU has been preempted. Zero + means the vCPU is not preempted. NOTE, it is always zero if the + the hypervisor doesn't support this field. + +MSR_KVM_EOI_EN: + 0x4b564d04 + +data: + Bit 0 is 1 when PV end of interrupt is enabled on the vcpu; 0 + when disabled. Bit 1 is reserved and must be zero. When PV end of + interrupt is enabled (bit 0 set), bits 63-2 hold a 4-byte aligned + physical address of a 4 byte memory area which must be in guest RAM and + must be zeroed. + + The first, least significant bit of 4 byte memory location will be + written to by the hypervisor, typically at the time of interrupt + injection. Value of 1 means that guest can skip writing EOI to the apic + (using MSR or MMIO write); instead, it is sufficient to signal + EOI by clearing the bit in guest memory - this location will + later be polled by the hypervisor. + Value of 0 means that the EOI write is required. + + It is always safe for the guest to ignore the optimization and perform + the APIC EOI write anyway. + + Hypervisor is guaranteed to only modify this least + significant bit while in the current VCPU context, this means that + guest does not need to use either lock prefix or memory ordering + primitives to synchronise with the hypervisor. + + However, hypervisor can set and clear this memory bit at any time: + therefore to make sure hypervisor does not interrupt the + guest and clear the least significant bit in the memory area + in the window between guest testing it to detect + whether it can skip EOI apic write and between guest + clearing it to signal EOI to the hypervisor, + guest must both read the least significant bit in the memory area and + clear it using a single CPU instruction, such as test and clear, or + compare and exchange. + +MSR_KVM_POLL_CONTROL: + 0x4b564d05 + + Control host-side polling. + +data: + Bit 0 enables (1) or disables (0) host-side HLT polling logic. + + KVM guests can request the host not to poll on HLT, for example if + they are performing polling themselves. + +MSR_KVM_ASYNC_PF_INT: + 0x4b564d06 + +data: + Second asynchronous page fault (APF) control MSR. + + Bits 0-7: APIC vector for delivery of 'page ready' APF events. + Bits 8-63: Reserved + + Interrupt vector for asynchnonous 'page ready' notifications delivery. + The vector has to be set up before asynchronous page fault mechanism + is enabled in MSR_KVM_ASYNC_PF_EN. The MSR is only available if + KVM_FEATURE_ASYNC_PF_INT is present in CPUID. + +MSR_KVM_ASYNC_PF_ACK: + 0x4b564d07 + +data: + Asynchronous page fault (APF) acknowledgment. + + When the guest is done processing 'page ready' APF event and 'token' + field in 'struct kvm_vcpu_pv_apf_data' is cleared it is supposed to + write '1' to bit 0 of the MSR, this causes the host to re-scan its queue + and check if there are more notifications pending. The MSR is available + if KVM_FEATURE_ASYNC_PF_INT is present in CPUID. + +MSR_KVM_MIGRATION_CONTROL: + 0x4b564d08 + +data: + This MSR is available if KVM_FEATURE_MIGRATION_CONTROL is present in + CPUID. Bit 0 represents whether live migration of the guest is allowed. + + When a guest is started, bit 0 will be 0 if the guest has encrypted + memory and 1 if the guest does not have encrypted memory. If the + guest is communicating page encryption status to the host using the + ``KVM_HC_MAP_GPA_RANGE`` hypercall, it can set bit 0 in this MSR to + allow live migration of the guest. diff --git a/Documentation/virt/kvm/x86/nested-vmx.rst b/Documentation/virt/kvm/x86/nested-vmx.rst new file mode 100644 index 000000000000..ac2095d41f02 --- /dev/null +++ b/Documentation/virt/kvm/x86/nested-vmx.rst @@ -0,0 +1,244 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========== +Nested VMX +========== + +Overview +--------- + +On Intel processors, KVM uses Intel's VMX (Virtual-Machine eXtensions) +to easily and efficiently run guest operating systems. Normally, these guests +*cannot* themselves be hypervisors running their own guests, because in VMX, +guests cannot use VMX instructions. + +The "Nested VMX" feature adds this missing capability - of running guest +hypervisors (which use VMX) with their own nested guests. It does so by +allowing a guest to use VMX instructions, and correctly and efficiently +emulating them using the single level of VMX available in the hardware. + +We describe in much greater detail the theory behind the nested VMX feature, +its implementation and its performance characteristics, in the OSDI 2010 paper +"The Turtles Project: Design and Implementation of Nested Virtualization", +available at: + + https://www.usenix.org/events/osdi10/tech/full_papers/Ben-Yehuda.pdf + + +Terminology +----------- + +Single-level virtualization has two levels - the host (KVM) and the guests. +In nested virtualization, we have three levels: The host (KVM), which we call +L0, the guest hypervisor, which we call L1, and its nested guest, which we +call L2. + + +Running nested VMX +------------------ + +The nested VMX feature is enabled by default since Linux kernel v4.20. For +older Linux kernel, it can be enabled by giving the "nested=1" option to the +kvm-intel module. + + +No modifications are required to user space (qemu). However, qemu's default +emulated CPU type (qemu64) does not list the "VMX" CPU feature, so it must be +explicitly enabled, by giving qemu one of the following options: + + - cpu host (emulated CPU has all features of the real CPU) + + - cpu qemu64,+vmx (add just the vmx feature to a named CPU type) + + +ABIs +---- + +Nested VMX aims to present a standard and (eventually) fully-functional VMX +implementation for the a guest hypervisor to use. As such, the official +specification of the ABI that it provides is Intel's VMX specification, +namely volume 3B of their "Intel 64 and IA-32 Architectures Software +Developer's Manual". Not all of VMX's features are currently fully supported, +but the goal is to eventually support them all, starting with the VMX features +which are used in practice by popular hypervisors (KVM and others). + +As a VMX implementation, nested VMX presents a VMCS structure to L1. +As mandated by the spec, other than the two fields revision_id and abort, +this structure is *opaque* to its user, who is not supposed to know or care +about its internal structure. Rather, the structure is accessed through the +VMREAD and VMWRITE instructions. +Still, for debugging purposes, KVM developers might be interested to know the +internals of this structure; This is struct vmcs12 from arch/x86/kvm/vmx.c. + +The name "vmcs12" refers to the VMCS that L1 builds for L2. In the code we +also have "vmcs01", the VMCS that L0 built for L1, and "vmcs02" is the VMCS +which L0 builds to actually run L2 - how this is done is explained in the +aforementioned paper. + +For convenience, we repeat the content of struct vmcs12 here. If the internals +of this structure changes, this can break live migration across KVM versions. +VMCS12_REVISION (from vmx.c) should be changed if struct vmcs12 or its inner +struct shadow_vmcs is ever changed. + +:: + + typedef u64 natural_width; + struct __packed vmcs12 { + /* According to the Intel spec, a VMCS region must start with + * these two user-visible fields */ + u32 revision_id; + u32 abort; + + u32 launch_state; /* set to 0 by VMCLEAR, to 1 by VMLAUNCH */ + u32 padding[7]; /* room for future expansion */ + + u64 io_bitmap_a; + u64 io_bitmap_b; + u64 msr_bitmap; + u64 vm_exit_msr_store_addr; + u64 vm_exit_msr_load_addr; + u64 vm_entry_msr_load_addr; + u64 tsc_offset; + u64 virtual_apic_page_addr; + u64 apic_access_addr; + u64 ept_pointer; + u64 guest_physical_address; + u64 vmcs_link_pointer; + u64 guest_ia32_debugctl; + u64 guest_ia32_pat; + u64 guest_ia32_efer; + u64 guest_pdptr0; + u64 guest_pdptr1; + u64 guest_pdptr2; + u64 guest_pdptr3; + u64 host_ia32_pat; + u64 host_ia32_efer; + u64 padding64[8]; /* room for future expansion */ + natural_width cr0_guest_host_mask; + natural_width cr4_guest_host_mask; + natural_width cr0_read_shadow; + natural_width cr4_read_shadow; + natural_width dead_space[4]; /* Last remnants of cr3_target_value[0-3]. */ + natural_width exit_qualification; + natural_width guest_linear_address; + natural_width guest_cr0; + natural_width guest_cr3; + natural_width guest_cr4; + natural_width guest_es_base; + natural_width guest_cs_base; + natural_width guest_ss_base; + natural_width guest_ds_base; + natural_width guest_fs_base; + natural_width guest_gs_base; + natural_width guest_ldtr_base; + natural_width guest_tr_base; + natural_width guest_gdtr_base; + natural_width guest_idtr_base; + natural_width guest_dr7; + natural_width guest_rsp; + natural_width guest_rip; + natural_width guest_rflags; + natural_width guest_pending_dbg_exceptions; + natural_width guest_sysenter_esp; + natural_width guest_sysenter_eip; + natural_width host_cr0; + natural_width host_cr3; + natural_width host_cr4; + natural_width host_fs_base; + natural_width host_gs_base; + natural_width host_tr_base; + natural_width host_gdtr_base; + natural_width host_idtr_base; + natural_width host_ia32_sysenter_esp; + natural_width host_ia32_sysenter_eip; + natural_width host_rsp; + natural_width host_rip; + natural_width paddingl[8]; /* room for future expansion */ + u32 pin_based_vm_exec_control; + u32 cpu_based_vm_exec_control; + u32 exception_bitmap; + u32 page_fault_error_code_mask; + u32 page_fault_error_code_match; + u32 cr3_target_count; + u32 vm_exit_controls; + u32 vm_exit_msr_store_count; + u32 vm_exit_msr_load_count; + u32 vm_entry_controls; + u32 vm_entry_msr_load_count; + u32 vm_entry_intr_info_field; + u32 vm_entry_exception_error_code; + u32 vm_entry_instruction_len; + u32 tpr_threshold; + u32 secondary_vm_exec_control; + u32 vm_instruction_error; + u32 vm_exit_reason; + u32 vm_exit_intr_info; + u32 vm_exit_intr_error_code; + u32 idt_vectoring_info_field; + u32 idt_vectoring_error_code; + u32 vm_exit_instruction_len; + u32 vmx_instruction_info; + u32 guest_es_limit; + u32 guest_cs_limit; + u32 guest_ss_limit; + u32 guest_ds_limit; + u32 guest_fs_limit; + u32 guest_gs_limit; + u32 guest_ldtr_limit; + u32 guest_tr_limit; + u32 guest_gdtr_limit; + u32 guest_idtr_limit; + u32 guest_es_ar_bytes; + u32 guest_cs_ar_bytes; + u32 guest_ss_ar_bytes; + u32 guest_ds_ar_bytes; + u32 guest_fs_ar_bytes; + u32 guest_gs_ar_bytes; + u32 guest_ldtr_ar_bytes; + u32 guest_tr_ar_bytes; + u32 guest_interruptibility_info; + u32 guest_activity_state; + u32 guest_sysenter_cs; + u32 host_ia32_sysenter_cs; + u32 padding32[8]; /* room for future expansion */ + u16 virtual_processor_id; + u16 guest_es_selector; + u16 guest_cs_selector; + u16 guest_ss_selector; + u16 guest_ds_selector; + u16 guest_fs_selector; + u16 guest_gs_selector; + u16 guest_ldtr_selector; + u16 guest_tr_selector; + u16 host_es_selector; + u16 host_cs_selector; + u16 host_ss_selector; + u16 host_ds_selector; + u16 host_fs_selector; + u16 host_gs_selector; + u16 host_tr_selector; + }; + + +Authors +------- + +These patches were written by: + - Abel Gordon, abelg il.ibm.com + - Nadav Har'El, nyh il.ibm.com + - Orit Wasserman, oritw il.ibm.com + - Ben-Ami Yassor, benami il.ibm.com + - Muli Ben-Yehuda, muli il.ibm.com + +With contributions by: + - Anthony Liguori, aliguori us.ibm.com + - Mike Day, mdday us.ibm.com + - Michael Factor, factor il.ibm.com + - Zvi Dubitzky, dubi il.ibm.com + +And valuable reviews by: + - Avi Kivity, avi redhat.com + - Gleb Natapov, gleb redhat.com + - Marcelo Tosatti, mtosatti redhat.com + - Kevin Tian, kevin.tian intel.com + - and others. diff --git a/Documentation/virt/kvm/x86/running-nested-guests.rst b/Documentation/virt/kvm/x86/running-nested-guests.rst new file mode 100644 index 000000000000..bd70c69468ae --- /dev/null +++ b/Documentation/virt/kvm/x86/running-nested-guests.rst @@ -0,0 +1,276 @@ +============================== +Running nested guests with KVM +============================== + +A nested guest is the ability to run a guest inside another guest (it +can be KVM-based or a different hypervisor). The straightforward +example is a KVM guest that in turn runs on a KVM guest (the rest of +this document is built on this example):: + + .----------------. .----------------. + | | | | + | L2 | | L2 | + | (Nested Guest) | | (Nested Guest) | + | | | | + |----------------'--'----------------| + | | + | L1 (Guest Hypervisor) | + | KVM (/dev/kvm) | + | | + .------------------------------------------------------. + | L0 (Host Hypervisor) | + | KVM (/dev/kvm) | + |------------------------------------------------------| + | Hardware (with virtualization extensions) | + '------------------------------------------------------' + +Terminology: + +- L0 – level-0; the bare metal host, running KVM + +- L1 – level-1 guest; a VM running on L0; also called the "guest + hypervisor", as it itself is capable of running KVM. + +- L2 – level-2 guest; a VM running on L1, this is the "nested guest" + +.. note:: The above diagram is modelled after the x86 architecture; + s390x, ppc64 and other architectures are likely to have + a different design for nesting. + + For example, s390x always has an LPAR (LogicalPARtition) + hypervisor running on bare metal, adding another layer and + resulting in at least four levels in a nested setup — L0 (bare + metal, running the LPAR hypervisor), L1 (host hypervisor), L2 + (guest hypervisor), L3 (nested guest). + + This document will stick with the three-level terminology (L0, + L1, and L2) for all architectures; and will largely focus on + x86. + + +Use Cases +--------- + +There are several scenarios where nested KVM can be useful, to name a +few: + +- As a developer, you want to test your software on different operating + systems (OSes). Instead of renting multiple VMs from a Cloud + Provider, using nested KVM lets you rent a large enough "guest + hypervisor" (level-1 guest). This in turn allows you to create + multiple nested guests (level-2 guests), running different OSes, on + which you can develop and test your software. + +- Live migration of "guest hypervisors" and their nested guests, for + load balancing, disaster recovery, etc. + +- VM image creation tools (e.g. ``virt-install``, etc) often run + their own VM, and users expect these to work inside a VM. + +- Some OSes use virtualization internally for security (e.g. to let + applications run safely in isolation). + + +Enabling "nested" (x86) +----------------------- + +From Linux kernel v4.20 onwards, the ``nested`` KVM parameter is enabled +by default for Intel and AMD. (Though your Linux distribution might +override this default.) + +In case you are running a Linux kernel older than v4.19, to enable +nesting, set the ``nested`` KVM module parameter to ``Y`` or ``1``. To +persist this setting across reboots, you can add it in a config file, as +shown below: + +1. On the bare metal host (L0), list the kernel modules and ensure that + the KVM modules:: + + $ lsmod | grep -i kvm + kvm_intel 133627 0 + kvm 435079 1 kvm_intel + +2. Show information for ``kvm_intel`` module:: + + $ modinfo kvm_intel | grep -i nested + parm: nested:bool + +3. For the nested KVM configuration to persist across reboots, place the + below in ``/etc/modprobed/kvm_intel.conf`` (create the file if it + doesn't exist):: + + $ cat /etc/modprobe.d/kvm_intel.conf + options kvm-intel nested=y + +4. Unload and re-load the KVM Intel module:: + + $ sudo rmmod kvm-intel + $ sudo modprobe kvm-intel + +5. Verify if the ``nested`` parameter for KVM is enabled:: + + $ cat /sys/module/kvm_intel/parameters/nested + Y + +For AMD hosts, the process is the same as above, except that the module +name is ``kvm-amd``. + + +Additional nested-related kernel parameters (x86) +------------------------------------------------- + +If your hardware is sufficiently advanced (Intel Haswell processor or +higher, which has newer hardware virt extensions), the following +additional features will also be enabled by default: "Shadow VMCS +(Virtual Machine Control Structure)", APIC Virtualization on your bare +metal host (L0). Parameters for Intel hosts:: + + $ cat /sys/module/kvm_intel/parameters/enable_shadow_vmcs + Y + + $ cat /sys/module/kvm_intel/parameters/enable_apicv + Y + + $ cat /sys/module/kvm_intel/parameters/ept + Y + +.. note:: If you suspect your L2 (i.e. nested guest) is running slower, + ensure the above are enabled (particularly + ``enable_shadow_vmcs`` and ``ept``). + + +Starting a nested guest (x86) +----------------------------- + +Once your bare metal host (L0) is configured for nesting, you should be +able to start an L1 guest with:: + + $ qemu-kvm -cpu host [...] + +The above will pass through the host CPU's capabilities as-is to the +gues); or for better live migration compatibility, use a named CPU +model supported by QEMU. e.g.:: + + $ qemu-kvm -cpu Haswell-noTSX-IBRS,vmx=on + +then the guest hypervisor will subsequently be capable of running a +nested guest with accelerated KVM. + + +Enabling "nested" (s390x) +------------------------- + +1. On the host hypervisor (L0), enable the ``nested`` parameter on + s390x:: + + $ rmmod kvm + $ modprobe kvm nested=1 + +.. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive + with the ``nested`` paramter — i.e. to be able to enable + ``nested``, the ``hpage`` parameter *must* be disabled. + +2. The guest hypervisor (L1) must be provided with the ``sie`` CPU + feature — with QEMU, this can be done by using "host passthrough" + (via the command-line ``-cpu host``). + +3. Now the KVM module can be loaded in the L1 (guest hypervisor):: + + $ modprobe kvm + + +Live migration with nested KVM +------------------------------ + +Migrating an L1 guest, with a *live* nested guest in it, to another +bare metal host, works as of Linux kernel 5.3 and QEMU 4.2.0 for +Intel x86 systems, and even on older versions for s390x. + +On AMD systems, once an L1 guest has started an L2 guest, the L1 guest +should no longer be migrated or saved (refer to QEMU documentation on +"savevm"/"loadvm") until the L2 guest shuts down. Attempting to migrate +or save-and-load an L1 guest while an L2 guest is running will result in +undefined behavior. You might see a ``kernel BUG!`` entry in ``dmesg``, a +kernel 'oops', or an outright kernel panic. Such a migrated or loaded L1 +guest can no longer be considered stable or secure, and must be restarted. +Migrating an L1 guest merely configured to support nesting, while not +actually running L2 guests, is expected to function normally even on AMD +systems but may fail once guests are started. + +Migrating an L2 guest is always expected to succeed, so all the following +scenarios should work even on AMD systems: + +- Migrating a nested guest (L2) to another L1 guest on the *same* bare + metal host. + +- Migrating a nested guest (L2) to another L1 guest on a *different* + bare metal host. + +- Migrating a nested guest (L2) to a bare metal host. + +Reporting bugs from nested setups +----------------------------------- + +Debugging "nested" problems can involve sifting through log files across +L0, L1 and L2; this can result in tedious back-n-forth between the bug +reporter and the bug fixer. + +- Mention that you are in a "nested" setup. If you are running any kind + of "nesting" at all, say so. Unfortunately, this needs to be called + out because when reporting bugs, people tend to forget to even + *mention* that they're using nested virtualization. + +- Ensure you are actually running KVM on KVM. Sometimes people do not + have KVM enabled for their guest hypervisor (L1), which results in + them running with pure emulation or what QEMU calls it as "TCG", but + they think they're running nested KVM. Thus confusing "nested Virt" + (which could also mean, QEMU on KVM) with "nested KVM" (KVM on KVM). + +Information to collect (generic) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following is not an exhaustive list, but a very good starting point: + + - Kernel, libvirt, and QEMU version from L0 + + - Kernel, libvirt and QEMU version from L1 + + - QEMU command-line of L1 -- when using libvirt, you'll find it here: + ``/var/log/libvirt/qemu/instance.log`` + + - QEMU command-line of L2 -- as above, when using libvirt, get the + complete libvirt-generated QEMU command-line + + - ``cat /sys/cpuinfo`` from L0 + + - ``cat /sys/cpuinfo`` from L1 + + - ``lscpu`` from L0 + + - ``lscpu`` from L1 + + - Full ``dmesg`` output from L0 + + - Full ``dmesg`` output from L1 + +x86-specific info to collect +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Both the below commands, ``x86info`` and ``dmidecode``, should be +available on most Linux distributions with the same name: + + - Output of: ``x86info -a`` from L0 + + - Output of: ``x86info -a`` from L1 + + - Output of: ``dmidecode`` from L0 + + - Output of: ``dmidecode`` from L1 + +s390x-specific info to collect +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Along with the earlier mentioned generic details, the below is +also recommended: + + - ``/proc/sysinfo`` from L1; this will also include the info from L0 diff --git a/Documentation/virt/kvm/x86/timekeeping.rst b/Documentation/virt/kvm/x86/timekeeping.rst new file mode 100644 index 000000000000..21ae7efa29ba --- /dev/null +++ b/Documentation/virt/kvm/x86/timekeeping.rst @@ -0,0 +1,645 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================================== +Timekeeping Virtualization for X86-Based Architectures +====================================================== + +:Author: Zachary Amsden +:Copyright: (c) 2010, Red Hat. All rights reserved. + +.. Contents + + 1) Overview + 2) Timing Devices + 3) TSC Hardware + 4) Virtualization Problems + +1. Overview +=========== + +One of the most complicated parts of the X86 platform, and specifically, +the virtualization of this platform is the plethora of timing devices available +and the complexity of emulating those devices. In addition, virtualization of +time introduces a new set of challenges because it introduces a multiplexed +division of time beyond the control of the guest CPU. + +First, we will describe the various timekeeping hardware available, then +present some of the problems which arise and solutions available, giving +specific recommendations for certain classes of KVM guests. + +The purpose of this document is to collect data and information relevant to +timekeeping which may be difficult to find elsewhere, specifically, +information relevant to KVM and hardware-based virtualization. + +2. Timing Devices +================= + +First we discuss the basic hardware devices available. TSC and the related +KVM clock are special enough to warrant a full exposition and are described in +the following section. + +2.1. i8254 - PIT +---------------- + +One of the first timer devices available is the programmable interrupt timer, +or PIT. The PIT has a fixed frequency 1.193182 MHz base clock and three +channels which can be programmed to deliver periodic or one-shot interrupts. +These three channels can be configured in different modes and have individual +counters. Channel 1 and 2 were not available for general use in the original +IBM PC, and historically were connected to control RAM refresh and the PC +speaker. Now the PIT is typically integrated as part of an emulated chipset +and a separate physical PIT is not used. + +The PIT uses I/O ports 0x40 - 0x43. Access to the 16-bit counters is done +using single or multiple byte access to the I/O ports. There are 6 modes +available, but not all modes are available to all timers, as only timer 2 +has a connected gate input, required for modes 1 and 5. The gate line is +controlled by port 61h, bit 0, as illustrated in the following diagram:: + + -------------- ---------------- + | | | | + | 1.1932 MHz|---------->| CLOCK OUT | ---------> IRQ 0 + | Clock | | | | + -------------- | +->| GATE TIMER 0 | + | ---------------- + | + | ---------------- + | | | + |------>| CLOCK OUT | ---------> 66.3 KHZ DRAM + | | | (aka /dev/null) + | +->| GATE TIMER 1 | + | ---------------- + | + | ---------------- + | | | + |------>| CLOCK OUT | ---------> Port 61h, bit 5 + | | | + Port 61h, bit 0 -------->| GATE TIMER 2 | \_.---- ____ + ---------------- _| )--|LPF|---Speaker + / *---- \___/ + Port 61h, bit 1 ---------------------------------/ + +The timer modes are now described. + +Mode 0: Single Timeout. + This is a one-shot software timeout that counts down + when the gate is high (always true for timers 0 and 1). When the count + reaches zero, the output goes high. + +Mode 1: Triggered One-shot. + The output is initially set high. When the gate + line is set high, a countdown is initiated (which does not stop if the gate is + lowered), during which the output is set low. When the count reaches zero, + the output goes high. + +Mode 2: Rate Generator. + The output is initially set high. When the countdown + reaches 1, the output goes low for one count and then returns high. The value + is reloaded and the countdown automatically resumes. If the gate line goes + low, the count is halted. If the output is low when the gate is lowered, the + output automatically goes high (this only affects timer 2). + +Mode 3: Square Wave. + This generates a high / low square wave. The count + determines the length of the pulse, which alternates between high and low + when zero is reached. The count only proceeds when gate is high and is + automatically reloaded on reaching zero. The count is decremented twice at + each clock to generate a full high / low cycle at the full periodic rate. + If the count is even, the clock remains high for N/2 counts and low for N/2 + counts; if the clock is odd, the clock is high for (N+1)/2 counts and low + for (N-1)/2 counts. Only even values are latched by the counter, so odd + values are not observed when reading. This is the intended mode for timer 2, + which generates sine-like tones by low-pass filtering the square wave output. + +Mode 4: Software Strobe. + After programming this mode and loading the counter, + the output remains high until the counter reaches zero. Then the output + goes low for 1 clock cycle and returns high. The counter is not reloaded. + Counting only occurs when gate is high. + +Mode 5: Hardware Strobe. + After programming and loading the counter, the + output remains high. When the gate is raised, a countdown is initiated + (which does not stop if the gate is lowered). When the counter reaches zero, + the output goes low for 1 clock cycle and then returns high. The counter is + not reloaded. + +In addition to normal binary counting, the PIT supports BCD counting. The +command port, 0x43 is used to set the counter and mode for each of the three +timers. + +PIT commands, issued to port 0x43, using the following bit encoding:: + + Bit 7-4: Command (See table below) + Bit 3-1: Mode (000 = Mode 0, 101 = Mode 5, 11X = undefined) + Bit 0 : Binary (0) / BCD (1) + +Command table:: + + 0000 - Latch Timer 0 count for port 0x40 + sample and hold the count to be read in port 0x40; + additional commands ignored until counter is read; + mode bits ignored. + + 0001 - Set Timer 0 LSB mode for port 0x40 + set timer to read LSB only and force MSB to zero; + mode bits set timer mode + + 0010 - Set Timer 0 MSB mode for port 0x40 + set timer to read MSB only and force LSB to zero; + mode bits set timer mode + + 0011 - Set Timer 0 16-bit mode for port 0x40 + set timer to read / write LSB first, then MSB; + mode bits set timer mode + + 0100 - Latch Timer 1 count for port 0x41 - as described above + 0101 - Set Timer 1 LSB mode for port 0x41 - as described above + 0110 - Set Timer 1 MSB mode for port 0x41 - as described above + 0111 - Set Timer 1 16-bit mode for port 0x41 - as described above + + 1000 - Latch Timer 2 count for port 0x42 - as described above + 1001 - Set Timer 2 LSB mode for port 0x42 - as described above + 1010 - Set Timer 2 MSB mode for port 0x42 - as described above + 1011 - Set Timer 2 16-bit mode for port 0x42 as described above + + 1101 - General counter latch + Latch combination of counters into corresponding ports + Bit 3 = Counter 2 + Bit 2 = Counter 1 + Bit 1 = Counter 0 + Bit 0 = Unused + + 1110 - Latch timer status + Latch combination of counter mode into corresponding ports + Bit 3 = Counter 2 + Bit 2 = Counter 1 + Bit 1 = Counter 0 + + The output of ports 0x40-0x42 following this command will be: + + Bit 7 = Output pin + Bit 6 = Count loaded (0 if timer has expired) + Bit 5-4 = Read / Write mode + 01 = MSB only + 10 = LSB only + 11 = LSB / MSB (16-bit) + Bit 3-1 = Mode + Bit 0 = Binary (0) / BCD mode (1) + +2.2. RTC +-------- + +The second device which was available in the original PC was the MC146818 real +time clock. The original device is now obsolete, and usually emulated by the +system chipset, sometimes by an HPET and some frankenstein IRQ routing. + +The RTC is accessed through CMOS variables, which uses an index register to +control which bytes are read. Since there is only one index register, read +of the CMOS and read of the RTC require lock protection (in addition, it is +dangerous to allow userspace utilities such as hwclock to have direct RTC +access, as they could corrupt kernel reads and writes of CMOS memory). + +The RTC generates an interrupt which is usually routed to IRQ 8. The interrupt +can function as a periodic timer, an additional once a day alarm, and can issue +interrupts after an update of the CMOS registers by the MC146818 is complete. +The type of interrupt is signalled in the RTC status registers. + +The RTC will update the current time fields by battery power even while the +system is off. The current time fields should not be read while an update is +in progress, as indicated in the status register. + +The clock uses a 32.768kHz crystal, so bits 6-4 of register A should be +programmed to a 32kHz divider if the RTC is to count seconds. + +This is the RAM map originally used for the RTC/CMOS:: + + Location Size Description + ------------------------------------------ + 00h byte Current second (BCD) + 01h byte Seconds alarm (BCD) + 02h byte Current minute (BCD) + 03h byte Minutes alarm (BCD) + 04h byte Current hour (BCD) + 05h byte Hours alarm (BCD) + 06h byte Current day of week (BCD) + 07h byte Current day of month (BCD) + 08h byte Current month (BCD) + 09h byte Current year (BCD) + 0Ah byte Register A + bit 7 = Update in progress + bit 6-4 = Divider for clock + 000 = 4.194 MHz + 001 = 1.049 MHz + 010 = 32 kHz + 10X = test modes + 110 = reset / disable + 111 = reset / disable + bit 3-0 = Rate selection for periodic interrupt + 000 = periodic timer disabled + 001 = 3.90625 uS + 010 = 7.8125 uS + 011 = .122070 mS + 100 = .244141 mS + ... + 1101 = 125 mS + 1110 = 250 mS + 1111 = 500 mS + 0Bh byte Register B + bit 7 = Run (0) / Halt (1) + bit 6 = Periodic interrupt enable + bit 5 = Alarm interrupt enable + bit 4 = Update-ended interrupt enable + bit 3 = Square wave interrupt enable + bit 2 = BCD calendar (0) / Binary (1) + bit 1 = 12-hour mode (0) / 24-hour mode (1) + bit 0 = 0 (DST off) / 1 (DST enabled) + OCh byte Register C (read only) + bit 7 = interrupt request flag (IRQF) + bit 6 = periodic interrupt flag (PF) + bit 5 = alarm interrupt flag (AF) + bit 4 = update interrupt flag (UF) + bit 3-0 = reserved + ODh byte Register D (read only) + bit 7 = RTC has power + bit 6-0 = reserved + 32h byte Current century BCD (*) + (*) location vendor specific and now determined from ACPI global tables + +2.3. APIC +--------- + +On Pentium and later processors, an on-board timer is available to each CPU +as part of the Advanced Programmable Interrupt Controller. The APIC is +accessed through memory-mapped registers and provides interrupt service to each +CPU, used for IPIs and local timer interrupts. + +Although in theory the APIC is a safe and stable source for local interrupts, +in practice, many bugs and glitches have occurred due to the special nature of +the APIC CPU-local memory-mapped hardware. Beware that CPU errata may affect +the use of the APIC and that workarounds may be required. In addition, some of +these workarounds pose unique constraints for virtualization - requiring either +extra overhead incurred from extra reads of memory-mapped I/O or additional +functionality that may be more computationally expensive to implement. + +Since the APIC is documented quite well in the Intel and AMD manuals, we will +avoid repetition of the detail here. It should be pointed out that the APIC +timer is programmed through the LVT (local vector timer) register, is capable +of one-shot or periodic operation, and is based on the bus clock divided down +by the programmable divider register. + +2.4. HPET +--------- + +HPET is quite complex, and was originally intended to replace the PIT / RTC +support of the X86 PC. It remains to be seen whether that will be the case, as +the de facto standard of PC hardware is to emulate these older devices. Some +systems designated as legacy free may support only the HPET as a hardware timer +device. + +The HPET spec is rather loose and vague, requiring at least 3 hardware timers, +but allowing implementation freedom to support many more. It also imposes no +fixed rate on the timer frequency, but does impose some extremal values on +frequency, error and slew. + +In general, the HPET is recommended as a high precision (compared to PIT /RTC) +time source which is independent of local variation (as there is only one HPET +in any given system). The HPET is also memory-mapped, and its presence is +indicated through ACPI tables by the BIOS. + +Detailed specification of the HPET is beyond the current scope of this +document, as it is also very well documented elsewhere. + +2.5. Offboard Timers +-------------------- + +Several cards, both proprietary (watchdog boards) and commonplace (e1000) have +timing chips built into the cards which may have registers which are accessible +to kernel or user drivers. To the author's knowledge, using these to generate +a clocksource for a Linux or other kernel has not yet been attempted and is in +general frowned upon as not playing by the agreed rules of the game. Such a +timer device would require additional support to be virtualized properly and is +not considered important at this time as no known operating system does this. + +3. TSC Hardware +=============== + +The TSC or time stamp counter is relatively simple in theory; it counts +instruction cycles issued by the processor, which can be used as a measure of +time. In practice, due to a number of problems, it is the most complicated +timekeeping device to use. + +The TSC is represented internally as a 64-bit MSR which can be read with the +RDMSR, RDTSC, or RDTSCP (when available) instructions. In the past, hardware +limitations made it possible to write the TSC, but generally on old hardware it +was only possible to write the low 32-bits of the 64-bit counter, and the upper +32-bits of the counter were cleared. Now, however, on Intel processors family +0Fh, for models 3, 4 and 6, and family 06h, models e and f, this restriction +has been lifted and all 64-bits are writable. On AMD systems, the ability to +write the TSC MSR is not an architectural guarantee. + +The TSC is accessible from CPL-0 and conditionally, for CPL > 0 software by +means of the CR4.TSD bit, which when enabled, disables CPL > 0 TSC access. + +Some vendors have implemented an additional instruction, RDTSCP, which returns +atomically not just the TSC, but an indicator which corresponds to the +processor number. This can be used to index into an array of TSC variables to +determine offset information in SMP systems where TSCs are not synchronized. +The presence of this instruction must be determined by consulting CPUID feature +bits. + +Both VMX and SVM provide extension fields in the virtualization hardware which +allows the guest visible TSC to be offset by a constant. Newer implementations +promise to allow the TSC to additionally be scaled, but this hardware is not +yet widely available. + +3.1. TSC synchronization +------------------------ + +The TSC is a CPU-local clock in most implementations. This means, on SMP +platforms, the TSCs of different CPUs may start at different times depending +on when the CPUs are powered on. Generally, CPUs on the same die will share +the same clock, however, this is not always the case. + +The BIOS may attempt to resynchronize the TSCs during the poweron process and +the operating system or other system software may attempt to do this as well. +Several hardware limitations make the problem worse - if it is not possible to +write the full 64-bits of the TSC, it may be impossible to match the TSC in +newly arriving CPUs to that of the rest of the system, resulting in +unsynchronized TSCs. This may be done by BIOS or system software, but in +practice, getting a perfectly synchronized TSC will not be possible unless all +values are read from the same clock, which generally only is possible on single +socket systems or those with special hardware support. + +3.2. TSC and CPU hotplug +------------------------ + +As touched on already, CPUs which arrive later than the boot time of the system +may not have a TSC value that is synchronized with the rest of the system. +Either system software, BIOS, or SMM code may actually try to establish the TSC +to a value matching the rest of the system, but a perfect match is usually not +a guarantee. This can have the effect of bringing a system from a state where +TSC is synchronized back to a state where TSC synchronization flaws, however +small, may be exposed to the OS and any virtualization environment. + +3.3. TSC and multi-socket / NUMA +-------------------------------- + +Multi-socket systems, especially large multi-socket systems are likely to have +individual clocksources rather than a single, universally distributed clock. +Since these clocks are driven by different crystals, they will not have +perfectly matched frequency, and temperature and electrical variations will +cause the CPU clocks, and thus the TSCs to drift over time. Depending on the +exact clock and bus design, the drift may or may not be fixed in absolute +error, and may accumulate over time. + +In addition, very large systems may deliberately slew the clocks of individual +cores. This technique, known as spread-spectrum clocking, reduces EMI at the +clock frequency and harmonics of it, which may be required to pass FCC +standards for telecommunications and computer equipment. + +It is recommended not to trust the TSCs to remain synchronized on NUMA or +multiple socket systems for these reasons. + +3.4. TSC and C-states +--------------------- + +C-states, or idling states of the processor, especially C1E and deeper sleep +states may be problematic for TSC as well. The TSC may stop advancing in such +a state, resulting in a TSC which is behind that of other CPUs when execution +is resumed. Such CPUs must be detected and flagged by the operating system +based on CPU and chipset identifications. + +The TSC in such a case may be corrected by catching it up to a known external +clocksource. + +3.5. TSC frequency change / P-states +------------------------------------ + +To make things slightly more interesting, some CPUs may change frequency. They +may or may not run the TSC at the same rate, and because the frequency change +may be staggered or slewed, at some points in time, the TSC rate may not be +known other than falling within a range of values. In this case, the TSC will +not be a stable time source, and must be calibrated against a known, stable, +external clock to be a usable source of time. + +Whether the TSC runs at a constant rate or scales with the P-state is model +dependent and must be determined by inspecting CPUID, chipset or vendor +specific MSR fields. + +In addition, some vendors have known bugs where the P-state is actually +compensated for properly during normal operation, but when the processor is +inactive, the P-state may be raised temporarily to service cache misses from +other processors. In such cases, the TSC on halted CPUs could advance faster +than that of non-halted processors. AMD Turion processors are known to have +this problem. + +3.6. TSC and STPCLK / T-states +------------------------------ + +External signals given to the processor may also have the effect of stopping +the TSC. This is typically done for thermal emergency power control to prevent +an overheating condition, and typically, there is no way to detect that this +condition has happened. + +3.7. TSC virtualization - VMX +----------------------------- + +VMX provides conditional trapping of RDTSC, RDMSR, WRMSR and RDTSCP +instructions, which is enough for full virtualization of TSC in any manner. In +addition, VMX allows passing through the host TSC plus an additional TSC_OFFSET +field specified in the VMCS. Special instructions must be used to read and +write the VMCS field. + +3.8. TSC virtualization - SVM +----------------------------- + +SVM provides conditional trapping of RDTSC, RDMSR, WRMSR and RDTSCP +instructions, which is enough for full virtualization of TSC in any manner. In +addition, SVM allows passing through the host TSC plus an additional offset +field specified in the SVM control block. + +3.9. TSC feature bits in Linux +------------------------------ + +In summary, there is no way to guarantee the TSC remains in perfect +synchronization unless it is explicitly guaranteed by the architecture. Even +if so, the TSCs in multi-sockets or NUMA systems may still run independently +despite being locally consistent. + +The following feature bits are used by Linux to signal various TSC attributes, +but they can only be taken to be meaningful for UP or single node systems. + +========================= ======================================= +X86_FEATURE_TSC The TSC is available in hardware +X86_FEATURE_RDTSCP The RDTSCP instruction is available +X86_FEATURE_CONSTANT_TSC The TSC rate is unchanged with P-states +X86_FEATURE_NONSTOP_TSC The TSC does not stop in C-states +X86_FEATURE_TSC_RELIABLE TSC sync checks are skipped (VMware) +========================= ======================================= + +4. Virtualization Problems +========================== + +Timekeeping is especially problematic for virtualization because a number of +challenges arise. The most obvious problem is that time is now shared between +the host and, potentially, a number of virtual machines. Thus the virtual +operating system does not run with 100% usage of the CPU, despite the fact that +it may very well make that assumption. It may expect it to remain true to very +exacting bounds when interrupt sources are disabled, but in reality only its +virtual interrupt sources are disabled, and the machine may still be preempted +at any time. This causes problems as the passage of real time, the injection +of machine interrupts and the associated clock sources are no longer completely +synchronized with real time. + +This same problem can occur on native hardware to a degree, as SMM mode may +steal cycles from the naturally on X86 systems when SMM mode is used by the +BIOS, but not in such an extreme fashion. However, the fact that SMM mode may +cause similar problems to virtualization makes it a good justification for +solving many of these problems on bare metal. + +4.1. Interrupt clocking +----------------------- + +One of the most immediate problems that occurs with legacy operating systems +is that the system timekeeping routines are often designed to keep track of +time by counting periodic interrupts. These interrupts may come from the PIT +or the RTC, but the problem is the same: the host virtualization engine may not +be able to deliver the proper number of interrupts per second, and so guest +time may fall behind. This is especially problematic if a high interrupt rate +is selected, such as 1000 HZ, which is unfortunately the default for many Linux +guests. + +There are three approaches to solving this problem; first, it may be possible +to simply ignore it. Guests which have a separate time source for tracking +'wall clock' or 'real time' may not need any adjustment of their interrupts to +maintain proper time. If this is not sufficient, it may be necessary to inject +additional interrupts into the guest in order to increase the effective +interrupt rate. This approach leads to complications in extreme conditions, +where host load or guest lag is too much to compensate for, and thus another +solution to the problem has risen: the guest may need to become aware of lost +ticks and compensate for them internally. Although promising in theory, the +implementation of this policy in Linux has been extremely error prone, and a +number of buggy variants of lost tick compensation are distributed across +commonly used Linux systems. + +Windows uses periodic RTC clocking as a means of keeping time internally, and +thus requires interrupt slewing to keep proper time. It does use a low enough +rate (ed: is it 18.2 Hz?) however that it has not yet been a problem in +practice. + +4.2. TSC sampling and serialization +----------------------------------- + +As the highest precision time source available, the cycle counter of the CPU +has aroused much interest from developers. As explained above, this timer has +many problems unique to its nature as a local, potentially unstable and +potentially unsynchronized source. One issue which is not unique to the TSC, +but is highlighted because of its very precise nature is sampling delay. By +definition, the counter, once read is already old. However, it is also +possible for the counter to be read ahead of the actual use of the result. +This is a consequence of the superscalar execution of the instruction stream, +which may execute instructions out of order. Such execution is called +non-serialized. Forcing serialized execution is necessary for precise +measurement with the TSC, and requires a serializing instruction, such as CPUID +or an MSR read. + +Since CPUID may actually be virtualized by a trap and emulate mechanism, this +serialization can pose a performance issue for hardware virtualization. An +accurate time stamp counter reading may therefore not always be available, and +it may be necessary for an implementation to guard against "backwards" reads of +the TSC as seen from other CPUs, even in an otherwise perfectly synchronized +system. + +4.3. Timespec aliasing +---------------------- + +Additionally, this lack of serialization from the TSC poses another challenge +when using results of the TSC when measured against another time source. As +the TSC is much higher precision, many possible values of the TSC may be read +while another clock is still expressing the same value. + +That is, you may read (T,T+10) while external clock C maintains the same value. +Due to non-serialized reads, you may actually end up with a range which +fluctuates - from (T-1.. T+10). Thus, any time calculated from a TSC, but +calibrated against an external value may have a range of valid values. +Re-calibrating this computation may actually cause time, as computed after the +calibration, to go backwards, compared with time computed before the +calibration. + +This problem is particularly pronounced with an internal time source in Linux, +the kernel time, which is expressed in the theoretically high resolution +timespec - but which advances in much larger granularity intervals, sometimes +at the rate of jiffies, and possibly in catchup modes, at a much larger step. + +This aliasing requires care in the computation and recalibration of kvmclock +and any other values derived from TSC computation (such as TSC virtualization +itself). + +4.4. Migration +-------------- + +Migration of a virtual machine raises problems for timekeeping in two ways. +First, the migration itself may take time, during which interrupts cannot be +delivered, and after which, the guest time may need to be caught up. NTP may +be able to help to some degree here, as the clock correction required is +typically small enough to fall in the NTP-correctable window. + +An additional concern is that timers based off the TSC (or HPET, if the raw bus +clock is exposed) may now be running at different rates, requiring compensation +in some way in the hypervisor by virtualizing these timers. In addition, +migrating to a faster machine may preclude the use of a passthrough TSC, as a +faster clock cannot be made visible to a guest without the potential of time +advancing faster than usual. A slower clock is less of a problem, as it can +always be caught up to the original rate. KVM clock avoids these problems by +simply storing multipliers and offsets against the TSC for the guest to convert +back into nanosecond resolution values. + +4.5. Scheduling +--------------- + +Since scheduling may be based on precise timing and firing of interrupts, the +scheduling algorithms of an operating system may be adversely affected by +virtualization. In theory, the effect is random and should be universally +distributed, but in contrived as well as real scenarios (guest device access, +causes of virtualization exits, possible context switch), this may not always +be the case. The effect of this has not been well studied. + +In an attempt to work around this, several implementations have provided a +paravirtualized scheduler clock, which reveals the true amount of CPU time for +which a virtual machine has been running. + +4.6. Watchdogs +-------------- + +Watchdog timers, such as the lock detector in Linux may fire accidentally when +running under hardware virtualization due to timer interrupts being delayed or +misinterpretation of the passage of real time. Usually, these warnings are +spurious and can be ignored, but in some circumstances it may be necessary to +disable such detection. + +4.7. Delays and precision timing +-------------------------------- + +Precise timing and delays may not be possible in a virtualized system. This +can happen if the system is controlling physical hardware, or issues delays to +compensate for slower I/O to and from devices. The first issue is not solvable +in general for a virtualized system; hardware control software can't be +adequately virtualized without a full real-time operating system, which would +require an RT aware virtualization platform. + +The second issue may cause performance problems, but this is unlikely to be a +significant issue. In many cases these delays may be eliminated through +configuration or paravirtualization. + +4.8. Covert channels and leaks +------------------------------ + +In addition to the above problems, time information will inevitably leak to the +guest about the host in anything but a perfect implementation of virtualized +time. This may allow the guest to infer the presence of a hypervisor (as in a +red-pill type detection), and it may allow information to leak between guests +by using CPU utilization itself as a signalling channel. Preventing such +problems would require completely isolated virtual time which may not track +real time any longer. This may be useful in certain security or QA contexts, +but in general isn't recommended for real-world deployment scenarios. -- cgit From 45016721de3c714902c6f475b705e10ae0bdd801 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Tue, 22 Mar 2022 12:07:11 +0100 Subject: Documentation: KVM: add virtual CPU errata documentation Add a file to document all the different ways in which the virtual CPU emulation is imperfect. Include an example to show how to document such errata. Signed-off-by: Paolo Bonzini Reviewed-by: Jim Mattson Reviewed-by: Oliver Upton Message-Id: <20220322110712.222449-3-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/x86/errata.rst | 39 +++++++++++++++++++++++++++++++++++ Documentation/virt/kvm/x86/index.rst | 1 + 2 files changed, 40 insertions(+) create mode 100644 Documentation/virt/kvm/x86/errata.rst (limited to 'Documentation') diff --git a/Documentation/virt/kvm/x86/errata.rst b/Documentation/virt/kvm/x86/errata.rst new file mode 100644 index 000000000000..806f049b6975 --- /dev/null +++ b/Documentation/virt/kvm/x86/errata.rst @@ -0,0 +1,39 @@ + +======================================= +Known limitations of CPU virtualization +======================================= + +Whenever perfect emulation of a CPU feature is impossible or too hard, KVM +has to choose between not implementing the feature at all or introducing +behavioral differences between virtual machines and bare metal systems. + +This file documents some of the known limitations that KVM has in +virtualizing CPU features. + +x86 +=== + +``KVM_GET_SUPPORTED_CPUID`` issues +---------------------------------- + +x87 features +~~~~~~~~~~~~ + +Unlike most other CPUID feature bits, CPUID[EAX=7,ECX=0]:EBX[6] +(FDP_EXCPTN_ONLY) and CPUID[EAX=7,ECX=0]:EBX]13] (ZERO_FCS_FDS) are +clear if the features are present and set if the features are not present. + +Clearing these bits in CPUID has no effect on the operation of the guest; +if these bits are set on hardware, the features will not be present on +any virtual machine that runs on that hardware. + +**Workaround:** It is recommended to always set these bits in guest CPUID. +Note however that any software (e.g ``WIN87EM.DLL``) expecting these features +to be present likely predates these CPUID feature bits, and therefore +doesn't know to check for them anyway. + +Nested virtualization features +------------------------------ + +TBD + diff --git a/Documentation/virt/kvm/x86/index.rst b/Documentation/virt/kvm/x86/index.rst index 55ede8e070b6..7ff588826b9f 100644 --- a/Documentation/virt/kvm/x86/index.rst +++ b/Documentation/virt/kvm/x86/index.rst @@ -9,6 +9,7 @@ KVM for x86 systems amd-memory-encryption cpuid + errata halt-polling hypercalls mmu -- cgit From cde363ab7ca7aea7a853851cd6a6745a9e1aaf5e Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Tue, 22 Mar 2022 12:07:12 +0100 Subject: Documentation: KVM: add API issues section Add a section to document all the different ways in which the KVM API sucks. I am sure there are way more, give people a place to vent so that userspace authors are aware. Signed-off-by: Paolo Bonzini Message-Id: <20220322110712.222449-4-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 46 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 07a45474abe9..1ec05e6bfa6f 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7719,3 +7719,49 @@ only be invoked on a VM prior to the creation of VCPUs. At this time, KVM_PMU_CAP_DISABLE is the only capability. Setting this capability will disable PMU virtualization for that VM. Usermode should adjust CPUID leaf 0xA to reflect that the PMU is disabled. + +9. Known KVM API problems +========================= + +In some cases, KVM's API has some inconsistencies or common pitfalls +that userspace need to be aware of. This section details some of +these issues. + +Most of them are architecture specific, so the section is split by +architecture. + +9.1. x86 +-------- + +``KVM_GET_SUPPORTED_CPUID`` issues +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In general, ``KVM_GET_SUPPORTED_CPUID`` is designed so that it is possible +to take its result and pass it directly to ``KVM_SET_CPUID2``. This section +documents some cases in which that requires some care. + +Local APIC features +~~~~~~~~~~~~~~~~~~~ + +CPU[EAX=1]:ECX[21] (X2APIC) is reported by ``KVM_GET_SUPPORTED_CPUID``, +but it can only be enabled if ``KVM_CREATE_IRQCHIP`` or +``KVM_ENABLE_CAP(KVM_CAP_IRQCHIP_SPLIT)`` are used to enable in-kernel emulation of +the local APIC. + +The same is true for the ``KVM_FEATURE_PV_UNHALT`` paravirtualized feature. + +CPU[EAX=1]:ECX[24] (TSC_DEADLINE) is not reported by ``KVM_GET_SUPPORTED_CPUID``. +It can be enabled if ``KVM_CAP_TSC_DEADLINE_TIMER`` is present and the kernel +has enabled in-kernel emulation of the local APIC. + +Obsolete ioctls and capabilities +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +KVM_CAP_DISABLE_QUIRKS does not let userspace know which quirks are actually +available. Use ``KVM_CHECK_EXTENSION(KVM_CAP_DISABLE_QUIRKS2)`` instead if +available. + +Ordering of KVM_GET_*/KVM_SET_* ioctls +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +TBD -- cgit From 6094e391e643fddd65d4b938c1d499a838dd4907 Mon Sep 17 00:00:00 2001 From: Vinod Koul Date: Sat, 26 Mar 2022 01:37:31 +0530 Subject: dt-bindings: net: qcom,ethqos: Document SM8150 SoC compatible SM8150 has an ethernet controller and it needs a different configuration, so add a new compatible for this. Acked-by: Rob Herring Signed-off-by: Vinod Koul [bhsharma: Massage the commit log] Signed-off-by: Bhupesh Sharma Link: https://lore.kernel.org/r/20220325200731.1585554-1-bhupesh.sharma@linaro.org Signed-off-by: Jakub Kicinski --- Documentation/devicetree/bindings/net/qcom,ethqos.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/qcom,ethqos.txt b/Documentation/devicetree/bindings/net/qcom,ethqos.txt index fcf5035810b5..1f5746849a71 100644 --- a/Documentation/devicetree/bindings/net/qcom,ethqos.txt +++ b/Documentation/devicetree/bindings/net/qcom,ethqos.txt @@ -7,7 +7,9 @@ This device has following properties: Required properties: -- compatible: Should be qcom,qcs404-ethqos" +- compatible: Should be one of: + "qcom,qcs404-ethqos" + "qcom,sm8150-ethqos" - reg: Address and length of the register set for the device -- cgit From 05b0ebd06ae6b9e72b747362e52abb400a175080 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Wed, 30 Mar 2022 07:24:21 +0200 Subject: PCI/doc: cleanup references to the legacy PCI DMA API Mention the regular DMA API calls instead of the now removed PCI DMA API. Signed-off-by: Christoph Hellwig Acked-by: Bjorn Helgaas --- Documentation/PCI/pci.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst index 87c6f4a6ca32..67a850b55617 100644 --- a/Documentation/PCI/pci.rst +++ b/Documentation/PCI/pci.rst @@ -278,20 +278,20 @@ appropriate parameters. In general this allows more efficient DMA on systems where System RAM exists above 4G _physical_ address. Drivers for all PCI-X and PCIe compliant devices must call -pci_set_dma_mask() as they are 64-bit DMA devices. +set_dma_mask() as they are 64-bit DMA devices. Similarly, drivers must also "register" this capability if the device -can directly address "consistent memory" in System RAM above 4G physical -address by calling pci_set_consistent_dma_mask(). +can directly address "coherent memory" in System RAM above 4G physical +address by calling dma_set_coherent_mask(). Again, this includes drivers for all PCI-X and PCIe compliant devices. Many 64-bit "PCI" devices (before PCI-X) and some PCI-X devices are 64-bit DMA capable for payload ("streaming") data but not control -("consistent") data. +("coherent") data. Setup shared control data ------------------------- -Once the DMA masks are set, the driver can allocate "consistent" (a.k.a. shared) +Once the DMA masks are set, the driver can allocate "coherent" (a.k.a. shared) memory. See Documentation/core-api/dma-api.rst for a full description of the DMA APIs. This section is just a reminder that it needs to be done before enabling DMA on the device. @@ -367,7 +367,7 @@ steps need to be performed: - Disable the device from generating IRQs - Release the IRQ (free_irq()) - Stop all DMA activity - - Release DMA buffers (both streaming and consistent) + - Release DMA buffers (both streaming and coherent) - Unregister from other subsystems (e.g. scsi or netdev) - Disable device from responding to MMIO/IO Port addresses - Release MMIO/IO Port resource(s) @@ -420,7 +420,7 @@ Once DMA is stopped, clean up streaming DMA first. I.e. unmap data buffers and return buffers to "upstream" owners if there is one. -Then clean up "consistent" buffers which contain the control data. +Then clean up "coherent" buffers which contain the control data. See Documentation/core-api/dma-api.rst for details on unmapping interfaces. -- cgit From be78837ca3c88eebd405103a7a2ce891c466b0db Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Tue, 29 Mar 2022 15:07:02 +0900 Subject: docs: sphinx/requirements: Limit jinja2<3.1 jinja2 release 3.1.0 (March 24, 2022) broke Sphinx<4.0. This looks like the result of deprecating Python 3.6. It has been tested against Sphinx 4.3.0 and later. Setting an upper limit of <3.1 to junja2 can unbreak Sphinx<4.0 including Sphinx 2.4.4. Signed-off-by: Akira Yokosawa Cc: Mauro Carvalho Chehab Cc: stable@vger.kernel.org # v5.15+ Link: https://lore.kernel.org/r/7dbff8a0-f4ff-34a0-71c7-1987baf471f9@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/sphinx/requirements.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sphinx/requirements.txt b/Documentation/sphinx/requirements.txt index 9a35f50798a6..2c573541ab71 100644 --- a/Documentation/sphinx/requirements.txt +++ b/Documentation/sphinx/requirements.txt @@ -1,2 +1,4 @@ +# jinja2>=3.1 is not compatible with Sphinx<4.0 +jinja2<3.1 sphinx_rtd_theme Sphinx==2.4.4 -- cgit From 022bb490c79799229ef467d9ccc3e5966001b0ae Mon Sep 17 00:00:00 2001 From: Jonathan Corbet Date: Fri, 25 Mar 2022 15:51:35 -0600 Subject: docs: Add a document on how to fix a messy diffstat A branch with merges in will sometimes create a diffstat containing a lot of unrelated work at "git request-pull" time. Create a document based on Linus's advice (found in the links below) and add it to the maintainer manual in the hope of saving some wear on Linus's keyboard going forward. Link: https://lore.kernel.org/lkml/CAHk-=wg3wXH2JNxkQi+eLZkpuxqV+wPiHhw_Jf7ViH33Sw7PHA@mail.gmail.com/ Link: https://lore.kernel.org/lkml/CAHk-=wgXbSa8yq8Dht8at+gxb_idnJ7X5qWZQWRBN4_CUPr=eQ@mail.gmail.com/ Acked-by: Borislav Petkov Reviewed-by: Akira Yokosawa Signed-off-by: Jonathan Corbet --- Documentation/maintainer/index.rst | 1 + Documentation/maintainer/messy-diffstat.rst | 96 +++++++++++++++++++++++++++++ 2 files changed, 97 insertions(+) create mode 100644 Documentation/maintainer/messy-diffstat.rst (limited to 'Documentation') diff --git a/Documentation/maintainer/index.rst b/Documentation/maintainer/index.rst index f0a60435b124..3e03283c144e 100644 --- a/Documentation/maintainer/index.rst +++ b/Documentation/maintainer/index.rst @@ -12,6 +12,7 @@ additions to this manual. configure-git rebasing-and-merging pull-requests + messy-diffstat maintainer-entry-profile modifying-patches diff --git a/Documentation/maintainer/messy-diffstat.rst b/Documentation/maintainer/messy-diffstat.rst new file mode 100644 index 000000000000..c015f66d7621 --- /dev/null +++ b/Documentation/maintainer/messy-diffstat.rst @@ -0,0 +1,96 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================================== +Handling messy pull-request diffstats +===================================== + +Subsystem maintainers routinely use ``git request-pull`` as part of the +process of sending work upstream. Normally, the result includes a nice +diffstat that shows which files will be touched and how much of each will +be changed. Occasionally, though, a repository with a relatively +complicated development history will yield a massive diffstat containing a +great deal of unrelated work. The result looks ugly and obscures what the +pull request is actually doing. This document describes what is happening +and how to fix things up; it is derived from The Wisdom of Linus Torvalds, +found in Linus1_ and Linus2_. + +.. _Linus1: https://lore.kernel.org/lkml/CAHk-=wg3wXH2JNxkQi+eLZkpuxqV+wPiHhw_Jf7ViH33Sw7PHA@mail.gmail.com/ +.. _Linus2: https://lore.kernel.org/lkml/CAHk-=wgXbSa8yq8Dht8at+gxb_idnJ7X5qWZQWRBN4_CUPr=eQ@mail.gmail.com/ + +A Git development history proceeds as a series of commits. In a simplified +manner, mainline kernel development looks like this:: + + ... vM --- vN-rc1 --- vN-rc2 --- vN-rc3 --- ... --- vN-rc7 --- vN + +If one wants to see what has changed between two points, a command like +this will do the job:: + + $ git diff --stat --summary vN-rc2..vN-rc3 + +Here, there are two clear points in the history; Git will essentially +"subtract" the beginning point from the end point and display the resulting +differences. The requested operation is unambiguous and easy enough to +understand. + +When a subsystem maintainer creates a branch and commits changes to it, the +result in the simplest case is a history that looks like:: + + ... vM --- vN-rc1 --- vN-rc2 --- vN-rc3 --- ... --- vN-rc7 --- vN + | + +-- c1 --- c2 --- ... --- cN + +If that maintainer now uses ``git diff`` to see what has changed between +the mainline branch (let's call it "linus") and cN, there are still two +clear endpoints, and the result is as expected. So a pull request +generated with ``git request-pull`` will also be as expected. But now +consider a slightly more complex development history:: + + ... vM --- vN-rc1 --- vN-rc2 --- vN-rc3 --- ... --- vN-rc7 --- vN + | | + | +-- c1 --- c2 --- ... --- cN + | / + +-- x1 --- x2 --- x3 + +Our maintainer has created one branch at vN-rc1 and another at vN-rc2; the +two were then subsequently merged into c2. Now a pull request generated +for cN may end up being messy indeed, and developers often end up wondering +why. + +What is happening here is that there are no longer two clear end points for +the ``git diff`` operation to use. The development culminating in cN +started in two different places; to generate the diffstat, ``git diff`` +ends up having pick one of them and hoping for the best. If the diffstat +starts at vN-rc1, it may end up including all of the changes between there +and the second origin end point (vN-rc2), which is certainly not what our +maintainer had in mind. With all of that extra junk in the diffstat, it +may be impossible to tell what actually happened in the changes leading up +to cN. + +Maintainers often try to resolve this problem by, for example, rebasing the +branch or performing another merge with the linus branch, then recreating +the pull request. This approach tends not to lead to joy at the receiving +end of that pull request; rebasing and/or merging just before pushing +upstream is a well-known way to get a grumpy response. + +So what is to be done? The best response when confronted with this +situation is to indeed to do a merge with the branch you intend your work +to be pulled into, but to do it privately, as if it were the source of +shame. Create a new, throwaway branch and do the merge there:: + + ... vM --- vN-rc1 --- vN-rc2 --- vN-rc3 --- ... --- vN-rc7 --- vN + | | | + | +-- c1 --- c2 --- ... --- cN | + | / | | + +-- x1 --- x2 --- x3 +------------+-- TEMP + +The merge operation resolves all of the complications resulting from the +multiple beginning points, yielding a coherent result that contains only +the differences from the mainline branch. Now it will be possible to +generate a diffstat with the desired information:: + + $ git diff -C --stat --summary linus..TEMP + +Save the output from this command, then simply delete the TEMP branch; +definitely do not expose it to the outside world. Take the saved diffstat +output and edit it into the messy pull request, yielding a result that +shows what is really going on. That request can then be sent upstream. -- cgit From e9c281928c24dfeb86b11c31b53757b6a127f8aa Mon Sep 17 00:00:00 2001 From: Nathan Chancellor Date: Fri, 4 Mar 2022 10:08:14 -0700 Subject: kbuild: Make $(LLVM) more flexible The LLVM make variable allows a developer to quickly switch between the GNU and LLVM tools. However, it does not handle versioned binaries, such as the ones shipped by Debian, as LLVM=1 just defines the tool variables with the unversioned binaries. There was some discussion during the review of the patch that introduces LLVM=1 around versioned binaries, ultimately coming to the conclusion that developers can just add the folder that contains the unversioned binaries to their PATH, as Debian's versioned suffixed binaries are really just symlinks to the unversioned binaries in /usr/lib/llvm-#/bin: $ realpath /usr/bin/clang-14 /usr/lib/llvm-14/bin/clang $ PATH=/usr/lib/llvm-14/bin:$PATH make ... LLVM=1 However, that can be cumbersome to developers who are constantly testing series with different toolchains and versions. It is simple enough to support these versioned binaries directly in the Kbuild system by allowing the developer to specify the version suffix with LLVM=, which is shorter than the above suggestion: $ make ... LLVM=-14 It does not change the meaning of LLVM=1 (which will continue to use unversioned binaries) and it does not add too much additional complexity to the existing $(LLVM) code, while allowing developers to quickly test their series with different versions of the whole LLVM suite of tools. Some developers may build LLVM from source but not add the binaries to their PATH, as they may not want to use that toolchain systemwide. Support those developers by allowing them to supply the directory that the LLVM tools are available in, as it is no more complex to support than the version suffix change above. $ make ... LLVM=/path/to/llvm/ Update and reorder the documentation to reflect these new additions. At the same time, notate that LLVM=0 is not the same as just omitting it altogether, which has confused people in the past. Link: https://lore.kernel.org/r/20200317215515.226917-1-ndesaulniers@google.com/ Link: https://lore.kernel.org/r/20220224151322.072632223@infradead.org/ Suggested-by: Masahiro Yamada Suggested-by: Peter Zijlstra Signed-off-by: Nathan Chancellor Reviewed-by: Kees Cook Reviewed-by: Nick Desaulniers Signed-off-by: Masahiro Yamada --- Documentation/kbuild/llvm.rst | 31 +++++++++++++++++++++++++------ 1 file changed, 25 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst index d32616891dcf..b854bb413164 100644 --- a/Documentation/kbuild/llvm.rst +++ b/Documentation/kbuild/llvm.rst @@ -49,17 +49,36 @@ example: :: LLVM Utilities -------------- -LLVM has substitutes for GNU binutils utilities. Kbuild supports ``LLVM=1`` -to enable them. :: - - make LLVM=1 - -They can be enabled individually. The full list of the parameters: :: +LLVM has substitutes for GNU binutils utilities. They can be enabled individually. +The full list of supported make variables:: make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \ OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \ HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld +To simplify the above command, Kbuild supports the ``LLVM`` variable:: + + make LLVM=1 + +If your LLVM tools are not available in your PATH, you can supply their +location using the LLVM variable with a trailing slash:: + + make LLVM=/path/to/llvm/ + +which will use ``/path/to/llvm/clang``, ``/path/to/llvm/ld.lld``, etc. + +If your LLVM tools have a version suffix and you want to test with that +explicit version rather than the unsuffixed executables like ``LLVM=1``, you +can pass the suffix using the ``LLVM`` variable:: + + make LLVM=-14 + +which will use ``clang-14``, ``ld.lld-14``, etc. + +``LLVM=0`` is not the same as omitting ``LLVM`` altogether, it will behave like +``LLVM=1``. If you only wish to use certain LLVM utilities, use their respective +make variables. + The integrated assembler is enabled by default. You can pass ``LLVM_IAS=0`` to disable it. -- cgit From 50386f7526dd7fd71a390966ea9736c8420aa31f Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 29 Mar 2022 21:24:52 -0700 Subject: docs: netdev: replace references to old archives Most people use (or should use) lore at this point. Replace the pointers to older archiving systems. Signed-off-by: Jakub Kicinski Reviewed-by: Florian Fainelli Signed-off-by: Paolo Abeni --- Documentation/networking/netdev-FAQ.rst | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index e26532f49760..25b8a7de737c 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -16,10 +16,8 @@ Note that some subsystems (e.g. wireless drivers) which have a high volume of traffic have their own specific mailing lists. The netdev list is managed (like many other Linux mailing lists) through -VGER (http://vger.kernel.org/) and archives can be found below: - -- http://marc.info/?l=linux-netdev -- http://www.spinics.net/lists/netdev/ +VGER (http://vger.kernel.org/) with archives available at +https://lore.kernel.org/netdev/ Aside from subsystems like that mentioned above, all network-related Linux development (i.e. RFC, review, comments, etc.) takes place on -- cgit From 30cddd30532a72f857abf9d7c80d8b620fd3e5a1 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 29 Mar 2022 21:24:53 -0700 Subject: docs: netdev: minor reword that -> those Signed-off-by: Jakub Kicinski Reviewed-by: Florian Fainelli Signed-off-by: Paolo Abeni --- Documentation/networking/netdev-FAQ.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index 25b8a7de737c..f7e5755e013e 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -19,7 +19,7 @@ The netdev list is managed (like many other Linux mailing lists) through VGER (http://vger.kernel.org/) with archives available at https://lore.kernel.org/netdev/ -Aside from subsystems like that mentioned above, all network-related +Aside from subsystems like those mentioned above, all network-related Linux development (i.e. RFC, review, comments, etc.) takes place on netdev. -- cgit From c82d90b14f6c23f4e7cd89944f9a89f89223dc58 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 29 Mar 2022 21:24:54 -0700 Subject: docs: netdev: move the patch marking section up We want people to mark their patches with net and net-next in the subject. Many miss doing that. Move the FAQ section which points that out up, and place it after the section which enumerates the trees, that seems like a pretty logical place for it. Since the two sections are together we can remove a little bit (not too much) of the repetition. v2: also remove the text for non-git setups, we want people to use git. Signed-off-by: Jakub Kicinski Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: Paolo Abeni --- Documentation/networking/netdev-FAQ.rst | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index f7e5755e013e..fd5f5a1a0846 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -35,6 +35,17 @@ for the future release. You can find the trees here: - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git +How do I indicate which tree (net vs. net-next) my patch should be in? +---------------------------------------------------------------------- +To help maintainers and CI bots you should explicitly mark which tree +your patch is targeting. Assuming that you use git, use the prefix +flag:: + + git format-patch --subject-prefix='PATCH net-next' start..finish + +Use ``net`` instead of ``net-next`` (always lower case) in the above for +bug-fix ``net`` content. + How often do changes from these trees make it to the mainline Linus tree? ------------------------------------------------------------------------- To understand this, you need to know a bit of background information on @@ -90,20 +101,6 @@ and note the top of the "tags" section. If it is rc1, it is early in the dev cycle. If it was tagged rc7 a week ago, then a release is probably imminent. -How do I indicate which tree (net vs. net-next) my patch should be in? ----------------------------------------------------------------------- -Firstly, think whether you have a bug fix or new "next-like" content. -Then once decided, assuming that you use git, use the prefix flag, i.e. -:: - - git format-patch --subject-prefix='PATCH net-next' start..finish - -Use ``net`` instead of ``net-next`` (always lower case) in the above for -bug-fix ``net`` content. If you don't use git, then note the only magic -in the above is just the subject text of the outgoing e-mail, and you -can manually change it yourself with whatever MUA you are comfortable -with. - I sent a patch and I'm wondering what happened to it - how can I tell whether it got merged? -------------------------------------------------------------------------------------------- Start by looking at the main patchworks queue for netdev: -- cgit From 2fd4c50dbff19eb3d798236074bfa3226b5df4a6 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 29 Mar 2022 21:24:55 -0700 Subject: docs: netdev: turn the net-next closed into a Warning Use the sphinx Warning box to make the net-next being closed stand out more. Signed-off-by: Jakub Kicinski Reviewed-by: Florian Fainelli Signed-off-by: Paolo Abeni --- Documentation/networking/netdev-FAQ.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index fd5f5a1a0846..041993258dda 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -70,8 +70,9 @@ relating to vX.Y An announcement indicating when ``net-next`` has been closed is usually sent to netdev, but knowing the above, you can predict that in advance. -IMPORTANT: Do not send new ``net-next`` content to netdev during the -period during which ``net-next`` tree is closed. +.. warning:: + Do not send new ``net-next`` content to netdev during the + period during which ``net-next`` tree is closed. Shortly after the two weeks have passed (and vX.Y-rc1 is released), the tree for ``net-next`` reopens to collect content for the next (vX.Y+1) -- cgit From 0e242e3fb7a7f6c120195c5a57faf78a321dbf65 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 29 Mar 2022 21:24:56 -0700 Subject: docs: netdev: note that RFC postings are allowed any time Document that RFCs are allowed during the merge window. Signed-off-by: Jakub Kicinski Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: Paolo Abeni --- Documentation/networking/netdev-FAQ.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index 041993258dda..f4c77efa75d4 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -74,6 +74,9 @@ sent to netdev, but knowing the above, you can predict that in advance. Do not send new ``net-next`` content to netdev during the period during which ``net-next`` tree is closed. +RFC patches sent for review only are obviously welcome at any time +(use ``--subject-prefix='RFC net-next'`` with ``git format-patch``). + Shortly after the two weeks have passed (and vX.Y-rc1 is released), the tree for ``net-next`` reopens to collect content for the next (vX.Y+1) release. -- cgit From 5d84921ac750d2b2e42c7102890b978cb2c2729e Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 29 Mar 2022 21:24:57 -0700 Subject: docs: netdev: shorten the name and mention msgid for patch status Cut down the length of the question so it renders better in docs. Mention that Message-ID can be used to search patchwork. Signed-off-by: Jakub Kicinski Reviewed-by: Florian Fainelli Signed-off-by: Paolo Abeni --- Documentation/networking/netdev-FAQ.rst | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index f4c77efa75d4..e10a8140d642 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -105,14 +105,16 @@ and note the top of the "tags" section. If it is rc1, it is early in the dev cycle. If it was tagged rc7 a week ago, then a release is probably imminent. -I sent a patch and I'm wondering what happened to it - how can I tell whether it got merged? --------------------------------------------------------------------------------------------- +How can I tell the status of a patch I've sent? +----------------------------------------------- Start by looking at the main patchworks queue for netdev: https://patchwork.kernel.org/project/netdevbpf/list/ The "State" field will tell you exactly where things are at with your -patch. +patch. Patches are indexed by the ``Message-ID`` header of the emails +which carried them so if you have trouble finding your patch append +the value of ``Message-ID`` to the URL above. The above only says "Under Review". How can I find out more? ------------------------------------------------------------- -- cgit From 8f785c1bb84f7c8ca07c408dc96e8d8358b02bb3 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 29 Mar 2022 21:24:58 -0700 Subject: docs: netdev: rephrase the 'Under review' question The semantics of "Under review" have shifted. Reword the question about it a bit and focus it on the response time. Signed-off-by: Jakub Kicinski Reviewed-by: Florian Fainelli Signed-off-by: Paolo Abeni --- Documentation/networking/netdev-FAQ.rst | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index e10a8140d642..00ac300ebe6a 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -116,10 +116,12 @@ patch. Patches are indexed by the ``Message-ID`` header of the emails which carried them so if you have trouble finding your patch append the value of ``Message-ID`` to the URL above. -The above only says "Under Review". How can I find out more? -------------------------------------------------------------- +How long before my patch is accepted? +------------------------------------- Generally speaking, the patches get triaged quickly (in less than -48h). So be patient. Asking the maintainer for status updates on your +48h). But be patient, if your patch is active in patchwork (i.e. it's +listed on the project's patch list) the chances it was missed are close to zero. +Asking the maintainer for status updates on your patch is a good way to ensure your patch is ignored or pushed to the bottom of the priority list. -- cgit From 724c1a7443c5ccb7cda9bfb5ccab84bcece2c50c Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 29 Mar 2022 21:24:59 -0700 Subject: docs: netdev: rephrase the 'should I update patchwork' question Make the question shorter and adjust the start of the answer accordingly. Signed-off-by: Jakub Kicinski Reviewed-by: Florian Fainelli Signed-off-by: Paolo Abeni --- Documentation/networking/netdev-FAQ.rst | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index 00ac300ebe6a..9c455d08510d 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -125,9 +125,11 @@ Asking the maintainer for status updates on your patch is a good way to ensure your patch is ignored or pushed to the bottom of the priority list. -I submitted multiple versions of the patch series. Should I directly update patchwork for the previous versions of these patch series? --------------------------------------------------------------------------------------------------------------------------------------- -No, please don't interfere with the patch status on patchwork, leave +Should I directly update patchwork state of my own patches? +----------------------------------------------------------- +It may be tempting to help the maintainers and update the state of your +own patches when you post a new version or spot a bug. Please do not do that. +Interfering with the patch status on patchwork will only cause confusion. Leave it to the maintainer to figure out what is the most recent and current version that should be applied. If there is any doubt, the maintainer will reply and ask what should be done. -- cgit From b8ba106378a058711d8abd0889351ff9c81850c1 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 29 Mar 2022 21:25:00 -0700 Subject: docs: netdev: add a question about re-posting frequency We have to tell people to stop reposting to often lately, or not to repost while the discussion is ongoing. Document this. Reviewed-by: Andrew Lunn Signed-off-by: Jakub Kicinski Reviewed-by: Florian Fainelli Signed-off-by: Paolo Abeni --- Documentation/networking/netdev-FAQ.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index 9c455d08510d..f8b89dc81cab 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -140,6 +140,17 @@ No, please resend the entire patch series and make sure you do number your patches such that it is clear this is the latest and greatest set of patches that can be applied. +I have received review feedback, when should I post a revised version of the patches? +------------------------------------------------------------------------------------- +Allow at least 24 hours to pass between postings. This will ensure reviewers +from all geographical locations have a chance to chime in. Do not wait +too long (weeks) between postings either as it will make it harder for reviewers +to recall all the context. + +Make sure you address all the feedback in your new posting. Do not post a new +version of the code if the discussion about the previous version is still +ongoing, unless directly instructed by a reviewer. + I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do? ---------------------------------------------------------------------------------------------------------------------------------------- There is no revert possible, once it is pushed out, it stays like that. -- cgit From 3eca381457ca58fbde16f827ddfaaecde3d61127 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 29 Mar 2022 21:25:01 -0700 Subject: docs: netdev: make the testing requirement more stringent These days we often ask for selftests so let's update our testing requirements. Signed-off-by: Jakub Kicinski Reviewed-by: Florian Fainelli Signed-off-by: Paolo Abeni --- Documentation/networking/netdev-FAQ.rst | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index f8b89dc81cab..1388f78cfbc5 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -196,11 +196,15 @@ as possible alternative mechanisms. What level of testing is expected before I submit my change? ------------------------------------------------------------ -If your changes are against ``net-next``, the expectation is that you -have tested by layering your changes on top of ``net-next``. Ideally -you will have done run-time testing specific to your change, but at a -minimum, your changes should survive an ``allyesconfig`` and an -``allmodconfig`` build without new warnings or failures. +At the very minimum your changes must survive an ``allyesconfig`` and an +``allmodconfig`` build with ``W=1`` set without new warnings or failures. + +Ideally you will have done run-time testing specific to your change, +and the patch series contains a set of kernel selftest for +``tools/testing/selftests/net`` or using the KUnit framework. + +You are expected to test your changes on top of the relevant networking +tree (``net`` or ``net-next``) and not e.g. a stable tree or ``linux-next``. How do I post corresponding changes to user space components? ------------------------------------------------------------- -- cgit From a300597318771f889136db36f9f0dcfd26b84f18 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 29 Mar 2022 21:25:02 -0700 Subject: docs: netdev: add missing back ticks I think double back ticks are more correct. Add where they are missing. Signed-off-by: Jakub Kicinski Reviewed-by: Florian Fainelli Signed-off-by: Paolo Abeni --- Documentation/networking/netdev-FAQ.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index 1388f78cfbc5..294ad9b0162d 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -218,7 +218,7 @@ or the user space project is not reviewed on netdev include a link to a public repo where user space patches can be seen. In case user space tooling lives in a separate repository but is -reviewed on netdev (e.g. patches to `iproute2` tools) kernel and +reviewed on netdev (e.g. patches to ``iproute2`` tools) kernel and user space patches should form separate series (threads) when posted to the mailing list, e.g.:: @@ -251,18 +251,18 @@ traffic if we can help it. netdevsim is great, can I extend it for my out-of-tree tests? ------------------------------------------------------------- -No, `netdevsim` is a test vehicle solely for upstream tests. -(Please add your tests under tools/testing/selftests/.) +No, ``netdevsim`` is a test vehicle solely for upstream tests. +(Please add your tests under ``tools/testing/selftests/``.) -We also give no guarantees that `netdevsim` won't change in the future +We also give no guarantees that ``netdevsim`` won't change in the future in a way which would break what would normally be considered uAPI. Is netdevsim considered a "user" of an API? ------------------------------------------- Linux kernel has a long standing rule that no API should be added unless -it has a real, in-tree user. Mock-ups and tests based on `netdevsim` are -strongly encouraged when adding new APIs, but `netdevsim` in itself +it has a real, in-tree user. Mock-ups and tests based on ``netdevsim`` are +strongly encouraged when adding new APIs, but ``netdevsim`` in itself is **not** considered a use case/user. Any other tips to help ensure my net/net-next patch gets OK'd? -- cgit From 99eba4e5cbd462db47dcb949af6d5474acdac953 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 29 Mar 2022 21:25:03 -0700 Subject: docs: netdev: call out the merge window in tag checking Add the most important case to the question about "where are we in the cycle" - the case of net-next being closed. Signed-off-by: Jakub Kicinski Reviewed-by: Florian Fainelli Signed-off-by: Paolo Abeni --- Documentation/networking/netdev-FAQ.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index 294ad9b0162d..a18e4e671e85 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -103,7 +103,9 @@ Load the mainline (Linus) page here: and note the top of the "tags" section. If it is rc1, it is early in the dev cycle. If it was tagged rc7 a week ago, then a release is -probably imminent. +probably imminent. If the most recent tag is a final release tag +(without an ``-rcN`` suffix) - we are most likely in a merge window +and ``net-next`` is closed. How can I tell the status of a patch I've sent? ----------------------------------------------- -- cgit From 08767a26f095909423f963c864f15db50c0ce9a7 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 29 Mar 2022 21:25:04 -0700 Subject: docs: netdev: broaden the new vs old code formatting guidelines Convert the "should I use new or old comment formatting" to cover all formatting. This makes the question itself shorter. Signed-off-by: Jakub Kicinski Reviewed-by: Florian Fainelli Signed-off-by: Paolo Abeni --- Documentation/networking/netdev-FAQ.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index a18e4e671e85..c456b5225d66 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -183,10 +183,10 @@ it is requested that you make it look like this:: * another line of text */ -I am working in existing code that has the former comment style and not the latter. Should I submit new code in the former style or the latter? ------------------------------------------------------------------------------------------------------------------------------------------------ -Make it the latter style, so that eventually all code in the domain -of netdev is of this format. +I am working in existing code which uses non-standard formatting. Which formatting should I use? +------------------------------------------------------------------------------------------------ +Make your code follow the most recent guidelines, so that eventually all code +in the domain of netdev is in the preferred format. I found a bug that might have possible security implications or similar. Should I mail the main netdev maintainer off-list? --------------------------------------------------------------------------------------------------------------------------- -- cgit From 8df0136376dc9227a45fd6a1420016f58792b5d0 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 29 Mar 2022 21:25:05 -0700 Subject: docs: netdev: move the netdev-FAQ to the process pages The documentation for the tip tree is really in quite a similar spirit to the netdev-FAQ. Move the netdev-FAQ to the process docs as well. Signed-off-by: Jakub Kicinski Reviewed-by: Florian Fainelli Signed-off-by: Paolo Abeni --- Documentation/bpf/bpf_devel_QA.rst | 2 +- Documentation/networking/index.rst | 3 +- Documentation/networking/netdev-FAQ.rst | 285 ------------------------- Documentation/process/maintainer-handbooks.rst | 1 + Documentation/process/maintainer-netdev.rst | 285 +++++++++++++++++++++++++ 5 files changed, 289 insertions(+), 287 deletions(-) delete mode 100644 Documentation/networking/netdev-FAQ.rst create mode 100644 Documentation/process/maintainer-netdev.rst (limited to 'Documentation') diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst index 253496af8fef..761474bd7fe6 100644 --- a/Documentation/bpf/bpf_devel_QA.rst +++ b/Documentation/bpf/bpf_devel_QA.rst @@ -658,7 +658,7 @@ when: .. Links .. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/ -.. _netdev-FAQ: ../networking/netdev-FAQ.rst +.. _netdev-FAQ: Documentation/process/maintainer-netdev.rst .. _selftests: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/ .. _Documentation/dev-tools/kselftest.rst: diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index ce017136ab05..72cf33579b78 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -1,12 +1,13 @@ Linux Networking Documentation ============================== +Refer to :ref:`netdev-FAQ` for a guide on netdev development process specifics. + Contents: .. toctree:: :maxdepth: 2 - netdev-FAQ af_xdp bareudp batman-adv diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst deleted file mode 100644 index c456b5225d66..000000000000 --- a/Documentation/networking/netdev-FAQ.rst +++ /dev/null @@ -1,285 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -.. _netdev-FAQ: - -========== -netdev FAQ -========== - -What is netdev? ---------------- -It is a mailing list for all network-related Linux stuff. This -includes anything found under net/ (i.e. core code like IPv6) and -drivers/net (i.e. hardware specific drivers) in the Linux source tree. - -Note that some subsystems (e.g. wireless drivers) which have a high -volume of traffic have their own specific mailing lists. - -The netdev list is managed (like many other Linux mailing lists) through -VGER (http://vger.kernel.org/) with archives available at -https://lore.kernel.org/netdev/ - -Aside from subsystems like those mentioned above, all network-related -Linux development (i.e. RFC, review, comments, etc.) takes place on -netdev. - -How do the changes posted to netdev make their way into Linux? --------------------------------------------------------------- -There are always two trees (git repositories) in play. Both are -driven by David Miller, the main network maintainer. There is the -``net`` tree, and the ``net-next`` tree. As you can probably guess from -the names, the ``net`` tree is for fixes to existing code already in the -mainline tree from Linus, and ``net-next`` is where the new code goes -for the future release. You can find the trees here: - -- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git -- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git - -How do I indicate which tree (net vs. net-next) my patch should be in? ----------------------------------------------------------------------- -To help maintainers and CI bots you should explicitly mark which tree -your patch is targeting. Assuming that you use git, use the prefix -flag:: - - git format-patch --subject-prefix='PATCH net-next' start..finish - -Use ``net`` instead of ``net-next`` (always lower case) in the above for -bug-fix ``net`` content. - -How often do changes from these trees make it to the mainline Linus tree? -------------------------------------------------------------------------- -To understand this, you need to know a bit of background information on -the cadence of Linux development. Each new release starts off with a -two week "merge window" where the main maintainers feed their new stuff -to Linus for merging into the mainline tree. After the two weeks, the -merge window is closed, and it is called/tagged ``-rc1``. No new -features get mainlined after this -- only fixes to the rc1 content are -expected. After roughly a week of collecting fixes to the rc1 content, -rc2 is released. This repeats on a roughly weekly basis until rc7 -(typically; sometimes rc6 if things are quiet, or rc8 if things are in a -state of churn), and a week after the last vX.Y-rcN was done, the -official vX.Y is released. - -Relating that to netdev: At the beginning of the 2-week merge window, -the ``net-next`` tree will be closed - no new changes/features. The -accumulated new content of the past ~10 weeks will be passed onto -mainline/Linus via a pull request for vX.Y -- at the same time, the -``net`` tree will start accumulating fixes for this pulled content -relating to vX.Y - -An announcement indicating when ``net-next`` has been closed is usually -sent to netdev, but knowing the above, you can predict that in advance. - -.. warning:: - Do not send new ``net-next`` content to netdev during the - period during which ``net-next`` tree is closed. - -RFC patches sent for review only are obviously welcome at any time -(use ``--subject-prefix='RFC net-next'`` with ``git format-patch``). - -Shortly after the two weeks have passed (and vX.Y-rc1 is released), the -tree for ``net-next`` reopens to collect content for the next (vX.Y+1) -release. - -If you aren't subscribed to netdev and/or are simply unsure if -``net-next`` has re-opened yet, simply check the ``net-next`` git -repository link above for any new networking-related commits. You may -also check the following website for the current status: - - http://vger.kernel.org/~davem/net-next.html - -The ``net`` tree continues to collect fixes for the vX.Y content, and is -fed back to Linus at regular (~weekly) intervals. Meaning that the -focus for ``net`` is on stabilization and bug fixes. - -Finally, the vX.Y gets released, and the whole cycle starts over. - -So where are we now in this cycle? ----------------------------------- - -Load the mainline (Linus) page here: - - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git - -and note the top of the "tags" section. If it is rc1, it is early in -the dev cycle. If it was tagged rc7 a week ago, then a release is -probably imminent. If the most recent tag is a final release tag -(without an ``-rcN`` suffix) - we are most likely in a merge window -and ``net-next`` is closed. - -How can I tell the status of a patch I've sent? ------------------------------------------------ -Start by looking at the main patchworks queue for netdev: - - https://patchwork.kernel.org/project/netdevbpf/list/ - -The "State" field will tell you exactly where things are at with your -patch. Patches are indexed by the ``Message-ID`` header of the emails -which carried them so if you have trouble finding your patch append -the value of ``Message-ID`` to the URL above. - -How long before my patch is accepted? -------------------------------------- -Generally speaking, the patches get triaged quickly (in less than -48h). But be patient, if your patch is active in patchwork (i.e. it's -listed on the project's patch list) the chances it was missed are close to zero. -Asking the maintainer for status updates on your -patch is a good way to ensure your patch is ignored or pushed to the -bottom of the priority list. - -Should I directly update patchwork state of my own patches? ------------------------------------------------------------ -It may be tempting to help the maintainers and update the state of your -own patches when you post a new version or spot a bug. Please do not do that. -Interfering with the patch status on patchwork will only cause confusion. Leave -it to the maintainer to figure out what is the most recent and current -version that should be applied. If there is any doubt, the maintainer -will reply and ask what should be done. - -I made changes to only a few patches in a patch series should I resend only those changed? ------------------------------------------------------------------------------------------- -No, please resend the entire patch series and make sure you do number your -patches such that it is clear this is the latest and greatest set of patches -that can be applied. - -I have received review feedback, when should I post a revised version of the patches? -------------------------------------------------------------------------------------- -Allow at least 24 hours to pass between postings. This will ensure reviewers -from all geographical locations have a chance to chime in. Do not wait -too long (weeks) between postings either as it will make it harder for reviewers -to recall all the context. - -Make sure you address all the feedback in your new posting. Do not post a new -version of the code if the discussion about the previous version is still -ongoing, unless directly instructed by a reviewer. - -I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do? ----------------------------------------------------------------------------------------------------------------------------------------- -There is no revert possible, once it is pushed out, it stays like that. -Please send incremental versions on top of what has been merged in order to fix -the patches the way they would look like if your latest patch series was to be -merged. - -Are there special rules regarding stable submissions on netdev? ---------------------------------------------------------------- -While it used to be the case that netdev submissions were not supposed -to carry explicit ``CC: stable@vger.kernel.org`` tags that is no longer -the case today. Please follow the standard stable rules in -:ref:`Documentation/process/stable-kernel-rules.rst `, -and make sure you include appropriate Fixes tags! - -Is the comment style convention different for the networking content? ---------------------------------------------------------------------- -Yes, in a largely trivial way. Instead of this:: - - /* - * foobar blah blah blah - * another line of text - */ - -it is requested that you make it look like this:: - - /* foobar blah blah blah - * another line of text - */ - -I am working in existing code which uses non-standard formatting. Which formatting should I use? ------------------------------------------------------------------------------------------------- -Make your code follow the most recent guidelines, so that eventually all code -in the domain of netdev is in the preferred format. - -I found a bug that might have possible security implications or similar. Should I mail the main netdev maintainer off-list? ---------------------------------------------------------------------------------------------------------------------------- -No. The current netdev maintainer has consistently requested that -people use the mailing lists and not reach out directly. If you aren't -OK with that, then perhaps consider mailing security@kernel.org or -reading about http://oss-security.openwall.org/wiki/mailing-lists/distros -as possible alternative mechanisms. - -What level of testing is expected before I submit my change? ------------------------------------------------------------- -At the very minimum your changes must survive an ``allyesconfig`` and an -``allmodconfig`` build with ``W=1`` set without new warnings or failures. - -Ideally you will have done run-time testing specific to your change, -and the patch series contains a set of kernel selftest for -``tools/testing/selftests/net`` or using the KUnit framework. - -You are expected to test your changes on top of the relevant networking -tree (``net`` or ``net-next``) and not e.g. a stable tree or ``linux-next``. - -How do I post corresponding changes to user space components? -------------------------------------------------------------- -User space code exercising kernel features should be posted -alongside kernel patches. This gives reviewers a chance to see -how any new interface is used and how well it works. - -When user space tools reside in the kernel repo itself all changes -should generally come as one series. If series becomes too large -or the user space project is not reviewed on netdev include a link -to a public repo where user space patches can be seen. - -In case user space tooling lives in a separate repository but is -reviewed on netdev (e.g. patches to ``iproute2`` tools) kernel and -user space patches should form separate series (threads) when posted -to the mailing list, e.g.:: - - [PATCH net-next 0/3] net: some feature cover letter - └─ [PATCH net-next 1/3] net: some feature prep - └─ [PATCH net-next 2/3] net: some feature do it - └─ [PATCH net-next 3/3] selftest: net: some feature - - [PATCH iproute2-next] ip: add support for some feature - -Posting as one thread is discouraged because it confuses patchwork -(as of patchwork 2.2.2). - -Can I reproduce the checks from patchwork on my local machine? --------------------------------------------------------------- - -Checks in patchwork are mostly simple wrappers around existing kernel -scripts, the sources are available at: - -https://github.com/kuba-moo/nipa/tree/master/tests - -Running all the builds and checks locally is a pain, can I post my patches and have the patchwork bot validate them? --------------------------------------------------------------------------------------------------------------------- - -No, you must ensure that your patches are ready by testing them locally -before posting to the mailing list. The patchwork build bot instance -gets overloaded very easily and netdev@vger really doesn't need more -traffic if we can help it. - -netdevsim is great, can I extend it for my out-of-tree tests? -------------------------------------------------------------- - -No, ``netdevsim`` is a test vehicle solely for upstream tests. -(Please add your tests under ``tools/testing/selftests/``.) - -We also give no guarantees that ``netdevsim`` won't change in the future -in a way which would break what would normally be considered uAPI. - -Is netdevsim considered a "user" of an API? -------------------------------------------- - -Linux kernel has a long standing rule that no API should be added unless -it has a real, in-tree user. Mock-ups and tests based on ``netdevsim`` are -strongly encouraged when adding new APIs, but ``netdevsim`` in itself -is **not** considered a use case/user. - -Any other tips to help ensure my net/net-next patch gets OK'd? --------------------------------------------------------------- -Attention to detail. Re-read your own work as if you were the -reviewer. You can start with using ``checkpatch.pl``, perhaps even with -the ``--strict`` flag. But do not be mindlessly robotic in doing so. -If your change is a bug fix, make sure your commit log indicates the -end-user visible symptom, the underlying reason as to why it happens, -and then if necessary, explain why the fix proposed is the best way to -get things done. Don't mangle whitespace, and as is common, don't -mis-indent function arguments that span multiple lines. If it is your -first patch, mail it to yourself so you can test apply it to an -unpatched tree to confirm infrastructure didn't mangle it. - -Finally, go back and read -:ref:`Documentation/process/submitting-patches.rst ` -to be sure you are not repeating some common mistake documented there. diff --git a/Documentation/process/maintainer-handbooks.rst b/Documentation/process/maintainer-handbooks.rst index 6af1abb0da48..d783060b4cc6 100644 --- a/Documentation/process/maintainer-handbooks.rst +++ b/Documentation/process/maintainer-handbooks.rst @@ -16,3 +16,4 @@ Contents: :maxdepth: 2 maintainer-tip + maintainer-netdev diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst new file mode 100644 index 000000000000..c456b5225d66 --- /dev/null +++ b/Documentation/process/maintainer-netdev.rst @@ -0,0 +1,285 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _netdev-FAQ: + +========== +netdev FAQ +========== + +What is netdev? +--------------- +It is a mailing list for all network-related Linux stuff. This +includes anything found under net/ (i.e. core code like IPv6) and +drivers/net (i.e. hardware specific drivers) in the Linux source tree. + +Note that some subsystems (e.g. wireless drivers) which have a high +volume of traffic have their own specific mailing lists. + +The netdev list is managed (like many other Linux mailing lists) through +VGER (http://vger.kernel.org/) with archives available at +https://lore.kernel.org/netdev/ + +Aside from subsystems like those mentioned above, all network-related +Linux development (i.e. RFC, review, comments, etc.) takes place on +netdev. + +How do the changes posted to netdev make their way into Linux? +-------------------------------------------------------------- +There are always two trees (git repositories) in play. Both are +driven by David Miller, the main network maintainer. There is the +``net`` tree, and the ``net-next`` tree. As you can probably guess from +the names, the ``net`` tree is for fixes to existing code already in the +mainline tree from Linus, and ``net-next`` is where the new code goes +for the future release. You can find the trees here: + +- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git +- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git + +How do I indicate which tree (net vs. net-next) my patch should be in? +---------------------------------------------------------------------- +To help maintainers and CI bots you should explicitly mark which tree +your patch is targeting. Assuming that you use git, use the prefix +flag:: + + git format-patch --subject-prefix='PATCH net-next' start..finish + +Use ``net`` instead of ``net-next`` (always lower case) in the above for +bug-fix ``net`` content. + +How often do changes from these trees make it to the mainline Linus tree? +------------------------------------------------------------------------- +To understand this, you need to know a bit of background information on +the cadence of Linux development. Each new release starts off with a +two week "merge window" where the main maintainers feed their new stuff +to Linus for merging into the mainline tree. After the two weeks, the +merge window is closed, and it is called/tagged ``-rc1``. No new +features get mainlined after this -- only fixes to the rc1 content are +expected. After roughly a week of collecting fixes to the rc1 content, +rc2 is released. This repeats on a roughly weekly basis until rc7 +(typically; sometimes rc6 if things are quiet, or rc8 if things are in a +state of churn), and a week after the last vX.Y-rcN was done, the +official vX.Y is released. + +Relating that to netdev: At the beginning of the 2-week merge window, +the ``net-next`` tree will be closed - no new changes/features. The +accumulated new content of the past ~10 weeks will be passed onto +mainline/Linus via a pull request for vX.Y -- at the same time, the +``net`` tree will start accumulating fixes for this pulled content +relating to vX.Y + +An announcement indicating when ``net-next`` has been closed is usually +sent to netdev, but knowing the above, you can predict that in advance. + +.. warning:: + Do not send new ``net-next`` content to netdev during the + period during which ``net-next`` tree is closed. + +RFC patches sent for review only are obviously welcome at any time +(use ``--subject-prefix='RFC net-next'`` with ``git format-patch``). + +Shortly after the two weeks have passed (and vX.Y-rc1 is released), the +tree for ``net-next`` reopens to collect content for the next (vX.Y+1) +release. + +If you aren't subscribed to netdev and/or are simply unsure if +``net-next`` has re-opened yet, simply check the ``net-next`` git +repository link above for any new networking-related commits. You may +also check the following website for the current status: + + http://vger.kernel.org/~davem/net-next.html + +The ``net`` tree continues to collect fixes for the vX.Y content, and is +fed back to Linus at regular (~weekly) intervals. Meaning that the +focus for ``net`` is on stabilization and bug fixes. + +Finally, the vX.Y gets released, and the whole cycle starts over. + +So where are we now in this cycle? +---------------------------------- + +Load the mainline (Linus) page here: + + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git + +and note the top of the "tags" section. If it is rc1, it is early in +the dev cycle. If it was tagged rc7 a week ago, then a release is +probably imminent. If the most recent tag is a final release tag +(without an ``-rcN`` suffix) - we are most likely in a merge window +and ``net-next`` is closed. + +How can I tell the status of a patch I've sent? +----------------------------------------------- +Start by looking at the main patchworks queue for netdev: + + https://patchwork.kernel.org/project/netdevbpf/list/ + +The "State" field will tell you exactly where things are at with your +patch. Patches are indexed by the ``Message-ID`` header of the emails +which carried them so if you have trouble finding your patch append +the value of ``Message-ID`` to the URL above. + +How long before my patch is accepted? +------------------------------------- +Generally speaking, the patches get triaged quickly (in less than +48h). But be patient, if your patch is active in patchwork (i.e. it's +listed on the project's patch list) the chances it was missed are close to zero. +Asking the maintainer for status updates on your +patch is a good way to ensure your patch is ignored or pushed to the +bottom of the priority list. + +Should I directly update patchwork state of my own patches? +----------------------------------------------------------- +It may be tempting to help the maintainers and update the state of your +own patches when you post a new version or spot a bug. Please do not do that. +Interfering with the patch status on patchwork will only cause confusion. Leave +it to the maintainer to figure out what is the most recent and current +version that should be applied. If there is any doubt, the maintainer +will reply and ask what should be done. + +I made changes to only a few patches in a patch series should I resend only those changed? +------------------------------------------------------------------------------------------ +No, please resend the entire patch series and make sure you do number your +patches such that it is clear this is the latest and greatest set of patches +that can be applied. + +I have received review feedback, when should I post a revised version of the patches? +------------------------------------------------------------------------------------- +Allow at least 24 hours to pass between postings. This will ensure reviewers +from all geographical locations have a chance to chime in. Do not wait +too long (weeks) between postings either as it will make it harder for reviewers +to recall all the context. + +Make sure you address all the feedback in your new posting. Do not post a new +version of the code if the discussion about the previous version is still +ongoing, unless directly instructed by a reviewer. + +I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do? +---------------------------------------------------------------------------------------------------------------------------------------- +There is no revert possible, once it is pushed out, it stays like that. +Please send incremental versions on top of what has been merged in order to fix +the patches the way they would look like if your latest patch series was to be +merged. + +Are there special rules regarding stable submissions on netdev? +--------------------------------------------------------------- +While it used to be the case that netdev submissions were not supposed +to carry explicit ``CC: stable@vger.kernel.org`` tags that is no longer +the case today. Please follow the standard stable rules in +:ref:`Documentation/process/stable-kernel-rules.rst `, +and make sure you include appropriate Fixes tags! + +Is the comment style convention different for the networking content? +--------------------------------------------------------------------- +Yes, in a largely trivial way. Instead of this:: + + /* + * foobar blah blah blah + * another line of text + */ + +it is requested that you make it look like this:: + + /* foobar blah blah blah + * another line of text + */ + +I am working in existing code which uses non-standard formatting. Which formatting should I use? +------------------------------------------------------------------------------------------------ +Make your code follow the most recent guidelines, so that eventually all code +in the domain of netdev is in the preferred format. + +I found a bug that might have possible security implications or similar. Should I mail the main netdev maintainer off-list? +--------------------------------------------------------------------------------------------------------------------------- +No. The current netdev maintainer has consistently requested that +people use the mailing lists and not reach out directly. If you aren't +OK with that, then perhaps consider mailing security@kernel.org or +reading about http://oss-security.openwall.org/wiki/mailing-lists/distros +as possible alternative mechanisms. + +What level of testing is expected before I submit my change? +------------------------------------------------------------ +At the very minimum your changes must survive an ``allyesconfig`` and an +``allmodconfig`` build with ``W=1`` set without new warnings or failures. + +Ideally you will have done run-time testing specific to your change, +and the patch series contains a set of kernel selftest for +``tools/testing/selftests/net`` or using the KUnit framework. + +You are expected to test your changes on top of the relevant networking +tree (``net`` or ``net-next``) and not e.g. a stable tree or ``linux-next``. + +How do I post corresponding changes to user space components? +------------------------------------------------------------- +User space code exercising kernel features should be posted +alongside kernel patches. This gives reviewers a chance to see +how any new interface is used and how well it works. + +When user space tools reside in the kernel repo itself all changes +should generally come as one series. If series becomes too large +or the user space project is not reviewed on netdev include a link +to a public repo where user space patches can be seen. + +In case user space tooling lives in a separate repository but is +reviewed on netdev (e.g. patches to ``iproute2`` tools) kernel and +user space patches should form separate series (threads) when posted +to the mailing list, e.g.:: + + [PATCH net-next 0/3] net: some feature cover letter + └─ [PATCH net-next 1/3] net: some feature prep + └─ [PATCH net-next 2/3] net: some feature do it + └─ [PATCH net-next 3/3] selftest: net: some feature + + [PATCH iproute2-next] ip: add support for some feature + +Posting as one thread is discouraged because it confuses patchwork +(as of patchwork 2.2.2). + +Can I reproduce the checks from patchwork on my local machine? +-------------------------------------------------------------- + +Checks in patchwork are mostly simple wrappers around existing kernel +scripts, the sources are available at: + +https://github.com/kuba-moo/nipa/tree/master/tests + +Running all the builds and checks locally is a pain, can I post my patches and have the patchwork bot validate them? +-------------------------------------------------------------------------------------------------------------------- + +No, you must ensure that your patches are ready by testing them locally +before posting to the mailing list. The patchwork build bot instance +gets overloaded very easily and netdev@vger really doesn't need more +traffic if we can help it. + +netdevsim is great, can I extend it for my out-of-tree tests? +------------------------------------------------------------- + +No, ``netdevsim`` is a test vehicle solely for upstream tests. +(Please add your tests under ``tools/testing/selftests/``.) + +We also give no guarantees that ``netdevsim`` won't change in the future +in a way which would break what would normally be considered uAPI. + +Is netdevsim considered a "user" of an API? +------------------------------------------- + +Linux kernel has a long standing rule that no API should be added unless +it has a real, in-tree user. Mock-ups and tests based on ``netdevsim`` are +strongly encouraged when adding new APIs, but ``netdevsim`` in itself +is **not** considered a use case/user. + +Any other tips to help ensure my net/net-next patch gets OK'd? +-------------------------------------------------------------- +Attention to detail. Re-read your own work as if you were the +reviewer. You can start with using ``checkpatch.pl``, perhaps even with +the ``--strict`` flag. But do not be mindlessly robotic in doing so. +If your change is a bug fix, make sure your commit log indicates the +end-user visible symptom, the underlying reason as to why it happens, +and then if necessary, explain why the fix proposed is the best way to +get things done. Don't mangle whitespace, and as is common, don't +mis-indent function arguments that span multiple lines. If it is your +first patch, mail it to yourself so you can test apply it to an +unpatched tree to confirm infrastructure didn't mangle it. + +Finally, go back and read +:ref:`Documentation/process/submitting-patches.rst ` +to be sure you are not repeating some common mistake documented there. -- cgit From dd550c7cdbe3087adfd51360931938db4de8e832 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Tue, 29 Mar 2022 10:50:05 +0200 Subject: dt-bindings: display: bridge: tc358867: Document DPI output support The TC358767/TC358867/TC9595 are all capable of operating in multiple modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Document support for the DPI output port, which can now be connected both as input and output. Acked-by: Rob Herring Reviewed-by: Lucas Stach Tested-by: Lucas Stach # In both DPI to eDP and DSI to DPI mode. Signed-off-by: Marek Vasut Cc: Jonas Karlman Cc: Laurent Pinchart Cc: Maxime Ripard Cc: Neil Armstrong Cc: Rob Herring Cc: Sam Ravnborg Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220329085015.39159-2-marex@denx.de --- .../devicetree/bindings/display/bridge/toshiba,tc358767.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml index f1541cc05297..5cfda6f2ba69 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml @@ -61,8 +61,8 @@ properties: port@1: $ref: /schemas/graph.yaml#/properties/port description: | - DPI input port. The remote endpoint phandle should be a - reference to a valid DPI output endpoint node + DPI input/output port. The remote endpoint phandle should be a + reference to a valid DPI output or input endpoint node. port@2: $ref: /schemas/graph.yaml#/properties/port -- cgit From 9ba328035e68a2eae973f0c9fbb5df15f160612c Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Tue, 29 Mar 2022 10:50:06 +0200 Subject: dt-bindings: display: bridge: tc358867: Document DSI data-lanes property It is necessary to specify the number of connected/used DSI data lanes when using the DSI input port of this bridge. Document the 'data-lanes' property of the DSI input port. Reviewed-by: Rob Herring Acked-by: Lucas Stach Tested-by: Lucas Stach # In both DPI to eDP and DSI to DPI mode. Signed-off-by: Marek Vasut Cc: Jonas Karlman Cc: Laurent Pinchart Cc: Maxime Ripard Cc: Neil Armstrong Cc: Rob Herring Cc: Sam Ravnborg Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220329085015.39159-3-marex@denx.de --- .../bindings/display/bridge/toshiba,tc358767.yaml | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml index 5cfda6f2ba69..ed280053ec62 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml @@ -53,11 +53,27 @@ properties: properties: port@0: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: | DSI input port. The remote endpoint phandle should be a reference to a valid DSI output endpoint node + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + description: array of physical DSI data lane indexes. + minItems: 1 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + port@1: $ref: /schemas/graph.yaml#/properties/port description: | -- cgit From 8933e7f2e37549cf54ad1133476bda8ec05b68ea Mon Sep 17 00:00:00 2001 From: Bagas Sanjaya Date: Tue, 29 Mar 2022 15:44:28 +0700 Subject: Documentation: riscv: remove non-existent directory from table of contents This subdir no longer exists: it was there to document some of the quirks and paths forward for handling them, but those have been dealt with as of Atish's recent patch set. Fixes: 23b1f18326ec ("Documentation: riscv: Remove the old documentation") Link: https://lore.kernel.org/linux-next/20220329133412.591d6882@canb.auug.org.au/ Reported-by: Stephen Rothwell Signed-off-by: Bagas Sanjaya [Palmer: commit text] Signed-off-by: Palmer Dabbelt --- Documentation/riscv/index.rst | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst index ea915c196048..e23b876ad6eb 100644 --- a/Documentation/riscv/index.rst +++ b/Documentation/riscv/index.rst @@ -7,7 +7,6 @@ RISC-V architecture boot-image-header vm-layout - pmu patch-acceptance features -- cgit From 704528d895dd3e7b173e672116b4eb2b0a0fceb0 Mon Sep 17 00:00:00 2001 From: "Matthew Wilcox (Oracle)" Date: Wed, 23 Mar 2022 21:29:04 -0400 Subject: fs: Remove ->readpages address space operation All filesystems have now been converted to use ->readahead, so remove the ->readpages operation and fix all the comments that used to refer to it. Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: Christoph Hellwig Reviewed-by: Al Viro Acked-by: Al Viro --- Documentation/filesystems/fsverity.rst | 6 +++--- Documentation/filesystems/locking.rst | 6 ------ Documentation/filesystems/vfs.rst | 11 ----------- 3 files changed, 3 insertions(+), 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst index 1d831e3cbcb3..8cc536d08f51 100644 --- a/Documentation/filesystems/fsverity.rst +++ b/Documentation/filesystems/fsverity.rst @@ -549,7 +549,7 @@ Pagecache ~~~~~~~~~ For filesystems using Linux's pagecache, the ``->readpage()`` and -``->readpages()`` methods must be modified to verify pages before they +``->readahead()`` methods must be modified to verify pages before they are marked Uptodate. Merely hooking ``->read_iter()`` would be insufficient, since ``->read_iter()`` is not used for memory maps. @@ -611,7 +611,7 @@ workqueue, and then the workqueue work does the decryption or verification. Finally, pages where no decryption or verity error occurred are marked Uptodate, and the pages are unlocked. -Files on ext4 and f2fs may contain holes. Normally, ``->readpages()`` +Files on ext4 and f2fs may contain holes. Normally, ``->readahead()`` simply zeroes holes and sets the corresponding pages Uptodate; no bios are issued. To prevent this case from bypassing fs-verity, these filesystems use fsverity_verify_page() to verify hole pages. @@ -778,7 +778,7 @@ weren't already directly answered in other parts of this document. - To prevent bypassing verification, pages must not be marked Uptodate until they've been verified. Currently, each filesystem is responsible for marking pages Uptodate via - ``->readpages()``. Therefore, currently it's not possible for + ``->readahead()``. Therefore, currently it's not possible for the VFS to do the verification on its own. Changing this would require significant changes to the VFS and all filesystems. diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 2998cec9af4b..c26d854275a0 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -241,8 +241,6 @@ prototypes:: int (*writepages)(struct address_space *, struct writeback_control *); bool (*dirty_folio)(struct address_space *, struct folio *folio); void (*readahead)(struct readahead_control *); - int (*readpages)(struct file *filp, struct address_space *mapping, - struct list_head *pages, unsigned nr_pages); int (*write_begin)(struct file *, struct address_space *mapping, loff_t pos, unsigned len, unsigned flags, struct page **pagep, void **fsdata); @@ -274,7 +272,6 @@ readpage: yes, unlocks shared writepages: dirty_folio maybe readahead: yes, unlocks shared -readpages: no shared write_begin: locks the page exclusive write_end: yes, unlocks exclusive bmap: @@ -300,9 +297,6 @@ completion. ->readahead() unlocks the pages that I/O is attempted on like ->readpage(). -->readpages() populates the pagecache with the passed pages and starts -I/O against them. They come unlocked upon I/O completion. - ->writepage() is used for two purposes: for "memory cleansing" and for "sync". These are quite different operations and the behaviour may differ depending upon the mode. diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index 4f14edf93941..794bd1a66bfb 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -726,8 +726,6 @@ cache in your filesystem. The following members are defined: int (*writepages)(struct address_space *, struct writeback_control *); bool (*dirty_folio)(struct address_space *, struct folio *); void (*readahead)(struct readahead_control *); - int (*readpages)(struct file *filp, struct address_space *mapping, - struct list_head *pages, unsigned nr_pages); int (*write_begin)(struct file *, struct address_space *mapping, loff_t pos, unsigned len, unsigned flags, struct page **pagep, void **fsdata); @@ -817,15 +815,6 @@ cache in your filesystem. The following members are defined: completes successfully. Setting PageError on any page will be ignored; simply unlock the page if an I/O error occurs. -``readpages`` - called by the VM to read pages associated with the address_space - object. This is essentially just a vector version of readpage. - Instead of just one page, several pages are requested. - readpages is only used for read-ahead, so read errors are - ignored. If anything goes wrong, feel free to give up. - This interface is deprecated and will be removed by the end of - 2020; implement readahead instead. - ``write_begin`` Called by the generic buffered write code to ask the filesystem to prepare to write len bytes at the given offset in the file. -- cgit From 577e9846f8a9e7b09cd356ae0d59a66e19402e8b Mon Sep 17 00:00:00 2001 From: Hugh Dickins Date: Fri, 1 Apr 2022 11:28:30 -0700 Subject: mm/munlock: update Documentation/vm/unevictable-lru.rst Update Documentation/vm/unevictable-lru.rst to reflect the changes made by the mm/munlock series: keeping an mlock_count instead of page_mlock() (formerly try_to_munlock()) and munlock_vma_pages_all() etc. Also make other little updates or cleanups wherever noticed. But, I apologize, this is already out of date, in that "folio" appears nowhere: 5.18 will be in a transitional state from "page" to "folio", and documenting its current mix of the two does not help to understand "the Unevictable LRU". Should be revisited when naming is more settled. Link: https://lkml.kernel.org/r/3753962-d491-bf60-f59f-51bfe84fd6a0@google.com Signed-off-by: Hugh Dickins Cc: Jonathan Corbet Cc: Randy Dunlap Cc: Matthew Wilcox Cc: Michal Hocko Cc: Vlastimil Babka Cc: "Kirill A. Shutemov" Cc: David Hildenbrand Cc: Alistair Popple Cc: Johannes Weiner Cc: Rik van Riel Cc: Suren Baghdasaryan Cc: Yu Zhao Cc: Greg Thelen Cc: Shakeel Butt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/unevictable-lru.rst | 471 ++++++++++++++++------------------- 1 file changed, 210 insertions(+), 261 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/unevictable-lru.rst b/Documentation/vm/unevictable-lru.rst index eae3af17f2d9..b280367d6a44 100644 --- a/Documentation/vm/unevictable-lru.rst +++ b/Documentation/vm/unevictable-lru.rst @@ -52,8 +52,13 @@ The infrastructure may also be able to handle other conditions that make pages unevictable, either by definition or by circumstance, in the future. -The Unevictable Page List -------------------------- +The Unevictable LRU Page List +----------------------------- + +The Unevictable LRU page list is a lie. It was never an LRU-ordered list, but a +companion to the LRU-ordered anonymous and file, active and inactive page lists; +and now it is not even a page list. But following familiar convention, here in +this document and in the source, we often imagine it as a fifth LRU page list. The Unevictable LRU infrastructure consists of an additional, per-node, LRU list called the "unevictable" list and an associated page flag, PG_unevictable, to @@ -63,8 +68,8 @@ The PG_unevictable flag is analogous to, and mutually exclusive with, the PG_active flag in that it indicates on which LRU list a page resides when PG_lru is set. -The Unevictable LRU infrastructure maintains unevictable pages on an additional -LRU list for a few reasons: +The Unevictable LRU infrastructure maintains unevictable pages as if they were +on an additional LRU list for a few reasons: (1) We get to "treat unevictable pages just like we treat other pages in the system - which means we get to use the same code to manipulate them, the @@ -72,13 +77,11 @@ LRU list for a few reasons: of the statistics, etc..." [Rik van Riel] (2) We want to be able to migrate unevictable pages between nodes for memory - defragmentation, workload management and memory hotplug. The linux kernel + defragmentation, workload management and memory hotplug. The Linux kernel can only migrate pages that it can successfully isolate from the LRU - lists. If we were to maintain pages elsewhere than on an LRU-like list, - where they can be found by isolate_lru_page(), we would prevent their - migration, unless we reworked migration code to find the unevictable pages - itself. - + lists (or "Movable" pages: outside of consideration here). If we were to + maintain pages elsewhere than on an LRU-like list, where they can be + detected by isolate_lru_page(), we would prevent their migration. The unevictable list does not differentiate between file-backed and anonymous, swap-backed pages. This differentiation is only important while the pages are, @@ -92,8 +95,8 @@ Memory Control Group Interaction -------------------------------- The unevictable LRU facility interacts with the memory control group [aka -memory controller; see Documentation/admin-guide/cgroup-v1/memory.rst] by extending the -lru_list enum. +memory controller; see Documentation/admin-guide/cgroup-v1/memory.rst] by +extending the lru_list enum. The memory controller data structure automatically gets a per-node unevictable list as a result of the "arrayification" of the per-node LRU lists (one per @@ -143,7 +146,6 @@ These are currently used in three places in the kernel: and this mark remains for the life of the inode. (2) By SYSV SHM to mark SHM_LOCK'd address spaces until SHM_UNLOCK is called. - Note that SHM_LOCK is not required to page in the locked pages if they're swapped out; the application must touch the pages manually if it wants to ensure they're in memory. @@ -156,19 +158,19 @@ These are currently used in three places in the kernel: Detecting Unevictable Pages --------------------------- -The function page_evictable() in vmscan.c determines whether a page is +The function page_evictable() in mm/internal.h determines whether a page is evictable or not using the query function outlined above [see section :ref:`Marking address spaces unevictable `] to check the AS_UNEVICTABLE flag. For address spaces that are so marked after being populated (as SHM regions -might be), the lock action (eg: SHM_LOCK) can be lazy, and need not populate +might be), the lock action (e.g. SHM_LOCK) can be lazy, and need not populate the page tables for the region as does, for example, mlock(), nor need it make any special effort to push any pages in the SHM_LOCK'd area to the unevictable list. Instead, vmscan will do this if and when it encounters the pages during a reclamation scan. -On an unlock action (such as SHM_UNLOCK), the unlocker (eg: shmctl()) must scan +On an unlock action (such as SHM_UNLOCK), the unlocker (e.g. shmctl()) must scan the pages in the region and "rescue" them from the unevictable list if no other condition is keeping them unevictable. If an unevictable region is destroyed, the pages are also "rescued" from the unevictable list in the process of @@ -176,7 +178,7 @@ freeing them. page_evictable() also checks for mlocked pages by testing an additional page flag, PG_mlocked (as wrapped by PageMlocked()), which is set when a page is -faulted into a VM_LOCKED vma, or found in a vma being VM_LOCKED. +faulted into a VM_LOCKED VMA, or found in a VMA being VM_LOCKED. Vmscan's Handling of Unevictable Pages @@ -186,28 +188,23 @@ If unevictable pages are culled in the fault path, or moved to the unevictable list at mlock() or mmap() time, vmscan will not encounter the pages until they have become evictable again (via munlock() for example) and have been "rescued" from the unevictable list. However, there may be situations where we decide, -for the sake of expediency, to leave a unevictable page on one of the regular +for the sake of expediency, to leave an unevictable page on one of the regular active/inactive LRU lists for vmscan to deal with. vmscan checks for such pages in all of the shrink_{active|inactive|page}_list() functions and will "cull" such pages that it encounters: that is, it diverts those pages to the -unevictable list for the node being scanned. +unevictable list for the memory cgroup and node being scanned. There may be situations where a page is mapped into a VM_LOCKED VMA, but the page is not marked as PG_mlocked. Such pages will make it all the way to -shrink_page_list() where they will be detected when vmscan walks the reverse -map in try_to_unmap(). If try_to_unmap() returns SWAP_MLOCK, -shrink_page_list() will cull the page at that point. +shrink_active_list() or shrink_page_list() where they will be detected when +vmscan walks the reverse map in page_referenced() or try_to_unmap(). The page +is culled to the unevictable list when it is released by the shrinker. To "cull" an unevictable page, vmscan simply puts the page back on the LRU list using putback_lru_page() - the inverse operation to isolate_lru_page() - after dropping the page lock. Because the condition which makes the page unevictable -may change once the page is unlocked, putback_lru_page() will recheck the -unevictable state of a page that it places on the unevictable list. If the -page has become unevictable, putback_lru_page() removes it from the list and -retries, including the page_unevictable() test. Because such a race is a rare -event and movement of pages onto the unevictable list should be rare, these -extra evictabilty checks should not occur in the majority of calls to -putback_lru_page(). +may change once the page is unlocked, __pagevec_lru_add_fn() will recheck the +unevictable state of a page before placing it on the unevictable list. MLOCKED Pages @@ -227,16 +224,25 @@ Nick posted his patch as an alternative to a patch posted by Christoph Lameter to achieve the same objective: hiding mlocked pages from vmscan. In Nick's patch, he used one of the struct page LRU list link fields as a count -of VM_LOCKED VMAs that map the page. This use of the link field for a count -prevented the management of the pages on an LRU list, and thus mlocked pages -were not migratable as isolate_lru_page() could not find them, and the LRU list -link field was not available to the migration subsystem. +of VM_LOCKED VMAs that map the page (Rik van Riel had the same idea three years +earlier). But this use of the link field for a count prevented the management +of the pages on an LRU list, and thus mlocked pages were not migratable as +isolate_lru_page() could not detect them, and the LRU list link field was not +available to the migration subsystem. -Nick resolved this by putting mlocked pages back on the lru list before +Nick resolved this by putting mlocked pages back on the LRU list before attempting to isolate them, thus abandoning the count of VM_LOCKED VMAs. When Nick's patch was integrated with the Unevictable LRU work, the count was -replaced by walking the reverse map to determine whether any VM_LOCKED VMAs -mapped the page. More on this below. +replaced by walking the reverse map when munlocking, to determine whether any +other VM_LOCKED VMAs still mapped the page. + +However, walking the reverse map for each page when munlocking was ugly and +inefficient, and could lead to catastrophic contention on a file's rmap lock, +when many processes which had it mlocked were trying to exit. In 5.18, the +idea of keeping mlock_count in Unevictable LRU list link field was revived and +put to work, without preventing the migration of mlocked pages. This is why +the "Unevictable LRU list" cannot be a linked list of pages now; but there was +no use for that linked list anyway - though its size is maintained for meminfo. Basic Management @@ -250,22 +256,18 @@ PageMlocked() functions. A PG_mlocked page will be placed on the unevictable list when it is added to the LRU. Such pages can be "noticed" by memory management in several places: - (1) in the mlock()/mlockall() system call handlers; + (1) in the mlock()/mlock2()/mlockall() system call handlers; (2) in the mmap() system call handler when mmapping a region with the MAP_LOCKED flag; (3) mmapping a region in a task that has called mlockall() with the MCL_FUTURE - flag + flag; - (4) in the fault path, if mlocked pages are "culled" in the fault path, - and when a VM_LOCKED stack segment is expanded; or + (4) in the fault path and when a VM_LOCKED stack segment is expanded; or (5) as mentioned above, in vmscan:shrink_page_list() when attempting to - reclaim a page in a VM_LOCKED VMA via try_to_unmap() - -all of which result in the VM_LOCKED flag being set for the VMA if it doesn't -already have it set. + reclaim a page in a VM_LOCKED VMA by page_referenced() or try_to_unmap(). mlocked pages become unlocked and rescued from the unevictable list when: @@ -280,51 +282,53 @@ mlocked pages become unlocked and rescued from the unevictable list when: (4) before a page is COW'd in a VM_LOCKED VMA. -mlock()/mlockall() System Call Handling ---------------------------------------- +mlock()/mlock2()/mlockall() System Call Handling +------------------------------------------------ -Both [do\_]mlock() and [do\_]mlockall() system call handlers call mlock_fixup() +mlock(), mlock2() and mlockall() system call handlers proceed to mlock_fixup() for each VMA in the range specified by the call. In the case of mlockall(), this is the entire active address space of the task. Note that mlock_fixup() is used for both mlocking and munlocking a range of memory. A call to mlock() -an already VM_LOCKED VMA, or to munlock() a VMA that is not VM_LOCKED is -treated as a no-op, and mlock_fixup() simply returns. +an already VM_LOCKED VMA, or to munlock() a VMA that is not VM_LOCKED, is +treated as a no-op and mlock_fixup() simply returns. -If the VMA passes some filtering as described in "Filtering Special Vmas" +If the VMA passes some filtering as described in "Filtering Special VMAs" below, mlock_fixup() will attempt to merge the VMA with its neighbors or split -off a subset of the VMA if the range does not cover the entire VMA. Once the -VMA has been merged or split or neither, mlock_fixup() will call -populate_vma_page_range() to fault in the pages via get_user_pages() and to -mark the pages as mlocked via mlock_vma_page(). +off a subset of the VMA if the range does not cover the entire VMA. Any pages +already present in the VMA are then marked as mlocked by mlock_page() via +mlock_pte_range() via walk_page_range() via mlock_vma_pages_range(). + +Before returning from the system call, do_mlock() or mlockall() will call +__mm_populate() to fault in the remaining pages via get_user_pages() and to +mark those pages as mlocked as they are faulted. Note that the VMA being mlocked might be mapped with PROT_NONE. In this case, get_user_pages() will be unable to fault in the pages. That's okay. If pages -do end up getting faulted into this VM_LOCKED VMA, we'll handle them in the -fault path or in vmscan. - -Also note that a page returned by get_user_pages() could be truncated or -migrated out from under us, while we're trying to mlock it. To detect this, -populate_vma_page_range() checks page_mapping() after acquiring the page lock. -If the page is still associated with its mapping, we'll go ahead and call -mlock_vma_page(). If the mapping is gone, we just unlock the page and move on. -In the worst case, this will result in a page mapped in a VM_LOCKED VMA -remaining on a normal LRU list without being PageMlocked(). Again, vmscan will -detect and cull such pages. - -mlock_vma_page() will call TestSetPageMlocked() for each page returned by -get_user_pages(). We use TestSetPageMlocked() because the page might already -be mlocked by another task/VMA and we don't want to do extra work. We -especially do not want to count an mlocked page more than once in the -statistics. If the page was already mlocked, mlock_vma_page() need do nothing -more. - -If the page was NOT already mlocked, mlock_vma_page() attempts to isolate the -page from the LRU, as it is likely on the appropriate active or inactive list -at that time. If the isolate_lru_page() succeeds, mlock_vma_page() will put -back the page - by calling putback_lru_page() - which will notice that the page -is now mlocked and divert the page to the node's unevictable list. If -mlock_vma_page() is unable to isolate the page from the LRU, vmscan will handle -it later if and when it attempts to reclaim the page. +do end up getting faulted into this VM_LOCKED VMA, they will be handled in the +fault path - which is also how mlock2()'s MLOCK_ONFAULT areas are handled. + +For each PTE (or PMD) being faulted into a VMA, the page add rmap function +calls mlock_vma_page(), which calls mlock_page() when the VMA is VM_LOCKED +(unless it is a PTE mapping of a part of a transparent huge page). Or when +it is a newly allocated anonymous page, lru_cache_add_inactive_or_unevictable() +calls mlock_new_page() instead: similar to mlock_page(), but can make better +judgments, since this page is held exclusively and known not to be on LRU yet. + +mlock_page() sets PageMlocked immediately, then places the page on the CPU's +mlock pagevec, to batch up the rest of the work to be done under lru_lock by +__mlock_page(). __mlock_page() sets PageUnevictable, initializes mlock_count +and moves the page to unevictable state ("the unevictable LRU", but with +mlock_count in place of LRU threading). Or if the page was already PageLRU +and PageUnevictable and PageMlocked, it simply increments the mlock_count. + +But in practice that may not work ideally: the page may not yet be on an LRU, or +it may have been temporarily isolated from LRU. In such cases the mlock_count +field cannot be touched, but will be set to 0 later when __pagevec_lru_add_fn() +returns the page to "LRU". Races prohibit mlock_count from being set to 1 then: +rather than risk stranding a page indefinitely as unevictable, always err with +mlock_count on the low side, so that when munlocked the page will be rescued to +an evictable LRU, then perhaps be mlocked again later if vmscan finds it in a +VM_LOCKED VMA. Filtering Special VMAs @@ -339,68 +343,48 @@ mlock_fixup() filters several classes of "special" VMAs: so there is no sense in attempting to visit them. 2) VMAs mapping hugetlbfs page are already effectively pinned into memory. We - neither need nor want to mlock() these pages. However, to preserve the - prior behavior of mlock() - before the unevictable/mlock changes - - mlock_fixup() will call make_pages_present() in the hugetlbfs VMA range to - allocate the huge pages and populate the ptes. + neither need nor want to mlock() these pages. But __mm_populate() includes + hugetlbfs ranges, allocating the huge pages and populating the PTEs. 3) VMAs with VM_DONTEXPAND are generally userspace mappings of kernel pages, - such as the VDSO page, relay channel pages, etc. These pages - are inherently unevictable and are not managed on the LRU lists. - mlock_fixup() treats these VMAs the same as hugetlbfs VMAs. It calls - make_pages_present() to populate the ptes. + such as the VDSO page, relay channel pages, etc. These pages are inherently + unevictable and are not managed on the LRU lists. __mm_populate() includes + these ranges, populating the PTEs if not already populated. + +4) VMAs with VM_MIXEDMAP set are not marked VM_LOCKED, but __mm_populate() + includes these ranges, populating the PTEs if not already populated. Note that for all of these special VMAs, mlock_fixup() does not set the VM_LOCKED flag. Therefore, we won't have to deal with them later during munlock(), munmap() or task exit. Neither does mlock_fixup() account these VMAs against the task's "locked_vm". -.. _munlock_munlockall_handling: munlock()/munlockall() System Call Handling ------------------------------------------- -The munlock() and munlockall() system calls are handled by the same functions - -do_mlock[all]() - as the mlock() and mlockall() system calls with the unlock vs -lock operation indicated by an argument. So, these system calls are also -handled by mlock_fixup(). Again, if called for an already munlocked VMA, -mlock_fixup() simply returns. Because of the VMA filtering discussed above, -VM_LOCKED will not be set in any "special" VMAs. So, these VMAs will be -ignored for munlock. +The munlock() and munlockall() system calls are handled by the same +mlock_fixup() function as mlock(), mlock2() and mlockall() system calls are. +If called to munlock an already munlocked VMA, mlock_fixup() simply returns. +Because of the VMA filtering discussed above, VM_LOCKED will not be set in +any "special" VMAs. So, those VMAs will be ignored for munlock. If the VMA is VM_LOCKED, mlock_fixup() again attempts to merge or split off the -specified range. The range is then munlocked via the function -populate_vma_page_range() - the same function used to mlock a VMA range - -passing a flag to indicate that munlock() is being performed. - -Because the VMA access protections could have been changed to PROT_NONE after -faulting in and mlocking pages, get_user_pages() was unreliable for visiting -these pages for munlocking. Because we don't want to leave pages mlocked, -get_user_pages() was enhanced to accept a flag to ignore the permissions when -fetching the pages - all of which should be resident as a result of previous -mlocking. - -For munlock(), populate_vma_page_range() unlocks individual pages by calling -munlock_vma_page(). munlock_vma_page() unconditionally clears the PG_mlocked -flag using TestClearPageMlocked(). As with mlock_vma_page(), -munlock_vma_page() use the Test*PageMlocked() function to handle the case where -the page might have already been unlocked by another task. If the page was -mlocked, munlock_vma_page() updates that zone statistics for the number of -mlocked pages. Note, however, that at this point we haven't checked whether -the page is mapped by other VM_LOCKED VMAs. - -We can't call page_mlock(), the function that walks the reverse map to -check for other VM_LOCKED VMAs, without first isolating the page from the LRU. -page_mlock() is a variant of try_to_unmap() and thus requires that the page -not be on an LRU list [more on these below]. However, the call to -isolate_lru_page() could fail, in which case we can't call page_mlock(). So, -we go ahead and clear PG_mlocked up front, as this might be the only chance we -have. If we can successfully isolate the page, we go ahead and call -page_mlock(), which will restore the PG_mlocked flag and update the zone -page statistics if it finds another VMA holding the page mlocked. If we fail -to isolate the page, we'll have left a potentially mlocked page on the LRU. -This is fine, because we'll catch it later if and if vmscan tries to reclaim -the page. This should be relatively rare. +specified range. All pages in the VMA are then munlocked by munlock_page() via +mlock_pte_range() via walk_page_range() via mlock_vma_pages_range() - the same +function used when mlocking a VMA range, with new flags for the VMA indicating +that it is munlock() being performed. + +munlock_page() uses the mlock pagevec to batch up work to be done under +lru_lock by __munlock_page(). __munlock_page() decrements the page's +mlock_count, and when that reaches 0 it clears PageMlocked and clears +PageUnevictable, moving the page from unevictable state to inactive LRU. + +But in practice that may not work ideally: the page may not yet have reached +"the unevictable LRU", or it may have been temporarily isolated from it. In +those cases its mlock_count field is unusable and must be assumed to be 0: so +that the page will be rescued to an evictable LRU, then perhaps be mlocked +again later if vmscan finds it in a VM_LOCKED VMA. Migrating MLOCKED Pages @@ -410,33 +394,38 @@ A page that is being migrated has been isolated from the LRU lists and is held locked across unmapping of the page, updating the page's address space entry and copying the contents and state, until the page table entry has been replaced with an entry that refers to the new page. Linux supports migration -of mlocked pages and other unevictable pages. This involves simply moving the -PG_mlocked and PG_unevictable states from the old page to the new page. +of mlocked pages and other unevictable pages. PG_mlocked is cleared from the +the old page when it is unmapped from the last VM_LOCKED VMA, and set when the +new page is mapped in place of migration entry in a VM_LOCKED VMA. If the page +was unevictable because mlocked, PG_unevictable follows PG_mlocked; but if the +page was unevictable for other reasons, PG_unevictable is copied explicitly. Note that page migration can race with mlocking or munlocking of the same page. -This has been discussed from the mlock/munlock perspective in the respective -sections above. Both processes (migration and m[un]locking) hold the page -locked. This provides the first level of synchronization. Page migration -zeros out the page_mapping of the old page before unlocking it, so m[un]lock -can skip these pages by testing the page mapping under page lock. +There is mostly no problem since page migration requires unmapping all PTEs of +the old page (including munlock where VM_LOCKED), then mapping in the new page +(including mlock where VM_LOCKED). The page table locks provide sufficient +synchronization. -To complete page migration, we place the new and old pages back onto the LRU -after dropping the page lock. The "unneeded" page - old page on success, new -page on failure - will be freed when the reference count held by the migration -process is released. To ensure that we don't strand pages on the unevictable -list because of a race between munlock and migration, page migration uses the -putback_lru_page() function to add migrated pages back to the LRU. +However, since mlock_vma_pages_range() starts by setting VM_LOCKED on a VMA, +before mlocking any pages already present, if one of those pages were migrated +before mlock_pte_range() reached it, it would get counted twice in mlock_count. +To prevent that, mlock_vma_pages_range() temporarily marks the VMA as VM_IO, +so that mlock_vma_page() will skip it. + +To complete page migration, we place the old and new pages back onto the LRU +afterwards. The "unneeded" page - old page on success, new page on failure - +is freed when the reference count held by the migration process is released. Compacting MLOCKED Pages ------------------------ -The unevictable LRU can be scanned for compactable regions and the default -behavior is to do so. /proc/sys/vm/compact_unevictable_allowed controls -this behavior (see Documentation/admin-guide/sysctl/vm.rst). Once scanning of the -unevictable LRU is enabled, the work of compaction is mostly handled by -the page migration code and the same work flow as described in MIGRATING -MLOCKED PAGES will apply. +The memory map can be scanned for compactable regions and the default behavior +is to let unevictable pages be moved. /proc/sys/vm/compact_unevictable_allowed +controls this behavior (see Documentation/admin-guide/sysctl/vm.rst). The work +of compaction is mostly handled by the page migration code and the same work +flow as described in Migrating MLOCKED Pages will apply. + MLOCKING Transparent Huge Pages ------------------------------- @@ -445,51 +434,44 @@ A transparent huge page is represented by a single entry on an LRU list. Therefore, we can only make unevictable an entire compound page, not individual subpages. -If a user tries to mlock() part of a huge page, we want the rest of the -page to be reclaimable. +If a user tries to mlock() part of a huge page, and no user mlock()s the +whole of the huge page, we want the rest of the page to be reclaimable. We cannot just split the page on partial mlock() as split_huge_page() can -fail and new intermittent failure mode for the syscall is undesirable. +fail and a new intermittent failure mode for the syscall is undesirable. -We handle this by keeping PTE-mapped huge pages on normal LRU lists: the -PMD on border of VM_LOCKED VMA will be split into PTE table. +We handle this by keeping PTE-mlocked huge pages on evictable LRU lists: +the PMD on the border of a VM_LOCKED VMA will be split into a PTE table. -This way the huge page is accessible for vmscan. Under memory pressure the +This way the huge page is accessible for vmscan. Under memory pressure the page will be split, subpages which belong to VM_LOCKED VMAs will be moved -to unevictable LRU and the rest can be reclaimed. +to the unevictable LRU and the rest can be reclaimed. + +/proc/meminfo's Unevictable and Mlocked amounts do not include those parts +of a transparent huge page which are mapped only by PTEs in VM_LOCKED VMAs. -See also comment in follow_trans_huge_pmd(). mmap(MAP_LOCKED) System Call Handling ------------------------------------- -In addition the mlock()/mlockall() system calls, an application can request -that a region of memory be mlocked supplying the MAP_LOCKED flag to the mmap() -call. There is one important and subtle difference here, though. mmap() + mlock() -will fail if the range cannot be faulted in (e.g. because mm_populate fails) -and returns with ENOMEM while mmap(MAP_LOCKED) will not fail. The mmaped -area will still have properties of the locked area - aka. pages will not get -swapped out - but major page faults to fault memory in might still happen. +In addition to the mlock(), mlock2() and mlockall() system calls, an application +can request that a region of memory be mlocked by supplying the MAP_LOCKED flag +to the mmap() call. There is one important and subtle difference here, though. +mmap() + mlock() will fail if the range cannot be faulted in (e.g. because +mm_populate fails) and returns with ENOMEM while mmap(MAP_LOCKED) will not fail. +The mmaped area will still have properties of the locked area - pages will not +get swapped out - but major page faults to fault memory in might still happen. -Furthermore, any mmap() call or brk() call that expands the heap by a -task that has previously called mlockall() with the MCL_FUTURE flag will result +Furthermore, any mmap() call or brk() call that expands the heap by a task +that has previously called mlockall() with the MCL_FUTURE flag will result in the newly mapped memory being mlocked. Before the unevictable/mlock -changes, the kernel simply called make_pages_present() to allocate pages and -populate the page table. +changes, the kernel simply called make_pages_present() to allocate pages +and populate the page table. -To mlock a range of memory under the unevictable/mlock infrastructure, the -mmap() handler and task address space expansion functions call +To mlock a range of memory under the unevictable/mlock infrastructure, +the mmap() handler and task address space expansion functions call populate_vma_page_range() specifying the vma and the address range to mlock. -The callers of populate_vma_page_range() will have already added the memory range -to be mlocked to the task's "locked_vm". To account for filtered VMAs, -populate_vma_page_range() returns the number of pages NOT mlocked. All of the -callers then subtract a non-negative return value from the task's locked_vm. A -negative return value represent an error - for example, from get_user_pages() -attempting to fault in a VMA with PROT_NONE access. In this case, we leave the -memory range accounted as locked_vm, as the protections could be changed later -and pages allocated into that region. - munmap()/exit()/exec() System Call Handling ------------------------------------------- @@ -500,81 +482,53 @@ munlock the pages if we're removing the last VM_LOCKED VMA that maps the pages. Before the unevictable/mlock changes, mlocking did not mark the pages in any way, so unmapping them required no processing. -To munlock a range of memory under the unevictable/mlock infrastructure, the -munmap() handler and task address space call tear down function -munlock_vma_pages_all(). The name reflects the observation that one always -specifies the entire VMA range when munlock()ing during unmap of a region. -Because of the VMA filtering when mlocking() regions, only "normal" VMAs that -actually contain mlocked pages will be passed to munlock_vma_pages_all(). - -munlock_vma_pages_all() clears the VM_LOCKED VMA flag and, like mlock_fixup() -for the munlock case, calls __munlock_vma_pages_range() to walk the page table -for the VMA's memory range and munlock_vma_page() each resident page mapped by -the VMA. This effectively munlocks the page, only if this is the last -VM_LOCKED VMA that maps the page. - - -try_to_unmap() --------------- - -Pages can, of course, be mapped into multiple VMAs. Some of these VMAs may -have VM_LOCKED flag set. It is possible for a page mapped into one or more -VM_LOCKED VMAs not to have the PG_mlocked flag set and therefore reside on one -of the active or inactive LRU lists. This could happen if, for example, a task -in the process of munlocking the page could not isolate the page from the LRU. -As a result, vmscan/shrink_page_list() might encounter such a page as described -in section "vmscan's handling of unevictable pages". To handle this situation, -try_to_unmap() checks for VM_LOCKED VMAs while it is walking a page's reverse -map. - -try_to_unmap() is always called, by either vmscan for reclaim or for page -migration, with the argument page locked and isolated from the LRU. Separate -functions handle anonymous and mapped file and KSM pages, as these types of -pages have different reverse map lookup mechanisms, with different locking. -In each case, whether rmap_walk_anon() or rmap_walk_file() or rmap_walk_ksm(), -it will call try_to_unmap_one() for every VMA which might contain the page. - -When trying to reclaim, if try_to_unmap_one() finds the page in a VM_LOCKED -VMA, it will then mlock the page via mlock_vma_page() instead of unmapping it, -and return SWAP_MLOCK to indicate that the page is unevictable: and the scan -stops there. - -mlock_vma_page() is called while holding the page table's lock (in addition -to the page lock, and the rmap lock): to serialize against concurrent mlock or -munlock or munmap system calls, mm teardown (munlock_vma_pages_all), reclaim, -holepunching, and truncation of file pages and their anonymous COWed pages. - - -page_mlock() Reverse Map Scan ---------------------------------- - -When munlock_vma_page() [see section :ref:`munlock()/munlockall() System Call -Handling ` above] tries to munlock a -page, it needs to determine whether or not the page is mapped by any -VM_LOCKED VMA without actually attempting to unmap all PTEs from the -page. For this purpose, the unevictable/mlock infrastructure -introduced a variant of try_to_unmap() called page_mlock(). - -page_mlock() walks the respective reverse maps looking for VM_LOCKED VMAs. When -such a VMA is found the page is mlocked via mlock_vma_page(). This undoes the -pre-clearing of the page's PG_mlocked done by munlock_vma_page. - -Note that page_mlock()'s reverse map walk must visit every VMA in a page's -reverse map to determine that a page is NOT mapped into any VM_LOCKED VMA. -However, the scan can terminate when it encounters a VM_LOCKED VMA. -Although page_mlock() might be called a great many times when munlocking a -large region or tearing down a large address space that has been mlocked via -mlockall(), overall this is a fairly rare event. +For each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls +munlock_vma_page(), which calls munlock_page() when the VMA is VM_LOCKED +(unless it was a PTE mapping of a part of a transparent huge page). + +munlock_page() uses the mlock pagevec to batch up work to be done under +lru_lock by __munlock_page(). __munlock_page() decrements the page's +mlock_count, and when that reaches 0 it clears PageMlocked and clears +PageUnevictable, moving the page from unevictable state to inactive LRU. + +But in practice that may not work ideally: the page may not yet have reached +"the unevictable LRU", or it may have been temporarily isolated from it. In +those cases its mlock_count field is unusable and must be assumed to be 0: so +that the page will be rescued to an evictable LRU, then perhaps be mlocked +again later if vmscan finds it in a VM_LOCKED VMA. + + +Truncating MLOCKED Pages +------------------------ + +File truncation or hole punching forcibly unmaps the deleted pages from +userspace; truncation even unmaps and deletes any private anonymous pages +which had been Copied-On-Write from the file pages now being truncated. + +Mlocked pages can be munlocked and deleted in this way: like with munmap(), +for each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls +munlock_vma_page(), which calls munlock_page() when the VMA is VM_LOCKED +(unless it was a PTE mapping of a part of a transparent huge page). + +However, if there is a racing munlock(), since mlock_vma_pages_range() starts +munlocking by clearing VM_LOCKED from a VMA, before munlocking all the pages +present, if one of those pages were unmapped by truncation or hole punch before +mlock_pte_range() reached it, it would not be recognized as mlocked by this VMA, +and would not be counted out of mlock_count. In this rare case, a page may +still appear as PageMlocked after it has been fully unmapped: and it is left to +release_pages() (or __page_cache_release()) to clear it and update statistics +before freeing (this event is counted in /proc/vmstat unevictable_pgs_cleared, +which is usually 0). Page Reclaim in shrink_*_list() ------------------------------- -shrink_active_list() culls any obviously unevictable pages - i.e. -!page_evictable(page) - diverting these to the unevictable list. +vmscan's shrink_active_list() culls any obviously unevictable pages - +i.e. !page_evictable(page) pages - diverting those to the unevictable list. However, shrink_active_list() only sees unevictable pages that made it onto the -active/inactive lru lists. Note that these pages do not have PageUnevictable -set - otherwise they would be on the unevictable list and shrink_active_list +active/inactive LRU lists. Note that these pages do not have PageUnevictable +set - otherwise they would be on the unevictable list and shrink_active_list() would never see them. Some examples of these unevictable pages on the LRU lists are: @@ -586,20 +540,15 @@ Some examples of these unevictable pages on the LRU lists are: when an application accesses the page the first time after SHM_LOCK'ing the segment. - (3) mlocked pages that could not be isolated from the LRU and moved to the - unevictable list in mlock_vma_page(). - -shrink_inactive_list() also diverts any unevictable pages that it finds on the -inactive lists to the appropriate node's unevictable list. + (3) pages still mapped into VM_LOCKED VMAs, which should be marked mlocked, + but events left mlock_count too low, so they were munlocked too early. -shrink_inactive_list() should only see SHM_LOCK'd pages that became SHM_LOCK'd -after shrink_active_list() had moved them to the inactive list, or pages mapped -into VM_LOCKED VMAs that munlock_vma_page() couldn't isolate from the LRU to -recheck via page_mlock(). shrink_inactive_list() won't notice the latter, -but will pass on to shrink_page_list(). +vmscan's shrink_inactive_list() and shrink_page_list() also divert obviously +unevictable pages found on the inactive lists to the appropriate memory cgroup +and node unevictable list. -shrink_page_list() again culls obviously unevictable pages that it could -encounter for similar reason to shrink_inactive_list(). Pages mapped into -VM_LOCKED VMAs but without PG_mlocked set will make it all the way to -try_to_unmap(). shrink_page_list() will divert them to the unevictable list -when try_to_unmap() returns SWAP_MLOCK, as discussed above. +rmap's page_referenced_one(), called via vmscan's shrink_active_list() or +shrink_page_list(), and rmap's try_to_unmap_one() called via shrink_page_list(), +check for (3) pages still mapped into VM_LOCKED VMAs, and call mlock_vma_page() +to correct them. Such pages are culled to the unevictable list when released +by the shrinker. -- cgit From c89b3ad2dea254ad17ae2585b17c2cf9f78e64d9 Mon Sep 17 00:00:00 2001 From: Yinan Zhang Date: Fri, 1 Apr 2022 11:28:51 -0700 Subject: doc/vm/page_owner.rst: remove content related to -c option -c option has been removed from page_owner_sort.c. Remove the usage of -c option from Documentation. This work is coauthored by Shenghong Han Yixuan Cao Chongxi Zhao Jiajian Ye Yuhong Feng Yongqiang Liu Link: https://lkml.kernel.org/r/20220326085920.1470081-2-zhangyinan2019@email.szu.edu.cn Signed-off-by: Yinan Zhang Cc: Jonathan Corbet Cc: Stephen Rothwell Cc: Sean Anderson Cc: Tang Bin Cc: Zhenliang Wei Cc: Georgi Djakov Cc: Chongxi Zhao Cc: Jiajian Ye Cc: Yixuan Cao Cc: Yuhong Feng Cc: Yongqiang Liu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/page_owner.rst | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index c4de6f8dabe9..65204d7f004f 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -125,7 +125,6 @@ Usage additional function: Cull: - -c Cull by comparing stacktrace instead of total block. --cull Specify culling rules.Culling syntax is key[,key[,...]].Choose a multi-letter key from the **STANDARD FORMAT SPECIFIERS** section. -- cgit From 2524257bce43610f5ec14feccbacf7a103cae94a Mon Sep 17 00:00:00 2001 From: Palmer Dabbelt Date: Fri, 1 Apr 2022 12:57:42 -0700 Subject: dt-bindings: Fix phandle-array issues in the idle-states bindings As per 39bd2b6a3783 ("dt-bindings: Improve phandle-array schemas"), the phandle-array bindings have been disambiguated. This fixes the new RISC-V idle-states bindings to comply with the schema. Fixes: 1bd524f7e8d8 ("dt-bindings: Add common bindings for ARM and RISC-V idle states") Reviewed-by: Rob Herring Signed-off-by: Palmer Dabbelt --- Documentation/devicetree/bindings/cpu/idle-states.yaml | 16 ++++++++-------- Documentation/devicetree/bindings/riscv/cpus.yaml | 2 ++ 2 files changed, 10 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/cpu/idle-states.yaml b/Documentation/devicetree/bindings/cpu/idle-states.yaml index 5daa219ceb7b..fa4d4142ac93 100644 --- a/Documentation/devicetree/bindings/cpu/idle-states.yaml +++ b/Documentation/devicetree/bindings/cpu/idle-states.yaml @@ -719,8 +719,8 @@ examples: reg = <0x0>; riscv,isa = "rv64imafdc"; mmu-type = "riscv,sv48"; - cpu-idle-states = <&CPU_RET_0_0 &CPU_NONRET_0_0 - &CLUSTER_RET_0 &CLUSTER_NONRET_0>; + cpu-idle-states = <&CPU_RET_0_0>, <&CPU_NONRET_0_0>, + <&CLUSTER_RET_0>, <&CLUSTER_NONRET_0>; cpu_intc0: interrupt-controller { #interrupt-cells = <1>; @@ -735,8 +735,8 @@ examples: reg = <0x1>; riscv,isa = "rv64imafdc"; mmu-type = "riscv,sv48"; - cpu-idle-states = <&CPU_RET_0_0 &CPU_NONRET_0_0 - &CLUSTER_RET_0 &CLUSTER_NONRET_0>; + cpu-idle-states = <&CPU_RET_0_0>, <&CPU_NONRET_0_0>, + <&CLUSTER_RET_0>, <&CLUSTER_NONRET_0>; cpu_intc1: interrupt-controller { #interrupt-cells = <1>; @@ -751,8 +751,8 @@ examples: reg = <0x10>; riscv,isa = "rv64imafdc"; mmu-type = "riscv,sv48"; - cpu-idle-states = <&CPU_RET_1_0 &CPU_NONRET_1_0 - &CLUSTER_RET_1 &CLUSTER_NONRET_1>; + cpu-idle-states = <&CPU_RET_1_0>, <&CPU_NONRET_1_0>, + <&CLUSTER_RET_1>, <&CLUSTER_NONRET_1>; cpu_intc10: interrupt-controller { #interrupt-cells = <1>; @@ -767,8 +767,8 @@ examples: reg = <0x11>; riscv,isa = "rv64imafdc"; mmu-type = "riscv,sv48"; - cpu-idle-states = <&CPU_RET_1_0 &CPU_NONRET_1_0 - &CLUSTER_RET_1 &CLUSTER_NONRET_1>; + cpu-idle-states = <&CPU_RET_1_0>, <&CPU_NONRET_1_0>, + <&CLUSTER_RET_1>, <&CLUSTER_NONRET_1>; cpu_intc11: interrupt-controller { #interrupt-cells = <1>; diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index f62f646bc695..d632ac76532e 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -101,6 +101,8 @@ properties: cpu-idle-states: $ref: '/schemas/types.yaml#/definitions/phandle-array' + items: + maxItems: 1 description: | List of phandles to idle state nodes supported by this hart (see ./idle-states.yaml). -- cgit From df06dae3f2a8bfb83683abf88d3dcde23fc8093d Mon Sep 17 00:00:00 2001 From: Sean Christopherson Date: Wed, 23 Feb 2022 16:53:02 +0000 Subject: KVM: Don't actually set a request when evicting vCPUs for GFN cache invd Don't actually set a request bit in vcpu->requests when making a request purely to force a vCPU to exit the guest. Logging a request but not actually consuming it would cause the vCPU to get stuck in an infinite loop during KVM_RUN because KVM would see the pending request and bail from VM-Enter to service the request. Note, it's currently impossible for KVM to set KVM_REQ_GPC_INVALIDATE as nothing in KVM is wired up to set guest_uses_pa=true. But, it'd be all too easy for arch code to introduce use of kvm_gfn_to_pfn_cache_init() without implementing handling of the request, especially since getting test coverage of MMU notifier interaction with specific KVM features usually requires a directed test. Opportunistically rename gfn_to_pfn_cache_invalidate_start()'s wake_vcpus to evict_vcpus. The purpose of the request is to get vCPUs out of guest mode, it's supposed to _avoid_ waking vCPUs that are blocking. Opportunistically rename KVM_REQ_GPC_INVALIDATE to be more specific as to what it wants to accomplish, and to genericize the name so that it can used for similar but unrelated scenarios, should they arise in the future. Add a comment and documentation to explain why the "no action" request exists. Add compile-time assertions to help detect improper usage. Use the inner assertless helper in the one s390 path that makes requests without a hardcoded request. Cc: David Woodhouse Signed-off-by: Sean Christopherson Message-Id: <20220223165302.3205276-1-seanjc@google.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/vcpu-requests.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/vcpu-requests.rst b/Documentation/virt/kvm/vcpu-requests.rst index b61d48aec36c..db43ee571f5a 100644 --- a/Documentation/virt/kvm/vcpu-requests.rst +++ b/Documentation/virt/kvm/vcpu-requests.rst @@ -135,6 +135,16 @@ KVM_REQ_UNHALT such as a pending signal, which does not indicate the VCPU's halt emulation should stop, and therefore does not make the request. +KVM_REQ_OUTSIDE_GUEST_MODE + + This "request" ensures the target vCPU has exited guest mode prior to the + sender of the request continuing on. No action needs be taken by the target, + and so no request is actually logged for the target. This request is similar + to a "kick", but unlike a kick it guarantees the vCPU has actually exited + guest mode. A kick only guarantees the vCPU will exit at some point in the + future, e.g. a previous kick may have started the process, but there's no + guarantee the to-be-kicked vCPU has fully exited guest mode. + KVM_REQUEST_MASK ---------------- -- cgit From cf1d88b36ba7e83bdaa50bccc4c47864e8f08cbe Mon Sep 17 00:00:00 2001 From: David Woodhouse Date: Thu, 3 Mar 2022 15:41:12 +0000 Subject: KVM: Remove dirty handling from gfn_to_pfn_cache completely It isn't OK to cache the dirty status of a page in internal structures for an indefinite period of time. Any time a vCPU exits the run loop to userspace might be its last; the VMM might do its final check of the dirty log, flush the last remaining dirty pages to the destination and complete a live migration. If we have internal 'dirty' state which doesn't get flushed until the vCPU is finally destroyed on the source after migration is complete, then we have lost data because that will escape the final copy. This problem already exists with the use of kvm_vcpu_unmap() to mark pages dirty in e.g. VMX nesting. Note that the actual Linux MM already considers the page to be dirty since we have a writeable mapping of it. This is just about the KVM dirty logging. For the nesting-style use cases (KVM_GUEST_USES_PFN) we will need to track which gfn_to_pfn_caches have been used and explicitly mark the corresponding pages dirty before returning to userspace. But we would have needed external tracking of that anyway, rather than walking the full list of GPCs to find those belonging to this vCPU which are dirty. So let's rely *solely* on that external tracking, and keep it simple rather than laying a tempting trap for callers to fall into. Signed-off-by: David Woodhouse Signed-off-by: Paolo Bonzini Message-Id: <20220303154127.202856-3-dwmw2@infradead.org> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 1ec05e6bfa6f..04b26c2a7159 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -5293,6 +5293,10 @@ type values: KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO Sets the guest physical address of the vcpu_info for a given vCPU. + As with the shared_info page for the VM, the corresponding page may be + dirtied at any time if event channel interrupt delivery is enabled, so + userspace should always assume that the page is dirty without relying + on dirty logging. KVM_XEN_VCPU_ATTR_TYPE_VCPU_TIME_INFO Sets the guest physical address of an additional pvclock structure -- cgit From ce2f72e26c1a352f5f2d1cda19bcafeff6c3b4fc Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Tue, 15 Mar 2022 18:17:15 -0400 Subject: KVM: x86: document limitations of MSR filtering MSR filtering requires an exit to userspace that is hard to implement and would be very slow in the case of nested VMX vmexit and vmentry MSR accesses. Document the limitation. Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 04b26c2a7159..d210a4e8dce3 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -4081,6 +4081,11 @@ x2APIC MSRs are always allowed, independent of the ``default_allow`` setting, and their behavior depends on the ``X2APIC_ENABLE`` bit of the APIC base register. +.. warning:: + MSR accesses coming from nested vmentry/vmexit are not filtered. + This includes both writes to individual VMCS fields and reads/writes + through the MSR lists pointed to by the VMCS. + If a bit is within one of the defined ranges, read and write accesses are guarded by the bitmap's value for the MSR index if the kind of access is included in the ``struct kvm_msr_filter_range`` flags. If no range -- cgit From fe5f691413c12999e747695b7220635375520f63 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Sun, 13 Mar 2022 15:05:22 +0100 Subject: KVM: MIPS: remove reference to trap&emulate virtualization Signed-off-by: Paolo Bonzini Message-Id: <20220313140522.1307751-1-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 6 ------ 1 file changed, 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index d210a4e8dce3..d13fa6600467 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -151,12 +151,6 @@ In order to create user controlled virtual machines on S390, check KVM_CAP_S390_UCONTROL and use the flag KVM_VM_S390_UCONTROL as privileged user (CAP_SYS_ADMIN). -To use hardware assisted virtualization on MIPS (VZ ASE) rather than -the default trap & emulate implementation (which changes the virtual -memory layout to fit in user mode), check KVM_CAP_MIPS_VZ and use the -flag KVM_VM_MIPS_VZ. - - On arm64, the physical address size for a VM (IPA Size limit) is limited to 40bits by default. The limit can be configured if the host supports the extension KVM_CAP_ARM_VM_IPA_SIZE. When supported, use -- cgit From f1a9761fbb00639c5e73835f7f373ef834bb867f Mon Sep 17 00:00:00 2001 From: Oliver Upton Date: Wed, 16 Mar 2022 00:55:37 +0000 Subject: KVM: x86: Allow userspace to opt out of hypercall patching KVM handles the VMCALL/VMMCALL instructions very strangely. Even though both of these instructions really should #UD when executed on the wrong vendor's hardware (i.e. VMCALL on SVM, VMMCALL on VMX), KVM replaces the guest's instruction with the appropriate instruction for the vendor. Nonetheless, older guest kernels without commit c1118b3602c2 ("x86: kvm: use alternatives for VMCALL vs. VMMCALL if kernel text is read-only") do not patch in the appropriate instruction using alternatives, likely motivating KVM's intervention. Add a quirk allowing userspace to opt out of hypercall patching. If the quirk is disabled, KVM synthesizes a #UD in the guest. Signed-off-by: Oliver Upton Message-Id: <20220316005538.2282772-2-oupton@google.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index d13fa6600467..700df350332b 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7134,6 +7134,15 @@ The valid bits in cap.args[0] are: Additionally, when this quirk is disabled, KVM clears CPUID.01H:ECX[bit 3] if IA32_MISC_ENABLE[bit 18] is cleared. + + KVM_X86_QUIRK_FIX_HYPERCALL_INSN By default, KVM rewrites guest + VMMCALL/VMCALL instructions to match the + vendor's hypercall instruction for the + system. When this quirk is disabled, KVM + will no longer rewrite invalid guest + hypercall instructions. Executing the + incorrect hypercall instruction will + generate a #UD within the guest. =================================== ============================================ 8. Other capabilities. -- cgit From 661a20fab7d156cf6b9a407c946a1e558a633151 Mon Sep 17 00:00:00 2001 From: David Woodhouse Date: Thu, 3 Mar 2022 15:41:25 +0000 Subject: KVM: x86/xen: Advertise and document KVM_XEN_HVM_CONFIG_EVTCHN_SEND MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit At the end of the patch series adding this batch of event channel acceleration features, finally add the feature bit which advertises them and document it all. For SCHEDOP_poll we need to wake a polling vCPU when a given port is triggered, even when it's masked — and we want to implement that in the kernel, for efficiency. So we want the kernel to know that it has sole ownership of event channel delivery. Thus, we allow userspace to make the 'promise' by setting the corresponding feature bit in its KVM_XEN_HVM_CONFIG call. As we implement SCHEDOP_poll bypass later, we will do so only if that promise has been made by userspace. Signed-off-by: David Woodhouse Signed-off-by: Paolo Bonzini Message-Id: <20220303154127.202856-16-dwmw2@infradead.org> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 129 +++++++++++++++++++++++++++++++++++++---- 1 file changed, 119 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 700df350332b..fdfd9e1bc7f7 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -982,12 +982,22 @@ memory. __u8 pad2[30]; }; -If the KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL flag is returned from the -KVM_CAP_XEN_HVM check, it may be set in the flags field of this ioctl. -This requests KVM to generate the contents of the hypercall page -automatically; hypercalls will be intercepted and passed to userspace -through KVM_EXIT_XEN. In this case, all of the blob size and address -fields must be zero. +If certain flags are returned from the KVM_CAP_XEN_HVM check, they may +be set in the flags field of this ioctl: + +The KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL flag requests KVM to generate +the contents of the hypercall page automatically; hypercalls will be +intercepted and passed to userspace through KVM_EXIT_XEN. In this +ase, all of the blob size and address fields must be zero. + +The KVM_XEN_HVM_CONFIG_EVTCHN_SEND flag indicates to KVM that userspace +will always use the KVM_XEN_HVM_EVTCHN_SEND ioctl to deliver event +channel interrupts rather than manipulating the guest's shared_info +structures directly. This, in turn, may allow KVM to enable features +such as intercepting the SCHEDOP_poll hypercall to accelerate PV +spinlock operation for the guest. Userspace may still use the ioctl +to deliver events if it was advertised, even if userspace does not +send this indication that it will always do so No other flags are currently valid in the struct kvm_xen_hvm_config. @@ -5216,7 +5226,25 @@ have deterministic behavior. struct { __u64 gfn; } shared_info; - __u64 pad[4]; + struct { + __u32 send_port; + __u32 type; /* EVTCHNSTAT_ipi / EVTCHNSTAT_interdomain */ + __u32 flags; + union { + struct { + __u32 port; + __u32 vcpu; + __u32 priority; + } port; + struct { + __u32 port; /* Zero for eventfd */ + __s32 fd; + } eventfd; + __u32 padding[4]; + } deliver; + } evtchn; + __u32 xen_version; + __u64 pad[8]; } u; }; @@ -5247,6 +5275,30 @@ KVM_XEN_ATTR_TYPE_SHARED_INFO KVM_XEN_ATTR_TYPE_UPCALL_VECTOR Sets the exception vector used to deliver Xen event channel upcalls. + This is the HVM-wide vector injected directly by the hypervisor + (not through the local APIC), typically configured by a guest via + HVM_PARAM_CALLBACK_IRQ. + +KVM_XEN_ATTR_TYPE_EVTCHN + This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates + support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It configures + an outbound port number for interception of EVTCHNOP_send requests + from the guest. A given sending port number may be directed back + to a specified vCPU (by APIC ID) / port / priority on the guest, + or to trigger events on an eventfd. The vCPU and priority can be + changed by setting KVM_XEN_EVTCHN_UPDATE in a subsequent call, + but other fields cannot change for a given sending port. A port + mapping is removed by using KVM_XEN_EVTCHN_DEASSIGN in the flags + field. + +KVM_XEN_ATTR_TYPE_XEN_VERSION + This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates + support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It configures + the 32-bit version code returned to the guest when it invokes the + XENVER_version call; typically (XEN_MAJOR << 16 | XEN_MINOR). PV + Xen guests will often use this to as a dummy hypercall to trigger + event channel delivery, so responding within the kernel without + exiting to userspace is beneficial. 4.127 KVM_XEN_HVM_GET_ATTR -------------------------- @@ -5258,7 +5310,8 @@ KVM_XEN_ATTR_TYPE_UPCALL_VECTOR :Returns: 0 on success, < 0 on error Allows Xen VM attributes to be read. For the structure and types, -see KVM_XEN_HVM_SET_ATTR above. +see KVM_XEN_HVM_SET_ATTR above. The KVM_XEN_ATTR_TYPE_EVTCHN +attribute cannot be read. 4.128 KVM_XEN_VCPU_SET_ATTR --------------------------- @@ -5285,6 +5338,13 @@ see KVM_XEN_HVM_SET_ATTR above. __u64 time_blocked; __u64 time_offline; } runstate; + __u32 vcpu_id; + struct { + __u32 port; + __u32 priority; + __u64 expires_ns; + } timer; + __u8 vector; } u; }; @@ -5326,6 +5386,27 @@ KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST or RUNSTATE_offline) to set the current accounted state as of the adjusted state_entry_time. +KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID + This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates + support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It sets the Xen + vCPU ID of the given vCPU, to allow timer-related VCPU operations to + be intercepted by KVM. + +KVM_XEN_VCPU_ATTR_TYPE_TIMER + This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates + support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It sets the + event channel port/priority for the VIRQ_TIMER of the vCPU, as well + as allowing a pending timer to be saved/restored. + +KVM_XEN_VCPU_ATTR_TYPE_UPCALL_VECTOR + This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates + support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It sets the + per-vCPU local APIC upcall vector, configured by a Xen guest with + the HVMOP_set_evtchn_upcall_vector hypercall. This is typically + used by Windows guests, and is distinct from the HVM-wide upcall + vector configured with HVM_PARAM_CALLBACK_IRQ. + + 4.129 KVM_XEN_VCPU_GET_ATTR --------------------------- @@ -5645,6 +5726,25 @@ enabled with ``arch_prctl()``, but this may change in the future. The offsets of the state save areas in struct kvm_xsave follow the contents of CPUID leaf 0xD on the host. +4.135 KVM_XEN_HVM_EVTCHN_SEND +----------------------------- + +:Capability: KVM_CAP_XEN_HVM / KVM_XEN_HVM_CONFIG_EVTCHN_SEND +:Architectures: x86 +:Type: vm ioctl +:Parameters: struct kvm_irq_routing_xen_evtchn +:Returns: 0 on success, < 0 on error + + +:: + + struct kvm_irq_routing_xen_evtchn { + __u32 port; + __u32 vcpu; + __u32 priority; + }; + +This ioctl injects an event channel interrupt directly to the guest vCPU. 5. The kvm_run structure ======================== @@ -7620,8 +7720,9 @@ PVHVM guests. Valid flags are:: #define KVM_XEN_HVM_CONFIG_HYPERCALL_MSR (1 << 0) #define KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL (1 << 1) #define KVM_XEN_HVM_CONFIG_SHARED_INFO (1 << 2) - #define KVM_XEN_HVM_CONFIG_RUNSTATE (1 << 2) - #define KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL (1 << 3) + #define KVM_XEN_HVM_CONFIG_RUNSTATE (1 << 3) + #define KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL (1 << 4) + #define KVM_XEN_HVM_CONFIG_EVTCHN_SEND (1 << 5) The KVM_XEN_HVM_CONFIG_HYPERCALL_MSR flag indicates that the KVM_XEN_HVM_CONFIG ioctl is available, for the guest to set its hypercall page. @@ -7645,6 +7746,14 @@ The KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL flag indicates that IRQ routing entries of the type KVM_IRQ_ROUTING_XEN_EVTCHN are supported, with the priority field set to indicate 2 level event channel delivery. +The KVM_XEN_HVM_CONFIG_EVTCHN_SEND flag indicates that KVM supports +injecting event channel events directly into the guest with the +KVM_XEN_HVM_EVTCHN_SEND ioctl. It also indicates support for the +KVM_XEN_ATTR_TYPE_EVTCHN/XEN_VERSION HVM attributes and the +KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID/TIMER/UPCALL_VECTOR vCPU attributes. +related to event channel delivery, timers, and the XENVER_version +interception. + 8.31 KVM_CAP_PPC_MULTITCE ------------------------- -- cgit From ffbb61d09fc56c85e28b110494f3788d0ed4d1f8 Mon Sep 17 00:00:00 2001 From: David Woodhouse Date: Fri, 25 Feb 2022 14:53:02 +0000 Subject: KVM: x86: Accept KVM_[GS]ET_TSC_KHZ as a VM ioctl. This sets the default TSC frequency for subsequently created vCPUs. Signed-off-by: David Woodhouse Message-Id: <20220225145304.36166-2-dwmw2@infradead.org> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index fdfd9e1bc7f7..b102ba7cf903 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -1897,22 +1897,25 @@ the future. 4.55 KVM_SET_TSC_KHZ -------------------- -:Capability: KVM_CAP_TSC_CONTROL +:Capability: KVM_CAP_TSC_CONTROL / KVM_CAP_VM_TSC_CONTROL :Architectures: x86 -:Type: vcpu ioctl +:Type: vcpu ioctl / vm ioctl :Parameters: virtual tsc_khz :Returns: 0 on success, -1 on error Specifies the tsc frequency for the virtual machine. The unit of the frequency is KHz. +If the KVM_CAP_VM_TSC_CONTROL capability is advertised, this can also +be used as a vm ioctl to set the initial tsc frequency of subsequently +created vCPUs. 4.56 KVM_GET_TSC_KHZ -------------------- -:Capability: KVM_CAP_GET_TSC_KHZ +:Capability: KVM_CAP_GET_TSC_KHZ / KVM_CAP_VM_TSC_CONTROL :Architectures: x86 -:Type: vcpu ioctl +:Type: vcpu ioctl / vm ioctl :Parameters: none :Returns: virtual tsc-khz on success, negative value on error -- cgit From 768c1e7f1de03afd0b55e0e951efc272309eeb52 Mon Sep 17 00:00:00 2001 From: Beau Belgrave Date: Tue, 29 Mar 2022 10:30:51 -0700 Subject: tracing/user_events: Remove eBPF interfaces Remove eBPF interfaces within user_events to ensure they are fully reviewed. Link: https://lore.kernel.org/all/20220329165718.GA10381@kbox/ Link: https://lkml.kernel.org/r/20220329173051.10087-1-beaub@linux.microsoft.com Suggested-by: Alexei Starovoitov Signed-off-by: Beau Belgrave Signed-off-by: Steven Rostedt (Google) --- Documentation/trace/user_events.rst | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/user_events.rst b/Documentation/trace/user_events.rst index bddedabaca80..c180936f49fc 100644 --- a/Documentation/trace/user_events.rst +++ b/Documentation/trace/user_events.rst @@ -7,7 +7,7 @@ user_events: User-based Event Tracing Overview -------- User based trace events allow user processes to create events and trace data -that can be viewed via existing tools, such as ftrace, perf and eBPF. +that can be viewed via existing tools, such as ftrace and perf. To enable this feature, build your kernel with CONFIG_USER_EVENTS=y. Programs can view status of the events via @@ -67,8 +67,7 @@ The command string format is as follows:: Supported Flags ^^^^^^^^^^^^^^^ -**BPF_ITER** - EBPF programs attached to this event will get the raw iovec -struct instead of any data copies for max performance. +None yet Field Format ^^^^^^^^^^^^ @@ -160,7 +159,7 @@ The following values are defined to aid in checking what has been attached: **EVENT_STATUS_FTRACE** - Bit set if ftrace has been attached (Bit 0). -**EVENT_STATUS_PERF** - Bit set if perf/eBPF has been attached (Bit 1). +**EVENT_STATUS_PERF** - Bit set if perf has been attached (Bit 1). Writing Data ------------ @@ -204,13 +203,6 @@ It's advised for user programs to do the following:: **NOTE:** *The write_index is not emitted out into the trace being recorded.* -EBPF ----- -EBPF programs that attach to a user-based event tracepoint are given a pointer -to a struct user_bpf_context. The bpf context contains the data type (which can -be a user or kernel buffer, or can be a pointer to the iovec) and the data -length that was emitted (minus the write_index). - Example Code ------------ See sample code in samples/user_events. -- cgit From 5a48b7433a5aee719ab242d2feadaf4c9e065989 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Sat, 2 Apr 2022 09:46:23 -0500 Subject: docs: net: dsa: fix minor grammar and punctuation issues Fix a few typos and minor grammatical issues. Signed-off-by: Bjorn Helgaas Signed-off-by: David S. Miller --- Documentation/networking/dsa/dsa.rst | 64 ++++++++++++++++++------------------ 1 file changed, 32 insertions(+), 32 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 89bb4fa4c362..ddc1dd039337 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -10,21 +10,21 @@ in joining the effort. Design principles ================= -The Distributed Switch Architecture is a subsystem which was primarily designed -to support Marvell Ethernet switches (MV88E6xxx, a.k.a Linkstreet product line) -using Linux, but has since evolved to support other vendors as well. +The Distributed Switch Architecture subsystem was primarily designed to +support Marvell Ethernet switches (MV88E6xxx, a.k.a. Link Street product +line) using Linux, but has since evolved to support other vendors as well. The original philosophy behind this design was to be able to use unmodified Linux tools such as bridge, iproute2, ifconfig to work transparently whether they configured/queried a switch port network device or a regular network device. -An Ethernet switch is typically comprised of multiple front-panel ports, and one -or more CPU or management port. The DSA subsystem currently relies on the +An Ethernet switch typically comprises multiple front-panel ports and one +or more CPU or management ports. The DSA subsystem currently relies on the presence of a management port connected to an Ethernet controller capable of receiving Ethernet frames from the switch. This is a very common setup for all kinds of Ethernet switches found in Small Home and Office products: routers, -gateways, or even top-of-the rack switches. This host Ethernet controller will +gateways, or even top-of-rack switches. This host Ethernet controller will be later referred to as "master" and "cpu" in DSA terminology and code. The D in DSA stands for Distributed, because the subsystem has been designed @@ -33,14 +33,14 @@ using upstream and downstream Ethernet links between switches. These specific ports are referred to as "dsa" ports in DSA terminology and code. A collection of multiple switches connected to each other is called a "switch tree". -For each front-panel port, DSA will create specialized network devices which are +For each front-panel port, DSA creates specialized network devices which are used as controlling and data-flowing endpoints for use by the Linux networking stack. These specialized network interfaces are referred to as "slave" network interfaces in DSA terminology and code. The ideal case for using DSA is when an Ethernet switch supports a "switch tag" which is a hardware feature making the switch insert a specific tag for each -Ethernet frames it received to/from specific ports to help the management +Ethernet frame it receives to/from specific ports to help the management interface figure out: - what port is this frame coming from @@ -125,7 +125,7 @@ other switches from the same fabric, and in this case, the outermost switch ports must decapsulate the packet. Note that in certain cases, it might be the case that the tagging format used -by a leaf switch (not connected directly to the CPU) to not be the same as what +by a leaf switch (not connected directly to the CPU) is not the same as what the network stack sees. This can be seen with Marvell switch trees, where the CPU port can be configured to use either the DSA or the Ethertype DSA (EDSA) format, but the DSA links are configured to use the shorter (without Ethertype) @@ -270,21 +270,21 @@ These interfaces are specialized in order to: to/from specific switch ports - query the switch for ethtool operations: statistics, link state, Wake-on-LAN, register dumps... -- external/internal PHY management: link, auto-negotiation etc. +- manage external/internal PHY: link, auto-negotiation, etc. These slave network devices have custom net_device_ops and ethtool_ops function pointers which allow DSA to introduce a level of layering between the networking -stack/ethtool, and the switch driver implementation. +stack/ethtool and the switch driver implementation. Upon frame transmission from these slave network devices, DSA will look up which -switch tagging protocol is currently registered with these network devices, and +switch tagging protocol is currently registered with these network devices and invoke a specific transmit routine which takes care of adding the relevant switch tag in the Ethernet frames. These frames are then queued for transmission using the master network device -``ndo_start_xmit()`` function, since they contain the appropriate switch tag, the +``ndo_start_xmit()`` function. Since they contain the appropriate switch tag, the Ethernet switch will be able to process these incoming frames from the -management interface and delivers these frames to the physical switch port. +management interface and deliver them to the physical switch port. Graphical representation ------------------------ @@ -330,9 +330,9 @@ MDIO reads/writes towards specific PHY addresses. In most MDIO-connected switches, these functions would utilize direct or indirect PHY addressing mode to return standard MII registers from the switch builtin PHYs, allowing the PHY library and/or to return link status, link partner pages, auto-negotiation -results etc.. +results, etc. -For Ethernet switches which have both external and internal MDIO busses, the +For Ethernet switches which have both external and internal MDIO buses, the slave MII bus can be utilized to mux/demux MDIO reads and writes towards either internal or external MDIO devices this switch might be connected to: internal PHYs, external PHYs, or even external switches. @@ -349,7 +349,7 @@ DSA data structures are defined in ``include/net/dsa.h`` as well as table indication (when cascading switches) - ``dsa_platform_data``: platform device configuration data which can reference - a collection of dsa_chip_data structure if multiples switches are cascaded, + a collection of dsa_chip_data structures if multiple switches are cascaded, the master network device this switch tree is attached to needs to be referenced @@ -426,7 +426,7 @@ logic basically looks like this: "phy-handle" property, if found, this PHY device is created and registered using ``of_phy_connect()`` -- if Device Tree is used, and the PHY device is "fixed", that is, conforms to +- if Device Tree is used and the PHY device is "fixed", that is, conforms to the definition of a non-MDIO managed PHY as defined in ``Documentation/devicetree/bindings/net/fixed-link.txt``, the PHY is registered and connected transparently using the special fixed MDIO bus driver @@ -481,7 +481,7 @@ Device Tree DSA features a standardized binding which is documented in ``Documentation/devicetree/bindings/net/dsa/dsa.txt``. PHY/MDIO library helper functions such as ``of_get_phy_mode()``, ``of_phy_connect()`` are also used to query -per-port PHY specific details: interface connection, MDIO bus location etc.. +per-port PHY specific details: interface connection, MDIO bus location, etc. Driver development ================== @@ -509,7 +509,7 @@ Switch configuration - ``setup``: setup function for the switch, this function is responsible for setting up the ``dsa_switch_ops`` private structure with all it needs: register maps, - interrupts, mutexes, locks etc.. This function is also expected to properly + interrupts, mutexes, locks, etc. This function is also expected to properly configure the switch to separate all network interfaces from each other, that is, they should be isolated by the switch hardware itself, typically by creating a Port-based VLAN ID for each port and allowing only the CPU port and the @@ -526,13 +526,13 @@ PHY devices and link management - ``get_phy_flags``: Some switches are interfaced to various kinds of Ethernet PHYs, if the PHY library PHY driver needs to know about information it cannot obtain on its own (e.g.: coming from switch memory mapped registers), this function - should return a 32-bits bitmask of "flags", that is private between the switch + should return a 32-bit bitmask of "flags" that is private between the switch driver and the Ethernet PHY driver in ``drivers/net/phy/\*``. - ``phy_read``: Function invoked by the DSA slave MDIO bus when attempting to read the switch port MDIO registers. If unavailable, return 0xffff for each read. For builtin switch Ethernet PHYs, this function should allow reading the link - status, auto-negotiation results, link partner pages etc.. + status, auto-negotiation results, link partner pages, etc. - ``phy_write``: Function invoked by the DSA slave MDIO bus when attempting to write to the switch port MDIO registers. If unavailable return a negative error @@ -554,7 +554,7 @@ Ethtool operations ------------------ - ``get_strings``: ethtool function used to query the driver's strings, will - typically return statistics strings, private flags strings etc. + typically return statistics strings, private flags strings, etc. - ``get_ethtool_stats``: ethtool function used to query per-port statistics and return their values. DSA overlays slave network devices general statistics: @@ -564,7 +564,7 @@ Ethtool operations - ``get_sset_count``: ethtool function used to query the number of statistics items - ``get_wol``: ethtool function used to obtain Wake-on-LAN settings per-port, this - function may, for certain implementations also query the master network device + function may for certain implementations also query the master network device Wake-on-LAN settings if this interface needs to participate in Wake-on-LAN - ``set_wol``: ethtool function used to configure Wake-on-LAN settings per-port, @@ -607,14 +607,14 @@ Power management in a fully active state - ``port_enable``: function invoked by the DSA slave network device ndo_open - function when a port is administratively brought up, this function should be - fully enabling a given switch port. DSA takes care of marking the port with + function when a port is administratively brought up, this function should + fully enable a given switch port. DSA takes care of marking the port with ``BR_STATE_BLOCKING`` if the port is a bridge member, or ``BR_STATE_FORWARDING`` if it was not, and propagating these changes down to the hardware - ``port_disable``: function invoked by the DSA slave network device ndo_close - function when a port is administratively brought down, this function should be - fully disabling a given switch port. DSA takes care of marking the port with + function when a port is administratively brought down, this function should + fully disable a given switch port. DSA takes care of marking the port with ``BR_STATE_DISABLED`` and propagating changes to the hardware if this port is disabled while being a bridge member @@ -622,12 +622,12 @@ Bridge layer ------------ - ``port_bridge_join``: bridge layer function invoked when a given switch port is - added to a bridge, this function should be doing the necessary at the switch - level to permit the joining port from being added to the relevant logical + added to a bridge, this function should do what's necessary at the switch + level to permit the joining port to be added to the relevant logical domain for it to ingress/egress traffic with other members of the bridge. - ``port_bridge_leave``: bridge layer function invoked when a given switch port is - removed from a bridge, this function should be doing the necessary at the + removed from a bridge, this function should do what's necessary at the switch level to deny the leaving port from ingress/egress traffic from the remaining bridge members. When the port leaves the bridge, it should be aged out at the switch hardware for the switch to (re) learn MAC addresses behind @@ -663,7 +663,7 @@ Bridge layer point for drivers that need to configure the hardware for enabling this feature. -- ``port_bridge_tx_fwd_unoffload``: bridge layer function invoken when a driver +- ``port_bridge_tx_fwd_unoffload``: bridge layer function invoked when a driver leaves a bridge port which had the TX forwarding offload feature enabled. Bridge VLAN filtering -- cgit From c54ce1a17232215c4a518149292b41835992eee8 Mon Sep 17 00:00:00 2001 From: Sameer Pujar Date: Thu, 31 Mar 2022 19:33:27 +0530 Subject: ASoC: tegra: Add binding doc for ASRC module This patch adds YAML schema for DT bindings of Asynchronous Sample Rate Converter (ASRC) module. It will be registered as an ASoC component and can be plugged into an audio path as per need via ALSA mixer controls. The bindings are applicable on Tegra186 and later where the ASRC device is present. Signed-off-by: Sameer Pujar Link: https://lore.kernel.org/r/1648735412-32220-2-git-send-email-spujar@nvidia.com Signed-off-by: Mark Brown --- .../bindings/sound/nvidia,tegra186-asrc.yaml | 81 ++++++++++++++++++++++ .../bindings/sound/nvidia,tegra210-ahub.yaml | 4 ++ 2 files changed, 85 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra186-asrc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra186-asrc.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra186-asrc.yaml new file mode 100644 index 000000000000..520d0d063d1a --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra186-asrc.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra186-asrc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra186 ASRC Device Tree Bindings + +description: | + Asynchronous Sample Rate Converter (ASRC) converts the sampling frequency + of the input signal from one frequency to another. It can handle over a + wide range of sample rate ratios (freq_in/freq_out) from 1:24 to 24:1. + ASRC has two modes of operation. One where ratio can be programmed in SW + and the other where it gets the information from ratio estimator module. + + It supports sample rate conversions in the range of 8 to 192 kHz and + supports 6 streams upto 12 total channels. The input data size can be + 16, 24 and 32 bits. + +maintainers: + - Jon Hunter + - Mohan Kumar + - Sameer Pujar + +allOf: + - $ref: name-prefix.yaml# + +properties: + $nodename: + pattern: "^asrc@[0-9a-f]*$" + + compatible: + oneOf: + - const: nvidia,tegra186-asrc + - items: + - enum: + - nvidia,tegra234-asrc + - nvidia,tegra194-asrc + - const: nvidia,tegra186-asrc + + reg: + maxItems: 1 + + sound-name-prefix: + pattern: "^ASRC[1-9]$" + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + ASRC has seven input ports and six output ports. Accordingly ACIF + (Audio Client Interfaces) port nodes are defined to represent the + ASRC inputs (port 0 to 6) and outputs (port 7 to 12). These are + connected to corresponding ports on AHUB (Audio Hub). Additional + input (port 6) is for receiving ratio information from estimator. + + patternProperties: + '^port@[0-6]': + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: ASRC ACIF input ports + '^port@[7-9]|1[1-2]': + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: ASRC ACIF output ports + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + + asrc@2910000 { + compatible = "nvidia,tegra186-asrc"; + reg = <0x2910000 0x2000>; + sound-name-prefix = "ASRC1"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml index 4727f1e42c53..6df6f858038c 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml @@ -106,6 +106,10 @@ patternProperties: type: object $ref: nvidia,tegra210-mixer.yaml# + '^asrc@[0-9a-f]+$': + type: object + $ref: nvidia,tegra186-asrc.yaml# + required: - compatible - reg -- cgit From 0e336eeaf467cdd86d827d696e24081b638ef61c Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Fri, 25 Mar 2022 15:31:20 +0000 Subject: ASoC: wm8731: Convert DT bindings to YAML format Convert the WM8731 DT bindings to YAML format, including addition of documentation for the regulator and clock bindings which the driver has had for some time but which were not covered in the bindings document. Signed-off-by: Mark Brown Cc: Rob Herring Cc: devicetree@vger.kernel.org Acked-by: Charles Keepax Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220325153121.1598494-7-broonie@kernel.org Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/wlf,wm8731.yaml | 97 ++++++++++++++++++++++ Documentation/devicetree/bindings/sound/wm8731.txt | 27 ------ 2 files changed, 97 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8731.yaml delete mode 100644 Documentation/devicetree/bindings/sound/wm8731.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8731.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8731.yaml new file mode 100644 index 000000000000..e7220e8b49f0 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8731.yaml @@ -0,0 +1,97 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8731.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Wolfson Microelectromics WM8731 audio CODEC + +maintainers: + - patches@opensource.cirrus.com + +description: | + Wolfson Microelectronics WM8731 audio CODEC + + Pins on the device (for linking into audio routes): + * LOUT: Left Channel Line Output + * ROUT: Right Channel Line Output + * LHPOUT: Left Channel Headphone Output + * RHPOUT: Right Channel Headphone Output + * LLINEIN: Left Channel Line Input + * RLINEIN: Right Channel Line Input + * MICIN: Microphone Input + +properties: + compatible: + enum: + - wlf,wm8731 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + + clocks: + description: Clock provider for MCLK pin. + maxItems: 1 + + clock-names: + items: + - const: mclk + + AVDD-supply: + description: Analog power supply regulator on the AVDD pin. + + HPVDD-supply: + description: Headphone power supply regulator on the HPVDD pin. + + DBVDD-supply: + description: Digital buffer supply regulator for the DBVDD pin. + + DCVDD-supply: + description: Digital core supply regulator for the DCVDD pin. + + spi-max-frequency: true + +additionalProperties: false + +required: + - reg + - compatible + - AVDD-supply + - HPVDD-supply + - DBVDD-supply + - DCVDD-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + wm8731_i2c: codec@0 { + compatible = "wlf,wm8731"; + reg = <0>; + spi-max-frequency = <12500000>; + + AVDD-supply = <&avdd_reg>; + HPVDD-supply = <&hpvdd_reg>; + DCVDD-supply = <&dcvdd_reg>; + DBVDD-supply = <&dbvdd_reg>; + }; + }; + - | + + i2c { + #address-cells = <1>; + #size-cells = <0>; + wm8731_spi: codec@1b { + compatible = "wlf,wm8731"; + reg = <0x1b>; + + AVDD-supply = <&avdd_reg>; + HPVDD-supply = <&hpvdd_reg>; + DCVDD-supply = <&dcvdd_reg>; + DBVDD-supply = <&dbvdd_reg>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wm8731.txt b/Documentation/devicetree/bindings/sound/wm8731.txt deleted file mode 100644 index f660d9bb0e69..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8731.txt +++ /dev/null @@ -1,27 +0,0 @@ -WM8731 audio CODEC - -This device supports both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - - compatible : "wlf,wm8731" - - - reg : the I2C address of the device for I2C, the chip select - number for SPI. - -Example: - -wm8731: codec@1a { - compatible = "wlf,wm8731"; - reg = <0x1a>; -}; - -Available audio endpoints for an audio-routing table: - * LOUT: Left Channel Line Output - * ROUT: Right Channel Line Output - * LHPOUT: Left Channel Headphone Output - * RHPOUT: Right Channel Headphone Output - * LLINEIN: Left Channel Line Input - * RLINEIN: Right Channel Line Input - * MICIN: Microphone Input -- cgit From dc16399078aea4c98f17aa99f0cdea9d5ac9c4a9 Mon Sep 17 00:00:00 2001 From: Trevor Wu Date: Thu, 24 Mar 2022 13:38:48 +0800 Subject: ASoC: dt-bindings: mediatek: mt8195: merge mt8195 machine yaml Because the same binding components can be shared by all codecs combinations, we only reserve one binding file for mt8195 machine driver and rename to a generic name. We use compatible string to separate different codec combination instead of creating a new binding file for new codec combination. Signed-off-by: Trevor Wu Reviewed-by: Miles Chen Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220324053851.27350-4-trevor.wu@mediatek.com Signed-off-by: Mark Brown --- .../sound/mt8195-mt6359-rt1011-rt5682.yaml | 51 ------------------ .../sound/mt8195-mt6359-rt1019-rt5682.yaml | 61 --------------------- .../devicetree/bindings/sound/mt8195-mt6359.yaml | 63 ++++++++++++++++++++++ 3 files changed, 63 insertions(+), 112 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1011-rt5682.yaml delete mode 100644 Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1019-rt5682.yaml create mode 100644 Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1011-rt5682.yaml b/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1011-rt5682.yaml deleted file mode 100644 index cf6ad7933e23..000000000000 --- a/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1011-rt5682.yaml +++ /dev/null @@ -1,51 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/sound/mt8195-mt6359-rt1011-rt5682.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Mediatek MT8195 with MT6359, RT1011 and RT5682 ASoC sound card driver - -maintainers: - - Trevor Wu - -description: - This binding describes the MT8195 sound card with RT1011 and RT5682. - -properties: - compatible: - const: mediatek,mt8195_mt6359_rt1011_rt5682 - - model: - $ref: /schemas/types.yaml#/definitions/string - description: User specified audio sound card name - - mediatek,platform: - $ref: "/schemas/types.yaml#/definitions/phandle" - description: The phandle of MT8195 ASoC platform. - - mediatek,dptx-codec: - $ref: "/schemas/types.yaml#/definitions/phandle" - description: The phandle of MT8195 Display Port Tx codec node. - - mediatek,hdmi-codec: - $ref: "/schemas/types.yaml#/definitions/phandle" - description: The phandle of MT8195 HDMI codec node. - -additionalProperties: false - -required: - - compatible - - mediatek,platform - -examples: - - | - - sound: mt8195-sound { - compatible = "mediatek,mt8195_mt6359_rt1011_rt5682"; - mediatek,platform = <&afe>; - pinctrl-names = "default"; - pinctrl-0 = <&aud_pins_default>; - }; - -... diff --git a/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1019-rt5682.yaml b/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1019-rt5682.yaml deleted file mode 100644 index 8f177e02ad35..000000000000 --- a/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1019-rt5682.yaml +++ /dev/null @@ -1,61 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/sound/mt8195-mt6359-rt1019-rt5682.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Mediatek MT8195 with MT6359, RT1019 and RT5682 ASoC sound card driver - -maintainers: - - Trevor Wu - -description: - This binding describes the MT8195 sound card. - -properties: - compatible: - const: mediatek,mt8195_mt6359_rt1019_rt5682 - - model: - $ref: /schemas/types.yaml#/definitions/string - description: User specified audio sound card name - - mediatek,platform: - $ref: "/schemas/types.yaml#/definitions/phandle" - description: The phandle of MT8195 ASoC platform. - - mediatek,dptx-codec: - $ref: "/schemas/types.yaml#/definitions/phandle" - description: The phandle of MT8195 Display Port Tx codec node. - - mediatek,hdmi-codec: - $ref: "/schemas/types.yaml#/definitions/phandle" - description: The phandle of MT8195 HDMI codec node. - - mediatek,adsp: - $ref: "/schemas/types.yaml#/definitions/phandle" - description: The phandle of MT8195 ADSP platform. - - mediatek,dai-link: - $ref: /schemas/types.yaml#/definitions/string-array - description: - A list of the desired dai-links in the sound card. Each entry is a - name defined in the machine driver. - -additionalProperties: false - -required: - - compatible - - mediatek,platform - -examples: - - | - - sound: mt8195-sound { - compatible = "mediatek,mt8195_mt6359_rt1019_rt5682"; - mediatek,platform = <&afe>; - pinctrl-names = "default"; - pinctrl-0 = <&aud_pins_default>; - }; - -... diff --git a/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml b/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml new file mode 100644 index 000000000000..04953f5b44a4 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mt8195-mt6359.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek MT8195 ASoC sound card driver + +maintainers: + - Trevor Wu + +description: + This binding describes the MT8195 sound card. + +properties: + compatible: + enum: + - mediatek,mt8195_mt6359_rt1019_rt5682 + - mediatek,mt8195_mt6359_rt1011_rt5682 + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + + mediatek,platform: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of MT8195 ASoC platform. + + mediatek,dptx-codec: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of MT8195 Display Port Tx codec node. + + mediatek,hdmi-codec: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of MT8195 HDMI codec node. + + mediatek,adsp: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of MT8195 ADSP platform. + + mediatek,dai-link: + $ref: /schemas/types.yaml#/definitions/string-array + description: + A list of the desired dai-links in the sound card. Each entry is a + name defined in the machine driver. + +additionalProperties: false + +required: + - compatible + - mediatek,platform + +examples: + - | + + sound: mt8195-sound { + compatible = "mediatek,mt8195_mt6359_rt1019_rt5682"; + mediatek,platform = <&afe>; + pinctrl-names = "default"; + pinctrl-0 = <&aud_pins_default>; + }; + +... -- cgit From cae34da5323b6ce4d0dc365d1b971f838dcff318 Mon Sep 17 00:00:00 2001 From: Trevor Wu Date: Thu, 24 Mar 2022 13:38:51 +0800 Subject: ASoC: dt-bindings: mediatek: mt8195: support mt8195-mt6359-max98390-rt5682 This patch adds compatible string "mediatek,mt8195-mt6359-max98390-rt5682" to support mt8195 board with mt6359, max98390 and rt5682. Signed-off-by: Trevor Wu Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220324053851.27350-7-trevor.wu@mediatek.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml b/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml index 04953f5b44a4..ad3447ff8b2c 100644 --- a/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml +++ b/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml @@ -17,6 +17,7 @@ properties: enum: - mediatek,mt8195_mt6359_rt1019_rt5682 - mediatek,mt8195_mt6359_rt1011_rt5682 + - mediatek,mt8195_mt6359_max98390_rt5682 model: $ref: /schemas/types.yaml#/definitions/string -- cgit From 2a826d9c4251e4a64aa79113aac8cedf7cd0ff57 Mon Sep 17 00:00:00 2001 From: ChiYuan Huang Date: Sat, 26 Mar 2022 19:39:47 +0800 Subject: regulator: Add binding for Richtek RT5759 DCDC converter Add bindings for Richtek RT5759 high-performance DCDC converter. Signed-off-by: ChiYuan Huang Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/1648294788-11758-2-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown --- .../regulator/richtek,rt5759-regulator.yaml | 90 ++++++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rt5759-regulator.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5759-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5759-regulator.yaml new file mode 100644 index 000000000000..0a4c9576a432 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5759-regulator.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rt5759-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT5759 High Performance DCDC Converter + +maintainers: + - ChiYuan Huang + +description: | + The RT5759 is a high-performance, synchronous step-down DC-DC converter that + can deliver up to 9A output current from 3V to 6.5V input supply, The output + voltage can be programmable with I2C controlled 7-Bit VID. + + Datasheet is available at + https://www.richtek.com/assets/product_file/RT5759/DS5759-00.pdf + +properties: + compatible: + enum: + - richtek,rt5759 + - richtek,rt5759a + + reg: + maxItems: 1 + + regulator-allowed-modes: + description: | + buck allowed operating mode + 0: auto mode (PSKIP: pulse skipping) + 1: force pwm mode + items: + enum: [0, 1] + + richtek,watchdog-enable: + description: enable the external watchdog reset pin listening + type: boolean + +allOf: + - $ref: regulator.yaml# + + - if: + properties: + compatible: + contains: + const: richtek,rt5759 + then: + properties: + richtek,watchdog-enable: false + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + # example 1 for RT5759 + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@62 { + compatible = "richtek,rt5759"; + reg = <0x62>; + regulator-name = "rt5759-buck"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on; + }; + }; + # example 2 for RT5759A + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@62 { + compatible = "richtek,rt5759a"; + reg = <0x62>; + regulator-name = "rt5759a-buck"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <1725000>; + regulator-boot-on; + richtek,watchdog-enable; + }; + }; -- cgit From 41812783057c01e4e5f1eec649607e4773124dba Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 1 Apr 2022 17:37:11 +0200 Subject: regulator: dt-bindings: richtek,rt4801: minor comments adjustments Correct grammar in 'enable-gpios' description and remove useless comment about regulator nodes, because these are obvious from patternProperties. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220401153711.1057853-1-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/richtek,rt4801-regulator.yaml | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml index 235e593b3b2c..4a4dfa7d9d09 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml @@ -17,9 +17,6 @@ description: | Datasheet is available at https://www.richtek.com/assets/product_file/RT4801H/DS4801H-00.pdf -#The valid names for RT4801 regulator nodes are: -#DSVP, DSVN - properties: compatible: enum: @@ -33,8 +30,8 @@ properties: The first one is ENP to enable DSVP, and second one is ENM to enable DSVN. Number of GPIO in the array list could be 1 or 2. If only one gpio is specified, only one gpio used to control ENP/ENM. - Else both are spefied, DSVP/DSVN could be controlled individually. - Othersie, this property not specified. treat both as always-on regulator. + Else if both are specified, DSVP/DSVN could be controlled individually. + If this property not specified, treat both as always-on regulators. minItems: 1 maxItems: 2 -- cgit From a4765dfb80a7333aaac394a5ba20056d11b55636 Mon Sep 17 00:00:00 2001 From: Leilk Liu Date: Mon, 21 Mar 2022 09:39:21 +0800 Subject: spi: support hclk this patch support hclk for AHB bus. Signed-off-by: Leilk Liu Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220321013922.24067-3-leilk.liu@mediatek.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml index 818130b11bb9..94ef0552bd42 100644 --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml @@ -53,16 +53,20 @@ properties: maxItems: 1 clocks: + minItems: 3 items: - description: clock used for the parent clock - description: clock used for the muxes clock - description: clock used for the clock gate + - description: clock used for the AHB bus, this clock is optional clock-names: + minItems: 3 items: - const: parent-clk - const: sel-clk - const: spi-clk + - const: hclk mediatek,pad-select: $ref: /schemas/types.yaml#/definitions/uint32-array -- cgit From ce92d6743fd55331b2466e0b4e6fa004f2cc6cad Mon Sep 17 00:00:00 2001 From: "Sicelo A. Mhlongo" Date: Mon, 7 Mar 2022 15:25:00 +0200 Subject: dt-bindings: iio: st,st-sensors add LIS302DL Update st,st-sensors bindings for STMicroelectronics LIS302DL variant Reviewed-by: Linus Walleij Acked-by: Rob Herring Signed-off-by: Sicelo A. Mhlongo Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220307132502.73854-2-absicsz@gmail.com Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/st,st-sensors.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml index 9735a2048255..fcb2902683c7 100644 --- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml +++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml @@ -29,6 +29,7 @@ properties: - st,lis2dw12 - st,lis2hh12 - st,lis2dh12-accel + - st,lis302dl - st,lis331dl-accel - st,lis331dlh-accel - st,lis3de -- cgit From c4dbfed37fef7e86a82cd28c97ca7d25b2516e37 Mon Sep 17 00:00:00 2001 From: Michael Srba Date: Wed, 23 Mar 2022 13:15:49 +0100 Subject: dt-bindings: iio: imu: mpu6050: Document invensense,icm20608d ICM-20608-D differs from the other ICM-20608 variants by having a DMP (Digital Motion Processor) core tacked on. Despite having a different WHOAMI register, this variant is completely interchangeable with the other ICM-20608 variants by simply pretending the DMP core doesn't exist. Signed-off-by: Michael Srba Acked-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220323121550.16096-2-michael.srba@seznam.cz Signed-off-by: Jonathan Cameron --- .../bindings/iio/imu/invensense,mpu6050.yaml | 34 ++++++++++++---------- 1 file changed, 19 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml index d69595a524c1..3ebc6526d82d 100644 --- a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml +++ b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml @@ -14,21 +14,25 @@ description: | properties: compatible: - enum: - - invensense,iam20680 - - invensense,icm20608 - - invensense,icm20609 - - invensense,icm20689 - - invensense,icm20602 - - invensense,icm20690 - - invensense,mpu6000 - - invensense,mpu6050 - - invensense,mpu6500 - - invensense,mpu6515 - - invensense,mpu6880 - - invensense,mpu9150 - - invensense,mpu9250 - - invensense,mpu9255 + oneOf: + - enum: + - invensense,iam20680 + - invensense,icm20608 + - invensense,icm20609 + - invensense,icm20689 + - invensense,icm20602 + - invensense,icm20690 + - invensense,mpu6000 + - invensense,mpu6050 + - invensense,mpu6500 + - invensense,mpu6515 + - invensense,mpu6880 + - invensense,mpu9150 + - invensense,mpu9250 + - invensense,mpu9255 + - items: + - const: invensense,icm20608d + - const: invensense,icm20608 reg: maxItems: 1 -- cgit From 210b9ddbcdbcb91d1ed45848863c7d4c68298278 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Mon, 28 Mar 2022 21:47:16 +0200 Subject: dt-bindings: iio: adc: ti,ads1015: Add missing ADS1115 compatible string Add missing ti,ads1115 compatible string. This compatible string is supported by the Linux kernel driver and the ads1015 is a 12bit ADC while ads1115 is 16bit ADC. Add the missing compatible string. Acked-by: Krzysztof Kozlowski Signed-off-by: Marek Vasut Cc: Daniel Baluta Cc: Rob Herring Cc: devicetree@vger.kernel.org Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220328194725.149150-1-marex@denx.de Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml index 2c2d01bbc296..c31c80989cc9 100644 --- a/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/iio/adc/ti,ads1015.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: TI ADS1015 4 channel I2C analog to digital converter +title: TI ADS1015/ADS1115 4 channel I2C analog to digital converter maintainers: - Daniel Baluta @@ -15,7 +15,9 @@ description: | properties: compatible: - const: ti,ads1015 + enum: + - ti,ads1015 + - ti,ads1115 reg: maxItems: 1 -- cgit From 94d9f3cb97f4a2c88d9040504cfcef114adb0741 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Mon, 28 Mar 2022 21:47:17 +0200 Subject: dt-bindings: iio: adc: ti,ads1015: Add TLA2024 compatible string Add ti,tla2024 compatible string. This device is compatible with ADS1015 except it has no on-chip comparator. Acked-by: Krzysztof Kozlowski Signed-off-by: Marek Vasut Reviewed-by: Andy Shevchenko Cc: Daniel Baluta Cc: Rob Herring Cc: devicetree@vger.kernel.org Link: https://lore.kernel.org/r/20220328194725.149150-2-marex@denx.de Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml index c31c80989cc9..a3b79438a13a 100644 --- a/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml @@ -18,6 +18,7 @@ properties: enum: - ti,ads1015 - ti,ads1115 + - ti,tla2024 reg: maxItems: 1 -- cgit From 1625c833db93516faaac5feedadf8d19c14238b6 Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Thu, 27 Jan 2022 12:56:21 +0100 Subject: x86/cpu: Allow feature bit names from /proc/cpuinfo in clearcpuid= Having to give the X86_FEATURE array indices in order to disable a feature bit for testing is not really user-friendly. So accept the feature bit names too. Some feature bits don't have names so there the array indices are still accepted, of course. Clearing CPUID flags is not something which should be done in production so taint the kernel too. An exemplary cmdline would then be something like: clearcpuid=de,440,smca,succory,bmi1,3dnow ("succory" is wrong on purpose). And it says: [ ... ] Clearing CPUID bits: de 13:24 smca (unknown: succory) bmi1 3dnow [ Fix CONFIG_X86_FEATURE_NAMES=n build error as reported by the 0day robot: https://lore.kernel.org/r/202203292206.ICsY2RKX-lkp@intel.com ] Signed-off-by: Borislav Petkov Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20220127115626.14179-2-bp@alien8.de --- Documentation/admin-guide/kernel-parameters.txt | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 3f1cc5e317ed..0ea17869a089 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -631,12 +631,17 @@ Defaults to zero when built as a module and to 10 seconds when built into the kernel. - clearcpuid=BITNUM[,BITNUM...] [X86] + clearcpuid=X[,X...] [X86] Disable CPUID feature X for the kernel. See arch/x86/include/asm/cpufeatures.h for the valid bit - numbers. Note the Linux specific bits are not necessarily - stable over kernel options, but the vendor specific + numbers X. Note the Linux-specific bits are not necessarily + stable over kernel options, but the vendor-specific ones should be. + X can also be a string as appearing in the flags: line + in /proc/cpuinfo which does not have the above + instability issue. However, not all features have names + in /proc/cpuinfo. + Note that using this option will taint your kernel. Also note that user programs calling CPUID directly or using the feature without checking anything will still see it. This just prevents it from -- cgit From c949110ef4e31cb5d3387bd8273fd5de66b5227b Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Thu, 27 Jan 2022 12:56:22 +0100 Subject: x86/cpu: Remove "nosep" That chicken bit was added by 4f88651125e2 ("[PATCH] i386: allow disabling X86_FEATURE_SEP at boot") but measuring int80 vsyscall performance on 32-bit doesn't matter anymore. If still needed, one can boot with clearcpuid=sep to disable that feature for testing. Signed-off-by: Borislav Petkov Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20220127115626.14179-3-bp@alien8.de --- Documentation/admin-guide/kernel-parameters.txt | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 0ea17869a089..a9f3d3158e77 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3665,8 +3665,6 @@ nosbagart [IA-64] - nosep [BUGS=X86-32] Disables x86 SYSENTER/SYSEXIT support. - nosgx [X86-64,SGX] Disables Intel SGX kernel support. nosmp [SMP] Tells an SMP kernel to act as a UP kernel, -- cgit From dbae0a934f09208075ec3e73491bd0844e1397b3 Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Thu, 27 Jan 2022 12:56:23 +0100 Subject: x86/cpu: Remove CONFIG_X86_SMAP and "nosmap" Those were added as part of the SMAP enablement but SMAP is currently an integral part of kernel proper and there's no need to disable it anymore. Rip out that functionality. Leave --uaccess default on for objtool as this is what objtool should do by default anyway. If still needed - clearcpuid=smap. Signed-off-by: Borislav Petkov Reviewed-by: Lai Jiangshan Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20220127115626.14179-4-bp@alien8.de --- Documentation/admin-guide/kernel-parameters.txt | 2 +- Documentation/x86/cpuinfo.rst | 5 ++--- 2 files changed, 3 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a9f3d3158e77..e0bb710f0fa9 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3461,7 +3461,7 @@ noexec=on: enable non-executable mappings (default) noexec=off: disable non-executable mappings - nosmap [X86,PPC] + nosmap [PPC] Disable SMAP (Supervisor Mode Access Prevention) even if it is supported by processor. diff --git a/Documentation/x86/cpuinfo.rst b/Documentation/x86/cpuinfo.rst index 5d54c39a063f..12fbe2b1e98a 100644 --- a/Documentation/x86/cpuinfo.rst +++ b/Documentation/x86/cpuinfo.rst @@ -140,9 +140,8 @@ from #define X86_FEATURE_UMIP (16*32 + 2). In addition, there exists a variety of custom command-line parameters that disable specific features. The list of parameters includes, but is not limited -to, nofsgsbase, nosmap, and nosmep. 5-level paging can also be disabled using -"no5lvl". SMAP and SMEP are disabled with the aforementioned parameters, -respectively. +to, nofsgsbase, and nosmep. 5-level paging can also be disabled using +"no5lvl". SMEP is disabled with the aforementioned parameter. e: The feature was known to be non-functional. ---------------------------------------------- -- cgit From 385d2ae0a1b5efacb30e13a0f0e521490441d9bb Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Thu, 27 Jan 2022 12:56:24 +0100 Subject: x86/cpu: Remove "nosmep" There should be no need to disable SMEP anymore. Signed-off-by: Borislav Petkov Reviewed-by: Lai Jiangshan Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20220127115626.14179-5-bp@alien8.de --- Documentation/admin-guide/kernel-parameters.txt | 2 +- Documentation/x86/cpuinfo.rst | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index e0bb710f0fa9..39ac2c14dd71 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3465,7 +3465,7 @@ Disable SMAP (Supervisor Mode Access Prevention) even if it is supported by processor. - nosmep [X86,PPC64s] + nosmep [PPC64s] Disable SMEP (Supervisor Mode Execution Prevention) even if it is supported by processor. diff --git a/Documentation/x86/cpuinfo.rst b/Documentation/x86/cpuinfo.rst index 12fbe2b1e98a..08246e8ac835 100644 --- a/Documentation/x86/cpuinfo.rst +++ b/Documentation/x86/cpuinfo.rst @@ -140,8 +140,8 @@ from #define X86_FEATURE_UMIP (16*32 + 2). In addition, there exists a variety of custom command-line parameters that disable specific features. The list of parameters includes, but is not limited -to, nofsgsbase, and nosmep. 5-level paging can also be disabled using -"no5lvl". SMEP is disabled with the aforementioned parameter. +to, nofsgsbase, nosgx, noxsave, etc. 5-level paging can also be disabled using +"no5lvl". e: The feature was known to be non-functional. ---------------------------------------------- -- cgit From 76ea0025a214cdf0d2c204f4c21cbffa9fb57c32 Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Thu, 27 Jan 2022 12:56:25 +0100 Subject: x86/cpu: Remove "noexec" It doesn't make any sense to disable non-executable mappings - security-wise or else. So rip out that switch and move the remaining code into setup.c and delete setup_nx.c Signed-off-by: Borislav Petkov Reviewed-by: Lai Jiangshan Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20220127115626.14179-6-bp@alien8.de --- Documentation/admin-guide/kernel-parameters.txt | 5 ----- Documentation/x86/x86_64/boot-options.rst | 9 --------- 2 files changed, 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 39ac2c14dd71..a2299b2ff2c8 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3456,11 +3456,6 @@ noexec [IA-64] - noexec [X86] - On X86-32 available only on PAE configured kernels. - noexec=on: enable non-executable mappings (default) - noexec=off: disable non-executable mappings - nosmap [PPC] Disable SMAP (Supervisor Mode Access Prevention) even if it is supported by processor. diff --git a/Documentation/x86/x86_64/boot-options.rst b/Documentation/x86/x86_64/boot-options.rst index 07aa0007f346..fb6030a25f08 100644 --- a/Documentation/x86/x86_64/boot-options.rst +++ b/Documentation/x86/x86_64/boot-options.rst @@ -157,15 +157,6 @@ Rebooting newer BIOS, or newer board) using this option will ignore the built-in quirk table, and use the generic default reboot actions. -Non Executable Mappings -======================= - - noexec=on|off - on - Enable(default) - off - Disable - NUMA ==== -- cgit From f8858b5eff30d1b2be15ef1ea6285964013b95e6 Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Thu, 27 Jan 2022 12:56:26 +0100 Subject: x86/cpu: Remove "noclflush" Not really needed anymore and there's clearcpuid=. Signed-off-by: Borislav Petkov Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20220127115626.14179-7-bp@alien8.de --- Documentation/admin-guide/kernel-parameters.txt | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a2299b2ff2c8..8c18e7d98f8a 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3444,8 +3444,6 @@ nocache [ARM] - noclflush [BUGS=X86] Don't use the CLFLUSH instruction - delayacct [KNL] Enable per-task delay accounting nodsp [SH] Disable hardware DSP at boot time. -- cgit From 3733db1f77130588c9a2c1596937294998bd7d27 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Tue, 15 Mar 2022 14:29:15 +0000 Subject: dt-bindings: clock: renesas: Document RZ/G2UL SoC Document the device tree binding for the Renesas RZ/G2UL Type-1 and Type-2 SoC. RZ/G2UL Type-2 has fewer clocks than RZ/G2UL Type-1 SoC. Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220315142915.17764-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml index bd3af8fc616b..311a93590597 100644 --- a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml @@ -10,7 +10,7 @@ maintainers: - Geert Uytterhoeven description: | - On Renesas RZ/{G2L,V2L} SoC, the CPG (Clock Pulse Generator) and Module + On Renesas RZ/{G2L,V2L}-alike SoC's, the CPG (Clock Pulse Generator) and Module Standby Mode share the same register block. They provide the following functionalities: @@ -23,8 +23,9 @@ description: | properties: compatible: enum: - - renesas,r9a07g044-cpg # RZ/G2{L,LC} - - renesas,r9a07g054-cpg # RZ/V2L + - renesas,r9a07g043-cpg # RZ/G2UL{Type-1,Type-2} + - renesas,r9a07g044-cpg # RZ/G2{L,LC} + - renesas,r9a07g054-cpg # RZ/V2L reg: maxItems: 1 -- cgit From 8362f5217bc69c3cd30da73cd2d2ae3af4cc8117 Mon Sep 17 00:00:00 2001 From: David Heidelberg Date: Wed, 8 Dec 2021 19:41:49 +0100 Subject: dt-bindings: reset: document deprecated HiSilicon property Documenting deprecated property prevents dt-schema validation errors. Signed-off-by: David Heidelberg Acked-by: Rob Herring Link: https://lore.kernel.org/r/20211208184149.99537-1-david@ixit.cz Signed-off-by: Philipp Zabel --- Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml index b0c41ab1a746..cdfcf32c53fa 100644 --- a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml @@ -24,6 +24,11 @@ properties: - const: hisilicon,hi3670-reset - const: hisilicon,hi3660-reset + hisi,rst-syscon: + deprecated: true + description: phandle of the reset's syscon, use hisilicon,rst-syscon instead + $ref: /schemas/types.yaml#/definitions/phandle + hisilicon,rst-syscon: description: phandle of the reset's syscon. $ref: /schemas/types.yaml#/definitions/phandle -- cgit From 3f285c301cd788164fa776e1f95458c56e68a6ee Mon Sep 17 00:00:00 2001 From: Biju Das Date: Tue, 15 Mar 2022 14:26:38 +0000 Subject: dt-bindings: power: renesas,rzg2l-sysc: Document RZ/G2UL SoC Add DT binding documentation for SYSC controller found on RZ/G2UL SoC's. SYSC controller found on the RZ/G2UL SoC is almost identical to one found on the RZ/G2L SoC's only difference being that the RZ/G2UL has only CA55 core0 reset vector address configuration register. Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220315142644.17660-2-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml index bb433e75a0ee..c31eeb66319f 100644 --- a/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml +++ b/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml @@ -10,8 +10,8 @@ maintainers: - Geert Uytterhoeven description: - The RZ/{G2L,V2L} System Controller (SYSC) performs system control of the LSI - and supports following functions, + The RZ/{G2L,V2L}-alike System Controller (SYSC) performs system control of + the LSI and supports following functions, - External terminal state capture function - 34-bit address space access function - Low power consumption control @@ -20,6 +20,7 @@ description: properties: compatible: enum: + - renesas,r9a07g043-sysc # RZ/G2UL - renesas,r9a07g044-sysc # RZ/G2{L,LC} - renesas,r9a07g054-sysc # RZ/V2L -- cgit From 03cb66463b5547b289099a95ac4ea591cca88ca9 Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Wed, 30 Mar 2022 14:11:18 +0900 Subject: dt-bindings: reset: Add parent "resets" property as optional LD11 mio reset controller has a reset lines from system controller. Add parent "resets" property to fix the following warning. uniphier-ld11-global.dt.yaml: reset: 'resets' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml Signed-off-by: Kunihiko Hayashi Reviewed-by: Krzysztof Kozlowski Signed-off-by: Philipp Zabel Link: https://lore.kernel.org/r/1648617078-8312-1-git-send-email-hayashi.kunihiko@socionext.com --- Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml b/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml index 377a7d242323..6566804ec567 100644 --- a/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml +++ b/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml @@ -55,6 +55,9 @@ properties: "#reset-cells": const: 1 + resets: + maxItems: 1 + additionalProperties: false required: -- cgit From 265a3bf486d4aac913d1bcbe81b01e271328a265 Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Wed, 30 Mar 2022 14:17:03 +0900 Subject: dt-bindings: gpio: uniphier: Add hogs parsing Allow parsing GPIO controller children nodes with GPIO hogs to fix the following warning: uniphier-ld11-ref.dtb: gpio@55000000: 'xirq0-hog' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml Signed-off-by: Kunihiko Hayashi Reviewed-by: Krzysztof Kozlowski Signed-off-by: Bartosz Golaszewski --- .../bindings/gpio/socionext,uniphier-gpio.yaml | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml index bcafa494ed7a..228fa27ffdc3 100644 --- a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml @@ -52,6 +52,23 @@ properties: triplets. $ref: /schemas/types.yaml#/definitions/uint32-matrix +patternProperties: + "^.+-hog(-[0-9]+)?$": + type: object + properties: + gpio-hog: true + gpios: true + input: true + output-high: true + output-low: true + line-name: true + + required: + - gpio-hog + - gpios + + additionalProperties: false + required: - compatible - reg -- cgit From b117c88df0e3b48903c36f97be92bac6a9e03df7 Mon Sep 17 00:00:00 2001 From: Horatiu Vultur Date: Fri, 1 Apr 2022 13:05:20 +0200 Subject: dt-bindings: net: micrel: Revert latency support and timestamping check Revert latency support from binding. Based on the discussion[1], the DT is the wrong place to have the lantecies for the PHY. [1] https://lkml.org/lkml/2022/3/4/325 Fixes: 2358dd3fd325fc ("dt-bindings: net: micrel: Configure latency values and timestamping check for LAN8814 phy") Signed-off-by: Horatiu Vultur Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/micrel.txt | 17 ----------------- 1 file changed, 17 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt index c5ab62c39133..8d157f0295a5 100644 --- a/Documentation/devicetree/bindings/net/micrel.txt +++ b/Documentation/devicetree/bindings/net/micrel.txt @@ -45,20 +45,3 @@ Optional properties: In fiber mode, auto-negotiation is disabled and the PHY can only work in 100base-fx (full and half duplex) modes. - - - lan8814,ignore-ts: If present the PHY will not support timestamping. - - This option acts as check whether Timestamping is supported by - hardware or not. LAN8814 phy support hardware tmestamping. - - - lan8814,latency_rx_10: Configures Latency value of phy in ingress at 10 Mbps. - - - lan8814,latency_tx_10: Configures Latency value of phy in egress at 10 Mbps. - - - lan8814,latency_rx_100: Configures Latency value of phy in ingress at 100 Mbps. - - - lan8814,latency_tx_100: Configures Latency value of phy in egress at 100 Mbps. - - - lan8814,latency_rx_1000: Configures Latency value of phy in ingress at 1000 Mbps. - - - lan8814,latency_tx_1000: Configures Latency value of phy in egress at 1000 Mbps. -- cgit From 7663f7a26b335a53102a0893824689182ac64e42 Mon Sep 17 00:00:00 2001 From: Tinghan Shen Date: Wed, 16 Feb 2022 19:31:29 +0800 Subject: dt-bindings: arm: mediatek: Add mt8195 pericfg compatible Add mt8195 pericfg compatible to binding document. Signed-off-by: Tinghan Shen Acked-by: Rob Herring Acked-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220216113131.13145-2-tinghan.shen@mediatek.com Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml index 8723dfe34bab..611f666f359d 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml @@ -26,6 +26,7 @@ properties: - mediatek,mt8135-pericfg - mediatek,mt8173-pericfg - mediatek,mt8183-pericfg + - mediatek,mt8195-pericfg - mediatek,mt8516-pericfg - const: syscon - items: -- cgit From 8a1e6bb3f78f06432e095758476358d8cb63c03d Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 30 Mar 2022 09:40:15 +0200 Subject: dt-bindings: update Krzysztof Kozlowski's email Krzysztof Kozlowski's @canonical.com email stopped working, so switch to generic @kernel.org account for all Devicetree bindings. Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Acked-by: Arnd Bergmann Link: https://lore.kernel.org/r/20220330074016.12896-2-krzysztof.kozlowski@linaro.org --- Documentation/devicetree/bindings/clock/samsung,exynos-audss-clock.yaml | 2 +- Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml | 2 +- Documentation/devicetree/bindings/clock/samsung,exynos-ext-clock.yaml | 2 +- .../devicetree/bindings/clock/samsung,exynos4412-isp-clock.yaml | 2 +- Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml | 2 +- Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml | 2 +- Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml | 2 +- Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml | 2 +- Documentation/devicetree/bindings/clock/samsung,exynos7885-clock.yaml | 2 +- Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml | 2 +- Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml | 2 +- .../devicetree/bindings/clock/samsung,s5pv210-audss-clock.yaml | 2 +- Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml | 2 +- .../devicetree/bindings/devfreq/event/samsung,exynos-nocp.yaml | 2 +- .../devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml | 2 +- .../devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml | 2 +- .../devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml | 2 +- .../devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml | 2 +- .../devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml | 2 +- .../devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml | 2 +- .../devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml | 2 +- Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml | 2 +- Documentation/devicetree/bindings/extcon/maxim,max77843.yaml | 2 +- Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml | 2 +- Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml | 2 +- Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml | 2 +- Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml | 2 +- Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml | 2 +- Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 2 +- Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml | 2 +- .../bindings/interrupt-controller/samsung,exynos4210-combiner.yaml | 2 +- Documentation/devicetree/bindings/leds/maxim,max77693.yaml | 2 +- Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml | 2 +- .../bindings/memory-controllers/ddr/jedec,lpddr2-timings.yaml | 2 +- .../devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml | 2 +- .../bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml | 2 +- .../devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml | 2 +- .../bindings/memory-controllers/marvell,mvebu-sdram-controller.yaml | 2 +- .../bindings/memory-controllers/qca,ath79-ddr-controller.yaml | 2 +- .../devicetree/bindings/memory-controllers/renesas,h8300-bsc.yaml | 2 +- .../devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml | 2 +- .../devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml | 2 +- .../devicetree/bindings/memory-controllers/ti,da8xx-ddrctl.yaml | 2 +- Documentation/devicetree/bindings/mfd/maxim,max14577.yaml | 2 +- Documentation/devicetree/bindings/mfd/maxim,max77686.yaml | 2 +- Documentation/devicetree/bindings/mfd/maxim,max77693.yaml | 2 +- Documentation/devicetree/bindings/mfd/maxim,max77802.yaml | 2 +- Documentation/devicetree/bindings/mfd/maxim,max77843.yaml | 2 +- Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml | 2 +- Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml | 2 +- Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml | 2 +- Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml | 2 +- Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml | 2 +- Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml | 2 +- Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml | 2 +- Documentation/devicetree/bindings/net/nfc/nxp,pn544.yaml | 2 +- Documentation/devicetree/bindings/net/nfc/st,st-nci.yaml | 2 +- Documentation/devicetree/bindings/net/nfc/st,st21nfca.yaml | 2 +- Documentation/devicetree/bindings/net/nfc/st,st95hf.yaml | 2 +- Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml | 2 +- Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml | 2 +- Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml | 2 +- Documentation/devicetree/bindings/phy/samsung,exynos5250-sata-phy.yaml | 2 +- Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml | 2 +- Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml | 2 +- Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml | 2 +- .../devicetree/bindings/pinctrl/samsung,pinctrl-gpio-bank.yaml | 2 +- Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml | 2 +- .../devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml | 2 +- Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml | 2 +- Documentation/devicetree/bindings/power/supply/maxim,max14577.yaml | 2 +- Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml | 2 +- Documentation/devicetree/bindings/regulator/maxim,max14577.yaml | 2 +- Documentation/devicetree/bindings/regulator/maxim,max77686.yaml | 2 +- Documentation/devicetree/bindings/regulator/maxim,max77693.yaml | 2 +- Documentation/devicetree/bindings/regulator/maxim,max77802.yaml | 2 +- Documentation/devicetree/bindings/regulator/maxim,max77843.yaml | 2 +- Documentation/devicetree/bindings/regulator/maxim,max8952.yaml | 2 +- Documentation/devicetree/bindings/regulator/maxim,max8973.yaml | 2 +- Documentation/devicetree/bindings/regulator/maxim,max8997.yaml | 2 +- Documentation/devicetree/bindings/regulator/samsung,s2mpa01.yaml | 2 +- Documentation/devicetree/bindings/regulator/samsung,s2mps11.yaml | 2 +- Documentation/devicetree/bindings/regulator/samsung,s2mps13.yaml | 2 +- Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml | 2 +- Documentation/devicetree/bindings/regulator/samsung,s2mps15.yaml | 2 +- Documentation/devicetree/bindings/regulator/samsung,s2mpu02.yaml | 2 +- Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml | 2 +- Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.yaml | 2 +- Documentation/devicetree/bindings/rng/timeriomem_rng.yaml | 2 +- Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml | 2 +- Documentation/devicetree/bindings/sound/samsung,arndale.yaml | 2 +- Documentation/devicetree/bindings/sound/samsung,smdk5250.yaml | 2 +- Documentation/devicetree/bindings/sound/samsung,snow.yaml | 2 +- Documentation/devicetree/bindings/sound/samsung,tm2.yaml | 2 +- Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml | 2 +- Documentation/devicetree/bindings/spi/samsung,spi.yaml | 2 +- Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml | 2 +- Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml | 2 +- Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml | 2 +- 99 files changed, 99 insertions(+), 99 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos-audss-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos-audss-clock.yaml index f14f1d39da36..d819dfaafff9 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos-audss-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos-audss-clock.yaml @@ -8,7 +8,7 @@ title: Samsung Exynos SoC Audio SubSystem clock controller maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml index 4e8062860986..0589a63e273a 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml @@ -8,7 +8,7 @@ title: Samsung Exynos SoC clock controller maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos-ext-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos-ext-clock.yaml index 64d027dbe3b2..c98eff64f2b5 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos-ext-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos-ext-clock.yaml @@ -8,7 +8,7 @@ title: Samsung SoC external/osc/XXTI/XusbXTI clock maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos4412-isp-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos4412-isp-clock.yaml index 1ed64add4355..b644bbd0df38 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos4412-isp-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos4412-isp-clock.yaml @@ -8,7 +8,7 @@ title: Samsung Exynos4412 SoC ISP clock controller maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml index a3fac5c6809d..b05f83533e3d 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml @@ -8,7 +8,7 @@ title: Samsung Exynos5260 SoC clock controller maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml index 032862e9f55b..b737c9d35a1c 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml @@ -8,7 +8,7 @@ title: Samsung Exynos5410 SoC clock controller maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml index edd1b4ac4334..3f9326e09f79 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml @@ -8,7 +8,7 @@ title: Samsung Exynos5433 SoC clock controller maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml index 599baf0b7231..c137c6744ef9 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml @@ -8,7 +8,7 @@ title: Samsung Exynos7 SoC clock controller maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos7885-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos7885-clock.yaml index 7e5a9cac2fd2..5073e569a47f 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos7885-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos7885-clock.yaml @@ -9,7 +9,7 @@ title: Samsung Exynos7885 SoC clock controller maintainers: - Dávid Virág - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml index 80ba60838f2b..aa11815ad3a3 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml @@ -9,7 +9,7 @@ title: Samsung Exynos850 SoC clock controller maintainers: - Sam Protsenko - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml b/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml index 1410c51e0e7d..9248bfc16d48 100644 --- a/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S2M and S5M family clock generator block maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for S2M and S5M family of Power diff --git a/Documentation/devicetree/bindings/clock/samsung,s5pv210-audss-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,s5pv210-audss-clock.yaml index ae8f8fc93233..2659854ea1c0 100644 --- a/Documentation/devicetree/bindings/clock/samsung,s5pv210-audss-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,s5pv210-audss-clock.yaml @@ -8,7 +8,7 @@ title: Samsung S5Pv210 SoC Audio SubSystem clock controller maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml index dcb29a2d1159..67a33665cf00 100644 --- a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml @@ -8,7 +8,7 @@ title: Samsung S5P6442/S5PC110/S5PV210 SoC clock controller maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-nocp.yaml b/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-nocp.yaml index d318fccf78f1..2bdd05af6079 100644 --- a/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-nocp.yaml +++ b/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-nocp.yaml @@ -8,7 +8,7 @@ title: Samsung Exynos NoC (Network on Chip) Probe maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | The Samsung Exynos542x SoC has a NoC (Network on Chip) Probe for NoC bus. diff --git a/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml b/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml index c9a8cb5fd555..e300df4b47f3 100644 --- a/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml +++ b/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml @@ -8,7 +8,7 @@ title: Samsung Exynos SoC PPMU (Platform Performance Monitoring Unit) maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | The Samsung Exynos SoC has PPMU (Platform Performance Monitoring Unit) for diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml index f998a3a5b71f..919734c05c0b 100644 --- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml @@ -11,7 +11,7 @@ maintainers: - Joonyoung Shim - Seung-Woo Kim - Kyungmin Park - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml index cb8e735ce3bd..63379fae3636 100644 --- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml @@ -11,7 +11,7 @@ maintainers: - Joonyoung Shim - Seung-Woo Kim - Kyungmin Park - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml index ba40284ac66f..00e325a19cb1 100644 --- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml @@ -11,7 +11,7 @@ maintainers: - Joonyoung Shim - Seung-Woo Kim - Kyungmin Park - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: Samsung Exynos SoC Mixer is responsible for mixing and blending multiple data diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml index 6f796835ea03..7c37470bd329 100644 --- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml @@ -11,7 +11,7 @@ maintainers: - Joonyoung Shim - Seung-Woo Kim - Kyungmin Park - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | DECON (Display and Enhancement Controller) is the Display Controller for the diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml index 01fccb138ebd..c5c6239c28d0 100644 --- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml @@ -11,7 +11,7 @@ maintainers: - Joonyoung Shim - Seung-Woo Kim - Kyungmin Park - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | MIC (Mobile Image Compressor) resides between DECON and MIPI DSI. MIPI DSI is diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml index afa137d47922..320eedc61a5b 100644 --- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml @@ -11,7 +11,7 @@ maintainers: - Joonyoung Shim - Seung-Woo Kim - Kyungmin Park - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | DECON (Display and Enhancement Controller) is the Display Controller for the diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml index 9cf5f120d516..c62ea9d22843 100644 --- a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml +++ b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml @@ -11,7 +11,7 @@ maintainers: - Joonyoung Shim - Seung-Woo Kim - Kyungmin Park - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml b/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml index f9ffe3d6f957..03d6b8dbbdd3 100644 --- a/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml +++ b/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml @@ -8,7 +8,7 @@ title: Maxim MAX77843 MicroUSB and Companion Power Management IC Extcon maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for Maxim MAX77843 MicroUSB diff --git a/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml b/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml index 4b5851c326f7..b1a4c235376e 100644 --- a/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml +++ b/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: LTC4151 High Voltage I2C Current and Voltage Monitor maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml b/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml index c42051f8a191..028d6e570131 100644 --- a/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml +++ b/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Microchip MCP3021 A/D converter maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml b/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml index 4669217d01e1..80df7182ea28 100644 --- a/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml +++ b/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Sensirion SHT15 humidity and temperature sensor maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml index d3eff4fac107..c5a889e3e27b 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: TMP102 temperature sensor maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml index eda55bbc172d..dcbc6fbc3b48 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: TMP108 temperature sensor maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml index 19874e8b73b9..3e52a0db6c41 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung's High Speed I2C controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | The Samsung's High Speed I2C controller is used to interface with I2C devices diff --git a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml index 84051b0129c2..c26230518957 100644 --- a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S3C/S5P/Exynos SoC I2C Controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.yaml b/Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.yaml index d631b7589d50..72456a07dac9 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung Exynos SoC Interrupt Combiner Controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | Samsung's Exynos4 architecture includes a interrupt combiner controller which diff --git a/Documentation/devicetree/bindings/leds/maxim,max77693.yaml b/Documentation/devicetree/bindings/leds/maxim,max77693.yaml index 86a0005cf156..e27f57bb52ae 100644 --- a/Documentation/devicetree/bindings/leds/maxim,max77693.yaml +++ b/Documentation/devicetree/bindings/leds/maxim,max77693.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim MAX77693 MicroUSB and Companion Power Management IC LEDs maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for Maxim MAX77693 MicroUSB Integrated diff --git a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml index 769f13250047..08cbdcddfead 100644 --- a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: DDR PHY Front End (DPFE) for Broadcom STB maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Markus Mayer properties: diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2-timings.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2-timings.yaml index f3e62ee07126..1daa66592477 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2-timings.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2-timings.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: LPDDR2 SDRAM AC timing parameters for a given speed-bin maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml index dd2141cad866..9d78f140609b 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: LPDDR2 SDRAM compliant to JEDEC JESD209-2 maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml index 97c3e988af5f..5c6512c1e1e3 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: LPDDR3 SDRAM AC timing parameters for a given speed-bin maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml index c542f32c39fa..48908a19473c 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: LPDDR3 SDRAM compliant to JEDEC JESD209-3 maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/memory-controllers/marvell,mvebu-sdram-controller.yaml b/Documentation/devicetree/bindings/memory-controllers/marvell,mvebu-sdram-controller.yaml index 14a6bc8f421f..9249624c4fa0 100644 --- a/Documentation/devicetree/bindings/memory-controllers/marvell,mvebu-sdram-controller.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/marvell,mvebu-sdram-controller.yaml @@ -8,7 +8,7 @@ title: Marvell MVEBU SDRAM controller maintainers: - Jan Luebbe - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml b/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml index 9566b3421f03..0c511ab906bf 100644 --- a/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Atheros AR7xxx/AR9xxx DDR controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | The DDR controller of the AR7xxx and AR9xxx families provides an interface to diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.yaml index 2b18cef99511..514b2c5f8858 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: H8/300 bus controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Yoshinori Sato properties: diff --git a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml index f152243f6b18..098348b2b815 100644 --- a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml @@ -9,7 +9,7 @@ title: | Controller device maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Lukasz Luba description: | diff --git a/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml b/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml index fb7ae38a9c86..06812512e9b2 100644 --- a/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Synopsys IntelliDDR Multi Protocol memory controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Manish Narani - Michal Simek diff --git a/Documentation/devicetree/bindings/memory-controllers/ti,da8xx-ddrctl.yaml b/Documentation/devicetree/bindings/memory-controllers/ti,da8xx-ddrctl.yaml index 9ed51185ff99..382ddab60fbd 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ti,da8xx-ddrctl.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ti,da8xx-ddrctl.yaml @@ -8,7 +8,7 @@ title: Texas Instruments da8xx DDR2/mDDR memory controller maintainers: - Bartosz Golaszewski - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | Documentation: diff --git a/Documentation/devicetree/bindings/mfd/maxim,max14577.yaml b/Documentation/devicetree/bindings/mfd/maxim,max14577.yaml index 27870b8760a6..52edd1bf549f 100644 --- a/Documentation/devicetree/bindings/mfd/maxim,max14577.yaml +++ b/Documentation/devicetree/bindings/mfd/maxim,max14577.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim MAX14577/MAX77836 MicroUSB and Companion Power Management IC maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for Maxim MAX14577/MAX77836 MicroUSB diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml index 859655a789c3..d027aabe453b 100644 --- a/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml +++ b/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml @@ -8,7 +8,7 @@ title: Maxim MAX77686 Power Management IC maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for Maxim MAX77686 Power Management diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml index 906101197e11..1b06a77ec798 100644 --- a/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml +++ b/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml @@ -8,7 +8,7 @@ title: Maxim MAX77693 MicroUSB and Companion Power Management IC maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for Maxim MAX77693 MicroUSB diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77802.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77802.yaml index baa1346ac5d5..ad2013900b03 100644 --- a/Documentation/devicetree/bindings/mfd/maxim,max77802.yaml +++ b/Documentation/devicetree/bindings/mfd/maxim,max77802.yaml @@ -8,7 +8,7 @@ title: Maxim MAX77802 Power Management IC maintainers: - Javier Martinez Canillas - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for Maxim MAX77802 Power Management diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77843.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77843.yaml index 61a0f9dcb983..f30f96bbff43 100644 --- a/Documentation/devicetree/bindings/mfd/maxim,max77843.yaml +++ b/Documentation/devicetree/bindings/mfd/maxim,max77843.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim MAX77843 MicroUSB and Companion Power Management IC maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for Maxim MAX77843 MicroUSB diff --git a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml index bae55c98961c..f7bb67d10eff 100644 --- a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml +++ b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung Exynos SoC Low Power Audio Subsystem (LPASS) maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki properties: diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml index 017befdf8adb..055dfc337c2f 100644 --- a/Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml +++ b/Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S2MPA01 Power Management IC maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for S2M and S5M family of Power diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml index 771b3f16da96..5ff6546c72b7 100644 --- a/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml +++ b/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S2MPS11/13/14/15 and S2MPU02 Power Management IC maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for S2M and S5M family of Power diff --git a/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml b/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml index 5531718abdf0..10c7b408f33a 100644 --- a/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml +++ b/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S5M8767 Power Management IC maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for S2M and S5M family of Power diff --git a/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml b/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml index 15a45db3899a..1bcaf6ba822c 100644 --- a/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml +++ b/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Marvell International Ltd. NCI NFC controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml b/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml index 7465aea2e1c0..e381a3c14836 100644 --- a/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml +++ b/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml @@ -8,7 +8,7 @@ title: NXP Semiconductors NCI NFC controller maintainers: - Charles Gorand - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml b/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml index d8ba5a18db98..0509e0166345 100644 --- a/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml +++ b/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: NXP Semiconductors PN532 NFC controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/net/nfc/nxp,pn544.yaml b/Documentation/devicetree/bindings/net/nfc/nxp,pn544.yaml index d520414de463..18b3a7d819df 100644 --- a/Documentation/devicetree/bindings/net/nfc/nxp,pn544.yaml +++ b/Documentation/devicetree/bindings/net/nfc/nxp,pn544.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: NXP Semiconductors PN544 NFC Controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/net/nfc/st,st-nci.yaml b/Documentation/devicetree/bindings/net/nfc/st,st-nci.yaml index a6a1bc788d29..ef1155038a2f 100644 --- a/Documentation/devicetree/bindings/net/nfc/st,st-nci.yaml +++ b/Documentation/devicetree/bindings/net/nfc/st,st-nci.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics ST NCI NFC controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/net/nfc/st,st21nfca.yaml b/Documentation/devicetree/bindings/net/nfc/st,st21nfca.yaml index 4356eacde8aa..8a7274357b46 100644 --- a/Documentation/devicetree/bindings/net/nfc/st,st21nfca.yaml +++ b/Documentation/devicetree/bindings/net/nfc/st,st21nfca.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics SAS ST21NFCA NFC controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/net/nfc/st,st95hf.yaml b/Documentation/devicetree/bindings/net/nfc/st,st95hf.yaml index d3bca376039e..963d9531a856 100644 --- a/Documentation/devicetree/bindings/net/nfc/st,st95hf.yaml +++ b/Documentation/devicetree/bindings/net/nfc/st,st95hf.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics ST95HF NFC controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml b/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml index 40da2ac98978..404c8df99364 100644 --- a/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml +++ b/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments TRF7970A RFID/NFC/15693 Transceiver maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Mark Greer properties: diff --git a/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml index 838c6d480ce6..b03b2f00cc5b 100644 --- a/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung Exynos SoC DisplayPort PHY maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Marek Szyprowski - Sylwester Nawrocki diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml index c61574e10b2a..3e5f035de2e9 100644 --- a/Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml @@ -11,7 +11,7 @@ maintainers: - Joonyoung Shim - Seung-Woo Kim - Kyungmin Park - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos5250-sata-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos5250-sata-phy.yaml index 62b39bb46585..8751e559484f 100644 --- a/Documentation/devicetree/bindings/phy/samsung,exynos5250-sata-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,exynos5250-sata-phy.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung Exynos5250 SoC SATA PHY maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Marek Szyprowski - Sylwester Nawrocki diff --git a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml index 54aa056b224d..415440aaad89 100644 --- a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S5P/Exynos SoC MIPI CSIS/DSIM DPHY maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Marek Szyprowski - Sylwester Nawrocki diff --git a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml index 056e270a4e88..d9f22a801cbf 100644 --- a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S5P/Exynos SoC USB 2.0 PHY maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Marek Szyprowski - Sylwester Nawrocki diff --git a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml index f83f0f8135b9..5ba55f9f20cc 100644 --- a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung Exynos SoC USB 3.0 DRD PHY USB 2.0 PHY maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Marek Szyprowski - Sylwester Nawrocki diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-gpio-bank.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-gpio-bank.yaml index f73348c54748..8cf3c47ab86b 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-gpio-bank.yaml +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-gpio-bank.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S3C/S5P/Exynos SoC pin controller - gpio bank maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml index c71939ac8b63..9869d4dceddb 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S3C/S5P/Exynos SoC pin controller - pins configuration maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml index a822f70f5702..1de91a51234d 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S3C/S5P/Exynos SoC pin controller - wake-up interrupt controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml index 989e48c051cf..3a65c66ca71d 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S3C/S5P/Exynos SoC pin controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki - Tomasz Figa diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max14577.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max14577.yaml index 3978b48299de..4d3a1d09036f 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max14577.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max14577.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim MAX14577/MAX77836 MicroUSB and Companion Power Management IC Charger maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for Maxim MAX14577/MAX77836 MicroUSB diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml index a21dc1a8890f..f5fd53debbc8 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim MAX77693 MicroUSB and Companion Power Management IC Charger maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for Maxim MAX77693 MicroUSB Integrated diff --git a/Documentation/devicetree/bindings/regulator/maxim,max14577.yaml b/Documentation/devicetree/bindings/regulator/maxim,max14577.yaml index 16f01886a601..285dc7122977 100644 --- a/Documentation/devicetree/bindings/regulator/maxim,max14577.yaml +++ b/Documentation/devicetree/bindings/regulator/maxim,max14577.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim MAX14577/MAX77836 MicroUSB and Companion Power Management IC regulators maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for Maxim MAX14577/MAX77836 MicroUSB diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77686.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77686.yaml index bb64b679f765..0e7cd4b3ace0 100644 --- a/Documentation/devicetree/bindings/regulator/maxim,max77686.yaml +++ b/Documentation/devicetree/bindings/regulator/maxim,max77686.yaml @@ -8,7 +8,7 @@ title: Maxim MAX77686 Power Management IC regulators maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for Maxim MAX77686 Power Management diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77693.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77693.yaml index 20d8559bdc2b..945a539749e8 100644 --- a/Documentation/devicetree/bindings/regulator/maxim,max77693.yaml +++ b/Documentation/devicetree/bindings/regulator/maxim,max77693.yaml @@ -8,7 +8,7 @@ title: Maxim MAX77693 MicroUSB and Companion Power Management IC regulators maintainers: - Chanwoo Choi - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for Maxim MAX77693 MicroUSB Integrated diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml index f2b4dd15a0f3..236348c4710c 100644 --- a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml +++ b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml @@ -8,7 +8,7 @@ title: Maxim MAX77802 Power Management IC regulators maintainers: - Javier Martinez Canillas - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for Maxim MAX77802 Power Management diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77843.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77843.yaml index a963025e96c1..9695e7242882 100644 --- a/Documentation/devicetree/bindings/regulator/maxim,max77843.yaml +++ b/Documentation/devicetree/bindings/regulator/maxim,max77843.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim MAX77843 MicroUSB and Companion Power Management IC regulators maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for Maxim MAX77843 MicroUSB Integrated diff --git a/Documentation/devicetree/bindings/regulator/maxim,max8952.yaml b/Documentation/devicetree/bindings/regulator/maxim,max8952.yaml index e4e8c58f6046..3ff0d7d980e9 100644 --- a/Documentation/devicetree/bindings/regulator/maxim,max8952.yaml +++ b/Documentation/devicetree/bindings/regulator/maxim,max8952.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim MAX8952 voltage regulator maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski allOf: - $ref: regulator.yaml# diff --git a/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml b/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml index 5898dcf10f06..b92eef68c19f 100644 --- a/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml +++ b/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim MAX8973/MAX77621 voltage regulator maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski allOf: - $ref: regulator.yaml# diff --git a/Documentation/devicetree/bindings/regulator/maxim,max8997.yaml b/Documentation/devicetree/bindings/regulator/maxim,max8997.yaml index d5a44ca3df04..4321f061a7f6 100644 --- a/Documentation/devicetree/bindings/regulator/maxim,max8997.yaml +++ b/Documentation/devicetree/bindings/regulator/maxim,max8997.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim MAX8997 Power Management IC maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | The Maxim MAX8997 is a Power Management IC which includes voltage and current diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.yaml index 0627dec513da..0f9eb317ba9a 100644 --- a/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.yaml +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S2MPA01 Power Management IC regulators maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for S2M and S5M family of Power diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps11.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mps11.yaml index e3b780715f44..f1c50dcd0b04 100644 --- a/Documentation/devicetree/bindings/regulator/samsung,s2mps11.yaml +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mps11.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S2MPS11 Power Management IC regulators maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for S2M and S5M family of Power diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps13.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mps13.yaml index 579d77aefc3f..53b105a4ead1 100644 --- a/Documentation/devicetree/bindings/regulator/samsung,s2mps13.yaml +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mps13.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S2MPS13 Power Management IC regulators maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for S2M and S5M family of Power diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml index fdea290b3e94..01f9d4e236e9 100644 --- a/Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S2MPS14 Power Management IC regulators maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for S2M and S5M family of Power diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps15.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mps15.yaml index b3a883c94628..9576c2df45a6 100644 --- a/Documentation/devicetree/bindings/regulator/samsung,s2mps15.yaml +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mps15.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S2MPS15 Power Management IC regulators maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for S2M and S5M family of Power diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mpu02.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mpu02.yaml index 0ded6953e3b6..39b652c3c3c4 100644 --- a/Documentation/devicetree/bindings/regulator/samsung,s2mpu02.yaml +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mpu02.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S2MPU02 Power Management IC regulators maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for S2M and S5M family of Power diff --git a/Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml b/Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml index 3c1617b66861..172631ca3c25 100644 --- a/Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml +++ b/Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S5M8767 Power Management IC regulators maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | This is a part of device tree bindings for S2M and S5M family of Power diff --git a/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.yaml b/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.yaml index a50c34d5d199..765d9f9edd6e 100644 --- a/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.yaml +++ b/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung Exynos SoC True Random Number Generator maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Łukasz Stelmach properties: diff --git a/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml b/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml index 84bf518a5549..4754174e9849 100644 --- a/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml +++ b/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: TimerIO Random Number Generator maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml index a98ed66d092e..0cabb773c397 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml @@ -8,7 +8,7 @@ title: Samsung's Exynos USI (Universal Serial Interface) binding maintainers: - Sam Protsenko - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | USI IP-core provides selectable serial protocol (UART, SPI or High-Speed I2C). diff --git a/Documentation/devicetree/bindings/sound/samsung,arndale.yaml b/Documentation/devicetree/bindings/sound/samsung,arndale.yaml index cea2bf3544f0..9bc4585bb6e5 100644 --- a/Documentation/devicetree/bindings/sound/samsung,arndale.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,arndale.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Insignal Arndale boards audio complex maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki properties: diff --git a/Documentation/devicetree/bindings/sound/samsung,smdk5250.yaml b/Documentation/devicetree/bindings/sound/samsung,smdk5250.yaml index cb51af90435e..ac151d3c1d77 100644 --- a/Documentation/devicetree/bindings/sound/samsung,smdk5250.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,smdk5250.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung SMDK5250 audio complex with WM8994 codec maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki properties: diff --git a/Documentation/devicetree/bindings/sound/samsung,snow.yaml b/Documentation/devicetree/bindings/sound/samsung,snow.yaml index 0c3b3302b842..51a83d3c7274 100644 --- a/Documentation/devicetree/bindings/sound/samsung,snow.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,snow.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Google Snow audio complex with MAX9809x codec maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki properties: diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml index 74712d6f3ef4..491e08019c04 100644 --- a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung Exynos5433 TM2(E) audio complex with WM5110 codec maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski - Sylwester Nawrocki properties: diff --git a/Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml index f0db3fb3d688..25b1b6c12d4d 100644 --- a/Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml +++ b/Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Peripheral-specific properties for Samsung S3C/S5P/Exynos SoC SPI controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: See spi-peripheral-props.yaml for more info. diff --git a/Documentation/devicetree/bindings/spi/samsung,spi.yaml b/Documentation/devicetree/bindings/spi/samsung,spi.yaml index bf9a76d931d2..a50f24f9359d 100644 --- a/Documentation/devicetree/bindings/spi/samsung,spi.yaml +++ b/Documentation/devicetree/bindings/spi/samsung,spi.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung S3C/S5P/Exynos SoC SPI controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: All the SPI controller nodes should be represented in the aliases node using diff --git a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml index 17129f75d962..1344df708e2d 100644 --- a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung Exynos SoC Thermal Management Unit (TMU) maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski description: | For multi-instance tmu each instance should have an alias correctly numbered diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml index 22b91a27d776..6b9a3bcb3926 100644 --- a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung Exynos SoC USB 3.0 DWC3 Controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml index fbf07d6e707a..340dff8d19c3 100644 --- a/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml +++ b/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung Exynos SoC USB 2.0 EHCI/OHCI Controller maintainers: - - Krzysztof Kozlowski + - Krzysztof Kozlowski properties: compatible: -- cgit From c5547574797b254ba9c98c7da417bc5de71cd198 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Thu, 24 Mar 2022 17:47:34 +0100 Subject: Documentation/ABI: sysfs-driver-intel_sdsi: Fix sphinx warnings Fix the following warnings from "make htmldocs": Documentation/ABI/testing/sysfs-driver-intel_sdsi:2: WARNING: Unexpected indentation. WARNING: Block quote ends without a blank line; unexpected unindent. WARNING: Definition list ends without a blank line; unexpected unindent. By turning the error-code table into a proper ReST table. While at it also fix the error-code table mixing tab and spaces for indentation (switch to all tabs). Reported-by: Stephen Rothwell Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20220324164737.21765-2-hdegoede@redhat.com --- Documentation/ABI/testing/sysfs-driver-intel_sdsi | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-intel_sdsi b/Documentation/ABI/testing/sysfs-driver-intel_sdsi index ab122125ff9a..96b92c105ec4 100644 --- a/Documentation/ABI/testing/sysfs-driver-intel_sdsi +++ b/Documentation/ABI/testing/sysfs-driver-intel_sdsi @@ -13,17 +13,19 @@ Description: Should the operation fail, one of the following error codes may be returned: + ========== ===== Error Code Cause - ---------- ----- - EIO General mailbox failure. Log may indicate cause. - EBUSY Mailbox is owned by another agent. - EPERM SDSI capability is not enabled in hardware. - EPROTO Failure in mailbox protocol detected by driver. + ========== ===== + EIO General mailbox failure. Log may indicate cause. + EBUSY Mailbox is owned by another agent. + EPERM SDSI capability is not enabled in hardware. + EPROTO Failure in mailbox protocol detected by driver. See log for details. - EOVERFLOW For provision commands, the size of the data + EOVERFLOW For provision commands, the size of the data exceeds what may be written. - ESPIPE Seeking is not allowed. - ETIMEDOUT Failure to complete mailbox transaction in time. + ESPIPE Seeking is not allowed. + ETIMEDOUT Failure to complete mailbox transaction in time. + ========== ===== What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/guid Date: Feb 2022 -- cgit From 45440a1d79eed68bcb8db236a6967a1d5c37a8ce Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Thu, 24 Mar 2022 17:47:35 +0100 Subject: Documentation/ABI: sysfs-class-firmware-attributes: Fix Sphinx errors Fix the following warnings from "make htmldocs": Documentation/ABI/testing/sysfs-class-firmware-attributes:130: ERROR: Unexpected indentation. ERROR: Unexpected indentation. ERROR: Unexpected indentation. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20220324164737.21765-3-hdegoede@redhat.com --- .../ABI/testing/sysfs-class-firmware-attributes | 42 ++++++++++++---------- 1 file changed, 23 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes index 05820365f1ec..5356ff2ed6c8 100644 --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes @@ -246,9 +246,7 @@ Description: that is being referenced (e.g hdd0, hdd1 etc) This attribute defaults to device 0. - certificate: - signature: - save_signature: + certificate, signature, save_signature: These attributes are used for certificate based authentication. This is used in conjunction with a signing server as an alternative to password based authentication. @@ -257,22 +255,27 @@ Description: The attributes can be displayed to check the stored value. Some usage examples: - Installing a certificate to enable feature: - echo authentication/Admin/current_password - echo > authentication/Admin/certificate - Updating the installed certificate: - echo > authentication/Admin/signature - echo > authentication/Admin/certificate + Installing a certificate to enable feature:: - Removing the installed certificate: - echo > authentication/Admin/signature - echo '' > authentication/Admin/certificate + echo "supervisor password" > authentication/Admin/current_password + echo "signed certificate" > authentication/Admin/certificate - Changing a BIOS setting: - echo > authentication/Admin/signature - echo > authentication/Admin/save_signature - echo Enable > attribute/PasswordBeep/current_value + Updating the installed certificate:: + + echo "signature" > authentication/Admin/signature + echo "signed certificate" > authentication/Admin/certificate + + Removing the installed certificate:: + + echo "signature" > authentication/Admin/signature + echo "" > authentication/Admin/certificate + + Changing a BIOS setting:: + + echo "signature" > authentication/Admin/signature + echo "save signature" > authentication/Admin/save_signature + echo Enable > attribute/PasswordBeep/current_value You cannot enable certificate authentication if a supervisor password has not been set. @@ -288,9 +291,10 @@ Description: certificate_to_password: Write only attribute used to switch from certificate based authentication back to password based. - Usage: - echo > authentication/Admin/signature - echo > authentication/Admin/certificate_to_password + Usage:: + + echo "signature" > authentication/Admin/signature + echo "password" > authentication/Admin/certificate_to_password What: /sys/class/firmware-attributes/*/attributes/pending_reboot -- cgit From 9aa6471419dc904c4f182295dbe00edfe4c92a29 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Thu, 24 Mar 2022 17:47:36 +0100 Subject: Documentation/ABI: sysfs-class-firmware-attributes: Misc. cleanups Cleanup / fix some minor issues. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20220324164737.21765-4-hdegoede@redhat.com --- Documentation/ABI/testing/sysfs-class-firmware-attributes | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes index 5356ff2ed6c8..4cdba3477176 100644 --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes @@ -116,7 +116,7 @@ Description: [ForceIf:=] [ForceIfNot:=] - For example: + For example:: LegacyOrom/dell_value_modifier has value: Disabled[ForceIf:SecureBoot=Enabled] @@ -212,7 +212,7 @@ Description: the next boot. Lenovo specific class extensions - ------------------------------ + -------------------------------- On Lenovo systems the following additional settings are available: @@ -349,7 +349,7 @@ Description: # echo "factory" > /sys/class/firmware-attributes/*/device/attributes/reset_bios # cat /sys/class/firmware-attributes/*/device/attributes/reset_bios - # builtinsafe lastknowngood [factory] custom + builtinsafe lastknowngood [factory] custom Note that any changes to this attribute requires a reboot for changes to take effect. -- cgit From f704882033a70cbc27f6944e831e325eb3214c73 Mon Sep 17 00:00:00 2001 From: Johnson Wang Date: Fri, 1 Apr 2022 16:02:12 +0800 Subject: regulator: Add BUCK and LDO document for MT6358 and MT6366 Add buck_vcore_sshub and ldo_vsram_others_sshub regulators to binding document for MT6358 and MT6366. Reviewed-by: Rob Herring Signed-off-by: Johnson Wang Link: https://lore.kernel.org/r/20220401080212.27383-3-johnson.wang@mediatek.com Signed-off-by: Mark Brown --- .../bindings/regulator/mt6358-regulator.txt | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt index 9a90a92f2d7e..7034cdca54e0 100644 --- a/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt @@ -8,14 +8,14 @@ Documentation/devicetree/bindings/regulator/regulator.txt. The valid names for regulators are:: BUCK: - buck_vdram1, buck_vcore, buck_vpa, buck_vproc11, buck_vproc12, buck_vgpu, - buck_vs2, buck_vmodem, buck_vs1 + buck_vdram1, buck_vcore, buck_vcore_sshub, buck_vpa, buck_vproc11, + buck_vproc12, buck_vgpu, buck_vs2, buck_vmodem, buck_vs1 LDO: ldo_vdram2, ldo_vsim1, ldo_vibr, ldo_vrf12, ldo_vio18, ldo_vusb, ldo_vcamio, ldo_vcamd, ldo_vcn18, ldo_vfe28, ldo_vsram_proc11, ldo_vcn28, ldo_vsram_others, - ldo_vsram_gpu, ldo_vxo22, ldo_vefuse, ldo_vaux18, ldo_vmch, ldo_vbif28, - ldo_vsram_proc12, ldo_vcama1, ldo_vemc, ldo_vio28, ldo_va12, ldo_vrf18, - ldo_vcn33_bt, ldo_vcn33_wifi, ldo_vcama2, ldo_vmc, ldo_vldo28, ldo_vaud28, + ldo_vsram_others_sshub, ldo_vsram_gpu, ldo_vxo22, ldo_vefuse, ldo_vaux18, + ldo_vmch, ldo_vbif28, ldo_vsram_proc12, ldo_vcama1, ldo_vemc, ldo_vio28, ldo_va12, + ldo_vrf18, ldo_vcn33_bt, ldo_vcn33_wifi, ldo_vcama2, ldo_vmc, ldo_vldo28, ldo_vaud28, ldo_vsim2 Example: @@ -354,5 +354,17 @@ Example: regulator-max-microvolt = <3100000>; regulator-enable-ramp-delay = <540>; }; + + mt6358_vcore_sshub_reg: buck_vcore_sshub { + regulator-name = "vcore_sshub"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + }; + + mt6358_vsram_others_sshub_reg: ldo_vsram_others_sshub { + regulator-name = "vsram_others_sshub"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + }; }; }; -- cgit From 4f9f45d0eb0e7d449bc9294459df79b9c66edfac Mon Sep 17 00:00:00 2001 From: Sherry Sun Date: Mon, 21 Mar 2022 15:51:30 +0800 Subject: dt-bindings: memory: snps,ddrc-3.80a compatible also need interrupts For the snps,ddrc-3.80a compatible, the interrupts property is also required, also order the compatibles by name (s goes before x). Signed-off-by: Sherry Sun Fixes: a9e6b3819b36 ("dt-bindings: memory: Add entry for version 3.80a") Link: https://lore.kernel.org/r/20220321075131.17811-2-sherry.sun@nxp.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml b/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml index fb7ae38a9c86..e3bc6ebce090 100644 --- a/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml @@ -24,9 +24,9 @@ description: | properties: compatible: enum: + - snps,ddrc-3.80a - xlnx,zynq-ddrc-a05 - xlnx,zynqmp-ddrc-2.40a - - snps,ddrc-3.80a interrupts: maxItems: 1 @@ -43,7 +43,9 @@ allOf: properties: compatible: contains: - const: xlnx,zynqmp-ddrc-2.40a + enum: + - snps,ddrc-3.80a + - xlnx,zynqmp-ddrc-2.40a then: required: - interrupts -- cgit From 02c7efa43627163e489a8db87882445a0ff381f7 Mon Sep 17 00:00:00 2001 From: Daniel Latypov Date: Mon, 31 Jan 2022 13:23:41 -0800 Subject: Documentation: kunit: fix path to .kunitconfig in start.rst Commit ddbd60c779b4 ("kunit: use --build_dir=.kunit as default") changed the default --build_dir, which had the side effect of making `.kunitconfig` move to `.kunit/.kunitconfig`. However, the first few lines of kunit/start.rst never got updated, oops. Fix this by telling people to run kunit.py first, which will automatically generate the .kunit directory and .kunitconfig file, and then edit the file manually as desired. Reported-by: Yifan Yuan Signed-off-by: Daniel Latypov Reviewed-by: David Gow Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/start.rst | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst index ad168d16968f..867a4bba6bf6 100644 --- a/Documentation/dev-tools/kunit/start.rst +++ b/Documentation/dev-tools/kunit/start.rst @@ -41,13 +41,18 @@ or ``VFAT_FS``. To run ``FAT_KUNIT_TEST``, the ``.kunitconfig`` has: CONFIG_MSDOS_FS=y CONFIG_FAT_KUNIT_TEST=y -1. A good starting point for the ``.kunitconfig``, is the KUnit default - config. Run the command: +1. A good starting point for the ``.kunitconfig`` is the KUnit default config. + You can generate it by running: .. code-block:: bash cd $PATH_TO_LINUX_REPO - cp tools/testing/kunit/configs/default.config .kunitconfig + tools/testing/kunit/kunit.py config + cat .kunit/.kunitconfig + +.. note :: + ``.kunitconfig`` lives in the ``--build_dir`` used by kunit.py, which is + ``.kunit`` by default. .. note :: You may want to remove CONFIG_KUNIT_ALL_TESTS from the ``.kunitconfig`` as -- cgit From e403fff3b848107e2da92b9a567a926aa5943f7d Mon Sep 17 00:00:00 2001 From: Arınç ÜNAL Date: Sat, 2 Apr 2022 23:46:19 +0300 Subject: dt-bindings: arm: bcm: fix BCM53012 and BCM53016 SoC strings MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fix inaccurate SoC strings brcm,brcm53012 and brcm,brcm53016 to respectively brcm,bcm53012 and brcm,bcm53016. Fixes: 4cb5201fcb5d ("dt-bindings: arm: bcm: Convert BCM4708 to YAML") Fixes: a2e385f5374d ("dt-bindings: ARM: add bindings for the Meraki MR32") Signed-off-by: Arınç ÜNAL Reviewed-by: Krzysztof Kozlowski Signed-off-by: Florian Fainelli --- Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml index 434d3c6db61e..f0e2a20d22d5 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml @@ -84,8 +84,8 @@ properties: - brcm,bcm953012hr - brcm,bcm953012k - meraki,mr32 - - const: brcm,brcm53012 - - const: brcm,brcm53016 + - const: brcm,bcm53012 + - const: brcm,bcm53016 - const: brcm,bcm4708 additionalProperties: true -- cgit From ca41a8b302601b2547ea8aac4306efd8356d85a6 Mon Sep 17 00:00:00 2001 From: Arınç ÜNAL Date: Sat, 2 Apr 2022 23:46:20 +0300 Subject: dt-bindings: arm: bcm: create new description for BCM53016 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Create a new description for BCM53016 and move Meraki MR32 under it. Signed-off-by: Arınç ÜNAL Signed-off-by: Florian Fainelli --- Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml index f0e2a20d22d5..8a97ee048053 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml @@ -83,8 +83,13 @@ properties: - brcm,bcm953012er - brcm,bcm953012hr - brcm,bcm953012k - - meraki,mr32 - const: brcm,bcm53012 + - const: brcm,bcm4708 + + - description: BCM53016 based boards + items: + - enum: + - meraki,mr32 - const: brcm,bcm53016 - const: brcm,bcm4708 -- cgit From 0346e33d558c3372a5f8138ad8086f9414177a06 Mon Sep 17 00:00:00 2001 From: Arınç ÜNAL Date: Sat, 2 Apr 2022 23:46:22 +0300 Subject: dt-bindings: arm: bcm: add bindings for Asus RT-AC88U MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add Asus RT-AC88U under BCM47094 based boards. Signed-off-by: Arınç ÜNAL Reviewed-by: Krzysztof Kozlowski Signed-off-by: Florian Fainelli --- Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml index 8a97ee048053..8b7e87fb6c34 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml @@ -64,6 +64,7 @@ properties: - description: BCM47094 based boards items: - enum: + - asus,rt-ac88u - dlink,dir-885l - linksys,panamera - luxul,abr-4500-v1 -- cgit From 3bbbb3e5b59f4ca0f7493307a03f99930737bb76 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 10 Mar 2022 08:32:58 +0100 Subject: dt-bindings: extcon: maxim,max77843: fix ports type The "ports" property can contain multiple ports as name suggests, so it should be using "ports" type from device graphs. Reported-by: Rob Herring Fixes: 9729cad0278b ("dt-bindings: extcon: maxim,max77843: Add MAX77843 bindings") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220310073258.24060-1-krzysztof.kozlowski@canonical.com --- Documentation/devicetree/bindings/extcon/maxim,max77843.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml b/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml index f9ffe3d6f957..0216ec868c3e 100644 --- a/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml +++ b/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml @@ -25,7 +25,7 @@ properties: $ref: /schemas/connector/usb-connector.yaml# ports: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/properties/ports description: Any connector to the data bus of this controller should be modelled using the OF graph bindings specified -- cgit From e7ccd8a49a050428bd842822970b70c66fd0b988 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 30 Mar 2022 15:04:16 +0200 Subject: dt-bindings: power: renesas,apmu: Fix cpus property limits "make dtbs_check": arch/arm/boot/dts/r8a7791-koelsch.dtb: apmu@e6152000: cpus:0: [6, 7] is too long From schema: Documentation/devicetree/bindings/power/renesas,apmu.yaml Correct the minimum and maximum number of CPUs controlled by a single APMU instance. Fixes: 39bd2b6a3783b899 ("dt-bindings: Improve phandle-array schemas") Signed-off-by: Geert Uytterhoeven Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/9ece1a07bbcb95abc9d80e6a6ecc95806a294a11.1648645279.git.geert+renesas@glider.be --- Documentation/devicetree/bindings/power/renesas,apmu.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/renesas,apmu.yaml b/Documentation/devicetree/bindings/power/renesas,apmu.yaml index 4d293b2b2f84..d77fc88050c8 100644 --- a/Documentation/devicetree/bindings/power/renesas,apmu.yaml +++ b/Documentation/devicetree/bindings/power/renesas,apmu.yaml @@ -36,7 +36,8 @@ properties: cpus: $ref: /schemas/types.yaml#/definitions/phandle-array items: - maxItems: 1 + minItems: 1 + maxItems: 4 description: | Array of phandles pointing to CPU cores, which should match the order of CPU cores used by the WUPCR and PSTR registers in the Advanced Power -- cgit From 27e4a85cf79b74650b0c60541fc989af7954ba62 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 30 Mar 2022 09:57:41 -0500 Subject: dt-bindings: Fix incomplete if/then/else schemas A recent review highlighted that the json-schema meta-schema allows any combination of if/then/else schema keywords even though if, then or else by themselves makes little sense. With an added meta-schema to only allow valid combinations, there's a handful of schemas found which need fixing in a variety of ways. Incorrect indentation is the most common issue. Cc: Lars-Peter Clausen Cc: Michael Hennerich Cc: Jonathan Cameron Cc: Krzysztof Kozlowski Cc: Olivier Moysan Cc: Arnaud Pouliquen Cc: Bjorn Andersson Cc: Georgi Djakov Cc: Ulf Hansson Cc: Thierry Reding Cc: Jonathan Hunter Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Kishon Vijay Abraham I Cc: Vinod Koul Cc: Mark Brown Cc: Fabrice Gasnier Cc: Grygorii Strashko Cc: Dmitry Osipenko Cc: linux-iio@vger.kernel.org Cc: alsa-devel@alsa-project.org Cc: linux-mmc@vger.kernel.org Cc: linux-tegra@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-phy@lists.infradead.org Signed-off-by: Rob Herring Acked-by: Jakub Kicinski Reviewed-by: Krzysztof Kozlowski Acked-by: Mark Brown Link: https://lore.kernel.org/r/20220330145741.3044896-1-robh@kernel.org --- .../devicetree/bindings/iio/adc/adi,ad7476.yaml | 1 + .../bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 8 +-- .../devicetree/bindings/iio/dac/adi,ad5360.yaml | 6 +- .../devicetree/bindings/interconnect/qcom,rpm.yaml | 84 +++++++++++----------- .../bindings/mmc/nvidia,tegra20-sdhci.yaml | 2 + .../devicetree/bindings/net/ti,davinci-mdio.yaml | 1 + .../bindings/phy/nvidia,tegra20-usb-phy.yaml | 20 +++--- .../devicetree/bindings/phy/qcom,usb-hs-phy.yaml | 32 +++++---- .../bindings/regulator/fixed-regulator.yaml | 34 ++++----- .../devicetree/bindings/sound/st,stm32-sai.yaml | 6 +- Documentation/devicetree/bindings/sram/sram.yaml | 16 ++--- 11 files changed, 107 insertions(+), 103 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml index cf711082ad7d..666414a9c0de 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml @@ -98,6 +98,7 @@ allOf: - ti,adc121s - ti,ads7866 - ti,ads7868 + then: required: - vcc-supply # Devices with a vref diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml index 7c260f209687..912372706280 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml @@ -174,7 +174,7 @@ patternProperties: contains: const: st,stm32-dfsdm-adc - - then: + then: properties: st,adc-channels: minItems: 1 @@ -206,7 +206,7 @@ patternProperties: contains: const: st,stm32-dfsdm-dmic - - then: + then: properties: st,adc-channels: maxItems: 1 @@ -254,7 +254,7 @@ allOf: contains: const: st,stm32h7-dfsdm - - then: + then: patternProperties: "^filter@[0-9]+$": properties: @@ -269,7 +269,7 @@ allOf: contains: const: st,stm32mp1-dfsdm - - then: + then: patternProperties: "^filter@[0-9]+$": properties: diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml index 0d8fb56f4b09..65f86f26947c 100644 --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml @@ -59,9 +59,9 @@ allOf: contains: enum: - adi,ad5371 - then: - required: - - vref2-supply + then: + required: + - vref2-supply examples: - | diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml index 89853b482513..8a676fef8c1d 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml @@ -93,48 +93,48 @@ allOf: - 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 - - # Child node's properties - patternProperties: - '^interconnect-[a-z0-9]+$': - type: object - description: - snoc-mm is a child of snoc, sharing snoc's register address space. - - properties: - compatible: - enum: - - qcom,msm8939-snoc-mm - - '#interconnect-cells': - const: 1 - - clock-names: - items: - - const: bus - - const: bus_a - - clocks: - items: - - description: Bus Clock - - description: Bus A Clock - - required: - - compatible - - '#interconnect-cells' - - clock-names - - clocks + then: + properties: + 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]+$': + type: object + description: + snoc-mm is a child of snoc, sharing snoc's register address space. + + properties: + compatible: + enum: + - qcom,msm8939-snoc-mm + + '#interconnect-cells': + const: 1 + + clock-names: + items: + - const: bus + - const: bus_a + + clocks: + items: + - description: Bus Clock + - description: Bus A Clock + + required: + - compatible + - '#interconnect-cells' + - clock-names + - clocks - if: properties: diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml index ce64b3498378..f3f4d5b02744 100644 --- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml @@ -197,6 +197,8 @@ allOf: - nvidia,tegra30-sdhci - nvidia,tegra114-sdhci - nvidia,tegra124-sdhci + then: + properties: clocks: items: - description: module clock diff --git a/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml b/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml index dbfca5ee9139..6f44f9516c36 100644 --- a/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml +++ b/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml @@ -56,6 +56,7 @@ if: compatible: contains: const: ti,davinci_mdio +then: required: - bus_freq diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.yaml index dfde0eaf66e1..d61585c96e31 100644 --- a/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.yaml @@ -275,17 +275,17 @@ allOf: - nvidia,hssquelch-level - nvidia,hsdiscon-level - else: - properties: - clocks: - maxItems: 4 + else: + properties: + clocks: + maxItems: 4 - clock-names: - items: - - const: reg - - const: pll_u - - const: timer - - const: utmi-pads + clock-names: + items: + - const: reg + - const: pll_u + - const: timer + - const: utmi-pads - if: properties: diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml index e23e5590eaa3..0655e485b260 100644 --- a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml @@ -14,24 +14,24 @@ if: compatible: contains: const: qcom,usb-hs-phy-apq8064 - then: - properties: - resets: - maxItems: 1 +then: + properties: + resets: + maxItems: 1 - reset-names: - const: por + reset-names: + const: por - else: - properties: - resets: - minItems: 2 - maxItems: 2 +else: + properties: + resets: + minItems: 2 + maxItems: 2 - reset-names: - items: - - const: phy - - const: por + reset-names: + items: + - const: phy + - const: por properties: compatible: @@ -92,6 +92,8 @@ additionalProperties: false examples: - | otg: usb-controller { + #reset-cells = <1>; + ulpi { phy { compatible = "qcom,usb-hs-phy-msm8974", "qcom,usb-hs-phy"; diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml index 9b131c6facbc..84eeaef179a5 100644 --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml @@ -18,23 +18,23 @@ description: allOf: - $ref: "regulator.yaml#" - -if: - properties: - compatible: - contains: - const: regulator-fixed-clock - required: - - clocks -else: - if: - properties: - compatible: - contains: - const: regulator-fixed-domain - required: - - power-domains - - required-opps + - if: + properties: + compatible: + contains: + const: regulator-fixed-clock + then: + required: + - clocks + - if: + properties: + compatible: + contains: + const: regulator-fixed-domain + then: + required: + - power-domains + - required-opps properties: compatible: diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml index b3dbcba33e41..fe2e15504ebc 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -136,8 +136,7 @@ allOf: compatible: contains: const: st,stm32f4-sai - - - then: + then: properties: clocks: items: @@ -148,8 +147,7 @@ allOf: items: - const: x8k - const: x11k - - - else: + else: properties: clocks: items: diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml index 668a9a41a775..993430be355b 100644 --- a/Documentation/devicetree/bindings/sram/sram.yaml +++ b/Documentation/devicetree/bindings/sram/sram.yaml @@ -136,14 +136,14 @@ required: - reg if: - properties: - compatible: - contains: - enum: - - qcom,rpm-msg-ram - - rockchip,rk3288-pmu-sram - -else: + not: + properties: + compatible: + contains: + enum: + - qcom,rpm-msg-ram + - rockchip,rk3288-pmu-sram +then: required: - "#address-cells" - "#size-cells" -- cgit From 866f404f1b7431ce956bf2f16264ef3ca51cb0dc Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 17 Mar 2022 15:29:52 +0100 Subject: dt-bindings: irqchip: mrvl,intc: refresh maintainers Jason's email bounces and his address was dropped from maintainers in commit 509920aee72a ("MAINTAINERS: Move Jason Cooper to CREDITS"), so drop him here too. Switch other maintainers from IRQCHIP subsystem maintainers to Marvell Orion platform maintainers because its a bigger chance they know the hardware. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Andrew Lunn Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220317142952.479413-1-krzysztof.kozlowski@canonical.com --- .../devicetree/bindings/interrupt-controller/mrvl,intc.yaml | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml index 372ccbfae771..5a583bf3dbc1 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml @@ -7,10 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Marvell MMP/Orion Interrupt controller bindings maintainers: - - Thomas Gleixner - - Jason Cooper - - Marc Zyngier - - Rob Herring + - Andrew Lunn + - Gregory Clement allOf: - if: -- cgit From c3b0068194269193286209d7a70ad1e93a13247f Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 1 Apr 2022 09:12:47 -0500 Subject: dt-bindings: Fix 'enum' lists with duplicate entries There's no reason to list the same value twice in an 'enum'. Fix all the occurrences in the tree. A meta-schema change will catch future ones. Cc: Krzysztof Kozlowski Cc: Thierry Reding Cc: Jonathan Hunter Cc: Mauro Carvalho Chehab Cc: Charles Keepax Cc: Linus Walleij Cc: Sebastian Reichel Cc: Tony Lindgren Cc: Yunfei Dong Cc: - Cc: linux-media@vger.kernel.org Cc: alsa-devel@alsa-project.org Cc: linux-gpio@vger.kernel.org Cc: linux-pm@vger.kernel.org Signed-off-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Acked-by: Sebastian Reichel Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20220401141247.2993925-1-robh@kernel.org --- .../devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml | 1 - Documentation/devicetree/bindings/bus/ti-sysc.yaml | 1 - .../devicetree/bindings/media/mediatek,vcodec-encoder.yaml | 1 - Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml | 11 +++++------ Documentation/devicetree/bindings/power/supply/bq2415x.yaml | 1 - 5 files changed, 5 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml index 0afec83cc723..564ae6aaccf7 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml @@ -13,7 +13,6 @@ maintainers: properties: compatible: enum: - - nvidia,tegra20-pmc - nvidia,tegra20-pmc - nvidia,tegra30-pmc - nvidia,tegra114-pmc diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.yaml b/Documentation/devicetree/bindings/bus/ti-sysc.yaml index bd40213302da..fced4082b047 100644 --- a/Documentation/devicetree/bindings/bus/ti-sysc.yaml +++ b/Documentation/devicetree/bindings/bus/ti-sysc.yaml @@ -34,7 +34,6 @@ properties: oneOf: - items: - enum: - - ti,sysc-omap2 - ti,sysc-omap2 - ti,sysc-omap4 - ti,sysc-omap4-simple diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml index e7b65a91c92c..df7df06c378f 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml @@ -106,7 +106,6 @@ allOf: enum: - mediatek,mt8173-vcodec-enc - mediatek,mt8192-vcodec-enc - - mediatek,mt8173-vcodec-enc then: properties: diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml index 8a90d8273767..6bd42e43cdab 100644 --- a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml +++ b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml @@ -48,13 +48,12 @@ properties: Name of one pin group to configure. enum: [ aif1, aif2, aif3, aif4, mif1, mif2, mif3, pdmspk1, pdmspk2, dmic4, dmic5, dmic6, gpio1, gpio2, gpio3, - gpio4, gpio5, gpio6, gpio7, gpio7, gpio8, gpio9, + gpio4, gpio5, gpio6, gpio7, gpio8, gpio9, gpio10, gpio11, gpio12, gpio13, gpio14, gpio15, - gpio16, gpio17, gpio17, gpio18, gpio19, gpio20, - gpio21, gpio22, gpio23, gpio24, gpio25, gpio26, - gpio27, gpio27, gpio28, gpio29, gpio30, gpio31, - gpio32, gpio33, gpio34, gpio35, gpio36, gpio37, - gpio37, gpio38, gpio39 ] + gpio16, gpio17, gpio18, gpio19, gpio20, gpio21, + gpio22, gpio23, gpio24, gpio25, gpio26, gpio27, + gpio28, gpio29, gpio30, gpio31, gpio32, gpio33, + gpio34, gpio35, gpio36, gpio37, gpio38, gpio39 ] function: description: diff --git a/Documentation/devicetree/bindings/power/supply/bq2415x.yaml b/Documentation/devicetree/bindings/power/supply/bq2415x.yaml index f8461f06e6f4..118cf484cc69 100644 --- a/Documentation/devicetree/bindings/power/supply/bq2415x.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq2415x.yaml @@ -16,7 +16,6 @@ allOf: properties: compatible: enum: - - ti,bq24150 - ti,bq24150 - ti,bq24150a - ti,bq24151 -- cgit From 1034eb1a6ab812b5c20063a0002de0b3b7f1d9ce Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Wed, 23 Feb 2022 00:33:12 +0100 Subject: dt-bindings: arm: ux500: Document Codina-TMO This is a U8500-based phone named Samsung Galaxy Exhibit or Samsung SGH-T599, codenamed "Codina TMO" as it was made for T-Mobile. Cc: phone-devel@vger.kernel.org Cc: devicetree@vger.kernel.org Signed-off-by: Linus Walleij Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220222233313.1774416-1-linus.walleij@linaro.org Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/arm/ux500.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/ux500.yaml b/Documentation/devicetree/bindings/arm/ux500.yaml index a46193ad94e0..17accb31bca0 100644 --- a/Documentation/devicetree/bindings/arm/ux500.yaml +++ b/Documentation/devicetree/bindings/arm/ux500.yaml @@ -40,6 +40,11 @@ properties: - const: samsung,codina - const: st-ericsson,u8500 + - description: Samsung Galaxy Exhibit (SGH-T599) + items: + - const: samsung,codina-tmo + - const: st-ericsson,u8500 + - description: Samsung Galaxy Beam (GT-I8530) items: - const: samsung,gavini -- cgit From 61695f8c5d5190db11aece403304f06d22c90597 Mon Sep 17 00:00:00 2001 From: Daniel Latypov Date: Mon, 28 Mar 2022 10:41:42 -0700 Subject: kunit: split resource API from test.h into new resource.h Background: Currently, a reader looking at kunit/test.h will find the file is quite long, and the first meaty comment is a doc comment about struct kunit_resource. Most users will not ever use the KUnit resource API directly. They'll use kunit_kmalloc() and friends, or decide it's simpler to do cleanups via labels (it often can be) instead of figuring out how to use the API. It's also logically separate from everything else in test.h. Removing it from the file doesn't cause any compilation errors (since struct kunit has `struct list_head resources` to store them). This commit: Let's move it into a kunit/resource.h file and give it a separate page in the docs, kunit/api/resource.rst. We include resource.h at the bottom of test.h since * don't want to force existing users to add a new include if they use the API * it accesses `lock` inside `struct kunit` in a inline func * so we can't just forward declare, and the alternatives require uninlining the func, adding hepers to lock/unlock, or other more invasive changes. Now the first big comment in test.h is about kunit_case, which is a lot more relevant to what a new user wants to know. A side effect of this is git blame won't properly track history by default, users need to run $ git blame -L ,1 -C17 include/kunit/resource.h Signed-off-by: Daniel Latypov Reviewed-by: David Gow Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/api/index.rst | 5 +++++ Documentation/dev-tools/kunit/api/resource.rst | 13 +++++++++++++ 2 files changed, 18 insertions(+) create mode 100644 Documentation/dev-tools/kunit/api/resource.rst (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/api/index.rst b/Documentation/dev-tools/kunit/api/index.rst index 3006cadcf44a..45ce04823f9f 100644 --- a/Documentation/dev-tools/kunit/api/index.rst +++ b/Documentation/dev-tools/kunit/api/index.rst @@ -6,6 +6,7 @@ API Reference .. toctree:: test + resource This section documents the KUnit kernel testing API. It is divided into the following sections: @@ -13,3 +14,7 @@ following sections: Documentation/dev-tools/kunit/api/test.rst - documents all of the standard testing API + +Documentation/dev-tools/kunit/api/resource.rst + + - documents the KUnit resource API diff --git a/Documentation/dev-tools/kunit/api/resource.rst b/Documentation/dev-tools/kunit/api/resource.rst new file mode 100644 index 000000000000..0a94f831259e --- /dev/null +++ b/Documentation/dev-tools/kunit/api/resource.rst @@ -0,0 +1,13 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============ +Resource API +============ + +This file documents the KUnit resource API. + +Most users won't need to use this API directly, power users can use it to store +state on a per-test basis, register custom cleanup actions, and more. + +.. kernel-doc:: include/kunit/resource.h + :internal: -- cgit From b04d1a8dc7e7ff7ca91a20bef053bcc04265d83a Mon Sep 17 00:00:00 2001 From: Daniel Latypov Date: Fri, 25 Mar 2022 17:33:56 -0700 Subject: Documentation: kunit: update kconfig options needed for UML coverage Recent changes have made it so the current set is not sufficient. Namely, CONFIG_DEBUG_INFO is not being set even when explicitly asked. Specifying a version of the debug info fixes this. Pick CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT as an option that's hopefully less fragile (esp. given we're tied to GCC 6 and lower). Signed-off-by: Daniel Latypov Reviewed-by: David Gow Tested-by: Maxime Ripard Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/running_tips.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/running_tips.rst b/Documentation/dev-tools/kunit/running_tips.rst index 7b6d26a25959..c36f6760087d 100644 --- a/Documentation/dev-tools/kunit/running_tips.rst +++ b/Documentation/dev-tools/kunit/running_tips.rst @@ -114,6 +114,7 @@ Instead of enabling ``CONFIG_GCOV_KERNEL=y``, we can set these options: CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_INFO=y + CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y CONFIG_GCOV=y @@ -122,7 +123,7 @@ Putting it together into a copy-pastable sequence of commands: .. code-block:: bash # Append coverage options to the current config - $ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig + $ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig $ ./tools/testing/kunit/kunit.py run # Extract the coverage information from the build dir (.kunit/) $ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/ -- cgit From d9a64c5eb0e1388c2905961e542b26b2dcae482c Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Wed, 30 Mar 2022 14:23:33 +0900 Subject: dt-bindings: PCI: uniphier: Convert uniphier-pcie.txt to json-schema Convert the file into a JSON description at the yaml format. Signed-off-by: Kunihiko Hayashi Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/1648617814-9217-2-git-send-email-hayashi.kunihiko@socionext.com --- .../bindings/pci/socionext,uniphier-pcie.yaml | 96 ++++++++++++++++++++++ .../devicetree/bindings/pci/uniphier-pcie.txt | 82 ------------------ 2 files changed, 96 insertions(+), 82 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/socionext,uniphier-pcie.yaml delete mode 100644 Documentation/devicetree/bindings/pci/uniphier-pcie.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie.yaml b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie.yaml new file mode 100644 index 000000000000..f5926d0fb085 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/socionext,uniphier-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier PCIe host controller + +description: | + UniPhier PCIe host controller is based on the Synopsys DesignWare + PCI core. It shares common features with the PCIe DesignWare core and + inherits common properties defined in + Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml. + +maintainers: + - Kunihiko Hayashi + +allOf: + - $ref: /schemas/pci/snps,dw-pcie.yaml# + +properties: + compatible: + enum: + - socionext,uniphier-pcie + + reg: + minItems: 3 + maxItems: 4 + + reg-names: + minItems: 3 + items: + - const: dbi + - const: link + - const: config + - const: atu + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + num-viewport: true + + num-lanes: true + + phys: + maxItems: 1 + + phy-names: + const: pcie-phy + +required: + - compatible + - reg + - reg-names + - clocks + - resets + +unevaluatedProperties: false + +examples: + - | + pcie: pcie@66000000 { + compatible = "socionext,uniphier-pcie"; + reg-names = "dbi", "link", "config"; + reg = <0x66000000 0x1000>, <0x66010000 0x10000>, <0x2fff0000 0x10000>; + #address-cells = <3>; + #size-cells = <2>; + clocks = <&sys_clk 24>; + resets = <&sys_rst 24>; + num-lanes = <1>; + num-viewport = <1>; + bus-range = <0x0 0xff>; + device_type = "pci"; + ranges = <0x81000000 0 0x00000000 0x2ffe0000 0 0x00010000>, + <0x82000000 0 0x00000000 0x20000000 0 0x0ffe0000>; + phy-names = "pcie-phy"; + phys = <&pcie_phy>; + #interrupt-cells = <1>; + interrupt-names = "dma", "msi"; + interrupts = <0 224 4>, <0 225 4>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0 0 0 1 &pcie_intc 0>, + <0 0 0 2 &pcie_intc 1>, + <0 0 0 3 &pcie_intc 2>, + <0 0 0 4 &pcie_intc 3>; + + pcie_intc: legacy-interrupt-controller { + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&gic>; + interrupts = <0 226 4>; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt deleted file mode 100644 index 359585db049f..000000000000 --- a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt +++ /dev/null @@ -1,82 +0,0 @@ -Socionext UniPhier PCIe host controller bindings - -This describes the devicetree bindings for PCIe host controller implemented -on Socionext UniPhier SoCs. - -UniPhier PCIe host controller is based on the Synopsys DesignWare PCI core. -It shares common functions with the PCIe DesignWare core driver and inherits -common properties defined in -Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml. - -Required properties: -- compatible: Should be "socionext,uniphier-pcie". -- reg: Specifies offset and length of the register set for the device. - According to the reg-names, appropriate register sets are required. -- reg-names: Must include the following entries: - "dbi" - controller configuration registers - "link" - SoC-specific glue layer registers - "config" - PCIe configuration space - "atu" - iATU registers for DWC version 4.80 or later -- clocks: A phandle to the clock gate for PCIe glue layer including - the host controller. -- resets: A phandle to the reset line for PCIe glue layer including - the host controller. -- interrupts: A list of interrupt specifiers. According to the - interrupt-names, appropriate interrupts are required. -- interrupt-names: Must include the following entries: - "dma" - DMA interrupt - "msi" - MSI interrupt - -Optional properties: -- phys: A phandle to generic PCIe PHY. According to the phy-names, appropriate - phys are required. -- phy-names: Must be "pcie-phy". - -Required sub-node: -- legacy-interrupt-controller: Specifies interrupt controller for legacy PCI - interrupts. - -Required properties for legacy-interrupt-controller: -- interrupt-controller: identifies the node as an interrupt controller. -- #interrupt-cells: specifies the number of cells needed to encode an - interrupt source. The value must be 1. -- interrupt-parent: Phandle to the parent interrupt controller. -- interrupts: An interrupt specifier for legacy interrupt. - -Example: - - pcie: pcie@66000000 { - compatible = "socionext,uniphier-pcie", "snps,dw-pcie"; - status = "disabled"; - reg-names = "dbi", "link", "config"; - reg = <0x66000000 0x1000>, <0x66010000 0x10000>, - <0x2fff0000 0x10000>; - #address-cells = <3>; - #size-cells = <2>; - clocks = <&sys_clk 24>; - resets = <&sys_rst 24>; - num-lanes = <1>; - num-viewport = <1>; - bus-range = <0x0 0xff>; - device_type = "pci"; - ranges = - /* downstream I/O */ - <0x81000000 0 0x00000000 0x2ffe0000 0 0x00010000 - /* non-prefetchable memory */ - 0x82000000 0 0x00000000 0x20000000 0 0x0ffe0000>; - #interrupt-cells = <1>; - interrupt-names = "dma", "msi"; - interrupts = <0 224 4>, <0 225 4>; - interrupt-map-mask = <0 0 0 7>; - interrupt-map = <0 0 0 1 &pcie_intc 0>, /* INTA */ - <0 0 0 2 &pcie_intc 1>, /* INTB */ - <0 0 0 3 &pcie_intc 2>, /* INTC */ - <0 0 0 4 &pcie_intc 3>; /* INTD */ - - pcie_intc: legacy-interrupt-controller { - interrupt-controller; - #interrupt-cells = <1>; - interrupt-parent = <&gic>; - interrupts = <0 226 4>; - }; - }; -- cgit From 2d091155cdc38bfd149b44d0b745b607f4c325f5 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 2 Apr 2022 21:28:19 +0200 Subject: dt-bindings: white-space cleanups Remove trailing white-spaces and trailing blank lines (yamllint with default options does not like them). Suggested-by: Corentin Labbe Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220402192819.154691-1-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/clock/samsung,exynos4412-isp-clock.yaml | 1 - Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml | 1 - Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml | 1 - .../devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml | 1 - Documentation/devicetree/bindings/display/bridge/ps8640.yaml | 1 - Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml | 1 - .../devicetree/bindings/display/mediatek/mediatek,merge.yaml | 1 - Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml | 1 - .../devicetree/bindings/display/panel/orisetech,otm8009a.yaml | 1 - .../devicetree/bindings/display/sprd/sprd,display-subsystem.yaml | 1 - Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml | 1 - Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml | 1 - Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml | 1 - Documentation/devicetree/bindings/gpu/samsung-rotator.yaml | 1 - Documentation/devicetree/bindings/hwmon/adt7475.yaml | 1 - Documentation/devicetree/bindings/i2c/i2c-gate.yaml | 1 - Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml | 1 - Documentation/devicetree/bindings/iio/adc/adi,ad7291.yaml | 1 - Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml | 2 +- Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml | 1 - Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml | 2 +- Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml | 1 - Documentation/devicetree/bindings/media/microchip,xisc.yaml | 1 - Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml | 1 - Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml | 2 +- Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml | 1 - Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml | 1 - Documentation/devicetree/bindings/power/supply/power-supply.yaml | 1 - Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml | 1 - Documentation/devicetree/bindings/power/supply/tps65217-charger.yaml | 2 +- .../devicetree/bindings/regulator/socionext,uniphier-regulator.yaml | 1 - Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml | 1 - Documentation/devicetree/bindings/reserved-memory/ramoops.yaml | 1 - Documentation/devicetree/bindings/reset/microchip,rst.yaml | 1 - Documentation/devicetree/bindings/rng/intel,ixp46x-rng.yaml | 1 - Documentation/devicetree/bindings/serial/sprd-uart.yaml | 2 +- Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml | 1 - Documentation/devicetree/bindings/sound/adi,adau1372.yaml | 1 - Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml | 1 - Documentation/devicetree/bindings/sound/maxim,max98520.yaml | 1 - Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml | 2 +- Documentation/devicetree/bindings/sound/mchp,spdiftx.yaml | 2 +- .../devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml | 1 - Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml | 1 - Documentation/devicetree/bindings/sound/samsung,odroid.yaml | 1 - Documentation/devicetree/bindings/sound/tas2562.yaml | 1 - Documentation/devicetree/bindings/sound/tas2770.yaml | 1 - Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml | 1 - Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml | 1 - Documentation/devicetree/bindings/spi/renesas,hspi.yaml | 1 - Documentation/devicetree/bindings/usb/dwc2.yaml | 4 ++-- Documentation/devicetree/bindings/usb/smsc,usb3503.yaml | 2 +- 52 files changed, 10 insertions(+), 53 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos4412-isp-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos4412-isp-clock.yaml index 1ed64add4355..7ad8a0c23b2a 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos4412-isp-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos4412-isp-clock.yaml @@ -61,4 +61,3 @@ examples: clocks = <&clock CLK_ACLK200>, <&clock CLK_ACLK400_MCUISP>; clock-names = "aclk200", "aclk400_mcuisp"; }; - diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml index 00648f9d9278..026a9f9e1aeb 100644 --- a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml +++ b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml @@ -82,4 +82,3 @@ examples: clock-names = "bus", "mod"; resets = <&ccu RST_BUS_CE>; }; - diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml index 343598c9f473..2e208d2fc98f 100644 --- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml @@ -150,4 +150,3 @@ examples: }; }; }; - diff --git a/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml index a88a5d8c7ba5..a44d025d33bd 100644 --- a/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml +++ b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml @@ -78,4 +78,3 @@ examples: }; }; }; - diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml index 186e17be51fb..8ab156e0a8cf 100644 --- a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml @@ -119,4 +119,3 @@ examples: }; }; }; - diff --git a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml index 0091df9dd73b..989ab312c1f4 100644 --- a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml +++ b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml @@ -105,4 +105,3 @@ examples: }; }; }; - diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml index d635c5dcb68b..69ba75777dac 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml @@ -102,4 +102,3 @@ examples: clock-names = "merge"; }; }; - diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml index 20ce88ab4b3a..6058948a9764 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml @@ -75,4 +75,3 @@ examples: }; }; ... - diff --git a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml index 17cbd0ad32bf..ad7d3575190e 100644 --- a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml +++ b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml @@ -50,4 +50,3 @@ examples: }; }; ... - diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml index d0a5592bd89d..b3d5e1b96fae 100644 --- a/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml +++ b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml @@ -63,4 +63,3 @@ examples: compatible = "sprd,display-subsystem"; ports = <&dpu_out>; }; - diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml b/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml index 01e2da23790b..d6ea4d62a2cf 100644 --- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml @@ -75,4 +75,3 @@ examples: }; ... - diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml index 7b1833d6caa2..1e1d8549b7ef 100644 --- a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml +++ b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml @@ -51,4 +51,3 @@ examples: }; ... - diff --git a/Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml b/Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml index 87b4afd2cf62..00cfa3913652 100644 --- a/Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml +++ b/Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml @@ -104,4 +104,3 @@ examples: }; ... - diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml b/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml index 62486f55177d..d60626ffb28e 100644 --- a/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml @@ -53,4 +53,3 @@ examples: clocks = <&clock 278>; clock-names = "rotator"; }; - diff --git a/Documentation/devicetree/bindings/hwmon/adt7475.yaml b/Documentation/devicetree/bindings/hwmon/adt7475.yaml index 7d9c083632b9..38879419c364 100644 --- a/Documentation/devicetree/bindings/hwmon/adt7475.yaml +++ b/Documentation/devicetree/bindings/hwmon/adt7475.yaml @@ -81,4 +81,3 @@ examples: adi,pwm-active-state = <1 0 1>; }; }; - diff --git a/Documentation/devicetree/bindings/i2c/i2c-gate.yaml b/Documentation/devicetree/bindings/i2c/i2c-gate.yaml index bd67b0766599..0cdc3e890df7 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-gate.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-gate.yaml @@ -36,4 +36,3 @@ examples: }; }; ... - diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml index 9b0603a72f40..b6af924dee2e 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml @@ -28,7 +28,6 @@ description: |+ '------------' '-----' '-----' '-----' - allOf: - $ref: /schemas/i2c/i2c-mux.yaml# diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7291.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7291.yaml index 930f9e3904d7..0b2f5dc80600 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7291.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7291.yaml @@ -44,4 +44,3 @@ examples: }; }; ... - diff --git a/Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml b/Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml index e51a585bd5a3..133b0f867992 100644 --- a/Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml +++ b/Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml @@ -41,7 +41,7 @@ examples: spi { #address-cells = <1>; #size-cells = <0>; - + dac@0 { compatible = "lltc,ltc1660"; reg = <0>; diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml index af51b91c893e..783c6b37c9f0 100644 --- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml +++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml @@ -107,4 +107,3 @@ examples: power-domains = <&pd_gsc>; #iommu-cells = <0>; }; - diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml index 1c24b333c6e2..5d66c3e4def5 100644 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml @@ -81,7 +81,7 @@ properties: description: | kHz; switching frequency. $ref: /schemas/types.yaml#/definitions/uint32 - enum: [ 600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371, 1600, 1920, + enum: [ 600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371, 1600, 1920, 2400, 3200, 4800, 9600 ] qcom,ovp: diff --git a/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml b/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml index aa2b3bf56b57..ea06976fbbc7 100644 --- a/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml +++ b/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml @@ -51,4 +51,3 @@ examples: interrupts = <208>, <209>, <210>; #mbox-cells = <1>; }; - diff --git a/Documentation/devicetree/bindings/media/microchip,xisc.yaml b/Documentation/devicetree/bindings/media/microchip,xisc.yaml index 086e1430af4f..40947f18873a 100644 --- a/Documentation/devicetree/bindings/media/microchip,xisc.yaml +++ b/Documentation/devicetree/bindings/media/microchip,xisc.yaml @@ -126,4 +126,3 @@ examples: }; }; }; - diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml index a30419ef550a..b783ad0d1f53 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml @@ -142,4 +142,3 @@ examples: assigned-clock-parents = <&k3_clks 118 11>; }; }; - diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml index cdf7b873b419..82d0a6b2a0a0 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml @@ -302,7 +302,7 @@ examples: pcie0 { #size-cells = <2>; #address-cells = <3>; - + wifi_0: wifi@0 { reg = <0 0 0 0 0>; memory-region = <&qcn9074_0>; diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml index 7657721a4e96..86e5f6513bb3 100644 --- a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml +++ b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml @@ -40,4 +40,3 @@ examples: #power-domain-cells = <1>; }; }; - diff --git a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml index 2dda91587dc3..dc697b6147b2 100644 --- a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml +++ b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml @@ -78,4 +78,3 @@ examples: power-supplies = <&mains_charger>, <&usb_charger>; }; }; - diff --git a/Documentation/devicetree/bindings/power/supply/power-supply.yaml b/Documentation/devicetree/bindings/power/supply/power-supply.yaml index 531b67225c74..9a490fbd32e1 100644 --- a/Documentation/devicetree/bindings/power/supply/power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/power-supply.yaml @@ -19,4 +19,3 @@ properties: supply it power, referenced by their phandles. additionalProperties: true - diff --git a/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml b/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml index a23f6653f332..93654e732cda 100644 --- a/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml +++ b/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml @@ -87,4 +87,3 @@ examples: }; }; }; - diff --git a/Documentation/devicetree/bindings/power/supply/tps65217-charger.yaml b/Documentation/devicetree/bindings/power/supply/tps65217-charger.yaml index a33408c3a407..2c2fe883bb48 100644 --- a/Documentation/devicetree/bindings/power/supply/tps65217-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/tps65217-charger.yaml @@ -24,7 +24,7 @@ properties: items: - const: USB - const: AC - + required: - compatible - interrupts diff --git a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml index 1218f21ba320..b48790cc05c8 100644 --- a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml @@ -83,4 +83,3 @@ examples: resets = <&sys_rst 14>; }; }; - diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml index 836d4156d54c..a5a27ee0a9e6 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml @@ -51,4 +51,3 @@ examples: }; ... - diff --git a/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml b/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml index f4c351a69542..0391871cf44d 100644 --- a/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml +++ b/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml @@ -142,4 +142,3 @@ examples: }; }; }; - diff --git a/Documentation/devicetree/bindings/reset/microchip,rst.yaml b/Documentation/devicetree/bindings/reset/microchip,rst.yaml index 578bfa529b16..81cd8c837623 100644 --- a/Documentation/devicetree/bindings/reset/microchip,rst.yaml +++ b/Documentation/devicetree/bindings/reset/microchip,rst.yaml @@ -57,4 +57,3 @@ examples: #reset-cells = <1>; cpu-syscon = <&cpu_ctrl>; }; - diff --git a/Documentation/devicetree/bindings/rng/intel,ixp46x-rng.yaml b/Documentation/devicetree/bindings/rng/intel,ixp46x-rng.yaml index 61963fa9347e..067e71e8ebe8 100644 --- a/Documentation/devicetree/bindings/rng/intel,ixp46x-rng.yaml +++ b/Documentation/devicetree/bindings/rng/intel,ixp46x-rng.yaml @@ -33,4 +33,3 @@ examples: compatible = "intel,ixp46x-rng"; reg = <0x70002100 4>; }; - diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.yaml b/Documentation/devicetree/bindings/serial/sprd-uart.yaml index a444bebd2c1a..da0e2745b5fc 100644 --- a/Documentation/devicetree/bindings/serial/sprd-uart.yaml +++ b/Documentation/devicetree/bindings/serial/sprd-uart.yaml @@ -35,7 +35,7 @@ properties: clock-names: description: | - "enable" for UART module enable clock, "uart" for UART clock, "source" + "enable" for UART module enable clock, "uart" for UART clock, "source" for UART source (parent) clock. items: - const: enable diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml index 02b2d5ba01d6..17db87cb9dab 100644 --- a/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml +++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml @@ -48,4 +48,3 @@ examples: compatible = "amlogic,canvas"; reg = <0x48 0x14>; }; - diff --git a/Documentation/devicetree/bindings/sound/adi,adau1372.yaml b/Documentation/devicetree/bindings/sound/adi,adau1372.yaml index 701449311fec..59f7c60a14ba 100644 --- a/Documentation/devicetree/bindings/sound/adi,adau1372.yaml +++ b/Documentation/devicetree/bindings/sound/adi,adau1372.yaml @@ -64,4 +64,3 @@ examples: clock-frequency = <12288000>; }; ... - diff --git a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml index 8b5be4b92f35..b4b35edcb493 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml @@ -112,4 +112,3 @@ examples: }; }; }; - diff --git a/Documentation/devicetree/bindings/sound/maxim,max98520.yaml b/Documentation/devicetree/bindings/sound/maxim,max98520.yaml index b6509cb2c8e0..3f88c7d61e34 100644 --- a/Documentation/devicetree/bindings/sound/maxim,max98520.yaml +++ b/Documentation/devicetree/bindings/sound/maxim,max98520.yaml @@ -33,4 +33,3 @@ examples: reg = <0x38>; }; }; - diff --git a/Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml b/Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml index 4a2129005c0f..970311143253 100644 --- a/Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml +++ b/Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml @@ -10,7 +10,7 @@ maintainers: - Codrin Ciubotariu description: - The Microchip Sony/Philips Digital Interface Receiver is a serial port + The Microchip Sony/Philips Digital Interface Receiver is a serial port compliant with the IEC-60958 standard. properties: diff --git a/Documentation/devicetree/bindings/sound/mchp,spdiftx.yaml b/Documentation/devicetree/bindings/sound/mchp,spdiftx.yaml index bdfb63387c53..d5c022e49526 100644 --- a/Documentation/devicetree/bindings/sound/mchp,spdiftx.yaml +++ b/Documentation/devicetree/bindings/sound/mchp,spdiftx.yaml @@ -10,7 +10,7 @@ maintainers: - Codrin Ciubotariu description: - The Microchip Sony/Philips Digital Interface Transmitter is a serial port + The Microchip Sony/Philips Digital Interface Transmitter is a serial port compliant with the IEC-60958 standard. properties: diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml index e768fb0e9a59..b1deaf271afa 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml @@ -82,4 +82,3 @@ examples: clocks = <&clk 216>, <&clk 217>, <&clk 120>; clock-names = "pll_a", "pll_a_out0", "mclk"; }; - diff --git a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml index 97f83eeaf091..a01c4ad929b8 100644 --- a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml @@ -149,4 +149,3 @@ examples: sound-dai = <&wm8994>; }; }; - diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml index db2513f3e168..7b4e08ddef6a 100644 --- a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml @@ -92,4 +92,3 @@ examples: sound-dai = <&hdmi>, <&max98090>; }; }; - diff --git a/Documentation/devicetree/bindings/sound/tas2562.yaml b/Documentation/devicetree/bindings/sound/tas2562.yaml index acd4bbe69731..5f7dd5d6cbca 100644 --- a/Documentation/devicetree/bindings/sound/tas2562.yaml +++ b/Documentation/devicetree/bindings/sound/tas2562.yaml @@ -76,4 +76,3 @@ examples: ti,imon-slot-no = <0>; }; }; - diff --git a/Documentation/devicetree/bindings/sound/tas2770.yaml b/Documentation/devicetree/bindings/sound/tas2770.yaml index 027bebf4e8cf..bc90e72bf7cf 100644 --- a/Documentation/devicetree/bindings/sound/tas2770.yaml +++ b/Documentation/devicetree/bindings/sound/tas2770.yaml @@ -80,4 +80,3 @@ examples: ti,vmon-slot-no = <2>; }; }; - diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml index 4d46c49ec32b..50de0da42c13 100644 --- a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml +++ b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml @@ -95,4 +95,3 @@ examples: reg = <0>; }; }; - diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml index 54b6f15eca18..8a9d526d06eb 100644 --- a/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml +++ b/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml @@ -52,4 +52,3 @@ examples: spi-max-frequency = <40000000>; }; }; - diff --git a/Documentation/devicetree/bindings/spi/renesas,hspi.yaml b/Documentation/devicetree/bindings/spi/renesas,hspi.yaml index c0eccf703039..bab5d4b7fc3d 100644 --- a/Documentation/devicetree/bindings/spi/renesas,hspi.yaml +++ b/Documentation/devicetree/bindings/spi/renesas,hspi.yaml @@ -56,4 +56,3 @@ examples: #address-cells = <1>; #size-cells = <0>; }; - diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index 4cebce682d16..17fc471a12bd 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -139,12 +139,12 @@ properties: snps,need-phy-for-wake: $ref: /schemas/types.yaml#/definitions/flag - description: If present indicates that the phy needs to be left on for + description: If present indicates that the phy needs to be left on for remote wakeup during suspend. snps,reset-phy-on-wake: $ref: /schemas/types.yaml#/definitions/flag - description: If present indicates that we need to reset the PHY when we + description: If present indicates that we need to reset the PHY when we detect a wakeup. This is due to a hardware errata. port: diff --git a/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml b/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml index 39228a506b93..b9e219829801 100644 --- a/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml +++ b/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml @@ -77,7 +77,7 @@ examples: i2c { #address-cells = <1>; #size-cells = <0>; - + usb-hub@8 { compatible = "smsc,usb3503"; reg = <0x08>; -- cgit From d49b3ae4294f00f268a76648d920dc2a2a07ec90 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 2 Apr 2022 17:55:51 +0200 Subject: dt-bindings: net: qcom,ipa: finish the qcom,smp2p example The example using qcom,smp2p should have all necessary properties, to avoid DT schema validation warnings. Reported-by: Rob Herring Signed-off-by: Krzysztof Kozlowski Reviewed-by: Alex Elder Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220402155551.16509-2-krzysztof.kozlowski@linaro.org --- Documentation/devicetree/bindings/net/qcom,ipa.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index 58ecc62adfaa..dd4bb2e74880 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -182,6 +182,12 @@ examples: smp2p-mpss { compatible = "qcom,smp2p"; + interrupts = ; + mboxes = <&apss_shared 6>; + qcom,smem = <94>, <432>; + qcom,local-pid = <0>; + qcom,remote-pid = <5>; + ipa_smp2p_out: ipa-ap-to-modem { qcom,entry-name = "ipa"; #qcom,smem-state-cells = <1>; @@ -193,6 +199,7 @@ examples: #interrupt-cells = <2>; }; }; + ipa@1e40000 { compatible = "qcom,sdm845-ipa"; -- cgit From 44c8a51a5f28436622fde18fd057c857b42ac28c Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 3 Apr 2022 10:18:48 +0200 Subject: docs: dt: writing-bindings: describe typical cases Add a chapter for caveats or typical mistakes. Source: Rob Herring's (Devicetree bindings maintainer) comments on LKML. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220403081849.8051-1-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/writing-bindings.rst | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/writing-bindings.rst b/Documentation/devicetree/bindings/writing-bindings.rst index 18d9e0689d49..5465eced2af1 100644 --- a/Documentation/devicetree/bindings/writing-bindings.rst +++ b/Documentation/devicetree/bindings/writing-bindings.rst @@ -58,6 +58,31 @@ Properties - DO define properties in terms of constraints. How many entries? What are possible values? What is the order? +Typical cases and caveats +========================= + +- Phandle entries, like clocks/dmas/interrupts/resets, should always be + explicitly ordered. Include the {clock,dma,interrupt,reset}-names if there is + more than one phandle. When used, both of these fields need the same + constraints (e.g. list of items). + +- For names used in {clock,dma,interrupt,reset}-names, do not add any suffix, + e.g.: "tx" instead of "txirq" (for interrupt). + +- Properties without schema types (e.g. without standard suffix or not defined + by schema) need the type, even if this is an enum. + +- If schema includes other schema (e.g. /schemas/i2c/i2c-controller.yaml) use + "unevaluatedProperties:false". In other cases, usually use + "additionalProperties:false". + +- For sub-blocks/components of bigger device (e.g. SoC blocks) use rather + device-based compatible (e.g. SoC-based compatible), instead of custom + versioning of that component. + For example use "vendor,soc1234-i2c" instead of "vendor,i2c-v2". + +- "syscon" is not a generic property. Use vendor and type, e.g. + "vendor,power-manager-syscon". Board/SoC .dts Files ==================== -- cgit From 7a150b0d850e37e7bdfc87459edd0ff302f67478 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 3 Apr 2022 10:18:49 +0200 Subject: docs: dt: writing-schema: mention coding style Mention the usage of YAML coding style. Describe explicitly that four-space indentation in DTS examples is preferred, because: 1. The YAML's default two-space indentation for DTS code makes it significantly less readable. 2. Linux coding style tabs would introduce inconsistency (entire file is indented with spaces). 3. On the other hand, eight spaces would not align with example's opening ' - |' part. Four spaces makes the code nicely aligned with it. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220403081849.8051-2-krzysztof.kozlowski@linaro.org --- Documentation/devicetree/bindings/example-schema.yaml | 14 +++++++------- Documentation/devicetree/bindings/writing-schema.rst | 6 ++++++ 2 files changed, 13 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml index 80a28781845d..8e1a8b19d429 100644 --- a/Documentation/devicetree/bindings/example-schema.yaml +++ b/Documentation/devicetree/bindings/example-schema.yaml @@ -249,13 +249,13 @@ examples: # be overridden or an appropriate parent bus node should be shown (such as on # i2c buses). # - # Any includes used have to be explicitly included. + # Any includes used have to be explicitly included. Use 4-space indentation. - | node@1000 { - compatible = "vendor,soc4-ip", "vendor,soc1-ip"; - reg = <0x1000 0x80>, - <0x3000 0x80>; - reg-names = "core", "aux"; - interrupts = <10>; - interrupt-controller; + compatible = "vendor,soc4-ip", "vendor,soc1-ip"; + reg = <0x1000 0x80>, + <0x3000 0x80>; + reg-names = "core", "aux"; + interrupts = <10>; + interrupt-controller; }; diff --git a/Documentation/devicetree/bindings/writing-schema.rst b/Documentation/devicetree/bindings/writing-schema.rst index 95ecf55559e5..2916edf829db 100644 --- a/Documentation/devicetree/bindings/writing-schema.rst +++ b/Documentation/devicetree/bindings/writing-schema.rst @@ -108,6 +108,12 @@ The YAML Devicetree format also makes all string values an array and scalar values a matrix (in order to define groupings) even when only a single value is present. Single entries in schemas are fixed up to match this encoding. +Coding style +------------ + +Use YAML coding style (two-space indentation). For DTS examples in the schema, +preferred is four-space indentation. + Testing ------- -- cgit From 60657fb9b19d4ff310bdebfd1fd5a075678c29fb Mon Sep 17 00:00:00 2001 From: Srinivasa Rao Mandadapu Date: Thu, 3 Mar 2022 19:32:08 +0530 Subject: dt-bindings: soundwire: qcom: Add bindings for audio clock reset control property Update description for audio clock reset control property, which is required for latest chipsets, to allow rx, tx and wsa bus clock enabling in software control mode by configuring dynamic clock gating control registers. Signed-off-by: Srinivasa Rao Mandadapu Co-developed-by: Venkata Prasad Potturu Signed-off-by: Venkata Prasad Potturu Reviewed-by: Stephen Boyd Acked-by: Rob Herring Link: https://lore.kernel.org/r/1646316128-21082-3-git-send-email-quic_srivasam@quicinc.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/soundwire/qcom,sdw.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt index 51ddbc509382..c85c25779e3f 100644 --- a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt +++ b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt @@ -162,6 +162,18 @@ board specific bus parameters. or applicable for the respective data port. More info in MIPI Alliance SoundWire 1.0 Specifications. +- reset: + Usage: optional + Value type: + Definition: Should specify the SoundWire audio CSR reset controller interface, + which is required for SoundWire version 1.6.0 and above. + +- reset-names: + Usage: optional + Value type: + Definition: should be "swr_audio_cgcr" for SoundWire audio CSR reset + controller interface. + Note: More Information on detail of encoding of these fields can be found in MIPI Alliance SoundWire 1.0 Specifications. @@ -180,6 +192,8 @@ soundwire: soundwire@c85 { interrupts = <20 IRQ_TYPE_EDGE_RISING>; clocks = <&wcc>; clock-names = "iface"; + resets = <&lpass_audiocc LPASS_AUDIO_SWR_TX_CGCR>; + reset-names = "swr_audio_cgcr"; #sound-dai-cells = <1>; qcom,dports-type = <0>; qcom,dout-ports = <6>; -- cgit From 2d12d3da5374433d44692a8681417bc7c424439b Mon Sep 17 00:00:00 2001 From: Tvrtko Ursulin Date: Fri, 1 Apr 2022 15:22:03 +0100 Subject: drm: Document fdinfo format specification MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Proposal to standardise the fdinfo text format as optionally output by DRM drivers. Idea is that a simple but, well defined, spec will enable generic userspace tools to be written while at the same time avoiding a more heavy handed approach of adding a mid-layer to DRM. i915 implements a subset of the spec, everything apart from the memory stats currently, and a matching intel_gpu_top tool exists. Open is to see if AMD can migrate to using the proposed GPU utilisation key-value pairs, or if they are not workable to see whether to go vendor specific, or if a standardised alternative can be found which is workable for both drivers. Same for the memory utilisation key-value pairs proposal. v2: * Update for removal of name and pid. v3: * 'Drm-driver' tag will be obtained from struct drm_driver.name. (Daniel) v4: * Added drm-engine-capacity- tag. Signed-off-by: Tvrtko Ursulin Cc: David M Nieto Cc: Christian König Cc: Daniel Vetter Cc: Daniel Stone Cc: Chris Healy Acked-by: Christian König Reviewed-by: Umesh Nerlige Ramappa Link: https://patchwork.freedesktop.org/patch/msgid/20220401142205.3123159-7-tvrtko.ursulin@linux.intel.com --- Documentation/gpu/drm-usage-stats.rst | 106 ++++++++++++++++++++++++++++++++++ Documentation/gpu/index.rst | 1 + 2 files changed, 107 insertions(+) create mode 100644 Documentation/gpu/drm-usage-stats.rst (limited to 'Documentation') diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst new file mode 100644 index 000000000000..b8cc28f4da6f --- /dev/null +++ b/Documentation/gpu/drm-usage-stats.rst @@ -0,0 +1,106 @@ +.. _drm-client-usage-stats: + +====================== +DRM client usage stats +====================== + +DRM drivers can choose to export partly standardised text output via the +`fops->show_fdinfo()` as part of the driver specific file operations registered +in the `struct drm_driver` object registered with the DRM core. + +One purpose of this output is to enable writing as generic as practicaly +feasible `top(1)` like userspace monitoring tools. + +Given the differences between various DRM drivers the specification of the +output is split between common and driver specific parts. Having said that, +wherever possible effort should still be made to standardise as much as +possible. + +File format specification +========================= + +- File shall contain one key value pair per one line of text. +- Colon character (`:`) must be used to delimit keys and values. +- All keys shall be prefixed with `drm-`. +- Whitespace between the delimiter and first non-whitespace character shall be + ignored when parsing. +- Neither keys or values are allowed to contain whitespace characters. +- Numerical key value pairs can end with optional unit string. +- Data type of the value is fixed as defined in the specification. + +Key types +--------- + +1. Mandatory, fully standardised. +2. Optional, fully standardised. +3. Driver specific. + +Data types +---------- + +- - Unsigned integer without defining the maximum value. +- - String excluding any above defined reserved characters or whitespace. + +Mandatory fully standardised keys +--------------------------------- + +- drm-driver: + +String shall contain the name this driver registered as via the respective +`struct drm_driver` data structure. + +Optional fully standardised keys +-------------------------------- + +- drm-pdev: + +For PCI devices this should contain the PCI slot address of the device in +question. + +- drm-client-id: + +Unique value relating to the open DRM file descriptor used to distinguish +duplicated and shared file descriptors. Conceptually the value should map 1:1 +to the in kernel representation of `struct drm_file` instances. + +Uniqueness of the value shall be either globally unique, or unique within the +scope of each device, in which case `drm-pdev` shall be present as well. + +Userspace should make sure to not double account any usage statistics by using +the above described criteria in order to associate data to individual clients. + +- drm-engine-: ns + +GPUs usually contain multiple execution engines. Each shall be given a stable +and unique name (str), with possible values documented in the driver specific +documentation. + +Value shall be in specified time units which the respective GPU engine spent +busy executing workloads belonging to this client. + +Values are not required to be constantly monotonic if it makes the driver +implementation easier, but are required to catch up with the previously reported +larger value within a reasonable period. Upon observing a value lower than what +was previously read, userspace is expected to stay with that larger previous +value until a monotonic update is seen. + +- drm-engine-capacity-: + +Engine identifier string must be the same as the one specified in the +drm-engine- tag and shall contain a greater than zero number in case the +exported engine corresponds to a group of identical hardware engines. + +In the absence of this tag parser shall assume capacity of one. Zero capacity +is not allowed. + +- drm-memory-: [KiB|MiB] + +Each possible memory type which can be used to store buffer objects by the +GPU in question shall be given a stable and unique name to be returned as the +string here. + +Value shall reflect the amount of storage currently consumed by the buffer +object belong to this client, in the respective memory region. + +Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' +indicating kibi- or mebi-bytes. diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index b9c1214d8f23..b99dede9a5b1 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide drm-kms drm-kms-helpers drm-uapi + drm-usage-stats driver-uapi drm-client drivers -- cgit From 055634e4b62f109a47727c2c50586e2e318595a9 Mon Sep 17 00:00:00 2001 From: Tvrtko Ursulin Date: Fri, 1 Apr 2022 15:22:05 +0100 Subject: drm/i915: Expose client engine utilisation via fdinfo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Similar to AMD commit 874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the infrastructure added in previous patches, we add basic client info and GPU engine utilisation for i915. Example of the output: pos: 0 flags: 0100002 mnt_id: 21 drm-driver: i915 drm-pdev: 0000:00:02.0 drm-client-id: 7 drm-engine-render: 9288864723 ns drm-engine-copy: 2035071108 ns drm-engine-video: 0 ns drm-engine-video-enhance: 0 ns v2: * Update for removal of name and pid. v3: * Use drm_driver.name. v4: * Added drm-engine-capacity- tag. * Fix typo. (Umesh) v5: * Don't output engine data before Gen8. Signed-off-by: Tvrtko Ursulin Cc: David M Nieto Cc: Christian König Cc: Daniel Vetter Cc: Chris Healy Acked-by: Christian König Reviewed-by: Umesh Nerlige Ramappa Acked-by: Rob Clark Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220401142205.3123159-9-tvrtko.ursulin@linux.intel.com --- Documentation/gpu/drm-usage-stats.rst | 6 ++++++ Documentation/gpu/i915.rst | 28 ++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index b8cc28f4da6f..6c9f166a8d6f 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -104,3 +104,9 @@ object belong to this client, in the respective memory region. Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' indicating kibi- or mebi-bytes. + +=============================== +Driver specific implementations +=============================== + +:ref:`i915-usage-stats` diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index bcaefc952764..cfc64f5795a4 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -709,3 +709,31 @@ The style guide for ``i915_reg.h``. .. kernel-doc:: drivers/gpu/drm/i915/i915_reg.h :doc: The i915 register macro definition style guide + +.. _i915-usage-stats: + +i915 DRM client usage stats implementation +========================================== + +The drm/i915 driver implements the DRM client usage stats specification as +documented in :ref:`drm-client-usage-stats`. + +Example of the output showing the implemented key value pairs and entirety of +the currently possible format options: + +:: + + pos: 0 + flags: 0100002 + mnt_id: 21 + drm-driver: i915 + drm-pdev: 0000:00:02.0 + drm-client-id: 7 + drm-engine-render: 9288864723 ns + drm-engine-copy: 2035071108 ns + drm-engine-video: 0 ns + drm-engine-capacity-video: 2 + drm-engine-video-enhance: 0 ns + +Possible `drm-engine-` key names are: `render`, `copy`, `video` and +`video-enhance`. -- cgit From 8047f98c8958d0f0c29882298ec293ff09ffea92 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Wed, 23 Mar 2022 16:48:23 +0100 Subject: dt-bindings: display: bridge: Drop requirement on input port for DSI devices MIPI-DSI devices, if they are controlled through the bus itself, have to be described as a child node of the controller they are attached to. Thus, there's no requirement on the controller having an OF-Graph output port to model the data stream: it's assumed that it would go from the parent to the child. However, some bridges controlled through the DSI bus still require an input OF-Graph port, thus requiring a controller with an OF-Graph output port. This prevents those bridges from being used with the controllers that do not have one without any particular reason to. Let's drop that requirement. Signed-off-by: Maxime Ripard Reviewed-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20220323154823.839469-1-maxime@cerno.tech --- Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml | 1 - Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml | 1 - 2 files changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml index 62c3bd4cb28d..7257fd0ae4da 100644 --- a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml +++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml @@ -51,7 +51,6 @@ properties: Video port for MIPI DPI output (panel or connector). required: - - port@0 - port@1 required: diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml index 5216c27fc0ad..a412a1da950f 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml @@ -39,7 +39,6 @@ properties: Video port for MIPI DPI output (panel or connector). required: - - port@0 - port@1 required: -- cgit From e23d86c49a9c78e8dbe3abff20b30812b26ab427 Mon Sep 17 00:00:00 2001 From: Kuldeep Singh Date: Tue, 29 Mar 2022 00:50:06 +0530 Subject: spi: qcom-qspi: Add minItems to interconnect-names Add minItems constraint to interconnect-names as well. The schema currently tries to match 2 names and fail for DTs with single entry. With the change applied, below interconnect-names values are possible: ['qspi-config'], ['qspi-config', 'qspi-memory'] Fixes: 8f9c291558ea ("dt-bindings: spi: Add interconnect binding for QSPI") Signed-off-by: Kuldeep Singh Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220328192006.18523-1-singh.kuldeep87k@gmail.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml index 5a60fba14bba..44d08aa3fd85 100644 --- a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml @@ -49,6 +49,7 @@ properties: maxItems: 2 interconnect-names: + minItems: 1 items: - const: qspi-config - const: qspi-memory -- cgit From c1be1ef1b4a7589878d63673b7b322856989064e Mon Sep 17 00:00:00 2001 From: Bagas Sanjaya Date: Sun, 3 Apr 2022 13:57:36 +0700 Subject: Documentation: kvm: Add missing line break in api.rst Add missing line break separator between literal block and description of KVM_EXIT_RISCV_SBI. This fixes: /Documentation/virt/kvm/api.rst:6118: WARNING: Literal block ends without a blank line; unexpected unindent. Fixes: da40d85805937d (RISC-V: KVM: Document RISC-V specific parts of KVM API, 2021-09-27) Cc: Anup Patel Cc: Paolo Bonzini Cc: Jonathan Corbet Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-riscv@lists.infradead.org Signed-off-by: Bagas Sanjaya Message-Id: <20220403065735.23859-1-bagasdotme@gmail.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index d13fa6600467..85c7abc51af5 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6190,6 +6190,7 @@ Valid values for 'type' are: unsigned long args[6]; unsigned long ret[2]; } riscv_sbi; + If exit reason is KVM_EXIT_RISCV_SBI then it indicates that the VCPU has done a SBI call which is not handled by KVM RISC-V kernel module. The details of the SBI call are available in 'riscv_sbi' member of kvm_run structure. The -- cgit From afd24a50c73c8fa6619fee093ceee2ab40bb2146 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Mon, 4 Apr 2022 17:29:48 +0200 Subject: dt-bindings: gpio: renesas,rcar-gpio: Add r8a779f0 support Document support for the GPIO controller blocks in the Renesas R-Car S4-8 (R8A779F0) SoC, including a new family-specific compatible value for the R-Car Gen4 family. Signed-off-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Signed-off-by: Bartosz Golaszewski --- Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml b/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml index f2541739ee3b..0681a4790cd6 100644 --- a/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml @@ -51,6 +51,11 @@ properties: - items: - const: renesas,gpio-r8a779a0 # R-Car V3U + - items: + - enum: + - renesas,gpio-r8a779f0 # R-Car S4-8 + - const: renesas,rcar-gen4-gpio # R-Car Gen4 + reg: maxItems: 1 -- cgit From 0c603a5c704fcfead5e85e4c89c297d2be68b671 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 2 Apr 2022 12:07:06 +0200 Subject: Documentation/process: mention patch changelog in review process Extend the "Respond to review comments" section of "Submitting patches" with reference to patch changelogs. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Jonathan Corbet --- Documentation/process/submitting-patches.rst | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index fb496b2ebfd3..9bb4e8c0f635 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -318,7 +318,10 @@ understands what is going on. Be sure to tell the reviewers what changes you are making and to thank them for their time. Code review is a tiring and time-consuming process, and reviewers sometimes get grumpy. Even in that case, though, respond -politely and address the problems they have pointed out. +politely and address the problems they have pointed out. When sending a next +version, add a ``patch changelog`` to the cover letter or to individual patches +explaining difference aganst previous submission (see +:ref:`the_canonical_patch_format`). See Documentation/process/email-clients.rst for recommendations on email clients and mailing list etiquette. -- cgit From 2c2de6f2e2bc444eed65eaa949b4fdadab93f6b3 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Sat, 2 Apr 2022 08:19:05 +0900 Subject: docs: driver-api/thermal/intel_dptf: Use copyright symbol MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Using a substitution pattern of "|copy|" without including isonum.txt causes a doc build warning. Using the symbol "©" itself is a better choice for those who read .rst sources. Reported by: Randy Dunlap Fixes: 16c02447f3e1 ("Documentation: thermal: DPTF Documentation") Suggested-by: Jonathan Corbet Signed-off-by: Akira Yokosawa Cc: "Rafael J. Wysocki" Cc: Srinivas Pandruvada Cc: linux-pm@vger.kernel.org Cc: linux-doc@vger.kernel.org Acked-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: Jonathan Corbet --- Documentation/driver-api/thermal/intel_dptf.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/thermal/intel_dptf.rst b/Documentation/driver-api/thermal/intel_dptf.rst index 96668dca753a..372bdb4d04c6 100644 --- a/Documentation/driver-api/thermal/intel_dptf.rst +++ b/Documentation/driver-api/thermal/intel_dptf.rst @@ -4,7 +4,7 @@ Intel(R) Dynamic Platform and Thermal Framework Sysfs Interface =============================================================== -:Copyright: |copy| 2022 Intel Corporation +:Copyright: © 2022 Intel Corporation :Author: Srinivas Pandruvada -- cgit From 12379401c000495e683c5c5574b82a64f8d826d6 Mon Sep 17 00:00:00 2001 From: Marcelo Schmitt Date: Wed, 30 Mar 2022 18:49:33 -0300 Subject: Documentation: dev-tools: Add a section for static analysis tools Complement the Kernel Testing Guide documentation page by adding a section about static analysis tools. Signed-off-by: Marcelo Schmitt Acked-by: Daniel Latypov Acked-by: Dan Carpenter Acked-by: Julia Lawall Reviewed-by: David Gow Reviewed-by: Shuah Khan Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/testing-overview.rst | 31 ++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) (limited to 'Documentation') diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst index 65feb81edb14..b5e02dd3fd94 100644 --- a/Documentation/dev-tools/testing-overview.rst +++ b/Documentation/dev-tools/testing-overview.rst @@ -115,3 +115,34 @@ that none of these errors are occurring during the test. Some of these tools integrate with KUnit or kselftest and will automatically fail tests if an issue is detected. +Static Analysis Tools +===================== + +In addition to testing a running kernel, one can also analyze kernel source code +directly (**at compile time**) using **static analysis** tools. The tools +commonly used in the kernel allow one to inspect the whole source tree or just +specific files within it. They make it easier to detect and fix problems during +the development process. + +Sparse can help test the kernel by performing type-checking, lock checking, +value range checking, in addition to reporting various errors and warnings while +examining the code. See the Documentation/dev-tools/sparse.rst documentation +page for details on how to use it. + +Smatch extends Sparse and provides additional checks for programming logic +mistakes such as missing breaks in switch statements, unused return values on +error checking, forgetting to set an error code in the return of an error path, +etc. Smatch also has tests against more serious issues such as integer +overflows, null pointer dereferences, and memory leaks. See the project page at +http://smatch.sourceforge.net/. + +Coccinelle is another static analyzer at our disposal. Coccinelle is often used +to aid refactoring and collateral evolution of source code, but it can also help +to avoid certain bugs that occur in common code patterns. The types of tests +available include API tests, tests for correct usage of kernel iterators, checks +for the soundness of free operations, analysis of locking behavior, and further +tests known to help keep consistent kernel usage. See the +Documentation/dev-tools/coccinelle.rst documentation page for details. + +Beware, though, that static analysis tools suffer from **false positives**. +Errors and warns need to be evaluated carefully before attempting to fix them. -- cgit From a32d5c0fc12b1dec44ddd97434cbb0203c7e60e5 Mon Sep 17 00:00:00 2001 From: Marcelo Schmitt Date: Wed, 30 Mar 2022 18:49:59 -0300 Subject: Documentation: dev-tools: Enhance static analysis section with discussion Enhance the static analysis tools section with a discussion on when to use each of them. This was mainly taken from Dan Carpenter and Julia Lawall's comments on a previous documentation patch for static analysis tools. Lore: https://lore.kernel.org/linux-doc/20220329090911.GX3293@kadam/T/#mb97770c8e938095aadc3ee08f4ac7fe32ae386e6 Signed-off-by: Marcelo Schmitt Acked-by: David Gow Cc: Dan Carpenter Cc: Julia Lawall Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/testing-overview.rst | 32 ++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'Documentation') diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst index b5e02dd3fd94..0aaf6ea53608 100644 --- a/Documentation/dev-tools/testing-overview.rst +++ b/Documentation/dev-tools/testing-overview.rst @@ -146,3 +146,35 @@ Documentation/dev-tools/coccinelle.rst documentation page for details. Beware, though, that static analysis tools suffer from **false positives**. Errors and warns need to be evaluated carefully before attempting to fix them. + +When to use Sparse and Smatch +----------------------------- + +Sparse does type checking, such as verifying that annotated variables do not +cause endianness bugs, detecting places that use ``__user`` pointers improperly, +and analyzing the compatibility of symbol initializers. + +Smatch does flow analysis and, if allowed to build the function database, it +also does cross function analysis. Smatch tries to answer questions like where +is this buffer allocated? How big is it? Can this index be controlled by the +user? Is this variable larger than that variable? + +It's generally easier to write checks in Smatch than it is to write checks in +Sparse. Nevertheless, there are some overlaps between Sparse and Smatch checks. + +Strong points of Smatch and Coccinelle +-------------------------------------- + +Coccinelle is probably the easiest for writing checks. It works before the +pre-processor so it's easier to check for bugs in macros using Coccinelle. +Coccinelle also creates patches for you, which no other tool does. + +For example, with Coccinelle you can do a mass conversion from +``kmalloc(x * size, GFP_KERNEL)`` to ``kmalloc_array(x, size, GFP_KERNEL)``, and +that's really useful. If you just created a Smatch warning and try to push the +work of converting on to the maintainers they would be annoyed. You'd have to +argue about each warning if can really overflow or not. + +Coccinelle does no analysis of variable values, which is the strong point of +Smatch. On the other hand, Coccinelle allows you to do simple things in a simple +way. -- cgit From f35cf1a59e9a5afd1ce8f020830a18adf2d86db3 Mon Sep 17 00:00:00 2001 From: Konstantin Ryabitsev Date: Tue, 29 Mar 2022 15:51:17 -0400 Subject: Documentation: kernel-hacking: minor edits for style Rusty's kernel-hacking guides provide important information, however they are written in a narrative style that some readers may interpret as off-putting. Since the goal is to make kernel documentation accessible to as many new developers as possible, it's best to avoid the turns of phrase that require a specific cultural context to properly understand. Signed-off-by: Konstantin Ryabitsev Signed-off-by: Jonathan Corbet --- Documentation/kernel-hacking/hacking.rst | 36 ++++++++++++++++---------------- Documentation/kernel-hacking/locking.rst | 5 +---- 2 files changed, 19 insertions(+), 22 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-hacking/hacking.rst b/Documentation/kernel-hacking/hacking.rst index 55bd37a2efb0..ebd9d90882ea 100644 --- a/Documentation/kernel-hacking/hacking.rst +++ b/Documentation/kernel-hacking/hacking.rst @@ -112,8 +112,7 @@ time, although different tasklets can run simultaneously. .. warning:: The name 'tasklet' is misleading: they have nothing to do with - 'tasks', and probably more to do with some bad vodka Alexey - Kuznetsov had at the time. + 'tasks'. You can tell you are in a softirq (or tasklet) using the :c:func:`in_softirq()` macro (``include/linux/preempt.h``). @@ -290,8 +289,8 @@ userspace. Unlike :c:func:`put_user()` and :c:func:`get_user()`, they return the amount of uncopied data (ie. 0 still means success). -[Yes, this moronic interface makes me cringe. The flamewar comes up -every year or so. --RR.] +[Yes, this objectionable interface makes me cringe. The flamewar comes +up every year or so. --RR.] The functions may sleep implicitly. This should never be called outside user context (it makes no sense), with interrupts disabled, or a @@ -645,8 +644,9 @@ names in development kernels; this is not done just to keep everyone on their toes: it reflects a fundamental change (eg. can no longer be called with interrupts on, or does extra checks, or doesn't do checks which were caught before). Usually this is accompanied by a fairly -complete note to the linux-kernel mailing list; search the archive. -Simply doing a global replace on the file usually makes things **worse**. +complete note to the appropriate kernel development mailing list; search +the archives. Simply doing a global replace on the file usually makes +things **worse**. Initializing structure members ------------------------------ @@ -723,14 +723,14 @@ Putting Your Stuff in the Kernel In order to get your stuff into shape for official inclusion, or even to make a neat patch, there's administrative work to be done: -- Figure out whose pond you've been pissing in. Look at the top of the - source files, inside the ``MAINTAINERS`` file, and last of all in the - ``CREDITS`` file. You should coordinate with this person to make sure - you're not duplicating effort, or trying something that's already - been rejected. +- Figure out who are the owners of the code you've been modifying. Look + at the top of the source files, inside the ``MAINTAINERS`` file, and + last of all in the ``CREDITS`` file. You should coordinate with these + people to make sure you're not duplicating effort, or trying something + that's already been rejected. - Make sure you put your name and EMail address at the top of any files - you create or mangle significantly. This is the first place people + Make sure you put your name and email address at the top of any files + you create or modify significantly. This is the first place people will look when they find a bug, or when **they** want to make a change. - Usually you want a configuration option for your kernel hack. Edit @@ -748,11 +748,11 @@ make a neat patch, there's administrative work to be done: can usually just add a "obj-$(CONFIG_xxx) += xxx.o" line. The syntax is documented in ``Documentation/kbuild/makefiles.rst``. -- Put yourself in ``CREDITS`` if you've done something noteworthy, - usually beyond a single file (your name should be at the top of the - source files anyway). ``MAINTAINERS`` means you want to be consulted - when changes are made to a subsystem, and hear about bugs; it implies - a more-than-passing commitment to some part of the code. +- Put yourself in ``CREDITS`` if you consider what you've done + noteworthy, usually beyond a single file (your name should be at the + top of the source files anyway). ``MAINTAINERS`` means you want to be + consulted when changes are made to a subsystem, and hear about bugs; + it implies a more-than-passing commitment to some part of the code. - Finally, don't forget to read ``Documentation/process/submitting-patches.rst`` and possibly diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst index 4cbd50edf277..6805ae6e86e6 100644 --- a/Documentation/kernel-hacking/locking.rst +++ b/Documentation/kernel-hacking/locking.rst @@ -941,8 +941,7 @@ lock. A classic problem here is when you provide callbacks or hooks: if you call these with the lock held, you risk simple deadlock, or a deadly -embrace (who knows what the callback will do?). Remember, the other -programmers are out to get you, so don't do this. +embrace (who knows what the callback will do?). Overzealous Prevention Of Deadlocks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -952,8 +951,6 @@ grabs a read lock, searches a list, fails to find what it wants, drops the read lock, grabs a write lock and inserts the object has a race condition. -If you don't see why, please stay away from my code. - Racing Timers: A Kernel Pastime ------------------------------- -- cgit From 980c3799c5000d1d1d007b1d51b7fb1bb9745a14 Mon Sep 17 00:00:00 2001 From: Bagas Sanjaya Date: Tue, 29 Mar 2022 11:52:34 +0700 Subject: Documentation: kernel-doc: Promote two chapter headings to page title Promote "Writing kernel-doc comments" heading to page title, in accordance to kernel documentation guidelines. Also promote "Including kernel-doc comments" heading because both headings deserve their own chapters in PDF output. There is no differences in the resulting output except formatting semantics. Cc: Jonathan Corbet Cc: "David S. Miller" Cc: Greg Kroah-Hartman Cc: Tony Nguyen Cc: Vinod Koul Cc: Daniel Borkmann Cc: Mauro Carvalho Chehab Cc: Akira Yokosawa Cc: "Rafael J. Wysocki" Cc: Jens Axboe Cc: linux-kernel@vger.kernel.org Signed-off-by: Bagas Sanjaya Signed-off-by: Jonathan Corbet --- Documentation/doc-guide/kernel-doc.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/doc-guide/kernel-doc.rst b/Documentation/doc-guide/kernel-doc.rst index 79aaa55d6bcf..a7cb2afd7990 100644 --- a/Documentation/doc-guide/kernel-doc.rst +++ b/Documentation/doc-guide/kernel-doc.rst @@ -1,3 +1,4 @@ +=========================== Writing kernel-doc comments =========================== @@ -436,6 +437,7 @@ The title following ``DOC:`` acts as a heading within the source file, but also as an identifier for extracting the documentation comment. Thus, the title must be unique within the file. +============================= Including kernel-doc comments ============================= -- cgit From 452c4915c18ce26b08a0e108513e803a196babfd Mon Sep 17 00:00:00 2001 From: Bagas Sanjaya Date: Tue, 29 Mar 2022 11:52:35 +0700 Subject: Documentation: sphinx: replace "Introduction" chapter heading with page title Replace first chapter heading ("Introduction") with page title named "Using Sphinx for kernel documentation". This way, the first-level TOC for doc-guide contains title instead of chapter headings for this page. Cc: Jonathan Corbet Cc: "David S. Miller" Cc: Greg Kroah-Hartman Cc: Tony Nguyen Cc: Vinod Koul Cc: Daniel Borkmann Cc: Mauro Carvalho Chehab Cc: Akira Yokosawa Cc: "Rafael J. Wysocki" Cc: Jens Axboe Cc: linux-kernel@vger.kernel.org Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Bagas Sanjaya Signed-off-by: Jonathan Corbet --- Documentation/doc-guide/sphinx.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst index bb36f18ae9ac..2ff1ab4158d4 100644 --- a/Documentation/doc-guide/sphinx.rst +++ b/Documentation/doc-guide/sphinx.rst @@ -1,7 +1,8 @@ .. _sphinxdoc: -Introduction -============ +===================================== +Using Sphinx for kernel documentation +===================================== The Linux kernel uses `Sphinx`_ to generate pretty documentation from `reStructuredText`_ files under ``Documentation``. To build the documentation in -- cgit From c57f3dbc3bd9ae3c4cf72c9937de205458815c8d Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 20:48:33 +0800 Subject: docs/zh_CN/damon: update outdated term 'regions update interval' MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since 072fd1b47215("Docs/damon: update outdated term 'regions update interval'") use update interval,zh_CN should use 更新间隔, so let's sync update. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst | 6 +++--- Documentation/translations/zh_CN/vm/damon/design.rst | 7 ++++--- 2 files changed, 7 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst index 5d7533347216..10b9ac7664d3 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst @@ -46,7 +46,7 @@ DAMON导出了八个文件, ``attrs``, ``target_ids``, ``init_regions``, 属性 ---- -用户可以通过读取和写入 ``attrs`` 文件获得和设置 ``采样间隔`` 、 ``聚集间隔`` 、 ``区域更新间隔`` +用户可以通过读取和写入 ``attrs`` 文件获得和设置 ``采样间隔`` 、 ``聚集间隔`` 、 ``更新间隔`` 以及监测目标区域的最小/最大数量。要详细了解监测属性，请参考 `:doc:/vm/damon/design` 。例如， 下面的命令将这些值设置为5ms、100ms、1000ms、10和1000，然后再次检查:: @@ -108,8 +108,8 @@ DAMON导出了八个文件, ``attrs``, ``target_ids``, ``init_regions``, 1 20 40 1 50 100" > init_regions -请注意，这只是设置了初始的监测目标区域。在虚拟内存监测的情况下，DAMON会在一个 ``区域更新间隔`` -后自动更新区域的边界。因此，在这种情况下，如果用户不希望更新的话，应该把 ``区域的更新间隔`` 设 +请注意，这只是设置了初始的监测目标区域。在虚拟内存监测的情况下，DAMON会在一个 ``更新间隔`` +后自动更新区域的边界。因此，在这种情况下，如果用户不希望更新的话，应该把 ``更新间隔`` 设 置得足够大。 diff --git a/Documentation/translations/zh_CN/vm/damon/design.rst b/Documentation/translations/zh_CN/vm/damon/design.rst index 05f66c02740a..46128b77c2b3 100644 --- a/Documentation/translations/zh_CN/vm/damon/design.rst +++ b/Documentation/translations/zh_CN/vm/damon/design.rst @@ -77,7 +77,7 @@ DAMON目前为物理和虚拟地址空间提供了基元的实现。下面两个 ======================== 下面四个部分分别描述了DAMON的核心机制和五个监测属性，即 ``采样间隔`` 、 ``聚集间隔`` 、 -``区域更新间隔`` 、 ``最小区域数`` 和 ``最大区域数`` 。 +``更新间隔`` 、 ``最小区域数`` 和 ``最大区域数`` 。 访问频率监测 @@ -135,5 +135,6 @@ DAMON的输出显示了在给定的时间内哪些页面的访问频率是多少 监测目标地址范围可以动态改变。例如，虚拟内存可以动态地被映射和解映射。物理内存可以被 热插拔。 -由于在某些情况下变化可能相当频繁，DAMON检查动态内存映射的变化，并仅在用户指定的时间 -间隔（ ``区域更新间隔`` ）内将其应用于抽象的目标区域。 +由于在某些情况下变化可能相当频繁，DAMON允许监控操作检查动态变化，包括内存映射变化， +并仅在用户指定的时间间隔（ ``更新间隔`` ）中的每个时间段，将其应用于监控操作相关的 +数据结构，如抽象的监控目标内存区。 \ No newline at end of file -- cgit From b22fe865dbf4fba1bd8f8d388ffa5bdc8cc69751 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 20:48:34 +0800 Subject: docs/zh_CN/damon: add sysfs interface Since 3d029480f24e("Docs/admin-guide/mm/damon/usage: document DAMON sysfs interface") add sysfs interface, let's sync update. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- .../zh_CN/admin-guide/mm/damon/usage.rst | 285 ++++++++++++++++++++- 1 file changed, 278 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst index 10b9ac7664d3..eee0e8c5c368 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst @@ -13,7 +13,7 @@ 详细用法 ======== -DAMON 为不同的用户提供了下面三种接口。 +DAMON 为不同的用户提供了下面这些接口。 - *DAMON用户空间工具。* `这 `_ 为有这特权的人， 如系统管理员，希望有一个刚好 @@ -21,19 +21,290 @@ DAMON 为不同的用户提供了下面三种接口。 使用它，用户可以以人性化的方式使用DAMON的主要功能。不过，它可能不会为特殊情况进行高度调整。 它同时支持虚拟和物理地址空间的监测。更多细节，请参考它的 `使用文档 `_。 -- *debugfs接口。* - :ref:`这 ` 是为那些希望更高级的使用DAMON的特权用户空间程序员准备的。 - 使用它，用户可以通过读取和写入特殊的debugfs文件来使用DAMON的主要功能。因此，你可以编写和使 - 用你个性化的DAMON debugfs包装程序，代替你读/写debugfs文件。 `DAMON用户空间工具 +- *sysfs接口。* + :ref:`这 ` 是为那些希望更高级的使用DAMON的特权用户空间程序员准备的。 + 使用它，用户可以通过读取和写入特殊的sysfs文件来使用DAMON的主要功能。因此，你可以编写和使 + 用你个性化的DAMON sysfs包装程序，代替你读/写sysfs文件。 `DAMON用户空间工具 `_ 就是这种程序的一个例子 它同时支持虚拟和物理地址 空间的监测。注意，这个界面只提供简单的监测结果 :ref:`统计 `。对于详细的监测 结果，DAMON提供了一个:ref:`跟踪点 `。 - +- *debugfs interface.* + :ref:`这 ` 几乎与:ref:`sysfs interface ` 接 + 口相同。这将在下一个LTS内核发布后被移除，所以用户应该转移到 + :ref:`sysfs interface `。 - *内核空间编程接口。* - :doc:`This ` 这是为内核空间程序员准备的。使用它，用户可以通过为你编写内 + :doc:`这 ` 这是为内核空间程序员准备的。使用它，用户可以通过为你编写内 核空间的DAMON应用程序，最灵活有效地利用DAMON的每一个功能。你甚至可以为各种地址空间扩展DAMON。 详细情况请参考接口 :doc:`文件 `。 +sysfs接口 +========= +DAMON的sysfs接口是在定义 ``CONFIG_DAMON_SYSFS`` 时建立的。它在其sysfs目录下创建多 +个目录和文件， ``/kernel/mm/damon/`` 。你可以通过对该目录下的文件进行写入和 +读取来控制DAMON。 + +对于一个简短的例子，用户可以监测一个给定工作负载的虚拟地址空间，如下所示:: + + # cd /sys/kernel/mm/damon/admin/ + # echo 1 > kdamonds/nr && echo 1 > kdamonds/0/contexts/nr + # echo vaddr > kdamonds/0/contexts/0/operations + # echo 1 > kdamonds/0/contexts/0/targets/nr + # echo $(pidof ) > kdamonds/0/contexts/0/targets/0/pid + # echo on > kdamonds/0/state + +文件层次结构 +------------ + +DAMON sysfs接口的文件层次结构如下图所示。在下图中，父子关系用缩进表示，每个目录有 +``/`` 后缀，每个目录中的文件用逗号（","）分开。 :: + + /sys/kernel/mm/damon/admin + │ kdamonds/nr_kdamonds + │ │ 0/state,pid + │ │ │ contexts/nr_contexts + │ │ │ │ 0/operations + │ │ │ │ │ monitoring_attrs/ + │ │ │ │ │ │ intervals/sample_us,aggr_us,update_us + │ │ │ │ │ │ nr_regions/min,max + │ │ │ │ │ targets/nr_targets + │ │ │ │ │ │ 0/pid_target + │ │ │ │ │ │ │ regions/nr_regions + │ │ │ │ │ │ │ │ 0/start,end + │ │ │ │ │ │ │ │ ... + │ │ │ │ │ │ ... + │ │ │ │ │ schemes/nr_schemes + │ │ │ │ │ │ 0/action + │ │ │ │ │ │ │ access_pattern/ + │ │ │ │ │ │ │ │ sz/min,max + │ │ │ │ │ │ │ │ nr_accesses/min,max + │ │ │ │ │ │ │ │ age/min,max + │ │ │ │ │ │ │ quotas/ms,bytes,reset_interval_ms + │ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil + │ │ │ │ │ │ │ watermarks/metric,interval_us,high,mid,low + │ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds + │ │ │ │ │ │ ... + │ │ │ │ ... + │ │ ... + +根 +-- + +DAMON sysfs接口的根是 ``/kernel/mm/damon/`` ，它有一个名为 ``admin`` 的 +目录。该目录包含特权用户空间程序控制DAMON的文件。拥有根权限的用户空间工具或deamons可以 +使用这个目录。 + +kdamonds/ +--------- + +与监测相关的信息包括请求规格和结果被称为DAMON上下文。DAMON用一个叫做kdamond的内核线程 +执行每个上下文，多个kdamonds可以并行运行。 + +在 ``admin`` 目录下，有一个目录，即``kdamonds``，它有控制kdamonds的文件存在。在开始 +时，这个目录只有一个文件，``nr_kdamonds``。向该文件写入一个数字（``N``），就会创建名为 +``0`` 到 ``N-1`` 的子目录数量。每个目录代表每个kdamond。 + +kdamonds// +------------- + +在每个kdamond目录中，存在两个文件（``state`` 和 ``pid`` ）和一个目录( ``contexts`` )。 + +读取 ``state`` 时，如果kdamond当前正在运行，则返回 ``on`` ，如果没有运行则返回 ``off`` 。 +写入 ``on`` 或 ``off`` 使kdamond处于状态。向 ``state`` 文件写 ``update_schemes_stats`` ， +更新kdamond的每个基于DAMON的操作方案的统计文件的内容。关于统计信息的细节，请参考 +:ref:`stats section `. + +如果状态为 ``on``，读取 ``pid`` 显示kdamond线程的pid。 + +``contexts`` 目录包含控制这个kdamond要执行的监测上下文的文件。 + +kdamonds//contexts/ +---------------------- + +在开始时，这个目录只有一个文件，即 ``nr_contexts`` 。向该文件写入一个数字( ``N`` )，就会创 +建名为``0`` 到 ``N-1`` 的子目录数量。每个目录代表每个监测背景。目前，每个kdamond只支持 +一个上下文，所以只有 ``0`` 或 ``1`` 可以被写入文件。 + +contexts// +------------- + +在每个上下文目录中，存在一个文件(``operations``)和三个目录(``monitoring_attrs``, +``targets``, 和 ``schemes``)。 + +DAMON支持多种类型的监测操作，包括对虚拟地址空间和物理地址空间的监测。你可以通过向文件 +中写入以下关键词之一，并从文件中读取，来设置和获取DAMON将为上下文使用何种类型的监测操作。 + + - vaddr: 监测特定进程的虚拟地址空间 + - paddr: 监视系统的物理地址空间 + +contexts//monitoring_attrs/ +------------------------------ + +用于指定监测属性的文件，包括所需的监测质量和效率，都在 ``monitoring_attrs`` 目录中。 +具体来说，这个目录下有两个目录，即 ``intervals`` 和 ``nr_regions`` 。 + +在 ``intervals`` 目录下，存在DAMON的采样间隔(``sample_us``)、聚集间隔(``aggr_us``) +和更新间隔(``update_us``)三个文件。你可以通过写入和读出这些文件来设置和获取微秒级的值。 + +在 ``nr_regions`` 目录下，有两个文件分别用于DAMON监测区域的下限和上限（``min`` 和 ``max`` ）， +这两个文件控制着监测的开销。你可以通过向这些文件的写入和读出来设置和获取这些值。 + +关于间隔和监测区域范围的更多细节，请参考设计文件 (:doc:`/vm/damon/design`)。 + +contexts//targets/ +--------------------- + +在开始时，这个目录只有一个文件 ``nr_targets`` 。向该文件写入一个数字(``N``)，就可以创建 +名为 ``0`` 到 ``N-1`` 的子目录的数量。每个目录代表每个监测目标。 + +targets// +------------ + +在每个目标目录中，存在一个文件(``pid_target``)和一个目录(``regions``)。 + +如果你把 ``vaddr`` 写到 ``contexts//operations`` 中，每个目标应该是一个进程。你 +可以通过将进程的pid写到 ``pid_target`` 文件中来指定DAMON的进程。 + +targets//regions +------------------- + +当使用 ``vaddr`` 监测操作集时（ ``vaddr`` 被写入 ``contexts//operations`` 文 +件），DAMON自动设置和更新监测目标区域，这样就可以覆盖目标进程的整个内存映射。然而，用户可 +能希望将初始监测区域设置为特定的地址范围。 + +相反，当使用 ``paddr`` 监测操作集时，DAMON不会自动设置和更新监测目标区域（ ``paddr`` +被写入 ``contexts//operations`` 中）。因此，在这种情况下，用户应该自己设置监测目标 +区域。 + +在这种情况下，用户可以按照自己的意愿明确设置初始监测目标区域，将适当的值写入该目录下的文件。 + +开始时，这个目录只有一个文件， ``nr_regions`` 。向该文件写入一个数字(``N``)，就可以创 +建名为 ``0`` 到 ``N-1`` 的子目录。每个目录代表每个初始监测目标区域。 + +regions// +------------ + +在每个区域目录中，你会发现两个文件（ ``start`` 和 ``end`` ）。你可以通过向文件写入 +和从文件中读出，分别设置和获得初始监测目标区域的起始和结束地址。 + +contexts//schemes/ +--------------------- + +对于一版的基于DAMON的数据访问感知的内存管理优化，用户通常希望系统对特定访问模式的内存区 +域应用内存管理操作。DAMON从用户那里接收这种形式化的操作方案，并将这些方案应用于目标内存 +区域。用户可以通过读取和写入这个目录下的文件来获得和设置这些方案。 + +在开始时，这个目录只有一个文件，``nr_schemes``。向该文件写入一个数字(``N``)，就可以 +创建名为``0``到``N-1``的子目录的数量。每个目录代表每个基于DAMON的操作方案。 + +schemes// +------------ + +在每个方案目录中，存在四个目录(``access_pattern``, ``quotas``,``watermarks``, +和 ``stats``)和一个文件(``action``)。 + +``action`` 文件用于设置和获取你想应用于具有特定访问模式的内存区域的动作。可以写入文件 +和从文件中读取的关键词及其含义如下。 + + - ``willneed``: 对有 ``MADV_WILLNEED`` 的区域调用 ``madvise()`` 。 + - ``cold``: 对具有 ``MADV_COLD`` 的区域调用 ``madvise()`` 。 + - ``pageout``: 为具有 ``MADV_PAGEOUT`` 的区域调用 ``madvise()`` 。 + - ``hugepage``: 为带有 ``MADV_HUGEPAGE`` 的区域调用 ``madvise()`` 。 + - ``nohugepage``: 为带有 ``MADV_NOHUGEPAGE`` 的区域调用 ``madvise()``。 + - ``stat``: 什么都不做，只计算统计数据 + +schemes//access_pattern/ +--------------------------- + +每个基于DAMON的操作方案的目标访问模式由三个范围构成，包括以字节为单位的区域大小、每个 +聚合区间的监测访问次数和区域年龄的聚合区间数。 + +在 ``access_pattern`` 目录下，存在三个目录（ ``sz``, ``nr_accesses``, 和 ``age`` ）， +每个目录有两个文件（``min`` 和 ``max`` ）。你可以通过向 ``sz``, ``nr_accesses``, 和 +``age`` 目录下的 ``min`` 和 ``max`` 文件分别写入和读取来设置和获取给定方案的访问模式。 + +schemes//quotas/ +------------------- + +每个 ``动作`` 的最佳 ``目标访问模式`` 取决于工作负载，所以不容易找到。更糟糕的是，将某些动作 +的方案设置得过于激进会造成严重的开销。为了避免这种开销，用户可以为每个方案限制时间和大小配额。 +具体来说，用户可以要求DAMON尽量只使用特定的时间（``时间配额``）来应用行动，并且在给定的时间间 +隔（``重置间隔``）内，只对具有目标访问模式的内存区域应用行动，而不使用特定数量（``大小配额``）。 + +当预计超过配额限制时，DAMON会根据 ``目标访问模式`` 的大小、访问频率和年龄，对找到的内存区域 +进行优先排序。为了进行个性化的优先排序，用户可以为这三个属性设置权重。 + +在 ``quotas`` 目录下，存在三个文件（``ms``, ``bytes``, ``reset_interval_ms``）和一个 +目录(``weights``)，其中有三个文件(``sz_permil``, ``nr_accesses_permil``, 和 +``age_permil``)。 + +你可以设置以毫秒为单位的 ``时间配额`` ，以字节为单位的 ``大小配额`` ，以及以毫秒为单位的 ``重 +置间隔`` ，分别向这三个文件写入数值。你还可以通过向 ``weights`` 目录下的三个文件写入数值来设 +置大小、访问频率和年龄的优先权，单位为千分之一。 + +schemes//watermarks/ +----------------------- + +为了便于根据系统状态激活和停用每个方案，DAMON提供了一个称为水位的功能。该功能接收五个值，称为 +``度量`` 、``间隔`` 、``高`` 、``中`` 、``低`` 。``度量值`` 是指可以测量的系统度量值，如 +自由内存比率。如果系统的度量值 ``高`` 于memoent的高值或 ``低`` 于低值，则该方案被停用。如果 +该值低于 ``中`` ，则该方案被激活。 + +在水位目录下，存在五个文件(``metric``, ``interval_us``,``high``, ``mid``, and ``low``) +用于设置每个值。你可以通过向这些文件的写入来分别设置和获取这五个值。 + +可以写入 ``metric`` 文件的关键词和含义如下。 + + - none: 忽略水位 + - free_mem_rate: 系统的自由内存率（千分比）。 + +``interval`` 应以微秒为单位写入。 + +schemes//stats/ +------------------ + +DAMON统计每个方案被尝试应用的区域的总数量和字节数，每个方案被成功应用的区域的两个数字，以及 +超过配额限制的总数量。这些统计数据可用于在线分析或调整方案。 + +可以通过读取 ``stats`` 目录下的文件(``nr_tried``, ``sz_tried``, ``nr_applied``, +``sz_applied``, 和 ``qt_exceeds``)）分别检索这些统计数据。这些文件不是实时更新的，所以 +你应该要求DAMON sysfs接口通过在相关的 ``kdamonds//state`` 文件中写入一个特殊的关键字 +``update_schemes_stats`` 来更新统计信息的文件内容。 + +用例 +~~~~ + +下面的命令应用了一个方案：”如果一个大小为[4KiB, 8KiB]的内存区域在[10, 20]的聚合时间间隔内 +显示出每一个聚合时间间隔[0, 5]的访问量，请分页该区域。对于分页，每秒最多只能使用10ms，而且每 +秒分页不能超过1GiB。在这一限制下，首先分页出具有较长年龄的内存区域。另外，每5秒钟检查一次系统 +的可用内存率，当可用内存率低于50%时开始监测和分页，但如果可用内存率大于60%，或低于30%，则停 +止监测。“ :: + + # cd /kernel/mm/damon/admin + # # populate directories + # echo 1 > kdamonds/nr_kdamonds; echo 1 > kdamonds/0/contexts/nr_contexts; + # echo 1 > kdamonds/0/contexts/0/schemes/nr_schemes + # cd kdamonds/0/contexts/0/schemes/0 + # # set the basic access pattern and the action + # echo 4096 > access_patterns/sz/min + # echo 8192 > access_patterns/sz/max + # echo 0 > access_patterns/nr_accesses/min + # echo 5 > access_patterns/nr_accesses/max + # echo 10 > access_patterns/age/min + # echo 20 > access_patterns/age/max + # echo pageout > action + # # set quotas + # echo 10 > quotas/ms + # echo $((1024*1024*1024)) > quotas/bytes + # echo 1000 > quotas/reset_interval_ms + # # set watermark + # echo free_mem_rate > watermarks/metric + # echo 5000000 > watermarks/interval_us + # echo 600 > watermarks/high + # echo 500 > watermarks/mid + # echo 300 > watermarks/low + +请注意，我们强烈建议使用用户空间的工具，如 `damo `_ ， +而不是像上面那样手动读写文件。以上只是一个例子。 debugfs接口 =========== -- cgit From 712ca54c5387d13853978776dbfb7646906ee969 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 20:48:35 +0800 Subject: docs/zh_CN/damon: typo fix The word in original doc is: 'enabled', not 'enable'. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst index 9e541578f38d..1500bdbf338a 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst @@ -53,8 +53,8 @@ DAMON_RECLAIM找到在特定时间内没有被访问的内存区域并分页。 下面是每个参数的描述。 -enable ------- +enabled +------- 启用或禁用DAMON_RECLAIM。 -- cgit From 9859b277bffe78e070bfdcf2be19520160e3a619 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 17:59:43 +0800 Subject: docs/zh_CN: add vm frontswap translation Translate .../vm/_free_page_reporting.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/frontswap.rst | 196 ++++++++++++++++++++++ Documentation/translations/zh_CN/vm/index.rst | 2 +- 2 files changed, 197 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/frontswap.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/frontswap.rst b/Documentation/translations/zh_CN/vm/frontswap.rst new file mode 100644 index 000000000000..3eb07870e2ef --- /dev/null +++ b/Documentation/translations/zh_CN/vm/frontswap.rst @@ -0,0 +1,196 @@ +:Original: Documentation/vm/_free_page_reporting.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + +========= +Frontswap +========= + +Frontswap为交换页提供了一个 “transcendent memory” 的接口。在一些环境中，由 +于交换页被保存在RAM（或类似RAM的设备）中，而不是交换磁盘，因此可以获得巨大的性能 +节省（提高）。 + +.. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/ + +Frontswap之所以这么命名，是因为它可以被认为是与swap设备的“back”存储相反。存 +储器被认为是一个同步并发安全的面向页面的“伪RAM设备”，符合transcendent memory +（如Xen的“tmem”，或内核内压缩内存，又称“zcache”，或未来的类似RAM的设备）的要 +求；这个伪RAM设备不能被内核直接访问或寻址，其大小未知且可能随时间变化。驱动程序通过 +调用frontswap_register_ops将自己与frontswap链接起来，以适当地设置frontswap_ops +的功能，它提供的功能必须符合某些策略，如下所示: + +一个 “init” 将设备准备好接收与指定的交换设备编号（又称“类型”）相关的frontswap +交换页。一个 “store” 将把该页复制到transcendent memory，并与该页的类型和偏移 +量相关联。一个 “load” 将把该页，如果找到的话，从transcendent memory复制到内核 +内存，但不会从transcendent memory中删除该页。一个 “invalidate_page” 将从 +transcendent memory中删除该页，一个 “invalidate_area” 将删除所有与交换类型 +相关的页（例如，像swapoff）并通知 “device” 拒绝进一步存储该交换类型。 + +一旦一个页面被成功存储，在该页面上的匹配加载通常会成功。因此，当内核发现自己处于需 +要交换页面的情况时，它首先尝试使用frontswap。如果存储的结果是成功的，那么数据就已 +经成功的保存到了transcendent memory中，并且避免了磁盘写入，如果后来再读回数据， +也避免了磁盘读取。如果存储返回失败，transcendent memory已经拒绝了该数据，且该页 +可以像往常一样被写入交换空间。 + +请注意，如果一个页面被存储，而该页面已经存在于transcendent memory中（一个 “重复” +的存储），要么存储成功，数据被覆盖，要么存储失败，该页面被废止。这确保了旧的数据永远 +不会从frontswap中获得。 + +如果配置正确，对frontswap的监控是通过 `/sys/kernel/debug/frontswap` 目录下的 +debugfs完成的。frontswap的有效性可以通过以下方式测量（在所有交换设备中）: + +``failed_stores`` + 有多少次存储的尝试是失败的 + +``loads`` + 尝试了多少次加载（应该全部成功） + +``succ_stores`` + 有多少次存储的尝试是成功的 + +``invalidates`` + 尝试了多少次作废 + +后台实现可以提供额外的指标。 + +经常问到的问题 +============== + +* 价值在哪里? + +当一个工作负载开始交换时，性能就会下降。Frontswap通过提供一个干净的、动态的接口来 +读取和写入交换页到 “transcendent memory”，从而大大增加了许多这样的工作负载的性 +能，否则内核是无法直接寻址的。当数据被转换为不同的形式和大小（比如压缩）或者被秘密 +移动（对于一些类似RAM的设备来说，这可能对写平衡很有用）时，这个接口是理想的。交换 +页（和被驱逐的页面缓存页）是这种比RAM慢但比磁盘快得多的“伪RAM设备”的一大用途。 + +Frontswap对内核的影响相当小，为各种系统配置中更动态、更灵活的RAM利用提供了巨大的 +灵活性： + +在单一内核的情况下，又称“zcache”，页面被压缩并存储在本地内存中，从而增加了可以安 +全保存在RAM中的匿名页面总数。Zcache本质上是用压缩/解压缩的CPU周期换取更好的内存利 +用率。Benchmarks测试显示，当内存压力较低时，几乎没有影响，而在高内存压力下的一些 +工作负载上，则有明显的性能改善（25%以上）。 + +“RAMster” 在zcache的基础上增加了对集群系统的 “peer-to-peer” transcendent memory +的支持。Frontswap页面像zcache一样被本地压缩，但随后被“remotified” 到另一个系 +统的RAM。这使得RAM可以根据需要动态地来回负载平衡，也就是说，当系统A超载时，它可以 +交换到系统B，反之亦然。RAMster也可以被配置成一个内存服务器，因此集群中的许多服务器 +可以根据需要动态地交换到配置有大量内存的单一服务器上......而不需要预先配置每个客户 +有多少内存可用 + +在虚拟情况下，虚拟化的全部意义在于统计地将物理资源在多个虚拟机的不同需求之间进行复 +用。对于RAM来说，这真的很难做到，而且在不改变内核的情况下，要做好这一点的努力基本上 +是失败的（除了一些广为人知的特殊情况下的工作负载）。具体来说，Xen Transcendent Memory +后端允许管理器拥有的RAM “fallow”，不仅可以在多个虚拟机之间进行“time-shared”， +而且页面可以被压缩和重复利用，以优化RAM的利用率。当客户操作系统被诱导交出未充分利用 +的RAM时（如 “selfballooning”），突然出现的意外内存压力可能会导致交换；frontswap +允许这些页面被交换到管理器RAM中或从管理器RAM中交换（如果整体主机系统内存条件允许）， +从而减轻计划外交换可能带来的可怕的性能影响。 + +一个KVM的实现正在进行中，并且已经被RFC'ed到lkml。而且，利用frontswap，对NVM作为 +内存扩展技术的调查也在进行中。 + +* 当然，在某些情况下可能有性能上的优势，但frontswap的空间/时间开销是多少？ + +如果 CONFIG_FRONTSWAP 被禁用，每个 frontswap 钩子都会编译成空，唯一的开销是每 +个 swapon'ed swap 设备的几个额外字节。如果 CONFIG_FRONTSWAP 被启用，但没有 +frontswap的 “backend” 寄存器，每读或写一个交换页就会有一个额外的全局变量，而不 +是零。如果 CONFIG_FRONTSWAP 被启用，并且有一个frontswap的backend寄存器，并且 +后端每次 “store” 请求都失败（即尽管声称可能，但没有提供内存），CPU 的开销仍然可以 +忽略不计 - 因为每次frontswap失败都是在交换页写到磁盘之前，系统很可能是 I/O 绑定 +的，无论如何使用一小部分的 CPU 都是不相关的。 + +至于空间，如果CONFIG_FRONTSWAP被启用，并且有一个frontswap的backend注册，那么 +每个交换设备的每个交换页都会被分配一个比特。这是在内核已经为每个交换设备的每个交换 +页分配的8位（在2.6.34之前是16位）上增加的。(Hugh Dickins观察到，frontswap可能 +会偷取现有的8个比特，但是我们以后再来担心这个小的优化问题)。对于标准的4K页面大小的 +非常大的交换盘（这很罕见），这是每32GB交换盘1MB开销。 + +当交换页存储在transcendent memory中而不是写到磁盘上时，有一个副作用，即这可能会 +产生更多的内存压力，有可能超过其他的优点。一个backend，比如zcache，必须实现策略 +来仔细（但动态地）管理内存限制，以确保这种情况不会发生。 + +* 好吧，那就用内核骇客能理解的术语来快速概述一下这个frontswap补丁的作用如何？ + +我们假设在内核初始化过程中，一个frontswap 的 “backend” 已经注册了；这个注册表 +明这个frontswap 的 “backend” 可以访问一些不被内核直接访问的“内存”。它到底提 +供了多少内存是完全动态和随机的。 + +每当一个交换设备被交换时，就会调用frontswap_init()，把交换设备的编号（又称“类 +型”）作为一个参数传给它。这就通知了frontswap，以期待 “store” 与该号码相关的交 +换页的尝试。 + +每当交换子系统准备将一个页面写入交换设备时（参见swap_writepage()），就会调用 +frontswap_store。Frontswap与frontswap backend协商，如果backend说它没有空 +间，frontswap_store返回-1，内核就会照常把页换到交换设备上。注意，来自frontswap +backend的响应对内核来说是不可预测的；它可能选择从不接受一个页面，可能接受每九个 +页面，也可能接受每一个页面。但是如果backend确实接受了一个页面，那么这个页面的数 +据已经被复制并与类型和偏移量相关联了，而且backend保证了数据的持久性。在这种情况 +下，frontswap在交换设备的“frontswap_map” 中设置了一个位，对应于交换设备上的 +页面偏移量，否则它就会将数据写入该设备。 + +当交换子系统需要交换一个页面时（swap_readpage()），它首先调用frontswap_load()， +检查frontswap_map，看这个页面是否早先被frontswap backend接受。如果是，该页 +的数据就会从frontswap后端填充，换入就完成了。如果不是，正常的交换代码将被执行， +以便从真正的交换设备上获得这一页的数据。 + +所以每次frontswap backend接受一个页面时，交换设备的读取和（可能）交换设备的写 +入都被 “frontswap backend store” 和（可能）“frontswap backend loads” +所取代，这可能会快得多。 + +* frontswap不能被配置为一个 “特殊的” 交换设备，它的优先级要高于任何真正的交换 + 设备（例如像zswap，或者可能是swap-over-nbd/NFS）？ + +首先，现有的交换子系统不允许有任何种类的交换层次结构。也许它可以被重写以适应层次 +结构，但这将需要相当大的改变。即使它被重写，现有的交换子系统也使用了块I/O层，它 +假定交换设备是固定大小的，其中的任何页面都是可线性寻址的。Frontswap几乎没有触 +及现有的交换子系统，而是围绕着块I/O子系统的限制，提供了大量的灵活性和动态性。 + +例如，frontswap backend对任何交换页的接受是完全不可预测的。这对frontswap backend +的定义至关重要，因为它赋予了backend完全动态的决定权。在zcache中，人们无法预 +先知道一个页面的可压缩性如何。可压缩性 “差” 的页面会被拒绝，而 “差” 本身也可 +以根据当前的内存限制动态地定义。 + +此外，frontswap是完全同步的，而真正的交换设备，根据定义，是异步的，并且使用 +块I/O。块I/O层不仅是不必要的，而且可能进行 “优化”，这对面向RAM的设备来说是 +不合适的，包括将一些页面的写入延迟相当长的时间。同步是必须的，以确保后端的动 +态性，并避免棘手的竞争条件，这将不必要地大大增加frontswap和/或块I/O子系统的 +复杂性。也就是说，只有最初的 “store” 和 “load” 操作是需要同步的。一个独立 +的异步线程可以自由地操作由frontswap存储的页面。例如，RAMster中的 “remotification” +线程使用标准的异步内核套接字，将压缩的frontswap页面移动到远程机器。同样， +KVM的客户方实现可以进行客户内压缩，并使用 “batched” hypercalls。 + +在虚拟化环境中，动态性允许管理程序（或主机操作系统）做“intelligent overcommit”。 +例如，它可以选择只接受页面，直到主机交换可能即将发生，然后强迫客户机做他们 +自己的交换。 + +transcendent memory规格的frontswap有一个坏处。因为任何 “store” 都可 +能失败，所以必须在一个真正的交换设备上有一个真正的插槽来交换页面。因此， +frontswap必须作为每个交换设备的 “影子” 来实现，它有可能容纳交换设备可能 +容纳的每一个页面，也有可能根本不容纳任何页面。这意味着frontswap不能包含比 +swap设备总数更多的页面。例如，如果在某些安装上没有配置交换设备，frontswap +就没有用。无交换设备的便携式设备仍然可以使用frontswap，但是这种设备的 +backend必须配置某种 “ghost” 交换设备，并确保它永远不会被使用。 + + +* 为什么会有这种关于 “重复存储” 的奇怪定义？如果一个页面以前被成功地存储过， + 难道它不能总是被成功地覆盖吗？ + +几乎总是可以的，不，有时不能。考虑一个例子，数据被压缩了，原来的4K页面被压 +缩到了1K。现在，有人试图用不可压缩的数据覆盖该页，因此会占用整个4K。但是 +backend没有更多的空间了。在这种情况下，这个存储必须被拒绝。每当frontswap +拒绝一个会覆盖的存储时，它也必须使旧的数据作废，并确保它不再被访问。因为交 +换子系统会把新的数据写到读交换设备上，这是确保一致性的正确做法。 + +* 为什么frontswap补丁会创建新的头文件swapfile.h？ + +frontswap代码依赖于一些swap子系统内部的数据结构，这些数据结构多年来一直 +在静态和全局之间来回移动。这似乎是一个合理的妥协：将它们定义为全局，但在一 +个新的包含文件中声明它们，该文件不被包含swap.h的大量源文件所包含。 + +Dan Magenheimer，最后更新于2012年4月9日 diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index a1d2f0356cc1..a78060a0c2ed 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -27,11 +27,11 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） free_page_reporting highmem ksm + frontswap TODOLIST: * arch_pgtable_helpers * free_page_reporting -* frontswap * hmm * hwpoison * hugetlbfs_reserv -- cgit From 19a05e35dd92e49b287ec2f66c609338e93b1e57 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 17:59:44 +0800 Subject: docs/zh_CN: add vm hwpoison translation Translate .../vm/hwpoison.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/hwpoison.rst | 166 +++++++++++++++++++++++ Documentation/translations/zh_CN/vm/index.rst | 2 +- 2 files changed, 167 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/hwpoison.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/hwpoison.rst b/Documentation/translations/zh_CN/vm/hwpoison.rst new file mode 100644 index 000000000000..c6e1e7bdb05b --- /dev/null +++ b/Documentation/translations/zh_CN/vm/hwpoison.rst @@ -0,0 +1,166 @@ + +:Original: Documentation/vm/hwpoison.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +======== +hwpoison +======== + +什么是hwpoison? +=============== + + +即将推出的英特尔CPU支持从一些内存错误中恢复（ ``MCA恢复`` ）。这需要操作系统宣布 +一个页面"poisoned"，杀死与之相关的进程，并避免在未来使用它。 + +这个补丁包在虚拟机中实现了必要的(编程)框架。 + +引用概述中的评论:: + + 高级机器的检查与处理。处理方法是损坏的页面被硬件报告，通常是由于2位ECC内 + 存或高速缓存故障。 + + 这主要是针对在后台检测到的损坏的页面。当当前的CPU试图访问它时，当前运行的进程 + 可以直接被杀死。因为还没有访问损坏的页面, 如果错误由于某种原因不能被处理，就可 + 以安全地忽略它. 而不是用另外一个机器检查去处理它。 + + 处理不同状态的页面缓存页。这里棘手的部分是，相对于其他虚拟内存用户， 我们可以异 + 步访问任何页面。因为内存故障可能随时随地发生，可能违反了他们的一些假设。这就是 + 为什么这段代码必须非常小心。一般来说，它试图使用正常的锁规则，如获得标准锁，即使 + 这意味着错误处理可能需要很长的时间。 + + 这里的一些操作有点低效，并且具有非线性的算法复杂性，因为数据结构没有针对这种情 + 况进行优化。特别是从vma到进程的映射就是这种情况。由于这种情况大概率是罕见的，所 + 以我们希望我们可以摆脱这种情况。 + +该代码由mm/memory-failure.c中的高级处理程序、一个新的页面poison位和虚拟机中的 +各种检查组成，用来处理poison的页面。 + +现在主要目标是KVM客户机，但它适用于所有类型的应用程序。支持KVM需要最近的qemu-kvm +版本。 + +对于KVM的使用，需要一个新的信号类型，这样KVM就可以用适当的地址将机器检查注入到客户 +机中。这在理论上也允许其他应用程序处理内存故障。我们的期望是，所有的应用程序都不要这 +样做，但一些非常专业的应用程序可能会这样做。 + +故障恢复模式 +============ + +有两种（实际上是三种）模式的内存故障恢复可以在。 + +vm.memory_failure_recovery sysctl 置零: + 所有的内存故障都会导致panic。请不要尝试恢复。 + +早期处理 + (可以在全局和每个进程中控制) 一旦检测到错误，立即向应用程序发送SIGBUS这允许 + 应用程序以温和的方式处理内存错误（例如，放弃受影响的对象） 这是KVM qemu使用的 + 模式。 + +推迟处理 + 当应用程序运行到损坏的页面时，发送SIGBUS。这对不知道内存错误的应用程序来说是 + 最好的，默认情况下注意一些页面总是被当作late kill处理。 + +用户控制 +======== + +vm.memory_failure_recovery + 参阅 sysctl.txt + +vm.memory_failure_early_kill + 全局启用early kill + +PR_MCE_KILL + 设置early/late kill mode/revert 到系统默认值。 + + arg1: PR_MCE_KILL_CLEAR: + 恢复到系统默认值 + arg1: PR_MCE_KILL_SET: + arg2定义了线程特定模式 + + PR_MCE_KILL_EARLY: + Early kill + PR_MCE_KILL_LATE: + Late kill + PR_MCE_KILL_DEFAULT + 使用系统全局默认值 + + 注意，如果你想有一个专门的线程代表进程处理SIGBUS(BUS_MCEERR_AO)，你应该在 + 指定线程上调用prctl(PR_MCE_KILL_EARLY)。否则，SIGBUS将被发送到主线程。 + +PR_MCE_KILL_GET + 返回当前模式 + +测试 +==== + +* madvise(MADV_HWPOISON, ....) (as root) - 在测试过程中Poison一个页面 + +* 通过debugfs ``/sys/kernel/debug/hwpoison/`` hwpoison-inject模块 + + corrupt-pfn + 在PFN处注入hwpoison故障，并echoed到这个文件。这做了一些早期过滤，以避 + 免在测试套件中损坏非预期页面。 + unpoison-pfn + 在PFN的Software-unpoison页面对应到这个文件。这样，一个页面可以再次被 + 复用。这只对Linux注入的故障起作用，对真正的内存故障不起作用。 + + 注意这些注入接口并不稳定，可能会在不同的内核版本中发生变化 + + corrupt-filter-dev-major, corrupt-filter-dev-minor + 只处理与块设备major/minor定义的文件系统相关的页面的内存故障。-1U是通 + 配符值。这应该只用于人工注入的测试。 + + corrupt-filter-memcg + 限制注入到memgroup拥有的页面。由memcg的inode号指定。 + + Example:: + + mkdir /sys/fs/cgroup/mem/hwpoison + + usemem -m 100 -s 1000 & + echo `jobs -p` > /sys/fs/cgroup/mem/hwpoison/tasks + + memcg_ino=$(ls -id /sys/fs/cgroup/mem/hwpoison | cut -f1 -d' ') + echo $memcg_ino > /debug/hwpoison/corrupt-filter-memcg + + page-types -p `pidof init` --hwpoison # shall do nothing + page-types -p `pidof usemem` --hwpoison # poison its pages + + corrupt-filter-flags-mask, corrupt-filter-flags-value + 当指定时，只有在((page_flags & mask) == value)的情况下才会poison页面。 + 这允许对许多种类的页面进行压力测试。page_flags与/proc/kpageflags中的相 + 同。这些标志位在include/linux/kernel-page-flags.h中定义，并在 + Documentation/admin-guide/mm/pagemap.rst中记录。 + +* 架构特定的MCE注入器 + + x86 有 mce-inject, mce-test + + 在mce-test中的一些便携式hwpoison测试程序，见下文。 + +引用 +==== + +http://halobates.de/mce-lc09-2.pdf + 09年LinuxCon的概述演讲 + +git://git.kernel.org/pub/scm/utils/cpu/mce/mce-test.git + 测试套件（在tsrc中的hwpoison特定可移植测试）。 + +git://git.kernel.org/pub/scm/utils/cpu/mce/mce-inject.git + x86特定的注入器 + + +限制 +==== +- 不是所有的页面类型都被支持，而且永远不会。大多数内核内部对象不能被恢 + 复，目前只有LRU页。 + +--- +Andi Kleen, 2009年10月 diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index a78060a0c2ed..c5b3d5ba21f1 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -28,12 +28,12 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） highmem ksm frontswap + hwpoison TODOLIST: * arch_pgtable_helpers * free_page_reporting * hmm -* hwpoison * hugetlbfs_reserv * memory-model * mmu_notifier -- cgit From 457d2de7ee647aa1ed77a066cfbe314253ccffe2 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 17:59:45 +0800 Subject: docs/zh_CN: add vm memory-model translation Translate .../vm/memory-model.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/index.rst | 3 +- .../translations/zh_CN/vm/memory-model.rst | 135 +++++++++++++++++++++ 2 files changed, 137 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/memory-model.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index c5b3d5ba21f1..c1f517da81f4 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -29,13 +29,14 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） ksm frontswap hwpoison + memory-model TODOLIST: * arch_pgtable_helpers * free_page_reporting * hmm * hugetlbfs_reserv -* memory-model + * mmu_notifier * numa * overcommit-accounting diff --git a/Documentation/translations/zh_CN/vm/memory-model.rst b/Documentation/translations/zh_CN/vm/memory-model.rst new file mode 100644 index 000000000000..013e30c88d72 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/memory-model.rst @@ -0,0 +1,135 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:Original: Documentation/vm/memory-model.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +============ +物理内存模型 +============ + +系统中的物理内存可以用不同的方式进行寻址。最简单的情况是，物理内存从地址0开 +始，跨越一个连续的范围，直到最大的地址。然而，这个范围可能包含CPU无法访问的 +小孔隙。那么，在完全不同的地址可能有几个连续的范围。而且，别忘了NUMA，即不 +同的内存库连接到不同的CPU。 + +Linux使用两种内存模型中的一种对这种多样性进行抽象。FLATMEM和SPARSEM。每 +个架构都定义了它所支持的内存模型，默认的内存模型是什么，以及是否有可能手动 +覆盖该默认值。 + +所有的内存模型都使用排列在一个或多个数组中的 `struct page` 来跟踪物理页 +帧的状态。 + +无论选择哪种内存模型，物理页框号（PFN）和相应的 `struct page` 之间都存 +在一对一的映射关系。 + +每个内存模型都定义了 :c:func:`pfn_to_page` 和 :c:func:`page_to_pfn` +帮助函数，允许从PFN到 `struct page` 的转换，反之亦然。 + +FLATMEM +======= + +最简单的内存模型是FLATMEM。这个模型适用于非NUMA系统的连续或大部分连续的 +物理内存。 + +在FLATMEM内存模型中，有一个全局的 `mem_map` 数组来映射整个物理内存。对 +于大多数架构，孔隙在 `mem_map` 数组中都有条目。与孔洞相对应的 `struct page` +对象从未被完全初始化。 + +为了分配 `mem_map` 数组，架构特定的设置代码应该调用free_area_init()函数。 +然而，在调用memblock_free_all()函数之前，映射数组是不能使用的，该函数 +将所有的内存交给页分配器。 + +一个架构可能会释放 `mem_map` 数组中不包括实际物理页的部分。在这种情况下，特 +定架构的 :c:func:`pfn_valid` 实现应该考虑到 `mem_map` 中的孔隙。 + +使用FLATMEM，PFN和 `struct page` 之间的转换是直接的。 `PFN - ARCH_PFN_OFFSET` +是 `mem_map` 数组的一个索引。 + +`ARCH_PFN_OFFSET` 定义了物理内存起始地址不同于0的系统的第一个页框号。 + +SPARSEMEM +========= + +SPARSEMEM是Linux中最通用的内存模型，它是唯一支持若干高级功能的内存模型， +如物理内存的热插拔、非易失性内存设备的替代内存图和较大系统的内存图的延迟 +初始化。 + +SPARSEMEM模型将物理内存显示为一个部分的集合。一个区段用mem_section结构 +体表示，它包含 `section_mem_map` ，从逻辑上讲，它是一个指向 `struct page` +阵列的指针。然而，它被存储在一些其他的magic中，以帮助分区管理。区段的大小 +和最大区段数是使用 `SECTION_SIZE_BITS` 和 `MAX_PHYSMEM_BITS` 常量 +来指定的，这两个常量是由每个支持SPARSEMEM的架构定义的。 `MAX_PHYSMEM_BITS` +是一个架构所支持的物理地址的实际宽度，而 `SECTION_SIZE_BITS` 是一个任 +意的值。 + +最大的段数表示为 `NR_MEM_SECTIONS` ，定义为 + +.. math:: + + NR\_MEM\_SECTIONS = 2 ^ {(MAX\_PHYSMEM\_BITS - SECTION\_SIZE\_BITS)} + +`mem_section` 对象被安排在一个叫做 `mem_sections` 的二维数组中。这个数组的 +大小和位置取决于 `CONFIG_SPARSEM_EXTREME` 和可能的最大段数: + +* 当 `CONFIG_SPARSEMEM_EXTREME` 被禁用时， `mem_sections` 数组是静态的，有 + `NR_MEM_SECTIONS` 行。每一行持有一个 `mem_section` 对象。 +* 当 `CONFIG_SPARSEMEM_EXTREME` 被启用时， `mem_sections` 数组被动态分配。 + 每一行包含价值 `PAGE_SIZE` 的 `mem_section` 对象，行数的计算是为了适应所有的 + 内存区。 + +架构设置代码应该调用sparse_init()来初始化内存区和内存映射。 + +通过SPARSEMEM，有两种可能的方式将PFN转换为相应的 `struct page` --"classic sparse"和 + "sparse vmemmap"。选择是在构建时进行的，它由 `CONFIG_SPARSEMEM_VMEMMAP` 的 + 值决定。 + +Classic sparse在page->flags中编码了一个页面的段号，并使用PFN的高位来访问映射该页 +框的段。在一个区段内，PFN是指向页数组的索引。 + +Sparse vmemmapvmemmap使用虚拟映射的内存映射来优化pfn_to_page和page_to_pfn操 +作。有一个全局的 `struct page *vmemmap` 指针，指向一个虚拟连续的 `struct page` +对象阵列。PFN是该数组的一个索引，`struct page` 从 `vmemmap` 的偏移量是该页的PFN。 + +为了使用vmemmap，一个架构必须保留一个虚拟地址的范围，以映射包含内存映射的物理页，并 +确保 `vmemmap`指向该范围。此外，架构应该实现 :c:func:`vmemmap_populate` 方法， +它将分配物理内存并为虚拟内存映射创建页表。如果一个架构对vmemmap映射没有任何特殊要求， +它可以使用通用内存管理提供的默认 :c:func:`vmemmap_populate_basepages`。 + +虚拟映射的内存映射允许将持久性内存设备的 `struct page` 对象存储在这些设备上预先分 +配的存储中。这种存储用vmem_altmap结构表示，最终通过一长串的函数调用传递给 +vmemmap_populate()。vmemmap_populate()实现可以使用 `vmem_altmap` 和 +:c:func:`vmemmap_alloc_block_buf` 助手来分配持久性内存设备上的内存映射。 + +ZONE_DEVICE +=========== +`ZONE_DEVICE` 设施建立在 `SPARSEM_VMEMMAP` 之上，为设备驱动识别的物理地址范 +围提供 `struct page` `mem_map` 服务。 `ZONE_DEVICE` 的 "设备" 方面与以下 +事实有关：这些地址范围的页面对象从未被在线标记过，而且必须对设备进行引用，而不仅仅 +是页面，以保持内存被“锁定”以便使用。 `ZONE_DEVICE` ，通过 :c:func:`devm_memremap_pages` ， +为给定的pfns范围执行足够的内存热插拔来开启 :c:func:`pfn_to_page`， +:c:func:`page_to_pfn`, ，和 :c:func:`get_user_pages` 服务。由于页面引 +用计数永远不会低于1，所以页面永远不会被追踪为空闲内存，页面的 `struct list_head lru` +空间被重新利用，用于向映射该内存的主机设备/驱动程序进行反向引用。 + +虽然 `SPARSEMEM` 将内存作为一个区段的集合，可以选择收集并合成内存块，但 +`ZONE_DEVICE` 用户需要更小的颗粒度来填充 `mem_map` 。鉴于 `ZONE_DEVICE` +内存从未被在线标记，因此它的内存范围从未通过sysfs内存热插拔api暴露在内存块边界 +上。这个实现依赖于这种缺乏用户接口的约束，允许子段大小的内存范围被指定给 +:c:func:`arch_add_memory` ，即内存热插拔的上半部分。子段支持允许2MB作为 +:c:func:`devm_memremap_pages` 的跨架构通用对齐颗粒度。 + +`ZONE_DEVICE` 的用户是: + +* pmem: 通过DAX映射将平台持久性内存作为直接I/O目标使用。 + +* hmm: 用 `->page_fault()` 和 `->page_free()` 事件回调扩展 `ZONE_DEVICE` ， + 以允许设备驱动程序协调与设备内存相关的内存管理事件，通常是GPU内存。参见/vm/hmm.rst。 + +* p2pdma: 创建 `struct page` 对象，允许PCI/E拓扑结构中的peer设备协调它们之间的 + 直接DMA操作，即绕过主机内存。 -- cgit From d1c84942e113802bacd14185cc4684b16be0ce29 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 17:59:46 +0800 Subject: docs/zh_CN: add vm mmu_notifier translation Translate .../vm/mmu_notifier.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/index.rst | 3 +- .../translations/zh_CN/vm/mmu_notifier.rst | 97 ++++++++++++++++++++++ 2 files changed, 98 insertions(+), 2 deletions(-) create mode 100644 Documentation/translations/zh_CN/vm/mmu_notifier.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index c1f517da81f4..1fb80aa7a08b 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -30,14 +30,13 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） frontswap hwpoison memory-model + mmu_notifier TODOLIST: * arch_pgtable_helpers * free_page_reporting * hmm * hugetlbfs_reserv - -* mmu_notifier * numa * overcommit-accounting * page_migration diff --git a/Documentation/translations/zh_CN/vm/mmu_notifier.rst b/Documentation/translations/zh_CN/vm/mmu_notifier.rst new file mode 100644 index 000000000000..b29a37b33628 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/mmu_notifier.rst @@ -0,0 +1,97 @@ +:Original: Documentation/vm/mmu_notifier.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + + +什么时候需要页表锁内通知？ +========================== + +当清除一个pte/pmd时，我们可以选择通过在页表锁下（通知版的\*_clear_flush调用 +mmu_notifier_invalidate_range）通知事件。但这种通知并不是在所有情况下都需要的。 + +对于二级TLB（非CPU TLB），如IOMMU TLB或设备TLB（当设备使用类似ATS/PASID的东西让 +IOMMU走CPU页表来访问进程的虚拟地址空间）。只有两种情况需要在清除pte/pmd时在持有页 +表锁的同时通知这些二级TLB： + + A) 在mmu_notifier_invalidate_range_end()之前，支持页的地址被释放。 + B) 一个页表项被更新以指向一个新的页面（COW，零页上的写异常，__replace_page()，...）。 + +情况A很明显，你不想冒风险让设备写到一个现在可能被一些完全不同的任务使用的页面。 + +情况B更加微妙。为了正确起见，它需要按照以下序列发生: + + - 上页表锁 + - 清除页表项并通知 ([pmd/pte]p_huge_clear_flush_notify()) + - 设置页表项以指向新页 + +如果在设置新的pte/pmd值之前，清除页表项之后没有进行通知，那么你就会破坏设备的C11或 +C++11等内存模型。 + +考虑以下情况（设备使用类似于ATS/PASID的功能）。 + +两个地址addrA和addrB，这样|addrA - addrB| >= PAGE_SIZE，我们假设它们是COW的 +写保护（B的其他情况也适用）。 + +:: + + [Time N] -------------------------------------------------------------------- + CPU-thread-0 {尝试写到addrA} + CPU-thread-1 {尝试写到addrB} + CPU-thread-2 {} + CPU-thread-3 {} + DEV-thread-0 {读取addrA并填充设备TLB} + DEV-thread-2 {读取addrB并填充设备TLB} + [Time N+1] ------------------------------------------------------------------ + CPU-thread-0 {COW_step0: {mmu_notifier_invalidate_range_start(addrA)}} + CPU-thread-1 {COW_step0: {mmu_notifier_invalidate_range_start(addrB)}} + CPU-thread-2 {} + CPU-thread-3 {} + DEV-thread-0 {} + DEV-thread-2 {} + [Time N+2] ------------------------------------------------------------------ + CPU-thread-0 {COW_step1: {更新页表以指向addrA的新页}} + CPU-thread-1 {COW_step1: {更新页表以指向addrB的新页}} + CPU-thread-2 {} + CPU-thread-3 {} + DEV-thread-0 {} + DEV-thread-2 {} + [Time N+3] ------------------------------------------------------------------ + CPU-thread-0 {preempted} + CPU-thread-1 {preempted} + CPU-thread-2 {写入addrA，这是对新页面的写入} + CPU-thread-3 {} + DEV-thread-0 {} + DEV-thread-2 {} + [Time N+3] ------------------------------------------------------------------ + CPU-thread-0 {preempted} + CPU-thread-1 {preempted} + CPU-thread-2 {} + CPU-thread-3 {写入addrB，这是一个写入新页的过程} + DEV-thread-0 {} + DEV-thread-2 {} + [Time N+4] ------------------------------------------------------------------ + CPU-thread-0 {preempted} + CPU-thread-1 {COW_step3: {mmu_notifier_invalidate_range_end(addrB)}} + CPU-thread-2 {} + CPU-thread-3 {} + DEV-thread-0 {} + DEV-thread-2 {} + [Time N+5] ------------------------------------------------------------------ + CPU-thread-0 {preempted} + CPU-thread-1 {} + CPU-thread-2 {} + CPU-thread-3 {} + DEV-thread-0 {从旧页中读取addrA} + DEV-thread-2 {从新页面读取addrB} + +所以在这里，因为在N+2的时候，清空页表项没有和通知一起作废二级TLB，设备在看到addrA的新值之前 +就看到了addrB的新值。这就破坏了设备的总内存序。 + +当改变一个pte的写保护或指向一个新的具有相同内容的写保护页（KSM）时，将mmu_notifier_invalidate_range +调用延迟到页表锁外的mmu_notifier_invalidate_range_end()是可以的。即使做页表更新的线程 +在释放页表锁后但在调用mmu_notifier_invalidate_range_end()前被抢占，也是如此。 -- cgit From 273bfe7ba7adb04cc259bca1cc6f3e7166aa7520 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 17:59:47 +0800 Subject: docs/zh_CN: add vm overcommit-accounting translation Translate .../vm/overcommit-accounting.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/index.rst | 2 +- .../zh_CN/vm/overcommit-accounting.rst | 86 ++++++++++++++++++++++ 2 files changed, 87 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/overcommit-accounting.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index 1fb80aa7a08b..1c6ec847a2f3 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -31,6 +31,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） hwpoison memory-model mmu_notifier + overcommit-accounting TODOLIST: * arch_pgtable_helpers @@ -38,7 +39,6 @@ TODOLIST: * hmm * hugetlbfs_reserv * numa -* overcommit-accounting * page_migration * page_frags * page_owner diff --git a/Documentation/translations/zh_CN/vm/overcommit-accounting.rst b/Documentation/translations/zh_CN/vm/overcommit-accounting.rst new file mode 100644 index 000000000000..8765cb118f24 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/overcommit-accounting.rst @@ -0,0 +1,86 @@ +:Original: Documentation/vm/overcommit-accounting.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + + +============== +超量使用审计 +============== + +Linux内核支持下列超量使用处理模式 + +0 + 启发式超量使用处理。拒绝明显的地址空间超量使用。用于一个典型的系统。 + 它确保严重的疯狂分配失败，同时允许超量使用以减少swap的使用。在这种模式下， + 允许root分配稍多的内存。这是默认的。 +1 + 总是超量使用。适用于一些科学应用。经典的例子是使用稀疏数组的代码，只是依赖 + 几乎完全由零页组成的虚拟内存 + +2 + 不超量使用。系统提交的总地址空间不允许超过swap+一个可配置的物理RAM的数量 + （默认为50%）。根据你使用的数量，在大多数情况下，这意味着一个进程在访问页面时 + 不会被杀死，但会在内存分配上收到相应的错误。 + + 对于那些想保证他们的内存分配在未来可用而又不需要初始化每一个页面的应用程序来说 + 是很有用的。 + +超量使用策略是通过sysctl `vm.overcommit_memory` 设置的。 + +可以通过 `vm.overcommit_ratio` （百分比）或 `vm.overcommit_kbytes` （绝对值） +来设置超限数量。这些只有在 `vm.overcommit_memory` 被设置为2时才有效果。 + +在 ``/proc/meminfo`` 中可以分别以CommitLimit和Committed_AS的形式查看当前 +的超量使用和提交量。 + +陷阱 +==== + +C语言的堆栈增长是一个隐含的mremap。如果你想得到绝对的保证，并在接近边缘的地方运行， +你 **必须** 为你认为你需要的最大尺寸的堆栈进行mmap。对于典型的堆栈使用来说，这并 +不重要，但如果你真的非常关心的话，这就是一个值得关注的案例。 + + +在模式2中，MAP_NORESERVE标志被忽略。 + + +它是如何工作的 +============== + +超量使用是基于以下规则 + +对于文件映射 + | SHARED or READ-only - 0 cost (该文件是映射而不是交换) + | PRIVATE WRITABLE - 每个实例的映射大小 + +对于匿名或者 ``/dev/zero`` 映射 + | SHARED - 映射的大小 + | PRIVATE READ-only - 0 cost (但作用不大) + | PRIVATE WRITABLE - 每个实例的映射大小 + +额外的计数 + | 通过mmap制作可写副本的页面 + | 从同一池中提取的shmfs内存 + +状态 +==== + +* 我们核算mmap内存映射 +* 我们核算mprotect在提交中的变化 +* 我们核算mremap的大小变化 +* 我们的审计 brk +* 审计munmap +* 我们在/proc中报告commit 状态 +* 核对并检查分叉的情况 +* 审查堆栈处理/执行中的构建 +* 叙述SHMfs的情况 +* 实现实际限制的执行 + +待续 +==== +* ptrace 页计数（这很难）。 -- cgit From f51debc256f88b49b8356d6ce4957380310791ef Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 17:59:48 +0800 Subject: docs/zh_CN: add vm page_frags translation Translate .../vm/page_frags.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/index.rst | 2 +- Documentation/translations/zh_CN/vm/page_frags.rst | 38 ++++++++++++++++++++++ 2 files changed, 39 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/page_frags.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index 1c6ec847a2f3..f478032cd477 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -32,6 +32,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） memory-model mmu_notifier overcommit-accounting + page_frags TODOLIST: * arch_pgtable_helpers @@ -40,7 +41,6 @@ TODOLIST: * hugetlbfs_reserv * numa * page_migration -* page_frags * page_owner * page_table_check * remap_file_pages diff --git a/Documentation/translations/zh_CN/vm/page_frags.rst b/Documentation/translations/zh_CN/vm/page_frags.rst new file mode 100644 index 000000000000..ad27fed33634 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/page_frags.rst @@ -0,0 +1,38 @@ +:Original: Documentation/vm/page_frag.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +======== +页面片段 +======== + +一个页面片段是一个任意长度的任意偏移的内存区域，它位于一个0或更高阶的复合页面中。 +该页中的多个碎片在该页的引用计数器中被单独计算。 + +page_frag函数，page_frag_alloc和page_frag_free，为页面片段提供了一个简单 +的分配框架。这被网络堆栈和网络设备驱动使用，以提供一个内存的支持区域，作为 +sk_buff->head使用，或者用于skb_shared_info的 “frags” 部分。 + +为了使用页面片段API，需要一个支持页面片段的缓冲区。这为碎片分配提供了一个中心点， +并允许多个调用使用一个缓存的页面。这样做的好处是可以避免对get_page的多次调用， +这在分配时开销可能会很大。然而，由于这种缓存的性质，要求任何对缓存的调用都要受到每 +个CPU的限制，或者每个CPU的限制，并在执行碎片分配时强制禁止中断。 + +网络堆栈在每个CPU使用两个独立的缓存来处理碎片分配。netdev_alloc_cache被使用 +netdev_alloc_frag和__netdev_alloc_skb调用的调用者使用。napi_alloc_cache +被调用__napi_alloc_frag和__napi_alloc_skb的调用者使用。这两个调用的主要区别是 +它们可能被调用的环境。“netdev” 前缀的函数可以在任何上下文中使用，因为这些函数 +将禁用中断，而 ”napi“ 前缀的函数只可以在softirq上下文中使用。 + +许多网络设备驱动程序使用类似的方法来分配页面片段，但页面片段是在环或描述符级别上 +缓存的。为了实现这些情况，有必要提供一种拆解页面缓存的通用方法。出于这个原因， +__page_frag_cache_drain被实现了。它允许通过一次调用从一个页面释放多个引用。 +这样做的好处是，它允许清理被添加到一个页面的多个引用，以避免每次分配都调用 +get_page。 + +Alexander Duyck，2016年11月29日。 -- cgit From 7bdc0a9515dd627a2d4daa4f5c0cbaac052b140d Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 17:59:49 +0800 Subject: docs/zh_CN: add vm page_owner translation Translate .../vm/page_owner.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/index.rst | 2 +- Documentation/translations/zh_CN/vm/page_owner.rst | 116 +++++++++++++++++++++ 2 files changed, 117 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/page_owner.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index f478032cd477..aa983d023045 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -33,6 +33,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） mmu_notifier overcommit-accounting page_frags + page_owner TODOLIST: * arch_pgtable_helpers @@ -41,7 +42,6 @@ TODOLIST: * hugetlbfs_reserv * numa * page_migration -* page_owner * page_table_check * remap_file_pages * slub diff --git a/Documentation/translations/zh_CN/vm/page_owner.rst b/Documentation/translations/zh_CN/vm/page_owner.rst new file mode 100644 index 000000000000..9e951fabba9d --- /dev/null +++ b/Documentation/translations/zh_CN/vm/page_owner.rst @@ -0,0 +1,116 @@ +:Original: Documentation/vm/page_owner.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +================================ +page owner: 跟踪谁分配的每个页面 +================================ + +概述 +==== + +page owner是用来追踪谁分配的每一个页面。它可以用来调试内存泄漏或找到内存占用者。 +当分配发生时，有关分配的信息，如调用堆栈和页面的顺序被存储到每个页面的特定存储中。 +当我们需要了解所有页面的状态时，我们可以获得并分析这些信息。 + +尽管我们已经有了追踪页面分配/释放的tracepoint，但用它来分析谁分配的每个页面是 +相当复杂的。我们需要扩大跟踪缓冲区，以防止在用户空间程序启动前出现重叠。而且，启 +动的程序会不断地将跟踪缓冲区转出，供以后分析，这将会改变系统的行为，会产生更多的 +可能性，而不是仅仅保留在内存中，所以不利于调试。 + +页面所有者也可以用于各种目的。例如，可以通过每个页面的gfp标志信息获得精确的碎片 +统计。如果启用了page owner，它就已经实现并激活了。我们非常欢迎其他用途。 + +page owner在默认情况下是禁用的。所以，如果你想使用它，你需要在你的启动cmdline +中加入"page_owner=on"。如果内核是用page owner构建的，并且由于没有启用启动 +选项而在运行时禁用page owner，那么运行时的开销是很小的。如果在运行时禁用，它不 +需要内存来存储所有者信息，所以没有运行时内存开销。而且，页面所有者在页面分配器的 +热路径中只插入了两个不可能的分支，如果不启用，那么分配就会像没有页面所有者的内核 +一样进行。这两个不可能的分支应该不会影响到分配的性能，特别是在静态键跳转标签修补 +功能可用的情况下。以下是由于这个功能而导致的内核代码大小的变化。 + +- 没有page owner:: + + text data bss dec hex filename + 48392 2333 644 51369 c8a9 mm/page_alloc.o + +- 有page owner:: + + text data bss dec hex filename + 48800 2445 644 51889 cab1 mm/page_alloc.o + 6662 108 29 6799 1a8f mm/page_owner.o + 1025 8 8 1041 411 mm/page_ext.o + +虽然总共增加了8KB的代码，但page_alloc.o增加了520字节，其中不到一半是在hotpath +中。构建带有page owner的内核，并在需要时打开它，将是调试内核内存问题的最佳选择。 + +有一个问题是由实现细节引起的。页所有者将信息存储到struct page扩展的内存中。这 +个内存的初始化时间比稀疏内存系统中的页面分配器启动的时间要晚一些，所以，在初始化 +之前，许多页面可以被分配，但它们没有所有者信息。为了解决这个问题，这些早期分配的 +页面在初始化阶段被调查并标记为分配。虽然这并不意味着它们有正确的所有者信息，但至 +少，我们可以更准确地判断该页是否被分配。在2GB内存的x86-64虚拟机上，有13343 +个早期分配的页面被捕捉和标记，尽管它们大部分是由结构页扩展功能分配的。总之，在这 +之后，没有任何页面处于未追踪状态。 + +使用方法 +======== + +1) 构建用户空间的帮助:: + + cd tools/vm + make page_owner_sort + +2) 启用page owner: 添加 "page_owner=on" 到 boot cmdline. + +3) 做你想调试的工作。 + +4) 分析来自页面所有者的信息:: + + cat /sys/kernel/debug/page_owner > page_owner_full.txt + ./page_owner_sort page_owner_full.txt sorted_page_owner.txt + + ``page_owner_full.txt`` 的一般输出情况如下(输出信息无翻译价值):: + + Page allocated via order XXX, ... + PFN XXX ... + // Detailed stack + + Page allocated via order XXX, ... + PFN XXX ... + // Detailed stack + + ``page_owner_sort`` 工具忽略了 ``PFN`` 行，将剩余的行放在buf中，使用regexp提 + 取页序值，计算buf的次数和页数，最后根据参数进行排序。 + + 在 ``sorted_page_owner.txt`` 中可以看到关于谁分配了每个页面的结果。一般输出:: + + XXX times, XXX pages: + Page allocated via order XXX, ... + // Detailed stack + + 默认情况下， ``page_owner_sort`` 是根据buf的时间来排序的。如果你想 + 按buf的页数排序，请使用-m参数。详细的参数是: + + 基本函数: + + Sort: + -a 按内存分配时间排序 + -m 按总内存排序 + -p 按pid排序。 + -P 按tgid排序。 + -r 按内存释放时间排序。 + -s 按堆栈跟踪排序。 + -t 按时间排序（默认）。 + + 其它函数: + + Cull: + -c 通过比较堆栈跟踪而不是总块来进行剔除。 + + Filter: + -f 过滤掉内存已被释放的块的信息。 -- cgit From dc742b017439b18847745c1095e0ee997d586d85 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 17:59:50 +0800 Subject: docs/zh_CN: add vm page_table_check translation Translate .../vm/page_table_check.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/index.rst | 2 +- .../translations/zh_CN/vm/page_table_check.rst | 56 ++++++++++++++++++++++ 2 files changed, 57 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/page_table_check.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index aa983d023045..a2dea8b618ad 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -34,6 +34,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） overcommit-accounting page_frags page_owner + page_table_check TODOLIST: * arch_pgtable_helpers @@ -42,7 +43,6 @@ TODOLIST: * hugetlbfs_reserv * numa * page_migration -* page_table_check * remap_file_pages * slub * split_page_table_lock diff --git a/Documentation/translations/zh_CN/vm/page_table_check.rst b/Documentation/translations/zh_CN/vm/page_table_check.rst new file mode 100644 index 000000000000..a29fc1b360e6 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/page_table_check.rst @@ -0,0 +1,56 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:Original: Documentation/vm/page_table_check.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +======== +页表检查 +======== + +概述 +==== + +页表检查允许通过确保防止某些类型的内存损坏来强化内核。 + +当新的页面可以从用户空间访问时，页表检查通过将它们的页表项（PTEs PMD等）添加到页表中来执行额外 +的验证。 + +在检测到损坏的情况下，内核会被崩溃。页表检查有一个小的性能和内存开销。因此，它在默认情况下是禁用 +的，但是在额外的加固超过性能成本的系统上，可以选择启用。另外，由于页表检查是同步的，它可以帮助调 +试双映射内存损坏问题，在错误的映射发生时崩溃内核，而不是在内存损坏错误发生后内核崩溃。 + +双重映射检测逻辑 +================ + ++-------------------+-------------------+-------------------+------------------+ +| Current Mapping | New mapping | Permissions | Rule | ++===================+===================+===================+==================+ +| Anonymous | Anonymous | Read | Allow | ++-------------------+-------------------+-------------------+------------------+ +| Anonymous | Anonymous | Read / Write | Prohibit | ++-------------------+-------------------+-------------------+------------------+ +| Anonymous | Named | Any | Prohibit | ++-------------------+-------------------+-------------------+------------------+ +| Named | Anonymous | Any | Prohibit | ++-------------------+-------------------+-------------------+------------------+ +| Named | Named | Any | Allow | ++-------------------+-------------------+-------------------+------------------+ + +启用页表检查 +============ + +用以下方法构建内核: + +- PAGE_TABLE_CHECK=y + 注意，它只能在ARCH_SUPPORTS_PAGE_TABLE_CHECK可用的平台上启用。 + +- 使用 "page_table_check=on" 内核参数启动。 + +可以选择用PAGE_TABLE_CHECK_ENFORCED来构建内核，以便在没有额外的内核参数的情况下获得页表 +支持。 -- cgit From 114b27cd15453541a7e34d0dc64a90032b26adc7 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 17:59:51 +0800 Subject: docs/zh_CN: add vm remap_file_pages translation Translate .../vm/remap_file_pages.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/index.rst | 2 +- .../translations/zh_CN/vm/remap_file_pages.rst | 32 ++++++++++++++++++++++ 2 files changed, 33 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/remap_file_pages.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index a2dea8b618ad..3e4f4cac509c 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -35,6 +35,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） page_frags page_owner page_table_check + remap_file_pages TODOLIST: * arch_pgtable_helpers @@ -43,7 +44,6 @@ TODOLIST: * hugetlbfs_reserv * numa * page_migration -* remap_file_pages * slub * split_page_table_lock * transhuge diff --git a/Documentation/translations/zh_CN/vm/remap_file_pages.rst b/Documentation/translations/zh_CN/vm/remap_file_pages.rst new file mode 100644 index 000000000000..af6b7e28af23 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/remap_file_pages.rst @@ -0,0 +1,32 @@ +:Original: Documentation/vm/remap_file_pages.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +============================== +remap_file_pages()系统调用 +============================== + +remap_file_pages()系统调用被用来创建一个非线性映射，也就是说，在这个映射中， +文件的页面被无序映射到内存中。使用remap_file_pages()比重复调用mmap(2)的好 +处是，前者不需要内核创建额外的VMA（虚拟内存区）数据结构。 + +支持非线性映射需要在内核虚拟内存子系统中编写大量的non-trivial的代码，包括热 +路径。另外，为了使非线性映射工作，内核需要一种方法来区分正常的页表项和带有文件 +偏移的项（pte_file）。内核为达到这个目的在PTE中保留了标志。PTE标志是稀缺资 +源，特别是在某些CPU架构上。如果能腾出这个标志用于其他用途就更好了。 + +幸运的是，在生活中并没有很多remap_file_pages()的用户。只知道有一个企业的RDBMS +实现在32位系统上使用这个系统调用来映射比32位虚拟地址空间线性尺寸更大的文件。 +由于64位系统的广泛使用，这种使用情况已经不重要了。 + +syscall被废弃了，现在用一个模拟来代替它。仿真会创建新的VMA，而不是非线性映射。 +对于remap_file_pages()的少数用户来说，它的工作速度会变慢，但ABI被保留了。 + +仿真的一个副作用（除了性能之外）是，由于额外的VMA，用户可以更容易达到 +vm.max_map_count的限制。关于限制的更多细节，请参见DEFAULT_MAX_MAP_COUNT +的注释。 -- cgit From 11e85082a19f8d830ceaa5f9fae979e09b147d75 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 17:59:52 +0800 Subject: docs/zh_CN: add vm split_page_table_lock translation Translate .../vm/split_page_table_lock.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/index.rst | 2 +- .../zh_CN/vm/split_page_table_lock.rst | 96 ++++++++++++++++++++++ 2 files changed, 97 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/split_page_table_lock.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index 3e4f4cac509c..8c7d0b1e5c3e 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -36,6 +36,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） page_owner page_table_check remap_file_pages + split_page_table_lock TODOLIST: * arch_pgtable_helpers @@ -45,7 +46,6 @@ TODOLIST: * numa * page_migration * slub -* split_page_table_lock * transhuge * unevictable-lru * vmalloced-kernel-stacks diff --git a/Documentation/translations/zh_CN/vm/split_page_table_lock.rst b/Documentation/translations/zh_CN/vm/split_page_table_lock.rst new file mode 100644 index 000000000000..50694d97c426 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/split_page_table_lock.rst @@ -0,0 +1,96 @@ +:Original: Documentation/vm/split_page_table_lock.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +================================= +分页表锁（split page table lock） +================================= + +最初，mm->page_table_lock spinlock保护了mm_struct的所有页表。但是这种方 +法导致了多线程应用程序的缺页异常可扩展性差，因为对锁的争夺很激烈。为了提高可扩 +展性，我们引入了分页表锁。 + +有了分页表锁，我们就有了单独的每张表锁来顺序化对表的访问。目前，我们对PTE和 +PMD表使用分页锁。对高层表的访问由mm->page_table_lock保护。 + +有一些辅助工具来锁定/解锁一个表和其他访问器函数: + + - pte_offset_map_lock() + 映射pte并获取PTE表锁，返回所取锁的指针； + - pte_unmap_unlock() + 解锁和解映射PTE表； + - pte_alloc_map_lock() + 如果需要的话，分配PTE表并获取锁，如果分配失败，返回已获取的锁的指针 + 或NULL； + - pte_lockptr() + 返回指向PTE表锁的指针； + - pmd_lock() + 取得PMD表锁，返回所取锁的指针。 + - pmd_lockptr() + 返回指向PMD表锁的指针； + +如果CONFIG_SPLIT_PTLOCK_CPUS（通常为4）小于或等于NR_CPUS，则在编译 +时启用PTE表的分页表锁。如果分页锁被禁用，所有的表都由mm->page_table_lock +来保护。 + +如果PMD表启用了分页锁，并且架构支持它，那么PMD表的分页锁就会被启用（见 +下文）。 + +Hugetlb 和分页表锁 +================== + +Hugetlb可以支持多种页面大小。我们只对PMD级别使用分页锁，但不对PUD使用。 + +Hugetlb特定的辅助函数: + + - huge_pte_lock() + 对PMD_SIZE页面采取pmd分割锁，否则mm->page_table_lock； + - huge_pte_lockptr() + 返回指向表锁的指针。 + +架构对分页表锁的支持 +==================== + +没有必要特别启用PTE分页表锁：所有需要的东西都由pgtable_pte_page_ctor() +和pgtable_pte_page_dtor()完成，它们必须在PTE表分配/释放时被调用。 + +确保架构不使用slab分配器来分配页表：slab使用page->slab_cache来分配其页 +面。这个区域与page->ptl共享存储。 + +PMD分页锁只有在你有两个以上的页表级别时才有意义。 + +启用PMD分页锁需要在PMD表分配时调用pgtable_pmd_page_ctor()，在释放时调 +用pgtable_pmd_page_dtor()。 + +分配通常发生在pmd_alloc_one()中，释放发生在pmd_free()和pmd_free_tlb() +中，但要确保覆盖所有的PMD表分配/释放路径：即X86_PAE在pgd_alloc()中预先 +分配一些PMD。 + +一切就绪后，你可以设置CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK。 + +注意：pgtable_pte_page_ctor()和pgtable_pmd_page_ctor()可能失败--必 +须正确处理。 + +page->ptl +========= + +page->ptl用于访问分割页表锁，其中'page'是包含该表的页面struct page。它 +与page->private（以及union中的其他几个字段）共享存储。 + +为了避免增加struct page的大小并获得最佳性能，我们使用了一个技巧: + + - 如果spinlock_t适合于long，我们使用page->ptr作为spinlock，这样我们 + 就可以避免间接访问并节省一个缓存行。 + - 如果spinlock_t的大小大于long的大小，我们使用page->ptl作为spinlock_t + 的指针并动态分配它。这允许在启用DEBUG_SPINLOCK或DEBUG_LOCK_ALLOC的 + 情况下使用分页锁，但由于间接访问而多花了一个缓存行。 + +PTE表的spinlock_t分配在pgtable_pte_page_ctor()中，PMD表的spinlock_t +分配在pgtable_pmd_page_ctor()中。 + +请不要直接访问page->ptl - -使用适当的辅助函数。 -- cgit From 2154e5e7d0123a7f1da2db527c59523f00cd7d3b Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 17:59:53 +0800 Subject: docs/zh_CN: add vm z3fold translation Translate .../vm/z3fold.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/index.rst | 2 +- Documentation/translations/zh_CN/vm/z3fold.rst | 31 ++++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/z3fold.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index 8c7d0b1e5c3e..e28d0e919bfe 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -37,6 +37,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） page_table_check remap_file_pages split_page_table_lock + z3fold TODOLIST: * arch_pgtable_helpers @@ -49,5 +50,4 @@ TODOLIST: * transhuge * unevictable-lru * vmalloced-kernel-stacks -* z3fold * zsmalloc diff --git a/Documentation/translations/zh_CN/vm/z3fold.rst b/Documentation/translations/zh_CN/vm/z3fold.rst new file mode 100644 index 000000000000..57204aa08caa --- /dev/null +++ b/Documentation/translations/zh_CN/vm/z3fold.rst @@ -0,0 +1,31 @@ +:Original: Documentation/vm/z3fold.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +====== +z3fold +====== + +z3fold是一个专门用于存储压缩页的分配器。它被设计为每个物理页最多可以存储三个压缩页。 +它是zbud的衍生物，允许更高的压缩率，保持其前辈的简单性和确定性。 + +z3fold和zbud的主要区别是: + +* 与zbud不同的是，z3fold允许最大的PAGE_SIZE分配。 +* z3fold在其页面中最多可以容纳3个压缩页面 +* z3fold本身没有输出任何API，因此打算通过zpool的API来使用 + +为了保持确定性和简单性，z3fold，就像zbud一样，总是在每页存储一个整数的压缩页，但是 +它最多可以存储3页，不像zbud最多可以存储2页。因此压缩率达到2.7倍左右，而zbud的压缩 +率是1.7倍左右。 + +不像zbud（但也像zsmalloc），z3fold_alloc()那样不返回一个可重复引用的指针。相反，它 +返回一个无符号长句柄，它编码了被分配对象的实际位置。 + +保持有效的压缩率接近于zsmalloc，z3fold不依赖于MMU的启用，并提供更可预测的回收行 +为，这使得它更适合于小型和反应迅速的系统。 -- cgit From 6dbc3a5bdb46ab41d6316d32a23f8dbd3593dafc Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Mon, 28 Mar 2022 17:59:54 +0800 Subject: docs/zh_CN: add vm zsmalloc translation Translate .../vm/zsmalloc.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/index.rst | 2 +- Documentation/translations/zh_CN/vm/zsmalloc.rst | 78 ++++++++++++++++++++++++ 2 files changed, 79 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/zsmalloc.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index e28d0e919bfe..c7148125e659 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -38,6 +38,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） remap_file_pages split_page_table_lock z3fold + zsmalloc TODOLIST: * arch_pgtable_helpers @@ -50,4 +51,3 @@ TODOLIST: * transhuge * unevictable-lru * vmalloced-kernel-stacks -* zsmalloc diff --git a/Documentation/translations/zh_CN/vm/zsmalloc.rst b/Documentation/translations/zh_CN/vm/zsmalloc.rst new file mode 100644 index 000000000000..29e9c70a8eb6 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/zsmalloc.rst @@ -0,0 +1,78 @@ +:Original: Documentation/vm/zs_malloc.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + +======== +zsmalloc +======== + +这个分配器是为与zram一起使用而设计的。因此，该分配器应该在低内存条件下工作良好。特别是， +它从未尝试过higher order页面的分配，这在内存压力下很可能会失败。另一方面，如果我们只 +是使用单（0-order）页，它将遭受非常高的碎片化 - 任何大小为PAGE_SIZE/2或更大的对象将 +占据整个页面。这是其前身（xvmalloc）的主要问题之一。 + +为了克服这些问题，zsmalloc分配了一堆0-order页面，并使用各种"struct page"字段将它 +们链接起来。这些链接的页面作为一个单一的higher order页面，即一个对象可以跨越0-order +页面的边界。代码将这些链接的页面作为一个实体，称为zspage。 + +为了简单起见，zsmalloc只能分配大小不超过PAGE_SIZE的对象，因为这满足了所有当前用户的 +要求（在最坏的情况下，页面是不可压缩的，因此以"原样"即未压缩的形式存储）。对于大于这 +个大小的分配请求，会返回失败（见zs_malloc）。 + +此外，zs_malloc()并不返回一个可重复引用的指针。相反，它返回一个不透明的句柄（无符号 +长），它编码了被分配对象的实际位置。这种间接性的原因是zsmalloc并不保持zspages的永久 +映射，因为这在32位系统上会导致问题，因为内核空间映射的VA区域非常小。因此，在使用分配 +的内存之前，对象必须使用zs_map_object()进行映射以获得一个可用的指针，随后使用 +zs_unmap_object()解除映射。 + +stat +==== + +通过CONFIG_ZSMALLOC_STAT，我们可以通过 ``/sys/kernel/debug/zsmalloc/`` +看到zsmalloc内部信息。下面是一个统计输出的例子。:: + + # cat /sys/kernel/debug/zsmalloc/zram0/classes + + class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage + ... + ... + 9 176 0 1 186 129 8 4 + 10 192 1 0 2880 2872 135 3 + 11 208 0 1 819 795 42 2 + 12 224 0 1 219 159 12 4 + ... + ... + + +class + 索引 +size + zspage存储对象大小 +almost_empty + ZS_ALMOST_EMPTY zspage的数量（见下文）。 +almost_full + ZS_ALMOST_FULL zspage的数量(见下图) +obj_allocated + 已分配对象的数量 +obj_used + 分配给用户的对象的数量 +pages_used + 为该类分配的页数 +pages_per_zspage + 组成一个zspage的0-order页面的数量 + +当n <= N / f时，我们将一个zspage分配给ZS_ALMOST_EMPTYfullness组，其中 + +* n = 已分配对象的数量 +* N = zspage可以存储的对象总数 +* f = fullness_threshold_frac(即，目前是4个) + +同样地，我们将zspage分配给: + +* ZS_ALMOST_FULL when n > N / f +* ZS_EMPTY when n == 0 +* ZS_FULL when n == N -- cgit From ca3d0b5dfc6bdb4ce33330fec313e4a0afb2c3d4 Mon Sep 17 00:00:00 2001 From: Catalin Marinas Date: Thu, 24 Mar 2022 15:16:05 +0000 Subject: Documentation/process: Update ARM contact for embargoed hardware issues With Grant taking a prominent role in Linaro, I will take over as the process ambassador for ARM w.r.t. embargoed hardware issues. Signed-off-by: Catalin Marinas Cc: Grant Likely Cc: Jonathan Corbet Cc: Greg Kroah-Hartman Signed-off-by: Jonathan Corbet --- Documentation/process/embargoed-hardware-issues.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst index 6f8f36e10e8b..41a2afaaea75 100644 --- a/Documentation/process/embargoed-hardware-issues.rst +++ b/Documentation/process/embargoed-hardware-issues.rst @@ -244,7 +244,7 @@ disclosure of a particular issue, unless requested by a response team or by an involved disclosed party. The current ambassadors list: ============= ======================================================== - ARM Grant Likely + ARM Catalin Marinas AMD Tom Lendacky IBM Z Christian Borntraeger IBM Power Anton Blanchard -- cgit From 7808c934120e6ffa95c0b11d3e079cb617f195fc Mon Sep 17 00:00:00 2001 From: Markus Reichl Date: Mon, 21 Mar 2022 13:04:11 +0100 Subject: w1: w1_therm: Document Maxim MAX31850 thermoelement IF. w1_therm driver supports now MAX31850, too. Add it to documentation and fix a small typo. Signed-off-by: Markus Reichl Signed-off-by: Jonathan Corbet --- Documentation/w1/slaves/w1_therm.rst | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/w1/slaves/w1_therm.rst b/Documentation/w1/slaves/w1_therm.rst index c3c9ed7a356c..758dadba84f6 100644 --- a/Documentation/w1/slaves/w1_therm.rst +++ b/Documentation/w1/slaves/w1_therm.rst @@ -6,7 +6,8 @@ Supported chips: * Maxim ds18*20 based temperature sensors. * Maxim ds1825 based temperature sensors. - * GXCAS GC20MH01 temperature sensor. + * GXCAS GX20MH01 temperature sensor. + * Maxim MAX31850 thermoelement interface. Author: Evgeniy Polyakov @@ -15,7 +16,7 @@ Description ----------- w1_therm provides basic temperature conversion for ds18*20, ds28ea00, GX20MH01 -devices. +and MAX31850 devices. Supported family codes: @@ -137,3 +138,7 @@ bits in Config register; R2 bit in Config register enabling 13 and 14 bit resolutions. The device is powered up in 14-bit resolution mode. The conversion times specified in the datasheet are too low and have to be increased. The device supports driver features ``1`` and ``2``. + +MAX31850 device shares family number 0x3B with DS1825. The device is generally +compatible with DS1825. The higher 4 bits of Config register read all 1, +indicating 15, but the device is always operating in 14-bit resolution mode. -- cgit From d4cd2389d053d27ed00a80ddd2217791eebe3185 Mon Sep 17 00:00:00 2001 From: Chin En Lin Date: Fri, 18 Mar 2022 22:25:36 +0800 Subject: Documentation: x86: Fix obsolete name of page fault handler Since commit 91eeafea1e4b ("x86/entry: Switch page fault exception to IDTENTRY_RAW"), the function name of the page fault handler is out of date. And because of commit aa37c51b9421 ("x86/mm: Break out user address space handling"), the description of search_exception_table is not correct anymore. It may mislead the user who wants to use the documentation to figure out the page fault handler. Also, fix typo and add the parentheses after function and macro name. Signed-off-by: Chin En Lin Signed-off-by: Jonathan Corbet --- Documentation/x86/exception-tables.rst | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/x86/exception-tables.rst b/Documentation/x86/exception-tables.rst index de58110c5ffd..efde1fef4fbd 100644 --- a/Documentation/x86/exception-tables.rst +++ b/Documentation/x86/exception-tables.rst @@ -32,14 +32,14 @@ Whenever the kernel tries to access an address that is currently not accessible, the CPU generates a page fault exception and calls the page fault handler:: - void do_page_fault(struct pt_regs *regs, unsigned long error_code) + void exc_page_fault(struct pt_regs *regs, unsigned long error_code) in arch/x86/mm/fault.c. The parameters on the stack are set up by the low level assembly glue in arch/x86/entry/entry_32.S. The parameter regs is a pointer to the saved registers on the stack, error_code contains a reason code for the exception. -do_page_fault first obtains the unaccessible address from the CPU +exc_page_fault() first obtains the inaccessible address from the CPU control register CR2. If the address is within the virtual address space of the process, the fault probably occurred, because the page was not swapped in, write protected or something similar. However, @@ -57,10 +57,10 @@ Where does fixup point to? Since we jump to the contents of fixup, fixup obviously points to executable code. This code is hidden inside the user access macros. -I have picked the get_user macro defined in arch/x86/include/asm/uaccess.h +I have picked the get_user() macro defined in arch/x86/include/asm/uaccess.h as an example. The definition is somewhat hard to follow, so let's peek at the code generated by the preprocessor and the compiler. I selected -the get_user call in drivers/char/sysrq.c for a detailed examination. +the get_user() call in drivers/char/sysrq.c for a detailed examination. The original code in sysrq.c line 587:: @@ -281,12 +281,15 @@ vma occurs? > c017e7a5 movb (%ebx),%dl #. MMU generates exception -#. CPU calls do_page_fault -#. do page fault calls search_exception_table (regs->eip == c017e7a5); -#. search_exception_table looks up the address c017e7a5 in the +#. CPU calls exc_page_fault() +#. exc_page_fault() calls do_user_addr_fault() +#. do_user_addr_fault() calls kernelmode_fixup_or_oops() +#. kernelmode_fixup_or_oops() calls fixup_exception() (regs->eip == c017e7a5); +#. fixup_exception() calls search_exception_tables() +#. search_exception_tables() looks up the address c017e7a5 in the exception table (i.e. the contents of the ELF section __ex_table) and returns the address of the associated fault handle code c0199ff5. -#. do_page_fault modifies its own return address to point to the fault +#. fixup_exception() modifies its own return address to point to the fault handle code and returns. #. execution continues in the fault handling code. #. a) EAX becomes -EFAULT (== -14) @@ -298,9 +301,9 @@ The steps 8a to 8c in a certain way emulate the faulting instruction. That's it, mostly. If you look at our example, you might ask why we set EAX to -EFAULT in the exception handler code. Well, the -get_user macro actually returns a value: 0, if the user access was +get_user() macro actually returns a value: 0, if the user access was successful, -EFAULT on failure. Our original code did not test this -return value, however the inline assembly code in get_user tries to +return value, however the inline assembly code in get_user() tries to return -EFAULT. GCC selected EAX to return this value. NOTE: -- cgit From 0dc089481308f0acf6bfd722df9d6fed2f534d5d Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Thu, 17 Mar 2022 10:59:14 +0800 Subject: docs/zh_CN: Add sched-debug Chinese translation Translate scheduler/sched-debug.rst into Chinese. Signed-off-by: Tang Yizhou Reviewed-by: Alex Shi Reviewed-by: Yanteng Si Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/scheduler/index.rst | 1 + .../translations/zh_CN/scheduler/sched-debug.rst | 51 ++++++++++++++++++++++ 2 files changed, 52 insertions(+) create mode 100644 Documentation/translations/zh_CN/scheduler/sched-debug.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/scheduler/index.rst b/Documentation/translations/zh_CN/scheduler/index.rst index 12bf3bd02ccf..5c0e07aee299 100644 --- a/Documentation/translations/zh_CN/scheduler/index.rst +++ b/Documentation/translations/zh_CN/scheduler/index.rst @@ -27,6 +27,7 @@ Linux调度器 sched-energy sched-nice-design sched-stats + sched-debug TODOList: diff --git a/Documentation/translations/zh_CN/scheduler/sched-debug.rst b/Documentation/translations/zh_CN/scheduler/sched-debug.rst new file mode 100644 index 000000000000..5e17740c2bf3 --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/sched-debug.rst @@ -0,0 +1,51 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/sched-debug.rst + +:翻译: + + 唐艺舟 Tang Yizhou + +============= +调度器debugfs +============= + +用配置项CONFIG_SCHED_DEBUG=y启动内核后，将可以访问/sys/kernel/debug/sched +下的调度器专用调试文件。其中一些文件描述如下。 + +numa_balancing +============== + +`numa_balancing` 目录用来存放控制非统一内存访问（NUMA）平衡特性的相关文件。 +如果该特性导致系统负载太高，那么可以通过 `scan_period_min_ms, scan_delay_ms, +scan_period_max_ms, scan_size_mb` 文件控制NUMA缺页的内核采样速率。 + + +scan_period_min_ms, scan_delay_ms, scan_period_max_ms, scan_size_mb +------------------------------------------------------------------- + +自动NUMA平衡会扫描任务地址空间，检测页面是否被正确放置，或者数据是否应该被 +迁移到任务正在运行的本地内存结点，此时需解映射页面。每个“扫描延迟”（scan delay） +时间之后，任务扫描其地址空间中下一批“扫描大小”（scan size）个页面。若抵达 +内存地址空间末尾，扫描器将从头开始重新扫描。 + +结合来看，“扫描延迟”和“扫描大小”决定扫描速率。当“扫描延迟”减小时，扫描速率 +增加。“扫描延迟”和每个任务的扫描速率都是自适应的，且依赖历史行为。如果页面被 +正确放置，那么扫描延迟就会增加；否则扫描延迟就会减少。“扫描大小”不是自适应的， +“扫描大小”越大，扫描速率越高。 + +更高的扫描速率会产生更高的系统开销，因为必须捕获缺页异常，并且潜在地必须迁移 +数据。然而，当扫描速率越高，若工作负载模式发生变化，任务的内存将越快地迁移到 +本地结点，由于远程内存访问而产生的性能影响将降到最低。下面这些文件控制扫描延迟 +的阈值和被扫描的页面数量。 + +``scan_period_min_ms`` 是扫描一个任务虚拟内存的最小时间，单位是毫秒。它有效地 +控制了每个任务的最大扫描速率。 + +``scan_delay_ms`` 是一个任务初始化创建（fork）时，第一次使用的“扫描延迟”。 + +``scan_period_max_ms`` 是扫描一个任务虚拟内存的最大时间，单位是毫秒。它有效地 +控制了每个任务的最小扫描速率。 + +``scan_size_mb`` 是一次特定的扫描中，要扫描多少兆字节（MB）对应的页面数。 -- cgit From 4407cca0109c47da912d1035b5ed344ac85eed32 Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Tue, 29 Mar 2022 15:23:58 +0800 Subject: docs/zh_CN: Add schedutil Chinese translation Translate scheduler/schedutil.rst into Chinese. Signed-off-by: Tang Yizhou Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/scheduler/index.rst | 1 + .../translations/zh_CN/scheduler/schedutil.rst | 165 +++++++++++++++++++++ 2 files changed, 166 insertions(+) create mode 100644 Documentation/translations/zh_CN/scheduler/schedutil.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/scheduler/index.rst b/Documentation/translations/zh_CN/scheduler/index.rst index 5c0e07aee299..a8eaa7325f54 100644 --- a/Documentation/translations/zh_CN/scheduler/index.rst +++ b/Documentation/translations/zh_CN/scheduler/index.rst @@ -25,6 +25,7 @@ Linux调度器 sched-domains sched-capacity sched-energy + schedutil sched-nice-design sched-stats sched-debug diff --git a/Documentation/translations/zh_CN/scheduler/schedutil.rst b/Documentation/translations/zh_CN/scheduler/schedutil.rst new file mode 100644 index 000000000000..d1ea68007520 --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/schedutil.rst @@ -0,0 +1,165 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/schedutil.rst + +:翻译: + + 唐艺舟 Tang Yizhou + +========= +Schedutil +========= + +.. note:: + + 本文所有内容都假设频率和工作算力之间存在线性关系。我们知道这是有瑕疵的， + 但这是最可行的近似处理。 + +PELT（实体负载跟踪，Per Entity Load Tracking） +============================================== + +通过PELT，我们跟踪了各种调度器实体的一些指标，从单个任务到任务组分片到CPU +运行队列。我们使用指数加权移动平均数（Exponentially Weighted Moving Average， +EWMA）作为其基础，每个周期（1024us）都会衰减，衰减速率满足y^32 = 0.5。 +也就是说，最近的32ms贡献负载的一半，而历史上的其它时间则贡献另一半。 + +具体而言： + + ewma_sum(u) := u_0 + u_1*y + u_2*y^2 + ... + + ewma(u) = ewma_sum(u) / ewma_sum(1) + +由于这本质上是一个无限几何级数的累加，结果是可组合的，即ewma(A) + ewma(B) = ewma(A+B)。 +这个属性是关键，因为它提供了在任务迁移时重新组合平均数的能力。 + +请注意，阻塞态的任务仍然对累加值（任务组分片和CPU运行队列）有贡献，这反映了 +它们在恢复运行后的预期贡献。 + +利用这一点，我们跟踪2个关键指标：“运行”和“可运行”。“运行”反映了一个调度实体 +在CPU上花费的时间，而“可运行”反映了一个调度实体在运行队列中花费的时间。当只有 +一个任务时，这两个指标是相同的，但一旦出现对CPU的争用，“运行”将减少以反映每个 +任务在CPU上花费的时间，而“可运行”将增加以反映争用的激烈程度。 + +更多细节见：kernel/sched/pelt.c + + +频率 / CPU不变性 +================ + +因为CPU频率在1GHz时利用率为50%和CPU频率在2GHz时利用率为50%是不一样的，同样 +在小核上运行时利用率为50%和在大核上运行时利用率为50%是不一样的，我们允许架构 +以两个比率来伸缩时间差，其中一个是动态电压频率升降（Dynamic Voltage and +Frequency Scaling，DVFS）比率，另一个是微架构比率。 + +对于简单的DVFS架构（软件有完全控制能力），我们可以很容易地计算该比率为:: + + f_cur + r_dvfs := ----- + f_max + +对于由硬件控制DVFS的更多动态系统，我们使用硬件计数器（Intel APERF/MPERF， +ARMv8.4-AMU）来计算这一比率。具体到Intel，我们使用:: + + APERF + f_cur := ----- * P0 + MPERF + + 4C-turbo; 如果可用并且使能了turbo + f_max := { 1C-turbo; 如果使能了turbo + P0; 其它情况 + + f_cur + r_dvfs := min( 1, ----- ) + f_max + +我们选择4C turbo而不是1C turbo，以使其更持久性略微更强。 + +r_cpu被定义为当前CPU的最高性能水平与系统中任何其它CPU的最高性能水平的比率。 + + r_tot = r_dvfs * r_cpu + +其结果是，上述“运行”和“可运行”的指标变成DVFS无关和CPU型号无关了。也就是说， +我们可以在CPU之间转移和比较它们。 + +更多细节见: + + - kernel/sched/pelt.h:update_rq_clock_pelt() + - arch/x86/kernel/smpboot.c:"APERF/MPERF frequency ratio computation." + - Documentation/translations/zh_CN/scheduler/sched-capacity.rst:"1. CPU Capacity + 2. Task utilization" + + +UTIL_EST / UTIL_EST_FASTUP +========================== + +由于周期性任务的平均数在睡眠时会衰减，而在运行时其预期利用率会和睡眠前相同， +因此它们在再次运行后会面临（DVFS）的上涨。 + +为了缓解这个问题，（一个默认使能的编译选项）UTIL_EST驱动一个无限脉冲响应 +（Infinite Impulse Response，IIR）的EWMA，“运行”值在出队时是最高的。 +另一个默认使能的编译选项UTIL_EST_FASTUP修改了IIR滤波器，使其允许立即增加， +仅在利用率下降时衰减。 + +进一步，运行队列的（可运行任务的）利用率之和由下式计算： + + util_est := \Sum_t max( t_running, t_util_est_ewma ) + +更多细节见: kernel/sched/fair.c:util_est_dequeue() + + +UCLAMP +====== + +可以在每个CFS或RT任务上设置有效的u_min和u_max clamp值（译注：clamp可以理解 +为类似滤波器的能力，它定义了有效取值范围的最大值和最小值）；运行队列为所有正在 +运行的任务保持这些clamp的最大聚合值。 + +更多细节见: include/uapi/linux/sched/types.h + + +Schedutil / DVFS +================ + +每当调度器的负载跟踪被更新时（任务唤醒、任务迁移、时间流逝），我们都会调用 +schedutil来更新硬件DVFS状态。 + +其基础是CPU运行队列的“运行”指标，根据上面的内容，它是CPU的频率不变的利用率 +估计值。由此我们计算出一个期望的频率，如下:: + + max( running, util_est ); 如果使能UTIL_EST + u_cfs := { running; 其它情况 + + clamp( u_cfs + u_rt, u_min, u_max ); 如果使能UCLAMP_TASK + u_clamp := { u_cfs + u_rt; 其它情况 + + u := u_clamp + u_irq + u_dl; [估计值。更多细节见源代码] + + f_des := min( f_max, 1.25 u * f_max ) + +关于IO-wait的说明：当发生更新是因为任务从IO完成中唤醒时，我们提升上面的“u”。 + +然后，这个频率被用来选择一个P-state或OPP，或者直接混入一个发给硬件的CPPC式 +请求。 + +关于截止期限调度器的说明: 截止期限任务（偶发任务模型）使我们能够计算出满足 +工作负荷所需的硬f_min值。 + +因为这些回调函数是直接来自调度器的，所以DVFS的硬件交互应该是“快速”和非阻塞的。 +在硬件交互缓慢和昂贵的时候，schedutil支持DVFS请求限速，不过会降低效率。 + +更多信息见: kernel/sched/cpufreq_schedutil.c + + +注意 +==== + + - 在低负载场景下，DVFS是最相关的，“运行”的值将密切反映利用率。 + + - 在负载饱和的场景下，任务迁移会导致一些瞬时性的使用率下降。假设我们有一个 + CPU，有4个任务占用导致其饱和，接下来我们将一个任务迁移到另一个空闲CPU上， + 旧的CPU的“运行”值将为0.75，而新的CPU将获得0.25。这是不可避免的，而且随着 + 时间流逝将自动修正。另注，由于没有空闲时间，我们还能保证f_max值吗？ + + - 上述大部分内容是关于避免DVFS下滑，以及独立的DVFS域发生负载迁移时不得不 + 重新学习/提升频率。 + -- cgit From 72661ff7662acc00d51976d4b2d2d13eb5628385 Mon Sep 17 00:00:00 2001 From: Richard Fitzgerald Date: Tue, 5 Apr 2022 14:54:18 +0100 Subject: ASoC: dt-bindings: cs35l45: Cirrus Logic CS35L45 Smart Amp This adds the schema binding for the Cirrus Logic CS35L45 Smart Amp and associated header file. Signed-off-by: Richard Fitzgerald Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220405135419.1230088-5-rf@opensource.cirrus.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/cirrus,cs35l45.yaml | 75 ++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml new file mode 100644 index 000000000000..184a1344ea76 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/cirrus,cs35l45.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic CS35L45 Speaker Amplifier + +maintainers: + - Ricardo Rivera-Matos + - Richard Fitzgerald + +description: | + CS35L45 is a Boosted Mono Class D Amplifier with DSP + Speaker Protection and Adaptive Battery Management. + +properties: + compatible: + enum: + - cirrus,cs35l45 + + reg: + maxItems: 1 + + '#sound-dai-cells': + const: 1 + + reset-gpios: + maxItems: 1 + + vdd-a-supply: + description: voltage regulator phandle for the VDD_A supply + + vdd-batt-supply: + description: voltage regulator phandle for the VDD_BATT supply + + spi-max-frequency: + maximum: 5000000 + + cirrus,asp-sdout-hiz-ctrl: + description: + Audio serial port SDOUT Hi-Z control. Sets the Hi-Z + configuration for SDOUT pin of amplifier. Logical OR of + CS35L45_ASP_TX_HIZ_xxx values. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 3 + default: 2 + +required: + - compatible + - reg + - "#sound-dai-cells" + +additionalProperties: false + +examples: + - | + #include + spi { + #address-cells = <1>; + #size-cells = <0>; + + cs35l45: cs35l45@2 { + #sound-dai-cells = <1>; + compatible = "cirrus,cs35l45"; + reg = <2>; + spi-max-frequency = <5000000>; + vdd-a-supply = <&dummy_vreg>; + vdd-batt-supply = <&dummy_vreg>; + reset-gpios = <&gpio 110 0>; + cirrus,asp-sdout-hiz-ctrl = <(CS35L45_ASP_TX_HIZ_UNUSED | + CS35L45_ASP_TX_HIZ_DISABLED)>; + }; + }; -- cgit From 852fda58d99a6c397f8303a8cd8ccec8702d82f5 Mon Sep 17 00:00:00 2001 From: Srinivasa Rao Mandadapu Date: Mon, 21 Mar 2022 14:26:19 +0530 Subject: ASoC: qcom: dt-bindings: Update bindings for clocks in lpass digital codes Update dt-bindings for clocks as per ADSP bypass solutions, in which macro dcodec GDSCs are enabled using power domains in lpass digital codec drivers. Signed-off-by: Srinivasa Rao Mandadapu Co-developed-by: Venkata Prasad Potturu Signed-off-by: Venkata Prasad Potturu Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1647852981-27895-2-git-send-email-quic_srivasam@quicinc.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/qcom,lpass-rx-macro.yaml | 17 +++++++++++------ .../devicetree/bindings/sound/qcom,lpass-tx-macro.yaml | 17 +++++++++++------ .../devicetree/bindings/sound/qcom,lpass-va-macro.yaml | 11 +++++++---- 3 files changed, 29 insertions(+), 16 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml index 6127df5836c2..a6905bcf89d2 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml @@ -28,12 +28,17 @@ properties: maxItems: 5 clock-names: - items: - - const: mclk - - const: npl - - const: macro - - const: dcodec - - const: fsgen + oneOf: + - items: #for ADSP based platforms + - const: mclk + - const: npl + - const: macro + - const: dcodec + - const: fsgen + - items: #for ADSP bypass based platforms + - const: mclk + - const: npl + - const: fsgen clock-output-names: items: diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml index 3f0f99cb18ca..324595a62ae8 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml @@ -28,12 +28,17 @@ properties: maxItems: 5 clock-names: - items: - - const: mclk - - const: npl - - const: macro - - const: dcodec - - const: fsgen + oneOf: + - items: #for ADSP based platforms + - const: mclk + - const: npl + - const: macro + - const: dcodec + - const: fsgen + - items: #for ADSP bypass based platforms + - const: mclk + - const: npl + - const: fsgen clock-output-names: items: diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml index 9868a5ebe27e..7b4cc84eda8c 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml @@ -28,10 +28,13 @@ properties: maxItems: 3 clock-names: - items: - - const: mclk - - const: core - - const: dcodec + oneOf: + - items: #for ADSP based platforms + - const: mclk + - const: core + - const: dcodec + - items: #for ADSP bypass based platforms + - const: mclk clock-output-names: items: -- cgit From 9108c3446f6e86146f0d3141b94415eb98c39566 Mon Sep 17 00:00:00 2001 From: Srinivasa Rao Mandadapu Date: Mon, 21 Mar 2022 14:26:20 +0530 Subject: ASoC: dt-bindings: wcd938x: Add mic bias supply property Add vdd mic bias supply, which is required to provide bias for wcd938x codec. Signed-off-by: Srinivasa Rao Mandadapu Co-developed-by: Venkata Prasad Potturu Signed-off-by: Venkata Prasad Potturu Acked-by: Rob Herring Link: https://lore.kernel.org/r/1647852981-27895-3-git-send-email-quic_srivasam@quicinc.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml index 7bf1a5fffcd2..51547190f709 100644 --- a/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml @@ -36,6 +36,9 @@ properties: vdd-io-supply: description: A reference to the 1.8V I/O supply + vdd-mic-bias-supply: + description: A reference to the 3.8V mic bias supply + qcom,tx-device: $ref: /schemas/types.yaml#/definitions/phandle-array description: A reference to Soundwire tx device phandle -- cgit From 98b7630a583fe970f59742dc855d1c03e258d645 Mon Sep 17 00:00:00 2001 From: Srinivasa Rao Mandadapu Date: Mon, 21 Mar 2022 14:26:21 +0530 Subject: ASoC: dt-bindings: lpass-cpu: Update clocks and power domain names for sc7280 platform Update required clock-names used for MI2S primary path, VA macro's codec memory path and HDMI path in sc7280 based platforms. Update power domain names required for sc7280 platforms. Signed-off-by: Srinivasa Rao Mandadapu Co-developed-by: Venkata Prasad Potturu Signed-off-by: Venkata Prasad Potturu Link: https://lore.kernel.org/r/1647852981-27895-4-git-send-email-quic_srivasam@quicinc.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml index 2c81efb5fa37..e9a533080b32 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml @@ -38,8 +38,8 @@ properties: maxItems: 7 clock-names: - minItems: 3 - maxItems: 7 + minItems: 1 + maxItems: 10 interrupts: minItems: 2 @@ -62,6 +62,9 @@ properties: power-domains: maxItems: 1 + power-domain-names: + maxItems: 1 + '#sound-dai-cells': const: 1 @@ -192,15 +195,19 @@ allOf: oneOf: - items: #for I2S - const: aon_cc_audio_hm_h + - const: audio_cc_ext_mclk0 - const: core_cc_sysnoc_mport_core + - const: core_cc_ext_if0_ibit - const: core_cc_ext_if1_ibit - items: #for Soundwire - const: aon_cc_audio_hm_h + - const: audio_cc_codec_mem - const: audio_cc_codec_mem0 - const: audio_cc_codec_mem1 - const: audio_cc_codec_mem2 + - const: aon_cc_va_mem0 - items: #for HDMI - - const: aon_cc_audio_hm_h + - const: core_cc_sysnoc_mport_core reg-names: anyOf: @@ -228,6 +235,10 @@ allOf: - const: lpass-irq-hdmi - const: lpass-irq-vaif - const: lpass-irq-rxtxif + power-domain-names: + allOf: + - items: + - const: lcx required: - iommus -- cgit From b2fa90ef62558ed65f09201b4c8b79ece4468275 Mon Sep 17 00:00:00 2001 From: Christophe Leroy Date: Thu, 31 Mar 2022 12:13:10 +0200 Subject: powerpc/85xx: Remove fsl,85... bindings Since 8a4ab218ef70 ("powerpc/85xx: Change deprecated binding for 85xx-based boards") those bindings are not used anymore. A comment in drivers/edac/mpc85xx_edac.c say they are to be removed with kernel 2.6.30. Remove them now. Signed-off-by: Christophe Leroy Signed-off-by: Borislav Petkov Acked-by: Krzysztof Kozlowski Acked-by: Scott Wood Link: https://lore.kernel.org/r/82a8bc4450a4daee50ee5fada75621fecb3703ff.1648721299.git.christophe.leroy@csgroup.eu --- .../devicetree/bindings/memory-controllers/fsl/fsl,ddr.yaml | 6 ------ Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt | 6 ------ 2 files changed, 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ddr.yaml b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ddr.yaml index af5147f9da72..84f778a99546 100644 --- a/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ddr.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ddr.yaml @@ -25,12 +25,6 @@ properties: - const: fsl,qoriq-memory-controller - enum: - fsl,bsc9132-memory-controller - - fsl,8540-memory-controller - - fsl,8541-memory-controller - - fsl,8544-memory-controller - - fsl,8548-memory-controller - - fsl,8555-memory-controller - - fsl,8568-memory-controller - fsl,mpc8536-memory-controller - fsl,mpc8540-memory-controller - fsl,mpc8541-memory-controller diff --git a/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt b/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt index 8a70696395a7..22ad012660e9 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt @@ -6,12 +6,6 @@ The cache bindings explained below are Devicetree Specification compliant Required Properties: - compatible : Should include one of the following: - "fsl,8540-l2-cache-controller" - "fsl,8541-l2-cache-controller" - "fsl,8544-l2-cache-controller" - "fsl,8548-l2-cache-controller" - "fsl,8555-l2-cache-controller" - "fsl,8568-l2-cache-controller" "fsl,b4420-l2-cache-controller" "fsl,b4860-l2-cache-controller" "fsl,bsc9131-l2-cache-controller" -- cgit From 4a5fb1bbcdf1cccae1f6b9c0277b3796b2a468ef Mon Sep 17 00:00:00 2001 From: Jérôme Pouiller Date: Sat, 26 Feb 2022 10:21:42 +0100 Subject: wfx: get out from the staging area MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The wfx driver is now mature enough to leave the staging area. Signed-off-by: Jérôme Pouiller Signed-off-by: Kalle Valo --- .../bindings/net/wireless/silabs,wfx.yaml | 137 +++++++++++++++++++++ .../bindings/staging/net/wireless/silabs,wfx.yaml | 137 --------------------- 2 files changed, 137 insertions(+), 137 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml delete mode 100644 Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml b/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml new file mode 100644 index 000000000000..f5a531738d93 --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020, Silicon Laboratories, Inc. +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/net/wireless/silabs,wfx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silicon Labs WFxxx devicetree bindings + +maintainers: + - Jérôme Pouiller + +description: > + Support for the Wifi chip WFxxx from Silicon Labs. Currently, the only device + from the WFxxx series is the WF200 described here: + https://www.silabs.com/documents/public/data-sheets/wf200-datasheet.pdf + + The WF200 can be connected via SPI or via SDIO. + + For SDIO: + + Declaring the WFxxx chip in device tree is mandatory (usually, the VID/PID is + sufficient for the SDIO devices). + + It is recommended to declare a mmc-pwrseq on SDIO host above WFx. Without + it, you may encounter issues during reboot. The mmc-pwrseq should be + compatible with mmc-pwrseq-simple. Please consult + Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml for more + information. + + For SPI: + + In add of the properties below, please consult + Documentation/devicetree/bindings/spi/spi-controller.yaml for optional SPI + related properties. + +properties: + compatible: + items: + - enum: + - silabs,brd4001a # WGM160P Evaluation Board + - silabs,brd8022a # WF200 Evaluation Board + - silabs,brd8023a # WFM200 Evaluation Board + - const: silabs,wf200 # Chip alone without antenna + + reg: + description: + When used on SDIO bus, must be set to 1. When used on SPI bus, it is + the chip select address of the device as defined in the SPI devices + bindings. + maxItems: 1 + + spi-max-frequency: true + + interrupts: + description: The interrupt line. Should be IRQ_TYPE_EDGE_RISING. When SPI is + used, this property is required. When SDIO is used, the "in-band" + interrupt provided by the SDIO bus is used unless an interrupt is defined + in the Device Tree. + maxItems: 1 + + reset-gpios: + description: (SPI only) Phandle of gpio that will be used to reset chip + during probe. Without this property, you may encounter issues with warm + boot. + + For SDIO, the reset gpio should declared using a mmc-pwrseq. + maxItems: 1 + + wakeup-gpios: + description: Phandle of gpio that will be used to wake-up chip. Without this + property, driver will disable most of power saving features. + maxItems: 1 + + silabs,antenna-config-file: + $ref: /schemas/types.yaml#/definitions/string + description: Use an alternative file for antenna configuration (aka + "Platform Data Set" in Silabs jargon). Default depends of "compatible" + string. For "silabs,wf200", the default is 'wf200.pds'. + + local-mac-address: true + + mac-address: true + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + #include + #include + + spi { + #address-cells = <1>; + #size-cells = <0>; + + wifi@0 { + compatible = "silabs,brd8022a", "silabs,wf200"; + pinctrl-names = "default"; + pinctrl-0 = <&wfx_irq &wfx_gpios>; + reg = <0>; + interrupts-extended = <&gpio 16 IRQ_TYPE_EDGE_RISING>; + wakeup-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>; + spi-max-frequency = <42000000>; + }; + }; + + - | + #include + #include + + wfx_pwrseq: wfx_pwrseq { + compatible = "mmc-pwrseq-simple"; + pinctrl-names = "default"; + pinctrl-0 = <&wfx_reset>; + reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>; + }; + + mmc { + mmc-pwrseq = <&wfx_pwrseq>; + #address-cells = <1>; + #size-cells = <0>; + + wifi@1 { + compatible = "silabs,brd8022a", "silabs,wf200"; + pinctrl-names = "default"; + pinctrl-0 = <&wfx_wakeup>; + reg = <1>; + wakeup-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml b/Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml deleted file mode 100644 index 105725a127ab..000000000000 --- a/Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml +++ /dev/null @@ -1,137 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -# Copyright (c) 2020, Silicon Laboratories, Inc. -%YAML 1.2 ---- - -$id: http://devicetree.org/schemas/staging/net/wireless/silabs,wfx.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Silicon Labs WFxxx devicetree bindings - -maintainers: - - Jérôme Pouiller - -description: > - Support for the Wifi chip WFxxx from Silicon Labs. Currently, the only device - from the WFxxx series is the WF200 described here: - https://www.silabs.com/documents/public/data-sheets/wf200-datasheet.pdf - - The WF200 can be connected via SPI or via SDIO. - - For SDIO: - - Declaring the WFxxx chip in device tree is mandatory (usually, the VID/PID is - sufficient for the SDIO devices). - - It is recommended to declare a mmc-pwrseq on SDIO host above WFx. Without - it, you may encounter issues during reboot. The mmc-pwrseq should be - compatible with mmc-pwrseq-simple. Please consult - Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml for more - information. - - For SPI: - - In add of the properties below, please consult - Documentation/devicetree/bindings/spi/spi-controller.yaml for optional SPI - related properties. - -properties: - compatible: - items: - - enum: - - silabs,brd4001a # WGM160P Evaluation Board - - silabs,brd8022a # WF200 Evaluation Board - - silabs,brd8023a # WFM200 Evaluation Board - - const: silabs,wf200 # Chip alone without antenna - - reg: - description: - When used on SDIO bus, must be set to 1. When used on SPI bus, it is - the chip select address of the device as defined in the SPI devices - bindings. - maxItems: 1 - - spi-max-frequency: true - - interrupts: - description: The interrupt line. Should be IRQ_TYPE_EDGE_RISING. When SPI is - used, this property is required. When SDIO is used, the "in-band" - interrupt provided by the SDIO bus is used unless an interrupt is defined - in the Device Tree. - maxItems: 1 - - reset-gpios: - description: (SPI only) Phandle of gpio that will be used to reset chip - during probe. Without this property, you may encounter issues with warm - boot. - - For SDIO, the reset gpio should declared using a mmc-pwrseq. - maxItems: 1 - - wakeup-gpios: - description: Phandle of gpio that will be used to wake-up chip. Without this - property, driver will disable most of power saving features. - maxItems: 1 - - silabs,antenna-config-file: - $ref: /schemas/types.yaml#/definitions/string - description: Use an alternative file for antenna configuration (aka - "Platform Data Set" in Silabs jargon). Default depends of "compatible" - string. For "silabs,wf200", the default is 'wf200.pds'. - - local-mac-address: true - - mac-address: true - -additionalProperties: false - -required: - - compatible - - reg - -examples: - - | - #include - #include - - spi { - #address-cells = <1>; - #size-cells = <0>; - - wifi@0 { - compatible = "silabs,brd8022a", "silabs,wf200"; - pinctrl-names = "default"; - pinctrl-0 = <&wfx_irq &wfx_gpios>; - reg = <0>; - interrupts-extended = <&gpio 16 IRQ_TYPE_EDGE_RISING>; - wakeup-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>; - spi-max-frequency = <42000000>; - }; - }; - - - | - #include - #include - - wfx_pwrseq: wfx_pwrseq { - compatible = "mmc-pwrseq-simple"; - pinctrl-names = "default"; - pinctrl-0 = <&wfx_reset>; - reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>; - }; - - mmc { - mmc-pwrseq = <&wfx_pwrseq>; - #address-cells = <1>; - #size-cells = <0>; - - wifi@1 { - compatible = "silabs,brd8022a", "silabs,wf200"; - pinctrl-names = "default"; - pinctrl-0 = <&wfx_wakeup>; - reg = <1>; - wakeup-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>; - }; - }; -... -- cgit From 9f04b55f003ccd00cf5e47bfb4116457f591d6de Mon Sep 17 00:00:00 2001 From: Oliver Glitta Date: Tue, 8 Jun 2021 10:45:17 +0200 Subject: slab, documentation: add description of debugfs files for SLUB caches Add description of debugfs files alloc_traces and free_traces to SLUB cache documentation. [ vbabka@suse.cz: some rewording ] Signed-off-by: Oliver Glitta Signed-off-by: Vlastimil Babka Cc: Jonathan Corbet Cc: Randy Dunlap Cc: linux-doc@vger.kernel.org Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Acked-by: Mike Rapoport Acked-by: David Rientjes --- Documentation/vm/slub.rst | 64 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) (limited to 'Documentation') diff --git a/Documentation/vm/slub.rst b/Documentation/vm/slub.rst index d3028554b1e9..43063ade737a 100644 --- a/Documentation/vm/slub.rst +++ b/Documentation/vm/slub.rst @@ -384,5 +384,69 @@ c) Execute ``slabinfo-gnuplot.sh`` in '-t' mode, passing all of the 40,60`` range will plot only samples collected between 40th and 60th seconds). + +DebugFS files for SLUB +====================== + +For more information about current state of SLUB caches with the user tracking +debug option enabled, debugfs files are available, typically under +/sys/kernel/debug/slab// (created only for caches with enabled user +tracking). There are 2 types of these files with the following debug +information: + +1. alloc_traces:: + + Prints information about unique allocation traces of the currently + allocated objects. The output is sorted by frequency of each trace. + + Information in the output: + Number of objects, allocating function, minimal/average/maximal jiffies since alloc, + pid range of the allocating processes, cpu mask of allocating cpus, and stack trace. + + Example::: + + 1085 populate_error_injection_list+0x97/0x110 age=166678/166680/166682 pid=1 cpus=1:: + __slab_alloc+0x6d/0x90 + kmem_cache_alloc_trace+0x2eb/0x300 + populate_error_injection_list+0x97/0x110 + init_error_injection+0x1b/0x71 + do_one_initcall+0x5f/0x2d0 + kernel_init_freeable+0x26f/0x2d7 + kernel_init+0xe/0x118 + ret_from_fork+0x22/0x30 + + +2. free_traces:: + + Prints information about unique freeing traces of the currently allocated + objects. The freeing traces thus come from the previous life-cycle of the + objects and are reported as not available for objects allocated for the first + time. The output is sorted by frequency of each trace. + + Information in the output: + Number of objects, freeing function, minimal/average/maximal jiffies since free, + pid range of the freeing processes, cpu mask of freeing cpus, and stack trace. + + Example::: + + 1980 age=4294912290 pid=0 cpus=0 + 51 acpi_ut_update_ref_count+0x6a6/0x782 age=236886/237027/237772 pid=1 cpus=1 + kfree+0x2db/0x420 + acpi_ut_update_ref_count+0x6a6/0x782 + acpi_ut_update_object_reference+0x1ad/0x234 + acpi_ut_remove_reference+0x7d/0x84 + acpi_rs_get_prt_method_data+0x97/0xd6 + acpi_get_irq_routing_table+0x82/0xc4 + acpi_pci_irq_find_prt_entry+0x8e/0x2e0 + acpi_pci_irq_lookup+0x3a/0x1e0 + acpi_pci_irq_enable+0x77/0x240 + pcibios_enable_device+0x39/0x40 + do_pci_enable_device.part.0+0x5d/0xe0 + pci_enable_device_flags+0xfc/0x120 + pci_enable_device+0x13/0x20 + virtio_pci_probe+0x9e/0x170 + local_pci_probe+0x48/0x80 + pci_device_probe+0x105/0x1c0 + Christoph Lameter, May 30, 2007 Sergey Senozhatsky, October 23, 2015 -- cgit From cab802b7b8c9eea6fe30161dab77a05d20d76195 Mon Sep 17 00:00:00 2001 From: Necip Fazil Yildiran Date: Tue, 5 Apr 2022 00:33:51 -0400 Subject: docs: kbuild: add references on Kconfig semantics Add references to 1) a research paper which provides a definition of Kconfig semantics, 2) the kismet tool, which checks for unmet direct dependency bugs in Kconfig specifications. Signed-off-by: Paul Gazzillo Signed-off-by: Necip Fazil Yildiran Signed-off-by: Masahiro Yamada --- Documentation/kbuild/kconfig-language.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst index 93a5b6e1fabd..a7173843a294 100644 --- a/Documentation/kbuild/kconfig-language.rst +++ b/Documentation/kbuild/kconfig-language.rst @@ -693,6 +693,8 @@ in documenting basic Kconfig syntax a more precise definition of Kconfig semantics is welcomed. One project deduced Kconfig semantics through the use of the xconfig configurator [1]_. Work should be done to confirm if the deduced semantics matches our intended Kconfig design goals. +Another project formalized a denotational semantics of a core subset of +the Kconfig language [10]_. Having well defined semantics can be useful for tools for practical evaluation of dependencies, for instance one such case was work to @@ -700,6 +702,8 @@ express in boolean abstraction of the inferred semantics of Kconfig to translate Kconfig logic into boolean formulas and run a SAT solver on this to find dead code / features (always inactive), 114 dead features were found in Linux using this methodology [1]_ (Section 8: Threats to validity). +The kismet tool, based on the semantics in [10]_, finds abuses of reverse +dependencies and has led to dozens of committed fixes to Linux Kconfig files [11]_. Confirming this could prove useful as Kconfig stands as one of the leading industrial variability modeling languages [1]_ [2]_. Its study would help @@ -738,3 +742,5 @@ https://kernelnewbies.org/KernelProjects/kconfig-sat .. [7] https://vamos.cs.fau.de .. [8] https://undertaker.cs.fau.de .. [9] https://www4.cs.fau.de/Publications/2011/tartler_11_eurosys.pdf +.. [10] https://paulgazzillo.com/papers/esecfse21.pdf +.. [11] https://github.com/paulgazz/kmax -- cgit From dc48f04fd6562de6019e9fc7ed9ed539d632babb Mon Sep 17 00:00:00 2001 From: Andy Chiu Date: Tue, 5 Apr 2022 17:19:28 +0800 Subject: dt-bindings: net: add pcs-handle attribute Document the new pcs-handle attribute to support connecting to an external PHY. For Xilinx's AXI Ethernet, this is used when the core operates in SGMII or 1000Base-X modes and links through the internal PCS/PMA PHY. Signed-off-by: Andy Chiu Reviewed-by: Greentime Hu Reviewed-by: Rob Herring Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/ethernet-controller.yaml | 6 ++++++ Documentation/devicetree/bindings/net/xilinx_axienet.txt | 8 +++++++- 2 files changed, 13 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index 817794e56227..4f15463611f8 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -106,6 +106,12 @@ properties: phy-mode: $ref: "#/properties/phy-connection-type" + pcs-handle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Specifies a reference to a node representing a PCS PHY device on a MDIO + bus to link with an external PHY (phy-handle) if exists. + phy-handle: $ref: /schemas/types.yaml#/definitions/phandle description: diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt b/Documentation/devicetree/bindings/net/xilinx_axienet.txt index b8e4894bc634..1aa4c6006cd0 100644 --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt @@ -26,7 +26,8 @@ Required properties: specified, the TX/RX DMA interrupts should be on that node instead, and only the Ethernet core interrupt is optionally specified here. -- phy-handle : Should point to the external phy device. +- phy-handle : Should point to the external phy device if exists. Pointing + this to the PCS/PMA PHY is deprecated and should be avoided. See ethernet.txt file in the same directory. - xlnx,rxmem : Set to allocated memory buffer for Rx/Tx in the hardware @@ -68,6 +69,11 @@ Optional properties: required through the core's MDIO interface (i.e. always, unless the PHY is accessed through a different bus). + - pcs-handle: Phandle to the internal PCS/PMA PHY in SGMII or 1000Base-X + modes, where "pcs-handle" should be used to point + to the PCS/PMA PHY, and "phy-handle" should point to an + external PHY if exists. + Example: axi_ethernet_eth: ethernet@40c00000 { compatible = "xlnx,axi-ethernet-1.00.a"; -- cgit From ed941f65da8166a0ffb82fec30ac331f348fb4d1 Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Tue, 5 Apr 2022 14:09:49 +0200 Subject: dt-bindings: net: convert mscc-miim to YAML format Convert the mscc-miim device tree binding to the new YAML format. The original binding don't mention if the interrupt property is optional or not. But on the SparX-5 SoC, for example, the interrupt property isn't used, thus in the new binding that property is optional. FWIW the driver doesn't use interrupts at all. Signed-off-by: Michael Walle Reviewed-by: Krzysztof Kozlowski Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller --- .../devicetree/bindings/net/mscc,miim.yaml | 56 ++++++++++++++++++++++ .../devicetree/bindings/net/mscc-miim.txt | 26 ---------- 2 files changed, 56 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/mscc,miim.yaml delete mode 100644 Documentation/devicetree/bindings/net/mscc-miim.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/mscc,miim.yaml b/Documentation/devicetree/bindings/net/mscc,miim.yaml new file mode 100644 index 000000000000..cdc39aa20683 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mscc,miim.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mscc,miim.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microsemi MII Management Controller (MIIM) + +maintainers: + - Alexandre Belloni + +allOf: + - $ref: "mdio.yaml#" + +properties: + compatible: + enum: + - mscc,ocelot-miim + - microchip,lan966x-miim + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + reg: + items: + - description: base address + - description: associated reset register for internal PHYs + minItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +unevaluatedProperties: false + +examples: + - | + mdio@107009c { + compatible = "mscc,ocelot-miim"; + reg = <0x107009c 0x36>, <0x10700f0 0x8>; + interrupts = <14>; + #address-cells = <1>; + #size-cells = <0>; + + phy0: ethernet-phy@0 { + reg = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/mscc-miim.txt b/Documentation/devicetree/bindings/net/mscc-miim.txt deleted file mode 100644 index 70e0cb1ee485..000000000000 --- a/Documentation/devicetree/bindings/net/mscc-miim.txt +++ /dev/null @@ -1,26 +0,0 @@ -Microsemi MII Management Controller (MIIM) / MDIO -================================================= - -Properties: -- compatible: must be "mscc,ocelot-miim" or "microchip,lan966x-miim" -- reg: The base address of the MDIO bus controller register bank. Optionally, a - second register bank can be defined if there is an associated reset register - for internal PHYs -- #address-cells: Must be <1>. -- #size-cells: Must be <0>. MDIO addresses have no size component. -- interrupts: interrupt specifier (refer to the interrupt binding) - -Typically an MDIO bus might have several children. - -Example: - mdio@107009c { - #address-cells = <1>; - #size-cells = <0>; - compatible = "mscc,ocelot-miim"; - reg = <0x107009c 0x36>, <0x10700f0 0x8>; - interrupts = <14>; - - phy0: ethernet-phy@0 { - reg = <0>; - }; - }; -- cgit From b0385d4c1fffe0152eabf4f20ff5f937524e9398 Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Tue, 5 Apr 2022 14:09:50 +0200 Subject: dt-bindings: net: mscc-miim: add clock and clock-frequency Add the (optional) clock input of the MDIO controller and indicate that the common clock-frequency property is supported. The driver can use it to set the desired MDIO bus frequency. Signed-off-by: Michael Walle Acked-by: Krzysztof Kozlowski Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/mscc,miim.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/mscc,miim.yaml b/Documentation/devicetree/bindings/net/mscc,miim.yaml index cdc39aa20683..2c451cfa4e0b 100644 --- a/Documentation/devicetree/bindings/net/mscc,miim.yaml +++ b/Documentation/devicetree/bindings/net/mscc,miim.yaml @@ -33,6 +33,11 @@ properties: interrupts: maxItems: 1 + clocks: + maxItems: 1 + + clock-frequency: true + required: - compatible - reg -- cgit From 1dafd0d607032ac3cdb7f6298342b93b9dc7b3e1 Mon Sep 17 00:00:00 2001 From: Lorenzo Bianconi Date: Tue, 5 Apr 2022 21:57:42 +0200 Subject: dt-bindings: net: mediatek: add optional properties for the SoC ethernet core Introduce dma-coherent, cci-control and hifsys optional properties to the mediatek ethernet controller bindings Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/mediatek-net.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt index 72d03e07cf7c..13cb12ee4ed6 100644 --- a/Documentation/devicetree/bindings/net/mediatek-net.txt +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt @@ -41,6 +41,12 @@ Required properties: - mediatek,pctl: phandle to the syscon node that handles the ports slew rate and driver current: only for MT2701 and MT7623 SoC +Optional properties: +- dma-coherent: present if dma operations are coherent +- mediatek,cci-control: phandle to the cache coherent interconnect node +- mediatek,hifsys: phandle to the mediatek hifsys controller used to provide + various clocks and reset to the system. + * Ethernet MAC node Required properties: -- cgit From 55c1c4e945fa98a91fac699914c4b456e63d8fad Mon Sep 17 00:00:00 2001 From: Lorenzo Bianconi Date: Tue, 5 Apr 2022 21:57:45 +0200 Subject: dt-bindings: arm: mediatek: document WED binding for MT7622 Document the binding for the Wireless Ethernet Dispatch core on the MT7622 SoC, which is used for Ethernet->WLAN offloading Add related info in mediatek-net bindings. Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: David S. Miller --- .../bindings/arm/mediatek/mediatek,mt7622-wed.yaml | 50 ++++++++++++++++++++++ .../devicetree/bindings/net/mediatek-net.txt | 2 + 2 files changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml new file mode 100644 index 000000000000..787d6673f952 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-wed.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek Wireless Ethernet Dispatch Controller for MT7622 + +maintainers: + - Lorenzo Bianconi + - Felix Fietkau + +description: + The mediatek wireless ethernet dispatch controller can be configured to + intercept and handle access to the WLAN DMA queues and PCIe interrupts + and implement hardware flow offloading from ethernet to WLAN. + +properties: + compatible: + items: + - enum: + - mediatek,mt7622-wed + - const: syscon + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include + #include + soc { + #address-cells = <2>; + #size-cells = <2>; + wed0: wed@1020a000 { + compatible = "mediatek,mt7622-wed","syscon"; + reg = <0 0x1020a000 0 0x1000>; + interrupts = ; + }; + }; diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt index 13cb12ee4ed6..1c8dc44bbb52 100644 --- a/Documentation/devicetree/bindings/net/mediatek-net.txt +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt @@ -46,6 +46,8 @@ Optional properties: - mediatek,cci-control: phandle to the cache coherent interconnect node - mediatek,hifsys: phandle to the mediatek hifsys controller used to provide various clocks and reset to the system. +- mediatek,wed: a list of phandles to wireless ethernet dispatch nodes for + MT7622 SoC. * Ethernet MAC node -- cgit From f14ac41b785f231573fe935a2eb5aaf737447f0c Mon Sep 17 00:00:00 2001 From: Lorenzo Bianconi Date: Tue, 5 Apr 2022 21:57:46 +0200 Subject: dt-bindings: arm: mediatek: document the pcie mirror node on MT7622 This patch adds the pcie mirror document bindings for MT7622 SoC. The feature is used for intercepting PCIe MMIO access for the WED core Add related info in mediatek-net bindings. Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: David S. Miller --- .../arm/mediatek/mediatek,mt7622-pcie-mirror.yaml | 42 ++++++++++++++++++++++ .../devicetree/bindings/net/mediatek-net.txt | 2 ++ 2 files changed, 44 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml new file mode 100644 index 000000000000..9fbeb626ab23 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek PCIE Mirror Controller for MT7622 + +maintainers: + - Lorenzo Bianconi + - Felix Fietkau + +description: + The mediatek PCIE mirror provides a configuration interface for PCIE + controller on MT7622 soc. + +properties: + compatible: + items: + - enum: + - mediatek,mt7622-pcie-mirror + - const: syscon + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + pcie_mirror: pcie-mirror@10000400 { + compatible = "mediatek,mt7622-pcie-mirror", "syscon"; + reg = <0 0x10000400 0 0x10>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt index 1c8dc44bbb52..f18d70189375 100644 --- a/Documentation/devicetree/bindings/net/mediatek-net.txt +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt @@ -48,6 +48,8 @@ Optional properties: various clocks and reset to the system. - mediatek,wed: a list of phandles to wireless ethernet dispatch nodes for MT7622 SoC. +- mediatek,pcie-mirror: phandle to the mediatek pcie-mirror controller for + MT7622 SoC. * Ethernet MAC node -- cgit From 46bc0d98cf16cac4cb4f73b61a754e5be7148480 Mon Sep 17 00:00:00 2001 From: Rex-BC Chen Date: Wed, 6 Apr 2022 11:00:06 +0800 Subject: dt-bindings: display: mediatek: revise enum to const There won't be more than 1 fallback for these bindings, so we modify them to use const instead of enum. Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220406030009.2357-2-rex-bc.chen@mediatek.com/ Signed-off-by: Rex-BC Chen Reviewed-by: Rob Herring Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Chun-Kuang Hu --- .../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 3 +-- .../devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 3 +-- .../devicetree/bindings/display/mediatek/mediatek,color.yaml | 6 ++---- .../devicetree/bindings/display/mediatek/mediatek,dither.yaml | 3 +-- .../devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 3 +-- .../devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 6 ++---- .../devicetree/bindings/display/mediatek/mediatek,rdma.yaml | 6 ++---- 7 files changed, 10 insertions(+), 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index 61f0ed1e388f..cdb6d0819cca 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -29,8 +29,7 @@ properties: - mediatek,mt8183-disp-aal - mediatek,mt8192-disp-aal - mediatek,mt8195-disp-aal - - enum: - - mediatek,mt8173-disp-aal + - const: mediatek,mt8173-disp-aal reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml index 0ed53b6238f0..7766c806c102 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -28,8 +28,7 @@ properties: - items: - enum: - mediatek,mt8195-disp-ccorr - - enum: - - mediatek,mt8192-disp-ccorr + - const: mediatek,mt8192-disp-ccorr reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index 3ad842eb5668..0c9095b0411e 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -32,15 +32,13 @@ properties: - enum: - mediatek,mt7623-disp-color - mediatek,mt2712-disp-color - - enum: - - mediatek,mt2701-disp-color + - const: mediatek,mt2701-disp-color - items: - enum: - mediatek,mt8183-disp-color - mediatek,mt8192-disp-color - mediatek,mt8195-disp-color - - enum: - - mediatek,mt8173-disp-color + - const: mediatek,mt8173-disp-color reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml index 6657549af165..8180ed0a89ff 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml @@ -28,8 +28,7 @@ properties: - enum: - mediatek,mt8192-disp-dither - mediatek,mt8195-disp-dither - - enum: - - mediatek,mt8183-disp-dither + - const: mediatek,mt8183-disp-dither reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml index 78442339314f..5f1825b4512b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -29,8 +29,7 @@ properties: - enum: - mediatek,mt8192-disp-gamma - mediatek,mt8195-disp-gamma - - enum: - - mediatek,mt8183-disp-gamma + - const: mediatek,mt8183-disp-gamma reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml index f77094e61443..51f8235f1b1b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -33,13 +33,11 @@ properties: - enum: - mediatek,mt7623-disp-ovl - mediatek,mt2712-disp-ovl - - enum: - - mediatek,mt2701-disp-ovl + - const: mediatek,mt2701-disp-ovl - items: - enum: - mediatek,mt8195-disp-ovl - - enum: - - mediatek,mt8183-disp-ovl + - const: mediatek,mt8183-disp-ovl reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml index e8c72afa0630..9a6756f185ee 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml @@ -35,13 +35,11 @@ properties: - enum: - mediatek,mt7623-disp-rdma - mediatek,mt2712-disp-rdma - - enum: - - mediatek,mt2701-disp-rdma + - const: mediatek,mt2701-disp-rdma - items: - enum: - mediatek,mt8192-disp-rdma - - enum: - - mediatek,mt8183-disp-rdma + - const: mediatek,mt8183-disp-rdma reg: maxItems: 1 -- cgit From db85474594609fc6f6a37fe5d5001fa9341971ed Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 6 Apr 2022 17:40:50 +0200 Subject: dt-bindings: soc: samsung: usi: refer to dtschema for SPI After adding DT schema for Samsung SPI controller, the Samsung USI bindings can reference it directly for proper schema validation. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sam Protsenko Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220324134106.103588-1-krzk@kernel.org --- Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml index a98ed66d092e..55417a649970 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml @@ -77,7 +77,7 @@ patternProperties: description: Child node describing underlying UART/serial "^spi@[0-9a-f]+$": - type: object + $ref: /schemas/spi/samsung,spi.yaml description: Child node describing underlying SPI required: -- cgit From 3225de1be4c57ab1371fa2f4717672abdbf98755 Mon Sep 17 00:00:00 2001 From: Rui Miguel Silva Date: Thu, 31 Mar 2022 16:45:34 +0100 Subject: dt-bindings: net: smsc,lan91c111 convert to schema Convert the smsc lan91c9x and lan91c1xx controller device tree bindings documentation to json-schema. Signed-off-by: Rui Miguel Silva Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220331154536.1544220-2-rui.silva@linaro.org --- .../devicetree/bindings/net/smsc,lan91c111.yaml | 61 ++++++++++++++++++++++ .../devicetree/bindings/net/smsc-lan91c111.txt | 17 ------ 2 files changed, 61 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/smsc,lan91c111.yaml delete mode 100644 Documentation/devicetree/bindings/net/smsc-lan91c111.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/smsc,lan91c111.yaml b/Documentation/devicetree/bindings/net/smsc,lan91c111.yaml new file mode 100644 index 000000000000..6df533162632 --- /dev/null +++ b/Documentation/devicetree/bindings/net/smsc,lan91c111.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/smsc,lan91c111.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Smart Mixed-Signal Connectivity (SMSC) LAN91C9x/91C1xx Controller + +maintainers: + - Nicolas Pitre + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + const: smsc,lan91c111 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + reg-shift: true + + reg-io-width: + enum: [ 1, 2, 4 ] + default: 4 + + reset-gpios: + description: GPIO connected to control RESET pin + maxItems: 1 + + power-gpios: + description: GPIO connect to control PWRDWN pin + maxItems: 1 + + pxa-u16-align4: + description: put in place the workaround the force all u16 writes to be + 32 bits aligned + type: boolean + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include + + ethernet@4010000 { + compatible = "smsc,lan91c111"; + reg = <0x40100000 0x10000>; + phy-mode = "mii"; + interrupts = ; + reg-io-width = <2>; + }; diff --git a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt deleted file mode 100644 index 309e37eb7c7c..000000000000 --- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt +++ /dev/null @@ -1,17 +0,0 @@ -SMSC LAN91c111 Ethernet mac - -Required properties: -- compatible = "smsc,lan91c111"; -- reg : physical address and size of registers -- interrupts : interrupt connection - -Optional properties: -- phy-device : see ethernet.txt file in the same directory -- reg-io-width : Mask of sizes (in bytes) of the IO accesses that - are supported on the device. Valid value for SMSC LAN91c111 are - 1, 2 or 4. If it's omitted or invalid, the size would be 2 meaning - 16-bit access only. -- power-gpios: GPIO to control the PWRDWN pin -- reset-gpios: GPIO to control the RESET pin -- pxa-u16-align4 : Boolean, put in place the workaround the force all - u16 writes to be 32 bits aligned -- cgit From ce8b3ad1071b764e963d9b08ac34ffddddf12da6 Mon Sep 17 00:00:00 2001 From: Dongjin Yang Date: Mon, 4 Apr 2022 11:28:57 +0900 Subject: dt-bindings: net: snps: remove duplicate name snps,dwmac has duplicated name for loongson,ls2k-dwmac and loongson,ls7a-dwmac. Signed-off-by: Dongjin Yang Fixes: 68277749a013 ("dt-bindings: dwmac: Add bindings for new Loongson SoC and bridge chip") Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220404022857epcms1p6e6af1a6a86569f339e50c318abde7d3c@epcms1p6 --- Documentation/devicetree/bindings/net/snps,dwmac.yaml | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 2d5248f5b919..36c85eb3dc0d 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -53,20 +53,18 @@ properties: - allwinner,sun8i-r40-gmac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac - - loongson,ls2k-dwmac - - loongson,ls7a-dwmac - amlogic,meson6-dwmac - amlogic,meson8b-dwmac - amlogic,meson8m2-dwmac - amlogic,meson-gxbb-dwmac - amlogic,meson-axg-dwmac - - loongson,ls2k-dwmac - - loongson,ls7a-dwmac - ingenic,jz4775-mac - ingenic,x1000-mac - ingenic,x1600-mac - ingenic,x1830-mac - ingenic,x2000-mac + - loongson,ls2k-dwmac + - loongson,ls7a-dwmac - rockchip,px30-gmac - rockchip,rk3128-gmac - rockchip,rk3228-gmac -- cgit From 9b5a7f4a2a8dcda461f9c7a6671150f4a8a902e8 Mon Sep 17 00:00:00 2001 From: Dave Hansen Date: Thu, 31 Mar 2022 10:57:28 -0700 Subject: x86/configs: Add x86 debugging Kconfig fragment plus docs The kernel has a wide variety of debugging options to help catch and squash bugs. However, new debugging is added all the time and the existing options can be hard to find. Add a Kconfig fragment with the debugging options which tip maintainers expect to be used to test contributions. This should make it easier for contributors to test their code and find issues before submission. [ bp: Add to "make help" output, fix DEBUG_INFO selection as pointed out by Nathan Chancellor . ] Signed-off-by: Dave Hansen Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20220331175728.299103A0@davehans-spike.ostc.intel.com --- Documentation/process/maintainer-tip.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/process/maintainer-tip.rst b/Documentation/process/maintainer-tip.rst index c74f4a81588b..572a3289c9cb 100644 --- a/Documentation/process/maintainer-tip.rst +++ b/Documentation/process/maintainer-tip.rst @@ -437,6 +437,20 @@ in a private repository which allows interested people to easily pull the series for testing. The usual way to offer this is a git URL in the cover letter of the patch series. +Testing +^^^^^^^ + +Code should be tested before submitting to the tip maintainers. Anything +other than minor changes should be built, booted and tested with +comprehensive (and heavyweight) kernel debugging options enabled. + +These debugging options can be found in kernel/configs/x86_debug.config +and can be added to an existing kernel config by running: + + make x86_debug.config + +Some of these options are x86-specific and can be left out when testing +on other architectures. Coding style notes ------------------ -- cgit From 6d41e13041a306f85ad6cbeb3d532f35cc5cc90a Mon Sep 17 00:00:00 2001 From: Andre Przywara Date: Thu, 17 Mar 2022 16:23:38 +0000 Subject: dt-bindings: watchdog: sunxi: fix F1C100s compatible The F1C100 series actually features a newer generation watchdog IP, so the compatible string was wrong. Signed-off-by: Andre Przywara Reviewed-by: Samuel Holland Acked-by: Rob Herring Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/20220317162349.739636-2-andre.przywara@arm.com --- .../devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml index 43afa24513b9..7a26cde0afdd 100644 --- a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml @@ -26,10 +26,8 @@ properties: - allwinner,sun50i-h616-wdt - allwinner,sun50i-r329-wdt - allwinner,sun50i-r329-wdt-reset + - allwinner,suniv-f1c100s-wdt - const: allwinner,sun6i-a31-wdt - - items: - - const: allwinner,suniv-f1c100s-wdt - - const: allwinner,sun4i-a10-wdt - const: allwinner,sun20i-d1-wdt - items: - const: allwinner,sun20i-d1-wdt-reset -- cgit From 42b91bb160815d82d36cc1cfe28f1edd9079d912 Mon Sep 17 00:00:00 2001 From: Andre Przywara Date: Thu, 17 Mar 2022 16:23:39 +0000 Subject: dt-bindings: watchdog: sunxi: clarify clock support Most Allwinner SoCs have just one input clock to drive the watchdog peripheral. So far this is the 24 MHz "HOSC" oscillator, divided down internally to 32 KHz. The F1C100 series watchdog however uses the unchanged 32 KHz "LOSC" as its only clock input, which has the same effect, but let's the binding description mismatch. Change the binding description to name the clocks more loosely, so both the LOSC and divided HOSC match the description. As the fixed clock names now make less sense, drop them from SoCs supporting just one clock input, they were not used by any DT anyway. For the newer SoCs, supporting a choice of two input clocks, we keep both the description and clock-names requirement. Signed-off-by: Andre Przywara Reviewed-by: Guenter Roeck Reviewed-by: Samuel Holland Reviewed-by: Rob Herring Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/20220317162349.739636-3-andre.przywara@arm.com --- .../bindings/watchdog/allwinner,sun4i-a10-wdt.yaml | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml index 7a26cde0afdd..cbcf19f51411 100644 --- a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml @@ -39,14 +39,8 @@ properties: clocks: minItems: 1 items: - - description: High-frequency oscillator input, divided internally - - description: Low-frequency oscillator input, only found on some variants - - clock-names: - minItems: 1 - items: - - const: hosc - - const: losc + - description: 32 KHz input clock + - description: secondary clock source interrupts: maxItems: 1 @@ -71,9 +65,14 @@ then: properties: clocks: minItems: 2 + items: + - description: High-frequency oscillator input, divided internally + - description: Low-frequency oscillator input clock-names: - minItems: 2 + items: + - const: hosc + - const: losc required: - clock-names @@ -83,9 +82,6 @@ else: clocks: maxItems: 1 - clock-names: - maxItems: 1 - unevaluatedProperties: false examples: -- cgit From fb2dcdd7c44652add88ac518c67b208e5133a7a9 Mon Sep 17 00:00:00 2001 From: Andre Przywara Date: Thu, 17 Mar 2022 16:23:41 +0000 Subject: dt-bindings: arm: sunxi: document LicheePi Nano name The top level LicheePi Nano compatible name was never documented in the bindings, so add the currently used string. As for the manufacturer name, Samuel reports: ========== From what I can tell, "Lichee Pi Nano" [1][2] is the original board, and the "Sipeed Lichee Nano" [3] is a newer batch by some of the same people [4]. Other than the silkscreen and the addition of the resistive touchscreen IC, the boards look identical. And in fact I was able to find an intermediate version of the schematic [5] that uses the old styling but includes the touchscreen IC. ========== [1]: https://licheepizero.us/ [2]: http://nano.lichee.pro/ [3]: https://wiki.sipeed.com/hardware/en/lichee/Nano/Nano.html [4]: see e.g. http://bbs.lichee.pro/ [5]: https://github.com/hongxuyao/F1C100s_with_Keil_RTX4_emWin5/blob/spl-separated/doc/lichee-nano/lichee_nano-Schematic.pdf Signed-off-by: Andre Przywara Reviewed-by: Samuel Holland Acked-by: Rob Herring Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/20220317162349.739636-5-andre.przywara@arm.com --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 086c68771d2b..95278a6a9a8e 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -391,6 +391,11 @@ properties: - const: libretech,all-h5-cc-h5 - const: allwinner,sun50i-h5 + - description: Lichee Pi Nano + items: + - const: licheepi,licheepi-nano + - const: allwinner,suniv-f1c100s + - description: Lichee Pi One items: - const: licheepi,licheepi-one -- cgit From 382e0d4f9ece6d1b282ac70c246bdc7be5edc053 Mon Sep 17 00:00:00 2001 From: Andre Przywara Date: Thu, 17 Mar 2022 16:23:47 +0000 Subject: dt-bindings: spi: sunxi: document F1C100 controllers The Allwinner F1C100 series contains two SPI controllers, which are compatible to the IP block used in the Allwinner H3 as well. The only difference in the integration is the missing mod clock in the F1C100, but that does not affect the SPI controller binding, as we can still supply the correct clock (AHB parent) easily. Signed-off-by: Andre Przywara Acked-by: Samuel Holland Acked-by: Rob Herring Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/20220317162349.739636-11-andre.przywara@arm.com --- Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml index 908248260afa..ca4c95345a49 100644 --- a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml +++ b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml @@ -26,6 +26,7 @@ properties: - allwinner,sun8i-r40-spi - allwinner,sun50i-h6-spi - allwinner,sun50i-h616-spi + - allwinner,suniv-f1c100s-spi - const: allwinner,sun8i-h3-spi reg: -- cgit From 5dc6ce767dc8ba173534fa75c66a9e2a13b969d1 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Tue, 8 Mar 2022 21:15:43 +0000 Subject: dt-bindings: gpu: mali-bifrost: Document RZ/V2L SoC The Renesas RZ/V2L SoC (a.k.a R9A07G054) has a Bifrost Mali-G31 GPU, add a compatible string for it. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Geert Uytterhoeven Acked-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220308211543.3081-1-prabhakar.mahadev-lad.rj@bp.renesas.com --- Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 4d6bfae0653c..85f8d4764740 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -20,6 +20,7 @@ properties: - mediatek,mt8183-mali - realtek,rtd1619-mali - renesas,r9a07g044-mali + - renesas,r9a07g054-mali - rockchip,px30-mali - rockchip,rk3568-mali - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable @@ -109,7 +110,9 @@ allOf: properties: compatible: contains: - const: renesas,r9a07g044-mali + enum: + - renesas,r9a07g044-mali + - renesas,r9a07g054-mali then: properties: interrupts: -- cgit From 1ecc0c09f19f8e10a2c52676f8ca47c28c9f73c7 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Mon, 4 Apr 2022 21:21:05 +0200 Subject: dt-bindings: display: panel: mipi-dbi-spi: Make width-mm/height-mm mandatory MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Make the width-mm/height-mm panel properties mandatory to correctly report the panel dimensions to the OS. Fixes: 2f3468b82db97 ("dt-bindings: display: add bindings for MIPI DBI compatible SPI panels") Signed-off-by: Marek Vasut Cc: Christoph Niedermaier Cc: Daniel Vetter Cc: Dmitry Osipenko Cc: Laurent Pinchart Cc: Noralf Trønnes Cc: Rob Herring Cc: Robert Foss Cc: Sam Ravnborg Cc: Thomas Zimmermann Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Acked-by: Noralf Trønnes Reviewed-by: Laurent Pinchart Acked-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20220404192105.12547-1-marex@denx.de --- Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml index f29789994b18..c2df8d28aaf5 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml @@ -83,6 +83,8 @@ properties: required: - compatible - reg + - width-mm + - height-mm - panel-timing unevaluatedProperties: false -- cgit From 2f073eb41230cf10d0c1fd0719fdb3f19e8497dd Mon Sep 17 00:00:00 2001 From: Chen-Yu Tsai Date: Thu, 7 Apr 2022 01:29:53 +0800 Subject: dt-bindings: vendor-prefixes: Add prefix for SINO WEALTH Eletronics Ltd. Add a vendor prefix entry for SINO WEALTH Eletronics Ltd. (http://www.sinowealth.com). Signed-off-by: Chen-Yu Tsai Acked-by: Javier Martinez Canillas Signed-off-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20220406172956.3953-2-wens@kernel.org --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 01430973ecec..79b72e370ade 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1130,6 +1130,8 @@ patternProperties: description: Sinlinx Electronics Technology Co., LTD "^sinovoip,.*": description: SinoVoip Co., Ltd + "^sinowealth,.*": + description: SINO WEALTH Electronic Ltd. "^sipeed,.*": description: Shenzhen Sipeed Technology Co., Ltd. "^sirf,.*": -- cgit From 97a40c23cda5d64a1c5e968e448435084ebc8c9b Mon Sep 17 00:00:00 2001 From: Chen-Yu Tsai Date: Thu, 7 Apr 2022 01:29:54 +0800 Subject: dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106 The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes. Add a compatible string for it. Signed-off-by: Chen-Yu Tsai Acked-by: Javier Martinez Canillas Signed-off-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20220406172956.3953-3-wens@kernel.org --- .../devicetree/bindings/display/solomon,ssd1307fb.yaml | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index 9baafd0c42dd..ade61d502edd 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -13,6 +13,7 @@ maintainers: properties: compatible: enum: + - sinowealth,sh1106-i2c - solomon,ssd1305fb-i2c - solomon,ssd1306fb-i2c - solomon,ssd1307fb-i2c @@ -131,6 +132,18 @@ required: - reg allOf: + - if: + properties: + compatible: + contains: + const: sinowealth,sh1106-i2c + then: + properties: + solomon,dclk-div: + default: 1 + solomon,dclk-frq: + default: 5 + - if: properties: compatible: -- cgit From 8c9c509baf660f1062bc758c26008b7f9bbc39f3 Mon Sep 17 00:00:00 2001 From: Michael Roth Date: Thu, 24 Feb 2022 10:56:13 -0600 Subject: x86/boot: Add a pointer to Confidential Computing blob in bootparams The previously defined Confidential Computing blob is provided to the kernel via a setup_data structure or EFI config table entry. Currently, these are both checked for by boot/compressed kernel to access the CPUID table address within it for use with SEV-SNP CPUID enforcement. To also enable that enforcement for the run-time kernel, similar access to the CPUID table is needed early on while it's still using the identity-mapped page table set up by boot/compressed, where global pointers need to be accessed via fixup_pointer(). This isn't much of an issue for accessing setup_data, and the EFI config table helper code currently used in boot/compressed *could* be used in this case as well since they both rely on identity-mapping. However, it has some reliance on EFI helpers/string constants that would need to be accessed via fixup_pointer(), and fixing it up while making it shareable between boot/compressed and run-time kernel is fragile and introduces a good bit of ugliness. Instead, add a boot_params->cc_blob_address pointer that the boot/compressed kernel can initialize so that the run-time kernel can access the CC blob from there instead of re-scanning the EFI config table. Also document these in Documentation/x86/zero-page.rst. While there, add missing documentation for the acpi_rsdp_addr field, which serves a similar purpose in providing the run-time kernel a pointer to the ACPI RSDP table so that it does not need to [re-]scan the EFI configuration table. [ bp: Fix typos, massage commit message. ] Signed-off-by: Michael Roth Signed-off-by: Brijesh Singh Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20220307213356.2797205-34-brijesh.singh@amd.com --- Documentation/x86/zero-page.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/x86/zero-page.rst b/Documentation/x86/zero-page.rst index f088f5881666..45aa9cceb4f1 100644 --- a/Documentation/x86/zero-page.rst +++ b/Documentation/x86/zero-page.rst @@ -19,6 +19,7 @@ Offset/Size Proto Name Meaning 058/008 ALL tboot_addr Physical address of tboot shared page 060/010 ALL ist_info Intel SpeedStep (IST) BIOS support information (struct ist_info) +070/008 ALL acpi_rsdp_addr Physical address of ACPI RSDP table 080/010 ALL hd0_info hd0 disk parameter, OBSOLETE!! 090/010 ALL hd1_info hd1 disk parameter, OBSOLETE!! 0A0/010 ALL sys_desc_table System description table (struct sys_desc_table), @@ -27,6 +28,7 @@ Offset/Size Proto Name Meaning 0C0/004 ALL ext_ramdisk_image ramdisk_image high 32bits 0C4/004 ALL ext_ramdisk_size ramdisk_size high 32bits 0C8/004 ALL ext_cmd_line_ptr cmd_line_ptr high 32bits +13C/004 ALL cc_blob_address Physical address of Confidential Computing blob 140/080 ALL edid_info Video mode setup (struct edid_info) 1C0/020 ALL efi_info EFI 32 information (struct efi_info) 1E0/004 ALL alt_mem_k Alternative mem check, in KB -- cgit From ba37a1438aeb540cc48722d629f4b2e7e4398466 Mon Sep 17 00:00:00 2001 From: Michael Roth Date: Mon, 7 Mar 2022 15:33:50 -0600 Subject: x86/sev: Add a sev= cmdline option For debugging purposes it is very useful to have a way to see the full contents of the SNP CPUID table provided to a guest. Add an sev=debug kernel command-line option to do so. Also introduce some infrastructure so that additional options can be specified via sev=option1[,option2] over time in a consistent manner. [ bp: Massage, simplify string parsing. ] Suggested-by: Borislav Petkov Signed-off-by: Michael Roth Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20220307213356.2797205-41-brijesh.singh@amd.com --- Documentation/admin-guide/kernel-parameters.txt | 2 ++ Documentation/x86/x86_64/boot-options.rst | 14 ++++++++++++++ 2 files changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 3f1cc5e317ed..48ad2ec0770b 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5308,6 +5308,8 @@ serialnumber [BUGS=X86-32] + sev=option[,option...] [X86-64] See Documentation/x86/x86_64/boot-options.rst + shapers= [NET] Maximal number of shapers. diff --git a/Documentation/x86/x86_64/boot-options.rst b/Documentation/x86/x86_64/boot-options.rst index 07aa0007f346..4efb1fa039ef 100644 --- a/Documentation/x86/x86_64/boot-options.rst +++ b/Documentation/x86/x86_64/boot-options.rst @@ -310,3 +310,17 @@ Miscellaneous Do not use GB pages for kernel direct mappings. gbpages Use GB pages for kernel direct mappings. + + +AMD SEV (Secure Encrypted Virtualization) +========================================= +Options relating to AMD SEV, specified via the following format: + +:: + + sev=option1[,option2] + +The available options are: + + debug + Enable debug messages. -- cgit From fce96cf0443083e37455eff8f78fd240c621dae3 Mon Sep 17 00:00:00 2001 From: Brijesh Singh Date: Mon, 7 Mar 2022 15:33:53 -0600 Subject: virt: Add SEV-SNP guest driver The SEV-SNP specification provides the guest a mechanism to communicate with the PSP without risk from a malicious hypervisor who wishes to read, alter, drop or replay the messages sent. The driver uses snp_issue_guest_request() to issue GHCB SNP_GUEST_REQUEST or SNP_EXT_GUEST_REQUEST NAE events to submit the request to PSP. The PSP requires that all communication should be encrypted using key specified through a struct snp_guest_platform_data descriptor. Userspace can use SNP_GET_REPORT ioctl() to query the guest attestation report. See SEV-SNP spec section Guest Messages for more details. [ bp: Remove the "what" from the commit message, massage. ] Signed-off-by: Brijesh Singh Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20220307213356.2797205-44-brijesh.singh@amd.com --- Documentation/virt/coco/sevguest.rst | 86 ++++++++++++++++++++++++++++++++++++ Documentation/virt/index.rst | 1 + 2 files changed, 87 insertions(+) create mode 100644 Documentation/virt/coco/sevguest.rst (limited to 'Documentation') diff --git a/Documentation/virt/coco/sevguest.rst b/Documentation/virt/coco/sevguest.rst new file mode 100644 index 000000000000..3da782e867a3 --- /dev/null +++ b/Documentation/virt/coco/sevguest.rst @@ -0,0 +1,86 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================================================== +The Definitive SEV Guest API Documentation +=================================================================== + +1. General description +====================== + +The SEV API is a set of ioctls that are used by the guest or hypervisor +to get or set a certain aspect of the SEV virtual machine. The ioctls belong +to the following classes: + + - Hypervisor ioctls: These query and set global attributes which affect the + whole SEV firmware. These ioctl are used by platform provisioning tools. + + - Guest ioctls: These query and set attributes of the SEV virtual machine. + +2. API description +================== + +This section describes ioctls that is used for querying the SEV guest report +from the SEV firmware. For each ioctl, the following information is provided +along with a description: + + Technology: + which SEV technology provides this ioctl. SEV, SEV-ES, SEV-SNP or all. + + Type: + hypervisor or guest. The ioctl can be used inside the guest or the + hypervisor. + + Parameters: + what parameters are accepted by the ioctl. + + Returns: + the return value. General error numbers (-ENOMEM, -EINVAL) + are not detailed, but errors with specific meanings are. + +The guest ioctl should be issued on a file descriptor of the /dev/sev-guest device. +The ioctl accepts struct snp_user_guest_request. The input and output structure is +specified through the req_data and resp_data field respectively. If the ioctl fails +to execute due to a firmware error, then fw_err code will be set otherwise the +fw_err will be set to 0x00000000000000ff. + +The firmware checks that the message sequence counter is one greater than +the guests message sequence counter. If guest driver fails to increment message +counter (e.g. counter overflow), then -EIO will be returned. + +:: + + struct snp_guest_request_ioctl { + /* Message version number */ + __u32 msg_version; + + /* Request and response structure address */ + __u64 req_data; + __u64 resp_data; + + /* firmware error code on failure (see psp-sev.h) */ + __u64 fw_err; + }; + +2.1 SNP_GET_REPORT +------------------ + +:Technology: sev-snp +:Type: guest ioctl +:Parameters (in): struct snp_report_req +:Returns (out): struct snp_report_resp on success, -negative on error + +The SNP_GET_REPORT ioctl can be used to query the attestation report from the +SEV-SNP firmware. The ioctl uses the SNP_GUEST_REQUEST (MSG_REPORT_REQ) command +provided by the SEV-SNP firmware to query the attestation report. + +On success, the snp_report_resp.data will contains the report. The report +contain the format described in the SEV-SNP specification. See the SEV-SNP +specification for further details. + + +Reference +--------- + +SEV-SNP and GHCB specification: developer.amd.com/sev + +The driver is based on SEV-SNP firmware spec 0.9 and GHCB spec version 2.0. diff --git a/Documentation/virt/index.rst b/Documentation/virt/index.rst index edea7fea95a8..40ad0d20032e 100644 --- a/Documentation/virt/index.rst +++ b/Documentation/virt/index.rst @@ -13,6 +13,7 @@ Linux Virtualization Support guest-halt-polling ne_overview acrn/index + coco/sevguest .. only:: html and subproject -- cgit From 68de0b2f938642079c0c853b219bdb88c4dc4d13 Mon Sep 17 00:00:00 2001 From: Brijesh Singh Date: Thu, 24 Feb 2022 10:56:23 -0600 Subject: virt: sevguest: Add support to derive key The SNP_GET_DERIVED_KEY ioctl interface can be used by the SNP guest to ask the firmware to provide a key derived from a root key. The derived key may be used by the guest for any purposes it chooses, such as a sealing key or communicating with the external entities. See SEV-SNP firmware spec for more information. [ bp: No need to memset "req" - it will get overwritten. ] Signed-off-by: Brijesh Singh Signed-off-by: Borislav Petkov Reviewed-by: Liam Merwick Link: https://lore.kernel.org/r/20220307213356.2797205-45-brijesh.singh@amd.com --- Documentation/virt/coco/sevguest.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/coco/sevguest.rst b/Documentation/virt/coco/sevguest.rst index 3da782e867a3..4135c1431241 100644 --- a/Documentation/virt/coco/sevguest.rst +++ b/Documentation/virt/coco/sevguest.rst @@ -77,6 +77,23 @@ On success, the snp_report_resp.data will contains the report. The report contain the format described in the SEV-SNP specification. See the SEV-SNP specification for further details. +2.2 SNP_GET_DERIVED_KEY +----------------------- +:Technology: sev-snp +:Type: guest ioctl +:Parameters (in): struct snp_derived_key_req +:Returns (out): struct snp_derived_key_resp on success, -negative on error + +The SNP_GET_DERIVED_KEY ioctl can be used to get a key derive from a root key. +The derived key can be used by the guest for any purpose, such as sealing keys +or communicating with external entities. + +The ioctl uses the SNP_GUEST_REQUEST (MSG_KEY_REQ) command provided by the +SEV-SNP firmware to derive the key. See SEV-SNP specification for further details +on the various fields passed in the key derivation request. + +On success, the snp_derived_key_resp.data contains the derived key value. See +the SEV-SNP specification for further details. Reference --------- -- cgit From d80b494f712317493d464a55652698c4d1b7bb0f Mon Sep 17 00:00:00 2001 From: Brijesh Singh Date: Mon, 7 Mar 2022 15:33:55 -0600 Subject: virt: sevguest: Add support to get extended report Version 2 of GHCB specification defines Non-Automatic-Exit (NAE) to get extended guest report which is similar to the SNP_GET_REPORT ioctl. The main difference is related to the additional data that will be returned. That additional data returned is a certificate blob that can be used by the SNP guest user. The certificate blob layout is defined in the GHCB specification. The driver simply treats the blob as a opaque data and copies it to userspace. [ bp: Massage commit message, cast 1st arg of access_ok() ] Signed-off-by: Brijesh Singh Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20220307213356.2797205-46-brijesh.singh@amd.com --- Documentation/virt/coco/sevguest.rst | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/coco/sevguest.rst b/Documentation/virt/coco/sevguest.rst index 4135c1431241..625de22658ec 100644 --- a/Documentation/virt/coco/sevguest.rst +++ b/Documentation/virt/coco/sevguest.rst @@ -95,6 +95,29 @@ on the various fields passed in the key derivation request. On success, the snp_derived_key_resp.data contains the derived key value. See the SEV-SNP specification for further details. + +2.3 SNP_GET_EXT_REPORT +---------------------- +:Technology: sev-snp +:Type: guest ioctl +:Parameters (in/out): struct snp_ext_report_req +:Returns (out): struct snp_report_resp on success, -negative on error + +The SNP_GET_EXT_REPORT ioctl is similar to the SNP_GET_REPORT. The difference is +related to the additional certificate data that is returned with the report. +The certificate data returned is being provided by the hypervisor through the +SNP_SET_EXT_CONFIG. + +The ioctl uses the SNP_GUEST_REQUEST (MSG_REPORT_REQ) command provided by the SEV-SNP +firmware to get the attestation report. + +On success, the snp_ext_report_resp.data will contain the attestation report +and snp_ext_report_req.certs_address will contain the certificate blob. If the +length of the blob is smaller than expected then snp_ext_report_req.certs_len will +be updated with the expected value. + +See GHCB specification for further detail on how to parse the certificate blob. + Reference --------- -- cgit From 92a99584d965b930988b28f36d925bd9675828b3 Mon Sep 17 00:00:00 2001 From: Michael Roth Date: Thu, 24 Feb 2022 10:56:25 -0600 Subject: virt: sevguest: Add documentation for SEV-SNP CPUID Enforcement Update the documentation with information regarding SEV-SNP CPUID Enforcement details and what sort of assurances it provides to guests. Signed-off-by: Michael Roth Signed-off-by: Brijesh Singh Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20220307213356.2797205-47-brijesh.singh@amd.com --- Documentation/virt/coco/sevguest.rst | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/coco/sevguest.rst b/Documentation/virt/coco/sevguest.rst index 625de22658ec..bf593e88cfd9 100644 --- a/Documentation/virt/coco/sevguest.rst +++ b/Documentation/virt/coco/sevguest.rst @@ -118,6 +118,35 @@ be updated with the expected value. See GHCB specification for further detail on how to parse the certificate blob. +3. SEV-SNP CPUID Enforcement +============================ + +SEV-SNP guests can access a special page that contains a table of CPUID values +that have been validated by the PSP as part of the SNP_LAUNCH_UPDATE firmware +command. It provides the following assurances regarding the validity of CPUID +values: + + - Its address is obtained via bootloader/firmware (via CC blob), and those + binaries will be measured as part of the SEV-SNP attestation report. + - Its initial state will be encrypted/pvalidated, so attempts to modify + it during run-time will result in garbage being written, or #VC exceptions + being generated due to changes in validation state if the hypervisor tries + to swap the backing page. + - Attempts to bypass PSP checks by the hypervisor by using a normal page, or + a non-CPUID encrypted page will change the measurement provided by the + SEV-SNP attestation report. + - The CPUID page contents are *not* measured, but attempts to modify the + expected contents of a CPUID page as part of guest initialization will be + gated by the PSP CPUID enforcement policy checks performed on the page + during SNP_LAUNCH_UPDATE, and noticeable later if the guest owner + implements their own checks of the CPUID values. + +It is important to note that this last assurance is only useful if the kernel +has taken care to make use of the SEV-SNP CPUID throughout all stages of boot. +Otherwise, guest owner attestation provides no assurance that the kernel wasn't +fed incorrect values at some point during boot. + + Reference --------- -- cgit From 2eacc8479c1f6610288f619a23c374502176ca66 Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Tue, 5 Apr 2022 16:55:02 +0900 Subject: regulator: uniphier: Clean up clocks, resets, and their names using compatible string Instead of "oneOf:" choices, use "allOf:" and "if:" to define clocks, resets, and their names that can be taken by the compatible string. The order of clock-names and reset-names doesn't change here. Signed-off-by: Kunihiko Hayashi Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1649145303-30221-2-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Mark Brown --- .../regulator/socionext,uniphier-regulator.yaml | 55 +++++++++++++++------- 1 file changed, 38 insertions(+), 17 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml index 1218f21ba320..cc40cf72a149 100644 --- a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml @@ -14,9 +14,6 @@ description: | maintainers: - Kunihiko Hayashi -allOf: - - $ref: "regulator.yaml#" - # USB3 Controller properties: @@ -36,25 +33,49 @@ properties: minItems: 1 maxItems: 2 - clock-names: - oneOf: - - items: # for Pro4, Pro5 - - const: gio - - const: link - - items: # for others - - const: link + clock-names: true resets: minItems: 1 maxItems: 2 - reset-names: - oneOf: - - items: # for Pro4, Pro5 - - const: gio - - const: link - - items: - - const: link + reset-names: true + +allOf: + - $ref: "regulator.yaml#" + - if: + properties: + compatible: + contains: + enum: + - socionext,uniphier-pro4-usb3-regulator + - socionext,uniphier-pro5-usb3-regulator + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: gio + - const: link + resets: + minItems: 2 + maxItems: 2 + reset-names: + items: + - const: gio + - const: link + else: + properties: + clocks: + maxItems: 1 + clock-names: + const: link + resets: + maxItems: 1 + reset-names: + const: link additionalProperties: false -- cgit From 65adf7234a0dd68217f58715b0b5fd940b630529 Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Tue, 5 Apr 2022 16:55:03 +0900 Subject: regulator: uniphier: Use unevaluatedProperties This refers common bindings, so this is preferred for unevaluatedProperties instead of additionalProperties. Signed-off-by: Kunihiko Hayashi Acked-by: Rob Herring Link: https://lore.kernel.org/r/1649145303-30221-3-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/socionext,uniphier-regulator.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml index cc40cf72a149..75087c6e001c 100644 --- a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml @@ -77,7 +77,7 @@ allOf: reset-names: const: link -additionalProperties: false +unevaluatedProperties: false required: - compatible -- cgit From 92298ea34a8546f11989d122e8f0937d002faeb6 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 5 Apr 2022 08:37:24 +0200 Subject: dt-bindings: qcom: update maintainers (drop Akash and Mukesh) Emails to Akash Asthana and Mukesh Savaliya bounce (550: Recipient address rejected: User unknown in virtual alias table), so switch maintainer to Bjorn (as active Qualcomm platform maintainer). Cc: Bjorn Andersson Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Acked-by: Mark Brown Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220405063724.12850-1-krzysztof.kozlowski@linaro.org --- Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml | 3 +-- Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index 95fcb43675d6..3f41c202b77b 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -7,8 +7,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: GENI Serial Engine QUP Wrapper Controller maintainers: - - Mukesh Savaliya - - Akash Asthana + - Bjorn Andersson description: | Generic Interface (GENI) based Qualcomm Universal Peripheral (QUP) wrapper diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml index 5a60fba14bba..b175099c3360 100644 --- a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml @@ -8,8 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: Qualcomm Quad Serial Peripheral Interface (QSPI) maintainers: - - Mukesh Savaliya - - Akash Asthana + - Bjorn Andersson description: The QSPI controller allows SPI protocol communication in single, dual, or quad wire transmission modes for read/write access to slaves such -- cgit From d6a4371c3cdd4febb6ccb860832409fd9a61e12a Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 5 Apr 2022 08:34:48 +0200 Subject: spi: dt-bindings: qcom,spi-qup: convert to dtschema Convert the Qualcomm Universal Peripheral (QUP) Serial Peripheral Interface (SPI) bindings to DT Schema. Signed-off-by: Krzysztof Kozlowski Acked-by: Kuldeep Singh Reviewed-by: Rob Herring Acked-by: Mark Brown Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220405063451.12011-7-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/spi/qcom,spi-qup.txt | 103 --------------------- .../devicetree/bindings/spi/qcom,spi-qup.yaml | 81 ++++++++++++++++ 2 files changed, 81 insertions(+), 103 deletions(-) delete mode 100644 Documentation/devicetree/bindings/spi/qcom,spi-qup.txt create mode 100644 Documentation/devicetree/bindings/spi/qcom,spi-qup.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt deleted file mode 100644 index 5c090771c016..000000000000 --- a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt +++ /dev/null @@ -1,103 +0,0 @@ -Qualcomm Universal Peripheral (QUP) Serial Peripheral Interface (SPI) - -The QUP core is an AHB slave that provides a common data path (an output FIFO -and an input FIFO) for serial peripheral interface (SPI) mini-core. - -SPI in master mode supports up to 50MHz, up to four chip selects, programmable -data path from 4 bits to 32 bits and numerous protocol variants. - -Required properties: -- compatible: Should contain: - "qcom,spi-qup-v1.1.1" for 8660, 8960 and 8064. - "qcom,spi-qup-v2.1.1" for 8974 and later - "qcom,spi-qup-v2.2.1" for 8974 v2 and later. - -- reg: Should contain base register location and length -- interrupts: Interrupt number used by this controller - -- clocks: Should contain the core clock and the AHB clock. -- clock-names: Should be "core" for the core clock and "iface" for the - AHB clock. - -- #address-cells: Number of cells required to define a chip select - address on the SPI bus. Should be set to 1. -- #size-cells: Should be zero. - -Optional properties: -- spi-max-frequency: Specifies maximum SPI clock frequency, - Units - Hz. Definition as per - Documentation/devicetree/bindings/spi/spi-bus.txt -- num-cs: total number of chipselects -- cs-gpios: should specify GPIOs used for chipselects. - The gpios will be referred to as reg = in the SPI child - nodes. If unspecified, a single SPI device without a chip - select can be used. - -- dmas: Two DMA channel specifiers following the convention outlined - in bindings/dma/dma.txt -- dma-names: Names for the dma channels, if present. There must be at - least one channel named "tx" for transmit and named "rx" for - receive. - -SPI slave nodes must be children of the SPI master node and can contain -properties described in Documentation/devicetree/bindings/spi/spi-bus.txt - -Example: - - spi_8: spi@f9964000 { /* BLSP2 QUP2 */ - - compatible = "qcom,spi-qup-v2"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0xf9964000 0x1000>; - interrupts = <0 102 0>; - spi-max-frequency = <19200000>; - - clocks = <&gcc GCC_BLSP2_QUP2_SPI_APPS_CLK>, <&gcc GCC_BLSP2_AHB_CLK>; - clock-names = "core", "iface"; - - dmas = <&blsp1_bam 13>, <&blsp1_bam 12>; - dma-names = "rx", "tx"; - - pinctrl-names = "default"; - pinctrl-0 = <&spi8_default>; - - device@0 { - compatible = "arm,pl022-dummy"; - #address-cells = <1>; - #size-cells = <1>; - reg = <0>; /* Chip select 0 */ - spi-max-frequency = <19200000>; - spi-cpol; - }; - - device@1 { - compatible = "arm,pl022-dummy"; - #address-cells = <1>; - #size-cells = <1>; - reg = <1>; /* Chip select 1 */ - spi-max-frequency = <9600000>; - spi-cpha; - }; - - device@2 { - compatible = "arm,pl022-dummy"; - #address-cells = <1>; - #size-cells = <1>; - reg = <2>; /* Chip select 2 */ - spi-max-frequency = <19200000>; - spi-cpol; - spi-cpha; - }; - - device@3 { - compatible = "arm,pl022-dummy"; - #address-cells = <1>; - #size-cells = <1>; - reg = <3>; /* Chip select 3 */ - spi-max-frequency = <19200000>; - spi-cpol; - spi-cpha; - spi-cs-high; - }; - }; diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qup.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qup.yaml new file mode 100644 index 000000000000..93f14dd01afc --- /dev/null +++ b/Documentation/devicetree/bindings/spi/qcom,spi-qup.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/qcom,spi-qup.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Universal Peripheral (QUP) Serial Peripheral Interface (SPI) + +maintainers: + - Andy Gross + - Bjorn Andersson + - Krzysztof Kozlowski + +description: + The QUP core is an AHB slave that provides a common data path (an output FIFO + and an input FIFO) for serial peripheral interface (SPI) mini-core. + + SPI in master mode supports up to 50MHz, up to four chip selects, + programmable data path from 4 bits to 32 bits and numerous protocol variants. + +allOf: + - $ref: /schemas/spi/spi-controller.yaml# + +properties: + compatible: + enum: + - qcom,spi-qup-v1.1.1 # for 8660, 8960 and 8064 + - qcom,spi-qup-v2.1.1 # for 8974 and later + - qcom,spi-qup-v2.2.1 # for 8974 v2 and later + + clocks: + maxItems: 2 + + clock-names: + items: + - const: core + - const: iface + + dmas: + maxItems: 2 + + dma-names: + items: + - const: tx + - const: rx + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - interrupts + - reg + +unevaluatedProperties: false + +examples: + - | + #include + #include + + spi@7575000 { + compatible = "qcom,spi-qup-v2.2.1"; + reg = <0x07575000 0x600>; + interrupts = ; + clocks = <&gcc GCC_BLSP1_QUP1_SPI_APPS_CLK>, + <&gcc GCC_BLSP1_AHB_CLK>; + clock-names = "core", "iface"; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&blsp1_spi1_default>; + pinctrl-1 = <&blsp1_spi1_sleep>; + dmas = <&blsp1_dma 12>, <&blsp1_dma 13>; + dma-names = "tx", "rx"; + #address-cells = <1>; + #size-cells = <0>; + }; -- cgit From a5b7063f6dde18f9a5b0356a1941e1ea4a499ea1 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 5 Apr 2022 08:34:49 +0200 Subject: dt-bindings: serial: qcom,msm-uartdm: convert to dtschema Convert the Qualcomm MSM Serial UARTDM bindings to DT Schema. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220405063451.12011-8-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/serial/qcom,msm-uartdm.txt | 81 --------------- .../bindings/serial/qcom,msm-uartdm.yaml | 112 +++++++++++++++++++++ 2 files changed, 112 insertions(+), 81 deletions(-) delete mode 100644 Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt create mode 100644 Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt deleted file mode 100644 index 9d098cf73b53..000000000000 --- a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt +++ /dev/null @@ -1,81 +0,0 @@ -* MSM Serial UARTDM - -The MSM serial UARTDM hardware is designed for high-speed use cases where the -transmit and/or receive channels can be offloaded to a dma-engine. From a -software perspective it's mostly compatible with the MSM serial UART except -that it supports reading and writing multiple characters at a time. - -Required properties: -- compatible: Should contain at least "qcom,msm-uartdm". - A more specific property should be specified as follows depending - on the version: - "qcom,msm-uartdm-v1.1" - "qcom,msm-uartdm-v1.2" - "qcom,msm-uartdm-v1.3" - "qcom,msm-uartdm-v1.4" -- reg: Should contain UART register locations and lengths. The first - register shall specify the main control registers. An optional second - register location shall specify the GSBI control region. - "qcom,msm-uartdm-v1.3" is the only compatible value that might - need the GSBI control region. -- interrupts: Should contain UART interrupt. -- clocks: Should contain the core clock and the AHB clock. -- clock-names: Should be "core" for the core clock and "iface" for the - AHB clock. - -Optional properties: -- dmas: Should contain dma specifiers for transmit and receive channels -- dma-names: Should contain "tx" for transmit and "rx" for receive channels -- qcom,tx-crci: Identificator for Client Rate Control Interface to be - used with TX DMA channel. Required when using DMA for transmission - with UARTDM v1.3 and below. -- qcom,rx-crci: Identificator for Client Rate Control Interface to be - used with RX DMA channel. Required when using DMA for reception - with UARTDM v1.3 and below. - -Note: Aliases may be defined to ensure the correct ordering of the UARTs. -The alias serialN will result in the UART being assigned port N. If any -serialN alias exists, then an alias must exist for each enabled UART. The -serialN aliases should be in a .dts file instead of in a .dtsi file. - -Examples: - -- A uartdm v1.4 device with dma capabilities. - - serial@f991e000 { - compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm"; - reg = <0xf991e000 0x1000>; - interrupts = <0 108 0x0>; - clocks = <&blsp1_uart2_apps_cxc>, <&blsp1_ahb_cxc>; - clock-names = "core", "iface"; - dmas = <&dma0 0>, <&dma0 1>; - dma-names = "tx", "rx"; - }; - -- A uartdm v1.3 device without dma capabilities and part of a GSBI complex. - - serial@19c40000 { - compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm"; - reg = <0x19c40000 0x1000>, - <0x19c00000 0x1000>; - interrupts = <0 195 0x0>; - clocks = <&gsbi5_uart_cxc>, <&gsbi5_ahb_cxc>; - clock-names = "core", "iface"; - }; - -- serialN alias. - - aliases { - serial0 = &uarta; - serial1 = &uartc; - serial2 = &uartb; - }; - - uarta: serial@12490000 { - }; - - uartb: serial@16340000 { - }; - - uartc: serial@1a240000 { - }; diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml new file mode 100644 index 000000000000..484b9a51f6a9 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml @@ -0,0 +1,112 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/qcom,msm-uartdm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm MSM Serial UARTDM + +maintainers: + - Andy Gross + - Bjorn Andersson + - Krzysztof Kozlowski + +description: | + The MSM serial UARTDM hardware is designed for high-speed use cases where the + transmit and/or receive channels can be offloaded to a dma-engine. From a + software perspective it's mostly compatible with the MSM serial UART except + that it supports reading and writing multiple characters at a time. + + Note:: Aliases may be defined to ensure the correct ordering of the UARTs. + The alias serialN will result in the UART being assigned port N. If any + serialN alias exists, then an alias must exist for each enabled UART. The + serialN aliases should be in a .dts file instead of in a .dtsi file. + +properties: + compatible: + items: + - enum: + - qcom,msm-uartdm-v1.1 + - qcom,msm-uartdm-v1.2 + - qcom,msm-uartdm-v1.3 + - qcom,msm-uartdm-v1.4 + - const: qcom,msm-uartdm + + clocks: + maxItems: 2 + + clock-names: + items: + - const: core + - const: iface + + dmas: + maxItems: 2 + + dma-names: + items: + - const: tx + - const: rx + + interrupts: + maxItems: 1 + + qcom,rx-crci: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Identificator for Client Rate Control Interface to be used with RX DMA + channel. Required when using DMA for reception with UARTDM v1.3 and + below. + + qcom,tx-crci: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Identificator for Client Rate Control Interface to be used with TX DMA + channel. Required when using DMA for transmission with UARTDM v1.3 and + below. + + reg: + minItems: 1 + items: + - description: Main control registers + - description: An optional second register location shall specify the GSBI control region. + +required: + - compatible + - clock-names + - clocks + - interrupts + - reg + +unevaluatedProperties: false + +allOf: + - $ref: /schemas/serial/serial.yaml# + + - if: + properties: + compatible: + contains: + const: qcom,msm-uartdm-v1.3 + then: + properties: + reg: + minItems: 2 + else: + properties: + reg: + maxItems: 1 + +examples: + - | + #include + + serial@f991e000 { + compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm"; + reg = <0xf991e000 0x1000>; + interrupts = ; + clocks = <&blsp1_uart2_apps_cxc>, <&blsp1_ahb_cxc>; + clock-names = "core", "iface"; + dmas = <&dma0 0>, <&dma0 1>; + dma-names = "tx", "rx"; + }; -- cgit From 71f333a1dddccdd636d42118c66dda68aee149ed Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 5 Apr 2022 08:34:50 +0200 Subject: dt-bindings: i2c: qcom,i2c-qup: convert to dtschema Convert the Qualcomm Universal Peripheral (QUP) I2C controller to DT Schema. Add missing properties: dma and dma-names, pinctrl states (to indicate support for sleep pinctrl). Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220405063451.12011-9-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/i2c/qcom,i2c-qup.txt | 40 ---------- .../devicetree/bindings/i2c/qcom,i2c-qup.yaml | 89 ++++++++++++++++++++++ 2 files changed, 89 insertions(+), 40 deletions(-) delete mode 100644 Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt create mode 100644 Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt deleted file mode 100644 index dc71754a56af..000000000000 --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt +++ /dev/null @@ -1,40 +0,0 @@ -Qualcomm Universal Peripheral (QUP) I2C controller - -Required properties: - - compatible: Should be: - * "qcom,i2c-qup-v1.1.1" for 8660, 8960 and 8064. - * "qcom,i2c-qup-v2.1.1" for 8974 v1. - * "qcom,i2c-qup-v2.2.1" for 8974 v2 and later. - - reg: Should contain QUP register address and length. - - interrupts: Should contain I2C interrupt. - - - clocks: A list of phandles + clock-specifiers, one for each entry in - clock-names. - - clock-names: Should contain: - * "core" for the core clock - * "iface" for the AHB clock - - - #address-cells: Should be <1> Address cells for i2c device address - - #size-cells: Should be <0> as i2c addresses have no size component - -Optional properties: - - clock-frequency: Should specify the desired i2c bus clock frequency in Hz, - defaults to 100kHz if omitted. - -Child nodes should conform to i2c bus binding. - -Example: - - i2c@f9924000 { - compatible = "qcom,i2c-qup-v2.2.1"; - reg = <0xf9924000 0x1000>; - interrupts = <0 96 0>; - - clocks = <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>; - clock-names = "core", "iface"; - - clock-frequency = <355000>; - - #address-cells = <1>; - #size-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml new file mode 100644 index 000000000000..f43947514d48 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/qcom,i2c-qup.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Universal Peripheral (QUP) I2C controller + +maintainers: + - Andy Gross + - Bjorn Andersson + - Krzysztof Kozlowski + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + enum: + - qcom,i2c-qup-v1.1.1 # for 8660, 8960 and 8064 + - qcom,i2c-qup-v2.1.1 # for 8974 v1 + - qcom,i2c-qup-v2.2.1 # for 8974 v2 and later + + clocks: + maxItems: 2 + + clock-names: + items: + - const: core + - const: iface + + clock-frequency: + default: 100000 + + dmas: + maxItems: 2 + + dma-names: + items: + - const: tx + - const: rx + + interrupts: + maxItems: 1 + + pinctrl-0: true + pinctrl-1: true + + pinctrl-names: + minItems: 1 + items: + - const: default + - const: sleep + + reg: + maxItems: 1 + +required: + - compatible + - clock-names + - clocks + - interrupts + - reg + +unevaluatedProperties: false + +examples: + - | + #include + #include + + i2c@c175000 { + compatible = "qcom,i2c-qup-v2.2.1"; + reg = <0x0c175000 0x600>; + interrupts = ; + + clocks = <&gcc GCC_BLSP1_QUP1_I2C_APPS_CLK>, + <&gcc GCC_BLSP1_AHB_CLK>; + clock-names = "core", "iface"; + dmas = <&blsp1_dma 6>, <&blsp1_dma 7>; + dma-names = "tx", "rx"; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&blsp1_i2c1_default>; + pinctrl-1 = <&blsp1_i2c1_sleep>; + clock-frequency = <400000>; + + #address-cells = <1>; + #size-cells = <0>; + }; -- cgit From 0557dc5ea2e4b9f8fb85f61445873fba26078b03 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 5 Apr 2022 08:34:51 +0200 Subject: dt-bindings: qcom: qcom,gsbi: convert to dtschema Convert the Qualcomm General Serial Bus Interface (GSBI) to DT Schema. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220405063451.12011-10-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/soc/qcom/qcom,gsbi.txt | 87 -------------- .../devicetree/bindings/soc/qcom/qcom,gsbi.yaml | 132 +++++++++++++++++++++ 2 files changed, 132 insertions(+), 87 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt deleted file mode 100644 index fe1855f09dcc..000000000000 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt +++ /dev/null @@ -1,87 +0,0 @@ -QCOM GSBI (General Serial Bus Interface) Driver - -The GSBI controller is modeled as a node with zero or more child nodes, each -representing a serial sub-node device that is mux'd as part of the GSBI -configuration settings. The mode setting will govern the input/output mode of -the 4 GSBI IOs. - -Required properties: -- compatible: Should contain "qcom,gsbi-v1.0.0" -- cell-index: Should contain the GSBI index -- reg: Address range for GSBI registers -- clocks: required clock -- clock-names: must contain "iface" entry -- qcom,mode : indicates MUX value for configuration of the serial interface. - Please reference dt-bindings/soc/qcom,gsbi.h for valid mux values. - -Optional properties: -- qcom,crci : indicates CRCI MUX value for QUP CRCI ports. Please reference - dt-bindings/soc/qcom,gsbi.h for valid CRCI mux values. -- syscon-tcsr: indicates phandle of TCSR syscon node. Required if child uses - dma. - -Required properties if child node exists: -- #address-cells: Must be 1 -- #size-cells: Must be 1 -- ranges: Must be present - -Properties for children: - -A GSBI controller node can contain 0 or more child nodes representing serial -devices. These serial devices can be a QCOM UART, I2C controller, spi -controller, or some combination of aforementioned devices. - -See the following for child node definitions: -Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt -Documentation/devicetree/bindings/spi/qcom,spi-qup.txt -Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt - -Example for APQ8064: - -#include - - gsbi4@16300000 { - compatible = "qcom,gsbi-v1.0.0"; - cell-index = <4>; - reg = <0x16300000 0x100>; - clocks = <&gcc GSBI4_H_CLK>; - clock-names = "iface"; - #address-cells = <1>; - #size-cells = <1>; - ranges; - qcom,mode = ; - qcom,crci = ; - - syscon-tcsr = <&tcsr>; - - /* child nodes go under here */ - - i2c_qup4: i2c@16380000 { - compatible = "qcom,i2c-qup-v1.1.1"; - reg = <0x16380000 0x1000>; - interrupts = <0 153 0>; - - clocks = <&gcc GSBI4_QUP_CLK>, <&gcc GSBI4_H_CLK>; - clock-names = "core", "iface"; - - clock-frequency = <200000>; - - #address-cells = <1>; - #size-cells = <0>; - - }; - - uart4: serial@16340000 { - compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm"; - reg = <0x16340000 0x1000>, - <0x16300000 0x1000>; - interrupts = <0 152 0x0>; - clocks = <&gcc GSBI4_UART_CLK>, <&gcc GSBI4_H_CLK>; - clock-names = "core", "iface"; - }; - }; - - tcsr: syscon@1a400000 { - compatible = "qcom,apq8064-tcsr", "syscon"; - reg = <0x1a400000 0x100>; - }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.yaml new file mode 100644 index 000000000000..c33704333e49 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/qcom/qcom,gsbi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm General Serial Bus Interface (GSBI) + +maintainers: + - Andy Gross + - Bjorn Andersson + - Krzysztof Kozlowski + +description: + The GSBI controller is modeled as a node with zero or more child nodes, each + representing a serial sub-node device that is mux'd as part of the GSBI + configuration settings. The mode setting will govern the input/output mode + of the 4 GSBI IOs. + + A GSBI controller node can contain 0 or more child nodes representing serial + devices. These serial devices can be a QCOM UART, I2C controller, spi + controller, or some combination of aforementioned devices. + +properties: + compatible: + const: qcom,gsbi-v1.0.0 + + '#address-cells': + const: 1 + + cell-index: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The GSBI index. + + clocks: + maxItems: 1 + + clock-names: + const: iface + + qcom,crci: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + CRCI MUX value for QUP CRCI ports. Please reference + include/dt-bindings/soc/qcom,gsbi.h for valid CRCI mux values. + + qcom,mode: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + MUX value for configuration of the serial interface. Please reference + include/dt-bindings/soc/qcom,gsbi.h for valid mux values. + + '#size-cells': + const: 1 + + syscon-tcsr: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle of TCSR syscon node.Required if child uses dma. + + ranges: true + + reg: + maxItems: 1 + +patternProperties: + "spi@[0-9a-f]+$": + type: object + $ref: /schemas/spi/qcom,spi-qup.yaml# + + "i2c@[0-9a-f]+$": + type: object + $ref: /schemas/i2c/qcom,i2c-qup.yaml# + + "serial@[0-9a-f]+$": + type: object + $ref: /schemas/serial/qcom,msm-uartdm.yaml# + +required: + - compatible + - cell-index + - clocks + - clock-names + - qcom,mode + - reg + +additionalProperties: false + +examples: + - | + #include + #include + #include + + gsbi@12440000 { + compatible = "qcom,gsbi-v1.0.0"; + reg = <0x12440000 0x100>; + cell-index = <1>; + clocks = <&gcc GSBI1_H_CLK>; + clock-names = "iface"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + syscon-tcsr = <&tcsr>; + qcom,mode = ; + + serial@12450000 { + compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm"; + reg = <0x12450000 0x100>, + <0x12400000 0x03>; + interrupts = <0 193 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&gcc GSBI1_UART_CLK>, <&gcc GSBI1_H_CLK>; + clock-names = "core", "iface"; + }; + + i2c@12460000 { + compatible = "qcom,i2c-qup-v1.1.1"; + reg = <0x12460000 0x1000>; + pinctrl-0 = <&i2c1_pins>; + pinctrl-1 = <&i2c1_pins_sleep>; + pinctrl-names = "default", "sleep"; + interrupts = <0 194 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&gcc GSBI1_QUP_CLK>, <&gcc GSBI1_H_CLK>; + clock-names = "core", "iface"; + #address-cells = <1>; + #size-cells = <0>; + + status = "disabled"; /* UART chosen */ + }; + }; -- cgit From 2b18b93e199510429fce0f799df6418eadf9bd08 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 6 Apr 2022 18:07:28 +0200 Subject: dt-bindings: vendor-prefixes: add Enclustra Add vendor prefix for Enclustra GmbH (https://www.enclustra.com). Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220406160728.720902-1-krzysztof.kozlowski@linaro.org --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 01430973ecec..113ff50eb46e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -383,6 +383,8 @@ patternProperties: description: Empire Electronix "^emtrion,.*": description: emtrion GmbH + "^enclustra,.*": + description: Enclustra GmbH "^endless,.*": description: Endless Mobile, Inc. "^ene,.*": -- cgit From fe88f5f70b9f1df16eabab4a558cf5cf567a1940 Mon Sep 17 00:00:00 2001 From: AngeloGioacchino Del Regno Date: Thu, 7 Apr 2022 11:47:53 +0200 Subject: dt-bindings: i2c: convert i2c-mt65xx to json-schema Convert I2C binding for MediaTek SoCs to Devicetree schema. Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220407094753.13282-1-angelogioacchino.delregno@collabora.com --- .../devicetree/bindings/i2c/i2c-mt65xx.txt | 53 --------- .../devicetree/bindings/i2c/i2c-mt65xx.yaml | 118 +++++++++++++++++++++ 2 files changed, 118 insertions(+), 53 deletions(-) delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt deleted file mode 100644 index 026985b8f61a..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt +++ /dev/null @@ -1,53 +0,0 @@ -* MediaTek's I2C controller - -The MediaTek's I2C controller is used to interface with I2C devices. - -Required properties: - - compatible: value should be either of the following. - "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for MediaTek MT2701 - "mediatek,mt2712-i2c": for MediaTek MT2712 - "mediatek,mt6577-i2c": for MediaTek MT6577 - "mediatek,mt6589-i2c": for MediaTek MT6589 - "mediatek,mt6797-i2c", "mediatek,mt6577-i2c": for MediaTek MT6797 - "mediatek,mt7622-i2c": for MediaTek MT7622 - "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623 - "mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek MT7629 - "mediatek,mt8168-i2c": for MediaTek MT8168 - "mediatek,mt8173-i2c": for MediaTek MT8173 - "mediatek,mt8183-i2c": for MediaTek MT8183 - "mediatek,mt8186-i2c": for MediaTek MT8186 - "mediatek,mt8192-i2c": for MediaTek MT8192 - "mediatek,mt8195-i2c", "mediatek,mt8192-i2c": for MediaTek MT8195 - "mediatek,mt8516-i2c", "mediatek,mt2712-i2c": for MediaTek MT8516 - - reg: physical base address of the controller and dma base, length of memory - mapped region. - - interrupts: interrupt number to the cpu. - - clock-div: the fixed value for frequency divider of clock source in i2c - module. Each IC may be different. - - clocks: clock name from clock manager - - clock-names: Must include "main" and "dma", "arb" is for multi-master that - one bus has more than two i2c controllers, if enable have-pmic need include - "pmic" extra. - -Optional properties: - - clock-frequency: Frequency in Hz of the bus when transfer, the default value - is 100000. - - mediatek,have-pmic: platform can control i2c form special pmic side. - Only mt6589 and mt8135 support this feature. - - mediatek,use-push-pull: IO config use push-pull mode. - - vbus-supply: phandle to the regulator that provides power to SCL/SDA. - -Example: - - i2c0: i2c@1100d000 { - compatible = "mediatek,mt6577-i2c"; - reg = <0x1100d000 0x70>, - <0x11000300 0x80>; - interrupts = ; - clock-frequency = <400000>; - mediatek,have-pmic; - clock-div = <16>; - clocks = <&i2c0_ck>, <&ap_dma_ck>; - clock-names = "main", "dma"; - }; - diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml new file mode 100644 index 000000000000..16a1a3118204 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml @@ -0,0 +1,118 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-mt65xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek I2C controller + +description: + This driver interfaces with the native I2C controller present in + various MediaTek SoCs. + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +maintainers: + - Qii Wang + +properties: + compatible: + oneOf: + - const: mediatek,mt2712-i2c + - const: mediatek,mt6577-i2c + - const: mediatek,mt6589-i2c + - const: mediatek,mt7622-i2c + - const: mediatek,mt8168-i2c + - const: mediatek,mt8173-i2c + - const: mediatek,mt8183-i2c + - const: mediatek,mt8186-i2c + - const: mediatek,mt8192-i2c + - items: + - enum: + - mediatek,mt7629-i2c + - mediatek,mt8516-i2c + - const: mediatek,mt2712-i2c + - items: + - enum: + - mediatek,mt2701-i2c + - mediatek,mt6797-i2c + - mediatek,mt7623-i2c + - const: mediatek,mt6577-i2c + - items: + - enum: + - mediatek,mt8195-i2c + - const: mediatek,mt8192-i2c + + reg: + items: + - description: Physical base address + - description: DMA base address + + interrupts: + maxItems: 1 + + clocks: + minItems: 2 + items: + - description: Main clock for I2C bus + - description: Clock for I2C via DMA + - description: Bus arbitrator clock + - description: Clock for I2C from PMIC + + clock-names: + minItems: 2 + items: + - const: main + - const: dma + - const: arb + - const: pmic + + clock-div: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Frequency divider of clock source in I2C module + + clock-frequency: + default: 100000 + description: + SCL frequency to use (in Hz). If omitted, 100kHz is used. + + mediatek,have-pmic: + description: Platform controls I2C from PMIC side + type: boolean + + mediatek,use-push-pull: + description: Use push-pull mode I/O config + type: boolean + + vbus-supply: + description: Phandle to the regulator providing power to SCL/SDA + +required: + - compatible + - reg + - clocks + - clock-names + - clock-div + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include + #include + + i2c0: i2c@1100d000 { + compatible = "mediatek,mt6577-i2c"; + reg = <0x1100d000 0x70>, <0x11000300 0x80>; + interrupts = ; + clocks = <&i2c0_ck>, <&ap_dma_ck>; + clock-names = "main", "dma"; + clock-div = <16>; + clock-frequency = <400000>; + mediatek,have-pmic; + + #address-cells = <1>; + #size-cells = <0>; + }; -- cgit From 081e8432adb192dd61a346eb23d3c415acb2fcaf Mon Sep 17 00:00:00 2001 From: Philipp Zabel Date: Thu, 7 Apr 2022 16:58:02 +0200 Subject: dt-bindings: reset: Drop the hisilicon,hi6220-reset binding The hisilicon,hi6220-sysctrl, hisilicon,hi6220-mediactrl, and hisilicon,hi6220-aoctrl controllers are already described in: Documentation/devicetree/bindings/arm/hisilicon/controller/sysctrl.yaml Documentation/devicetree/bindings/arm/hisilicon/controller/hi6220-domain-ctrl.yaml Signed-off-by: Philipp Zabel Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220407145802.4060130-1-p.zabel@pengutronix.de --- .../bindings/reset/hisilicon,hi6220-reset.txt | 37 ---------------------- 1 file changed, 37 deletions(-) delete mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt deleted file mode 100644 index ea0a6a9734c1..000000000000 --- a/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt +++ /dev/null @@ -1,37 +0,0 @@ -Hisilicon System Reset Controller -====================================== - -Please also refer to reset.txt in this directory for common reset -controller binding usage. - -The reset controller registers are part of the system-ctl block on -hi6220 SoC. - -Required properties: -- compatible: should be one of the following: - - "hisilicon,hi6220-sysctrl", "syscon" : For peripheral reset controller. - - "hisilicon,hi6220-mediactrl", "syscon" : For media reset controller. - - "hisilicon,hi6220-aoctrl", "syscon" : For ao reset controller. -- reg: should be register base and length as documented in the - datasheet -- #reset-cells: 1, see below - -Example: -sys_ctrl: sys_ctrl@f7030000 { - compatible = "hisilicon,hi6220-sysctrl", "syscon"; - reg = <0x0 0xf7030000 0x0 0x2000>; - #clock-cells = <1>; - #reset-cells = <1>; -}; - -Specifying reset lines connected to IP modules -============================================== -example: - - uart1: serial@..... { - ... - resets = <&sys_ctrl PERIPH_RSTEN3_UART1>; - ... - }; - -The index could be found in . -- cgit From 673283a3be1718a58ab9ff7762ef4ec6bcf505c4 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 7 Apr 2022 16:34:05 +0200 Subject: dt-bindings: align SPI NOR node name with dtschema The node names should be generic and SPI NOR dtschema expects "flash". Signed-off-by: Krzysztof Kozlowski Acked-by: Mark Brown Reviewed-by: Miquel Raynal Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220407143405.295907-1-krzysztof.kozlowski@linaro.org --- Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt | 2 +- Documentation/devicetree/bindings/spi/spi-davinci.txt | 2 +- Documentation/devicetree/bindings/spi/spi-pl022.yaml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt b/Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt index 74981520d6dd..a99de13c7ccd 100644 --- a/Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt +++ b/Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt @@ -17,7 +17,7 @@ spi-nor-controller@10000000 { reg = <0x10000000 0x1000>, <0x14000000 0x1000000>; reg-names = "control", "memory"; clocks = <&clock HI3519_FMC_CLK>; - spi-nor@0 { + flash@0 { compatible = "jedec,spi-nor"; reg = <0>; }; diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt b/Documentation/devicetree/bindings/spi/spi-davinci.txt index 200c7fc7b089..f012888656ec 100644 --- a/Documentation/devicetree/bindings/spi/spi-davinci.txt +++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt @@ -78,7 +78,7 @@ spi0:spi@20bf0000 { interrupts = <338>; clocks = <&clkspi>; - flash: n25q032@0 { + flash: flash@0 { #address-cells = <1>; #size-cells = <1>; compatible = "st,m25p32"; diff --git a/Documentation/devicetree/bindings/spi/spi-pl022.yaml b/Documentation/devicetree/bindings/spi/spi-pl022.yaml index bda45ff3d294..0e382119c64f 100644 --- a/Documentation/devicetree/bindings/spi/spi-pl022.yaml +++ b/Documentation/devicetree/bindings/spi/spi-pl022.yaml @@ -143,7 +143,7 @@ examples: <&dma_controller 24 0>; dma-names = "rx", "tx"; - m25p80@1 { + flash@1 { compatible = "st,m25p80"; reg = <1>; spi-max-frequency = <12000000>; -- cgit From 981a340540381532652731a500ba9df768bcef7d Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 7 Apr 2022 21:35:42 +0200 Subject: dt-bindings: power: renesas,rcar-sysc: drop useless consumer example Consumer examples in the bindings of resource providers are trivial, useless and duplication of code. Remove the example code for consumer. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220407193542.17230-1-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/power/renesas,rcar-sysc.yaml | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml index 62a49ca319ec..bd9608c83c3f 100644 --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml @@ -10,9 +10,11 @@ maintainers: - Geert Uytterhoeven - Magnus Damm -description: +description: | The R-Car (RZ/G) System Controller provides power management for the CPU cores and various coprocessors. + The power domain IDs for consumers are defined in header files:: + include.dt-bindings/power/r8*-sysc.h properties: compatible: @@ -64,14 +66,3 @@ examples: reg = <0xe6180000 0x0200>; #power-domain-cells = <1>; }; - - - | - // Power Domain consumers - #include - - cache-controller-0 { - compatible = "cache"; - power-domains = <&sysc R8A7791_PD_CA15_SCU>; - cache-unified; - cache-level = <2>; - }; -- cgit From ccc706353d1b89d8ff1726e575dd4a10f8550fb7 Mon Sep 17 00:00:00 2001 From: Rohit Agarwal Date: Wed, 16 Mar 2022 11:37:14 +0530 Subject: dt-bindings: power: Add rpm power domain bindings for SDX65 Add RPM power domain bindings for the SDX65 SoC. Signed-off-by: Rohit Agarwal Acked-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/1647410837-22537-4-git-send-email-quic_rohiagar@quicinc.com --- Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index 940e97b565bf..b90c4427beec 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -33,6 +33,7 @@ properties: - qcom,sc8180x-rpmhpd - qcom,sdm845-rpmhpd - qcom,sdx55-rpmhpd + - qcom,sdx65-rpmhpd - qcom,sm6115-rpmpd - qcom,sm6125-rpmpd - qcom,sm6350-rpmhpd -- cgit From 50c4decc1b15313afa31f9a99da0904fa9c9b071 Mon Sep 17 00:00:00 2001 From: Mario Limonciello Date: Thu, 31 Mar 2022 16:12:11 -0500 Subject: crypto: ccp - Export PSP security bits to userspace The PSP sets several pre-defined bits in the capabilities register to indicate that security attributes of the platform. Export these attributes into userspace for administrators to confirm platform is properly locked down. Acked-by: Tom Lendacky Signed-off-by: Mario Limonciello Signed-off-by: Herbert Xu --- Documentation/ABI/testing/sysfs-driver-ccp | 87 ++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-ccp (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-ccp b/Documentation/ABI/testing/sysfs-driver-ccp new file mode 100644 index 000000000000..7aded9b75553 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-ccp @@ -0,0 +1,87 @@ +What: /sys/bus/pci/devices//fused_part +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices//fused_part file reports + whether the CPU or APU has been fused to prevent tampering. + 0: Not fused + 1: Fused + +What: /sys/bus/pci/devices//debug_lock_on +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices//debug_lock_on reports + whether the AMD CPU or APU has been unlocked for debugging. + Possible values: + 0: Not locked + 1: Locked + +What: /sys/bus/pci/devices//tsme_status +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices//tsme_status file reports + the status of transparent secure memory encryption on AMD systems. + Possible values: + 0: Not active + 1: Active + +What: /sys/bus/pci/devices//anti_rollback_status +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices//anti_rollback_status file reports + whether the PSP is enforcing rollback protection. + Possible values: + 0: Not enforcing + 1: Enforcing + +What: /sys/bus/pci/devices//rpmc_production_enabled +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices//rpmc_production_enabled file reports + whether Replay Protected Monotonic Counter support has been enabled. + Possible values: + 0: Not enabled + 1: Enabled + +What: /sys/bus/pci/devices//rpmc_spirom_available +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices//rpmc_spirom_available file reports + whether an Replay Protected Monotonic Counter supported SPI is installed + on the system. + Possible values: + 0: Not present + 1: Present + +What: /sys/bus/pci/devices//hsp_tpm_available +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices//hsp_tpm_available file reports + whether the HSP TPM has been activated. + Possible values: + 0: Not activated or present + 1: Activated + +What: /sys/bus/pci/devices//rom_armor_enforced +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices//rom_armor_enforced file reports + whether RomArmor SPI protection is enforced. + Possible values: + 0: Not enforced + 1: Enforced -- cgit From 2610bd72efe4b376febd477425769f647152a3a8 Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Tue, 5 Apr 2022 16:53:00 +0900 Subject: dt-bindings: net: ave: Clean up clocks, resets, and their names using compatible string Instead of "oneOf:" choices, use "allOf:" and "if:" to define clocks, resets, and their names that can be taken by the compatible string. The order of clock-names and reset-names doesn't change here. Signed-off-by: Kunihiko Hayashi Reviewed-by: Rob Herring Signed-off-by: David S. Miller --- .../bindings/net/socionext,uniphier-ave4.yaml | 55 +++++++++++++++------- 1 file changed, 38 insertions(+), 17 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml index e602761f7b14..f257520b9a7e 100644 --- a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml @@ -13,9 +13,6 @@ description: | This describes the devicetree bindings for AVE ethernet controller implemented on Socionext UniPhier SoCs. -allOf: - - $ref: ethernet-controller.yaml# - properties: compatible: enum: @@ -44,25 +41,13 @@ properties: minItems: 1 maxItems: 4 - clock-names: - oneOf: - - items: # for Pro4 - - const: gio - - const: ether - - const: ether-gb - - const: ether-phy - - const: ether # for others + clock-names: true resets: minItems: 1 maxItems: 2 - reset-names: - oneOf: - - items: # for Pro4 - - const: gio - - const: ether - - const: ether # for others + reset-names: true socionext,syscon-phy-mode: $ref: /schemas/types.yaml#/definitions/phandle-array @@ -78,6 +63,42 @@ properties: $ref: mdio.yaml# unevaluatedProperties: false +allOf: + - $ref: ethernet-controller.yaml# + - if: + properties: + compatible: + contains: + const: socionext,uniphier-pro4-ave4 + then: + properties: + clocks: + minItems: 4 + maxItems: 4 + clock-names: + items: + - const: gio + - const: ether + - const: ether-gb + - const: ether-phy + resets: + minItems: 2 + maxItems: 2 + reset-names: + items: + - const: gio + - const: ether + else: + properties: + clocks: + maxItems: 1 + clock-names: + const: ether + resets: + maxItems: 1 + reset-names: + const: ether + required: - compatible - reg -- cgit From 5a80059d88046b0a87e957565363ba3ee57600bb Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Tue, 5 Apr 2022 16:53:01 +0900 Subject: dt-bindings: net: ave: Use unevaluatedProperties This refers common bindings, so this is preferred for unevaluatedProperties instead of additionalProperties. Signed-off-by: Kunihiko Hayashi Acked-by: Rob Herring Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml index f257520b9a7e..b0ebcef6801c 100644 --- a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml @@ -111,7 +111,7 @@ required: - reset-names - mdio -additionalProperties: false +unevaluatedProperties: false examples: - | -- cgit From 1efe7eca170d344c5101c69ac51df6982de764e4 Mon Sep 17 00:00:00 2001 From: Jiaxin Yu Date: Fri, 8 Apr 2022 14:05:49 +0800 Subject: ASoC: dt-bindings: mt8192-mt6359: add new compatible and new properties MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 1. Adds new compatible string "mt8192_mt6359_rt1015p_rt5682s" for machines with rt1015p and rt5682s. 2. Adds new property "headset-codec" for getting headset codec. 3. Adds new property "speaker-codecs" for getting speaker codecs. Signed-off-by: Jiaxin Yu Reviewed-by: Rob Herring Reviewed-by: Nícolas F. R. A. Prado Tested-by: Nícolas F. R. A. Prado Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220408060552.26607-2-jiaxin.yu@mediatek.com Signed-off-by: Mark Brown --- .../sound/mt8192-mt6359-rt1015-rt5682.yaml | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml index 5a5b765b859a..4fa179909c62 100644 --- a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml +++ b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml @@ -18,6 +18,7 @@ properties: enum: - mediatek,mt8192_mt6359_rt1015_rt5682 - mediatek,mt8192_mt6359_rt1015p_rt5682 + - mediatek,mt8192_mt6359_rt1015p_rt5682s mediatek,platform: $ref: "/schemas/types.yaml#/definitions/phandle" @@ -27,11 +28,33 @@ properties: $ref: "/schemas/types.yaml#/definitions/phandle" description: The phandle of HDMI codec. + headset-codec: + type: object + properties: + sound-dai: + $ref: /schemas/types.yaml#/definitions/phandle + required: + - sound-dai + + speaker-codecs: + type: object + properties: + sound-dai: + minItems: 1 + maxItems: 2 + items: + maxItems: 1 + $ref: /schemas/types.yaml#/definitions/phandle-array + required: + - sound-dai + additionalProperties: false required: - compatible - mediatek,platform + - headset-codec + - speaker-codecs examples: - | @@ -44,6 +67,15 @@ examples: "aud_clk_mosi_on"; pinctrl-0 = <&aud_clk_mosi_off>; pinctrl-1 = <&aud_clk_mosi_on>; + + headset-codec { + sound-dai = <&rt5682>; + }; + + speaker-codecs { + sound-dai = <&rt1015_l>, + <&rt1015_r>; + }; }; ... -- cgit From 2cd1881b9821be68d1eb748c96311258b16af225 Mon Sep 17 00:00:00 2001 From: Gal Pressman Date: Wed, 6 Apr 2022 16:54:20 +0300 Subject: bonding: Update layer2 and layer2+3 hash formula documentation When using layer2 or layer2+3 hash, only the 5th byte of the MAC addresses is used. Signed-off-by: Gal Pressman Signed-off-by: David S. Miller --- Documentation/networking/bonding.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/bonding.rst b/Documentation/networking/bonding.rst index 525e6842dd33..43be3782e5df 100644 --- a/Documentation/networking/bonding.rst +++ b/Documentation/networking/bonding.rst @@ -894,7 +894,7 @@ xmit_hash_policy Uses XOR of hardware MAC addresses and packet type ID field to generate the hash. The formula is - hash = source MAC XOR destination MAC XOR packet type ID + hash = source MAC[5] XOR destination MAC[5] XOR packet type ID slave number = hash modulo slave count This algorithm will place all traffic to a particular @@ -910,7 +910,7 @@ xmit_hash_policy Uses XOR of hardware MAC addresses and IP addresses to generate the hash. The formula is - hash = source MAC XOR destination MAC XOR packet type ID + hash = source MAC[5] XOR destination MAC[5] XOR packet type ID hash = hash XOR source IP XOR destination IP hash = hash XOR (hash RSHIFT 16) hash = hash XOR (hash RSHIFT 8) -- cgit From 6c389328c985a3aa8575cf3a573a05c1d121fceb Mon Sep 17 00:00:00 2001 From: Hou Zhiqiang Date: Fri, 11 Mar 2022 17:49:35 -0600 Subject: dt-bindings: pci: layerscape-pci: Add a optional property big-endian This property is to indicate the endianness when accessing the PEX_LUT and PF register block, so if these registers are implemented in big-endian, specify this property. Link: https://lore.kernel.org/r/20220311234938.8706-2-leoyang.li@nxp.com Signed-off-by: Hou Zhiqiang Signed-off-by: Lorenzo Pieralisi Acked-by: Rob Herring --- Documentation/devicetree/bindings/pci/layerscape-pci.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index f36efa73a470..215d2ee65c83 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -40,6 +40,10 @@ Required properties: of the data transferred from/to the IP block. This can avoid the software cache flush/invalid actions, and improve the performance significantly. +Optional properties: +- big-endian: If the PEX_LUT and PF register block is in big-endian, specify + this property. + Example: pcie@3400000 { -- cgit From 84f293b204ab1ef519278e7993e9930f03879627 Mon Sep 17 00:00:00 2001 From: Hou Zhiqiang Date: Fri, 11 Mar 2022 17:49:36 -0600 Subject: dt-bindings: pci: layerscape-pci: Update the description of SCFG property Update the description of the second entry of 'fsl,pcie-scfg' property, as the LS1043A PCIe controller also has some control registers in SCFG block, while it has 3 controllers. Link: https://lore.kernel.org/r/20220311234938.8706-3-leoyang.li@nxp.com Signed-off-by: Hou Zhiqiang Signed-off-by: Lorenzo Pieralisi Acked-by: Rob Herring --- Documentation/devicetree/bindings/pci/layerscape-pci.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index 215d2ee65c83..f1115fcd8088 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -34,7 +34,7 @@ Required properties: "intr": The interrupt that is asserted for controller interrupts - fsl,pcie-scfg: Must include two entries. The first entry must be a link to the SCFG device node - The second entry must be '0' or '1' based on physical PCIe controller index. + The second entry is the physical PCIe controller index starting from '0'. This is used to get SCFG PEXN registers - dma-coherent: Indicates that the hardware IP block can ensure the coherency of the data transferred from/to the IP block. This can avoid the software -- cgit From cddc1a9ab360d10891bf05e178ea225fb2791355 Mon Sep 17 00:00:00 2001 From: Xiaowei Bao Date: Fri, 11 Mar 2022 17:49:37 -0600 Subject: dt-bindings: pci: layerscape-pci: Add EP mode compatible strings for ls1028a Add EP mode compatible string for ls1028a. Link: https://lore.kernel.org/r/20220311234938.8706-4-leoyang.li@nxp.com Signed-off-by: Xiaowei Bao Signed-off-by: Hou Zhiqiang Signed-off-by: Li Yang Signed-off-by: Lorenzo Pieralisi Acked-by: Rob Herring --- Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index f1115fcd8088..8fd6039a826b 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -23,6 +23,7 @@ Required properties: "fsl,ls1012a-pcie" "fsl,ls1028a-pcie" EP mode: + "fsl,ls1028a-pcie-ep", "fsl,ls-pcie-ep" "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep" "fsl,ls1088a-pcie-ep", "fsl,ls-pcie-ep" "fsl,ls2088a-pcie-ep", "fsl,ls-pcie-ep" -- cgit From a3b18f5f1d42e7e08eda5d131a34b352a50deb6e Mon Sep 17 00:00:00 2001 From: Li Yang Date: Fri, 11 Mar 2022 17:49:38 -0600 Subject: dt-bindings: pci: layerscape-pci: define AER/PME interrupts Different platforms using this controller are using different numbers of interrupt lines and the routing of events to these interrupt lines are different too. So instead of trying to define names for these interrupt lines, we define the more specific AER/PME events that are routed to these interrupt lines. For platforms which only has a single interrupt line for miscellaneous controller events, we can keep using the original "intr" name for backward compatibility. Also change the example from ls1021a to ls1088a for better representation. Link: https://lore.kernel.org/r/20220311234938.8706-5-leoyang.li@nxp.com Signed-off-by: Li Yang Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring --- .../devicetree/bindings/pci/layerscape-pci.txt | 58 ++++++++++++---------- 1 file changed, 32 insertions(+), 26 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index 8fd6039a826b..ee8a4791a78b 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -31,8 +31,14 @@ Required properties: - reg: base addresses and lengths of the PCIe controller register blocks. - interrupts: A list of interrupt outputs of the controller. Must contain an entry for each entry in the interrupt-names property. -- interrupt-names: Must include the following entries: - "intr": The interrupt that is asserted for controller interrupts +- interrupt-names: It could include the following entries: + "aer": Used for interrupt line which reports AER events when + non MSI/MSI-X/INTx mode is used + "pme": Used for interrupt line which reports PME events when + non MSI/MSI-X/INTx mode is used + "intr": Used for SoCs(like ls2080a, lx2160a, ls2080a, ls2088a, ls1088a) + which has a single interrupt line for miscellaneous controller + events(could include AER and PME events). - fsl,pcie-scfg: Must include two entries. The first entry must be a link to the SCFG device node The second entry is the physical PCIe controller index starting from '0'. @@ -47,27 +53,27 @@ Optional properties: Example: - pcie@3400000 { - compatible = "fsl,ls1021a-pcie"; - reg = <0x00 0x03400000 0x0 0x00010000 /* controller registers */ - 0x40 0x00000000 0x0 0x00002000>; /* configuration space */ - reg-names = "regs", "config"; - interrupts = ; /* controller interrupt */ - interrupt-names = "intr"; - fsl,pcie-scfg = <&scfg 0>; - #address-cells = <3>; - #size-cells = <2>; - device_type = "pci"; - dma-coherent; - num-lanes = <4>; - bus-range = <0x0 0xff>; - ranges = <0x81000000 0x0 0x00000000 0x40 0x00010000 0x0 0x00010000 /* downstream I/O */ - 0xc2000000 0x0 0x20000000 0x40 0x20000000 0x0 0x20000000 /* prefetchable memory */ - 0x82000000 0x0 0x40000000 0x40 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */ - #interrupt-cells = <1>; - interrupt-map-mask = <0 0 0 7>; - interrupt-map = <0000 0 0 1 &gic GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>, - <0000 0 0 2 &gic GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>, - <0000 0 0 3 &gic GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>, - <0000 0 0 4 &gic GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>; - }; + pcie@3400000 { + compatible = "fsl,ls1088a-pcie"; + reg = <0x00 0x03400000 0x0 0x00100000>, /* controller registers */ + <0x20 0x00000000 0x0 0x00002000>; /* configuration space */ + reg-names = "regs", "config"; + interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>; /* aer interrupt */ + interrupt-names = "aer"; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + dma-coherent; + num-viewport = <256>; + bus-range = <0x0 0xff>; + ranges = <0x81000000 0x0 0x00000000 0x20 0x00010000 0x0 0x00010000 /* downstream I/O */ + 0x82000000 0x0 0x40000000 0x20 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */ + msi-parent = <&its>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0000 0 0 1 &gic 0 0 0 109 IRQ_TYPE_LEVEL_HIGH>, + <0000 0 0 2 &gic 0 0 0 110 IRQ_TYPE_LEVEL_HIGH>, + <0000 0 0 3 &gic 0 0 0 111 IRQ_TYPE_LEVEL_HIGH>, + <0000 0 0 4 &gic 0 0 0 112 IRQ_TYPE_LEVEL_HIGH>; + iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */ + }; -- cgit From 06006ad29abeee1f94d1793107309ce100067e46 Mon Sep 17 00:00:00 2001 From: Zong Li Date: Mon, 28 Mar 2022 17:52:22 +0800 Subject: dt-bindings: dma-engine: sifive,fu540: Add dma-channels property and modify compatible Add dma-channels property, then we can determine how many channels there by device tree, rather than statically defining it in PDMA driver. In addition, we also modify the compatible for PDMA versioning scheme. Signed-off-by: Zong Li Reviewed-by: Rob Herring Suggested-by: Palmer Dabbelt Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt Acked-by: Krzysztof Kozlowski Reviewed-by: Bin Meng Link: https://lore.kernel.org/r/7cc9a7b5f7e6c28fc9eb172c441b5aed2159b8a0.1648461096.git.zong.li@sifive.com Signed-off-by: Vinod Koul --- .../bindings/dma/sifive,fu540-c000-pdma.yaml | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml index 47c46af25536..3271755787b4 100644 --- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml +++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml @@ -28,7 +28,15 @@ allOf: properties: compatible: items: - - const: sifive,fu540-c000-pdma + - enum: + - sifive,fu540-c000-pdma + - const: sifive,pdma0 + description: + Should be "sifive,-pdma" and "sifive,pdma". + Supported compatible strings are - + "sifive,fu540-c000-pdma" for the SiFive PDMA v0 as integrated onto the + SiFive FU540 chip resp and "sifive,pdma0" for the SiFive PDMA v0 IP block + with no chip integration tweaks. reg: maxItems: 1 @@ -37,6 +45,12 @@ properties: minItems: 1 maxItems: 8 + dma-channels: + description: For backwards-compatibility, the default value is 4 + minimum: 1 + maximum: 4 + default: 4 + '#dma-cells': const: 1 @@ -50,8 +64,9 @@ unevaluatedProperties: false examples: - | dma-controller@3000000 { - compatible = "sifive,fu540-c000-pdma"; + compatible = "sifive,fu540-c000-pdma", "sifive,pdma0"; reg = <0x3000000 0x8000>; + dma-channels = <4>; interrupts = <23>, <24>, <25>, <26>, <27>, <28>, <29>, <30>; #dma-cells = <1>; }; -- cgit From b9c7ba58777acfd0892b808aea25074d46e0618f Mon Sep 17 00:00:00 2001 From: Kuppuswamy Sathyanarayanan Date: Wed, 6 Apr 2022 02:29:39 +0300 Subject: Documentation/x86: Document TDX kernel architecture Document the TDX guest architecture details like #VE support, shared memory, etc. [ dhansen: made some wording changes, including removing all the plural "#VE's" and "#VEs". ] Signed-off-by: Kuppuswamy Sathyanarayanan Signed-off-by: Kirill A. Shutemov Signed-off-by: Dave Hansen Reviewed-by: Dave Hansen Link: https://lkml.kernel.org/r/20220405232939.73860-31-kirill.shutemov@linux.intel.com --- Documentation/x86/index.rst | 1 + Documentation/x86/tdx.rst | 218 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 219 insertions(+) create mode 100644 Documentation/x86/tdx.rst (limited to 'Documentation') diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index 91b2fa456618..51982dee6c2a 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -26,6 +26,7 @@ x86-specific Documentation intel_txt amd-memory-encryption amd_hsmp + tdx pti mds microcode diff --git a/Documentation/x86/tdx.rst b/Documentation/x86/tdx.rst new file mode 100644 index 000000000000..b8fa4329e1a5 --- /dev/null +++ b/Documentation/x86/tdx.rst @@ -0,0 +1,218 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================================== +Intel Trust Domain Extensions (TDX) +===================================== + +Intel's Trust Domain Extensions (TDX) protect confidential guest VMs from +the host and physical attacks by isolating the guest register state and by +encrypting the guest memory. In TDX, a special module running in a special +mode sits between the host and the guest and manages the guest/host +separation. + +Since the host cannot directly access guest registers or memory, much +normal functionality of a hypervisor must be moved into the guest. This is +implemented using a Virtualization Exception (#VE) that is handled by the +guest kernel. A #VE is handled entirely inside the guest kernel, but some +require the hypervisor to be consulted. + +TDX includes new hypercall-like mechanisms for communicating from the +guest to the hypervisor or the TDX module. + +New TDX Exceptions +================== + +TDX guests behave differently from bare-metal and traditional VMX guests. +In TDX guests, otherwise normal instructions or memory accesses can cause +#VE or #GP exceptions. + +Instructions marked with an '*' conditionally cause exceptions. The +details for these instructions are discussed below. + +Instruction-based #VE +--------------------- + +- Port I/O (INS, OUTS, IN, OUT) +- HLT +- MONITOR, MWAIT +- WBINVD, INVD +- VMCALL +- RDMSR*,WRMSR* +- CPUID* + +Instruction-based #GP +--------------------- + +- All VMX instructions: INVEPT, INVVPID, VMCLEAR, VMFUNC, VMLAUNCH, + VMPTRLD, VMPTRST, VMREAD, VMRESUME, VMWRITE, VMXOFF, VMXON +- ENCLS, ENCLU +- GETSEC +- RSM +- ENQCMD +- RDMSR*,WRMSR* + +RDMSR/WRMSR Behavior +-------------------- + +MSR access behavior falls into three categories: + +- #GP generated +- #VE generated +- "Just works" + +In general, the #GP MSRs should not be used in guests. Their use likely +indicates a bug in the guest. The guest may try to handle the #GP with a +hypercall but it is unlikely to succeed. + +The #VE MSRs are typically able to be handled by the hypervisor. Guests +can make a hypercall to the hypervisor to handle the #VE. + +The "just works" MSRs do not need any special guest handling. They might +be implemented by directly passing through the MSR to the hardware or by +trapping and handling in the TDX module. Other than possibly being slow, +these MSRs appear to function just as they would on bare metal. + +CPUID Behavior +-------------- + +For some CPUID leaves and sub-leaves, the virtualized bit fields of CPUID +return values (in guest EAX/EBX/ECX/EDX) are configurable by the +hypervisor. For such cases, the Intel TDX module architecture defines two +virtualization types: + +- Bit fields for which the hypervisor controls the value seen by the guest + TD. + +- Bit fields for which the hypervisor configures the value such that the + guest TD either sees their native value or a value of 0. For these bit + fields, the hypervisor can mask off the native values, but it can not + turn *on* values. + +A #VE is generated for CPUID leaves and sub-leaves that the TDX module does +not know how to handle. The guest kernel may ask the hypervisor for the +value with a hypercall. + +#VE on Memory Accesses +====================== + +There are essentially two classes of TDX memory: private and shared. +Private memory receives full TDX protections. Its content is protected +against access from the hypervisor. Shared memory is expected to be +shared between guest and hypervisor and does not receive full TDX +protections. + +A TD guest is in control of whether its memory accesses are treated as +private or shared. It selects the behavior with a bit in its page table +entries. This helps ensure that a guest does not place sensitive +information in shared memory, exposing it to the untrusted hypervisor. + +#VE on Shared Memory +-------------------- + +Access to shared mappings can cause a #VE. The hypervisor ultimately +controls whether a shared memory access causes a #VE, so the guest must be +careful to only reference shared pages it can safely handle a #VE. For +instance, the guest should be careful not to access shared memory in the +#VE handler before it reads the #VE info structure (TDG.VP.VEINFO.GET). + +Shared mapping content is entirely controlled by the hypervisor. The guest +should only use shared mappings for communicating with the hypervisor. +Shared mappings must never be used for sensitive memory content like kernel +stacks. A good rule of thumb is that hypervisor-shared memory should be +treated the same as memory mapped to userspace. Both the hypervisor and +userspace are completely untrusted. + +MMIO for virtual devices is implemented as shared memory. The guest must +be careful not to access device MMIO regions unless it is also prepared to +handle a #VE. + +#VE on Private Pages +-------------------- + +An access to private mappings can also cause a #VE. Since all kernel +memory is also private memory, the kernel might theoretically need to +handle a #VE on arbitrary kernel memory accesses. This is not feasible, so +TDX guests ensure that all guest memory has been "accepted" before memory +is used by the kernel. + +A modest amount of memory (typically 512M) is pre-accepted by the firmware +before the kernel runs to ensure that the kernel can start up without +being subjected to a #VE. + +The hypervisor is permitted to unilaterally move accepted pages to a +"blocked" state. However, if it does this, page access will not generate a +#VE. It will, instead, cause a "TD Exit" where the hypervisor is required +to handle the exception. + +Linux #VE handler +================= + +Just like page faults or #GP's, #VE exceptions can be either handled or be +fatal. Typically, an unhandled userspace #VE results in a SIGSEGV. +An unhandled kernel #VE results in an oops. + +Handling nested exceptions on x86 is typically nasty business. A #VE +could be interrupted by an NMI which triggers another #VE and hilarity +ensues. The TDX #VE architecture anticipated this scenario and includes a +feature to make it slightly less nasty. + +During #VE handling, the TDX module ensures that all interrupts (including +NMIs) are blocked. The block remains in place until the guest makes a +TDG.VP.VEINFO.GET TDCALL. This allows the guest to control when interrupts +or a new #VE can be delivered. + +However, the guest kernel must still be careful to avoid potential +#VE-triggering actions (discussed above) while this block is in place. +While the block is in place, any #VE is elevated to a double fault (#DF) +which is not recoverable. + +MMIO handling +============= + +In non-TDX VMs, MMIO is usually implemented by giving a guest access to a +mapping which will cause a VMEXIT on access, and then the hypervisor +emulates the access. That is not possible in TDX guests because VMEXIT +will expose the register state to the host. TDX guests don't trust the host +and can't have their state exposed to the host. + +In TDX, MMIO regions typically trigger a #VE exception in the guest. The +guest #VE handler then emulates the MMIO instruction inside the guest and +converts it into a controlled TDCALL to the host, rather than exposing +guest state to the host. + +MMIO addresses on x86 are just special physical addresses. They can +theoretically be accessed with any instruction that accesses memory. +However, the kernel instruction decoding method is limited. It is only +designed to decode instructions like those generated by io.h macros. + +MMIO access via other means (like structure overlays) may result in an +oops. + +Shared Memory Conversions +========================= + +All TDX guest memory starts out as private at boot. This memory can not +be accessed by the hypervisor. However, some kernel users like device +drivers might have a need to share data with the hypervisor. To do this, +memory must be converted between shared and private. This can be +accomplished using some existing memory encryption helpers: + + * set_memory_decrypted() converts a range of pages to shared. + * set_memory_encrypted() converts memory back to private. + +Device drivers are the primary user of shared memory, but there's no need +to touch every driver. DMA buffers and ioremap() do the conversions +automatically. + +TDX uses SWIOTLB for most DMA allocations. The SWIOTLB buffer is +converted to shared on boot. + +For coherent DMA allocation, the DMA buffer gets converted on the +allocation. Check force_dma_unencrypted() for details. + +References +========== + +TDX reference material is collected here: + +https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html -- cgit From 998282c6dad8ff0f981d2f18b1d0278760ff5d81 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Mon, 13 Dec 2021 09:26:04 +0100 Subject: dt-bindings: qcom,pdc: Add SM6350 compatible Add devicetree compatible for pdc on SM6350 SoC. Also correct the compatibles for sm8250 and sm8350. Signed-off-by: Luca Weiss Acked-by: Rob Herring Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20211213082614.22651-4-luca.weiss@fairphone.com --- Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt index 98d89e53013d..3b7b1134dea9 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt @@ -21,8 +21,9 @@ Properties: - "qcom,sc7180-pdc": For SC7180 - "qcom,sc7280-pdc": For SC7280 - "qcom,sdm845-pdc": For SDM845 - - "qcom,sdm8250-pdc": For SM8250 - - "qcom,sdm8350-pdc": For SM8350 + - "qcom,sm6350-pdc": For SM6350 + - "qcom,sm8250-pdc": For SM8250 + - "qcom,sm8350-pdc": For SM8350 - reg: Usage: required -- cgit From 0bd1767942625c0f7654b7f0829920e1dabcfbcf Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Mon, 13 Dec 2021 09:26:06 +0100 Subject: dt-bindings: thermal: tsens: Add SM6350 compatible Add devicetree compatible for tsens on SM6350 SoC. Signed-off-by: Luca Weiss Acked-by: Konrad Dybcio Acked-by: Rob Herring Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20211213082614.22651-6-luca.weiss@fairphone.com --- Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index b6406bcc683f..55a16d2f13c9 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -51,6 +51,7 @@ properties: - qcom,sc8180x-tsens - qcom,sdm630-tsens - qcom,sdm845-tsens + - qcom,sm6350-tsens - qcom,sm8150-tsens - qcom,sm8250-tsens - qcom,sm8350-tsens -- cgit From aecf03614d5ded3f930143cda2ba3d76d09b107d Mon Sep 17 00:00:00 2001 From: Raphael-Xu <13691752556@139.com> Date: Fri, 8 Apr 2022 22:11:18 +0800 Subject: ASoC: rename tas2764 to tas27xx rename tas2764.yaml to tas27xx.yaml Signed-off-by: Raphael-Xu <13691752556@139.com> Link: https://lore.kernel.org/r/20220408141119.958-1-13691752556@139.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/tas2764.yaml | 76 ---------------------- .../devicetree/bindings/sound/tas27xx.yaml | 76 ++++++++++++++++++++++ 2 files changed, 76 insertions(+), 76 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/tas2764.yaml create mode 100644 Documentation/devicetree/bindings/sound/tas27xx.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/tas2764.yaml b/Documentation/devicetree/bindings/sound/tas2764.yaml deleted file mode 100644 index 5bf8c76ecda1..000000000000 --- a/Documentation/devicetree/bindings/sound/tas2764.yaml +++ /dev/null @@ -1,76 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -# Copyright (C) 2020 Texas Instruments Incorporated -%YAML 1.2 ---- -$id: "http://devicetree.org/schemas/sound/tas2764.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" - -title: Texas Instruments TAS2764 Smart PA - -maintainers: - - Dan Murphy - -description: | - The TAS2764 is a mono, digital input Class-D audio amplifier optimized for - efficiently driving high peak power into small loudspeakers. - Integrated speaker voltage and current sense provides for - real time monitoring of loudspeaker behavior. - -properties: - compatible: - enum: - - ti,tas2764 - - reg: - maxItems: 1 - description: | - I2C address of the device can be between 0x38 to 0x45. - - reset-gpios: - maxItems: 1 - description: GPIO used to reset the device. - - shutdown-gpios: - maxItems: 1 - description: GPIO used to control the state of the device. - - interrupts: - maxItems: 1 - - ti,imon-slot-no: - $ref: /schemas/types.yaml#/definitions/uint32 - description: TDM TX current sense time slot. - - ti,vmon-slot-no: - $ref: /schemas/types.yaml#/definitions/uint32 - description: TDM TX voltage sense time slot. - - '#sound-dai-cells': - const: 1 - -required: - - compatible - - reg - -additionalProperties: false - -examples: - - | - #include - i2c0 { - #address-cells = <1>; - #size-cells = <0>; - codec: codec@38 { - compatible = "ti,tas2764"; - reg = <0x38>; - #sound-dai-cells = <1>; - interrupt-parent = <&gpio1>; - interrupts = <14>; - reset-gpios = <&gpio1 15 0>; - shutdown-gpios = <&gpio1 15 0>; - ti,imon-slot-no = <0>; - ti,vmon-slot-no = <2>; - }; - }; - -... diff --git a/Documentation/devicetree/bindings/sound/tas27xx.yaml b/Documentation/devicetree/bindings/sound/tas27xx.yaml new file mode 100644 index 000000000000..5bf8c76ecda1 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tas27xx.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/sound/tas2764.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Texas Instruments TAS2764 Smart PA + +maintainers: + - Dan Murphy + +description: | + The TAS2764 is a mono, digital input Class-D audio amplifier optimized for + efficiently driving high peak power into small loudspeakers. + Integrated speaker voltage and current sense provides for + real time monitoring of loudspeaker behavior. + +properties: + compatible: + enum: + - ti,tas2764 + + reg: + maxItems: 1 + description: | + I2C address of the device can be between 0x38 to 0x45. + + reset-gpios: + maxItems: 1 + description: GPIO used to reset the device. + + shutdown-gpios: + maxItems: 1 + description: GPIO used to control the state of the device. + + interrupts: + maxItems: 1 + + ti,imon-slot-no: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TDM TX current sense time slot. + + ti,vmon-slot-no: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TDM TX voltage sense time slot. + + '#sound-dai-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + codec: codec@38 { + compatible = "ti,tas2764"; + reg = <0x38>; + #sound-dai-cells = <1>; + interrupt-parent = <&gpio1>; + interrupts = <14>; + reset-gpios = <&gpio1 15 0>; + shutdown-gpios = <&gpio1 15 0>; + ti,imon-slot-no = <0>; + ti,vmon-slot-no = <2>; + }; + }; + +... -- cgit From 239556a34385706562a481f452ce0963fb569cb8 Mon Sep 17 00:00:00 2001 From: Raphael-Xu <13691752556@139.com> Date: Fri, 8 Apr 2022 22:11:19 +0800 Subject: ASoC: update to support either TAS2764 or TAS2780 update tas27xx.yaml to support either TAS2764 or TAS2780 Signed-off-by: Raphael-Xu <13691752556@139.com> Link: https://lore.kernel.org/r/20220408141119.958-2-13691752556@139.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/tas27xx.yaml | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/tas27xx.yaml b/Documentation/devicetree/bindings/sound/tas27xx.yaml index 5bf8c76ecda1..191f4bceb4ee 100644 --- a/Documentation/devicetree/bindings/sound/tas27xx.yaml +++ b/Documentation/devicetree/bindings/sound/tas27xx.yaml @@ -1,25 +1,27 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -# Copyright (C) 2020 Texas Instruments Incorporated +# Copyright (C) 2020-2022 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/sound/tas2764.yaml#" +$id: "http://devicetree.org/schemas/sound/tas27xx.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" -title: Texas Instruments TAS2764 Smart PA +title: Texas Instruments TAS2764/TAS2780 Smart PA maintainers: - - Dan Murphy + - Shenghao Ding description: | - The TAS2764 is a mono, digital input Class-D audio amplifier optimized for - efficiently driving high peak power into small loudspeakers. - Integrated speaker voltage and current sense provides for - real time monitoring of loudspeaker behavior. + The TAS2764/TAS2780 is a mono, digital input Class-D audio amplifier + optimized for efficiently driving high peak power into small + loudspeakers. Integrated speaker voltage and current sense provides + for real time monitoring of loudspeaker behavior. properties: compatible: enum: - ti,tas2764 + or + - ti,tas2780 reg: maxItems: 1 -- cgit From 8f0e3af81711bf72b9c6138b0138bdc330d8c388 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 29 Mar 2022 11:38:03 +0200 Subject: dt-bindings: memory: renesas,rpc-if: Document R-Car H3/M3/E3 support Document support for the SPI Multi I/O Bus Controller (RPC-IF) in the R-Car H3, M3-W, M3-W+, M3-N, and E3 SoCs. Signed-off-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Acked-by: Rob Herring Link: https://lore.kernel.org/r/3784b6cb76a008fb56d6cb4ba228d78c77e710fa.1648546583.git.geert+renesas@glider.be Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/renesas,rpc-if.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml index 9a6dbf54b540..ae31dc97524c 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml @@ -31,8 +31,13 @@ properties: - renesas,r8a774b1-rpc-if # RZ/G2N - renesas,r8a774c0-rpc-if # RZ/G2E - renesas,r8a774e1-rpc-if # RZ/G2H + - renesas,r8a7795-rpc-if # R-Car H3 + - renesas,r8a7796-rpc-if # R-Car M3-W + - renesas,r8a77961-rpc-if # R-Car M3-W+ + - renesas,r8a77965-rpc-if # R-Car M3-N - renesas,r8a77970-rpc-if # R-Car V3M - renesas,r8a77980-rpc-if # R-Car V3H + - renesas,r8a77990-rpc-if # R-Car E3 - renesas,r8a77995-rpc-if # R-Car D3 - renesas,r8a779a0-rpc-if # R-Car V3U - const: renesas,rcar-gen3-rpc-if # a generic R-Car gen3 or RZ/G2{E,H,M,N} device -- cgit From 1ceaccf2b267165fcff39e374f8596dfccd2321b Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 7 Apr 2022 22:41:15 +0200 Subject: arm64: dts: synaptics: remove unused DTSI for AS370 The as370.dtsi for Synaptics AS370 SoC does not have a user (DTS board file), is uncompilable and untestable. It was added back in 2018. No user appeared since that time, so assume it won't be added. Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Arnd Bergmann --- Documentation/devicetree/bindings/arm/syna.txt | 4 ---- 1 file changed, 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/syna.txt b/Documentation/devicetree/bindings/arm/syna.txt index d8b48f2edf1b..851f48ead927 100644 --- a/Documentation/devicetree/bindings/arm/syna.txt +++ b/Documentation/devicetree/bindings/arm/syna.txt @@ -18,10 +18,6 @@ stable binding/ABI. --------------------------------------------------------------- -Boards with the Synaptics AS370 SoC shall have the following properties: - Required root node property: - compatible: "syna,as370" - Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500 shall have the following properties: -- cgit From c9cfafc51ec9feff3f10f3517ff398c0e01adeac Mon Sep 17 00:00:00 2001 From: Drew Fustini Date: Thu, 7 Apr 2022 08:46:20 -0700 Subject: dt-bindings: soc: ti: wkup_m3_ipc: convert bindings to json-schema Convert the wkup_m3_ipc bindings documentation to json-schema. Link: https://lore.kernel.org/linux-arm-kernel/20220221125522.l3tntb6i7yjxp6vb@flattered/ Suggested-by: Nishanth Menon Reviewed-by: Krzysztof Kozlowski Signed-off-by: Drew Fustini Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220407154618.2297171-1-dfustini@baylibre.com --- .../devicetree/bindings/soc/ti/wkup-m3-ipc.yaml | 81 ++++++++++++++++++++++ .../devicetree/bindings/soc/ti/wkup_m3_ipc.txt | 57 --------------- 2 files changed, 81 insertions(+), 57 deletions(-) create mode 100644 Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml delete mode 100644 Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml b/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml new file mode 100644 index 000000000000..d855c01ce61c --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/ti/wkup-m3-ipc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Wakeup M3 IPC device + +maintainers: + - Dave Gerlach + - Drew Fustini + +description: |+ + The TI AM33xx and AM43xx family of devices use a small Cortex M3 co-processor + (commonly referred to as Wakeup M3 or CM3) to help with various low power tasks + that cannot be controlled from the MPU, like suspend/resume and certain deep + C-states for CPU Idle. Once the wkup_m3_ipc driver uses the wkup_m3_rproc driver + to boot the wkup_m3, it handles communication with the CM3 using IPC registers + present in the SoC's control module and a mailbox. The wkup_m3_ipc exposes an + API to allow the SoC PM code to execute specific PM tasks. + + Wkup M3 Device Node + ==================== + A wkup_m3_ipc device node is used to represent the IPC registers within an + SoC. + +properties: + compatible: + enum: + - ti,am3352-wkup-m3-ipc # for AM33xx SoCs + - ti,am4372-wkup-m3-ipc # for AM43xx SoCs + + reg: + description: + The IPC register address space to communicate with the Wakeup M3 processor + maxItems: 1 + + interrupts: + description: wkup_m3 interrupt that signals the MPU + maxItems: 1 + + ti,rproc: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to the wkup_m3 rproc node so the IPC driver can boot it + + mboxes: + description: + phandles used by IPC framework to get correct mbox + channel for communication. Must point to appropriate + mbox_wkupm3 child node. + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - ti,rproc + - mboxes + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <1>; + #size-cells = <1>; + + mailbox: mailbox { + #mbox-cells = <1>; + }; + + wkup_m3_ipc: wkup_m3_ipc@1324 { + compatible = "ti,am3352-wkup-m3-ipc"; + reg = <0x1324 0x24>; + interrupts = <78>; + ti,rproc = <&wkup_m3>; + mboxes = <&mailbox &mbox_wkupm3>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt b/Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt deleted file mode 100644 index 401550487ed6..000000000000 --- a/Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt +++ /dev/null @@ -1,57 +0,0 @@ -Wakeup M3 IPC Driver -===================== - -The TI AM33xx and AM43xx family of devices use a small Cortex M3 co-processor -(commonly referred to as Wakeup M3 or CM3) to help with various low power tasks -that cannot be controlled from the MPU, like suspend/resume and certain deep -C-states for CPU Idle. Once the wkup_m3_ipc driver uses the wkup_m3_rproc driver -to boot the wkup_m3, it handles communication with the CM3 using IPC registers -present in the SoC's control module and a mailbox. The wkup_m3_ipc exposes an -API to allow the SoC PM code to execute specific PM tasks. - -Wkup M3 Device Node: -==================== -A wkup_m3_ipc device node is used to represent the IPC registers within an -SoC. - -Required properties: --------------------- -- compatible: Should be, - "ti,am3352-wkup-m3-ipc" for AM33xx SoCs - "ti,am4372-wkup-m3-ipc" for AM43xx SoCs -- reg: Contains the IPC register address space to communicate - with the Wakeup M3 processor -- interrupts: Contains the interrupt information for the wkup_m3 - interrupt that signals the MPU. -- ti,rproc: phandle to the wkup_m3 rproc node so the IPC driver - can boot it. -- mboxes: phandles used by IPC framework to get correct mbox - channel for communication. Must point to appropriate - mbox_wkupm3 child node. - -Example: --------- -/* AM33xx */ - l4_wkup: l4_wkup@44c00000 { - ... - - scm: scm@210000 { - compatible = "ti,am3-scm", "simple-bus"; - reg = <0x210000 0x2000>; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x210000 0x2000>; - - ... - - wkup_m3_ipc: wkup_m3_ipc@1324 { - compatible = "ti,am3352-wkup-m3-ipc"; - reg = <0x1324 0x24>; - interrupts = <78>; - ti,rproc = <&wkup_m3>; - mboxes = <&mailbox &mbox_wkupm3>; - }; - - ... - }; - }; -- cgit From 7057081cfcc584d9eb68ff8d42e5609655301992 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Thu, 7 Apr 2022 23:01:06 +0200 Subject: dt-bindings: trivial-devices: Document CPLD on DH electronics boards The CPLD on DH electronics boards is used to model arbitrary custom glue logic, however it does have SPI interface. Document the CPLD DT binding as trivial SPI device. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Mark Brown Cc: Peng Fan Cc: Rob Herring Cc: Shawn Guo Cc: devicetree@vger.kernel.org Cc: NXP Linux Team To: linux-spi@vger.kernel.org Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220407210106.256027-1-marex@denx.de --- Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 550a2e5c9e05..b2801b666078 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -87,6 +87,8 @@ properties: - devantech,srf08 # Devantech SRF10 ultrasonic ranger - devantech,srf10 + # DH electronics GmbH on-board CPLD trivial SPI device + - dh,dhcom-board # DA9053: flexible system level PMIC with multicore support - dlg,da9053 # DA9063: system PMIC for quad-core application processors -- cgit From b61b76dfef30945f175d4acfecb9beb862174f01 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Thu, 7 Apr 2022 23:01:31 +0200 Subject: dt-bindings: trivial-devices: Document CPLD on Menlo boards The CPLD on Menlo boards is used to operate custom hardware, document the CPLD DT binding as trivial SPI device. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Mark Brown Cc: Peng Fan Cc: Rob Herring Cc: Shawn Guo Cc: devicetree@vger.kernel.org Cc: NXP Linux Team To: linux-spi@vger.kernel.org Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220407210131.256045-1-marex@denx.de --- Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index b2801b666078..ac847043827d 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -217,6 +217,8 @@ properties: - memsic,mxc6255 # MEMSIC 3-axis accelerometer - memsic,mxc6655 + # Menlo on-board CPLD trivial SPI device + - menlo,m53cpld # Microchip differential I2C ADC, 1 Channel, 18 bit - microchip,mcp3421 # Microchip differential I2C ADC, 2 Channel, 18 bit -- cgit From a1793920b6647447e4757aec4434eb919840acb8 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Thu, 24 Feb 2022 19:54:15 -0800 Subject: dt-bindings: arm: qcom: Document sa8540p, sc8180x and sc8280xp Add compatibles for the sa8540p automotive, as well as sc8180x and sc8280xp compute platforms. Also add compatibles for the ADP devboard, the Lenovo Flex 5G, Microsoft Surface Pro X and the sc8280xp QRD. Signed-off-by: Bjorn Andersson Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220225035415.2294821-1-bjorn.andersson@linaro.org --- Documentation/devicetree/bindings/arm/qcom.yaml | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 129cdd246223..93e4e4256e73 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -39,8 +39,11 @@ description: | msm8994 msm8996 sa8155p + sa8540p sc7180 sc7280 + sc8180x + sc8280xp sdm630 sdm632 sdm660 @@ -225,6 +228,18 @@ properties: - google,senor - const: qcom,sc7280 + - items: + - enum: + - lenovo,flex-5g + - microsoft,surface-prox + - qcom,sc8180x-primus + - const: qcom,sc8180x + + - items: + - enum: + - qcom,sc8280xp-qrd + - const: qcom,sc8280xp + - items: - enum: - fairphone,fp3 @@ -258,6 +273,11 @@ properties: - qcom,sa8155p-adp - const: qcom,sa8155p + - items: + - enum: + - qcom,sa8295p-adp + - const: qcom,sa8540p + - items: - enum: - fairphone,fp4 -- cgit From c54eead2a66914a36b4a9ea5bbeb95a768307cba Mon Sep 17 00:00:00 2001 From: Yue Hu Date: Thu, 7 Apr 2022 18:28:32 +0800 Subject: docs: filesystems: caching/backend-api.rst: correct two relinquish APIs use 1. cache backend is using fscache_relinquish_cache() rather than fscache_relinquish_cookie() to reset the cache cookie. 2. No fscache_cache_relinquish() helper currently, it should be fscache_relinquish_cache(). Signed-off-by: Yue Hu Signed-off-by: David Howells cc: linux-cachefs@redhat.com Link: https://listman.redhat.com/archives/linux-cachefs/2022-April/006703.html # v1 Link: https://listman.redhat.com/archives/linux-cachefs/2022-April/006704.html # v2 --- Documentation/filesystems/caching/backend-api.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/caching/backend-api.rst b/Documentation/filesystems/caching/backend-api.rst index be793c49a772..d7b2df5fd607 100644 --- a/Documentation/filesystems/caching/backend-api.rst +++ b/Documentation/filesystems/caching/backend-api.rst @@ -73,7 +73,7 @@ busy. If successful, the cache backend can then start setting up the cache. In the event that the initialisation fails, the cache backend should call:: - void fscache_relinquish_cookie(struct fscache_cache *cache); + void fscache_relinquish_cache(struct fscache_cache *cache); to reset and discard the cookie. @@ -125,7 +125,7 @@ outstanding accesses on the volume to complete before returning. When the the cache is completely withdrawn, fscache should be notified by calling:: - void fscache_cache_relinquish(struct fscache_cache *cache); + void fscache_relinquish_cache(struct fscache_cache *cache); to clear fields in the cookie and discard the caller's ref on it. -- cgit From 5d3d5b9645b53691b2eee7607cf995bcfae46dd0 Mon Sep 17 00:00:00 2001 From: Yue Hu Date: Thu, 7 Apr 2022 19:02:39 +0800 Subject: docs: filesystems: caching/backend-api.rst: fix an object withdrawn API There's no fscache_are_objects_withdrawn() helper at all to test if cookie withdrawal is completed currently. The cache backend is using fscache_wait_for_objects() to wait all objects to be withdrawn. Signed-off-by: Yue Hu Signed-off-by: David Howells cc: linux-cachefs@redhat.com Link: https://listman.redhat.com/archives/linux-cachefs/2022-April/006705.html # v1 --- Documentation/filesystems/caching/backend-api.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/caching/backend-api.rst b/Documentation/filesystems/caching/backend-api.rst index d7b2df5fd607..d7507becf674 100644 --- a/Documentation/filesystems/caching/backend-api.rst +++ b/Documentation/filesystems/caching/backend-api.rst @@ -110,9 +110,9 @@ to withdraw them, calling:: on the cookie that each object belongs to. This schedules the specified cookie for withdrawal. This gets offloaded to a workqueue. The cache backend can -test for completion by calling:: +wait for completion by calling:: - bool fscache_are_objects_withdrawn(struct fscache_cookie *cache); + void fscache_wait_for_objects(struct fscache_cache *cache); Once all the cookies are withdrawn, a cache backend can withdraw all the volumes, calling:: -- cgit From 2c547f299827c12244d613eb2ee3616d88f56088 Mon Sep 17 00:00:00 2001 From: Yue Hu Date: Wed, 6 Apr 2022 11:50:17 +0800 Subject: fscache: Remove the cookie parameter from fscache_clear_page_bits() The cookie is not used at all, remove it and update the usage in io.c and afs/write.c (which is the only user outside of fscache currently) at the same time. [DH: Amended the documentation also] Signed-off-by: Yue Hu Signed-off-by: David Howells cc: linux-cachefs@redhat.com Link: https://listman.redhat.com/archives/linux-cachefs/2022-April/006659.html --- Documentation/filesystems/caching/netfs-api.rst | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/caching/netfs-api.rst b/Documentation/filesystems/caching/netfs-api.rst index 5066113acad5..7308d76a29dc 100644 --- a/Documentation/filesystems/caching/netfs-api.rst +++ b/Documentation/filesystems/caching/netfs-api.rst @@ -404,22 +404,21 @@ schedule a write of that region:: And if an error occurs before that point is reached, the marks can be removed by calling:: - void fscache_clear_page_bits(struct fscache_cookie *cookie, - struct address_space *mapping, + void fscache_clear_page_bits(struct address_space *mapping, loff_t start, size_t len, bool caching) -In both of these functions, the cookie representing the cache object to be -written to and a pointer to the mapping to which the source pages are attached -are passed in; start and len indicate the size of the region that's going to be -written (it doesn't have to align to page boundaries necessarily, but it does -have to align to DIO boundaries on the backing filesystem). The caching -parameter indicates if caching should be skipped, and if false, the functions -do nothing. - -The write function takes some additional parameters: i_size indicates the size -of the netfs file and term_func indicates an optional completion function, to -which term_func_priv will be passed, along with the error or amount written. +In these functions, a pointer to the mapping to which the source pages are +attached is passed in and start and len indicate the size of the region that's +going to be written (it doesn't have to align to page boundaries necessarily, +but it does have to align to DIO boundaries on the backing filesystem). The +caching parameter indicates if caching should be skipped, and if false, the +functions do nothing. + +The write function takes some additional parameters: the cookie representing +the cache object to be written to, i_size indicates the size of the netfs file +and term_func indicates an optional completion function, to which +term_func_priv will be passed, along with the error or amount written. Note that the write function will always run asynchronously and will unmark all the pages upon completion before calling term_func. -- cgit From 6648d167fbd16eaa4ef4972b4904adde2717f722 Mon Sep 17 00:00:00 2001 From: Michael Riesch Date: Thu, 10 Mar 2022 22:03:50 +0100 Subject: dt-bindings: arm: rockchip: add radxa rock3 model a Add entry for the Radxa ROCK3 Model A board (with the Rockchip RK3568 SoC). Signed-off-by: Michael Riesch Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220310210352.451136-2-michael.riesch@wolfvision.net Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index eece92f83a2d..efb0a9c4347b 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -545,6 +545,11 @@ properties: - const: radxa,rock2-square - const: rockchip,rk3288 + - description: Radxa ROCK3 Model A + items: + - const: radxa,rock3a + - const: rockchip,rk3568 + - description: Rikomagic MK808 v1 items: - const: rikomagic,mk808 -- cgit From 8a1b63b14fe7df811439235606c146faa15faa52 Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Thu, 24 Mar 2022 13:01:22 +0100 Subject: dt-bindings: soc: rockchip: add naneng combo phy register compatible Add Naneng combo phy register compatible. Signed-off-by: Johan Jonker Signed-off-by: Yifeng Zhao Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220324120122.1339-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index b2ba7bed89b2..5079e9d24af6 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -15,6 +15,8 @@ properties: - items: - enum: - rockchip,rk3288-sgrf + - rockchip,rk3568-pipe-grf + - rockchip,rk3568-pipe-phy-grf - rockchip,rk3568-usb2phy-grf - rockchip,rv1108-usbgrf - const: syscon -- cgit From 2a872dd86eeb349f169df0a204668afa578a94b2 Mon Sep 17 00:00:00 2001 From: Peter Geis Date: Fri, 8 Apr 2022 11:12:33 -0400 Subject: dt-bindings: soc: rockchip: add rk3566-pipe-grf compatible The rk3566 requires special handling for the dwc3-otg clock in order for the port to function correctly. Add a binding for the rk3566-pipe-grf so we can handle setup with the grf driver. Signed-off-by: Peter Geis Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220408151237.3165046-2-pgwipeout@gmail.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index 5079e9d24af6..75a2b8bb25fb 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -15,6 +15,7 @@ properties: - items: - enum: - rockchip,rk3288-sgrf + - rockchip,rk3566-pipe-grf - rockchip,rk3568-pipe-grf - rockchip,rk3568-pipe-phy-grf - rockchip,rk3568-usb2phy-grf -- cgit From 04d3e427148f8ed7322f70e324731c81460671df Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Tue, 29 Mar 2022 17:07:37 +0200 Subject: dt-bindings: clock: fix some conversion style issues for rockchip,rk3399-cru.yaml With the conversion of rockchip,rk3399-cru.txt a table with external clocks was copied. Make it a bit cleaner by aligning the columns. Also fix a description. Phrases start with a capital. Signed-off-by: Johan Jonker Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220329150742.22093-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner --- .../devicetree/bindings/clock/rockchip,rk3399-cru.yaml | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml index 72b286a1beba..76dd24d49a37 100644 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml @@ -22,11 +22,11 @@ description: | There are several clocks that are generated outside the SoC. It is expected that they are defined using standard clock bindings with following clock-output-names: - - "xin24m" - crystal input - required, - - "xin32k" - rtc clock - optional, - - "clkin_gmac" - external GMAC clock - optional, - - "clkin_i2s" - external I2S clock - optional, - - "pclkin_cif" - external ISP clock - optional, + - "xin24m" - crystal input - required, + - "xin32k" - rtc clock - optional, + - "clkin_gmac" - external GMAC clock - optional, + - "clkin_i2s" - external I2S clock - optional, + - "pclkin_cif" - external ISP clock - optional, - "clk_usbphy0_480m" - output clock of the pll in the usbphy0 - "clk_usbphy1_480m" - output clock of the pll in the usbphy1 @@ -62,8 +62,8 @@ properties: rockchip,grf: $ref: /schemas/types.yaml#/definitions/phandle - description: > - phandle to the syscon managing the "general register files". It is used + description: + Phandle to the syscon managing the "general register files". It is used for GRF muxes, if missing any muxes present in the GRF will not be available. -- cgit From 50cfde33494072c74bf39a0c281cfa0c3289bd57 Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Tue, 29 Mar 2022 17:07:38 +0200 Subject: dt-bindings: clock: replace a maintainer for rockchip,rk3399-cru.yaml With the rk3399 cru YAML conversion the original text author was somehow added as a maintainer, but who's currently no longer involved on the subject. Replace this position with the Rockchip clock maintainer on her request. Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20220329150742.22093-2-jbx6244@gmail.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml index 76dd24d49a37..3cc8398fd3b9 100644 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Rockchip RK3399 Clock and Reset Unit maintainers: - - Xing Zheng + - Elaine Zhang - Heiko Stuebner description: | -- cgit From 91154f0cd889ed3772a0ac0e24ee363f93fe784c Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Tue, 29 Mar 2022 17:07:39 +0200 Subject: dt-bindings: clock: use generic node name for pmucru example in rockchip,rk3399-cru.yaml The node names should be generic, so fix this for the pmucru node example in the rockchip,rk3399-cru.yaml file and rename it to "clock-controller". Signed-off-by: Johan Jonker Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220329150742.22093-3-jbx6244@gmail.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml index 3cc8398fd3b9..18a0093115a1 100644 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml @@ -77,7 +77,7 @@ additionalProperties: false examples: - | - pmucru: pmu-clock-controller@ff750000 { + pmucru: clock-controller@ff750000 { compatible = "rockchip,rk3399-pmucru"; reg = <0xff750000 0x1000>; #clock-cells = <1>; -- cgit From 7adc1b98bb6e6611bc9122de77737b193b693122 Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Tue, 29 Mar 2022 17:07:40 +0200 Subject: dt-bindings: clock: fix rk3399 cru clock issues The current rk3399 cru DT node gives warnings like: 'clocks' is a dependency of 'assigned-clocks'. With the YAML conversion somehow "assigned-xxx" properties where added. If a proper clock is added to the cru node these properties are no longer needed, so removed them. Currently only one clock will be added, so limit the clock maxItems to 1. Add a clock name to be able to differentiate and filter bogus entries. Signed-off-by: Johan Jonker Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220329150742.22093-4-jbx6244@gmail.com Signed-off-by: Heiko Stuebner --- .../devicetree/bindings/clock/rockchip,rk3399-cru.yaml | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml index 18a0093115a1..54da1e31ea73 100644 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml @@ -46,19 +46,10 @@ properties: const: 1 clocks: - minItems: 1 - - assigned-clocks: - minItems: 1 - maxItems: 64 - - assigned-clock-parents: - minItems: 1 - maxItems: 64 + maxItems: 1 - assigned-clock-rates: - minItems: 1 - maxItems: 64 + clock-names: + const: xin24m rockchip,grf: $ref: /schemas/types.yaml#/definitions/phandle -- cgit From 4f1a22ee7b576a38dc5705837c9b0de0c7b5b064 Mon Sep 17 00:00:00 2001 From: John Garry Date: Fri, 8 Apr 2022 17:04:12 +0800 Subject: libata: Improve ATA queued command allocation Improve ATA queued command allocation as follows: - For attaining a qc tag for a SAS host we need to allocate a bit in ata_port.sas_tag_allocated bitmap. However we already have a unique tag per device in range [0, ATA_MAX_QUEUE -1] in the scsi cmnd budget token, so just use that instead. - It is a bit pointless to have ata_qc_new_init() in libata-core.c since it pokes scsi internals, so inline it in ata_scsi_qc_new() (in libata-scsi.c). Also update Doc accordingly. - Use standard SCSI helpers set_host_byte() and set_status_byte() in ata_scsi_qc_new(). Christoph Hellwig originally contributed the change to inline ata_qc_new_init(). Signed-off-by: John Garry Reviewed-by: Christoph Hellwig Signed-off-by: Damien Le Moal --- Documentation/driver-api/libata.rst | 11 ----------- 1 file changed, 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/libata.rst b/Documentation/driver-api/libata.rst index d477e296bda5..311af516a3fd 100644 --- a/Documentation/driver-api/libata.rst +++ b/Documentation/driver-api/libata.rst @@ -424,12 +424,6 @@ How commands are issued ----------------------- Internal commands - First, qc is allocated and initialized using :c:func:`ata_qc_new_init`. - Although :c:func:`ata_qc_new_init` doesn't implement any wait or retry - mechanism when qc is not available, internal commands are currently - issued only during initialization and error recovery, so no other - command is active and allocation is guaranteed to succeed. - Once allocated qc's taskfile is initialized for the command to be executed. qc currently has two mechanisms to notify completion. One is via ``qc->complete_fn()`` callback and the other is completion @@ -447,11 +441,6 @@ SCSI commands translated. No qc is involved in processing a simulated scmd. The result is computed right away and the scmd is completed. - For a translated scmd, :c:func:`ata_qc_new_init` is invoked to allocate a - qc and the scmd is translated into the qc. SCSI midlayer's - completion notification function pointer is stored into - ``qc->scsidone``. - ``qc->complete_fn()`` callback is used for completion notification. ATA commands use :c:func:`ata_scsi_qc_complete` while ATAPI commands use :c:func:`atapi_qc_complete`. Both functions end up calling ``qc->scsidone`` -- cgit From 6863c612024f92dfba656cc4f74b19d348cfce8f Mon Sep 17 00:00:00 2001 From: Roger Quadros Date: Sat, 26 Mar 2022 10:07:24 +0200 Subject: dt-bindings: mtd: ti,elm: Convert to yaml Convert elm.txt to ti,elm.yaml. hwmod framework use is deprecated for new platforms so mark it so. Signed-off-by: Roger Quadros Reviewed-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220326080726.30372-2-rogerq@kernel.org --- Documentation/devicetree/bindings/mtd/elm.txt | 16 -------- Documentation/devicetree/bindings/mtd/ti,elm.yaml | 48 +++++++++++++++++++++++ 2 files changed, 48 insertions(+), 16 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mtd/elm.txt create mode 100644 Documentation/devicetree/bindings/mtd/ti,elm.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/elm.txt b/Documentation/devicetree/bindings/mtd/elm.txt deleted file mode 100644 index 59ddc61c1076..000000000000 --- a/Documentation/devicetree/bindings/mtd/elm.txt +++ /dev/null @@ -1,16 +0,0 @@ -Error location module - -Required properties: -- compatible: Must be "ti,am3352-elm" -- reg: physical base address and size of the registers map. -- interrupts: Interrupt number for the elm. - -Optional properties: -- ti,hwmods: Name of the hwmod associated to the elm - -Example: -elm: elm@0 { - compatible = "ti,am3352-elm"; - reg = <0x48080000 0x2000>; - interrupts = <4>; -}; diff --git a/Documentation/devicetree/bindings/mtd/ti,elm.yaml b/Documentation/devicetree/bindings/mtd/ti,elm.yaml new file mode 100644 index 000000000000..1821395bbfb6 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/ti,elm.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/ti,elm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments Error Location Module (ELM). + +maintainers: + - Roger Quadros + +description: + ELM module is used together with GPMC and NAND Flash to detect + errors and the location of the error based on BCH algorithms + so they can be corrected if possible. + +properties: + compatible: + enum: + - ti,am3352-elm + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + ti,hwmods: + description: + Name of the HWMOD associated with ELM. This is for legacy + platforms only. + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + elm: ecc@0 { + compatible = "ti,am3352-elm"; + reg = <0x0 0x2000>; + interrupts = <4>; + }; -- cgit From 05691c0287886806616a1bb0ecbce6ec5e8f43cc Mon Sep 17 00:00:00 2001 From: Roger Quadros Date: Sat, 26 Mar 2022 10:07:25 +0200 Subject: dt-bindings: mtd: ti,elm: Add support for AM64 ELM TI's AM64 SoC has the Error Locator Module. Add compatible and related properties to support ELM on AM64 SoC. Signed-off-by: Roger Quadros Reviewed-by: Krzysztof Kozlowski Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220326080726.30372-3-rogerq@kernel.org --- Documentation/devicetree/bindings/mtd/ti,elm.yaml | 24 +++++++++++++++++++++++ 1 file changed, 24 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/ti,elm.yaml b/Documentation/devicetree/bindings/mtd/ti,elm.yaml index 1821395bbfb6..87128c004596 100644 --- a/Documentation/devicetree/bindings/mtd/ti,elm.yaml +++ b/Documentation/devicetree/bindings/mtd/ti,elm.yaml @@ -18,6 +18,7 @@ properties: compatible: enum: - ti,am3352-elm + - ti,am64-elm reg: maxItems: 1 @@ -25,6 +26,17 @@ properties: interrupts: maxItems: 1 + clocks: + maxItems: 1 + description: Functional clock. + + clock-names: + items: + - const: fck + + power-domains: + maxItems: 1 + ti,hwmods: description: Name of the HWMOD associated with ELM. This is for legacy @@ -37,6 +49,18 @@ required: - reg - interrupts +allOf: + - if: + properties: + compatible: + contains: + const: ti,am64-elm + then: + required: + - clocks + - clock-names + - power-domains + additionalProperties: false examples: -- cgit From 06a6a774f6b8ed94aefcf60caa56fe92d3a18e17 Mon Sep 17 00:00:00 2001 From: Sander Vanheule Date: Sat, 9 Apr 2022 21:55:46 +0200 Subject: dt-bindings: gpio: realtek-otto: Add rtl9300 compatible Add the "realtek,rlt9300-gpio", "realtek,otto-gpio" compatible for GPIO nodes on the RTL930x SoC series. This SoC requires an extra register range, defining the interrupt CPU mapping registers. Signed-off-by: Sander Vanheule Reviewed-by: Krzysztof Kozlowski Signed-off-by: Bartosz Golaszewski --- .../bindings/gpio/realtek,otto-gpio.yaml | 33 ++++++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml b/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml index 100f20cebd76..3c511e9af377 100644 --- a/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml @@ -28,10 +28,10 @@ properties: - enum: - realtek,rtl8380-gpio - realtek,rtl8390-gpio + - realtek,rtl9300-gpio - const: realtek,otto-gpio - reg: - maxItems: 1 + reg: true "#gpio-cells": const: 2 @@ -50,6 +50,23 @@ properties: interrupts: maxItems: 1 +if: + properties: + compatible: + contains: + const: realtek,rtl9300-gpio +then: + properties: + reg: + items: + - description: GPIO and interrupt control + - description: interrupt CPU map +else: + properties: + reg: + items: + - description: GPIO and interrupt control + required: - compatible - reg @@ -74,5 +91,17 @@ examples: interrupt-parent = <&rtlintc>; interrupts = <23>; }; + - | + gpio@3300 { + compatible = "realtek,rtl9300-gpio", "realtek,otto-gpio"; + reg = <0x3300 0x1c>, <0x3338 0x8>; + gpio-controller; + #gpio-cells = <2>; + ngpios = <24>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&rtlintc>; + interrupts = <13>; + }; ... -- cgit From d0b55b6912f3c249097977eba8f3ed580d5f1c6b Mon Sep 17 00:00:00 2001 From: Sander Vanheule Date: Sat, 9 Apr 2022 21:55:50 +0200 Subject: dt-bindings: gpio: realtek-otto: Add rtl9310 compatible Add the "realtek,rlt9310-gpio", "realtek,otto-gpio" compatible for GPIO nodes on the RTL931x SoC series. Signed-off-by: Sander Vanheule Acked-by: Krzysztof Kozlowski Signed-off-by: Bartosz Golaszewski --- Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml b/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml index 3c511e9af377..39fd959c45d2 100644 --- a/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml @@ -29,6 +29,7 @@ properties: - realtek,rtl8380-gpio - realtek,rtl8390-gpio - realtek,rtl9300-gpio + - realtek,rtl9310-gpio - const: realtek,otto-gpio reg: true -- cgit From 26ad4834da921ffcadad3ba177dbb137d36c9248 Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Thu, 3 Feb 2022 13:23:35 +0200 Subject: dt-bindings: omap: Add clock-output-names and #clock-cells This allows us to use clock-output-names for the clock manager instance name instead of relying on non-standard node names. Cc: Stephen Boyd Cc: Tero Kristo Signed-off-by: Tony Lindgren Acked-by: Rob Herring Message-Id: <20220203112337.19821-1-tony@atomide.com> --- Documentation/devicetree/bindings/arm/omap/prcm.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/omap/prcm.txt b/Documentation/devicetree/bindings/arm/omap/prcm.txt index 3eb6d7afff14..431ef8c56a13 100644 --- a/Documentation/devicetree/bindings/arm/omap/prcm.txt +++ b/Documentation/devicetree/bindings/arm/omap/prcm.txt @@ -31,12 +31,17 @@ Required properties: (base address and length) - clocks: clocks for this module - clockdomains: clockdomains for this module +- #clock-cells: From common clock binding +- clock-output-names: From common clock binding + Example: -cm: cm@48004000 { +cm: clock@48004000 { compatible = "ti,omap3-cm"; reg = <0x48004000 0x4000>; + #clock-cells = <0>; + clock-output-names = "cm"; cm_clocks: clocks { #address-cells = <1>; -- cgit From 8ab423081a263cc84f4377d518d98330d4f78072 Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Thu, 3 Feb 2022 13:23:36 +0200 Subject: dt-bindings: clock: ti: Add clock-output-names for clockctrl This allows us to use clock-output-names for the clockctrl instance name instead of relying on a custom compatible or non-standard node names. Cc: Stephen Boyd Cc: Tero Kristo Signed-off-by: Tony Lindgren Acked-by: Rob Herring Message-Id: <20220203112337.19821-2-tony@atomide.com> --- Documentation/devicetree/bindings/clock/ti-clkctrl.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti-clkctrl.txt b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt index 18af6b9409e3..d20db7974a38 100644 --- a/Documentation/devicetree/bindings/clock/ti-clkctrl.txt +++ b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt @@ -21,6 +21,7 @@ Required properties : "ti,clkctrl-l4-per" "ti,clkctrl-l4-secure" "ti,clkctrl-l4-wkup" +- clock-output-names : from common clock binding - #clock-cells : shall contain 2 with the first entry being the instance offset from the clock domain base and the second being the clock index @@ -32,7 +33,8 @@ Example: Clock controller node on omap 4430: l4per: cm@1400 { cm_l4per@0 { cm_l4per_clkctrl: clock@20 { - compatible = "ti,clkctrl-l4-per", "ti,clkctrl"; + compatible = "ti,clkctrl"; + clock-output-names = "l4_per"; reg = <0x20 0x1b0>; #clock-cells = <2>; }; -- cgit From fc3d39d5758dc001662df5aac825b2b6bcb6476f Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Thu, 3 Feb 2022 13:23:37 +0200 Subject: dt-bindings: clock: ti: Add clock-output-names for TI composite clocks For the TI composite clocks, we currently have only the divider clock list clock-output-names as an optional devicetree property. Let's add clock-output-names for all the TI composite clock bindings. This allows us to use clock-output-names for the clockctrl instance name instead of relying on a custom compatible or non-standard node names. Cc: Stephen Boyd Cc: Tero Kristo Signed-off-by: Tony Lindgren Acked-by: Rob Herring Message-Id: <20220203112337.19821-3-tony@atomide.com> --- Documentation/devicetree/bindings/clock/ti/clockdomain.txt | 3 +++ Documentation/devicetree/bindings/clock/ti/composite.txt | 3 +++ Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt | 1 + Documentation/devicetree/bindings/clock/ti/gate.txt | 1 + Documentation/devicetree/bindings/clock/ti/interface.txt | 1 + Documentation/devicetree/bindings/clock/ti/mux.txt | 1 + 6 files changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt index cb76b3f2b341..9c6199249ce5 100644 --- a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt +++ b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt @@ -17,6 +17,9 @@ Required properties: - #clock-cells : from common clock binding; shall be set to 0. - clocks : link phandles of clocks within this domain +Optional properties: +- clock-output-names : from common clock binding. + Examples: dss_clkdm: dss_clkdm { compatible = "ti,clockdomain"; diff --git a/Documentation/devicetree/bindings/clock/ti/composite.txt b/Documentation/devicetree/bindings/clock/ti/composite.txt index 5f43c4706b09..33ac7c9ad053 100644 --- a/Documentation/devicetree/bindings/clock/ti/composite.txt +++ b/Documentation/devicetree/bindings/clock/ti/composite.txt @@ -27,6 +27,9 @@ Required properties: - clocks : link phandles of component clocks - #clock-cells : from common clock binding; shall be set to 0. +Optional properties: +- clock-output-names : from common clock binding. + Examples: usb_l4_gate_ick: usb_l4_gate_ick { diff --git a/Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt b/Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt index 662b36d53bf0..518e3c142276 100644 --- a/Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt +++ b/Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt @@ -16,6 +16,7 @@ Required properties: - clocks: parent clock. Optional properties: +- clock-output-names : from common clock binding. - ti,autoidle-shift: bit shift of the autoidle enable bit for the clock, see [2] - reg: offset for the autoidle register of this clock, see [2] diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt b/Documentation/devicetree/bindings/clock/ti/gate.txt index 56d603c1f716..b4820b1de4f0 100644 --- a/Documentation/devicetree/bindings/clock/ti/gate.txt +++ b/Documentation/devicetree/bindings/clock/ti/gate.txt @@ -36,6 +36,7 @@ Required properties: ti,clkdm-gate-clock type Optional properties: +- clock-output-names : from common clock binding. - ti,bit-shift : bit shift for programming the clock gate, invalid for ti,clkdm-gate-clock type - ti,set-bit-to-disable : inverts default gate programming. Setting the bit diff --git a/Documentation/devicetree/bindings/clock/ti/interface.txt b/Documentation/devicetree/bindings/clock/ti/interface.txt index 3f4704040140..94ec77dc3c59 100644 --- a/Documentation/devicetree/bindings/clock/ti/interface.txt +++ b/Documentation/devicetree/bindings/clock/ti/interface.txt @@ -28,6 +28,7 @@ Required properties: - reg : base address for the control register Optional properties: +- clock-output-names : from common clock binding. - ti,bit-shift : bit shift for the bit enabling/disabling the clock (default 0) Examples: diff --git a/Documentation/devicetree/bindings/clock/ti/mux.txt b/Documentation/devicetree/bindings/clock/ti/mux.txt index eec8994b9be8..e17425a58621 100644 --- a/Documentation/devicetree/bindings/clock/ti/mux.txt +++ b/Documentation/devicetree/bindings/clock/ti/mux.txt @@ -42,6 +42,7 @@ Required properties: - reg : register offset for register controlling adjustable mux Optional properties: +- clock-output-names : from common clock binding. - ti,bit-shift : number of bits to shift the bit-mask, defaults to 0 if not present - ti,index-starts-at-one : valid input select programming starts at 1, not -- cgit From 1f854536a8336c61c89ab040bbc874c75325d37c Mon Sep 17 00:00:00 2001 From: Paul Kocialkowski Date: Thu, 31 Mar 2022 15:41:14 +0200 Subject: dmaengine: Clarify cyclic transfer residue documentation The current documentation for the residue reported in a cyclic transfer case mentions that the reported residue should be relative to the current period only. However the definition of DMA_RESIDUE_GRANULARITY_SEGMENT specifies that the residue should be updated after each period for a cyclic transfer, which is in direct contradiction. Moreover the pcm_dmaengine common code uses the residue relative to the whole cyclic buffer size, not one period. Correct the residue-related documentation to reflect this. Signed-off-by: Paul Kocialkowski Link: https://lore.kernel.org/r/20220331134114.703782-1-paul.kocialkowski@bootlin.com Signed-off-by: Vinod Koul --- Documentation/driver-api/dmaengine/provider.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst index 0072c9c7efd3..d3fa80e333b1 100644 --- a/Documentation/driver-api/dmaengine/provider.rst +++ b/Documentation/driver-api/dmaengine/provider.rst @@ -457,7 +457,7 @@ supported. - Should use dma_set_residue to report it - In the case of a cyclic transfer, it should only take into - account the current period. + account the total size of the cyclic buffer. - Should return DMA_OUT_OF_ORDER if the device does not support in order completion and is completing the operation out of order. -- cgit From cc4abaa67e051ddc1bb4e00186870adbd780d1cd Mon Sep 17 00:00:00 2001 From: Olivier Dautricourt Date: Thu, 17 Mar 2022 18:56:56 +0100 Subject: dt-bindings: altr,msgdma: update my email address This email should now be used to contact me. Signed-off-by: Olivier Dautricourt Acked-by: Rob Herring Link: https://lore.kernel.org/r/dc3decf1dae172c688017bd3ada2ad2b7d060c1e.1647539776.git.olivier.dautricourt@orolia.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/altr,msgdma.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/altr,msgdma.yaml b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml index b193ee2db4a7..b53ac7631a76 100644 --- a/Documentation/devicetree/bindings/dma/altr,msgdma.yaml +++ b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Altera mSGDMA IP core maintainers: - - Olivier Dautricourt + - Olivier Dautricourt description: | Altera / Intel modular Scatter-Gather Direct Memory Access (mSGDMA) -- cgit From 729106266a50400181c3baa508c79bead46eb8e0 Mon Sep 17 00:00:00 2001 From: Akhil R Date: Fri, 25 Feb 2022 18:50:43 +0530 Subject: dt-bindings: dmaengine: Add doc for tegra gpcdma Add DT binding document for Nvidia Tegra GPCDMA controller. Signed-off-by: Rajesh Gumasta Signed-off-by: Akhil R Reviewed-by: Jon Hunter Reviewed-by: Rob Herring Acked-by: Thierry Reding Link: https://lore.kernel.org/r/20220225132044.14478-2-akhilrajeev@nvidia.com Signed-off-by: Vinod Koul --- .../bindings/dma/nvidia,tegra186-gpc-dma.yaml | 110 +++++++++++++++++++++ 1 file changed, 110 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml new file mode 100644 index 000000000000..9dd1476d1849 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml @@ -0,0 +1,110 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/nvidia,tegra186-gpc-dma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra GPC DMA Controller Device Tree Bindings + +description: | + The Tegra General Purpose Central (GPC) DMA controller is used for faster + data transfers between memory to memory, memory to device and device to + memory. + +maintainers: + - Jon Hunter + - Rajesh Gumasta + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + oneOf: + - const: nvidia,tegra186-gpcdma + - items: + - const: nvidia,tegra194-gpcdma + - const: nvidia,tegra186-gpcdma + + "#dma-cells": + const: 1 + + reg: + maxItems: 1 + + interrupts: + description: + Should contain all of the per-channel DMA interrupts in + ascending order with respect to the DMA channel index. + minItems: 1 + maxItems: 31 + + resets: + maxItems: 1 + + reset-names: + const: gpcdma + + iommus: + maxItems: 1 + + dma-coherent: true + +required: + - compatible + - reg + - interrupts + - resets + - reset-names + - "#dma-cells" + - iommus + +additionalProperties: false + +examples: + - | + #include + #include + #include + + dma-controller@2600000 { + compatible = "nvidia,tegra186-gpcdma"; + reg = <0x2600000 0x210000>; + resets = <&bpmp TEGRA186_RESET_GPCDMA>; + reset-names = "gpcdma"; + interrupts = , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + ; + #dma-cells = <1>; + iommus = <&smmu TEGRA186_SID_GPCDMA_0>; + dma-coherent; + }; +... -- cgit From af105c9cc9ec8fdc087827a98d4b9dc10d61c358 Mon Sep 17 00:00:00 2001 From: Like Xu Date: Wed, 6 Apr 2022 14:37:15 +0800 Subject: Documentation: KVM: Add SPDX-License-Identifier tag +new file mode 100644 +WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 +#27: FILE: Documentation/virt/kvm/x86/errata.rst:1: Opportunistically update all other non-added KVM documents and remove a new extra blank line at EOF for x86/errata.rst. Signed-off-by: Like Xu Message-Id: <20220406063715.55625-5-likexu@tencent.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/vcpu-requests.rst | 2 ++ Documentation/virt/kvm/x86/amd-memory-encryption.rst | 2 ++ Documentation/virt/kvm/x86/errata.rst | 2 +- Documentation/virt/kvm/x86/running-nested-guests.rst | 2 ++ 4 files changed, 7 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/vcpu-requests.rst b/Documentation/virt/kvm/vcpu-requests.rst index db43ee571f5a..31f62b64e07b 100644 --- a/Documentation/virt/kvm/vcpu-requests.rst +++ b/Documentation/virt/kvm/vcpu-requests.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0 + ================= KVM VCPU Requests ================= diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst index 1c6847fff304..2d307811978c 100644 --- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst +++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0 + ====================================== Secure Encrypted Virtualization (SEV) ====================================== diff --git a/Documentation/virt/kvm/x86/errata.rst b/Documentation/virt/kvm/x86/errata.rst index 806f049b6975..410e0aa63493 100644 --- a/Documentation/virt/kvm/x86/errata.rst +++ b/Documentation/virt/kvm/x86/errata.rst @@ -1,3 +1,4 @@ +.. SPDX-License-Identifier: GPL-2.0 ======================================= Known limitations of CPU virtualization @@ -36,4 +37,3 @@ Nested virtualization features ------------------------------ TBD - diff --git a/Documentation/virt/kvm/x86/running-nested-guests.rst b/Documentation/virt/kvm/x86/running-nested-guests.rst index bd70c69468ae..a27e6768d900 100644 --- a/Documentation/virt/kvm/x86/running-nested-guests.rst +++ b/Documentation/virt/kvm/x86/running-nested-guests.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0 + ============================== Running nested guests with KVM ============================== -- cgit From 082ffee0505810bba7c4add343fa178861e26212 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Mon, 21 Mar 2022 14:33:14 +0100 Subject: dt-bindings: phy: qcom,qmp: Add SM6350 UFS PHY bindings Document the compatible string for the UFS PHY found in SM6350. Signed-off-by: Luca Weiss Acked-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220321133318.99406-3-luca.weiss@fairphone.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index e20d9b087bb8..5d7417c34c87 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -39,6 +39,7 @@ properties: - qcom,sdm845-qmp-usb3-phy - qcom,sdm845-qmp-usb3-uni-phy - qcom,sm6115-qmp-ufs-phy + - qcom,sm6350-qmp-ufs-phy - qcom,sm8150-qmp-ufs-phy - qcom,sm8150-qmp-usb3-phy - qcom,sm8150-qmp-usb3-uni-phy @@ -279,6 +280,7 @@ allOf: enum: - qcom,msm8998-qmp-ufs-phy - qcom,sdm845-qmp-ufs-phy + - qcom,sm6350-qmp-ufs-phy - qcom,sm8150-qmp-ufs-phy - qcom,sm8250-qmp-ufs-phy - qcom,sc8180x-qmp-ufs-phy -- cgit From 95862bd9781edc5b3272e03320609efb3aef2807 Mon Sep 17 00:00:00 2001 From: Rex-BC Chen Date: Wed, 6 Apr 2022 11:00:07 +0800 Subject: dt-bindings: display: mediatek: change to use enum for mutex All single entry cases in mutex can be merged as a single enum. Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220406030009.2357-3-rex-bc.chen@mediatek.com/ Signed-off-by: Rex-BC Chen Reviewed-by: Rob Herring Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Chun-Kuang Hu --- .../bindings/display/mediatek/mediatek,mutex.yaml | 24 ++++++++-------------- 1 file changed, 9 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml index 00e6a1041a9b..b470fbb1b40a 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml @@ -23,21 +23,15 @@ description: | properties: compatible: - oneOf: - - items: - - const: mediatek,mt2701-disp-mutex - - items: - - const: mediatek,mt2712-disp-mutex - - items: - - const: mediatek,mt8167-disp-mutex - - items: - - const: mediatek,mt8173-disp-mutex - - items: - - const: mediatek,mt8183-disp-mutex - - items: - - const: mediatek,mt8192-disp-mutex - - items: - - const: mediatek,mt8195-disp-mutex + enum: + - mediatek,mt2701-disp-mutex + - mediatek,mt2712-disp-mutex + - mediatek,mt8167-disp-mutex + - mediatek,mt8173-disp-mutex + - mediatek,mt8183-disp-mutex + - mediatek,mt8192-disp-mutex + - mediatek,mt8195-disp-mutex + reg: maxItems: 1 -- cgit From 8a26ea19d4dc7905305c3ccc2dd2fc69ef90c002 Mon Sep 17 00:00:00 2001 From: Rex-BC Chen Date: Wed, 6 Apr 2022 11:00:08 +0800 Subject: dt-bindings: display: mediatek: add MT8186 SoC binding Add MT8186 SoC binding to AAL, CCORR, COLOR, DITHER, GAMMA, MUTEX, OVL, POSTMASK and RDMA. Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220406030009.2357-4-rex-bc.chen@mediatek.com/ Signed-off-by: Rex-BC Chen Reviewed-by: Rob Herring Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Chun-Kuang Hu --- Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml | 4 ++++ .../devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 4 ++++ .../devicetree/bindings/display/mediatek/mediatek,color.yaml | 1 + .../devicetree/bindings/display/mediatek/mediatek,dither.yaml | 1 + .../devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 1 + .../devicetree/bindings/display/mediatek/mediatek,mutex.yaml | 1 + .../devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml | 4 ++++ Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 4 ++++ .../devicetree/bindings/display/mediatek/mediatek,postmask.yaml | 4 ++++ Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml | 1 + 10 files changed, 25 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index cdb6d0819cca..cb4a2f39ff88 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -30,6 +30,10 @@ properties: - mediatek,mt8192-disp-aal - mediatek,mt8195-disp-aal - const: mediatek,mt8173-disp-aal + - items: + - enum: + - mediatek,mt8186-disp-aal + - const: mediatek,mt8183-disp-aal reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml index 7766c806c102..63fb02014a56 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -29,6 +29,10 @@ properties: - enum: - mediatek,mt8195-disp-ccorr - const: mediatek,mt8192-disp-ccorr + - items: + - enum: + - mediatek,mt8186-disp-ccorr + - const: mediatek,mt8183-disp-ccorr reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index 0c9095b0411e..d2f89ee7996f 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -36,6 +36,7 @@ properties: - items: - enum: - mediatek,mt8183-disp-color + - mediatek,mt8186-disp-color - mediatek,mt8192-disp-color - mediatek,mt8195-disp-color - const: mediatek,mt8173-disp-color diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml index 8180ed0a89ff..8ad8187c02d1 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml @@ -26,6 +26,7 @@ properties: - const: mediatek,mt8183-disp-dither - items: - enum: + - mediatek,mt8186-disp-dither - mediatek,mt8192-disp-dither - mediatek,mt8195-disp-dither - const: mediatek,mt8183-disp-dither diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml index 5f1825b4512b..a89ea0ea7542 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -27,6 +27,7 @@ properties: - const: mediatek,mt8183-disp-gamma - items: - enum: + - mediatek,mt8186-disp-gamma - mediatek,mt8192-disp-gamma - mediatek,mt8195-disp-gamma - const: mediatek,mt8183-disp-gamma diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml index b470fbb1b40a..3fdad71210b4 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml @@ -29,6 +29,7 @@ properties: - mediatek,mt8167-disp-mutex - mediatek,mt8173-disp-mutex - mediatek,mt8183-disp-mutex + - mediatek,mt8186-disp-mutex - mediatek,mt8192-disp-mutex - mediatek,mt8195-disp-mutex diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml index da999ba53b7c..4e94f4e947ad 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml @@ -25,6 +25,10 @@ properties: - const: mediatek,mt8183-disp-ovl-2l - items: - const: mediatek,mt8192-disp-ovl-2l + - items: + - enum: + - mediatek,mt8186-disp-ovl-2l + - const: mediatek,mt8192-disp-ovl-2l reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml index 51f8235f1b1b..a2a27d0ca038 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -38,6 +38,10 @@ properties: - enum: - mediatek,mt8195-disp-ovl - const: mediatek,mt8183-disp-ovl + - items: + - enum: + - mediatek,mt8186-disp-ovl + - const: mediatek,mt8192-disp-ovl reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml index 2d769422e29f..654080bfbdfb 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml @@ -23,6 +23,10 @@ properties: oneOf: - items: - const: mediatek,mt8192-disp-postmask + - items: + - enum: + - mediatek,mt8186-disp-postmask + - const: mediatek,mt8192-disp-postmask reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml index 9a6756f185ee..0882ae86e6c4 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml @@ -38,6 +38,7 @@ properties: - const: mediatek,mt2701-disp-rdma - items: - enum: + - mediatek,mt8186-disp-rdma - mediatek,mt8192-disp-rdma - const: mediatek,mt8183-disp-rdma -- cgit From 52136021f69aef59190078c0ca304680b32f2533 Mon Sep 17 00:00:00 2001 From: Xinlei Lee Date: Mon, 11 Apr 2022 10:53:03 +0800 Subject: dt-bindings: display: mediatek: dpi: Add compatible for MediaTek MT8186 Add dt-binding documentation of dpi for MediaTek MT8186 SoC. Link: https://patchwork.kernel.org/project/linux-mediatek/patch/1649645584-13186-2-git-send-email-xinlei.lee@mediatek.com/ Signed-off-by: Xinlei Lee Reviewed-by: Rex-BC Chen Signed-off-by: Chun-Kuang Hu --- Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml index 843f89d6053f..77ee1b923991 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml @@ -22,6 +22,7 @@ properties: - mediatek,mt7623-dpi - mediatek,mt8173-dpi - mediatek,mt8183-dpi + - mediatek,mt8186-dpi - mediatek,mt8192-dpi reg: -- cgit From c69a00a12e26cf4faffdcdb340cb2d059b61d57e Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Tue, 25 Jan 2022 15:41:10 -0800 Subject: srcu: Add boot-time control over srcu_node array allocation This commit adds an srcu_tree.convert_to_big kernel parameter that either refuses to convert at all (0), converts immediately at init_srcu_struct() time (1), or lets rcutorture convert it (2). An addition contention-based dynamic conversion choice will be added, along with documentation. [ paulmck: Apply callback-scanning feedback from Neeraj Upadhyay. ] Co-developed-by: Neeraj Upadhyay Signed-off-by: Neeraj Upadhyay Signed-off-by: Paul E. McKenney --- Documentation/admin-guide/kernel-parameters.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 3f1cc5e317ed..1f1fcac7777d 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5608,6 +5608,19 @@ off: Disable mitigation and remove performance impact to RDRAND and RDSEED + srcutree.convert_to_big [KNL] + Specifies under what conditions an SRCU tree + srcu_struct structure will be converted to big + form, that is, with an rcu_node tree: + + 0: Never. + 1: At init_srcu_struct() time. + 2: When rcutorture decides to. + + Either way, the srcu_node tree will be sized based + on the actual runtime number of CPUs (nr_cpu_ids) + instead of the compile-time CONFIG_NR_CPUS. + srcutree.counter_wrap_check [KNL] Specifies how frequently to check for grace-period sequence counter wrap for the -- cgit From 9f2e91d94c91558e3764fe4e01c5e6281a90f239 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Thu, 27 Jan 2022 20:32:05 -0800 Subject: srcu: Add contention-triggered addition of srcu_node tree This commit instruments the acquisitions of the srcu_struct structure's ->lock, enabling the initiation of a transition from SRCU_SIZE_SMALL to SRCU_SIZE_BIG when sufficient contention is experienced. The instrumentation counts the number of trylock failures within the confines of a single jiffy. If that number exceeds the value specified by the srcutree.small_contention_lim kernel boot parameter (which defaults to 100), and if the value specified by the srcutree.convert_to_big kernel boot parameter has the 0x10 bit set (defaults to 0), then a transition will be automatically initiated. By default, there will never be any transitions, so that none of the srcu_struct structures ever gains an srcu_node array. The useful values for srcutree.convert_to_big are: 0x00: Never convert. 0x01: Always convert at init_srcu_struct() time. 0x02: Convert when rcutorture prints its first round of statistics. 0x03: Decide conversion approach at boot given system size. 0x10: Convert if contention is encountered. 0x12: Convert if contention is encountered or when rcutorture prints its first round of statistics, whichever comes first. The value 0x11 acts the same as 0x01 because the conversion happens before there is any chance of contention. [ paulmck: Apply "static" feedback from kernel test robot. ] Co-developed-by: Neeraj Upadhyay Signed-off-by: Neeraj Upadhyay Signed-off-by: Paul E. McKenney --- Documentation/admin-guide/kernel-parameters.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 1f1fcac7777d..177e688768c0 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5616,6 +5616,7 @@ 0: Never. 1: At init_srcu_struct() time. 2: When rcutorture decides to. + 0x1X: Above plus if high contention. Either way, the srcu_node tree will be sized based on the actual runtime number of CPUs (nr_cpu_ids) @@ -5638,6 +5639,14 @@ expediting. Set to zero to disable automatic expediting. + srcutree.small_contention_lim [KNL] + Specifies the number of update-side contention + events per jiffy will be tolerated before + initiating a conversion of an srcu_struct + structure to big form. Note that the value of + srcutree.convert_to_big must have the 0x10 bit + set for contention-based conversions to occur. + ssbd= [ARM64,HW] Speculative Store Bypass Disable control -- cgit From f25390033fa2445cdc4d6cf8243a9b85d942845f Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Fri, 25 Feb 2022 16:01:12 -0800 Subject: rcu-tasks: Print pre-stall-warning informational messages RCU-tasks stall-warning messages are printed after the grace period is ten minutes old. Unfortunately, most of us will have rebooted the system in response to an apparently-hung command long before the ten minutes is up, and will thus see what looks to be a silent hang. This commit therefore adds pr_info() messages that are printed earlier. These should avoid being classified as errors, but should give impatient users a hint. These are controlled by new rcupdate.rcu_task_stall_info and rcupdate.rcu_task_stall_info_mult kernel-boot parameters. The former defines the initial delay in jiffies (defaulting to 10 seconds) and the latter defines the multiplier (defaulting to 3). Thus, by default, the first message will appear 10 seconds into the RCU-tasks grace period, the second 40 seconds in, and the third 160 seconds in. There would be a fourth at 640 seconds in, but the stall warning message appears 600 seconds in, and once a stall warning is printed for a given grace period, no further informational messages are printed. Signed-off-by: Paul E. McKenney --- Documentation/admin-guide/kernel-parameters.txt | 30 ++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 3f1cc5e317ed..babc701d4864 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4955,10 +4955,34 @@ number avoids disturbing real-time workloads, but lengthens grace periods. + rcupdate.rcu_task_stall_info= [KNL] + Set initial timeout in jiffies for RCU task stall + informational messages, which give some indication + of the problem for those not patient enough to + wait for ten minutes. Informational messages are + only printed prior to the stall-warning message + for a given grace period. Disable with a value + less than or equal to zero. Defaults to ten + seconds. A change in value does not take effect + until the beginning of the next grace period. + + rcupdate.rcu_task_stall_info_mult= [KNL] + Multiplier for time interval between successive + RCU task stall informational messages for a given + RCU tasks grace period. This value is clamped + to one through ten, inclusive. It defaults to + the value three, so that the first informational + message is printed 10 seconds into the grace + period, the second at 40 seconds, the third at + 160 seconds, and then the stall warning at 600 + seconds would prevent a fourth at 640 seconds. + rcupdate.rcu_task_stall_timeout= [KNL] - Set timeout in jiffies for RCU task stall warning - messages. Disable with a value less than or equal - to zero. + Set timeout in jiffies for RCU task stall + warning messages. Disable with a value less + than or equal to zero. Defaults to ten minutes. + A change in value does not take effect until + the beginning of the next grace period. rcupdate.rcu_self_test= [KNL] Run the RCU early boot self tests -- cgit From d00004c4563f6c00a79f7228524966ac7a1aa29c Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 5 Apr 2022 08:55:12 +0200 Subject: dt-bindings: soc: qcom,smsm: convert to dtschema Convert the Qualcomm Shared Memory State Machine to DT schema. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220405065512.26521-1-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/soc/qcom/qcom,smsm.txt | 104 ---------------- .../devicetree/bindings/soc/qcom/qcom,smsm.yaml | 138 +++++++++++++++++++++ 2 files changed, 138 insertions(+), 104 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt deleted file mode 100644 index 2993b5a97dd6..000000000000 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt +++ /dev/null @@ -1,104 +0,0 @@ -Qualcomm Shared Memory State Machine - -The Shared Memory State Machine facilitates broadcasting of single bit state -information between the processors in a Qualcomm SoC. Each processor is -assigned 32 bits of state that can be modified. A processor can through a -matrix of bitmaps signal subscription of notifications upon changes to a -certain bit owned by a certain remote processor. - -- compatible: - Usage: required - Value type: - Definition: must be one of: - "qcom,smsm" - -- qcom,ipc-N: - Usage: required - Value type: - Definition: three entries specifying the outgoing ipc bit used for - signaling the N:th remote processor - - phandle to a syscon node representing the apcs registers - - u32 representing offset to the register within the syscon - - u32 representing the ipc bit within the register - -- qcom,local-host: - Usage: optional - Value type: - Definition: identifier of the local processor in the list of hosts, or - in other words specifier of the column in the subscription - matrix representing the local processor - defaults to host 0 - -- #address-cells: - Usage: required - Value type: - Definition: must be 1 - -- #size-cells: - Usage: required - Value type: - Definition: must be 0 - -= SUBNODES -Each processor's state bits are described by a subnode of the smsm device node. -Nodes can either be flagged as an interrupt-controller to denote a remote -processor's state bits or the local processors bits. The node names are not -important. - -- reg: - Usage: required - Value type: - Definition: specifies the offset, in words, of the first bit for this - entry - -- #qcom,smem-state-cells: - Usage: required for local entry - Value type: - Definition: must be 1 - denotes bit number - -- interrupt-controller: - Usage: required for remote entries - Value type: - Definition: marks the entry as a interrupt-controller and the state bits - to belong to a remote processor - -- #interrupt-cells: - Usage: required for remote entries - Value type: - Definition: must be 2 - denotes bit number and IRQ flags - -- interrupts: - Usage: required for remote entries - Value type: - Definition: one entry specifying remote IRQ used by the remote processor - to signal changes of its state bits - - -= EXAMPLE -The following example shows the SMEM setup for controlling properties of the -wireless processor, defined from the 8974 apps processor's point-of-view. It -encompasses one outbound entry and the outgoing interrupt for the wireless -processor. - -smsm { - compatible = "qcom,smsm"; - - #address-cells = <1>; - #size-cells = <0>; - - qcom,ipc-3 = <&apcs 8 19>; - - apps_smsm: apps@0 { - reg = <0>; - - #qcom,smem-state-cells = <1>; - }; - - wcnss_smsm: wcnss@7 { - reg = <7>; - interrupts = <0 144 1>; - - interrupt-controller; - #interrupt-cells = <2>; - }; -}; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml new file mode 100644 index 000000000000..db67cf043256 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml @@ -0,0 +1,138 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/qcom/qcom,smsm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Shared Memory State Machine + +maintainers: + - Andy Gross + - Bjorn Andersson + - Krzysztof Kozlowski + +description: + The Shared Memory State Machine facilitates broadcasting of single bit state + information between the processors in a Qualcomm SoC. Each processor is + assigned 32 bits of state that can be modified. A processor can through a + matrix of bitmaps signal subscription of notifications upon changes to a + certain bit owned by a certain remote processor. + +properties: + compatible: + const: qcom,smsm + + '#address-cells': + const: 1 + + qcom,local-host: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + description: + Identifier of the local processor in the list of hosts, or in other words + specifier of the column in the subscription matrix representing the local + processor. + + '#size-cells': + const: 0 + +patternProperties: + "^qcom,ipc-[1-4]$": + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to a syscon node representing the APCS registers + - description: u32 representing offset to the register within the syscon + - description: u32 representing the ipc bit within the register + description: + Three entries specifying the outgoing ipc bit used for signaling the N:th + remote processor. + + "@[0-9a-f]$": + type: object + description: + Each processor's state bits are described by a subnode of the SMSM device + node. Nodes can either be flagged as an interrupt-controller to denote a + remote processor's state bits or the local processors bits. The node + names are not important. + + properties: + reg: + maxItems: 1 + + interrupt-controller: + description: + Marks the entry as a interrupt-controller and the state bits to + belong to a remote processor. + + '#interrupt-cells': + const: 2 + + interrupts: + maxItems: 1 + description: + One entry specifying remote IRQ used by the remote processor to + signal changes of its state bits. + + '#qcom,smem-state-cells': + $ref: /schemas/types.yaml#/definitions/uint32 + const: 1 + description: + Required for local entry. Denotes bit number. + + required: + - reg + + oneOf: + - required: + - '#qcom,smem-state-cells' + - required: + - interrupt-controller + - '#interrupt-cells' + - interrupts + + additionalProperties: false + +required: + - compatible + - '#address-cells' + - '#size-cells' + +anyOf: + - required: + - qcom,ipc-1 + - required: + - qcom,ipc-2 + - required: + - qcom,ipc-3 + - required: + - qcom,ipc-4 + +additionalProperties: false + +examples: + # The following example shows the SMEM setup for controlling properties of + # the wireless processor, defined from the 8974 apps processor's + # point-of-view. It encompasses one outbound entry and the outgoing interrupt + # for the wireless processor. + - | + #include + + shared-memory { + compatible = "qcom,smsm"; + #address-cells = <1>; + #size-cells = <0>; + qcom,ipc-3 = <&apcs 8 19>; + + apps_smsm: apps@0 { + reg = <0>; + #qcom,smem-state-cells = <1>; + }; + + wcnss_smsm: wcnss@7 { + reg = <7>; + interrupts = ; + interrupt-controller; + #interrupt-cells = <2>; + }; + }; -- cgit From a5ffbc04ad0327919157a643cc56de513a4c6928 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 5 Apr 2022 08:57:52 +0200 Subject: dt-bindings: soc: qcom,wcnss: convert to dtschema Convert the Qualcomm WCNSS bindings to DT Schema. Changes against original bindings: fix qcom,smd-channels and qcom,smem-states names (how they are used in DTS and driver), enforce child node naming of bluetooth and wifi. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220405065752.27389-3-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/soc/qcom/qcom,wcnss.txt | 131 -------------------- .../devicetree/bindings/soc/qcom/qcom,wcnss.yaml | 137 +++++++++++++++++++++ 2 files changed, 137 insertions(+), 131 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt deleted file mode 100644 index 1382b64e1381..000000000000 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt +++ /dev/null @@ -1,131 +0,0 @@ -Qualcomm WCNSS Binding - -This binding describes the Qualcomm WCNSS hardware. It consists of control -block and a BT, WiFi and FM radio block, all using SMD as command channels. - -- compatible: - Usage: required - Value type: - Definition: must be: "qcom,wcnss", - -- qcom,smd-channel: - Usage: required - Value type: - Definition: standard SMD property specifying the SMD channel used for - communication with the WiFi firmware. - Should be "WCNSS_CTRL". - -- qcom,mmio: - Usage: required - Value type: - Definition: reference to a node specifying the wcnss "ccu" and "dxe" - register blocks. The node must be compatible with one of - the following: - "qcom,riva", - "qcom,pronto" - -- firmware-name: - Usage: optional - Value type: - Definition: specifies the relative firmware image path for the WLAN NV - blob. Defaults to "wlan/prima/WCNSS_qcom_wlan_nv.bin" if - not specified. - -= SUBNODES -The subnodes of the wcnss node are optional and describe the individual blocks in -the WCNSS. - -== Bluetooth -The following properties are defined to the bluetooth node: - -- compatible: - Usage: required - Value type: - Definition: must be: - "qcom,wcnss-bt" - -- local-bd-address: - Usage: optional - Value type: - Definition: see Documentation/devicetree/bindings/net/bluetooth.txt - -== WiFi -The following properties are defined to the WiFi node: - -- compatible: - Usage: required - Value type: - Definition: must be one of: - "qcom,wcnss-wlan", - -- interrupts: - Usage: required - Value type: - Definition: should specify the "rx" and "tx" interrupts - -- interrupt-names: - Usage: required - Value type: - Definition: must contain "rx" and "tx" - -- qcom,smem-state: - Usage: required - Value type: - Definition: should reference the tx-enable and tx-rings-empty SMEM states - -- qcom,smem-state-names: - Usage: required - Value type: - Definition: must contain "tx-enable" and "tx-rings-empty" - -= EXAMPLE -The following example represents a SMD node, with one edge representing the -"pronto" subsystem, with the wcnss device and its wcn3680 BT and WiFi blocks -described; as found on the 8974 platform. - -smd { - compatible = "qcom,smd"; - - pronto-edge { - interrupts = <0 142 1>; - - qcom,ipc = <&apcs 8 17>; - qcom,smd-edge = <6>; - - wcnss { - compatible = "qcom,wcnss"; - qcom,smd-channels = "WCNSS_CTRL"; - - #address-cells = <1>; - #size-cells = <1>; - - qcom,mmio = <&pronto>; - - bt { - compatible = "qcom,wcnss-bt"; - - /* BD address 00:11:22:33:44:55 */ - local-bd-address = [ 55 44 33 22 11 00 ]; - }; - - wlan { - compatible = "qcom,wcnss-wlan"; - - interrupts = <0 145 0>, <0 146 0>; - interrupt-names = "tx", "rx"; - - qcom,smem-state = <&apps_smsm 10>, <&apps_smsm 9>; - qcom,smem-state-names = "tx-enable", "tx-rings-empty"; - }; - }; - }; -}; - -soc { - pronto: pronto { - compatible = "qcom,pronto"; - - reg = <0xfb204000 0x2000>, <0xfb202000 0x1000>, <0xfb21b000 0x3000>; - reg-names = "ccu", "dxe", "pmu"; - }; -}; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml new file mode 100644 index 000000000000..d891ecfb2691 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/qcom/qcom,wcnss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm WCNSS + +maintainers: + - Andy Gross + - Bjorn Andersson + +description: + The Qualcomm WCNSS hardware consists of control block and a BT, WiFi and FM + radio block, all using SMD as command channels. + +properties: + compatible: + const: qcom,wcnss + + firmware-name: + $ref: /schemas/types.yaml#/definitions/string + default: "wlan/prima/WCNSS_qcom_wlan_nv.bin" + description: + Relative firmware image path for the WLAN NV blob. + + qcom,mmio: + $ref: /schemas/types.yaml#/definitions/phandle + description: | + Reference to a node specifying the wcnss "ccu" and "dxe" register blocks. + The node must be compatible with one of the following:: + - qcom,riva" + - qcom,pronto" + + qcom,smd-channels: + $ref: /schemas/types.yaml#/definitions/string + const: WCNSS_CTRL + description: + Standard SMD property specifying the SMD channel used for communication + with the WiFi firmware. + + bluetooth: + type: object + additionalProperties: false + properties: + compatible: + const: qcom,wcnss-bt + + local-bd-address: + $ref: /schemas/types.yaml#/definitions/uint8-array + maxItems: 6 + description: + See Documentation/devicetree/bindings/net/bluetooth.txt + + required: + - compatible + + wifi: + additionalProperties: false + type: object + properties: + compatible: + const: qcom,wcnss-wlan + + interrupts: + maxItems: 2 + + interrupt-names: + items: + - const: tx + - const: rx + + qcom,smem-states: + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 2 + description: + Should reference the tx-enable and tx-rings-empty SMEM states. + + qcom,smem-state-names: + $ref: /schemas/types.yaml#/definitions/string-array + items: + - const: tx-enable + - const: tx-rings-empty + description: + Names of SMEM states. + + required: + - compatible + - interrupts + - interrupt-names + - qcom,smem-states + - qcom,smem-state-names + +required: + - compatible + - qcom,mmio + - qcom,smd-channels + +additionalProperties: false + +examples: + - | + #include + + smd-edge { + interrupts = ; + + qcom,ipc = <&apcs 8 17>; + qcom,smd-edge = <6>; + qcom,remote-pid = <4>; + + label = "pronto"; + + wcnss { + compatible = "qcom,wcnss"; + qcom,smd-channels = "WCNSS_CTRL"; + + qcom,mmio = <&pronto>; + + bluetooth { + compatible = "qcom,wcnss-bt"; + /* BD address 00:11:22:33:44:55 */ + local-bd-address = [ 55 44 33 22 11 00 ]; + }; + + wifi { + compatible = "qcom,wcnss-wlan"; + + interrupts = , + ; + interrupt-names = "tx", "rx"; + + qcom,smem-states = <&apps_smsm 10>, <&apps_smsm 9>; + qcom,smem-state-names = "tx-enable", "tx-rings-empty"; + }; + }; + }; -- cgit From 1dcf37365e7de6214af55587c69f4cced06262de Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 5 Apr 2022 08:34:51 +0200 Subject: dt-bindings: qcom: qcom,gsbi: convert to dtschema Convert the Qualcomm General Serial Bus Interface (GSBI) to DT Schema. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220405063451.12011-10-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/soc/qcom/qcom,gsbi.txt | 87 -------------- .../devicetree/bindings/soc/qcom/qcom,gsbi.yaml | 132 +++++++++++++++++++++ 2 files changed, 132 insertions(+), 87 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt deleted file mode 100644 index fe1855f09dcc..000000000000 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt +++ /dev/null @@ -1,87 +0,0 @@ -QCOM GSBI (General Serial Bus Interface) Driver - -The GSBI controller is modeled as a node with zero or more child nodes, each -representing a serial sub-node device that is mux'd as part of the GSBI -configuration settings. The mode setting will govern the input/output mode of -the 4 GSBI IOs. - -Required properties: -- compatible: Should contain "qcom,gsbi-v1.0.0" -- cell-index: Should contain the GSBI index -- reg: Address range for GSBI registers -- clocks: required clock -- clock-names: must contain "iface" entry -- qcom,mode : indicates MUX value for configuration of the serial interface. - Please reference dt-bindings/soc/qcom,gsbi.h for valid mux values. - -Optional properties: -- qcom,crci : indicates CRCI MUX value for QUP CRCI ports. Please reference - dt-bindings/soc/qcom,gsbi.h for valid CRCI mux values. -- syscon-tcsr: indicates phandle of TCSR syscon node. Required if child uses - dma. - -Required properties if child node exists: -- #address-cells: Must be 1 -- #size-cells: Must be 1 -- ranges: Must be present - -Properties for children: - -A GSBI controller node can contain 0 or more child nodes representing serial -devices. These serial devices can be a QCOM UART, I2C controller, spi -controller, or some combination of aforementioned devices. - -See the following for child node definitions: -Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt -Documentation/devicetree/bindings/spi/qcom,spi-qup.txt -Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt - -Example for APQ8064: - -#include - - gsbi4@16300000 { - compatible = "qcom,gsbi-v1.0.0"; - cell-index = <4>; - reg = <0x16300000 0x100>; - clocks = <&gcc GSBI4_H_CLK>; - clock-names = "iface"; - #address-cells = <1>; - #size-cells = <1>; - ranges; - qcom,mode = ; - qcom,crci = ; - - syscon-tcsr = <&tcsr>; - - /* child nodes go under here */ - - i2c_qup4: i2c@16380000 { - compatible = "qcom,i2c-qup-v1.1.1"; - reg = <0x16380000 0x1000>; - interrupts = <0 153 0>; - - clocks = <&gcc GSBI4_QUP_CLK>, <&gcc GSBI4_H_CLK>; - clock-names = "core", "iface"; - - clock-frequency = <200000>; - - #address-cells = <1>; - #size-cells = <0>; - - }; - - uart4: serial@16340000 { - compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm"; - reg = <0x16340000 0x1000>, - <0x16300000 0x1000>; - interrupts = <0 152 0x0>; - clocks = <&gcc GSBI4_UART_CLK>, <&gcc GSBI4_H_CLK>; - clock-names = "core", "iface"; - }; - }; - - tcsr: syscon@1a400000 { - compatible = "qcom,apq8064-tcsr", "syscon"; - reg = <0x1a400000 0x100>; - }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.yaml new file mode 100644 index 000000000000..c33704333e49 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/qcom/qcom,gsbi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm General Serial Bus Interface (GSBI) + +maintainers: + - Andy Gross + - Bjorn Andersson + - Krzysztof Kozlowski + +description: + The GSBI controller is modeled as a node with zero or more child nodes, each + representing a serial sub-node device that is mux'd as part of the GSBI + configuration settings. The mode setting will govern the input/output mode + of the 4 GSBI IOs. + + A GSBI controller node can contain 0 or more child nodes representing serial + devices. These serial devices can be a QCOM UART, I2C controller, spi + controller, or some combination of aforementioned devices. + +properties: + compatible: + const: qcom,gsbi-v1.0.0 + + '#address-cells': + const: 1 + + cell-index: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The GSBI index. + + clocks: + maxItems: 1 + + clock-names: + const: iface + + qcom,crci: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + CRCI MUX value for QUP CRCI ports. Please reference + include/dt-bindings/soc/qcom,gsbi.h for valid CRCI mux values. + + qcom,mode: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + MUX value for configuration of the serial interface. Please reference + include/dt-bindings/soc/qcom,gsbi.h for valid mux values. + + '#size-cells': + const: 1 + + syscon-tcsr: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle of TCSR syscon node.Required if child uses dma. + + ranges: true + + reg: + maxItems: 1 + +patternProperties: + "spi@[0-9a-f]+$": + type: object + $ref: /schemas/spi/qcom,spi-qup.yaml# + + "i2c@[0-9a-f]+$": + type: object + $ref: /schemas/i2c/qcom,i2c-qup.yaml# + + "serial@[0-9a-f]+$": + type: object + $ref: /schemas/serial/qcom,msm-uartdm.yaml# + +required: + - compatible + - cell-index + - clocks + - clock-names + - qcom,mode + - reg + +additionalProperties: false + +examples: + - | + #include + #include + #include + + gsbi@12440000 { + compatible = "qcom,gsbi-v1.0.0"; + reg = <0x12440000 0x100>; + cell-index = <1>; + clocks = <&gcc GSBI1_H_CLK>; + clock-names = "iface"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + syscon-tcsr = <&tcsr>; + qcom,mode = ; + + serial@12450000 { + compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm"; + reg = <0x12450000 0x100>, + <0x12400000 0x03>; + interrupts = <0 193 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&gcc GSBI1_UART_CLK>, <&gcc GSBI1_H_CLK>; + clock-names = "core", "iface"; + }; + + i2c@12460000 { + compatible = "qcom,i2c-qup-v1.1.1"; + reg = <0x12460000 0x1000>; + pinctrl-0 = <&i2c1_pins>; + pinctrl-1 = <&i2c1_pins_sleep>; + pinctrl-names = "default", "sleep"; + interrupts = <0 194 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&gcc GSBI1_QUP_CLK>, <&gcc GSBI1_H_CLK>; + clock-names = "core", "iface"; + #address-cells = <1>; + #size-cells = <0>; + + status = "disabled"; /* UART chosen */ + }; + }; -- cgit From ca1666463eec6a80724701bf58f33530f5642a2b Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 1 Apr 2022 22:27:59 +0200 Subject: dt-bindings: qcom,smd-rpm: update maintainers (drop Kathiravan) Kathiravan's email bounces (585: Recipient address rejected: undeliverable address: No such user here) so switch maintainers to Andy and Bjorn (as Qualcomm platform maintainers). Signed-off-by: Krzysztof Kozlowski Acked-by: Mark Brown Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220401202759.191560-1-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml | 3 ++- Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml index f052e03be402..8069d32cf899 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml @@ -69,7 +69,8 @@ description: l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22 maintainers: - - Kathiravan T + - Andy Gross + - Bjorn Andersson properties: compatible: diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index b32457c2fc0b..d91b62eed5c6 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -25,7 +25,8 @@ description: | rpm_requests. maintainers: - - Kathiravan T + - Andy Gross + - Bjorn Andersson properties: compatible: -- cgit From 506840600613027f139d30447a2c27ec8088c698 Mon Sep 17 00:00:00 2001 From: Corentin Labbe Date: Mon, 11 Apr 2022 19:44:09 +0000 Subject: ASoC: fix invalid yaml The word "or" is useless and breaks yaml validation. Signed-off-by: Corentin Labbe Link: https://lore.kernel.org/r/20220411194409.3390002-1-clabbe@baylibre.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/tas27xx.yaml | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/tas27xx.yaml b/Documentation/devicetree/bindings/sound/tas27xx.yaml index 191f4bceb4ee..66a0df8850ea 100644 --- a/Documentation/devicetree/bindings/sound/tas27xx.yaml +++ b/Documentation/devicetree/bindings/sound/tas27xx.yaml @@ -20,7 +20,6 @@ properties: compatible: enum: - ti,tas2764 - or - ti,tas2780 reg: -- cgit From 61cada8da2f4c67026e41915f91673f045d4b18c Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 11 Apr 2022 11:53:17 +0200 Subject: dt-bindings: power: renesas,rcar-sysc: correct typo in path Fix typo '.' -> '/' in the path to headers. Fixes: 981a34054038 ("dt-bindings: power: renesas,rcar-sysc: drop useless consumer example") Reported-by: Geert Uytterhoeven Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220411095317.221317-1-krzysztof.kozlowski@linaro.org --- Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml index bd9608c83c3f..76c417990f12 100644 --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml @@ -14,7 +14,7 @@ description: | The R-Car (RZ/G) System Controller provides power management for the CPU cores and various coprocessors. The power domain IDs for consumers are defined in header files:: - include.dt-bindings/power/r8*-sysc.h + include/dt-bindings/power/r8*-sysc.h properties: compatible: -- cgit From 4185b27b3bef9ce724a3dafd8193c935e845fcdc Mon Sep 17 00:00:00 2001 From: Taniya Das Date: Wed, 23 Feb 2022 22:52:47 +0530 Subject: dt-bindings: clock: Add YAML schemas for LPASS clocks on SC7280 The LPASS(Low Power Audio Subsystem) clock provider have a bunch of generic properties that are needed in a device tree. Also add clock ids for LPASS core clocks and audio clock IDs for LPASS client to request for the clocks. Reviewed-by: Rob Herring Reviewed-by: Stephen Boyd Signed-off-by: Taniya Das Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220223172248.18877-1-tdas@codeaurora.org --- .../bindings/clock/qcom,sc7280-lpasscorecc.yaml | 172 +++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml new file mode 100644 index 000000000000..bad9135489de --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml @@ -0,0 +1,172 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sc7280-lpasscorecc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm LPASS Core & Audio Clock Controller Binding for SC7280 + +maintainers: + - Taniya Das + +description: | + Qualcomm LPASS core and audio clock control module which supports the + clocks and power domains on SC7280. + + See also: + - dt-bindings/clock/qcom,lpasscorecc-sc7280.h + - dt-bindings/clock/qcom,lpassaudiocc-sc7280.h + +properties: + clocks: true + + clock-names: true + + compatible: + enum: + - qcom,sc7280-lpassaoncc + - qcom,sc7280-lpassaudiocc + - qcom,sc7280-lpasscorecc + - qcom,sc7280-lpasshm + + power-domains: + maxItems: 1 + + '#clock-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#power-domain-cells' + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + const: qcom,sc7280-lpassaudiocc + + then: + properties: + clocks: + items: + - description: Board XO source + - description: LPASS_AON_CC_MAIN_RCG_CLK_SRC + + clock-names: + items: + - const: bi_tcxo + - const: lpass_aon_cc_main_rcg_clk_src + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7280-lpassaoncc + + then: + properties: + clocks: + items: + - description: Board XO source + - description: Board XO active only source + - description: LPASS_AON_CC_MAIN_RCG_CLK_SRC + + clock-names: + items: + - const: bi_tcxo + - const: bi_tcxo_ao + - const: iface + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7280-lpasshm + - qcom,sc7280-lpasscorecc + + then: + properties: + clocks: + items: + - description: Board XO source + + clock-names: + items: + - const: bi_tcxo + +examples: + - | + #include + #include + #include + #include + lpass_audiocc: clock-controller@3300000 { + compatible = "qcom,sc7280-lpassaudiocc"; + reg = <0x3300000 0x30000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&lpass_aon LPASS_AON_CC_MAIN_RCG_CLK_SRC>; + clock-names = "bi_tcxo", "lpass_aon_cc_main_rcg_clk_src"; + power-domains = <&lpass_aon LPASS_AON_CC_LPASS_AUDIO_HM_GDSC>; + #clock-cells = <1>; + #power-domain-cells = <1>; + }; + + - | + #include + #include + #include + #include + lpass_hm: clock-controller@3c00000 { + compatible = "qcom,sc7280-lpasshm"; + reg = <0x3c00000 0x28>; + clocks = <&rpmhcc RPMH_CXO_CLK>; + clock-names = "bi_tcxo"; + #clock-cells = <1>; + #power-domain-cells = <1>; + }; + + - | + #include + #include + #include + #include + lpasscore: clock-controller@3900000 { + compatible = "qcom,sc7280-lpasscorecc"; + reg = <0x3900000 0x50000>; + clocks = <&rpmhcc RPMH_CXO_CLK>; + clock-names = "bi_tcxo"; + power-domains = <&lpass_hm LPASS_CORE_CC_LPASS_CORE_HM_GDSC>; + #clock-cells = <1>; + #power-domain-cells = <1>; + }; + + - | + #include + #include + #include + #include + lpass_aon: clock-controller@3380000 { + compatible = "qcom,sc7280-lpassaoncc"; + reg = <0x3380000 0x30000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, <&rpmhcc RPMH_CXO_CLK_A>, + <&lpasscore LPASS_CORE_CC_CORE_CLK>; + clock-names = "bi_tcxo", "bi_tcxo_ao","iface"; + #clock-cells = <1>; + #power-domain-cells = <1>; + }; + +... -- cgit From a29c96a4053dc3c1d39353b61089882f81c6b23d Mon Sep 17 00:00:00 2001 From: Jae Hyun Yoo Date: Tue, 29 Mar 2022 10:39:28 -0700 Subject: dt-bindings: pinctrl: aspeed-g6: remove FWQSPID group FWQSPID is not a group of FWSPID so remove it. Fixes: 7488838f2315 ("dt-bindings: pinctrl: aspeed: Document AST2600 pinmux") Signed-off-by: Jae Hyun Yoo Acked-by: Rob Herring Reviewed-by: Andrew Jeffery Link: https://lore.kernel.org/r/20220329173932.2588289-4-quic_jaehyoo@quicinc.com Signed-off-by: Joel Stanley --- Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml index 57b68d6c7c70..eb6e2f2dc9eb 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml @@ -58,7 +58,7 @@ patternProperties: $ref: "/schemas/types.yaml#/definitions/string" enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMCG1, EMMCG4, - EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWQSPID, FWSPIWP, + EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, HVI3C3, HVI3C4, I2C1, I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, -- cgit From 5da3ae69987a92c009263e38a0b1842fa879c7a0 Mon Sep 17 00:00:00 2001 From: Jae Hyun Yoo Date: Tue, 29 Mar 2022 10:39:30 -0700 Subject: dt-bindings: pinctrl: aspeed-g6: add FWQSPI function/group Add FWQSPI function/group to support QSPI mode on the dedicated FWSPI interface. Signed-off-by: Jae Hyun Yoo Reviewed-by: Andrew Jeffery Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220329173932.2588289-6-quic_jaehyoo@quicinc.com Signed-off-by: Joel Stanley --- Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml index eb6e2f2dc9eb..3666ac5b6518 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml @@ -33,7 +33,7 @@ patternProperties: $ref: "/schemas/types.yaml#/definitions/string" enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMC, ESPI, ESPIALT, - FSI1, FSI2, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3, + FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, I2C1, I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, @@ -58,7 +58,7 @@ patternProperties: $ref: "/schemas/types.yaml#/definitions/string" enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMCG1, EMMCG4, - EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWSPIWP, + EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, HVI3C3, HVI3C4, I2C1, I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, -- cgit From 7102ffe4c166ca0f5e35137e9f9de83768c2d27d Mon Sep 17 00:00:00 2001 From: "wangjianjian (C)" Date: Fri, 1 Apr 2022 20:07:35 +0800 Subject: ext4, doc: fix incorrect h_reserved size According to document and code, ext4_xattr_header's size is 32 bytes, so h_reserved size should be 3. Signed-off-by: Wang Jianjian Link: https://lore.kernel.org/r/92fcc3a6-7d77-8c09-4126-377fcb4c46a5@huawei.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org --- Documentation/filesystems/ext4/attributes.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/ext4/attributes.rst b/Documentation/filesystems/ext4/attributes.rst index 54386a010a8d..871d2da7a0a9 100644 --- a/Documentation/filesystems/ext4/attributes.rst +++ b/Documentation/filesystems/ext4/attributes.rst @@ -76,7 +76,7 @@ The beginning of an extended attribute block is in - Checksum of the extended attribute block. * - 0x14 - \_\_u32 - - h\_reserved[2] + - h\_reserved[3] - Zero. The checksum is calculated against the FS UUID, the 64-bit block number -- cgit From b736cedce53390705887d5188678b0f25a9b9c23 Mon Sep 17 00:00:00 2001 From: Luca Weiss Date: Sat, 26 Feb 2022 11:19:38 +0100 Subject: dt-bindings: arm: qcom: Document asus,sparrow device Document the ASUS ZenWatch 2 ("sparrow") which is a smartwatch based on Snapdragon 400 SoC. Signed-off-by: Luca Weiss Acked-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220226101939.1011551-1-luca@z3ntu.xyz --- Documentation/devicetree/bindings/arm/qcom.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 129cdd246223..7f89ab344d3f 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -99,6 +99,7 @@ properties: - items: - enum: + - asus,sparrow - lg,lenok - const: qcom,apq8026 -- cgit From a175c6faaa36b1a4c7d945bd3fb0c354c9323623 Mon Sep 17 00:00:00 2001 From: Adam Skladowski Date: Mon, 7 Mar 2022 20:17:24 +0100 Subject: dt-bindings: firmware: qcom-scm: Document msm8976 bindings SCM driver on MSM8976 requires 3 clocks. Signed-off-by: Adam Skladowski Acked-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220307191726.10869-4-a39.skl@gmail.com --- Documentation/devicetree/bindings/firmware/qcom,scm.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt index b1cd4ad1889a..0f4e5ab26477 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt @@ -19,6 +19,7 @@ Required properties: * "qcom,scm-msm8953" * "qcom,scm-msm8960" * "qcom,scm-msm8974" + * "qcom,scm-msm8976" * "qcom,scm-msm8994" * "qcom,scm-msm8996" * "qcom,scm-msm8998" @@ -37,7 +38,7 @@ Required properties: * core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660" and "qcom,scm-msm8960" * core, iface and bus clocks required for "qcom,scm-apq8084", - "qcom,scm-msm8916", "qcom,scm-msm8953" and "qcom,scm-msm8974" + "qcom,scm-msm8916", "qcom,scm-msm8953", "qcom,scm-msm8974" and "qcom,scm-msm8976" - clock-names: Must contain "core" for the core clock, "iface" for the interface clock and "bus" for the bus clock per the requirements of the compatible. - qcom,dload-mode: phandle to the TCSR hardware block and offset of the -- cgit From 375eed5f51a84dee4cf933a2ec0710bab9a8df69 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 1 Apr 2022 22:10:33 +0200 Subject: dt-bindings: soc: qcom,smd: convert to dtschema Convert the Qualcomm Shared Memory Driver bindings to DT Schema. Changes against original bindings: enforce only specific names of child nodes, instead of any names. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220401201035.189106-9-krzysztof.kozlowski@linaro.org --- .../bindings/regulator/qcom,smd-rpm-regulator.yaml | 2 +- .../devicetree/bindings/remoteproc/qcom,q6v5.txt | 2 +- .../bindings/remoteproc/qcom,wcnss-pil.txt | 2 +- .../devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml | 4 +- .../devicetree/bindings/soc/qcom/qcom,smd.txt | 98 --------------- .../devicetree/bindings/soc/qcom/qcom,smd.yaml | 137 +++++++++++++++++++++ 6 files changed, 142 insertions(+), 103 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml index 8069d32cf899..6a9a7eed466f 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml @@ -12,7 +12,7 @@ description: resides as a subnode of the SMD. As such, the SMD-RPM regulator requires that the SMD and RPM nodes be present. - Please refer to Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt for + Please refer to Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml for information pertaining to the SMD node. Please refer to Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 8f1507052afd..b677900b3aae 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -250,7 +250,7 @@ the memory regions used by the Hexagon firmware. Each sub-node must contain: The Hexagon node may also have an subnode named either "smd-edge" or "glink-edge" that describes the communication edge, channels and devices -related to the Hexagon. See ../soc/qcom/qcom,smd.txt and +related to the Hexagon. See ../soc/qcom/qcom,smd.yaml and ../soc/qcom/qcom,glink.txt for details on how to describe these. = EXAMPLE diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt index a83080b8905c..ac423f4c3f1b 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt @@ -111,7 +111,7 @@ and its resource dependencies. It is described by the following properties: The wcnss node can also have an subnode named "smd-edge" that describes the SMD edge, channels and devices related to the WCNSS. -See ../soc/qcom/qcom,smd.txt for details on how to describe the SMD edge. +See ../soc/qcom/qcom,smd.yaml for details on how to describe the SMD edge. = EXAMPLE The following example describes the resources needed to boot control the WCNSS, diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index d91b62eed5c6..c4ca384be196 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -12,7 +12,7 @@ description: | to vote for state of the system resources, such as clocks, regulators and bus frequencies. - The SMD information for the RPM edge should be filled out. See qcom,smd.txt + The SMD information for the RPM edge should be filled out. See qcom,smd.yaml for the required edge properties. All SMD related properties will reside within the RPM node itself. @@ -83,7 +83,7 @@ examples: qcom,ipc = <&apcs 8 0>; qcom,smd-edge = <15>; - rpm_requests { + rpm-requests { compatible = "qcom,rpm-msm8974"; qcom,smd-channels = "rpm_requests"; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt deleted file mode 100644 index 234ae2256501..000000000000 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt +++ /dev/null @@ -1,98 +0,0 @@ -Qualcomm Shared Memory Driver (SMD) binding - -This binding describes the Qualcomm Shared Memory Driver, a fifo based -communication channel for sending data between the various subsystems in -Qualcomm platforms. - -- compatible: - Usage: required - Value type: - Definition: must be "qcom,smd" - -= EDGES - -Each subnode of the SMD node represents a remote subsystem or a remote -processor of some sort - or in SMD language an "edge". The name of the edges -are not important. -The edge is described by the following properties: - -- interrupts: - Usage: required - Value type: - Definition: should specify the IRQ used by the remote processor to - signal this processor about communication related updates - -- mboxes: - Usage: required - Value type: - Definition: reference to the associated doorbell in APCS, as described - in mailbox/mailbox.txt - -- qcom,ipc: - Usage: required, unless mboxes is specified - Value type: - Definition: three entries specifying the outgoing ipc bit used for - signaling the remote processor: - - phandle to a syscon node representing the apcs registers - - u32 representing offset to the register within the syscon - - u32 representing the ipc bit within the register - -- qcom,smd-edge: - Usage: required - Value type: - Definition: the identifier of the remote processor in the smd channel - allocation table - -- qcom,remote-pid: - Usage: optional - Value type: - Definition: the identifier for the remote processor as known by the rest - of the system. - -- label: - Usage: optional - Value type: - Definition: name of the edge, used for debugging and identification - purposes. The node name will be used if this is not - present. - -= SMD DEVICES - -In turn, subnodes of the "edges" represent devices tied to SMD channels on that -"edge". The names of the devices are not important. The properties of these -nodes are defined by the individual bindings for the SMD devices - but must -contain the following property: - -- qcom,smd-channels: - Usage: required - Value type: - Definition: a list of channels tied to this device, used for matching - the device to channels - -= EXAMPLE - -The following example represents a smd node, with one edge representing the -"rpm" subsystem. For the "rpm" subsystem we have a device tied to the -"rpm_request" channel. - - apcs: syscon@f9011000 { - compatible = "syscon"; - reg = <0xf9011000 0x1000>; - }; - - smd { - compatible = "qcom,smd"; - - rpm { - interrupts = <0 168 1>; - qcom,ipc = <&apcs 8 0>; - qcom,smd-edge = <15>; - - rpm_requests { - compatible = "qcom,rpm-msm8974"; - qcom,smd-channels = "rpm_requests"; - - ... - }; - }; - }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml new file mode 100644 index 000000000000..e6f9ffa1c0ea --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/qcom/qcom,smd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Shared Memory Driver + +maintainers: + - Andy Gross + - Bjorn Andersson + - Krzysztof Kozlowski + +description: + The Qualcomm Shared Memory Driver is a FIFO based communication channel for + sending data between the various subsystems in Qualcomm platforms. + +properties: + compatible: + const: qcom,smd + +patternProperties: + "^.*-edge|rpm$": + type: object + description: + Each subnode of the SMD node represents a remote subsystem or a remote + processor of some sort - or in SMD language an "edge". The name of the + edges are not important. + + properties: + interrupts: + maxItems: 1 + + label: + $ref: /schemas/types.yaml#/definitions/string + description: + Name of the edge, used for debugging and identification purposes. The + node name will be used if this is not present. + + mboxes: + maxItems: 1 + description: + Reference to the mailbox representing the outgoing doorbell in APCS for + this client. + + qcom,ipc: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to a syscon node representing the APCS registers + - description: u32 representing offset to the register within the syscon + - description: u32 representing the ipc bit within the register + description: + Three entries specifying the outgoing ipc bit used for signaling the + remote processor. + + qcom,smd-edge: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The identifier of the remote processor in the smd channel allocation + table. + + qcom,remote-pid: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The identifier for the remote processor as known by the rest of the + system. + + # Binding for edge subnodes is not complete + patternProperties: + "^rpm-requests$": + type: object + description: + In turn, subnodes of the "edges" represent devices tied to SMD + channels on that "edge". The names of the devices are not + important. The properties of these nodes are defined by the + individual bindings for the SMD devices. + + properties: + qcom,smd-channels: + $ref: /schemas/types.yaml#/definitions/string-array + minItems: 1 + maxItems: 32 + description: + A list of channels tied to this device, used for matching the + device to channels. + + required: + - compatible + - qcom,smd-channels + + additionalProperties: true + + required: + - interrupts + - qcom,smd-edge + + oneOf: + - required: + - mboxes + - required: + - qcom,ipc + + additionalProperties: false + +required: + - compatible + +additionalProperties: false + +examples: + # The following example represents a smd node, with one edge representing the + # "rpm" subsystem. For the "rpm" subsystem we have a device tied to the + # "rpm_request" channel. + - | + #include + + shared-memory { + compatible = "qcom,smd"; + + rpm { + interrupts = ; + qcom,ipc = <&apcs 8 0>; + qcom,smd-edge = <15>; + + rpm-requests { + compatible = "qcom,rpm-msm8974"; + qcom,smd-channels = "rpm_requests"; + + clock-controller { + compatible = "qcom,rpmcc-msm8974", "qcom,rpmcc"; + #clock-cells = <1>; + }; + + }; + }; + }; -- cgit From 05a24414fd5ee93f6aa7a6ad684657cd0d36777a Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 1 Apr 2022 22:10:34 +0200 Subject: dt-bindings: clock: qcom,rpmcc: convert to dtschema Convert the Qualcomm RPM Clock Controller bindings to DT schema and include it in parent's schema (SMD RPM). Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220401201035.189106-10-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/clock/qcom,rpmcc.txt | 63 -------------------- .../devicetree/bindings/clock/qcom,rpmcc.yaml | 69 ++++++++++++++++++++++ .../devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml | 4 ++ 3 files changed, 73 insertions(+), 63 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/qcom,rpmcc.txt create mode 100644 Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt deleted file mode 100644 index da295c3c004b..000000000000 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt +++ /dev/null @@ -1,63 +0,0 @@ -Qualcomm RPM Clock Controller Binding ------------------------------------------------- -The RPM is a dedicated hardware engine for managing the shared -SoC resources in order to keep the lowest power profile. It -communicates with other hardware subsystems via shared memory -and accepts clock requests, aggregates the requests and turns -the clocks on/off or scales them on demand. - -Required properties : -- compatible : shall contain only one of the following. The generic - compatible "qcom,rpmcc" should be also included. - - "qcom,rpmcc-mdm9607", "qcom,rpmcc" - "qcom,rpmcc-msm8660", "qcom,rpmcc" - "qcom,rpmcc-apq8060", "qcom,rpmcc" - "qcom,rpmcc-msm8226", "qcom,rpmcc" - "qcom,rpmcc-msm8916", "qcom,rpmcc" - "qcom,rpmcc-msm8936", "qcom,rpmcc" - "qcom,rpmcc-msm8953", "qcom,rpmcc" - "qcom,rpmcc-msm8974", "qcom,rpmcc" - "qcom,rpmcc-msm8976", "qcom,rpmcc" - "qcom,rpmcc-apq8064", "qcom,rpmcc" - "qcom,rpmcc-ipq806x", "qcom,rpmcc" - "qcom,rpmcc-msm8992",·"qcom,rpmcc" - "qcom,rpmcc-msm8994",·"qcom,rpmcc" - "qcom,rpmcc-msm8996", "qcom,rpmcc" - "qcom,rpmcc-msm8998", "qcom,rpmcc" - "qcom,rpmcc-qcm2290", "qcom,rpmcc" - "qcom,rpmcc-qcs404", "qcom,rpmcc" - "qcom,rpmcc-sdm660", "qcom,rpmcc" - "qcom,rpmcc-sm6115", "qcom,rpmcc" - "qcom,rpmcc-sm6125", "qcom,rpmcc" - -- #clock-cells : shall contain 1 - -The clock enumerators are defined in -and come in pairs: FOO_CLK followed by FOO_A_CLK. The latter clock -is an "active" clock, which means that the consumer only care that the -clock is available when the apps CPU subsystem is active, i.e. not -suspended or in deep idle. If it is important that the clock keeps running -during system suspend, you need to specify the non-active clock, the one -not containing *_A_* in the enumerator name. - -Example: - smd { - compatible = "qcom,smd"; - - rpm { - interrupts = <0 168 1>; - qcom,ipc = <&apcs 8 0>; - qcom,smd-edge = <15>; - - rpm_requests { - compatible = "qcom,rpm-msm8916"; - qcom,smd-channels = "rpm_requests"; - - rpmcc: clock-controller { - compatible = "qcom,rpmcc-msm8916", "qcom,rpmcc"; - #clock-cells = <1>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml new file mode 100644 index 000000000000..6a492b1ebc7c --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,rpmcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm RPM Clock Controller + +maintainers: + - Bjorn Andersson + - Krzysztof Kozlowski + +description: | + The clock enumerators are defined in and + come in pairs:: FOO_CLK followed by FOO_A_CLK. The latter clock is + an "active" clock, which means that the consumer only care that the clock is + available when the apps CPU subsystem is active, i.e. not suspended or in + deep idle. If it is important that the clock keeps running during system + suspend, you need to specify the non-active clock, the one not containing + *_A_* in the enumerator name. + +properties: + compatible: + items: + - enum: + - qcom,rpmcc-apq8060 + - qcom,rpmcc-apq8064 + - qcom,rpmcc-ipq806x + - qcom,rpmcc-mdm9607 + - qcom,rpmcc-msm8226 + - qcom,rpmcc-msm8660 + - qcom,rpmcc-msm8916 + - qcom,rpmcc-msm8936 + - qcom,rpmcc-msm8953 + - qcom,rpmcc-msm8974 + - qcom,rpmcc-msm8976 + - qcom,rpmcc-msm8992 + - qcom,rpmcc-msm8994 + - qcom,rpmcc-msm8996 + - qcom,rpmcc-msm8998 + - qcom,rpmcc-qcm2290 + - qcom,rpmcc-qcs404 + - qcom,rpmcc-sdm660 + - qcom,rpmcc-sm6115 + - qcom,rpmcc-sm6125 + - const: qcom,rpmcc + + '#clock-cells': + const: 1 + +required: + - compatible + - '#clock-cells' + +additionalProperties: false + +examples: + - | + rpm { + rpm-requests { + compatible = "qcom,rpm-msm8916"; + qcom,smd-channels = "rpm_requests"; + + clock-controller { + compatible = "qcom,rpmcc-msm8916", "qcom,rpmcc"; + #clock-cells = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index b32457c2fc0b..e6543de51d70 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -45,6 +45,10 @@ properties: - qcom,rpm-qcm2290 - qcom,rpm-qcs404 + clock-controller: + $ref: /schemas/clock/qcom,rpmcc.yaml# + unevaluatedProperties: false + qcom,smd-channels: $ref: /schemas/types.yaml#/definitions/string-array description: Channel name used for the RPM communication -- cgit From e5baef55f891b0ef6518bd5eeeee75a5f8b676dc Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 1 Apr 2022 22:10:35 +0200 Subject: dt-bindings: clock: qcom,rpmcc: add clocks property The RPM clock controller receive input clock ("xo"). It is modelled on only one chip - MSM8953. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220401201035.189106-11-krzysztof.kozlowski@linaro.org --- Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml index 6a492b1ebc7c..9d296b89a8d0 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml @@ -48,6 +48,12 @@ properties: '#clock-cells': const: 1 + clocks: + maxItems: 1 + + clock-names: + const: xo + required: - compatible - '#clock-cells' -- cgit From 7b5d44212076e7474bc8d86bcf38829992a14cc2 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 4 Apr 2022 08:40:17 +0200 Subject: dt-bindings: qcom: qcom,geni-se: refer to dtschema for SPI After adding DT schema for the SPI controller, the Qualcomm GENI Serial Engine QUP Wrapper Controller bindings can reference it directly for full schema validation. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Kuldeep Singh Reviewed-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220404064017.68634-2-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/soc/qcom/qcom,geni-se.yaml | 22 +--------------------- 1 file changed, 1 insertion(+), 21 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index 95fcb43675d6..1ca081b1664e 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -103,27 +103,7 @@ patternProperties: supports up to 50MHz, up to four chip selects, programmable data path from 4 bits to 32 bits and numerous protocol variants. - $ref: /schemas/spi/spi-controller.yaml# - - properties: - compatible: - enum: - - qcom,geni-spi - - interrupts: - maxItems: 1 - - "#address-cells": - const: 1 - - "#size-cells": - const: 0 - - required: - - compatible - - interrupts - - "#address-cells" - - "#size-cells" + $ref: /schemas/spi/qcom,spi-geni-qcom.yaml# "i2c@[0-9a-f]+$": type: object -- cgit From cfe4c1021ef5621384878f1de0bc8fdab761a702 Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Wed, 30 Mar 2022 19:55:11 +0900 Subject: dt-bindings: phy: uniphier-usb2: Add vbus-supply UniPhier USB2 PHY controller can apply vbus-supply. Add "vbus-supply" property to fix the following warning. uniphier-pro4-ace.dtb: usb-glue: phy@2: 'vbus-supply' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml Signed-off-by: Kunihiko Hayashi Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/1648637715-19262-2-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml index 479b203f7aa6..63dab914a48d 100644 --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml @@ -43,6 +43,9 @@ patternProperties: "#phy-cells": const: 0 + vbus-supply: + description: A phandle to the regulator for USB VBUS, only for USB host + required: - reg - "#phy-cells" -- cgit From 61a37dc9c36fe4be455cef89e17388fa6e9c1e82 Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Wed, 30 Mar 2022 19:55:12 +0900 Subject: dt-bindings: phy: uniphier-usb3ss: Treat vbus-supply as optional The usb-device doesn't need "vbus-supply" property, so the property should be removed from required. Signed-off-by: Kunihiko Hayashi Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/1648637715-19262-3-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml index 92d46eb913a3..06c957d52d23 100644 --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml @@ -61,7 +61,7 @@ properties: - const: phy vbus-supply: - description: A phandle to the regulator for USB VBUS + description: A phandle to the regulator for USB VBUS, only for USB host required: - compatible @@ -71,7 +71,6 @@ required: - clock-names - resets - reset-names - - vbus-supply additionalProperties: false -- cgit From fccd2f32deb1bef32915b2240dfd603633eef960 Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Wed, 30 Mar 2022 19:55:13 +0900 Subject: dt-bindings: phy: uniphier-ahci: Fix missing reset-names UniPhier AHCI PHY controller needs to specify 6 reset lines, so this adds missing "phy" to reset-names and increases maxItems of resets. Fixes: 34f92b67621f ("dt-bindings: phy: uniphier-ahci: Add bindings for Pro4 SoC") Signed-off-by: Kunihiko Hayashi Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/1648637715-19262-4-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml index 3b400a85b44a..14f7579e7daa 100644 --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml @@ -43,13 +43,14 @@ properties: resets: minItems: 2 - maxItems: 5 + maxItems: 6 reset-names: oneOf: - items: # for Pro4 - const: link - const: gio + - const: phy - const: pm - const: tx - const: rx -- cgit From 45d1f841d5a4afb415415f9f87c9d4ce15e19f42 Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Wed, 30 Mar 2022 19:55:14 +0900 Subject: dt-bindings: phy: uniphier-usb3hs: Fix incorrect clock-names and reset-names There is no clock-names and reset-names for Pro5 SoC, that should have two properties, "gio" and "link" like usb3-ssphy. And according to the existing PXs2 devicetree, the clock-names for PXs2 SoC should have "link" and "phy", and minItems of clocks should be 2. Fixes: 134ab2845acb ("dt-bindings: phy: Convert UniPhier USB3-PHY conroller to json-schema") Signed-off-by: Kunihiko Hayashi Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/1648637715-19262-5-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Vinod Koul --- .../bindings/phy/socionext,uniphier-usb3hs-phy.yaml | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml index 33946efcac5e..1bbd164f2527 100644 --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml @@ -31,12 +31,14 @@ properties: const: 0 clocks: - minItems: 1 + minItems: 2 maxItems: 3 clock-names: oneOf: - - const: link # for PXs2 + - items: # for Pro5 + - const: gio + - const: link - items: # for PXs3 with phy-ext - const: link - const: phy @@ -49,9 +51,13 @@ properties: maxItems: 2 reset-names: - items: - - const: link - - const: phy + oneOf: + - items: # for Pro5 + - const: gio + - const: link + - items: # for others + - const: link + - const: phy vbus-supply: description: A phandle to the regulator for USB VBUS -- cgit From 09cc358a39d41152236e8f2653a94ab39b35cd3f Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Wed, 30 Mar 2022 19:55:15 +0900 Subject: dt-bindings: phy: uniphier: Clean up clocks, resets, and their names using compatible string Instead of "oneOf:" choices, use "allOf:" and "if:" to define clocks, clock-names, resets, and reset-names that can be taken by the compatible string. The order of clock-names and reset-names doesn't change here. Signed-off-by: Kunihiko Hayashi Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/1648637715-19262-6-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Vinod Koul --- .../bindings/phy/socionext,uniphier-ahci-phy.yaml | 90 +++++++++++++++----- .../bindings/phy/socionext,uniphier-pcie-phy.yaml | 47 ++++++++--- .../phy/socionext,uniphier-usb3hs-phy.yaml | 93 ++++++++++++++++----- .../phy/socionext,uniphier-usb3ss-phy.yaml | 95 +++++++++++++++++----- 4 files changed, 251 insertions(+), 74 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml index 14f7579e7daa..a3cd45acea28 100644 --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml @@ -30,33 +30,79 @@ properties: minItems: 1 maxItems: 2 - clock-names: - oneOf: - - items: # for PXs2 - - const: link - - items: # for Pro4 - - const: link - - const: gio - - items: # for others - - const: link - - const: phy + clock-names: true resets: minItems: 2 maxItems: 6 - reset-names: - oneOf: - - items: # for Pro4 - - const: link - - const: gio - - const: phy - - const: pm - - const: tx - - const: rx - - items: # for others - - const: link - - const: phy + reset-names: true + +allOf: + - if: + properties: + compatible: + contains: + const: socionext,uniphier-pro4-ahci-phy + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: link + - const: gio + resets: + minItems: 6 + maxItems: 6 + reset-names: + items: + - const: link + - const: gio + - const: phy + - const: pm + - const: tx + - const: rx + - if: + properties: + compatible: + contains: + const: socionext,uniphier-pxs2-ahci-phy + then: + properties: + clocks: + maxItems: 1 + clock-names: + const: link + resets: + minItems: 2 + maxItems: 2 + reset-names: + items: + - const: link + - const: phy + - if: + properties: + compatible: + contains: + const: socionext,uniphier-pxs3-ahci-phy + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: link + - const: phy + resets: + minItems: 2 + maxItems: 2 + reset-names: + items: + - const: link + - const: phy required: - compatible diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml index fbb71d6dd531..b3ed2f74a414 100644 --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml @@ -31,28 +31,51 @@ properties: minItems: 1 maxItems: 2 - clock-names: - oneOf: - - items: # for Pro5 - - const: gio - - const: link - - const: link # for others + clock-names: true resets: minItems: 1 maxItems: 2 - reset-names: - oneOf: - - items: # for Pro5 - - const: gio - - const: link - - const: link # for others + reset-names: true socionext,syscon: $ref: /schemas/types.yaml#/definitions/phandle description: A phandle to system control to set configurations for phy +allOf: + - if: + properties: + compatible: + contains: + const: socionext,uniphier-pro5-pcie-phy + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: gio + - const: link + resets: + minItems: 2 + maxItems: 2 + reset-names: + items: + - const: gio + - const: link + else: + properties: + clocks: + maxItems: 1 + clock-names: + const: link + resets: + maxItems: 1 + reset-names: + const: link + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml index 1bbd164f2527..21e4414eea60 100644 --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml @@ -34,30 +34,12 @@ properties: minItems: 2 maxItems: 3 - clock-names: - oneOf: - - items: # for Pro5 - - const: gio - - const: link - - items: # for PXs3 with phy-ext - - const: link - - const: phy - - const: phy-ext - - items: # for others - - const: link - - const: phy + clock-names: true resets: maxItems: 2 - reset-names: - oneOf: - - items: # for Pro5 - - const: gio - - const: link - - items: # for others - - const: link - - const: phy + reset-names: true vbus-supply: description: A phandle to the regulator for USB VBUS @@ -80,6 +62,77 @@ properties: required for each port, if any one is omitted, the trimming data of the port will not be set at all. +allOf: + - if: + properties: + compatible: + contains: + const: socionext,uniphier-pro5-usb3-hsphy + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: gio + - const: link + resets: + minItems: 2 + maxItems: 2 + reset-names: + items: + - const: gio + - const: link + - if: + properties: + compatible: + contains: + enum: + - socionext,uniphier-pxs2-usb3-hsphy + - socionext,uniphier-ld20-usb3-hsphy + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: link + - const: phy + resets: + minItems: 2 + maxItems: 2 + reset-names: + items: + - const: link + - const: phy + - if: + properties: + compatible: + contains: + enum: + - socionext,uniphier-pxs3-usb3-hsphy + - socionext,uniphier-nx1-usb3-hsphy + then: + properties: + clocks: + minItems: 2 + maxItems: 3 + clock-names: + minItems: 2 + items: + - const: link + - const: phy + - const: phy-ext + resets: + minItems: 2 + maxItems: 2 + reset-names: + items: + - const: link + - const: phy + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml index 06c957d52d23..4c26d2d2303d 100644 --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml @@ -35,34 +35,89 @@ properties: minItems: 2 maxItems: 3 - clock-names: - oneOf: - - items: # for Pro4, Pro5 - - const: gio - - const: link - - items: # for PXs3 with phy-ext - - const: link - - const: phy - - const: phy-ext - - items: # for others - - const: link - - const: phy + clock-names: true resets: maxItems: 2 - reset-names: - oneOf: - - items: # for Pro4,Pro5 - - const: gio - - const: link - - items: # for others - - const: link - - const: phy + reset-names: true vbus-supply: description: A phandle to the regulator for USB VBUS, only for USB host +allOf: + - if: + properties: + compatible: + contains: + enum: + - socionext,uniphier-pro4-usb3-ssphy + - socionext,uniphier-pro5-usb3-ssphy + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: gio + - const: link + resets: + minItems: 2 + maxItems: 2 + reset-names: + items: + - const: gio + - const: link + - if: + properties: + compatible: + contains: + enum: + - socionext,uniphier-pxs2-usb3-ssphy + - socionext,uniphier-ld20-usb3-ssphy + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: link + - const: phy + resets: + minItems: 2 + maxItems: 2 + reset-names: + items: + - const: link + - const: phy + - if: + properties: + compatible: + contains: + enum: + - socionext,uniphier-pxs3-usb3-ssphy + - socionext,uniphier-nx1-usb3-ssphy + then: + properties: + clocks: + minItems: 2 + maxItems: 3 + clock-names: + minItems: 2 + items: + - const: link + - const: phy + - const: phy-ext + resets: + minItems: 2 + maxItems: 2 + reset-names: + items: + - const: link + - const: phy + required: - compatible - reg -- cgit From aa1855a79a95960cc51c51ce714d4cd4d3cf1757 Mon Sep 17 00:00:00 2001 From: Rohit Agarwal Date: Tue, 12 Apr 2022 10:47:31 +0530 Subject: dt-bindings: phy: qcom,qmp: Add SDX65 USB PHY binding Add devicetree YAML binding for Qualcomm QMP Super Speed (SS) PHY found in SDX65. Signed-off-by: Rohit Agarwal Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/1649740652-17515-2-git-send-email-quic_rohiagar@quicinc.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index 5d7417c34c87..8b850c5ab116 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -58,6 +58,7 @@ properties: - qcom,sm8450-qmp-usb3-phy - qcom,sdx55-qmp-pcie-phy - qcom,sdx55-qmp-usb3-uni-phy + - qcom,sdx65-qmp-usb3-uni-phy reg: minItems: 1 @@ -164,6 +165,7 @@ allOf: contains: enum: - qcom,sdx55-qmp-usb3-uni-phy + - qcom,sdx65-qmp-usb3-uni-phy then: properties: clocks: -- cgit From 4b047ec3a15d1eda7a3d8526566796ad4f4930c0 Mon Sep 17 00:00:00 2001 From: David Rhodes Date: Wed, 13 Apr 2022 09:37:27 +0100 Subject: ASoC: cs35l41: Document CS35l41 External Boost Document internal and external boost feature for ASoC CS35L41. For internal boost the following properties are required: - cirrus,boost-peak-milliamp - cirrus,boost-ind-nanohenry - cirrus,boost-cap-microfarad For external boost, the GPIO1 must be configured as output, so the following properties are required: - cirrus,gpio1-src-select = <1> - cirrus,gpio1-output-enable Signed-off-by: David Rhodes Signed-off-by: Lucas Tanure Acked-by: Charles Keepax Reviewed-by: Rob Herring Acked-by: Mark Brown Link: https://lore.kernel.org/r/20220413083728.10730-16-tanureal@opensource.cirrus.com Signed-off-by: Takashi Iwai --- .../devicetree/bindings/sound/cirrus,cs35l41.yaml | 44 ++++++++++++++++++++-- 1 file changed, 41 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml index 3235702ce402..51d815d0c696 100644 --- a/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml +++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml @@ -75,6 +75,19 @@ properties: maximum: 3 default: 2 + cirrus,boost-type: + description: + Configures the type of Boost being used. + Internal boost requires boost-peak-milliamp, boost-ind-nanohenry and + boost-cap-microfarad. + External Boost must have GPIO1 as GPIO output. GPIO1 will be set high to + enable boost voltage. + 0 = Internal Boost + 1 = External Boost + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 1 + cirrus,gpio1-polarity-invert: description: Boolean which specifies whether the GPIO1 @@ -131,9 +144,32 @@ required: - compatible - reg - "#sound-dai-cells" - - cirrus,boost-peak-milliamp - - cirrus,boost-ind-nanohenry - - cirrus,boost-cap-microfarad + +allOf: + - if: + properties: + cirrus,boost-type: + const: 0 + then: + required: + - cirrus,boost-peak-milliamp + - cirrus,boost-ind-nanohenry + - cirrus,boost-cap-microfarad + else: + if: + properties: + cirrus,boost-type: + const: 1 + then: + required: + - cirrus,gpio1-output-enable + - cirrus,gpio1-src-select + properties: + cirrus,boost-peak-milliamp: false + cirrus,boost-ind-nanohenry: false + cirrus,boost-cap-microfarad: false + cirrus,gpio1-src-select: + enum: [1] additionalProperties: false @@ -150,6 +186,8 @@ examples: VA-supply = <&dummy_vreg>; VP-supply = <&dummy_vreg>; reset-gpios = <&gpio 110 0>; + + cirrus,boost-type = <0>; cirrus,boost-peak-milliamp = <4500>; cirrus,boost-ind-nanohenry = <1000>; cirrus,boost-cap-microfarad = <15>; -- cgit From 05d39fc06cee5b11b195d0d5fec55d01da2781cb Mon Sep 17 00:00:00 2001 From: Biju Das Date: Sat, 2 Apr 2022 08:32:34 +0100 Subject: dt-bindings: arm: renesas: Document Renesas RZ/G2UL SMARC EVK Document the Renesas SMARC EVK board which is based on the Renesas RZ/G2UL Type-1 (R9A07G043U11) SoC. The SMARC EVK consists of an RZ/G2UL Type-1 SoM module and a SMARC carrier board. The SoM module sits on top of the carrier board. Signed-off-by: Biju Das Link: https://lore.kernel.org/r/20220402073234.24625-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/arm/renesas.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index fa435d6fda77..f61807103867 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -405,6 +405,8 @@ properties: - description: RZ/G2UL (R9A07G043) items: + - enum: + - renesas,smarc-evk # SMARC EVK - enum: - renesas,r9a07g043u11 # RZ/G2UL Type-1 - renesas,r9a07g043u12 # RZ/G2UL Type-2 -- cgit From 862cd659a6fbac664f1fcdd7149046040a7a7e9c Mon Sep 17 00:00:00 2001 From: Veerasenareddy Burru Date: Tue, 12 Apr 2022 20:34:57 -0700 Subject: octeon_ep: Add driver framework and device initialization Add driver framework and device setup and initialization for Octeon PCI Endpoint NIC. Add implementation to load module, initilaize, register network device, cleanup and unload module. Signed-off-by: Veerasenareddy Burru Signed-off-by: Abhijit Ayarekar Signed-off-by: Satananda Burla Signed-off-by: David S. Miller --- .../networking/device_drivers/ethernet/index.rst | 1 + .../device_drivers/ethernet/marvell/octeon_ep.rst | 35 ++++++++++++++++++++++ 2 files changed, 36 insertions(+) create mode 100644 Documentation/networking/device_drivers/ethernet/marvell/octeon_ep.rst (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/ethernet/index.rst b/Documentation/networking/device_drivers/ethernet/index.rst index 6b5dc203da2b..21a97703421d 100644 --- a/Documentation/networking/device_drivers/ethernet/index.rst +++ b/Documentation/networking/device_drivers/ethernet/index.rst @@ -39,6 +39,7 @@ Contents: intel/iavf intel/ice marvell/octeontx2 + marvell/octeon_ep mellanox/mlx5 microsoft/netvsc neterion/s2io diff --git a/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep.rst new file mode 100644 index 000000000000..bc562c49011b --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep.rst @@ -0,0 +1,35 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +==================================================================== +Linux kernel networking driver for Marvell's Octeon PCI Endpoint NIC +==================================================================== + +Network driver for Marvell's Octeon PCI EndPoint NIC. +Copyright (c) 2020 Marvell International Ltd. + +Contents +======== + +- `Overview`_ +- `Supported Devices`_ +- `Interface Control`_ + +Overview +======== +This driver implements networking functionality of Marvell's Octeon PCI +EndPoint NIC. + +Supported Devices +================= +Currently, this driver support following devices: + * Network controller: Cavium, Inc. Device b200 + +Interface Control +================= +Network Interface control like changing mtu, link speed, link down/up are +done by writing command to mailbox command queue, a mailbox interface +implemented through a reserved region in BAR4. +This driver writes the commands into the mailbox and the firmware on the +Octeon device processes them. The firmware also sends unsolicited notifications +to driver for events suchs as link change, through notification queue +implemented as part of mailbox interface. -- cgit From dd45d96bd9d3a052f1497f3d813a76d8308af25e Mon Sep 17 00:00:00 2001 From: Vinod Koul Date: Wed, 6 Apr 2022 18:55:07 +0530 Subject: dt-bindings: dmaengine: qcom: gpi: add compatible for sm8350/sm8350 Add the compatible for newer qcom socs with gpi dma i.e qcom sm8350 and sm8450. Signed-off-by: Vinod Koul Reviewed-by: Bjorn Andersson Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220406132508.1029348-2-vkoul@kernel.org Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/qcom,gpi.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml index e614fe3187bb..67f046a4a442 100644 --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml @@ -22,6 +22,8 @@ properties: - qcom,sdm845-gpi-dma - qcom,sm8150-gpi-dma - qcom,sm8250-gpi-dma + - qcom,sm8350-gpi-dma + - qcom,sm8450-gpi-dma reg: maxItems: 1 -- cgit From a5c7a39f508ae1fd3288493b96dd26079bae41bf Mon Sep 17 00:00:00 2001 From: Petr Mladek Date: Tue, 5 Apr 2022 13:48:29 +0200 Subject: printk/index: Printk index feature documentation Document the printk index feature. The primary motivation is to explain that it is not creating KABI from particular printk() calls. Acked-by: Sergey Senozhatsky Reviewed-by: Chris Down Signed-off-by: Petr Mladek --- Documentation/core-api/index.rst | 1 + Documentation/core-api/printk-index.rst | 137 ++++++++++++++++++++++++++++++++ 2 files changed, 138 insertions(+) create mode 100644 Documentation/core-api/printk-index.rst (limited to 'Documentation') diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index 972d46a5ddf6..8a3fce1fe582 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -20,6 +20,7 @@ it. workqueue printk-basics printk-formats + printk-index symbol-namespaces Data structures and low-level utilities diff --git a/Documentation/core-api/printk-index.rst b/Documentation/core-api/printk-index.rst new file mode 100644 index 000000000000..3062f37d119b --- /dev/null +++ b/Documentation/core-api/printk-index.rst @@ -0,0 +1,137 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============ +Printk Index +============ + +There are many ways how to monitor the state of the system. One important +source of information is the system log. It provides a lot of information, +including more or less important warnings and error messages. + +There are monitoring tools that filter and take action based on messages +logged. + +The kernel messages are evolving together with the code. As a result, +particular kernel messages are not KABI and never will be! + +It is a huge challenge for maintaining the system log monitors. It requires +knowing what messages were updated in a particular kernel version and why. +Finding these changes in the sources would require non-trivial parsers. +Also it would require matching the sources with the binary kernel which +is not always trivial. Various changes might be backported. Various kernel +versions might be used on different monitored systems. + +This is where the printk index feature might become useful. It provides +a dump of printk formats used all over the source code used for the kernel +and modules on the running system. It is accessible at runtime via debugfs. + +The printk index helps to find changes in the message formats. Also it helps +to track the strings back to the kernel sources and the related commit. + + +User Interface +============== + +The index of printk formats are split in into separate files. The files are +named according to the binaries where the printk formats are built-in. There +is always "vmlinux" and optionally also modules, for example:: + + /sys/kernel/debug/printk/index/vmlinux + /sys/kernel/debug/printk/index/ext4 + /sys/kernel/debug/printk/index/scsi_mod + +Note that only loaded modules are shown. Also printk formats from a module +might appear in "vmlinux" when the module is built-in. + +The content is inspired by the dynamic debug interface and looks like:: + + $> head -1 /sys/kernel/debug/printk/index/vmlinux; shuf -n 5 vmlinux + # filename:line function "format" + <5> block/blk-settings.c:661 disk_stack_limits "%s: Warning: Device %s is misaligned\n" + <4> kernel/trace/trace.c:8296 trace_create_file "Could not create tracefs '%s' entry\n" + <6> arch/x86/kernel/hpet.c:144 _hpet_print_config "hpet: %s(%d):\n" + <6> init/do_mounts.c:605 prepare_namespace "Waiting for root device %s...\n" + <6> drivers/acpi/osl.c:1410 acpi_no_auto_serialize_setup "ACPI: auto-serialization disabled\n" + +, where the meaning is: + + - :level: log level value: 0-7 for particular severity, -1 as default, + 'c' as continuous line without an explicit log level + - :flags: optional flags: currently only 'c' for KERN_CONT + - :filename\:line: source filename and line number of the related + printk() call. Note that there are many wrappers, for example, + pr_warn(), pr_warn_once(), dev_warn(). + - :function: function name where the printk() call is used. + - :format: format string + +The extra information makes it a bit harder to find differences +between various kernels. Especially the line number might change +very often. On the other hand, it helps a lot to confirm that +it is the same string or find the commit that is responsible +for eventual changes. + + +printk() Is Not a Stable KABI +============================= + +Several developers are afraid that exporting all these implementation +details into the user space will transform particular printk() calls +into KABI. + +But it is exactly the opposite. printk() calls must _not_ be KABI. +And the printk index helps user space tools to deal with this. + + +Subsystem specific printk wrappers +================================== + +The printk index is generated using extra metadata that are stored in +a dedicated .elf section ".printk_index". It is achieved using macro +wrappers doing __printk_index_emit() together with the real printk() +call. The same technique is used also for the metadata used by +the dynamic debug feature. + +The metadata are stored for a particular message only when it is printed +using these special wrappers. It is implemented for the commonly +used printk() calls, including, for example, pr_warn(), or pr_once(). + +Additional changes are necessary for various subsystem specific wrappers +that call the original printk() via a common helper function. These needs +their own wrappers adding __printk_index_emit(). + +Only few subsystem specific wrappers have been updated so far, +for example, dev_printk(). As a result, the printk formats from +some subsystes can be missing in the printk index. + + +Subsystem specific prefix +========================= + +The macro pr_fmt() macro allows to define a prefix that is printed +before the string generated by the related printk() calls. + +Subsystem specific wrappers usually add even more complicated +prefixes. + +These prefixes can be stored into the printk index metadata +by an optional parameter of __printk_index_emit(). The debugfs +interface might then show the printk formats including these prefixes. +For example, drivers/acpi/osl.c contains:: + + #define pr_fmt(fmt) "ACPI: OSL: " fmt + + static int __init acpi_no_auto_serialize_setup(char *str) + { + acpi_gbl_auto_serialize_methods = FALSE; + pr_info("Auto-serialization disabled\n"); + + return 1; + } + +This results in the following printk index entry:: + + <6> drivers/acpi/osl.c:1410 acpi_no_auto_serialize_setup "ACPI: auto-serialization disabled\n" + +It helps matching messages from the real log with printk index. +Then the source file name, line number, and function name can +be used to match the string with the source code. -- cgit From 619fdc47f821139f312a87b397a75ff69ec6f8b6 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 11 Apr 2022 12:59:03 +0200 Subject: regulator: dt-bindings: qcom,rpmh: document h and k ID Document used PMIC IDs: 'h' (sm8450-hdk, sm8450-qrd) and 'k' (sc7280-crd). Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220411105903.230733-1-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml index e28ee9e46788..2714a790ff83 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml @@ -78,7 +78,7 @@ properties: RPMh resource name suffix used for the regulators found on this PMIC. $ref: /schemas/types.yaml#/definitions/string - enum: [a, b, c, d, e, f] + enum: [a, b, c, d, e, f, h, k] qcom,always-wait-for-ack: description: | -- cgit From 4d0d5c352303a318925ceb84a86818761aa6586b Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 13 Apr 2022 08:47:29 -0500 Subject: dt-bindings: hwmon: ti,tmp421: Fix type for 'ti,n-factor' 'ti,n-factor' is read as a 32-bit signed value, so the type and constraints are wrong. The same property is also defined for ti,tmp464 and is correct. The constraints should also not be under 'items' as this property is not an array. Cc: Jean Delvare Cc: Guenter Roeck Cc: Krzysztof Kozlowski Cc: linux-hwmon@vger.kernel.org Signed-off-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220413134729.3112190-1-robh@kernel.org Signed-off-by: Guenter Roeck --- Documentation/devicetree/bindings/hwmon/ti,tmp421.yaml | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp421.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp421.yaml index 36f649938fb7..a6f1fa75a67c 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp421.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp421.yaml @@ -58,10 +58,9 @@ patternProperties: description: | The value (two's complement) to be programmed in the channel specific N correction register. For remote channels only. - $ref: /schemas/types.yaml#/definitions/uint32 - items: - minimum: 0 - maximum: 255 + $ref: /schemas/types.yaml#/definitions/int32 + minimum: -128 + maximum: 127 required: - reg -- cgit From 75a3a99a5a9886af13be44e640cb415ebda80db2 Mon Sep 17 00:00:00 2001 From: Lukasz Luba Date: Mon, 21 Mar 2022 09:57:25 +0000 Subject: PM: EM: Change the order of arguments in the .active_power() callback The .active_power() callback passes the device pointer when it's called. Aligned with a convetion present in other subsystems and pass the 'dev' as a first argument. It looks more cleaner. Adjust all affected drivers which implement that API callback. Suggested-by: Ionela Voinescu Signed-off-by: Lukasz Luba Reviewed-by: Ionela Voinescu Signed-off-by: Rafael J. Wysocki --- Documentation/power/energy-model.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst index 49549aab41b4..fd29ed2506c0 100644 --- a/Documentation/power/energy-model.rst +++ b/Documentation/power/energy-model.rst @@ -181,8 +181,8 @@ EM framework:: -> drivers/cpufreq/foo_cpufreq.c - 01 static int est_power(unsigned long *mW, unsigned long *KHz, - 02 struct device *dev) + 01 static int est_power(struct device *dev, unsigned long *mW, + 02 unsigned long *KHz) 03 { 04 long freq, power; 05 -- cgit From 015f569c4649fe9595ed465dc8e4301d34937f8f Mon Sep 17 00:00:00 2001 From: Lukasz Luba Date: Mon, 21 Mar 2022 09:57:27 +0000 Subject: Documentation: EM: Add artificial EM registration description Add description about new artificial EM registration and use cases. Update also the documentation with the new .get_cost() callback description and usage. Signed-off-by: Lukasz Luba Reviewed-by: Ionela Voinescu Signed-off-by: Rafael J. Wysocki --- Documentation/power/energy-model.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst index fd29ed2506c0..feb257b7f350 100644 --- a/Documentation/power/energy-model.rst +++ b/Documentation/power/energy-model.rst @@ -123,6 +123,26 @@ allows a platform to register EM power values which are reflecting total power (static + dynamic). These power values might be coming directly from experiments and measurements. +Registration of 'artificial' EM +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +There is an option to provide a custom callback for drivers missing detailed +knowledge about power value for each performance state. The callback +.get_cost() is optional and provides the 'cost' values used by the EAS. +This is useful for platforms that only provide information on relative +efficiency between CPU types, where one could use the information to +create an abstract power model. But even an abstract power model can +sometimes be hard to fit in, given the input power value size restrictions. +The .get_cost() allows to provide the 'cost' values which reflect the +efficiency of the CPUs. This would allow to provide EAS information which +has different relation than what would be forced by the EM internal +formulas calculating 'cost' values. To register an EM for such platform, the +driver must set the flag 'milliwatts' to 0, provide .get_power() callback +and provide .get_cost() callback. The EM framework would handle such platform +properly during registration. A flag EM_PERF_DOMAIN_ARTIFICIAL is set for such +platform. Special care should be taken by other frameworks which are using EM +to test and treat this flag properly. + Registration of 'simple' EM ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit From 4a6471e65050fef99559354bac97b551310f985c Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 12 Apr 2022 12:50:13 +0200 Subject: ARM: dts: at91: use generic node name for dataflash The node names should be generic, so use "flash" for dataflash nodes and for cfi-flash. Suggested-by: Tudor Ambarus Signed-off-by: Krzysztof Kozlowski Reviewed-by: Tudor Ambarus Signed-off-by: Nicolas Ferre Link: https://lore.kernel.org/r/20220412105013.249793-1-krzysztof.kozlowski@linaro.org --- Documentation/devicetree/bindings/mfd/atmel-flexcom.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt index 692300117c64..9d837535637b 100644 --- a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt +++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt @@ -54,7 +54,7 @@ flexcom@f8034000 { clock-names = "spi_clk"; atmel,fifo-size = <32>; - mtd_dataflash@0 { + flash@0 { compatible = "atmel,at25f512b"; reg = <0>; spi-max-frequency = <20000000>; -- cgit From cbabf03c3ef3cce74a97f140cf57611a9e8a21bc Mon Sep 17 00:00:00 2001 From: Dov Murik Date: Tue, 12 Apr 2022 21:21:25 +0000 Subject: virt: Add efi_secret module to expose confidential computing secrets The new efi_secret module exposes the confidential computing (coco) EFI secret area via securityfs interface. When the module is loaded (and securityfs is mounted, typically under /sys/kernel/security), a "secrets/coco" directory is created in securityfs. In it, a file is created for each secret entry. The name of each such file is the GUID of the secret entry, and its content is the secret data. This allows applications running in a confidential computing setting to read secrets provided by the guest owner via a secure secret injection mechanism (such as AMD SEV's LAUNCH_SECRET command). Removing (unlinking) files in the "secrets/coco" directory will zero out the secret in memory, and remove the filesystem entry. If the module is removed and loaded again, that secret will not appear in the filesystem. Signed-off-by: Dov Murik Reviewed-by: Gerd Hoffmann Link: https://lore.kernel.org/r/20220412212127.154182-3-dovmurik@linux.ibm.com Signed-off-by: Ard Biesheuvel --- Documentation/ABI/testing/securityfs-secrets-coco | 51 +++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 Documentation/ABI/testing/securityfs-secrets-coco (limited to 'Documentation') diff --git a/Documentation/ABI/testing/securityfs-secrets-coco b/Documentation/ABI/testing/securityfs-secrets-coco new file mode 100644 index 000000000000..f2b6909155f9 --- /dev/null +++ b/Documentation/ABI/testing/securityfs-secrets-coco @@ -0,0 +1,51 @@ +What: security/secrets/coco +Date: February 2022 +Contact: Dov Murik +Description: + Exposes confidential computing (coco) EFI secrets to + userspace via securityfs. + + EFI can declare memory area used by confidential computing + platforms (such as AMD SEV and SEV-ES) for secret injection by + the Guest Owner during VM's launch. The secrets are encrypted + by the Guest Owner and decrypted inside the trusted enclave, + and therefore are not readable by the untrusted host. + + The efi_secret module exposes the secrets to userspace. Each + secret appears as a file under /secrets/coco, + where the filename is the GUID of the entry in the secrets + table. This module is loaded automatically by the EFI driver + if the EFI secret area is populated. + + Two operations are supported for the files: read and unlink. + Reading the file returns the content of secret entry. + Unlinking the file overwrites the secret data with zeroes and + removes the entry from the filesystem. A secret cannot be read + after it has been unlinked. + + For example, listing the available secrets:: + + # modprobe efi_secret + # ls -l /sys/kernel/security/secrets/coco + -r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-06879ce3da0b + -r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-d3a0b54312c6 + -r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-ff17f78864d2 + -r--r----- 1 root root 0 Jun 28 11:54 e6f5a162-d67f-4750-a67c-5d065f2a9910 + + Reading the secret data by reading a file:: + + # cat /sys/kernel/security/secrets/coco/e6f5a162-d67f-4750-a67c-5d065f2a9910 + the-content-of-the-secret-data + + Wiping a secret by unlinking a file:: + + # rm /sys/kernel/security/secrets/coco/e6f5a162-d67f-4750-a67c-5d065f2a9910 + # ls -l /sys/kernel/security/secrets/coco + -r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-06879ce3da0b + -r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-d3a0b54312c6 + -r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-ff17f78864d2 + + Note: The binary format of the secrets table injected by the + Guest Owner is described in + drivers/virt/coco/efi_secret/efi_secret.c under "Structure of + the EFI secret area". -- cgit From 7419995a331c24a239bc0bce5df24360544c7038 Mon Sep 17 00:00:00 2001 From: Dov Murik Date: Tue, 12 Apr 2022 21:21:27 +0000 Subject: docs: security: Add secrets/coco documentation Add documentation for the efi_secret module which allows access to Confidential Computing injected secrets. Signed-off-by: Dov Murik Reviewed-by: Gerd Hoffmann Link: https://lore.kernel.org/r/20220412212127.154182-5-dovmurik@linux.ibm.com Signed-off-by: Ard Biesheuvel --- Documentation/security/index.rst | 1 + Documentation/security/secrets/coco.rst | 103 +++++++++++++++++++++++++++++++ Documentation/security/secrets/index.rst | 9 +++ 3 files changed, 113 insertions(+) create mode 100644 Documentation/security/secrets/coco.rst create mode 100644 Documentation/security/secrets/index.rst (limited to 'Documentation') diff --git a/Documentation/security/index.rst b/Documentation/security/index.rst index 16335de04e8c..6ed8d2fa6f9e 100644 --- a/Documentation/security/index.rst +++ b/Documentation/security/index.rst @@ -17,3 +17,4 @@ Security Documentation tpm/index digsig landlock + secrets/index diff --git a/Documentation/security/secrets/coco.rst b/Documentation/security/secrets/coco.rst new file mode 100644 index 000000000000..262e7abb1b24 --- /dev/null +++ b/Documentation/security/secrets/coco.rst @@ -0,0 +1,103 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================== +Confidential Computing secrets +============================== + +This document describes how Confidential Computing secret injection is handled +from the firmware to the operating system, in the EFI driver and the efi_secret +kernel module. + + +Introduction +============ + +Confidential Computing (coco) hardware such as AMD SEV (Secure Encrypted +Virtualization) allows guest owners to inject secrets into the VMs +memory without the host/hypervisor being able to read them. In SEV, +secret injection is performed early in the VM launch process, before the +guest starts running. + +The efi_secret kernel module allows userspace applications to access these +secrets via securityfs. + + +Secret data flow +================ + +The guest firmware may reserve a designated memory area for secret injection, +and publish its location (base GPA and length) in the EFI configuration table +under a ``LINUX_EFI_COCO_SECRET_AREA_GUID`` entry +(``adf956ad-e98c-484c-ae11-b51c7d336447``). This memory area should be marked +by the firmware as ``EFI_RESERVED_TYPE``, and therefore the kernel should not +be use it for its own purposes. + +During the VM's launch, the virtual machine manager may inject a secret to that +area. In AMD SEV and SEV-ES this is performed using the +``KVM_SEV_LAUNCH_SECRET`` command (see [sev]_). The strucutre of the injected +Guest Owner secret data should be a GUIDed table of secret values; the binary +format is described in ``drivers/virt/coco/efi_secret/efi_secret.c`` under +"Structure of the EFI secret area". + +On kernel start, the kernel's EFI driver saves the location of the secret area +(taken from the EFI configuration table) in the ``efi.coco_secret`` field. +Later it checks if the secret area is populated: it maps the area and checks +whether its content begins with ``EFI_SECRET_TABLE_HEADER_GUID`` +(``1e74f542-71dd-4d66-963e-ef4287ff173b``). If the secret area is populated, +the EFI driver will autoload the efi_secret kernel module, which exposes the +secrets to userspace applications via securityfs. The details of the +efi_secret filesystem interface are in [secrets-coco-abi]_. + + +Application usage example +========================= + +Consider a guest performing computations on encrypted files. The Guest Owner +provides the decryption key (= secret) using the secret injection mechanism. +The guest application reads the secret from the efi_secret filesystem and +proceeds to decrypt the files into memory and then performs the needed +computations on the content. + +In this example, the host can't read the files from the disk image +because they are encrypted. Host can't read the decryption key because +it is passed using the secret injection mechanism (= secure channel). +Host can't read the decrypted content from memory because it's a +confidential (memory-encrypted) guest. + +Here is a simple example for usage of the efi_secret module in a guest +to which an EFI secret area with 4 secrets was injected during launch:: + + # ls -la /sys/kernel/security/secrets/coco + total 0 + drwxr-xr-x 2 root root 0 Jun 28 11:54 . + drwxr-xr-x 3 root root 0 Jun 28 11:54 .. + -r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-06879ce3da0b + -r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-d3a0b54312c6 + -r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-ff17f78864d2 + -r--r----- 1 root root 0 Jun 28 11:54 e6f5a162-d67f-4750-a67c-5d065f2a9910 + + # hd /sys/kernel/security/secrets/coco/e6f5a162-d67f-4750-a67c-5d065f2a9910 + 00000000 74 68 65 73 65 2d 61 72 65 2d 74 68 65 2d 6b 61 |these-are-the-ka| + 00000010 74 61 2d 73 65 63 72 65 74 73 00 01 02 03 04 05 |ta-secrets......| + 00000020 06 07 |..| + 00000022 + + # rm /sys/kernel/security/secrets/coco/e6f5a162-d67f-4750-a67c-5d065f2a9910 + + # ls -la /sys/kernel/security/secrets/coco + total 0 + drwxr-xr-x 2 root root 0 Jun 28 11:55 . + drwxr-xr-x 3 root root 0 Jun 28 11:54 .. + -r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-06879ce3da0b + -r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-d3a0b54312c6 + -r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-ff17f78864d2 + + +References +========== + +See [sev-api-spec]_ for more info regarding SEV ``LAUNCH_SECRET`` operation. + +.. [sev] Documentation/virt/kvm/amd-memory-encryption.rst +.. [secrets-coco-abi] Documentation/ABI/testing/securityfs-secrets-coco +.. [sev-api-spec] https://www.amd.com/system/files/TechDocs/55766_SEV-KM_API_Specification.pdf diff --git a/Documentation/security/secrets/index.rst b/Documentation/security/secrets/index.rst new file mode 100644 index 000000000000..ced34e9c43bd --- /dev/null +++ b/Documentation/security/secrets/index.rst @@ -0,0 +1,9 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +Secrets documentation +===================== + +.. toctree:: + + coco -- cgit From c24a950ec7d60c4da91dc3f273295c7f438b531e Mon Sep 17 00:00:00 2001 From: Peter Gonda Date: Thu, 7 Apr 2022 14:02:33 -0700 Subject: KVM, SEV: Add KVM_EXIT_SHUTDOWN metadata for SEV-ES If an SEV-ES guest requests termination, exit to userspace with KVM_EXIT_SYSTEM_EVENT and a dedicated SEV_TERM type instead of -EINVAL so that userspace can take appropriate action. See AMD's GHCB spec section '4.1.13 Termination Request' for more details. Suggested-by: Sean Christopherson Suggested-by: Paolo Bonzini Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Peter Gonda Reported-by: kernel test robot Message-Id: <20220407210233.782250-1-pgonda@google.com> [Add documentatino. - Paolo] Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index e7a0dfdc0178..72183ae628f7 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6088,8 +6088,12 @@ should put the acknowledged interrupt vector into the 'epr' field. #define KVM_SYSTEM_EVENT_SHUTDOWN 1 #define KVM_SYSTEM_EVENT_RESET 2 #define KVM_SYSTEM_EVENT_CRASH 3 + #define KVM_SYSTEM_EVENT_SEV_TERM 4 + #define KVM_SYSTEM_EVENT_NDATA_VALID (1u << 31) __u32 type; + __u32 ndata; __u64 flags; + __u64 data[16]; } system_event; If exit_reason is KVM_EXIT_SYSTEM_EVENT then the vcpu has triggered @@ -6099,7 +6103,7 @@ HVC instruction based PSCI call from the vcpu. The 'type' field describes the system-level event type. The 'flags' field describes architecture specific flags for the system-level event. -Valid values for 'type' are: +Valid values for bits 30:0 of 'type' are: - KVM_SYSTEM_EVENT_SHUTDOWN -- the guest has requested a shutdown of the VM. Userspace is not obliged to honour this, and if it does honour @@ -6112,12 +6116,18 @@ Valid values for 'type' are: has requested a crash condition maintenance. Userspace can choose to ignore the request, or to gather VM memory core dump and/or reset/shutdown of the VM. + - KVM_SYSTEM_EVENT_SEV_TERM -- an AMD SEV guest requested termination. + The guest physical address of the guest's GHCB is stored in `data[0]`. Valid flags are: - KVM_SYSTEM_EVENT_RESET_FLAG_PSCI_RESET2 (arm64 only) -- the guest issued a SYSTEM_RESET2 call according to v1.1 of the PSCI specification. +Extra data for this event is stored in the `data[]` array, up to index +`ndata-1` included, if bit 31 is set in `type`. The data depends on the +`type` field. There is no extra data if bit 31 is clear or `ndata` is zero. + :: /* KVM_EXIT_IOAPIC_EOI */ -- cgit From e802ca757b29ef98d9e155dec686a2ec8f832b65 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Wed, 13 Apr 2022 14:59:12 +0300 Subject: ACPI: docs: enumeration: Unify Package () for properties (part 2) Unify Package () representation for properties: - make them one line where it's possible - add spaces between parentheses and curly braces - drop the explicit size of package Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki --- Documentation/firmware-guide/acpi/enumeration.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index 47fb4d6d4557..6b62425ef9cd 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -167,8 +167,7 @@ The table below shows an example of its usage:: Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { - Package () {"interrupt-names", - Package (2) {"default", "alert"}}, + Package () { "interrupt-names", Package () { "default", "alert" } }, } ... }) -- cgit From fee6de80bdd3df976a43f3092a165cb43c072f20 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Thu, 7 Apr 2022 12:30:16 +0200 Subject: dt-bindings: nvmem: snvs-lpgpr: Add i.MX8M compatible strings Add compatible strings for i.MX8M(Q), i.MX8M Mini, i.MX8M Nano, i.MX8M Plus. All these SoCs have the SNVS LPGPR registers and they are at the same offset as on i.MX7D. Signed-off-by: Marek Vasut Cc: Anson Huang Cc: Fabio Estevam Cc: Oleksij Rempel Cc: Peng Fan Cc: Rob Herring Cc: Shawn Guo Cc: NXP Linux Team Cc: devicetree@vger.kernel.org To: linux-arm-kernel@lists.infradead.org Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220407103016.16543-1-marex@denx.de --- Documentation/devicetree/bindings/nvmem/snvs-lpgpr.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.yaml b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.yaml index c819f0e90320..e374aa7891ae 100644 --- a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.yaml +++ b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.yaml @@ -15,6 +15,10 @@ properties: - fsl,imx6q-snvs-lpgpr - fsl,imx6ul-snvs-lpgpr - fsl,imx7d-snvs-lpgpr + - fsl,imx8mm-snvs-lpgpr + - fsl,imx8mn-snvs-lpgpr + - fsl,imx8mp-snvs-lpgpr + - fsl,imx8mq-snvs-lpgpr required: - compatible -- cgit From 376eb490c7811b026ebfed32280688620dd1c0ca Mon Sep 17 00:00:00 2001 From: Drew Fustini Date: Sat, 9 Apr 2022 14:12:14 -0700 Subject: dt-bindings: wkup-m3-ipc: Add vtt toggle gpio pin property Document Wakeup M3 IPC property that indicates a GPIO pin is connected to the enable pin on DDR VTT regulator and can be toggled during low power mode transitions. Signed-off-by: Dave Gerlach [dfustini: converted to YAML, removed unnecessary "ti,needs-vtt-toggle"] Signed-off-by: Drew Fustini Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220409211215.2529387-2-dfustini@baylibre.com --- Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml b/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml index d855c01ce61c..7f4a75c5fcaa 100644 --- a/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml +++ b/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml @@ -24,6 +24,14 @@ description: |+ A wkup_m3_ipc device node is used to represent the IPC registers within an SoC. + Support for VTT Toggle + ================================== + On some boards like the AM335x EVM-SK and the AM437x GP EVM, a GPIO pin is + connected to the enable pin on the DDR VTT regulator. This allows the + regulator to be disabled upon suspend and enabled upon resume. Please note + that the GPIO pin must be part of the GPIO0 module as only this GPIO module + is in the wakeup power domain. + properties: compatible: enum: @@ -51,6 +59,10 @@ properties: mbox_wkupm3 child node. maxItems: 1 + ti,vtt-gpio-pin: + $ref: /schemas/types.yaml#/definitions/uint32 + description: GPIO pin connected to enable pin on VTT regulator + required: - compatible - reg @@ -76,6 +88,7 @@ examples: interrupts = <78>; ti,rproc = <&wkup_m3>; mboxes = <&mailbox &mbox_wkupm3>; + ti,vtt-gpio-pin = <7>; }; }; ... -- cgit From 2142c27ef06bf8f9c0bd784395ea5aa1924cad49 Mon Sep 17 00:00:00 2001 From: Brian Norris Date: Tue, 8 Mar 2022 11:08:47 -0800 Subject: dt-bindings: devfreq: rk3399_dmc: Convert to YAML I want to add, deprecate, and bugfix some properties, as well as add the first users. This is easier with a proper schema. The transformation is mostly straightforward, plus a few notable tweaks: * Renamed rockchip,dram_speed_bin to rockchip,ddr3_speed_bin. The driver code and the example matched, but the description was different. I went with the implementation. Note that this property is also slated for deprecation/deletion in the subsequent patches. * Drop upthreshold and downdifferential properties from the example. These were undocumented (so, wouldn't pass validation), but were representing software properties (governor tweaks). I drop them from the driver in subsequent patches. * Rename clock from pclk_ddr_mon to dmc_clk. The driver, DT example, and all downstream users matched -- the binding definition was the exception. Anyway, "dmc_clk" is a more appropriately generic name. * Choose a better filename and location (this is a memory controller). Signed-off-by: Brian Norris Reviewed-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Chanwoo Choi --- .../devicetree/bindings/devfreq/rk3399_dmc.txt | 212 -------------- .../memory-controllers/rockchip,rk3399-dmc.yaml | 306 +++++++++++++++++++++ 2 files changed, 306 insertions(+), 212 deletions(-) delete mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt deleted file mode 100644 index 58fc8a6cebc7..000000000000 --- a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt +++ /dev/null @@ -1,212 +0,0 @@ -* Rockchip rk3399 DMC (Dynamic Memory Controller) device - -Required properties: -- compatible: Must be "rockchip,rk3399-dmc". -- devfreq-events: Node to get DDR loading, Refer to - Documentation/devicetree/bindings/devfreq/event/ - rockchip-dfi.txt -- clocks: Phandles for clock specified in "clock-names" property -- clock-names : The name of clock used by the DFI, must be - "pclk_ddr_mon"; -- operating-points-v2: Refer to Documentation/devicetree/bindings/opp/opp-v2.yaml - for details. -- center-supply: DMC supply node. -- status: Marks the node enabled/disabled. -- rockchip,pmu: Phandle to the syscon managing the "PMU general register - files". - -Optional properties: -- interrupts: The CPU interrupt number. The interrupt specifier - format depends on the interrupt controller. - It should be a DCF interrupt. When DDR DVFS finishes - a DCF interrupt is triggered. -- rockchip,pmu: Phandle to the syscon managing the "PMU general register - files". - -Following properties relate to DDR timing: - -- rockchip,dram_speed_bin : Value reference include/dt-bindings/clock/rk3399-ddr.h, - it selects the DDR3 cl-trp-trcd type. It must be - set according to "Speed Bin" in DDR3 datasheet, - DO NOT use a smaller "Speed Bin" than specified - for the DDR3 being used. - -- rockchip,pd_idle : Configure the PD_IDLE value. Defines the - power-down idle period in which memories are - placed into power-down mode if bus is idle - for PD_IDLE DFI clock cycles. - -- rockchip,sr_idle : Configure the SR_IDLE value. Defines the - self-refresh idle period in which memories are - placed into self-refresh mode if bus is idle - for SR_IDLE * 1024 DFI clock cycles (DFI - clocks freq is half of DRAM clock), default - value is "0". - -- rockchip,sr_mc_gate_idle : Defines the memory self-refresh and controller - clock gating idle period. Memories are placed - into self-refresh mode and memory controller - clock arg gating started if bus is idle for - sr_mc_gate_idle*1024 DFI clock cycles. - -- rockchip,srpd_lite_idle : Defines the self-refresh power down idle - period in which memories are placed into - self-refresh power down mode if bus is idle - for srpd_lite_idle * 1024 DFI clock cycles. - This parameter is for LPDDR4 only. - -- rockchip,standby_idle : Defines the standby idle period in which - memories are placed into self-refresh mode. - The controller, pi, PHY and DRAM clock will - be gated if bus is idle for standby_idle * DFI - clock cycles. - -- rockchip,dram_dll_dis_freq : Defines the DDR3 DLL bypass frequency in MHz. - When DDR frequency is less than DRAM_DLL_DISB_FREQ, - DDR3 DLL will be bypassed. Note: if DLL was bypassed, - the odt will also stop working. - -- rockchip,phy_dll_dis_freq : Defines the PHY dll bypass frequency in - MHz (Mega Hz). When DDR frequency is less than - DRAM_DLL_DISB_FREQ, PHY DLL will be bypassed. - Note: PHY DLL and PHY ODT are independent. - -- rockchip,ddr3_odt_dis_freq : When the DRAM type is DDR3, this parameter defines - the ODT disable frequency in MHz (Mega Hz). - when the DDR frequency is less then ddr3_odt_dis_freq, - the ODT on the DRAM side and controller side are - both disabled. - -- rockchip,ddr3_drv : When the DRAM type is DDR3, this parameter defines - the DRAM side driver strength in ohms. Default - value is 40. - -- rockchip,ddr3_odt : When the DRAM type is DDR3, this parameter defines - the DRAM side ODT strength in ohms. Default value - is 120. - -- rockchip,phy_ddr3_ca_drv : When the DRAM type is DDR3, this parameter defines - the phy side CA line (incluing command line, - address line and clock line) driver strength. - Default value is 40. - -- rockchip,phy_ddr3_dq_drv : When the DRAM type is DDR3, this parameter defines - the PHY side DQ line (including DQS/DQ/DM line) - driver strength. Default value is 40. - -- rockchip,phy_ddr3_odt : When the DRAM type is DDR3, this parameter defines - the PHY side ODT strength. Default value is 240. - -- rockchip,lpddr3_odt_dis_freq : When the DRAM type is LPDDR3, this parameter defines - then ODT disable frequency in MHz (Mega Hz). - When DDR frequency is less then ddr3_odt_dis_freq, - the ODT on the DRAM side and controller side are - both disabled. - -- rockchip,lpddr3_drv : When the DRAM type is LPDDR3, this parameter defines - the DRAM side driver strength in ohms. Default - value is 34. - -- rockchip,lpddr3_odt : When the DRAM type is LPDDR3, this parameter defines - the DRAM side ODT strength in ohms. Default value - is 240. - -- rockchip,phy_lpddr3_ca_drv : When the DRAM type is LPDDR3, this parameter defines - the PHY side CA line (including command line, - address line and clock line) driver strength. - Default value is 40. - -- rockchip,phy_lpddr3_dq_drv : When the DRAM type is LPDDR3, this parameter defines - the PHY side DQ line (including DQS/DQ/DM line) - driver strength. Default value is 40. - -- rockchip,phy_lpddr3_odt : When dram type is LPDDR3, this parameter define - the phy side odt strength, default value is 240. - -- rockchip,lpddr4_odt_dis_freq : When the DRAM type is LPDDR4, this parameter - defines the ODT disable frequency in - MHz (Mega Hz). When the DDR frequency is less then - ddr3_odt_dis_freq, the ODT on the DRAM side and - controller side are both disabled. - -- rockchip,lpddr4_drv : When the DRAM type is LPDDR4, this parameter defines - the DRAM side driver strength in ohms. Default - value is 60. - -- rockchip,lpddr4_dq_odt : When the DRAM type is LPDDR4, this parameter defines - the DRAM side ODT on DQS/DQ line strength in ohms. - Default value is 40. - -- rockchip,lpddr4_ca_odt : When the DRAM type is LPDDR4, this parameter defines - the DRAM side ODT on CA line strength in ohms. - Default value is 40. - -- rockchip,phy_lpddr4_ca_drv : When the DRAM type is LPDDR4, this parameter defines - the PHY side CA line (including command address - line) driver strength. Default value is 40. - -- rockchip,phy_lpddr4_ck_cs_drv : When the DRAM type is LPDDR4, this parameter defines - the PHY side clock line and CS line driver - strength. Default value is 80. - -- rockchip,phy_lpddr4_dq_drv : When the DRAM type is LPDDR4, this parameter defines - the PHY side DQ line (including DQS/DQ/DM line) - driver strength. Default value is 80. - -- rockchip,phy_lpddr4_odt : When the DRAM type is LPDDR4, this parameter defines - the PHY side ODT strength. Default value is 60. - -Example: - dmc_opp_table: dmc_opp_table { - compatible = "operating-points-v2"; - - opp00 { - opp-hz = /bits/ 64 <300000000>; - opp-microvolt = <900000>; - }; - opp01 { - opp-hz = /bits/ 64 <666000000>; - opp-microvolt = <900000>; - }; - }; - - dmc: dmc { - compatible = "rockchip,rk3399-dmc"; - devfreq-events = <&dfi>; - interrupts = ; - clocks = <&cru SCLK_DDRC>; - clock-names = "dmc_clk"; - operating-points-v2 = <&dmc_opp_table>; - center-supply = <&ppvar_centerlogic>; - upthreshold = <15>; - downdifferential = <10>; - rockchip,ddr3_speed_bin = <21>; - rockchip,pd_idle = <0x40>; - rockchip,sr_idle = <0x2>; - rockchip,sr_mc_gate_idle = <0x3>; - rockchip,srpd_lite_idle = <0x4>; - rockchip,standby_idle = <0x2000>; - rockchip,dram_dll_dis_freq = <300>; - rockchip,phy_dll_dis_freq = <125>; - rockchip,auto_pd_dis_freq = <666>; - rockchip,ddr3_odt_dis_freq = <333>; - rockchip,ddr3_drv = <40>; - rockchip,ddr3_odt = <120>; - rockchip,phy_ddr3_ca_drv = <40>; - rockchip,phy_ddr3_dq_drv = <40>; - rockchip,phy_ddr3_odt = <240>; - rockchip,lpddr3_odt_dis_freq = <333>; - rockchip,lpddr3_drv = <34>; - rockchip,lpddr3_odt = <240>; - rockchip,phy_lpddr3_ca_drv = <40>; - rockchip,phy_lpddr3_dq_drv = <40>; - rockchip,phy_lpddr3_odt = <240>; - rockchip,lpddr4_odt_dis_freq = <333>; - rockchip,lpddr4_drv = <60>; - rockchip,lpddr4_dq_odt = <40>; - rockchip,lpddr4_ca_odt = <40>; - rockchip,phy_lpddr4_ca_drv = <40>; - rockchip,phy_lpddr4_ck_cs_drv = <80>; - rockchip,phy_lpddr4_dq_drv = <80>; - rockchip,phy_lpddr4_odt = <60>; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml new file mode 100644 index 000000000000..b32c03cb0c68 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml @@ -0,0 +1,306 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# %YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/rockchip,rk3399-dmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip rk3399 DMC (Dynamic Memory Controller) device + +maintainers: + - Brian Norris + +properties: + compatible: + enum: + - rockchip,rk3399-dmc + + devfreq-events: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Node to get DDR loading. Refer to + Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt. + + clocks: + maxItems: 1 + + clock-names: + items: + - const: dmc_clk + + operating-points-v2: true + + center-supply: + description: + DMC regulator supply. + + rockchip,pmu: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon managing the "PMU general register files". + + interrupts: + maxItems: 1 + description: + The CPU interrupt number. It should be a DCF interrupt. When DDR DVFS + finishes, a DCF interrupt is triggered. + + rockchip,ddr3_speed_bin: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + For values, reference include/dt-bindings/clock/rk3399-ddr.h. Selects the + DDR3 cl-trp-trcd type. It must be set according to "Speed Bin" in DDR3 + datasheet; DO NOT use a smaller "Speed Bin" than specified for the DDR3 + being used. + + rockchip,pd_idle: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Configure the PD_IDLE value. Defines the power-down idle period in which + memories are placed into power-down mode if bus is idle for PD_IDLE DFI + clock cycles. + + rockchip,sr_idle: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Configure the SR_IDLE value. Defines the self-refresh idle period in + which memories are placed into self-refresh mode if bus is idle for + SR_IDLE * 1024 DFI clock cycles (DFI clocks freq is half of DRAM clock). + default: 0 + + rockchip,sr_mc_gate_idle: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Defines the memory self-refresh and controller clock gating idle period. + Memories are placed into self-refresh mode and memory controller clock + arg gating started if bus is idle for sr_mc_gate_idle*1024 DFI clock + cycles. + + rockchip,srpd_lite_idle: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Defines the self-refresh power down idle period in which memories are + placed into self-refresh power down mode if bus is idle for + srpd_lite_idle * 1024 DFI clock cycles. This parameter is for LPDDR4 + only. + + rockchip,standby_idle: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Defines the standby idle period in which memories are placed into + self-refresh mode. The controller, pi, PHY and DRAM clock will be gated + if bus is idle for standby_idle * DFI clock cycles. + + rockchip,dram_dll_dis_freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Defines the DDR3 DLL bypass frequency in MHz. When DDR frequency is less + than DRAM_DLL_DISB_FREQ, DDR3 DLL will be bypassed. + Note: if DLL was bypassed, the odt will also stop working. + + rockchip,phy_dll_dis_freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Defines the PHY dll bypass frequency in MHz (Mega Hz). When DDR frequency + is less than DRAM_DLL_DISB_FREQ, PHY DLL will be bypassed. + Note: PHY DLL and PHY ODT are independent. + + rockchip,auto_pd_dis_freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Defines the auto PD disable frequency in MHz. + + rockchip,ddr3_odt_dis_freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is DDR3, this parameter defines the ODT disable + frequency in MHz (Mega Hz). When the DDR frequency is less then + ddr3_odt_dis_freq, the ODT on the DRAM side and controller side are both + disabled. + + rockchip,ddr3_drv: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is DDR3, this parameter defines the DRAM side drive + strength in ohms. + default: 40 + + rockchip,ddr3_odt: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is DDR3, this parameter defines the DRAM side ODT + strength in ohms. + default: 120 + + rockchip,phy_ddr3_ca_drv: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is DDR3, this parameter defines the phy side CA line + (incluing command line, address line and clock line) drive strength. + default: 40 + + rockchip,phy_ddr3_dq_drv: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is DDR3, this parameter defines the PHY side DQ line + (including DQS/DQ/DM line) drive strength. + default: 40 + + rockchip,phy_ddr3_odt: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is DDR3, this parameter defines the PHY side ODT + strength. + default: 240 + + rockchip,lpddr3_odt_dis_freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is LPDDR3, this parameter defines then ODT disable + frequency in MHz (Mega Hz). When DDR frequency is less then + ddr3_odt_dis_freq, the ODT on the DRAM side and controller side are both + disabled. + + rockchip,lpddr3_drv: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is LPDDR3, this parameter defines the DRAM side drive + strength in ohms. + default: 34 + + rockchip,lpddr3_odt: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is LPDDR3, this parameter defines the DRAM side ODT + strength in ohms. + default: 240 + + rockchip,phy_lpddr3_ca_drv: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is LPDDR3, this parameter defines the PHY side CA line + (including command line, address line and clock line) drive strength. + default: 40 + + rockchip,phy_lpddr3_dq_drv: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is LPDDR3, this parameter defines the PHY side DQ line + (including DQS/DQ/DM line) drive strength. + default: 40 + + rockchip,phy_lpddr3_odt: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When dram type is LPDDR3, this parameter define the phy side odt + strength, default value is 240. + + rockchip,lpddr4_odt_dis_freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is LPDDR4, this parameter defines the ODT disable + frequency in MHz (Mega Hz). When the DDR frequency is less then + ddr3_odt_dis_freq, the ODT on the DRAM side and controller side are both + disabled. + + rockchip,lpddr4_drv: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is LPDDR4, this parameter defines the DRAM side drive + strength in ohms. + default: 60 + + rockchip,lpddr4_dq_odt: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is LPDDR4, this parameter defines the DRAM side ODT on + DQS/DQ line strength in ohms. + default: 40 + + rockchip,lpddr4_ca_odt: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is LPDDR4, this parameter defines the DRAM side ODT on + CA line strength in ohms. + default: 40 + + rockchip,phy_lpddr4_ca_drv: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is LPDDR4, this parameter defines the PHY side CA line + (including command address line) drive strength. + default: 40 + + rockchip,phy_lpddr4_ck_cs_drv: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is LPDDR4, this parameter defines the PHY side clock + line and CS line drive strength. + default: 80 + + rockchip,phy_lpddr4_dq_drv: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is LPDDR4, this parameter defines the PHY side DQ line + (including DQS/DQ/DM line) drive strength. + default: 80 + + rockchip,phy_lpddr4_odt: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the DRAM type is LPDDR4, this parameter defines the PHY side ODT + strength. + default: 60 + +required: + - compatible + - devfreq-events + - clocks + - clock-names + - operating-points-v2 + - center-supply + +additionalProperties: false + +examples: + - | + #include + #include + memory-controller { + compatible = "rockchip,rk3399-dmc"; + devfreq-events = <&dfi>; + rockchip,pmu = <&pmu>; + interrupts = ; + clocks = <&cru SCLK_DDRC>; + clock-names = "dmc_clk"; + operating-points-v2 = <&dmc_opp_table>; + center-supply = <&ppvar_centerlogic>; + rockchip,ddr3_speed_bin = <21>; + rockchip,pd_idle = <0x40>; + rockchip,sr_idle = <0x2>; + rockchip,sr_mc_gate_idle = <0x3>; + rockchip,srpd_lite_idle = <0x4>; + rockchip,standby_idle = <0x2000>; + rockchip,dram_dll_dis_freq = <300>; + rockchip,phy_dll_dis_freq = <125>; + rockchip,auto_pd_dis_freq = <666>; + rockchip,ddr3_odt_dis_freq = <333>; + rockchip,ddr3_drv = <40>; + rockchip,ddr3_odt = <120>; + rockchip,phy_ddr3_ca_drv = <40>; + rockchip,phy_ddr3_dq_drv = <40>; + rockchip,phy_ddr3_odt = <240>; + rockchip,lpddr3_odt_dis_freq = <333>; + rockchip,lpddr3_drv = <34>; + rockchip,lpddr3_odt = <240>; + rockchip,phy_lpddr3_ca_drv = <40>; + rockchip,phy_lpddr3_dq_drv = <40>; + rockchip,phy_lpddr3_odt = <240>; + rockchip,lpddr4_odt_dis_freq = <333>; + rockchip,lpddr4_drv = <60>; + rockchip,lpddr4_dq_odt = <40>; + rockchip,lpddr4_ca_odt = <40>; + rockchip,phy_lpddr4_ca_drv = <40>; + rockchip,phy_lpddr4_ck_cs_drv = <80>; + rockchip,phy_lpddr4_dq_drv = <80>; + rockchip,phy_lpddr4_odt = <60>; + }; -- cgit From 76d136b56fc13d12f9b0d68b9a626dfaf8e2b7ae Mon Sep 17 00:00:00 2001 From: Brian Norris Date: Tue, 8 Mar 2022 11:08:48 -0800 Subject: dt-bindings: devfreq: rk3399_dmc: Deprecate unused/redundant properties These DRAM configuration properties are all handled in ARM Trusted Firmware (and have been since the early days of this SoC), and there are no in-tree users of the DMC binding yet. It's better to just defer to firmware instead of maintaining this large list of properties. There's also some confusion about units: many of these are specified in MHz, but the downstream users and driver code are treating them as Hz, I believe. Rather than straighten all that out, I just drop them. Signed-off-by: Brian Norris Reviewed-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi --- .../memory-controllers/rockchip,rk3399-dmc.yaml | 42 +++++++++++----------- 1 file changed, 21 insertions(+), 21 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml index b32c03cb0c68..356bbe5db383 100644 --- a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml @@ -45,6 +45,7 @@ properties: finishes, a DCF interrupt is triggered. rockchip,ddr3_speed_bin: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: For values, reference include/dt-bindings/clock/rk3399-ddr.h. Selects the @@ -91,6 +92,7 @@ properties: if bus is idle for standby_idle * DFI clock cycles. rockchip,dram_dll_dis_freq: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: | Defines the DDR3 DLL bypass frequency in MHz. When DDR frequency is less @@ -98,6 +100,7 @@ properties: Note: if DLL was bypassed, the odt will also stop working. rockchip,phy_dll_dis_freq: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: | Defines the PHY dll bypass frequency in MHz (Mega Hz). When DDR frequency @@ -105,6 +108,7 @@ properties: Note: PHY DLL and PHY ODT are independent. rockchip,auto_pd_dis_freq: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: Defines the auto PD disable frequency in MHz. @@ -118,6 +122,7 @@ properties: disabled. rockchip,ddr3_drv: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is DDR3, this parameter defines the DRAM side drive @@ -125,6 +130,7 @@ properties: default: 40 rockchip,ddr3_odt: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is DDR3, this parameter defines the DRAM side ODT @@ -132,6 +138,7 @@ properties: default: 120 rockchip,phy_ddr3_ca_drv: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is DDR3, this parameter defines the phy side CA line @@ -139,6 +146,7 @@ properties: default: 40 rockchip,phy_ddr3_dq_drv: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is DDR3, this parameter defines the PHY side DQ line @@ -146,6 +154,7 @@ properties: default: 40 rockchip,phy_ddr3_odt: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is DDR3, this parameter defines the PHY side ODT @@ -161,6 +170,7 @@ properties: disabled. rockchip,lpddr3_drv: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is LPDDR3, this parameter defines the DRAM side drive @@ -168,6 +178,7 @@ properties: default: 34 rockchip,lpddr3_odt: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is LPDDR3, this parameter defines the DRAM side ODT @@ -175,6 +186,7 @@ properties: default: 240 rockchip,phy_lpddr3_ca_drv: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is LPDDR3, this parameter defines the PHY side CA line @@ -182,6 +194,7 @@ properties: default: 40 rockchip,phy_lpddr3_dq_drv: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is LPDDR3, this parameter defines the PHY side DQ line @@ -189,6 +202,7 @@ properties: default: 40 rockchip,phy_lpddr3_odt: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When dram type is LPDDR3, this parameter define the phy side odt @@ -203,6 +217,7 @@ properties: disabled. rockchip,lpddr4_drv: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is LPDDR4, this parameter defines the DRAM side drive @@ -210,6 +225,7 @@ properties: default: 60 rockchip,lpddr4_dq_odt: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is LPDDR4, this parameter defines the DRAM side ODT on @@ -217,6 +233,7 @@ properties: default: 40 rockchip,lpddr4_ca_odt: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is LPDDR4, this parameter defines the DRAM side ODT on @@ -224,6 +241,7 @@ properties: default: 40 rockchip,phy_lpddr4_ca_drv: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is LPDDR4, this parameter defines the PHY side CA line @@ -231,6 +249,7 @@ properties: default: 40 rockchip,phy_lpddr4_ck_cs_drv: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is LPDDR4, this parameter defines the PHY side clock @@ -238,6 +257,7 @@ properties: default: 80 rockchip,phy_lpddr4_dq_drv: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is LPDDR4, this parameter defines the PHY side DQ line @@ -245,6 +265,7 @@ properties: default: 80 rockchip,phy_lpddr4_odt: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is LPDDR4, this parameter defines the PHY side ODT @@ -274,33 +295,12 @@ examples: clock-names = "dmc_clk"; operating-points-v2 = <&dmc_opp_table>; center-supply = <&ppvar_centerlogic>; - rockchip,ddr3_speed_bin = <21>; rockchip,pd_idle = <0x40>; rockchip,sr_idle = <0x2>; rockchip,sr_mc_gate_idle = <0x3>; rockchip,srpd_lite_idle = <0x4>; rockchip,standby_idle = <0x2000>; - rockchip,dram_dll_dis_freq = <300>; - rockchip,phy_dll_dis_freq = <125>; - rockchip,auto_pd_dis_freq = <666>; rockchip,ddr3_odt_dis_freq = <333>; - rockchip,ddr3_drv = <40>; - rockchip,ddr3_odt = <120>; - rockchip,phy_ddr3_ca_drv = <40>; - rockchip,phy_ddr3_dq_drv = <40>; - rockchip,phy_ddr3_odt = <240>; rockchip,lpddr3_odt_dis_freq = <333>; - rockchip,lpddr3_drv = <34>; - rockchip,lpddr3_odt = <240>; - rockchip,phy_lpddr3_ca_drv = <40>; - rockchip,phy_lpddr3_dq_drv = <40>; - rockchip,phy_lpddr3_odt = <240>; rockchip,lpddr4_odt_dis_freq = <333>; - rockchip,lpddr4_drv = <60>; - rockchip,lpddr4_dq_odt = <40>; - rockchip,lpddr4_ca_odt = <40>; - rockchip,phy_lpddr4_ca_drv = <40>; - rockchip,phy_lpddr4_ck_cs_drv = <80>; - rockchip,phy_lpddr4_dq_drv = <80>; - rockchip,phy_lpddr4_odt = <60>; }; -- cgit From 4de8fd02a55f2b00fe952cdfb2757968827f3c0e Mon Sep 17 00:00:00 2001 From: Brian Norris Date: Tue, 8 Mar 2022 11:08:49 -0800 Subject: dt-bindings: devfreq: rk3399_dmc: Fix Hz units The driver and all downstream device trees [1] are using Hz units, but the document claims MHz. DRAM frequency for these systems can't possibly exceed 2^32-1 Hz, so the choice of unit doesn't really matter than much. Rather than add unnecessary risk in getting the units wrong, let's just go with the unofficial convention and make the docs match reality. A sub-1MHz frequency is extremely unlikely, so include a minimum in the schema, to help catch anybody who might have believed this was MHz. [1] And notably, also those trying to upstream them: https://lore.kernel.org/lkml/20210308233858.24741-3-daniel.lezcano@linaro.org/ Signed-off-by: Brian Norris Reviewed-by: Rob Herring Acked-by: Chanwoo Choi Reviewed-by: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi --- .../memory-controllers/rockchip,rk3399-dmc.yaml | 24 +++++++++++----------- 1 file changed, 12 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml index 356bbe5db383..96efb23cfc0f 100644 --- a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml @@ -115,11 +115,11 @@ properties: rockchip,ddr3_odt_dis_freq: $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1000000 # In case anyone thought this was MHz. description: When the DRAM type is DDR3, this parameter defines the ODT disable - frequency in MHz (Mega Hz). When the DDR frequency is less then - ddr3_odt_dis_freq, the ODT on the DRAM side and controller side are both - disabled. + frequency in Hz. When the DDR frequency is less then ddr3_odt_dis_freq, + the ODT on the DRAM side and controller side are both disabled. rockchip,ddr3_drv: deprecated: true @@ -163,11 +163,11 @@ properties: rockchip,lpddr3_odt_dis_freq: $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1000000 # In case anyone thought this was MHz. description: When the DRAM type is LPDDR3, this parameter defines then ODT disable - frequency in MHz (Mega Hz). When DDR frequency is less then - ddr3_odt_dis_freq, the ODT on the DRAM side and controller side are both - disabled. + frequency in Hz. When DDR frequency is less then ddr3_odt_dis_freq, the + ODT on the DRAM side and controller side are both disabled. rockchip,lpddr3_drv: deprecated: true @@ -210,11 +210,11 @@ properties: rockchip,lpddr4_odt_dis_freq: $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1000000 # In case anyone thought this was MHz. description: When the DRAM type is LPDDR4, this parameter defines the ODT disable - frequency in MHz (Mega Hz). When the DDR frequency is less then - ddr3_odt_dis_freq, the ODT on the DRAM side and controller side are both - disabled. + frequency in Hz. When the DDR frequency is less then ddr3_odt_dis_freq, + the ODT on the DRAM side and controller side are both disabled. rockchip,lpddr4_drv: deprecated: true @@ -300,7 +300,7 @@ examples: rockchip,sr_mc_gate_idle = <0x3>; rockchip,srpd_lite_idle = <0x4>; rockchip,standby_idle = <0x2000>; - rockchip,ddr3_odt_dis_freq = <333>; - rockchip,lpddr3_odt_dis_freq = <333>; - rockchip,lpddr4_odt_dis_freq = <333>; + rockchip,ddr3_odt_dis_freq = <333000000>; + rockchip,lpddr3_odt_dis_freq = <333000000>; + rockchip,lpddr4_odt_dis_freq = <333000000>; }; -- cgit From 77c188085b466434b2180ffe917a60ed442c8739 Mon Sep 17 00:00:00 2001 From: Brian Norris Date: Tue, 8 Mar 2022 11:08:50 -0800 Subject: dt-bindings: devfreq: rk3399_dmc: Specify idle params in nanoseconds It's inefficient to use the same number of cycles for all OPPs, since lower frequencies make for longer idle times. Let's specify the idle time instead, so software can pick the optimal number of cycles on its own. NB: these bindings aren't used anywhere yet. Signed-off-by: Brian Norris Reviewed-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi --- .../memory-controllers/rockchip,rk3399-dmc.yaml | 51 +++++++++++++++++++--- 1 file changed, 46 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml index 96efb23cfc0f..5228a32b5962 100644 --- a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml @@ -54,42 +54,52 @@ properties: being used. rockchip,pd_idle: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: Configure the PD_IDLE value. Defines the power-down idle period in which memories are placed into power-down mode if bus is idle for PD_IDLE DFI clock cycles. + See also rockchip,pd-idle-ns. rockchip,sr_idle: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: Configure the SR_IDLE value. Defines the self-refresh idle period in which memories are placed into self-refresh mode if bus is idle for SR_IDLE * 1024 DFI clock cycles (DFI clocks freq is half of DRAM clock). + See also rockchip,sr-idle-ns. default: 0 rockchip,sr_mc_gate_idle: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: Defines the memory self-refresh and controller clock gating idle period. Memories are placed into self-refresh mode and memory controller clock arg gating started if bus is idle for sr_mc_gate_idle*1024 DFI clock cycles. + See also rockchip,sr-mc-gate-idle-ns. rockchip,srpd_lite_idle: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: Defines the self-refresh power down idle period in which memories are placed into self-refresh power down mode if bus is idle for srpd_lite_idle * 1024 DFI clock cycles. This parameter is for LPDDR4 only. + See also rockchip,srpd-lite-idle-ns. rockchip,standby_idle: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: Defines the standby idle period in which memories are placed into self-refresh mode. The controller, pi, PHY and DRAM clock will be gated if bus is idle for standby_idle * DFI clock cycles. + See also rockchip,standby-idle-ns. rockchip,dram_dll_dis_freq: deprecated: true @@ -272,6 +282,37 @@ properties: strength. default: 60 + rockchip,pd-idle-ns: + description: + Configure the PD_IDLE value in nanoseconds. Defines the power-down idle + period in which memories are placed into power-down mode if bus is idle + for PD_IDLE nanoseconds. + + rockchip,sr-idle-ns: + description: + Configure the SR_IDLE value in nanoseconds. Defines the self-refresh idle + period in which memories are placed into self-refresh mode if bus is idle + for SR_IDLE nanoseconds. + default: 0 + + rockchip,sr-mc-gate-idle-ns: + description: + Defines the memory self-refresh and controller clock gating idle period in nanoseconds. + Memories are placed into self-refresh mode and memory controller clock + arg gating started if bus is idle for sr_mc_gate_idle nanoseconds. + + rockchip,srpd-lite-idle-ns: + description: + Defines the self-refresh power down idle period in which memories are + placed into self-refresh power down mode if bus is idle for + srpd_lite_idle nanoseonds. This parameter is for LPDDR4 only. + + rockchip,standby-idle-ns: + description: + Defines the standby idle period in which memories are placed into + self-refresh mode. The controller, pi, PHY and DRAM clock will be gated + if bus is idle for standby_idle nanoseconds. + required: - compatible - devfreq-events @@ -295,11 +336,11 @@ examples: clock-names = "dmc_clk"; operating-points-v2 = <&dmc_opp_table>; center-supply = <&ppvar_centerlogic>; - rockchip,pd_idle = <0x40>; - rockchip,sr_idle = <0x2>; - rockchip,sr_mc_gate_idle = <0x3>; - rockchip,srpd_lite_idle = <0x4>; - rockchip,standby_idle = <0x2000>; + rockchip,pd-idle-ns = <160>; + rockchip,sr-idle-ns = <10240>; + rockchip,sr-mc-gate-idle-ns = <40960>; + rockchip,srpd-lite-idle-ns = <61440>; + rockchip,standby-idle-ns = <81920>; rockchip,ddr3_odt_dis_freq = <333000000>; rockchip,lpddr3_odt_dis_freq = <333000000>; rockchip,lpddr4_odt_dis_freq = <333000000>; -- cgit From a86fb6a9a21d20aa643448d742da4eec065091f7 Mon Sep 17 00:00:00 2001 From: Brian Norris Date: Tue, 8 Mar 2022 11:08:51 -0800 Subject: dt-bindings: devfreq: rk3399_dmc: Add more disable-freq properties DDR DVFS tuning has found that several power-saving features don't have good tradeoffs at higher frequencies -- at higher frequencies, we'll see glitches or other errors. Provide tuning controls so these can be disabled at higher OPPs, and left active only at the lower ones. Signed-off-by: Brian Norris Reviewed-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi --- .../memory-controllers/rockchip,rk3399-dmc.yaml | 37 ++++++++++++++++++++++ 1 file changed, 37 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml index 5228a32b5962..fb4920397d08 100644 --- a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml @@ -313,6 +313,38 @@ properties: self-refresh mode. The controller, pi, PHY and DRAM clock will be gated if bus is idle for standby_idle nanoseconds. + rockchip,pd-idle-dis-freq-hz: + description: + Defines the power-down idle disable frequency in Hz. When the DDR + frequency is greater than pd-idle-dis-freq, power-down idle is disabled. + See also rockchip,pd-idle-ns. + + rockchip,sr-idle-dis-freq-hz: + description: + Defines the self-refresh idle disable frequency in Hz. When the DDR + frequency is greater than sr-idle-dis-freq, self-refresh idle is + disabled. See also rockchip,sr-idle-ns. + + rockchip,sr-mc-gate-idle-dis-freq-hz: + description: + Defines the self-refresh and memory-controller clock gating disable + frequency in Hz. When the DDR frequency is greater than + sr-mc-gate-idle-dis-freq, the clock will not be gated when idle. See also + rockchip,sr-mc-gate-idle-ns. + + rockchip,srpd-lite-idle-dis-freq-hz: + description: + Defines the self-refresh power down idle disable frequency in Hz. When + the DDR frequency is greater than srpd-lite-idle-dis-freq, memory will + not be placed into self-refresh power down mode when idle. See also + rockchip,srpd-lite-idle-ns. + + rockchip,standby-idle-dis-freq-hz: + description: + Defines the standby idle disable frequency in Hz. When the DDR frequency + is greater than standby-idle-dis-freq, standby idle is disabled. See also + rockchip,standby-idle-ns. + required: - compatible - devfreq-events @@ -344,4 +376,9 @@ examples: rockchip,ddr3_odt_dis_freq = <333000000>; rockchip,lpddr3_odt_dis_freq = <333000000>; rockchip,lpddr4_odt_dis_freq = <333000000>; + rockchip,pd-idle-dis-freq-hz = <1000000000>; + rockchip,sr-idle-dis-freq-hz = <1000000000>; + rockchip,sr-mc-gate-idle-dis-freq-hz = <1000000000>; + rockchip,srpd-lite-idle-dis-freq-hz = <0>; + rockchip,standby-idle-dis-freq-hz = <928000000>; }; -- cgit From 694ed9922bc821e7208bc6593b5eeb88f8382fd5 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Mon, 11 Apr 2022 00:05:14 +0200 Subject: dt-bindings: rcc: Add optional external ethernet RX clock properties Describe optional external ethernet RX clock in the DT binding to fix dtbs_check warnings like: arch/arm/boot/dts/stm32mp153c-dhcom-drc02.dt.yaml: rcc@50000000: 'assigned-clock-parents', 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks' do not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Gabriel Fernandez Cc: Rob Herring To: devicetree@vger.kernel.org Acked-by: Gabriel Fernandez Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220410220514.21779-1-marex@denx.de --- Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml index a0ae4867ed27..7a251264582d 100644 --- a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml +++ b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml @@ -59,6 +59,14 @@ properties: - st,stm32mp1-rcc - const: syscon + clocks: + description: + Specifies the external RX clock for ethernet MAC. + maxItems: 1 + + clock-names: + const: ETH_RX_CLK/ETH_REF_CLK + reg: maxItems: 1 -- cgit From 8feecea4de7ee1bd9712947bb85d495b1d1e438d Mon Sep 17 00:00:00 2001 From: Lad Prabhakar Date: Mon, 11 Apr 2022 14:43:05 +0200 Subject: dt-bindings: ata: renesas,rcar-sata: Add r8a774e1 support Document SATA support for the RZ/G2H SoC, no driver change required. Signed-off-by: Lad Prabhakar Reviewed-by: Marian-Cristian Rotariu Acked-by: Rob Herring Signed-off-by: Geert Uytterhoeven Acked-by: Damien Le Moal Signed-off-by: Damien Le Moal --- Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml b/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml index c060c7914cae..c4e4a9eab658 100644 --- a/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml +++ b/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml @@ -26,6 +26,7 @@ properties: - items: - enum: - renesas,sata-r8a774b1 # RZ/G2N + - renesas,sata-r8a774e1 # RZ/G2H - renesas,sata-r8a7795 # R-Car H3 - renesas,sata-r8a77965 # R-Car M3-N - const: renesas,rcar-gen3-sata # generic R-Car Gen3 or RZ/G2 -- cgit From 3dc6ffae2da201284cb24af66af77ee0bbb2efaa Mon Sep 17 00:00:00 2001 From: Kurt Kanzenbach Date: Thu, 14 Apr 2022 11:18:03 +0200 Subject: timekeeping: Introduce fast accessor to clock tai Introduce fast/NMI safe accessor to clock tai for tracing. The Linux kernel tracing infrastructure has support for using different clocks to generate timestamps for trace events. Especially in TSN networks it's useful to have TAI as trace clock, because the application scheduling is done in accordance to the network time, which is based on TAI. With a tai trace_clock in place, it becomes very convenient to correlate network activity with Linux kernel application traces. Use the same implementation as ktime_get_boot_fast_ns() does by reading the monotonic time and adding the TAI offset. The same limitations as for the fast boot implementation apply. The TAI offset may change at run time e.g., by setting the time or using adjtimex() with an offset. However, these kind of offset changes are rare events. Nevertheless, the user has to be aware and deal with it in post processing. An alternative approach would be to use the same implementation as ktime_get_real_fast_ns() does. However, this requires to add an additional u64 member to the tk_read_base struct. This struct together with a seqcount is designed to fit into a single cache line on 64 bit architectures. Adding a new member would violate this constraint. Signed-off-by: Kurt Kanzenbach Signed-off-by: Thomas Gleixner Cc: Steven Rostedt Link: https://lore.kernel.org/r/20220414091805.89667-2-kurt@linutronix.de --- Documentation/core-api/timekeeping.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/core-api/timekeeping.rst b/Documentation/core-api/timekeeping.rst index 729e24864fe7..22ec68f24421 100644 --- a/Documentation/core-api/timekeeping.rst +++ b/Documentation/core-api/timekeeping.rst @@ -132,6 +132,7 @@ Some additional variants exist for more specialized cases: .. c:function:: u64 ktime_get_mono_fast_ns( void ) u64 ktime_get_raw_fast_ns( void ) u64 ktime_get_boot_fast_ns( void ) + u64 ktime_get_tai_fast_ns( void ) u64 ktime_get_real_fast_ns( void ) These variants are safe to call from any context, including from -- cgit From 548f8b21ae6053680c61fe7ca79e2380b0b3964e Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 11 Apr 2022 17:55:28 +0200 Subject: dt-bindings: soc: qcom,smp2p: convert to dtschema Convert the Qualcomm Shared Memory Point 2 Point bindings to DT Schema. Changes against original bindings: enforce only specific names of child nodes, instead of any names. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220411155528.502889-1-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/soc/qcom/qcom,smp2p.txt | 110 ---------------- .../devicetree/bindings/soc/qcom/qcom,smp2p.yaml | 145 +++++++++++++++++++++ 2 files changed, 145 insertions(+), 110 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt deleted file mode 100644 index 49e1d72d3648..000000000000 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt +++ /dev/null @@ -1,110 +0,0 @@ -Qualcomm Shared Memory Point 2 Point binding - -The Shared Memory Point to Point (SMP2P) protocol facilitates communication of -a single 32-bit value between two processors. Each value has a single writer -(the local side) and a single reader (the remote side). Values are uniquely -identified in the system by the directed edge (local processor ID to remote -processor ID) and a string identifier. - -- compatible: - Usage: required - Value type: - Definition: must be one of: - "qcom,smp2p" - -- interrupts: - Usage: required - Value type: - Definition: one entry specifying the smp2p notification interrupt - -- mboxes: - Usage: required - Value type: - Definition: reference to the associated doorbell in APCS, as described - in mailbox/mailbox.txt - -- qcom,ipc: - Usage: required, unless mboxes is specified - Value type: - Definition: three entries specifying the outgoing ipc bit used for - signaling the remote end of the smp2p edge: - - phandle to a syscon node representing the apcs registers - - u32 representing offset to the register within the syscon - - u32 representing the ipc bit within the register - -- qcom,smem: - Usage: required - Value type: - Definition: two identifiers of the inbound and outbound smem items used - for this edge - -- qcom,local-pid: - Usage: required - Value type: - Definition: specifies the identifier of the local endpoint of this edge - -- qcom,remote-pid: - Usage: required - Value type: - Definition: specifies the identifier of the remote endpoint of this edge - -= SUBNODES -Each SMP2P pair contain a set of inbound and outbound entries, these are -described in subnodes of the smp2p device node. The node names are not -important. - -- qcom,entry-name: - Usage: required - Value type: - Definition: specifies the name of this entry, for inbound entries this - will be used to match against the remotely allocated entry - and for outbound entries this name is used for allocating - entries - -- interrupt-controller: - Usage: required for incoming entries - Value type: - Definition: marks the entry as inbound; the node should be specified - as a two cell interrupt-controller as defined in - "../interrupt-controller/interrupts.txt" - If not specified this node will denote the outgoing entry - -- #interrupt-cells: - Usage: required for incoming entries - Value type: - Definition: must be 2 - denoting the bit in the entry and IRQ flags - -- #qcom,smem-state-cells: - Usage: required for outgoing entries - Value type: - Definition: must be 1 - denoting the bit in the entry - -= EXAMPLE -The following example shows the SMP2P setup with the wireless processor, -defined from the 8974 apps processor's point-of-view. It encompasses one -inbound and one outbound entry: - -wcnss-smp2p { - compatible = "qcom,smp2p"; - qcom,smem = <431>, <451>; - - interrupts = <0 143 1>; - - qcom,ipc = <&apcs 8 18>; - - qcom,local-pid = <0>; - qcom,remote-pid = <4>; - - wcnss_smp2p_out: master-kernel { - qcom,entry-name = "master-kernel"; - - #qcom,smem-state-cells = <1>; - }; - - wcnss_smp2p_in: slave-kernel { - qcom,entry-name = "slave-kernel"; - - interrupt-controller; - #interrupt-cells = <2>; - }; -}; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml new file mode 100644 index 000000000000..795bd8cd4104 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml @@ -0,0 +1,145 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/qcom/qcom,smp2p.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Shared Memory Point 2 Point + +maintainers: + - Andy Gross + - Bjorn Andersson + - Krzysztof Kozlowski + +description: + The Shared Memory Point to Point (SMP2P) protocol facilitates communication + of a single 32-bit value between two processors. Each value has a single + writer (the local side) and a single reader (the remote side). Values are + uniquely identified in the system by the directed edge (local processor ID to + remote processor ID) and a string identifier. + +properties: + compatible: + const: qcom,smp2p + + interrupts: + maxItems: 1 + + mboxes: + maxItems: 1 + description: + Reference to the mailbox representing the outgoing doorbell in APCS for + this client. + + qcom,ipc: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to a syscon node representing the APCS registers + - description: u32 representing offset to the register within the syscon + - description: u32 representing the ipc bit within the register + description: + Three entries specifying the outgoing ipc bit used for signaling the + remote end of the smp2p edge. + + qcom,local-pid: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The identifier of the local endpoint of this edge. + + qcom,remote-pid: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The identifier of the remote endpoint of this edge. + + qcom,smem: + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + maxItems: 2 + description: + Two identifiers of the inbound and outbound smem items used for this edge. + +patternProperties: + "^master-kernel|slave-kernel|ipa-ap-to-modem|ipa-modem-to-ap$": + type: object + description: + Each SMP2P pair contain a set of inbound and outbound entries, these are + described in subnodes of the smp2p device node. The node names are not + important. + + properties: + interrupt-controller: + description: + Marks the entry as inbound; the node should be specified as a two + cell interrupt-controller. If not specified this node will denote + the outgoing entry. + + '#interrupt-cells': + const: 2 + + qcom,entry-name: + $ref: /schemas/types.yaml#/definitions/string + description: + The name of this entry, for inbound entries this will be used to + match against the remotely allocated entry and for outbound entries + this name is used for allocating entries. + + '#qcom,smem-state-cells': + $ref: /schemas/types.yaml#/definitions/uint32 + const: 1 + description: + Required for outgoing entries. + + required: + - qcom,entry-name + + oneOf: + - required: + - interrupt-controller + - '#interrupt-cells' + - required: + - '#qcom,smem-state-cells' + + additionalProperties: false + +required: + - compatible + - interrupts + - qcom,local-pid + - qcom,remote-pid + - qcom,smem + +oneOf: + - required: + - mboxes + - required: + - qcom,ipc + +additionalProperties: false + +examples: + # The following example shows the SMP2P setup with the wireless processor, + # defined from the 8974 apps processor's point-of-view. It encompasses one + # inbound and one outbound entry. + - | + #include + + shared-memory { + compatible = "qcom,smp2p"; + qcom,smem = <431>, <451>; + interrupts = ; + qcom,ipc = <&apcs 8 18>; + qcom,local-pid = <0>; + qcom,remote-pid = <4>; + + wcnss_smp2p_out: master-kernel { + qcom,entry-name = "master-kernel"; + #qcom,smem-state-cells = <1>; + }; + + wcnss_smp2p_in: slave-kernel { + qcom,entry-name = "slave-kernel"; + interrupt-controller; + #interrupt-cells = <2>; + }; + }; -- cgit From b96cd8b05ead8939b972192c4f4ac2fc2dffceb7 Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Mon, 11 Apr 2022 13:01:38 +0200 Subject: Documentation: move tty to driver-api Based on discussion starting as 87mthw2o93.fsf@meer.lwn.net, let's move the tty documentation to driver-api. It's more appropriate there. Cc: Jonathan Corbet Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20220411110143.10019-2-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/index.rst | 1 + Documentation/driver-api/serial/driver.rst | 2 +- Documentation/driver-api/tty/index.rst | 62 ++++++++++++ Documentation/driver-api/tty/n_tty.rst | 22 +++++ Documentation/driver-api/tty/tty_buffer.rst | 46 +++++++++ Documentation/driver-api/tty/tty_driver.rst | 128 +++++++++++++++++++++++++ Documentation/driver-api/tty/tty_internals.rst | 31 ++++++ Documentation/driver-api/tty/tty_ldisc.rst | 85 ++++++++++++++++ Documentation/driver-api/tty/tty_port.rst | 70 ++++++++++++++ Documentation/driver-api/tty/tty_struct.rst | 81 ++++++++++++++++ Documentation/index.rst | 1 - Documentation/tty/index.rst | 63 ------------ Documentation/tty/n_tty.rst | 22 ----- Documentation/tty/tty_buffer.rst | 46 --------- Documentation/tty/tty_driver.rst | 128 ------------------------- Documentation/tty/tty_internals.rst | 31 ------ Documentation/tty/tty_ldisc.rst | 85 ---------------- Documentation/tty/tty_port.rst | 70 -------------- Documentation/tty/tty_struct.rst | 81 ---------------- 19 files changed, 527 insertions(+), 528 deletions(-) create mode 100644 Documentation/driver-api/tty/index.rst create mode 100644 Documentation/driver-api/tty/n_tty.rst create mode 100644 Documentation/driver-api/tty/tty_buffer.rst create mode 100644 Documentation/driver-api/tty/tty_driver.rst create mode 100644 Documentation/driver-api/tty/tty_internals.rst create mode 100644 Documentation/driver-api/tty/tty_ldisc.rst create mode 100644 Documentation/driver-api/tty/tty_port.rst create mode 100644 Documentation/driver-api/tty/tty_struct.rst delete mode 100644 Documentation/tty/index.rst delete mode 100644 Documentation/tty/n_tty.rst delete mode 100644 Documentation/tty/tty_buffer.rst delete mode 100644 Documentation/tty/tty_driver.rst delete mode 100644 Documentation/tty/tty_internals.rst delete mode 100644 Documentation/tty/tty_ldisc.rst delete mode 100644 Documentation/tty/tty_port.rst delete mode 100644 Documentation/tty/tty_struct.rst (limited to 'Documentation') diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index a7b0223e2886..bbbbcf20b7ce 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -101,6 +101,7 @@ available subsections can be seen below. surface_aggregator/index switchtec sync_file + tty vfio-mediated-device vfio vfio-pci-device-specific-driver-acceptance diff --git a/Documentation/driver-api/serial/driver.rst b/Documentation/driver-api/serial/driver.rst index 06ec04ba086f..7ef83fd3917b 100644 --- a/Documentation/driver-api/serial/driver.rst +++ b/Documentation/driver-api/serial/driver.rst @@ -311,7 +311,7 @@ hardware. This call must not sleep set_ldisc(port,termios) - Notifier for discipline change. See Documentation/tty/tty_ldisc.rst. + Notifier for discipline change. See ../tty/tty_ldisc.rst. Locking: caller holds tty_port->mutex diff --git a/Documentation/driver-api/tty/index.rst b/Documentation/driver-api/tty/index.rst new file mode 100644 index 000000000000..2240e52203d6 --- /dev/null +++ b/Documentation/driver-api/tty/index.rst @@ -0,0 +1,62 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +TTY +=== + +Teletypewriter (TTY) layer takes care of all those serial devices. Including +the virtual ones like pseudoterminal (PTY). + +TTY structures +============== + +There are several major TTY structures. Every TTY device in a system has a +corresponding struct tty_port. These devices are maintained by a TTY driver +which is struct tty_driver. This structure describes the driver but also +contains a reference to operations which could be performed on the TTYs. It is +struct tty_operations. Then, upon open, a struct tty_struct is allocated and +lives until the final close. During this time, several callbacks from struct +tty_operations are invoked by the TTY layer. + +Every character received by the kernel (both from devices and users) is passed +through a preselected :doc:`tty_ldisc` (in +short ldisc; in C, struct tty_ldisc_ops). Its task is to transform characters +as defined by a particular ldisc or by user too. The default one is n_tty, +implementing echoes, signal handling, jobs control, special characters +processing, and more. The transformed characters are passed further to +user/device, depending on the source. + +In-detail description of the named TTY structures is in separate documents: + +.. toctree:: + :maxdepth: 2 + + tty_driver + tty_port + tty_struct + tty_ldisc + tty_buffer + n_tty + tty_internals + +Writing TTY Driver +================== + +Before one starts writing a TTY driver, they must consider +:doc:`Serial <../serial/driver>` and :doc:`USB Serial <../../usb/usb-serial>` +layers first. Drivers for serial devices can often use one of these specific +layers to implement a serial driver. Only special devices should be handled +directly by the TTY Layer. If you are about to write such a driver, read on. + +A *typical* sequence a TTY driver performs is as follows: + +#. Allocate and register a TTY driver (module init) +#. Create and register TTY devices as they are probed (probe function) +#. Handle TTY operations and events like interrupts (TTY core invokes the + former, the device the latter) +#. Remove devices as they are going away (remove function) +#. Unregister and free the TTY driver (module exit) + +Steps regarding driver, i.e. 1., 3., and 5. are described in detail in +:doc:`tty_driver`. For the other two (devices handling), look into +:doc:`tty_port`. diff --git a/Documentation/driver-api/tty/n_tty.rst b/Documentation/driver-api/tty/n_tty.rst new file mode 100644 index 000000000000..15b70faee72d --- /dev/null +++ b/Documentation/driver-api/tty/n_tty.rst @@ -0,0 +1,22 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===== +N_TTY +===== + +.. contents:: :local: + +The default (and fallback) :doc:`TTY line discipline `. It tries to +handle characters as per POSIX. + +External Functions +================== + +.. kernel-doc:: drivers/tty/n_tty.c + :export: + +Internal Functions +================== + +.. kernel-doc:: drivers/tty/n_tty.c + :internal: diff --git a/Documentation/driver-api/tty/tty_buffer.rst b/Documentation/driver-api/tty/tty_buffer.rst new file mode 100644 index 000000000000..a39d4781e0d2 --- /dev/null +++ b/Documentation/driver-api/tty/tty_buffer.rst @@ -0,0 +1,46 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========== +TTY Buffer +========== + +.. contents:: :local: + +Here, we document functions for taking care of tty buffer and their flipping. +Drivers are supposed to fill the buffer by one of those functions below and +then flip the buffer, so that the data are passed to :doc:`line discipline +` for further processing. + +Flip Buffer Management +====================== + +.. kernel-doc:: drivers/tty/tty_buffer.c + :identifiers: tty_prepare_flip_string tty_insert_flip_string_fixed_flag + tty_insert_flip_string_flags __tty_insert_flip_char + tty_flip_buffer_push tty_ldisc_receive_buf + +---- + +Other Functions +=============== + +.. kernel-doc:: drivers/tty/tty_buffer.c + :identifiers: tty_buffer_space_avail tty_buffer_set_limit + +---- + +Buffer Locking +============== + +These are used only in special circumstances. Avoid them. + +.. kernel-doc:: drivers/tty/tty_buffer.c + :identifiers: tty_buffer_lock_exclusive tty_buffer_unlock_exclusive + +---- + +Internal Functions +================== + +.. kernel-doc:: drivers/tty/tty_buffer.c + :internal: diff --git a/Documentation/driver-api/tty/tty_driver.rst b/Documentation/driver-api/tty/tty_driver.rst new file mode 100644 index 000000000000..cc529f863406 --- /dev/null +++ b/Documentation/driver-api/tty/tty_driver.rst @@ -0,0 +1,128 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================= +TTY Driver and TTY Operations +============================= + +.. contents:: :local: + +Allocation +========== + +The first thing a driver needs to do is to allocate a struct tty_driver. This +is done by tty_alloc_driver() (or __tty_alloc_driver()). Next, the newly +allocated structure is filled with information. See `TTY Driver Reference`_ at +the end of this document on what actually shall be filled in. + +The allocation routines expect a number of devices the driver can handle at +most and flags. Flags are those starting ``TTY_DRIVER_`` listed and described +in `TTY Driver Flags`_ below. + +When the driver is about to be freed, tty_driver_kref_put() is called on that. +It will decrements the reference count and if it reaches zero, the driver is +freed. + +For reference, both allocation and deallocation functions are explained here in +detail: + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: __tty_alloc_driver tty_driver_kref_put + +TTY Driver Flags +---------------- + +Here comes the documentation of flags accepted by tty_alloc_driver() (or +__tty_alloc_driver()): + +.. kernel-doc:: include/linux/tty_driver.h + :doc: TTY Driver Flags + +---- + +Registration +============ + +When a struct tty_driver is allocated and filled in, it can be registered using +tty_register_driver(). It is recommended to pass ``TTY_DRIVER_DYNAMIC_DEV`` in +flags of tty_alloc_driver(). If it is not passed, *all* devices are also +registered during tty_register_driver() and the following paragraph of +registering devices can be skipped for such drivers. However, the struct +tty_port part in `Registering Devices`_ is still relevant there. + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_register_driver tty_unregister_driver + +Registering Devices +------------------- + +Every TTY device shall be backed by a struct tty_port. Usually, TTY drivers +embed tty_port into device's private structures. Further details about handling +tty_port can be found in :doc:`tty_port`. The driver is also recommended to use +tty_port's reference counting by tty_port_get() and tty_port_put(). The final +put is supposed to free the tty_port including the device's private struct. + +Unless ``TTY_DRIVER_DYNAMIC_DEV`` was passed as flags to tty_alloc_driver(), +TTY driver is supposed to register every device discovered in the system +(the latter is preferred). This is performed by tty_register_device(). Or by +tty_register_device_attr() if the driver wants to expose some information +through struct attribute_group. Both of them register ``index``'th device and +upon return, the device can be opened. There are also preferred tty_port +variants described in `Linking Devices to Ports`_ later. It is up to driver to +manage free indices and choosing the right one. The TTY layer only refuses to +register more devices than passed to tty_alloc_driver(). + +When the device is opened, the TTY layer allocates struct tty_struct and starts +calling operations from :c:member:`tty_driver.ops`, see `TTY Operations +Reference`_. + +The registration routines are documented as follows: + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_register_device tty_register_device_attr + tty_unregister_device + +---- + +Linking Devices to Ports +------------------------ +As stated earlier, every TTY device shall have a struct tty_port assigned to +it. It must be known to the TTY layer at :c:member:`tty_driver.ops.install()` +at latest. There are few helpers to *link* the two. Ideally, the driver uses +tty_port_register_device() or tty_port_register_device_attr() instead of +tty_register_device() and tty_register_device_attr() at the registration time. +This way, the driver needs not care about linking later on. + +If that is not possible, the driver still can link the tty_port to a specific +index *before* the actual registration by tty_port_link_device(). If it still +does not fit, tty_port_install() can be used from the +:c:member:`tty_driver.ops.install` hook as a last resort. The last one is +dedicated mostly for in-memory devices like PTY where tty_ports are allocated +on demand. + +The linking routines are documented here: + +.. kernel-doc:: drivers/tty/tty_port.c + :identifiers: tty_port_link_device tty_port_register_device + tty_port_register_device_attr + +---- + +TTY Driver Reference +==================== + +All members of struct tty_driver are documented here. The required members are +noted at the end. struct tty_operations are documented next. + +.. kernel-doc:: include/linux/tty_driver.h + :identifiers: tty_driver + +---- + +TTY Operations Reference +======================== + +When a TTY is registered, these driver hooks can be invoked by the TTY layer: + +.. kernel-doc:: include/linux/tty_driver.h + :identifiers: tty_operations + diff --git a/Documentation/driver-api/tty/tty_internals.rst b/Documentation/driver-api/tty/tty_internals.rst new file mode 100644 index 000000000000..d0d415820300 --- /dev/null +++ b/Documentation/driver-api/tty/tty_internals.rst @@ -0,0 +1,31 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============= +TTY Internals +============= + +.. contents:: :local: + +Kopen +===== + +These functions serve for opening a TTY from the kernelspace: + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_kopen_exclusive tty_kopen_shared tty_kclose + +---- + +Exported Internal Functions +=========================== + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_release_struct tty_dev_name_to_number tty_get_icount + +---- + +Internal Functions +================== + +.. kernel-doc:: drivers/tty/tty_io.c + :internal: diff --git a/Documentation/driver-api/tty/tty_ldisc.rst b/Documentation/driver-api/tty/tty_ldisc.rst new file mode 100644 index 000000000000..5144751be804 --- /dev/null +++ b/Documentation/driver-api/tty/tty_ldisc.rst @@ -0,0 +1,85 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================== +TTY Line Discipline +=================== + +.. contents:: :local: + +TTY line discipline process all incoming and outgoing character from/to a tty +device. The default line discipline is :doc:`N_TTY `. It is also a +fallback if establishing any other discipline for a tty fails. If even N_TTY +fails, N_NULL takes over. That never fails, but also does not process any +characters -- it throws them away. + +Registration +============ + +Line disciplines are registered with tty_register_ldisc() passing the ldisc +structure. At the point of registration the discipline must be ready to use and +it is possible it will get used before the call returns success. If the call +returns an error then it won’t get called. Do not re-use ldisc numbers as they +are part of the userspace ABI and writing over an existing ldisc will cause +demons to eat your computer. You must not re-register over the top of the line +discipline even with the same data or your computer again will be eaten by +demons. In order to remove a line discipline call tty_unregister_ldisc(). + +Heed this warning: the reference count field of the registered copies of the +tty_ldisc structure in the ldisc table counts the number of lines using this +discipline. The reference count of the tty_ldisc structure within a tty counts +the number of active users of the ldisc at this instant. In effect it counts +the number of threads of execution within an ldisc method (plus those about to +enter and exit although this detail matters not). + +.. kernel-doc:: drivers/tty/tty_ldisc.c + :identifiers: tty_register_ldisc tty_unregister_ldisc + +Other Functions +=============== + +.. kernel-doc:: drivers/tty/tty_ldisc.c + :identifiers: tty_set_ldisc tty_ldisc_flush + +Line Discipline Operations Reference +==================================== + +.. kernel-doc:: include/linux/tty_ldisc.h + :identifiers: tty_ldisc_ops + +Driver Access +============= + +Line discipline methods can call the methods of the underlying hardware driver. +These are documented as a part of struct tty_operations. + +TTY Flags +========= + +Line discipline methods have access to :c:member:`tty_struct.flags` field. See +:doc:`tty_struct`. + +Locking +======= + +Callers to the line discipline functions from the tty layer are required to +take line discipline locks. The same is true of calls from the driver side +but not yet enforced. + +.. kernel-doc:: drivers/tty/tty_ldisc.c + :identifiers: tty_ldisc_ref_wait tty_ldisc_ref tty_ldisc_deref + +While these functions are slightly slower than the old code they should have +minimal impact as most receive logic uses the flip buffers and they only +need to take a reference when they push bits up through the driver. + +A caution: The :c:member:`tty_ldisc_ops.open()`, +:c:member:`tty_ldisc_ops.close()` and :c:member:`tty_driver.set_ldisc()` +functions are called with the ldisc unavailable. Thus tty_ldisc_ref() will fail +in this situation if used within these functions. Ldisc and driver code +calling its own functions must be careful in this case. + +Internal Functions +================== + +.. kernel-doc:: drivers/tty/tty_ldisc.c + :internal: diff --git a/Documentation/driver-api/tty/tty_port.rst b/Documentation/driver-api/tty/tty_port.rst new file mode 100644 index 000000000000..5cb90e954fcf --- /dev/null +++ b/Documentation/driver-api/tty/tty_port.rst @@ -0,0 +1,70 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======== +TTY Port +======== + +.. contents:: :local: + +The TTY drivers are advised to use struct tty_port helpers as much as possible. +If the drivers implement :c:member:`tty_port.ops.activate()` and +:c:member:`tty_port.ops.shutdown()`, they can use tty_port_open(), +tty_port_close(), and tty_port_hangup() in respective +:c:member:`tty_struct.ops` hooks. + +The reference and details are contained in the `TTY Port Reference`_ and `TTY +Port Operations Reference`_ sections at the bottom. + +TTY Port Functions +================== + +Init & Destroy +-------------- + +.. kernel-doc:: drivers/tty/tty_port.c + :identifiers: tty_port_init tty_port_destroy + tty_port_get tty_port_put + +Open/Close/Hangup Helpers +------------------------- + +.. kernel-doc:: drivers/tty/tty_port.c + :identifiers: tty_port_install tty_port_open tty_port_block_til_ready + tty_port_close tty_port_close_start tty_port_close_end tty_port_hangup + tty_port_shutdown + +TTY Refcounting +--------------- + +.. kernel-doc:: drivers/tty/tty_port.c + :identifiers: tty_port_tty_get tty_port_tty_set + +TTY Helpers +----------- + +.. kernel-doc:: drivers/tty/tty_port.c + :identifiers: tty_port_tty_hangup tty_port_tty_wakeup + + +Modem Signals +------------- + +.. kernel-doc:: drivers/tty/tty_port.c + :identifiers: tty_port_carrier_raised tty_port_raise_dtr_rts + tty_port_lower_dtr_rts + +---- + +TTY Port Reference +================== + +.. kernel-doc:: include/linux/tty_port.h + :identifiers: tty_port + +---- + +TTY Port Operations Reference +============================= + +.. kernel-doc:: include/linux/tty_port.h + :identifiers: tty_port_operations diff --git a/Documentation/driver-api/tty/tty_struct.rst b/Documentation/driver-api/tty/tty_struct.rst new file mode 100644 index 000000000000..c72f5a4293b2 --- /dev/null +++ b/Documentation/driver-api/tty/tty_struct.rst @@ -0,0 +1,81 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========== +TTY Struct +========== + +.. contents:: :local: + +struct tty_struct is allocated by the TTY layer upon the first open of the TTY +device and released after the last close. The TTY layer passes this structure +to most of struct tty_operation's hooks. Members of tty_struct are documented +in `TTY Struct Reference`_ at the bottom. + +Initialization +============== + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_init_termios + +Name +==== + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_name + +Reference counting +================== + +.. kernel-doc:: include/linux/tty.h + :identifiers: tty_kref_get + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_kref_put + +Install +======= + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_standard_install + +Read & Write +============ + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_put_char + +Start & Stop +============ + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: start_tty stop_tty + +Wakeup +====== + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_wakeup + +Hangup +====== + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_hangup tty_vhangup tty_hung_up_p + +Misc +==== + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_do_resize + +TTY Struct Flags +================ + +.. kernel-doc:: include/linux/tty.h + :doc: TTY Struct Flags + +TTY Struct Reference +==================== + +.. kernel-doc:: include/linux/tty.h + :identifiers: tty_struct diff --git a/Documentation/index.rst b/Documentation/index.rst index 1988c19d9daf..5a5acac985f3 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -137,7 +137,6 @@ needed). misc-devices/index scheduler/index mhi/index - tty/index peci/index Architecture-agnostic documentation diff --git a/Documentation/tty/index.rst b/Documentation/tty/index.rst deleted file mode 100644 index 21ea0cb21e55..000000000000 --- a/Documentation/tty/index.rst +++ /dev/null @@ -1,63 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -=== -TTY -=== - -Teletypewriter (TTY) layer takes care of all those serial devices. Including -the virtual ones like pseudoterminal (PTY). - -TTY structures -============== - -There are several major TTY structures. Every TTY device in a system has a -corresponding struct tty_port. These devices are maintained by a TTY driver -which is struct tty_driver. This structure describes the driver but also -contains a reference to operations which could be performed on the TTYs. It is -struct tty_operations. Then, upon open, a struct tty_struct is allocated and -lives until the final close. During this time, several callbacks from struct -tty_operations are invoked by the TTY layer. - -Every character received by the kernel (both from devices and users) is passed -through a preselected :doc:`tty_ldisc` (in -short ldisc; in C, struct tty_ldisc_ops). Its task is to transform characters -as defined by a particular ldisc or by user too. The default one is n_tty, -implementing echoes, signal handling, jobs control, special characters -processing, and more. The transformed characters are passed further to -user/device, depending on the source. - -In-detail description of the named TTY structures is in separate documents: - -.. toctree:: - :maxdepth: 2 - - tty_driver - tty_port - tty_struct - tty_ldisc - tty_buffer - n_tty - tty_internals - -Writing TTY Driver -================== - -Before one starts writing a TTY driver, they must consider -:doc:`Serial <../driver-api/serial/driver>` and :doc:`USB Serial -<../usb/usb-serial>` layers -first. Drivers for serial devices can often use one of these specific layers to -implement a serial driver. Only special devices should be handled directly by -the TTY Layer. If you are about to write such a driver, read on. - -A *typical* sequence a TTY driver performs is as follows: - -#. Allocate and register a TTY driver (module init) -#. Create and register TTY devices as they are probed (probe function) -#. Handle TTY operations and events like interrupts (TTY core invokes the - former, the device the latter) -#. Remove devices as they are going away (remove function) -#. Unregister and free the TTY driver (module exit) - -Steps regarding driver, i.e. 1., 3., and 5. are described in detail in -:doc:`tty_driver`. For the other two (devices handling), look into -:doc:`tty_port`. diff --git a/Documentation/tty/n_tty.rst b/Documentation/tty/n_tty.rst deleted file mode 100644 index 15b70faee72d..000000000000 --- a/Documentation/tty/n_tty.rst +++ /dev/null @@ -1,22 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -===== -N_TTY -===== - -.. contents:: :local: - -The default (and fallback) :doc:`TTY line discipline `. It tries to -handle characters as per POSIX. - -External Functions -================== - -.. kernel-doc:: drivers/tty/n_tty.c - :export: - -Internal Functions -================== - -.. kernel-doc:: drivers/tty/n_tty.c - :internal: diff --git a/Documentation/tty/tty_buffer.rst b/Documentation/tty/tty_buffer.rst deleted file mode 100644 index a39d4781e0d2..000000000000 --- a/Documentation/tty/tty_buffer.rst +++ /dev/null @@ -1,46 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -========== -TTY Buffer -========== - -.. contents:: :local: - -Here, we document functions for taking care of tty buffer and their flipping. -Drivers are supposed to fill the buffer by one of those functions below and -then flip the buffer, so that the data are passed to :doc:`line discipline -` for further processing. - -Flip Buffer Management -====================== - -.. kernel-doc:: drivers/tty/tty_buffer.c - :identifiers: tty_prepare_flip_string tty_insert_flip_string_fixed_flag - tty_insert_flip_string_flags __tty_insert_flip_char - tty_flip_buffer_push tty_ldisc_receive_buf - ----- - -Other Functions -=============== - -.. kernel-doc:: drivers/tty/tty_buffer.c - :identifiers: tty_buffer_space_avail tty_buffer_set_limit - ----- - -Buffer Locking -============== - -These are used only in special circumstances. Avoid them. - -.. kernel-doc:: drivers/tty/tty_buffer.c - :identifiers: tty_buffer_lock_exclusive tty_buffer_unlock_exclusive - ----- - -Internal Functions -================== - -.. kernel-doc:: drivers/tty/tty_buffer.c - :internal: diff --git a/Documentation/tty/tty_driver.rst b/Documentation/tty/tty_driver.rst deleted file mode 100644 index cc529f863406..000000000000 --- a/Documentation/tty/tty_driver.rst +++ /dev/null @@ -1,128 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -============================= -TTY Driver and TTY Operations -============================= - -.. contents:: :local: - -Allocation -========== - -The first thing a driver needs to do is to allocate a struct tty_driver. This -is done by tty_alloc_driver() (or __tty_alloc_driver()). Next, the newly -allocated structure is filled with information. See `TTY Driver Reference`_ at -the end of this document on what actually shall be filled in. - -The allocation routines expect a number of devices the driver can handle at -most and flags. Flags are those starting ``TTY_DRIVER_`` listed and described -in `TTY Driver Flags`_ below. - -When the driver is about to be freed, tty_driver_kref_put() is called on that. -It will decrements the reference count and if it reaches zero, the driver is -freed. - -For reference, both allocation and deallocation functions are explained here in -detail: - -.. kernel-doc:: drivers/tty/tty_io.c - :identifiers: __tty_alloc_driver tty_driver_kref_put - -TTY Driver Flags ----------------- - -Here comes the documentation of flags accepted by tty_alloc_driver() (or -__tty_alloc_driver()): - -.. kernel-doc:: include/linux/tty_driver.h - :doc: TTY Driver Flags - ----- - -Registration -============ - -When a struct tty_driver is allocated and filled in, it can be registered using -tty_register_driver(). It is recommended to pass ``TTY_DRIVER_DYNAMIC_DEV`` in -flags of tty_alloc_driver(). If it is not passed, *all* devices are also -registered during tty_register_driver() and the following paragraph of -registering devices can be skipped for such drivers. However, the struct -tty_port part in `Registering Devices`_ is still relevant there. - -.. kernel-doc:: drivers/tty/tty_io.c - :identifiers: tty_register_driver tty_unregister_driver - -Registering Devices -------------------- - -Every TTY device shall be backed by a struct tty_port. Usually, TTY drivers -embed tty_port into device's private structures. Further details about handling -tty_port can be found in :doc:`tty_port`. The driver is also recommended to use -tty_port's reference counting by tty_port_get() and tty_port_put(). The final -put is supposed to free the tty_port including the device's private struct. - -Unless ``TTY_DRIVER_DYNAMIC_DEV`` was passed as flags to tty_alloc_driver(), -TTY driver is supposed to register every device discovered in the system -(the latter is preferred). This is performed by tty_register_device(). Or by -tty_register_device_attr() if the driver wants to expose some information -through struct attribute_group. Both of them register ``index``'th device and -upon return, the device can be opened. There are also preferred tty_port -variants described in `Linking Devices to Ports`_ later. It is up to driver to -manage free indices and choosing the right one. The TTY layer only refuses to -register more devices than passed to tty_alloc_driver(). - -When the device is opened, the TTY layer allocates struct tty_struct and starts -calling operations from :c:member:`tty_driver.ops`, see `TTY Operations -Reference`_. - -The registration routines are documented as follows: - -.. kernel-doc:: drivers/tty/tty_io.c - :identifiers: tty_register_device tty_register_device_attr - tty_unregister_device - ----- - -Linking Devices to Ports ------------------------- -As stated earlier, every TTY device shall have a struct tty_port assigned to -it. It must be known to the TTY layer at :c:member:`tty_driver.ops.install()` -at latest. There are few helpers to *link* the two. Ideally, the driver uses -tty_port_register_device() or tty_port_register_device_attr() instead of -tty_register_device() and tty_register_device_attr() at the registration time. -This way, the driver needs not care about linking later on. - -If that is not possible, the driver still can link the tty_port to a specific -index *before* the actual registration by tty_port_link_device(). If it still -does not fit, tty_port_install() can be used from the -:c:member:`tty_driver.ops.install` hook as a last resort. The last one is -dedicated mostly for in-memory devices like PTY where tty_ports are allocated -on demand. - -The linking routines are documented here: - -.. kernel-doc:: drivers/tty/tty_port.c - :identifiers: tty_port_link_device tty_port_register_device - tty_port_register_device_attr - ----- - -TTY Driver Reference -==================== - -All members of struct tty_driver are documented here. The required members are -noted at the end. struct tty_operations are documented next. - -.. kernel-doc:: include/linux/tty_driver.h - :identifiers: tty_driver - ----- - -TTY Operations Reference -======================== - -When a TTY is registered, these driver hooks can be invoked by the TTY layer: - -.. kernel-doc:: include/linux/tty_driver.h - :identifiers: tty_operations - diff --git a/Documentation/tty/tty_internals.rst b/Documentation/tty/tty_internals.rst deleted file mode 100644 index d0d415820300..000000000000 --- a/Documentation/tty/tty_internals.rst +++ /dev/null @@ -1,31 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -============= -TTY Internals -============= - -.. contents:: :local: - -Kopen -===== - -These functions serve for opening a TTY from the kernelspace: - -.. kernel-doc:: drivers/tty/tty_io.c - :identifiers: tty_kopen_exclusive tty_kopen_shared tty_kclose - ----- - -Exported Internal Functions -=========================== - -.. kernel-doc:: drivers/tty/tty_io.c - :identifiers: tty_release_struct tty_dev_name_to_number tty_get_icount - ----- - -Internal Functions -================== - -.. kernel-doc:: drivers/tty/tty_io.c - :internal: diff --git a/Documentation/tty/tty_ldisc.rst b/Documentation/tty/tty_ldisc.rst deleted file mode 100644 index 5144751be804..000000000000 --- a/Documentation/tty/tty_ldisc.rst +++ /dev/null @@ -1,85 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -=================== -TTY Line Discipline -=================== - -.. contents:: :local: - -TTY line discipline process all incoming and outgoing character from/to a tty -device. The default line discipline is :doc:`N_TTY `. It is also a -fallback if establishing any other discipline for a tty fails. If even N_TTY -fails, N_NULL takes over. That never fails, but also does not process any -characters -- it throws them away. - -Registration -============ - -Line disciplines are registered with tty_register_ldisc() passing the ldisc -structure. At the point of registration the discipline must be ready to use and -it is possible it will get used before the call returns success. If the call -returns an error then it won’t get called. Do not re-use ldisc numbers as they -are part of the userspace ABI and writing over an existing ldisc will cause -demons to eat your computer. You must not re-register over the top of the line -discipline even with the same data or your computer again will be eaten by -demons. In order to remove a line discipline call tty_unregister_ldisc(). - -Heed this warning: the reference count field of the registered copies of the -tty_ldisc structure in the ldisc table counts the number of lines using this -discipline. The reference count of the tty_ldisc structure within a tty counts -the number of active users of the ldisc at this instant. In effect it counts -the number of threads of execution within an ldisc method (plus those about to -enter and exit although this detail matters not). - -.. kernel-doc:: drivers/tty/tty_ldisc.c - :identifiers: tty_register_ldisc tty_unregister_ldisc - -Other Functions -=============== - -.. kernel-doc:: drivers/tty/tty_ldisc.c - :identifiers: tty_set_ldisc tty_ldisc_flush - -Line Discipline Operations Reference -==================================== - -.. kernel-doc:: include/linux/tty_ldisc.h - :identifiers: tty_ldisc_ops - -Driver Access -============= - -Line discipline methods can call the methods of the underlying hardware driver. -These are documented as a part of struct tty_operations. - -TTY Flags -========= - -Line discipline methods have access to :c:member:`tty_struct.flags` field. See -:doc:`tty_struct`. - -Locking -======= - -Callers to the line discipline functions from the tty layer are required to -take line discipline locks. The same is true of calls from the driver side -but not yet enforced. - -.. kernel-doc:: drivers/tty/tty_ldisc.c - :identifiers: tty_ldisc_ref_wait tty_ldisc_ref tty_ldisc_deref - -While these functions are slightly slower than the old code they should have -minimal impact as most receive logic uses the flip buffers and they only -need to take a reference when they push bits up through the driver. - -A caution: The :c:member:`tty_ldisc_ops.open()`, -:c:member:`tty_ldisc_ops.close()` and :c:member:`tty_driver.set_ldisc()` -functions are called with the ldisc unavailable. Thus tty_ldisc_ref() will fail -in this situation if used within these functions. Ldisc and driver code -calling its own functions must be careful in this case. - -Internal Functions -================== - -.. kernel-doc:: drivers/tty/tty_ldisc.c - :internal: diff --git a/Documentation/tty/tty_port.rst b/Documentation/tty/tty_port.rst deleted file mode 100644 index 5cb90e954fcf..000000000000 --- a/Documentation/tty/tty_port.rst +++ /dev/null @@ -1,70 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -======== -TTY Port -======== - -.. contents:: :local: - -The TTY drivers are advised to use struct tty_port helpers as much as possible. -If the drivers implement :c:member:`tty_port.ops.activate()` and -:c:member:`tty_port.ops.shutdown()`, they can use tty_port_open(), -tty_port_close(), and tty_port_hangup() in respective -:c:member:`tty_struct.ops` hooks. - -The reference and details are contained in the `TTY Port Reference`_ and `TTY -Port Operations Reference`_ sections at the bottom. - -TTY Port Functions -================== - -Init & Destroy --------------- - -.. kernel-doc:: drivers/tty/tty_port.c - :identifiers: tty_port_init tty_port_destroy - tty_port_get tty_port_put - -Open/Close/Hangup Helpers -------------------------- - -.. kernel-doc:: drivers/tty/tty_port.c - :identifiers: tty_port_install tty_port_open tty_port_block_til_ready - tty_port_close tty_port_close_start tty_port_close_end tty_port_hangup - tty_port_shutdown - -TTY Refcounting ---------------- - -.. kernel-doc:: drivers/tty/tty_port.c - :identifiers: tty_port_tty_get tty_port_tty_set - -TTY Helpers ------------ - -.. kernel-doc:: drivers/tty/tty_port.c - :identifiers: tty_port_tty_hangup tty_port_tty_wakeup - - -Modem Signals -------------- - -.. kernel-doc:: drivers/tty/tty_port.c - :identifiers: tty_port_carrier_raised tty_port_raise_dtr_rts - tty_port_lower_dtr_rts - ----- - -TTY Port Reference -================== - -.. kernel-doc:: include/linux/tty_port.h - :identifiers: tty_port - ----- - -TTY Port Operations Reference -============================= - -.. kernel-doc:: include/linux/tty_port.h - :identifiers: tty_port_operations diff --git a/Documentation/tty/tty_struct.rst b/Documentation/tty/tty_struct.rst deleted file mode 100644 index c72f5a4293b2..000000000000 --- a/Documentation/tty/tty_struct.rst +++ /dev/null @@ -1,81 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -========== -TTY Struct -========== - -.. contents:: :local: - -struct tty_struct is allocated by the TTY layer upon the first open of the TTY -device and released after the last close. The TTY layer passes this structure -to most of struct tty_operation's hooks. Members of tty_struct are documented -in `TTY Struct Reference`_ at the bottom. - -Initialization -============== - -.. kernel-doc:: drivers/tty/tty_io.c - :identifiers: tty_init_termios - -Name -==== - -.. kernel-doc:: drivers/tty/tty_io.c - :identifiers: tty_name - -Reference counting -================== - -.. kernel-doc:: include/linux/tty.h - :identifiers: tty_kref_get - -.. kernel-doc:: drivers/tty/tty_io.c - :identifiers: tty_kref_put - -Install -======= - -.. kernel-doc:: drivers/tty/tty_io.c - :identifiers: tty_standard_install - -Read & Write -============ - -.. kernel-doc:: drivers/tty/tty_io.c - :identifiers: tty_put_char - -Start & Stop -============ - -.. kernel-doc:: drivers/tty/tty_io.c - :identifiers: start_tty stop_tty - -Wakeup -====== - -.. kernel-doc:: drivers/tty/tty_io.c - :identifiers: tty_wakeup - -Hangup -====== - -.. kernel-doc:: drivers/tty/tty_io.c - :identifiers: tty_hangup tty_vhangup tty_hung_up_p - -Misc -==== - -.. kernel-doc:: drivers/tty/tty_io.c - :identifiers: tty_do_resize - -TTY Struct Flags -================ - -.. kernel-doc:: include/linux/tty.h - :doc: TTY Struct Flags - -TTY Struct Reference -==================== - -.. kernel-doc:: include/linux/tty.h - :identifiers: tty_struct -- cgit From 1a4a8f6bbac07e3270805009c69e89c7de801df1 Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Mon, 11 Apr 2022 13:01:39 +0200 Subject: Documentation: tty: introduce "Other Documentation" So far only n_tty belongs here, but in the next patches, more will come. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20220411110143.10019-3-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/tty/index.rst | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/tty/index.rst b/Documentation/driver-api/tty/index.rst index 2240e52203d6..e6a7f717a9a5 100644 --- a/Documentation/driver-api/tty/index.rst +++ b/Documentation/driver-api/tty/index.rst @@ -36,7 +36,6 @@ In-detail description of the named TTY structures is in separate documents: tty_struct tty_ldisc tty_buffer - n_tty tty_internals Writing TTY Driver @@ -60,3 +59,13 @@ A *typical* sequence a TTY driver performs is as follows: Steps regarding driver, i.e. 1., 3., and 5. are described in detail in :doc:`tty_driver`. For the other two (devices handling), look into :doc:`tty_port`. + +Other Documentation +=================== + +Miscellaneous documentation can be further found in these documents: + +.. toctree:: + :maxdepth: 2 + + n_tty -- cgit From e26595034dada8a1e6c10f0e0187f43edec72698 Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Mon, 11 Apr 2022 13:01:40 +0200 Subject: Documentation: tty: move n_gsm to tty We have n_tty documented in Documentation/driver-api/tty/. n_gsm belongs there too, so move from serial/ to tty/ too. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20220411110143.10019-4-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/serial/index.rst | 1 - Documentation/driver-api/serial/n_gsm.rst | 159 ------------------------------ Documentation/driver-api/tty/index.rst | 1 + Documentation/driver-api/tty/n_gsm.rst | 159 ++++++++++++++++++++++++++++++ 4 files changed, 160 insertions(+), 160 deletions(-) delete mode 100644 Documentation/driver-api/serial/n_gsm.rst create mode 100644 Documentation/driver-api/tty/n_gsm.rst (limited to 'Documentation') diff --git a/Documentation/driver-api/serial/index.rst b/Documentation/driver-api/serial/index.rst index 7eb21a695fc3..4ebdb86cd6b6 100644 --- a/Documentation/driver-api/serial/index.rst +++ b/Documentation/driver-api/serial/index.rst @@ -17,7 +17,6 @@ Serial drivers :maxdepth: 1 moxa-smartio - n_gsm serial-iso7816 serial-rs485 diff --git a/Documentation/driver-api/serial/n_gsm.rst b/Documentation/driver-api/serial/n_gsm.rst deleted file mode 100644 index 49956509ad73..000000000000 --- a/Documentation/driver-api/serial/n_gsm.rst +++ /dev/null @@ -1,159 +0,0 @@ -============================== -GSM 0710 tty multiplexor HOWTO -============================== - -This line discipline implements the GSM 07.10 multiplexing protocol -detailed in the following 3GPP document: - - https://www.3gpp.org/ftp/Specs/archive/07_series/07.10/0710-720.zip - -This document give some hints on how to use this driver with GPRS and 3G -modems connected to a physical serial port. - -How to use it -------------- -1. config initiator -^^^^^^^^^^^^^^^^^^^^^ - -1.1 initialize the modem in 0710 mux mode (usually AT+CMUX= command) through - its serial port. Depending on the modem used, you can pass more or less - parameters to this command. - -1.2 switch the serial line to using the n_gsm line discipline by using - TIOCSETD ioctl. - -1.3 configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl. - -1.4 obtain base gsmtty number for the used serial port. - -Major parts of the initialization program : -(a good starting point is util-linux-ng/sys-utils/ldattach.c):: - - #include - #include - #include - #include - #define DEFAULT_SPEED B115200 - #define SERIAL_PORT /dev/ttyS0 - - int ldisc = N_GSM0710; - struct gsm_config c; - struct termios configuration; - uint32_t first; - - /* open the serial port connected to the modem */ - fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY); - - /* configure the serial port : speed, flow control ... */ - - /* send the AT commands to switch the modem to CMUX mode - and check that it's successful (should return OK) */ - write(fd, "AT+CMUX=0\r", 10); - - /* experience showed that some modems need some time before - being able to answer to the first MUX packet so a delay - may be needed here in some case */ - sleep(3); - - /* use n_gsm line discipline */ - ioctl(fd, TIOCSETD, &ldisc); - - /* get n_gsm configuration */ - ioctl(fd, GSMIOC_GETCONF, &c); - /* we are initiator and need encoding 0 (basic) */ - c.initiator = 1; - c.encapsulation = 0; - /* our modem defaults to a maximum size of 127 bytes */ - c.mru = 127; - c.mtu = 127; - /* set the new configuration */ - ioctl(fd, GSMIOC_SETCONF, &c); - /* get first gsmtty device node */ - ioctl(fd, GSMIOC_GETFIRST, &first); - printf("first muxed line: /dev/gsmtty%i\n", first); - - /* and wait for ever to keep the line discipline enabled */ - daemon(0,0); - pause(); - -1.5 use these devices as plain serial ports. - - for example, it's possible: - - - and to use gnokii to send / receive SMS on ttygsm1 - - to use ppp to establish a datalink on ttygsm2 - -1.6 first close all virtual ports before closing the physical port. - - Note that after closing the physical port the modem is still in multiplexing - mode. This may prevent a successful re-opening of the port later. To avoid - this situation either reset the modem if your hardware allows that or send - a disconnect command frame manually before initializing the multiplexing mode - for the second time. The byte sequence for the disconnect command frame is:: - - 0xf9, 0x03, 0xef, 0x03, 0xc3, 0x16, 0xf9. - -2. config requester -^^^^^^^^^^^^^^^^^^^^^ - -2.1 receive string "AT+CMUX= command" through its serial port,initialize - mux mode config - -2.2 switch the serial line to using the n_gsm line discipline by using - TIOCSETD ioctl. - -2.3 configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl. - -2.4 obtain base gsmtty number for the used serial port:: - - #include - #include - #include - #include - #define DEFAULT_SPEED B115200 - #define SERIAL_PORT /dev/ttyS0 - - int ldisc = N_GSM0710; - struct gsm_config c; - struct termios configuration; - uint32_t first; - - /* open the serial port */ - fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY); - - /* configure the serial port : speed, flow control ... */ - - /* get serial data and check "AT+CMUX=command" parameter ... */ - - /* use n_gsm line discipline */ - ioctl(fd, TIOCSETD, &ldisc); - - /* get n_gsm configuration */ - ioctl(fd, GSMIOC_GETCONF, &c); - /* we are requester and need encoding 0 (basic) */ - c.initiator = 0; - c.encapsulation = 0; - /* our modem defaults to a maximum size of 127 bytes */ - c.mru = 127; - c.mtu = 127; - /* set the new configuration */ - ioctl(fd, GSMIOC_SETCONF, &c); - /* get first gsmtty device node */ - ioctl(fd, GSMIOC_GETFIRST, &first); - printf("first muxed line: /dev/gsmtty%i\n", first); - - /* and wait for ever to keep the line discipline enabled */ - daemon(0,0); - pause(); - -Additional Documentation ------------------------- -More practical details on the protocol and how it's supported by industrial -modems can be found in the following documents : - -- http://www.telit.com/module/infopool/download.php?id=616 -- http://www.u-blox.com/images/downloads/Product_Docs/LEON-G100-G200-MuxImplementation_ApplicationNote_%28GSM%20G1-CS-10002%29.pdf -- http://www.sierrawireless.com/Support/Downloads/AirPrime/WMP_Series/~/media/Support_Downloads/AirPrime/Application_notes/CMUX_Feature_Application_Note-Rev004.ashx -- http://wm.sim.com/sim/News/photo/2010721161442.pdf - -11-03-08 - Eric Bénard - diff --git a/Documentation/driver-api/tty/index.rst b/Documentation/driver-api/tty/index.rst index e6a7f717a9a5..85eaac76a971 100644 --- a/Documentation/driver-api/tty/index.rst +++ b/Documentation/driver-api/tty/index.rst @@ -68,4 +68,5 @@ Miscellaneous documentation can be further found in these documents: .. toctree:: :maxdepth: 2 + n_gsm n_tty diff --git a/Documentation/driver-api/tty/n_gsm.rst b/Documentation/driver-api/tty/n_gsm.rst new file mode 100644 index 000000000000..49956509ad73 --- /dev/null +++ b/Documentation/driver-api/tty/n_gsm.rst @@ -0,0 +1,159 @@ +============================== +GSM 0710 tty multiplexor HOWTO +============================== + +This line discipline implements the GSM 07.10 multiplexing protocol +detailed in the following 3GPP document: + + https://www.3gpp.org/ftp/Specs/archive/07_series/07.10/0710-720.zip + +This document give some hints on how to use this driver with GPRS and 3G +modems connected to a physical serial port. + +How to use it +------------- +1. config initiator +^^^^^^^^^^^^^^^^^^^^^ + +1.1 initialize the modem in 0710 mux mode (usually AT+CMUX= command) through + its serial port. Depending on the modem used, you can pass more or less + parameters to this command. + +1.2 switch the serial line to using the n_gsm line discipline by using + TIOCSETD ioctl. + +1.3 configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl. + +1.4 obtain base gsmtty number for the used serial port. + +Major parts of the initialization program : +(a good starting point is util-linux-ng/sys-utils/ldattach.c):: + + #include + #include + #include + #include + #define DEFAULT_SPEED B115200 + #define SERIAL_PORT /dev/ttyS0 + + int ldisc = N_GSM0710; + struct gsm_config c; + struct termios configuration; + uint32_t first; + + /* open the serial port connected to the modem */ + fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY); + + /* configure the serial port : speed, flow control ... */ + + /* send the AT commands to switch the modem to CMUX mode + and check that it's successful (should return OK) */ + write(fd, "AT+CMUX=0\r", 10); + + /* experience showed that some modems need some time before + being able to answer to the first MUX packet so a delay + may be needed here in some case */ + sleep(3); + + /* use n_gsm line discipline */ + ioctl(fd, TIOCSETD, &ldisc); + + /* get n_gsm configuration */ + ioctl(fd, GSMIOC_GETCONF, &c); + /* we are initiator and need encoding 0 (basic) */ + c.initiator = 1; + c.encapsulation = 0; + /* our modem defaults to a maximum size of 127 bytes */ + c.mru = 127; + c.mtu = 127; + /* set the new configuration */ + ioctl(fd, GSMIOC_SETCONF, &c); + /* get first gsmtty device node */ + ioctl(fd, GSMIOC_GETFIRST, &first); + printf("first muxed line: /dev/gsmtty%i\n", first); + + /* and wait for ever to keep the line discipline enabled */ + daemon(0,0); + pause(); + +1.5 use these devices as plain serial ports. + + for example, it's possible: + + - and to use gnokii to send / receive SMS on ttygsm1 + - to use ppp to establish a datalink on ttygsm2 + +1.6 first close all virtual ports before closing the physical port. + + Note that after closing the physical port the modem is still in multiplexing + mode. This may prevent a successful re-opening of the port later. To avoid + this situation either reset the modem if your hardware allows that or send + a disconnect command frame manually before initializing the multiplexing mode + for the second time. The byte sequence for the disconnect command frame is:: + + 0xf9, 0x03, 0xef, 0x03, 0xc3, 0x16, 0xf9. + +2. config requester +^^^^^^^^^^^^^^^^^^^^^ + +2.1 receive string "AT+CMUX= command" through its serial port,initialize + mux mode config + +2.2 switch the serial line to using the n_gsm line discipline by using + TIOCSETD ioctl. + +2.3 configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl. + +2.4 obtain base gsmtty number for the used serial port:: + + #include + #include + #include + #include + #define DEFAULT_SPEED B115200 + #define SERIAL_PORT /dev/ttyS0 + + int ldisc = N_GSM0710; + struct gsm_config c; + struct termios configuration; + uint32_t first; + + /* open the serial port */ + fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY); + + /* configure the serial port : speed, flow control ... */ + + /* get serial data and check "AT+CMUX=command" parameter ... */ + + /* use n_gsm line discipline */ + ioctl(fd, TIOCSETD, &ldisc); + + /* get n_gsm configuration */ + ioctl(fd, GSMIOC_GETCONF, &c); + /* we are requester and need encoding 0 (basic) */ + c.initiator = 0; + c.encapsulation = 0; + /* our modem defaults to a maximum size of 127 bytes */ + c.mru = 127; + c.mtu = 127; + /* set the new configuration */ + ioctl(fd, GSMIOC_SETCONF, &c); + /* get first gsmtty device node */ + ioctl(fd, GSMIOC_GETFIRST, &first); + printf("first muxed line: /dev/gsmtty%i\n", first); + + /* and wait for ever to keep the line discipline enabled */ + daemon(0,0); + pause(); + +Additional Documentation +------------------------ +More practical details on the protocol and how it's supported by industrial +modems can be found in the following documents : + +- http://www.telit.com/module/infopool/download.php?id=616 +- http://www.u-blox.com/images/downloads/Product_Docs/LEON-G100-G200-MuxImplementation_ApplicationNote_%28GSM%20G1-CS-10002%29.pdf +- http://www.sierrawireless.com/Support/Downloads/AirPrime/WMP_Series/~/media/Support_Downloads/AirPrime/Application_notes/CMUX_Feature_Application_Note-Rev004.ashx +- http://wm.sim.com/sim/News/photo/2010721161442.pdf + +11-03-08 - Eric Bénard - -- cgit From 5b437ae9fcbb22fe6de3c715534515209207a092 Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Mon, 11 Apr 2022 13:01:41 +0200 Subject: Documentation: tty: move moxa-smartio.rst to tty It is a tty_driver, not serial -- uart_driver. So move it to the tty docs dir too. (The same as the driver itself.) Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20220411110143.10019-5-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/serial/index.rst | 1 - Documentation/driver-api/serial/moxa-smartio.rst | 197 ----------------------- Documentation/driver-api/tty/index.rst | 1 + Documentation/driver-api/tty/moxa-smartio.rst | 197 +++++++++++++++++++++++ 4 files changed, 198 insertions(+), 198 deletions(-) delete mode 100644 Documentation/driver-api/serial/moxa-smartio.rst create mode 100644 Documentation/driver-api/tty/moxa-smartio.rst (limited to 'Documentation') diff --git a/Documentation/driver-api/serial/index.rst b/Documentation/driver-api/serial/index.rst index 4ebdb86cd6b6..03a55b987a1d 100644 --- a/Documentation/driver-api/serial/index.rst +++ b/Documentation/driver-api/serial/index.rst @@ -16,7 +16,6 @@ Serial drivers .. toctree:: :maxdepth: 1 - moxa-smartio serial-iso7816 serial-rs485 diff --git a/Documentation/driver-api/serial/moxa-smartio.rst b/Documentation/driver-api/serial/moxa-smartio.rst deleted file mode 100644 index af25bc5cc3e6..000000000000 --- a/Documentation/driver-api/serial/moxa-smartio.rst +++ /dev/null @@ -1,197 +0,0 @@ -============================================================= -MOXA Smartio/Industio Family Device Driver Installation Guide -============================================================= - -Copyright (C) 2008, Moxa Inc. -Copyright (C) 2021, Jiri Slaby - -.. Content - - 1. Introduction - 2. System Requirement - 3. Installation - 3.1 Hardware installation - 3.2 Device naming convention - 4. Utilities - 5. Setserial - 6. Troubleshooting - -1. Introduction -^^^^^^^^^^^^^^^ - - The Smartio/Industio/UPCI family Linux driver supports following multiport - boards: - - - 2 ports multiport board - CP-102U, CP-102UL, CP-102UF - CP-132U-I, CP-132UL, - CP-132, CP-132I, CP132S, CP-132IS, - (CP-102, CP-102S) - - - 4 ports multiport board - CP-104EL, - CP-104UL, CP-104JU, - CP-134U, CP-134U-I, - C104H/PCI, C104HS/PCI, - CP-114, CP-114I, CP-114S, CP-114IS, CP-114UL, - (C114HI, CT-114I), - POS-104UL, - CB-114, - CB-134I - - - 8 ports multiport board - CP-118EL, CP-168EL, - CP-118U, CP-168U, - C168H/PCI, - CB-108 - - If a compatibility problem occurs, please contact Moxa at - support@moxa.com.tw. - - In addition to device driver, useful utilities are also provided in this - version. They are: - - - msdiag - Diagnostic program for displaying installed Moxa - Smartio/Industio boards. - - msmon - Monitor program to observe data count and line status signals. - - msterm A simple terminal program which is useful in testing serial - ports. - - All the drivers and utilities are published in form of source code under - GNU General Public License in this version. Please refer to GNU General - Public License announcement in each source code file for more detail. - - In Moxa's Web sites, you may always find the latest driver at - https://www.moxa.com/. - - This version of driver can be installed as a Loadable Module (Module driver) - or built-in into kernel (Static driver). Before you install the driver, - please refer to hardware installation procedure in the User's Manual. - - We assume the user should be familiar with following documents: - - - Serial-HOWTO - - Kernel-HOWTO - -2. System Requirement -^^^^^^^^^^^^^^^^^^^^^ - - - Maximum 4 boards can be installed in combination - -3. Installation -^^^^^^^^^^^^^^^ - -3.1 Hardware installation -========================= - -PCI/UPCI board --------------- - - You may need to adjust IRQ usage in BIOS to avoid IRQ conflict with other - ISA devices. Please refer to hardware installation procedure in User's - Manual in advance. - -PCI IRQ Sharing ---------------- - - Each port within the same multiport board shares the same IRQ. Up to - 4 Moxa Smartio/Industio PCI Family multiport boards can be installed - together on one system and they can share the same IRQ. - - - -3.2 Device naming convention -============================ - - The device node is named "ttyMxx". - -Device naming when more than 2 boards installed ------------------------------------------------ - - Naming convention for each Smartio/Industio multiport board is - pre-defined as below. - - ============ =============== - Board Num. Device node - 1st board ttyM0 - ttyM7 - 2nd board ttyM8 - ttyM15 - 3rd board ttyM16 - ttyM23 - 4th board ttyM24 - ttyM31 - ============ =============== - -4. Utilities -^^^^^^^^^^^^ - - There are 3 utilities contained in this driver. They are msdiag, msmon and - msterm. These 3 utilities are released in form of source code. They should - be compiled into executable file and copied into /usr/bin. - -msdiag - Diagnostic -=================== - - This utility provides the function to display what Moxa Smartio/Industio - board was found by the driver in the system. - -msmon - Port Monitoring -======================= - - This utility gives the user a quick view about all the MOXA ports' - activities. One can easily learn each port's total received/transmitted - (Rx/Tx) character count since the time when the monitoring is started. - - Rx/Tx throughputs per second are also reported in interval basis (e.g. - the last 5 seconds) and in average basis (since the time the monitoring - is started). You can reset all ports' count by key. <+> <-> - (plus/minus) keys to change the displaying time interval. Press - on the port, that cursor stay, to view the port's communication - parameters, signal status, and input/output queue. - -msterm - Terminal Emulation -=========================== - - This utility provides data sending and receiving ability of all tty ports, - especially for MOXA ports. It is quite useful for testing simple - application, for example, sending AT command to a modem connected to the - port or used as a terminal for login purpose. Note that this is only a - dumb terminal emulation without handling full screen operation. - -5. Setserial -^^^^^^^^^^^^ - - Supported Setserial parameters are listed as below. - - ============== ============================================================= - uart set UART type(16450 --> disable FIFO, 16550A --> enable FIFO) - close_delay set the amount of time (in 1/100 of a second) that DTR - should be kept low while being closed. - closing_wait set the amount of time (in 1/100 of a second) that the - serial port should wait for data to be drained while - being closed, before the receiver is disabled. - spd_hi Use 57.6kb when the application requests 38.4kb. - spd_vhi Use 115.2kb when the application requests 38.4kb. - spd_shi Use 230.4kb when the application requests 38.4kb. - spd_warp Use 460.8kb when the application requests 38.4kb. - spd_normal Use 38.4kb when the application requests 38.4kb. - spd_cust Use the custom divisor to set the speed when the - application requests 38.4kb. - divisor This option sets the custom division. - baud_base This option sets the base baud rate. - ============== ============================================================= - -6. Troubleshooting -^^^^^^^^^^^^^^^^^^ - - The boot time error messages and solutions are stated as clearly as - possible. If all the possible solutions fail, please contact our technical - support team to get more help. - - - Error msg: - More than 4 Moxa Smartio/Industio family boards found. Fifth board - and after are ignored. - - Solution: - To avoid this problem, please unplug fifth and after board, because Moxa - driver supports up to 4 boards. diff --git a/Documentation/driver-api/tty/index.rst b/Documentation/driver-api/tty/index.rst index 85eaac76a971..2d32606a4278 100644 --- a/Documentation/driver-api/tty/index.rst +++ b/Documentation/driver-api/tty/index.rst @@ -68,5 +68,6 @@ Miscellaneous documentation can be further found in these documents: .. toctree:: :maxdepth: 2 + moxa-smartio n_gsm n_tty diff --git a/Documentation/driver-api/tty/moxa-smartio.rst b/Documentation/driver-api/tty/moxa-smartio.rst new file mode 100644 index 000000000000..af25bc5cc3e6 --- /dev/null +++ b/Documentation/driver-api/tty/moxa-smartio.rst @@ -0,0 +1,197 @@ +============================================================= +MOXA Smartio/Industio Family Device Driver Installation Guide +============================================================= + +Copyright (C) 2008, Moxa Inc. +Copyright (C) 2021, Jiri Slaby + +.. Content + + 1. Introduction + 2. System Requirement + 3. Installation + 3.1 Hardware installation + 3.2 Device naming convention + 4. Utilities + 5. Setserial + 6. Troubleshooting + +1. Introduction +^^^^^^^^^^^^^^^ + + The Smartio/Industio/UPCI family Linux driver supports following multiport + boards: + + - 2 ports multiport board + CP-102U, CP-102UL, CP-102UF + CP-132U-I, CP-132UL, + CP-132, CP-132I, CP132S, CP-132IS, + (CP-102, CP-102S) + + - 4 ports multiport board + CP-104EL, + CP-104UL, CP-104JU, + CP-134U, CP-134U-I, + C104H/PCI, C104HS/PCI, + CP-114, CP-114I, CP-114S, CP-114IS, CP-114UL, + (C114HI, CT-114I), + POS-104UL, + CB-114, + CB-134I + + - 8 ports multiport board + CP-118EL, CP-168EL, + CP-118U, CP-168U, + C168H/PCI, + CB-108 + + If a compatibility problem occurs, please contact Moxa at + support@moxa.com.tw. + + In addition to device driver, useful utilities are also provided in this + version. They are: + + - msdiag + Diagnostic program for displaying installed Moxa + Smartio/Industio boards. + - msmon + Monitor program to observe data count and line status signals. + - msterm A simple terminal program which is useful in testing serial + ports. + + All the drivers and utilities are published in form of source code under + GNU General Public License in this version. Please refer to GNU General + Public License announcement in each source code file for more detail. + + In Moxa's Web sites, you may always find the latest driver at + https://www.moxa.com/. + + This version of driver can be installed as a Loadable Module (Module driver) + or built-in into kernel (Static driver). Before you install the driver, + please refer to hardware installation procedure in the User's Manual. + + We assume the user should be familiar with following documents: + + - Serial-HOWTO + - Kernel-HOWTO + +2. System Requirement +^^^^^^^^^^^^^^^^^^^^^ + + - Maximum 4 boards can be installed in combination + +3. Installation +^^^^^^^^^^^^^^^ + +3.1 Hardware installation +========================= + +PCI/UPCI board +-------------- + + You may need to adjust IRQ usage in BIOS to avoid IRQ conflict with other + ISA devices. Please refer to hardware installation procedure in User's + Manual in advance. + +PCI IRQ Sharing +--------------- + + Each port within the same multiport board shares the same IRQ. Up to + 4 Moxa Smartio/Industio PCI Family multiport boards can be installed + together on one system and they can share the same IRQ. + + + +3.2 Device naming convention +============================ + + The device node is named "ttyMxx". + +Device naming when more than 2 boards installed +----------------------------------------------- + + Naming convention for each Smartio/Industio multiport board is + pre-defined as below. + + ============ =============== + Board Num. Device node + 1st board ttyM0 - ttyM7 + 2nd board ttyM8 - ttyM15 + 3rd board ttyM16 - ttyM23 + 4th board ttyM24 - ttyM31 + ============ =============== + +4. Utilities +^^^^^^^^^^^^ + + There are 3 utilities contained in this driver. They are msdiag, msmon and + msterm. These 3 utilities are released in form of source code. They should + be compiled into executable file and copied into /usr/bin. + +msdiag - Diagnostic +=================== + + This utility provides the function to display what Moxa Smartio/Industio + board was found by the driver in the system. + +msmon - Port Monitoring +======================= + + This utility gives the user a quick view about all the MOXA ports' + activities. One can easily learn each port's total received/transmitted + (Rx/Tx) character count since the time when the monitoring is started. + + Rx/Tx throughputs per second are also reported in interval basis (e.g. + the last 5 seconds) and in average basis (since the time the monitoring + is started). You can reset all ports' count by key. <+> <-> + (plus/minus) keys to change the displaying time interval. Press + on the port, that cursor stay, to view the port's communication + parameters, signal status, and input/output queue. + +msterm - Terminal Emulation +=========================== + + This utility provides data sending and receiving ability of all tty ports, + especially for MOXA ports. It is quite useful for testing simple + application, for example, sending AT command to a modem connected to the + port or used as a terminal for login purpose. Note that this is only a + dumb terminal emulation without handling full screen operation. + +5. Setserial +^^^^^^^^^^^^ + + Supported Setserial parameters are listed as below. + + ============== ============================================================= + uart set UART type(16450 --> disable FIFO, 16550A --> enable FIFO) + close_delay set the amount of time (in 1/100 of a second) that DTR + should be kept low while being closed. + closing_wait set the amount of time (in 1/100 of a second) that the + serial port should wait for data to be drained while + being closed, before the receiver is disabled. + spd_hi Use 57.6kb when the application requests 38.4kb. + spd_vhi Use 115.2kb when the application requests 38.4kb. + spd_shi Use 230.4kb when the application requests 38.4kb. + spd_warp Use 460.8kb when the application requests 38.4kb. + spd_normal Use 38.4kb when the application requests 38.4kb. + spd_cust Use the custom divisor to set the speed when the + application requests 38.4kb. + divisor This option sets the custom division. + baud_base This option sets the base baud rate. + ============== ============================================================= + +6. Troubleshooting +^^^^^^^^^^^^^^^^^^ + + The boot time error messages and solutions are stated as clearly as + possible. If all the possible solutions fail, please contact our technical + support team to get more help. + + + Error msg: + More than 4 Moxa Smartio/Industio family boards found. Fifth board + and after are ignored. + + Solution: + To avoid this problem, please unplug fifth and after board, because Moxa + driver supports up to 4 boards. -- cgit From e937eb43b8791cd55bd518d1ffc747d3430d8ec9 Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Mon, 11 Apr 2022 13:01:42 +0200 Subject: Documentation: tty: n_gsm, delete "Additional Documentation" All of the URLs give 404. There is a little point to preserve them. If really need be, we could try archive.org if the documents are not there by a chance. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20220411110143.10019-6-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/tty/n_gsm.rst | 10 ---------- 1 file changed, 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/tty/n_gsm.rst b/Documentation/driver-api/tty/n_gsm.rst index 49956509ad73..04308a7a194a 100644 --- a/Documentation/driver-api/tty/n_gsm.rst +++ b/Documentation/driver-api/tty/n_gsm.rst @@ -146,14 +146,4 @@ Major parts of the initialization program : daemon(0,0); pause(); -Additional Documentation ------------------------- -More practical details on the protocol and how it's supported by industrial -modems can be found in the following documents : - -- http://www.telit.com/module/infopool/download.php?id=616 -- http://www.u-blox.com/images/downloads/Product_Docs/LEON-G100-G200-MuxImplementation_ApplicationNote_%28GSM%20G1-CS-10002%29.pdf -- http://www.sierrawireless.com/Support/Downloads/AirPrime/WMP_Series/~/media/Support_Downloads/AirPrime/Application_notes/CMUX_Feature_Application_Note-Rev004.ashx -- http://wm.sim.com/sim/News/photo/2010721161442.pdf - 11-03-08 - Eric Bénard - -- cgit From 7fb4028fbb97d6c71c30556e81eb8ce07eef7b8b Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Mon, 11 Apr 2022 13:01:43 +0200 Subject: Documentation: tty: n_gsm, use power of ReST Reformat the whole document, so that automatic numbering and TOC is properly generated. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20220411110143.10019-7-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/tty/n_gsm.rst | 144 +++++++++++++++++---------------- 1 file changed, 74 insertions(+), 70 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/tty/n_gsm.rst b/Documentation/driver-api/tty/n_gsm.rst index 04308a7a194a..35d7381515b0 100644 --- a/Documentation/driver-api/tty/n_gsm.rst +++ b/Documentation/driver-api/tty/n_gsm.rst @@ -2,6 +2,8 @@ GSM 0710 tty multiplexor HOWTO ============================== +.. contents:: :local: + This line discipline implements the GSM 07.10 multiplexing protocol detailed in the following 3GPP document: @@ -11,79 +13,81 @@ This document give some hints on how to use this driver with GPRS and 3G modems connected to a physical serial port. How to use it -------------- -1. config initiator -^^^^^^^^^^^^^^^^^^^^^ +============= -1.1 initialize the modem in 0710 mux mode (usually AT+CMUX= command) through - its serial port. Depending on the modem used, you can pass more or less - parameters to this command. +Config Initiator +---------------- -1.2 switch the serial line to using the n_gsm line discipline by using - TIOCSETD ioctl. +#. Initialize the modem in 0710 mux mode (usually ``AT+CMUX=`` command) through + its serial port. Depending on the modem used, you can pass more or less + parameters to this command. -1.3 configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl. +#. Switch the serial line to using the n_gsm line discipline by using + ``TIOCSETD`` ioctl. -1.4 obtain base gsmtty number for the used serial port. +#. Configure the mux using ``GSMIOC_GETCONF``/``GSMIOC_SETCONF`` ioctl. -Major parts of the initialization program : -(a good starting point is util-linux-ng/sys-utils/ldattach.c):: +#. Obtain base gsmtty number for the used serial port. - #include - #include - #include - #include - #define DEFAULT_SPEED B115200 - #define SERIAL_PORT /dev/ttyS0 + Major parts of the initialization program + (a good starting point is util-linux-ng/sys-utils/ldattach.c):: - int ldisc = N_GSM0710; - struct gsm_config c; - struct termios configuration; - uint32_t first; + #include + #include + #include + #include - /* open the serial port connected to the modem */ - fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY); + #define DEFAULT_SPEED B115200 + #define SERIAL_PORT /dev/ttyS0 - /* configure the serial port : speed, flow control ... */ + int ldisc = N_GSM0710; + struct gsm_config c; + struct termios configuration; + uint32_t first; - /* send the AT commands to switch the modem to CMUX mode - and check that it's successful (should return OK) */ - write(fd, "AT+CMUX=0\r", 10); + /* open the serial port connected to the modem */ + fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY); - /* experience showed that some modems need some time before - being able to answer to the first MUX packet so a delay - may be needed here in some case */ - sleep(3); + /* configure the serial port : speed, flow control ... */ - /* use n_gsm line discipline */ - ioctl(fd, TIOCSETD, &ldisc); + /* send the AT commands to switch the modem to CMUX mode + and check that it's successful (should return OK) */ + write(fd, "AT+CMUX=0\r", 10); - /* get n_gsm configuration */ - ioctl(fd, GSMIOC_GETCONF, &c); - /* we are initiator and need encoding 0 (basic) */ - c.initiator = 1; - c.encapsulation = 0; - /* our modem defaults to a maximum size of 127 bytes */ - c.mru = 127; - c.mtu = 127; - /* set the new configuration */ - ioctl(fd, GSMIOC_SETCONF, &c); - /* get first gsmtty device node */ - ioctl(fd, GSMIOC_GETFIRST, &first); - printf("first muxed line: /dev/gsmtty%i\n", first); + /* experience showed that some modems need some time before + being able to answer to the first MUX packet so a delay + may be needed here in some case */ + sleep(3); - /* and wait for ever to keep the line discipline enabled */ - daemon(0,0); - pause(); + /* use n_gsm line discipline */ + ioctl(fd, TIOCSETD, &ldisc); + + /* get n_gsm configuration */ + ioctl(fd, GSMIOC_GETCONF, &c); + /* we are initiator and need encoding 0 (basic) */ + c.initiator = 1; + c.encapsulation = 0; + /* our modem defaults to a maximum size of 127 bytes */ + c.mru = 127; + c.mtu = 127; + /* set the new configuration */ + ioctl(fd, GSMIOC_SETCONF, &c); + /* get first gsmtty device node */ + ioctl(fd, GSMIOC_GETFIRST, &first); + printf("first muxed line: /dev/gsmtty%i\n", first); + + /* and wait for ever to keep the line discipline enabled */ + daemon(0,0); + pause(); -1.5 use these devices as plain serial ports. +#. Use these devices as plain serial ports. - for example, it's possible: + For example, it's possible: - - and to use gnokii to send / receive SMS on ttygsm1 - - to use ppp to establish a datalink on ttygsm2 + - to use *gnokii* to send / receive SMS on ``ttygsm1`` + - to use *ppp* to establish a datalink on ``ttygsm2`` -1.6 first close all virtual ports before closing the physical port. +#. First close all virtual ports before closing the physical port. Note that after closing the physical port the modem is still in multiplexing mode. This may prevent a successful re-opening of the port later. To avoid @@ -91,27 +95,27 @@ Major parts of the initialization program : a disconnect command frame manually before initializing the multiplexing mode for the second time. The byte sequence for the disconnect command frame is:: - 0xf9, 0x03, 0xef, 0x03, 0xc3, 0x16, 0xf9. + 0xf9, 0x03, 0xef, 0x03, 0xc3, 0x16, 0xf9 -2. config requester -^^^^^^^^^^^^^^^^^^^^^ +Config Requester +---------------- -2.1 receive string "AT+CMUX= command" through its serial port,initialize - mux mode config +#. Receive ``AT+CMUX=`` command through its serial port, initialize mux mode + config. -2.2 switch the serial line to using the n_gsm line discipline by using - TIOCSETD ioctl. +#. Switch the serial line to using the *n_gsm* line discipline by using + ``TIOCSETD`` ioctl. -2.3 configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl. +#. Configure the mux using ``GSMIOC_GETCONF``/``GSMIOC_SETCONF`` ioctl. -2.4 obtain base gsmtty number for the used serial port:: +#. Obtain base gsmtty number for the used serial port:: - #include - #include - #include - #include - #define DEFAULT_SPEED B115200 - #define SERIAL_PORT /dev/ttyS0 + #include + #include + #include + #include + #define DEFAULT_SPEED B115200 + #define SERIAL_PORT /dev/ttyS0 int ldisc = N_GSM0710; struct gsm_config c; -- cgit From 5a674d9dc9a097308e8f5848b8439e8a3eeac846 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 13 Apr 2022 09:01:21 -0500 Subject: dt-bindings: Fix array constraints on scalar properties Scalar properties shouldn't have array constraints (minItems, maxItems, items). These constraints can simply be dropped with any constraints under 'items' moved up a level. Cc: Agathe Porte Cc: Guenter Roeck Cc: Jean Delvare Cc: Krzysztof Kozlowski Cc: Olivier Moysan Cc: Arnaud Pouliquen Cc: Jonathan Cameron Cc: Lars-Peter Clausen Cc: Philipp Zabel Cc: Mauro Carvalho Chehab Cc: Bjorn Andersson Cc: Mathieu Poirier Cc: Mark Brown Cc: Fabrice Gasnier Cc: Yunfei Dong Cc: Geert Uytterhoeven Cc: linux-hwmon@vger.kernel.org Cc: alsa-devel@alsa-project.org Cc: linux-iio@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: linux-remoteproc@vger.kernel.org Cc: linux-spi@vger.kernel.org Signed-off-by: Rob Herring Acked-by: Jonathan Cameron Reviewed-by: Philipp Zabel Acked-by: Mark Brown Reviewed-by: Geert Uytterhoeven Acked-by: Guenter Roeck Link: https://lore.kernel.org/r/20220413140121.3132837-1-robh@kernel.org --- Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml | 5 ++--- Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 4 +--- Documentation/devicetree/bindings/media/coda.yaml | 1 - Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml | 2 -- Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml | 2 -- .../devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml | 1 - .../devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml | 4 +--- Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml | 2 -- 8 files changed, 4 insertions(+), 17 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml index 801ca9ba7d34..e7493e25a7d2 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml @@ -58,9 +58,8 @@ patternProperties: The value (two's complement) to be programmed in the channel specific N correction register. For remote channels only. $ref: /schemas/types.yaml#/definitions/int32 - items: - minimum: -128 - maximum: 127 + minimum: -128 + maximum: 127 required: - reg diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml index 912372706280..92f9472a77ae 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml @@ -108,9 +108,7 @@ patternProperties: - [1-5]: order 1 to 5. For audio purpose it is recommended to use order 3 to 5. $ref: /schemas/types.yaml#/definitions/uint32 - items: - minimum: 0 - maximum: 5 + maximum: 5 "#io-channel-cells": const: 1 diff --git a/Documentation/devicetree/bindings/media/coda.yaml b/Documentation/devicetree/bindings/media/coda.yaml index 36781ee4617f..c9d5adbc8c4a 100644 --- a/Documentation/devicetree/bindings/media/coda.yaml +++ b/Documentation/devicetree/bindings/media/coda.yaml @@ -65,7 +65,6 @@ properties: iram: $ref: /schemas/types.yaml#/definitions/phandle description: phandle pointing to the SRAM device node - maxItems: 1 required: - compatible diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml index 9b179bb44dfb..aa55ca65d6ed 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml @@ -63,13 +63,11 @@ properties: mediatek,vpu: $ref: /schemas/types.yaml#/definitions/phandle - maxItems: 1 description: Describes point to vpu. mediatek,scp: $ref: /schemas/types.yaml#/definitions/phandle - maxItems: 1 description: Describes point to scp. diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml index df7df06c378f..deb5b657a2d5 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml @@ -55,13 +55,11 @@ properties: mediatek,vpu: $ref: /schemas/types.yaml#/definitions/phandle - maxItems: 1 description: Describes point to vpu. mediatek,scp: $ref: /schemas/types.yaml#/definitions/phandle - maxItems: 1 description: Describes point to scp. diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml index 7687be0f50aa..c73bf2352aca 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml @@ -61,7 +61,6 @@ properties: mediatek,scp: $ref: /schemas/types.yaml#/definitions/phandle - maxItems: 1 description: | The node of system control processor (SCP), using the remoteproc & rpmsg framework. diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml index 2424de733ee4..d99a729d2710 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml @@ -104,8 +104,7 @@ properties: qcom,smem-state-names: $ref: /schemas/types.yaml#/definitions/string description: The names of the state bits used for SMP2P output - items: - - const: stop + const: stop glink-edge: type: object @@ -130,7 +129,6 @@ properties: qcom,remote-pid: $ref: /schemas/types.yaml#/definitions/uint32 description: ID of the shared memory used by GLINK for communication with WPSS - maxItems: 1 required: - interrupts diff --git a/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml b/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml index b104899205f6..5de710adfa63 100644 --- a/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml +++ b/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml @@ -124,7 +124,6 @@ properties: description: | Override the default TX fifo size. Unit is words. Ignored if 0. $ref: /schemas/types.yaml#/definitions/uint32 - maxItems: 1 default: 64 renesas,rx-fifo-size: @@ -132,7 +131,6 @@ properties: description: | Override the default RX fifo size. Unit is words. Ignored if 0. $ref: /schemas/types.yaml#/definitions/uint32 - maxItems: 1 default: 64 required: -- cgit From 652980b1541c5a02e6410647c7daf840c06d724a Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 13 Apr 2022 09:00:15 -0500 Subject: dt-bindings: display: panel-timing: Define a single type for properties It's not good practice to define multiple types for the same property, so factor out the type reference making the properties always an uint32-array with a length of 1 or 3 items. Signed-off-by: Rob Herring Reviewed-by: Sam Ravnborg Link: https://lore.kernel.org/r/20220413140016.3131013-1-robh@kernel.org --- .../bindings/display/panel/panel-timing.yaml | 42 ++++++++++------------ 1 file changed, 18 insertions(+), 24 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml index 9bf592dc3033..7749de95ee40 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml @@ -71,78 +71,72 @@ properties: hfront-porch: description: Horizontal front porch panel timing + $ref: /schemas/types.yaml#/definitions/uint32-array oneOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - maxItems: 1 + - maxItems: 1 items: description: typical number of pixels - - $ref: /schemas/types.yaml#/definitions/uint32-array - minItems: 3 + - minItems: 3 maxItems: 3 items: description: min, typ, max number of pixels hback-porch: description: Horizontal back porch timing + $ref: /schemas/types.yaml#/definitions/uint32-array oneOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - maxItems: 1 + - maxItems: 1 items: description: typical number of pixels - - $ref: /schemas/types.yaml#/definitions/uint32-array - minItems: 3 + - minItems: 3 maxItems: 3 items: description: min, typ, max number of pixels hsync-len: description: Horizontal sync length panel timing + $ref: /schemas/types.yaml#/definitions/uint32-array oneOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - maxItems: 1 + - maxItems: 1 items: description: typical number of pixels - - $ref: /schemas/types.yaml#/definitions/uint32-array - minItems: 3 + - minItems: 3 maxItems: 3 items: description: min, typ, max number of pixels vfront-porch: description: Vertical front porch panel timing + $ref: /schemas/types.yaml#/definitions/uint32-array oneOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - maxItems: 1 + - maxItems: 1 items: description: typical number of lines - - $ref: /schemas/types.yaml#/definitions/uint32-array - minItems: 3 + - minItems: 3 maxItems: 3 items: description: min, typ, max number of lines vback-porch: description: Vertical back porch panel timing + $ref: /schemas/types.yaml#/definitions/uint32-array oneOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - maxItems: 1 + - maxItems: 1 items: description: typical number of lines - - $ref: /schemas/types.yaml#/definitions/uint32-array - minItems: 3 + - minItems: 3 maxItems: 3 items: description: min, typ, max number of lines vsync-len: description: Vertical sync length panel timing + $ref: /schemas/types.yaml#/definitions/uint32-array oneOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - maxItems: 1 + - maxItems: 1 items: description: typical number of lines - - $ref: /schemas/types.yaml#/definitions/uint32-array - minItems: 3 + - minItems: 3 maxItems: 3 items: description: min, typ, max number of lines -- cgit From a7dbdfda0c42bda6088d02da15c4e56f5094426a Mon Sep 17 00:00:00 2001 From: Kai Ye Date: Sat, 9 Apr 2022 16:03:22 +0800 Subject: Documentation: update debugfs doc for Hisilicon HPRE Update documentation describing DebugFS that could help to check the change of register values. Signed-off-by: Kai Ye Signed-off-by: Herbert Xu --- Documentation/ABI/testing/debugfs-hisi-hpre | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-hisi-hpre b/Documentation/ABI/testing/debugfs-hisi-hpre index 396de7bc735d..82abf92df429 100644 --- a/Documentation/ABI/testing/debugfs-hisi-hpre +++ b/Documentation/ABI/testing/debugfs-hisi-hpre @@ -104,6 +104,20 @@ Description: Dump the status of the QM. Four states: initiated, started, stopped and closed. Available for both PF and VF, and take no other effect on HPRE. +What: /sys/kernel/debug/hisi_hpre//qm/diff_regs +Date: Mar 2022 +Contact: linux-crypto@vger.kernel.org +Description: QM debug registers(regs) read hardware register value. This + node is used to show the change of the qm register values. This + node can be help users to check the change of register values. + +What: /sys/kernel/debug/hisi_hpre//hpre_dfx/diff_regs +Date: Mar 2022 +Contact: linux-crypto@vger.kernel.org +Description: HPRE debug registers(regs) read hardware register value. This + node is used to show the change of the register values. This + node can be help users to check the change of register values. + What: /sys/kernel/debug/hisi_hpre//hpre_dfx/send_cnt Date: Apr 2020 Contact: linux-crypto@vger.kernel.org -- cgit From 73e3b46e90a34657bc31fa4886f21800041fd397 Mon Sep 17 00:00:00 2001 From: Kai Ye Date: Sat, 9 Apr 2022 16:03:23 +0800 Subject: Documentation: update debugfs doc for Hisilicon SEC Update documentation describing DebugFS that could help to check the change of register values. Signed-off-by: Kai Ye Signed-off-by: Herbert Xu --- Documentation/ABI/testing/debugfs-hisi-sec | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-hisi-sec b/Documentation/ABI/testing/debugfs-hisi-sec index 2bf84ced484b..93c530d1bf0f 100644 --- a/Documentation/ABI/testing/debugfs-hisi-sec +++ b/Documentation/ABI/testing/debugfs-hisi-sec @@ -84,6 +84,20 @@ Description: Dump the status of the QM. Four states: initiated, started, stopped and closed. Available for both PF and VF, and take no other effect on SEC. +What: /sys/kernel/debug/hisi_sec2//qm/diff_regs +Date: Mar 2022 +Contact: linux-crypto@vger.kernel.org +Description: QM debug registers(regs) read hardware register value. This + node is used to show the change of the qm register values. This + node can be help users to check the change of register values. + +What: /sys/kernel/debug/hisi_sec2//sec_dfx/diff_regs +Date: Mar 2022 +Contact: linux-crypto@vger.kernel.org +Description: SEC debug registers(regs) read hardware register value. This + node is used to show the change of the register values. This + node can be help users to check the change of register values. + What: /sys/kernel/debug/hisi_sec2//sec_dfx/send_cnt Date: Apr 2020 Contact: linux-crypto@vger.kernel.org -- cgit From 30169c5b550a71a47b0aecd9c254dc3a1d5bf4a7 Mon Sep 17 00:00:00 2001 From: Kai Ye Date: Sat, 9 Apr 2022 16:03:24 +0800 Subject: Documentation: update debugfs doc for Hisilicon ZIP Update documentation describing DebugFS that could help to check the change of register values. Signed-off-by: Kai Ye Signed-off-by: Herbert Xu --- Documentation/ABI/testing/debugfs-hisi-zip | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-hisi-zip b/Documentation/ABI/testing/debugfs-hisi-zip index bf1258bc6495..fd3f314cf8d1 100644 --- a/Documentation/ABI/testing/debugfs-hisi-zip +++ b/Documentation/ABI/testing/debugfs-hisi-zip @@ -97,6 +97,20 @@ Description: Dump the status of the QM. Four states: initiated, started, stopped and closed. Available for both PF and VF, and take no other effect on ZIP. +What: /sys/kernel/debug/hisi_zip//qm/diff_regs +Date: Mar 2022 +Contact: linux-crypto@vger.kernel.org +Description: QM debug registers(regs) read hardware register value. This + node is used to show the change of the qm registers value. This + node can be help users to check the change of register values. + +What: /sys/kernel/debug/hisi_zip//zip_dfx/diff_regs +Date: Mar 2022 +Contact: linux-crypto@vger.kernel.org +Description: ZIP debug registers(regs) read hardware register value. This + node is used to show the change of the registers value. this + node can be help users to check the change of register values. + What: /sys/kernel/debug/hisi_zip//zip_dfx/send_cnt Date: Apr 2020 Contact: linux-crypto@vger.kernel.org -- cgit From ef9a23f358383376009bac2a0262be1fff3eda70 Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Wed, 30 Mar 2022 14:15:37 +0900 Subject: dt-bindings: serial: uniphier: Use maxItems for a single clock 'maxItems' is preferred for a single entry, not 'minItems'. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Kunihiko Hayashi Link: https://lore.kernel.org/r/1648617338-8600-2-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml b/Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml index d490c7c4b967..06353028b274 100644 --- a/Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml +++ b/Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml @@ -20,7 +20,7 @@ properties: maxItems: 1 clocks: - minItems: 1 + maxItems: 1 auto-flow-control: description: enable automatic flow control support. -- cgit From e5fe471f7156c96a9da34b25f955dae5b0dfb46a Mon Sep 17 00:00:00 2001 From: Kunihiko Hayashi Date: Wed, 30 Mar 2022 14:15:38 +0900 Subject: dt-bindings: serial: uniphier: Add "resets" property as optional UniPhier UART controller has a reset lines from system controller. Add "resets" property to fix the following warning. uniphier-ld11-global.dtb: serial@54006800: 'resets' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml Reviewed-by: Krzysztof Kozlowski Signed-off-by: Kunihiko Hayashi Link: https://lore.kernel.org/r/1648617338-8600-3-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml b/Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml index 06353028b274..3d01cc355778 100644 --- a/Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml +++ b/Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml @@ -22,6 +22,9 @@ properties: clocks: maxItems: 1 + resets: + maxItems: 1 + auto-flow-control: description: enable automatic flow control support. $ref: /schemas/types.yaml#/definitions/flag -- cgit From 77edd0de002813629bb3b6efd336a630fab68aa0 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Wed, 23 Mar 2022 17:36:59 +0800 Subject: dt-bindings: serial: fsl-lpuart: Add imx93 compatible string The lpuart on i.MX93 is derived from i.MX7ULP with some industrial enhancements, it uses two compatible strings, so update the compatible string for i.MX93. Acked-by: Rob Herring Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20220323093659.1722463-1-peng.fan@oss.nxp.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml index ff364bd0fbac..30eaa62e1aed 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml @@ -23,7 +23,9 @@ properties: - fsl,imx8qxp-lpuart - fsl,imxrt1050-lpuart - items: - - const: fsl,imx8ulp-lpuart + - enum: + - fsl,imx93-lpuart + - fsl,imx8ulp-lpuart - const: fsl,imx7ulp-lpuart - items: - enum: -- cgit From 7bb301812b62809903e07ceaf5c176f20798e3c6 Mon Sep 17 00:00:00 2001 From: Phil Edworthy Date: Wed, 30 Mar 2022 16:40:13 +0100 Subject: dt-bindings: serial: renesas,em-uart: Document r9a09g011 bindings The Renesas RZ/V2M (r9a09g011) SoC uses a uart that is compatible with the EMMA Mobile SoC. Signed-off-by: Phil Edworthy Reviewed-by: Biju Das Link: https://lore.kernel.org/r/20220330154024.112270-3-phil.edworthy@renesas.com Acked-by: Rob Herring Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/renesas,em-uart.yaml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml index e98ec48fee46..332c385618e1 100644 --- a/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml @@ -14,7 +14,14 @@ allOf: properties: compatible: - const: renesas,em-uart + oneOf: + - items: + - enum: + - renesas,r9a09g011-uart # RZ/V2M + - const: renesas,em-uart # generic EMMA Mobile compatible UART + + - items: + - const: renesas,em-uart # generic EMMA Mobile compatible UART reg: maxItems: 1 -- cgit From 19401e9755313ba681e9c8f41e8c176cd95663bb Mon Sep 17 00:00:00 2001 From: Kuldeep Singh Date: Mon, 4 Apr 2022 23:59:36 +0530 Subject: dt-bindings: serial: Update Qualcomm geni based QUP UART bindings Similar to I2C controller, move geni based QUP UART controller binding out from parent schema to an individual binding and let parent refer to child schema later on. UART binding also stand incomplete right now similar to I2C, complete it along this process. Signed-off-by: Kuldeep Singh Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220404182938.29492-4-singh.kuldeep87k@gmail.com Signed-off-by: Greg Kroah-Hartman --- .../bindings/serial/qcom,serial-geni-qcom.yaml | 86 ++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml b/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml new file mode 100644 index 000000000000..05a6999808d1 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/serial/qcom,serial-geni-qcom.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Geni based QUP UART interface + +maintainers: + - Andy Gross + - Bjorn Andersson + +allOf: + - $ref: /schemas/serial/serial.yaml# + +properties: + compatible: + enum: + - qcom,geni-uart + - qcom,geni-debug-uart + + clocks: + maxItems: 1 + + clock-names: + const: se + + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: qup-core + - const: qup-config + + interrupts: + minItems: 1 + items: + - description: UART core irq + - description: Wakeup irq (RX GPIO) + + operating-points-v2: true + + pinctrl-0: true + pinctrl-1: true + + pinctrl-names: + minItems: 1 + items: + - const: default + - const: sleep + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - interrupts + - reg + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + + serial@a88000 { + compatible = "qcom,geni-uart"; + reg = <0xa88000 0x7000>; + interrupts = ; + clock-names = "se"; + clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>; + pinctrl-0 = <&qup_uart0_default>; + pinctrl-names = "default"; + interconnects = <&qup_virt MASTER_QUP_CORE_0 0 &qup_virt SLAVE_QUP_CORE_0 0>, + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>; + interconnect-names = "qup-core", "qup-config"; + }; +... -- cgit From 8b1ac84dcf2cf0fc86f29e92e5c63c4862de6e55 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Thu, 24 Mar 2022 17:59:18 +0100 Subject: Documentation/ABI: sysfs-fs-erofs: Fix Sphinx errors Fix the following warnings from "make htmldocs": Documentation/ABI/testing/sysfs-fs-erofs:10: ERROR: Unexpected indentation. WARNING: Block quote ends without a blank line; unexpected unindent. Signed-off-by: Hans de Goede Acked-by: Gao Xiang Link: https://lore.kernel.org/r/20220324165918.22005-4-hdegoede@redhat.com Signed-off-by: Gao Xiang --- Documentation/ABI/testing/sysfs-fs-erofs | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-fs-erofs b/Documentation/ABI/testing/sysfs-fs-erofs index 05482374a741..bb4681a01811 100644 --- a/Documentation/ABI/testing/sysfs-fs-erofs +++ b/Documentation/ABI/testing/sysfs-fs-erofs @@ -9,8 +9,9 @@ Description: Shows all enabled kernel features. What: /sys/fs/erofs//sync_decompress Date: November 2021 Contact: "Huang Jianan" -Description: Control strategy of sync decompression +Description: Control strategy of sync decompression: + - 0 (default, auto): enable for readpage, and enable for - readahead on atomic contexts only, + readahead on atomic contexts only. - 1 (force on): enable for readpage and readahead. - 2 (force off): disable for all situations. -- cgit From 4dc84c06a343fcb95fd5a0acb537aefa4ebdd1b0 Mon Sep 17 00:00:00 2001 From: Jie Wang Date: Tue, 12 Apr 2022 10:01:19 +0800 Subject: net: ethtool: extend ringparam set/get APIs for tx_push Currently tx push is a standard driver feature which controls use of a fast path descriptor push. So this patch extends the ringparam APIs and data structures to support set/get tx push by ethtool -G/g. Signed-off-by: Jie Wang Signed-off-by: Guangbin Huang Signed-off-by: Jakub Kicinski --- Documentation/networking/ethtool-netlink.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 24d9be69065d..dbca3e9ec782 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -862,6 +862,7 @@ Kernel response contents: ``ETHTOOL_A_RINGS_RX_BUF_LEN`` u32 size of buffers on the ring ``ETHTOOL_A_RINGS_TCP_DATA_SPLIT`` u8 TCP header / data split ``ETHTOOL_A_RINGS_CQE_SIZE`` u32 Size of TX/RX CQE + ``ETHTOOL_A_RINGS_TX_PUSH`` u8 flag of TX Push mode ==================================== ====== =========================== ``ETHTOOL_A_RINGS_TCP_DATA_SPLIT`` indicates whether the device is usable with @@ -871,6 +872,12 @@ separate buffers. The device configuration must make it possible to receive full memory pages of data, for example because MTU is high enough or through HW-GRO. +``ETHTOOL_A_RINGS_TX_PUSH`` flag is used to enable descriptor fast +path to send packets. In ordinary path, driver fills descriptors in DRAM and +notifies NIC hardware. In fast path, driver pushes descriptors to the device +through MMIO writes, thus reducing the latency. However, enabling this feature +may increase the CPU cost. Drivers may enforce additional per-packet +eligibility checks (e.g. on packet size). RINGS_SET ========= @@ -887,6 +894,7 @@ Request contents: ``ETHTOOL_A_RINGS_TX`` u32 size of TX ring ``ETHTOOL_A_RINGS_RX_BUF_LEN`` u32 size of buffers on the ring ``ETHTOOL_A_RINGS_CQE_SIZE`` u32 Size of TX/RX CQE + ``ETHTOOL_A_RINGS_TX_PUSH`` u8 flag of TX Push mode ==================================== ====== =========================== Kernel checks that requested ring sizes do not exceed limits reported by -- cgit From c562570e00799c919d64e793e5b4c334d6978ce2 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 5 Apr 2022 08:34:50 +0200 Subject: dt-bindings: i2c: qcom,i2c-qup: convert to dtschema Convert the Qualcomm Universal Peripheral (QUP) I2C controller to DT Schema. Add missing properties: dma and dma-names, pinctrl states (to indicate support for sleep pinctrl). Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Wolfram Sang --- .../devicetree/bindings/i2c/qcom,i2c-qup.txt | 40 ---------- .../devicetree/bindings/i2c/qcom,i2c-qup.yaml | 89 ++++++++++++++++++++++ 2 files changed, 89 insertions(+), 40 deletions(-) delete mode 100644 Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt create mode 100644 Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt deleted file mode 100644 index dc71754a56af..000000000000 --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt +++ /dev/null @@ -1,40 +0,0 @@ -Qualcomm Universal Peripheral (QUP) I2C controller - -Required properties: - - compatible: Should be: - * "qcom,i2c-qup-v1.1.1" for 8660, 8960 and 8064. - * "qcom,i2c-qup-v2.1.1" for 8974 v1. - * "qcom,i2c-qup-v2.2.1" for 8974 v2 and later. - - reg: Should contain QUP register address and length. - - interrupts: Should contain I2C interrupt. - - - clocks: A list of phandles + clock-specifiers, one for each entry in - clock-names. - - clock-names: Should contain: - * "core" for the core clock - * "iface" for the AHB clock - - - #address-cells: Should be <1> Address cells for i2c device address - - #size-cells: Should be <0> as i2c addresses have no size component - -Optional properties: - - clock-frequency: Should specify the desired i2c bus clock frequency in Hz, - defaults to 100kHz if omitted. - -Child nodes should conform to i2c bus binding. - -Example: - - i2c@f9924000 { - compatible = "qcom,i2c-qup-v2.2.1"; - reg = <0xf9924000 0x1000>; - interrupts = <0 96 0>; - - clocks = <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>; - clock-names = "core", "iface"; - - clock-frequency = <355000>; - - #address-cells = <1>; - #size-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml new file mode 100644 index 000000000000..f43947514d48 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/qcom,i2c-qup.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Universal Peripheral (QUP) I2C controller + +maintainers: + - Andy Gross + - Bjorn Andersson + - Krzysztof Kozlowski + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + enum: + - qcom,i2c-qup-v1.1.1 # for 8660, 8960 and 8064 + - qcom,i2c-qup-v2.1.1 # for 8974 v1 + - qcom,i2c-qup-v2.2.1 # for 8974 v2 and later + + clocks: + maxItems: 2 + + clock-names: + items: + - const: core + - const: iface + + clock-frequency: + default: 100000 + + dmas: + maxItems: 2 + + dma-names: + items: + - const: tx + - const: rx + + interrupts: + maxItems: 1 + + pinctrl-0: true + pinctrl-1: true + + pinctrl-names: + minItems: 1 + items: + - const: default + - const: sleep + + reg: + maxItems: 1 + +required: + - compatible + - clock-names + - clocks + - interrupts + - reg + +unevaluatedProperties: false + +examples: + - | + #include + #include + + i2c@c175000 { + compatible = "qcom,i2c-qup-v2.2.1"; + reg = <0x0c175000 0x600>; + interrupts = ; + + clocks = <&gcc GCC_BLSP1_QUP1_I2C_APPS_CLK>, + <&gcc GCC_BLSP1_AHB_CLK>; + clock-names = "core", "iface"; + dmas = <&blsp1_dma 6>, <&blsp1_dma 7>; + dma-names = "tx", "rx"; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&blsp1_i2c1_default>; + pinctrl-1 = <&blsp1_i2c1_sleep>; + clock-frequency = <400000>; + + #address-cells = <1>; + #size-cells = <0>; + }; -- cgit From 43e3df81ee591973c49e95b3900c765c9d616db4 Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Fri, 8 Apr 2022 22:47:41 +0800 Subject: docs/zh_CN: Add locking/index Chinese translation Translate locking/index.rst into Chinese. Signed-off-by: Tang Yizhou Reviewed-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/index.rst | 2 +- Documentation/translations/zh_CN/locking/index.rst | 42 ++++++++++++++++++++++ 2 files changed, 43 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/locking/index.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 88d8df957a78..ac32d8e306ac 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -108,6 +108,7 @@ TODOList: :maxdepth: 2 core-api/index + locking/index accounting/index cpu-freq/index iio/index @@ -123,7 +124,6 @@ TODOList: TODOList: * driver-api/index -* locking/index * block/index * cdrom/index * ide/index diff --git a/Documentation/translations/zh_CN/locking/index.rst b/Documentation/translations/zh_CN/locking/index.rst new file mode 100644 index 000000000000..700df8a2bb70 --- /dev/null +++ b/Documentation/translations/zh_CN/locking/index.rst @@ -0,0 +1,42 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/locking/index.rst + +:翻译: + + 唐艺舟 Tang Yizhou + +== +锁 +== + +.. toctree:: + :maxdepth: 1 + +TODOList: + + * locktypes + * lockdep-design + * lockstat + * locktorture + * mutex-design + * rt-mutex-design + * rt-mutex + * seqlock + * spinlocks + * ww-mutex-design + * preempt-locking + * pi-futex + * futex-requeue-pi + * hwspinlock + * percpu-rw-semaphore + * robust-futexes + * robust-futex-ABI + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` -- cgit From 6c300a7142c190d01916e7fcef8a7c403cfe8221 Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Fri, 8 Apr 2022 22:47:42 +0800 Subject: docs/zh_CN: Add spinlocks Chinese translation Translate locking/spinlocks.rst into Chinese. Signed-off-by: Tang Yizhou Reviewed-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/locking/spinlocks.rst | 149 +++++++++++++++++++++ 1 file changed, 149 insertions(+) create mode 100644 Documentation/translations/zh_CN/locking/spinlocks.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/locking/spinlocks.rst b/Documentation/translations/zh_CN/locking/spinlocks.rst new file mode 100644 index 000000000000..2017c01f0a4b --- /dev/null +++ b/Documentation/translations/zh_CN/locking/spinlocks.rst @@ -0,0 +1,149 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/locking/spinlocks.rst + +:翻译: + + 唐艺舟 Tang Yizhou + +========== +加锁的教训 +========== + +教训 1：自旋锁 +============== + +加锁最基本的原语是自旋锁（spinlock）:: + + static DEFINE_SPINLOCK(xxx_lock); + + unsigned long flags; + + spin_lock_irqsave(&xxx_lock, flags); + ... 这里是临界区 .. + spin_unlock_irqrestore(&xxx_lock, flags); + +上述代码总是安全的。自旋锁将在 _本地_ 禁用中断，但它本身将保证全局锁定。所以它 +将保证在该锁保护的区域内只有一个控制线程。即使在单处理器（UP）下也能很好的工作， +所以代码 _不_ 需要担心UP还是SMP的问题：自旋锁在两种情况下都能正常工作。 + + 注意！自旋锁对内存的潜在影响由下述文档进一步描述： + + Documentation/memory-barriers.txt + + (5) ACQUIRE operations. + + (6) RELEASE operations. + +上述代码通常非常简单（对大部分情况，你通常需要并且只希望有一个自旋锁——使用多个 +自旋锁会使事情变得更复杂，甚至更慢，而且通常仅仅在你 **理解的** 序列有被拆分的 +需求时才值得这么做：如果你不确定的话，请不惜一切代价避免这样做）。 + +这是关于自旋锁的唯一真正困难的部分：一旦你开始使用自旋锁，它们往往会扩展到你以前 +可能没有注意到的领域，因为你必须确保自旋锁正确地保护共享数据结构 **每一处** 被 +使用的地方。自旋锁是最容易被添加到完全独立于其它代码的地方（例如，没有人访问的 +内部驱动数据结构）的。 + + 注意！仅当你在跨CPU核访问时使用 **同一把** 自旋锁，对它的使用才是安全的。 + 这意味着所有访问共享变量的代码必须对它们想使用的自旋锁达成一致。 + +---- + +教训 2：读-写自旋锁 +=================== + +如果你的数据访问有一个非常自然的模式，倾向于从共享变量中读取数据，读-写自旋锁 +（rw_lock）有时是有用的。它们允许多个读者同时出现在同一个临界区，但是如果有人想 +改变变量，它必须获得一个独占的写锁。 + + 注意！读-写自旋锁比原始自旋锁需要更多的原子内存操作。除非读者的临界区很长， + 否则你最好只使用原始自旋锁。 + +例程看起来和上面一样:: + + rwlock_t xxx_lock = __RW_LOCK_UNLOCKED(xxx_lock); + + unsigned long flags; + + read_lock_irqsave(&xxx_lock, flags); + .. 仅读取信息的临界区 ... + read_unlock_irqrestore(&xxx_lock, flags); + + write_lock_irqsave(&xxx_lock, flags); + .. 读取和独占写信息 ... + write_unlock_irqrestore(&xxx_lock, flags); + +上面这种锁对于复杂的数据结构如链表可能会有用，特别是在不改变链表的情况下搜索其中 +的条目。读锁允许许多并发的读者。任何希望 **修改** 链表的代码将必须先获取写锁。 + + 注意！RCU锁更适合遍历链表，但需要仔细注意设计细节（见Documentation/RCU/listRCU.rst）。 + +另外，你不能把读锁“升级”为写锁，所以如果你在 _任何_ 时候需要做任何修改 +（即使你不是每次都这样做），你必须在一开始就获得写锁。 + + 注意！我们正在努力消除大多数情况下的读-写自旋锁的使用，所以请不要在没有达成 + 共识的情况下增加一个新的（相反，请参阅Documentation/RCU/rcu.rst以获得完整 + 信息）。 + +---- + +教训 3：重新审视自旋锁 +====================== + +上述的自旋锁原语绝不是唯一的。它们是最安全的，在所有情况下都能正常工作，但部分 +**因为** 它们是安全的，它们也是相当慢的。它们比原本需要的更慢，因为它们必须要 +禁用中断（在X86上只是一条指令，但却是一条昂贵的指令——而在其他体系结构上，情况 +可能更糟）。 + +如果你有必须保护跨CPU访问的数据结构且你想使用自旋锁的场景，你有可能使用代价小的 +自旋锁版本。当且仅当你知道某自旋锁永远不会在中断处理程序中使用，你可以使用非中断 +的版本:: + + spin_lock(&lock); + ... + spin_unlock(&lock); + +（当然，也可以使用相应的读-写锁版本）。这种自旋锁将同样可以保证独占访问，而且 +速度会快很多。如果你知道有关的数据只在“进程上下文”中被存取，即，不涉及中断， +这种自旋锁就有用了。 + +当这些版本的自旋锁涉及中断时，你不能使用的原因是会陷入死锁:: + + spin_lock(&lock); + ... + <- 中断来临： + spin_lock(&lock); + +一个中断试图对一个已经锁定的变量上锁。如果中断发生在另一个CPU上，不会有问题； +但如果中断发生在已经持有自旋锁的同一个CPU上，将 _会_ 有问题，因为该锁显然永远 +不会被释放（因为中断正在等待该锁，而锁的持有者被中断打断，并且无法继续执行， +直到中断处理结束）。 + +（这也是自旋锁的中断版本只需要禁用 _本地_ 中断的原因——在发生于其它CPU的中断中 +使用同一把自旋锁是没问题的，因为发生于其它CPU的中断不会打断已经持锁的CPU，所以 +锁的持有者可以继续执行并最终释放锁）。 + + Linus + +---- + +参考信息 +======== + +对于动态初始化，使用spin_lock_init()或rwlock_init()是合适的:: + + spinlock_t xxx_lock; + rwlock_t xxx_rw_lock; + + static int __init xxx_init(void) + { + spin_lock_init(&xxx_lock); + rwlock_init(&xxx_rw_lock); + ... + } + + module_init(xxx_init); + +对于静态初始化，使用DEFINE_SPINLOCK() / DEFINE_RWLOCK()或 +__SPIN_LOCK_UNLOCKED() / __RW_LOCK_UNLOCKED()是合适的。 -- cgit From ddb21d27a6a508eae9aa8b72a924d989fb260dea Mon Sep 17 00:00:00 2001 From: Chunguang Xu Date: Fri, 8 Apr 2022 17:31:06 +0800 Subject: docs/scheduler: Change unit of cpu_time and rq_time to nanoseconds In the current implementation, cpu_time and rq_time should be in nanoseconds, so this document needs to be modified. Signed-off-by: Chunguang Xu Signed-off-by: Jonathan Corbet --- Documentation/scheduler/sched-stats.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scheduler/sched-stats.rst b/Documentation/scheduler/sched-stats.rst index dd9b99a025f7..9078a27a4137 100644 --- a/Documentation/scheduler/sched-stats.rst +++ b/Documentation/scheduler/sched-stats.rst @@ -56,9 +56,9 @@ Next two are try_to_wake_up() statistics: Next three are statistics describing scheduling latency: - 7) sum of all time spent running by tasks on this processor (in jiffies) + 7) sum of all time spent running by tasks on this processor (in nanoseconds) 8) sum of all time spent waiting to run by tasks on this processor (in - jiffies) + nanoseconds) 9) # of timeslices run on this cpu -- cgit From ab0167d9d45799a81b8397eaa45da746fa173aae Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Fri, 8 Apr 2022 10:35:25 +0800 Subject: docs/zh_CN: add vm hugetlbfs_reserv translation Translate .../vm/hugetlbfs_reserv.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Signed-off-by: Jonathan Corbet --- .../translations/zh_CN/vm/hugetlbfs_reserv.rst | 436 +++++++++++++++++++++ Documentation/translations/zh_CN/vm/index.rst | 1 + 2 files changed, 437 insertions(+) create mode 100644 Documentation/translations/zh_CN/vm/hugetlbfs_reserv.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/hugetlbfs_reserv.rst b/Documentation/translations/zh_CN/vm/hugetlbfs_reserv.rst new file mode 100644 index 000000000000..c6d471ce2131 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/hugetlbfs_reserv.rst @@ -0,0 +1,436 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/vm/hugetlbfs_reserv.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + +============== +Hugetlbfs 预留 +============== + +概述 +==== + +:ref:`hugetlbpage` 中描述的巨页通常是预先分配给应用程序使用的。如果VMA指 +示要使用巨页，这些巨页会在缺页异常时被实例化到任务的地址空间。如果在缺页异常 +时没有巨页存在，任务就会被发送一个SIGBUS，并经常不高兴地死去。在加入巨页支 +持后不久，人们决定，在mmap()时检测巨页的短缺情况会更好。这个想法是，如果 +没有足够的巨页来覆盖映射，mmap()将失败。这首先是在mmap()时在代码中做一个 +简单的检查，以确定是否有足够的空闲巨页来覆盖映射。就像内核中的大多数东西一 +样，代码随着时间的推移而不断发展。然而，基本的想法是在mmap()时 “预留” +巨页，以确保巨页可以用于该映射中的缺页异常。下面的描述试图描述在v4.10内核 +中是如何进行巨页预留处理的。 + + +读者 +==== +这个描述主要是针对正在修改hugetlbfs代码的内核开发者。 + + +数据结构 +======== + +resv_huge_pages + 这是一个全局的（per-hstate）预留的巨页的计数。预留的巨页只对预留它们的任 + 务可用。因此，一般可用的巨页的数量被计算为(``free_huge_pages - resv_huge_pages``)。 +Reserve Map + 预留映射由以下结构体描述:: + + struct resv_map { + struct kref refs; + spinlock_t lock; + struct list_head regions; + long adds_in_progress; + struct list_head region_cache; + long region_cache_count; + }; + + 系统中每个巨页映射都有一个预留映射。resv_map中的regions列表描述了映射中的 + 区域。一个区域被描述为:: + + struct file_region { + struct list_head link; + long from; + long to; + }; + + file_region结构体的 ‘from’ 和 ‘to’ 字段是进入映射的巨页索引。根据映射的类型，在 + reserv_map 中的一个区域可能表示该范围存在预留，或预留不存在。 +Flags for MAP_PRIVATE Reservations + 这些被存储在预留的映射指针的底部。 + + ``#define HPAGE_RESV_OWNER (1UL << 0)`` + 表示该任务是与该映射相关的预留的所有者。 + ``#define HPAGE_RESV_UNMAPPED (1UL << 1)`` + 表示最初映射此范围（并创建储备）的任务由于COW失败而从该任务（子任务）中取消映 + 射了一个页面。 +Page Flags + PagePrivate页面标志是用来指示在释放巨页时必须恢复巨页的预留。更多细节将在 + “释放巨页” 一节中讨论。 + + +预留映射位置（私有或共享） +========================== + +一个巨页映射或段要么是私有的，要么是共享的。如果是私有的，它通常只对一个地址空间 +（任务）可用。如果是共享的，它可以被映射到多个地址空间（任务）。对于这两种类型的映射， +预留映射的位置和语义是明显不同的。位置的差异是： + +- 对于私有映射，预留映射挂在VMA结构体上。具体来说，就是vma->vm_private_data。这个保 + 留映射是在创建映射（mmap(MAP_PRIVATE)）时创建的。 +- 对于共享映射，预留映射挂在inode上。具体来说，就是inode->i_mapping->private_data。 + 由于共享映射总是由hugetlbfs文件系统中的文件支持，hugetlbfs代码确保每个节点包含一个预 + 留映射。因此，预留映射在创建节点时被分配。 + + +创建预留 +======== +当创建一个巨大的有页面支持的共享内存段（shmget(SHM_HUGETLB)）或通过mmap(MAP_HUGETLB) +创建一个映射时，就会创建预留。这些操作会导致对函数hugetlb_reserve_pages()的调用:: + + int hugetlb_reserve_pages(struct inode *inode, + long from, long to, + struct vm_area_struct *vma, + vm_flags_t vm_flags) + +hugetlb_reserve_pages()做的第一件事是检查在调用shmget()或mmap()时是否指定了NORESERVE +标志。如果指定了NORESERVE，那么这个函数立即返回，因为不需要预留。 + +参数'from'和'to'是映射或基础文件的巨页索引。对于shmget()，'from'总是0，'to'对应于段/映射 +的长度。对于mmap()，offset参数可以用来指定进入底层文件的偏移量。在这种情况下，'from'和'to' +参数已经被这个偏移量所调整。 + +PRIVATE和SHARED映射之间的一个很大的区别是预留在预留映射中的表示方式。 + +- 对于共享映射，预留映射中的条目表示对应页面的预留存在或曾经存在。当预留被消耗时，预留映射不被 + 修改。 +- 对于私有映射，预留映射中没有条目表示相应页面存在预留。随着预留被消耗，条目被添加到预留映射中。 + 因此，预留映射也可用于确定哪些预留已被消耗。 + +对于私有映射，hugetlb_reserve_pages()创建预留映射并将其挂在VMA结构体上。此外， +HPAGE_RESV_OWNER标志被设置，以表明该VMA拥有预留。 + +预留映射被查阅以确定当前映射/段需要多少巨页预留。对于私有映射，这始终是一个值（to - from）。 +然而，对于共享映射来说，一些预留可能已经存在于(to - from)的范围内。关于如何实现这一点的细节， +请参见 :ref:`预留映射的修改 ` 一节。 + +该映射可能与一个子池（subpool）相关联。如果是这样，将查询子池以确保有足够的空间用于映射。子池 +有可能已经预留了可用于映射的预留空间。更多细节请参见 :ref: `子池预留 ` +一节。 + +在咨询了预留映射和子池之后，就知道了需要的新预留数量。hugetlb_acct_memory()函数被调用以检查 +并获取所要求的预留数量。hugetlb_acct_memory()调用到可能分配和调整剩余页数的函数。然而，在这 +些函数中，代码只是检查以确保有足够的空闲的巨页来容纳预留。如果有的话，全局预留计数resv_huge_pages +会被调整，如下所示:: + + if (resv_needed <= (resv_huge_pages - free_huge_pages)) + resv_huge_pages += resv_needed; + +注意，在检查和调整这些计数器时，全局锁hugetlb_lock会被预留。 + +如果有足够的空闲的巨页，并且全局计数resv_huge_pages被调整，那么与映射相关的预留映射被修改以 +反映预留。在共享映射的情况下，将存在一个file_region，包括'from'-'to'范围。对于私有映射， +不对预留映射进行修改，因为没有条目表示存在预留。 + +如果hugetlb_reserve_pages()成功，全局预留数和与映射相关的预留映射将根据需要被修改，以确保 +在'from'-'to'范围内存在预留。 + +消耗预留/分配一个巨页 +=========================== + +当与预留相关的巨页在相应的映射中被分配和实例化时，预留就被消耗了。该分配是在函数alloc_huge_page() +中进行的:: + + struct page *alloc_huge_page(struct vm_area_struct *vma, + unsigned long addr, int avoid_reserve) + +alloc_huge_page被传递给一个VMA指针和一个虚拟地址，因此它可以查阅预留映射以确定是否存在预留。 +此外，alloc_huge_page需要一个参数avoid_reserve，该参数表示即使看起来已经为指定的地址预留了 +预留，也不应该使用预留。avoid_reserve参数最常被用于写时拷贝和页面迁移的情况下，即现有页面的额 +外拷贝被分配。 + + +调用辅助函数vma_needs_reservation()来确定是否存在对映射(vma)中地址的预留。关于这个函数的详 +细内容，请参见 :ref:`预留映射帮助函数 ` 一节。从 +vma_needs_reservation()返回的值通常为0或1。如果该地址存在预留，则为0，如果不存在预留，则为1。 +如果不存在预留，并且有一个与映射相关联的子池，则查询子池以确定它是否包含预留。如果子池包含预留， +则可将其中一个用于该分配。然而，在任何情况下，avoid_reserve参数都会优先考虑为分配使用预留。在 +确定预留是否存在并可用于分配后，调用dequeue_huge_page_vma()函数。这个函数需要两个与预留有关 +的参数： + +- avoid_reserve，这是传递给alloc_huge_page()的同一个值/参数。 +- chg，尽管这个参数的类型是long，但只有0或1的值被传递给dequeue_huge_page_vma。如果该值为0， + 则表明存在预留（关于可能的问题，请参见 “预留和内存策略” 一节）。如果值 + 为1，则表示不存在预留，如果可能的话，必须从全局空闲池中取出该页。 + +与VMA的内存策略相关的空闲列表被搜索到一个空闲页。如果找到了一个页面，当该页面从空闲列表中移除时， +free_huge_pages的值被递减。如果有一个与该页相关的预留，将进行以下调整:: + + SetPagePrivate(page); /* 表示分配这个页面消耗了一个预留， + * 如果遇到错误，以至于必须释放这个页面，预留将被 + * 恢复。 */ + resv_huge_pages--; /* 减少全局预留计数 */ + +注意，如果找不到满足VMA内存策略的巨页，将尝试使用伙伴分配器分配一个。这就带来了超出预留范围 +的剩余巨页和超额分配的问题。即使分配了一个多余的页面，也会进行与上面一样的基于预留的调整: +SetPagePrivate(page) 和 resv_huge_pages--. + +在获得一个新的巨页后，(page)->private被设置为与该页面相关的子池的值，如果它存在的话。当页 +面被释放时，这将被用于子池的计数。 + +然后调用函数vma_commit_reservation()，根据预留的消耗情况调整预留映射。一般来说，这涉及 +到确保页面在区域映射的file_region结构体中被表示。对于预留存在的共享映射，预留映射中的条目 +已经存在，所以不做任何改变。然而，如果共享映射中没有预留，或者这是一个私有映射，则必须创建一 +个新的条目。 + +注意，如果找不到满足VMA内存策略的巨页，将尝试使用伙伴分配器分配一个。这就带来了超出预留范围 +的剩余巨页和过度分配的问题。即使分配了一个多余的页面，也会进行与上面一样的基于预留的调整。 +SetPagePrivate(page)和resv_huge_pages-。 + +在获得一个新的巨页后，(page)->private被设置为与该页面相关的子池的值，如果它存在的话。当页 +面被释放时，这将被用于子池的计数。 + +然后调用函数vma_commit_reservation()，根据预留的消耗情况调整预留映射。一般来说，这涉及 +到确保页面在区域映射的file_region结构体中被表示。对于预留存在的共享映射，预留映射中的条目 +已经存在，所以不做任何改变。然而，如果共享映射中没有预留，或者这是一个私有映射，则必须创建 +一个新的条目。 + +在alloc_huge_page()开始调用vma_needs_reservation()和页面分配后调用 +vma_commit_reservation()之间，预留映射有可能被改变。如果hugetlb_reserve_pages在共 +享映射中为同一页面被调用，这将是可能的。在这种情况下，预留计数和子池空闲页计数会有一个偏差。 +这种罕见的情况可以通过比较vma_needs_reservation和vma_commit_reservation的返回值来 +识别。如果检测到这种竞争，子池和全局预留计数将被调整以进行补偿。关于这些函数的更多信息，请 +参见 :ref:`预留映射帮助函数 ` 一节。 + + +实例化巨页 +========== + +在巨页分配之后，页面通常被添加到分配任务的页表中。在此之前，共享映射中的页面被添加到页面缓 +存中，私有映射中的页面被添加到匿名反向映射中。在这两种情况下，PagePrivate标志被清除。因此， +当一个已经实例化的巨页被释放时，不会对全局预留计数（resv_huge_pages）进行调整。 + + +释放巨页 +======== + +巨页释放是由函数free_huge_page()执行的。这个函数是hugetlbfs复合页的析构器。因此，它只传 +递一个指向页面结构体的指针。当一个巨页被释放时，可能需要进行预留计算。如果该页与包含保 +留的子池相关联，或者该页在错误路径上被释放，必须恢复全局预留计数，就会出现这种情况。 + +page->private字段指向与该页相关的任何子池。如果PagePrivate标志被设置，它表明全局预留计数 +应该被调整（关于如何设置这些标志的信息，请参见 +:ref: `消耗预留/分配一个巨页 ` ）。 + + +该函数首先调用hugepage_subpool_put_pages()来处理该页。如果这个函数返回一个0的值（不等于 +传递的1的值），它表明预留与子池相关联，这个新释放的页面必须被用来保持子池预留的数量超过最小值。 +因此，在这种情况下，全局resv_huge_pages计数器被递增。 + +如果页面中设置了PagePrivate标志，那么全局resv_huge_pages计数器将永远被递增。 + +子池预留 +======== + +有一个结构体hstate与每个巨页尺寸相关联。hstate跟踪所有指定大小的巨页。一个子池代表一 +个hstate中的页面子集，它与一个已挂载的hugetlbfs文件系统相关 + +当一个hugetlbfs文件系统被挂载时，可以指定min_size选项，它表示文件系统所需的最小的巨页数量。 +如果指定了这个选项，与min_size相对应的巨页的数量将被预留给文件系统使用。这个数字在结构体 +hugepage_subpool的min_hpages字段中被跟踪。在挂载时，hugetlb_acct_memory(min_hpages) +被调用以预留指定数量的巨页。如果它们不能被预留，挂载就会失败。 + +当从子池中获取或释放页面时，会调用hugepage_subpool_get/put_pages()函数。 +hugepage_subpool_get/put_pages被传递给巨页数量，以此来调整子池的 “已用页面” 计数 +（get为下降，put为上升）。通常情况下，如果子池中没有足够的页面，它们会返回与传递的相同的值或 +一个错误。 + +然而，如果预留与子池相关联，可能会返回一个小于传递值的返回值。这个返回值表示必须进行的额外全局 +池调整的数量。例如，假设一个子池包含3个预留的巨页，有人要求5个。与子池相关的3个预留页可以用来 +满足部分请求。但是，必须从全局池中获得2个页面。为了向调用者转达这一信息，将返回值2。然后，调用 +者要负责从全局池中获取另外两个页面。 + + +COW和预留 +========== + +由于共享映射都指向并使用相同的底层页面，COW最大的预留问题是私有映射。在这种情况下，两个任务可 +以指向同一个先前分配的页面。一个任务试图写到该页，所以必须分配一个新的页，以便每个任务都指向它 +自己的页。 + +当该页最初被分配时，该页的预留被消耗了。当由于COW而试图分配一个新的页面时，有可能没有空闲的巨 +页，分配会失败。 + +当最初创建私有映射时，通过设置所有者的预留映射指针中的HPAGE_RESV_OWNER位来标记映射的所有者。 +由于所有者创建了映射，所有者拥有与映射相关的所有预留。因此，当一个写异常发生并且没有可用的页面 +时，对预留的所有者和非所有者采取不同的行动。 + +在发生异常的任务不是所有者的情况下，异常将失败，该任务通常会收到一个SIGBUS。 + +如果所有者是发生异常的任务，我们希望它能够成功，因为它拥有原始的预留。为了达到这个目的，该页被 +从非所有者任务中解映射出来。这样一来，唯一的引用就是来自拥有者的任务。此外，HPAGE_RESV_UNMAPPED +位被设置在非拥有任务的预留映射指针中。如果非拥有者任务后来在一个不存在的页面上发生异常，它可能 +会收到一个SIGBUS。但是，映射/预留的原始拥有者的行为将与预期一致。 + +预留映射的修改 +============== + +以下低级函数用于对预留映射进行修改。通常情况下，这些函数不会被直接调用。而是调用一个预留映射辅 +助函数，该函数调用这些低级函数中的一个。这些低级函数在源代码（mm/hugetlb.c）中得到了相当好的 +记录。这些函数是:: + + long region_chg(struct resv_map *resv, long f, long t); + long region_add(struct resv_map *resv, long f, long t); + void region_abort(struct resv_map *resv, long f, long t); + long region_count(struct resv_map *resv, long f, long t); + +在预留映射上的操作通常涉及两个操作: + +1) region_chg()被调用来检查预留映射，并确定在指定的范围[f, t]内有多少页目前没有被代表。 + + 调用代码执行全局检查和分配，以确定是否有足够的巨页使操作成功。 + +2) + a) 如果操作能够成功，regi_add()将被调用，以实际修改先前传递给regi_chg()的相同范围 + [f, t]的预留映射。 + b) 如果操作不能成功，region_abort被调用，在相同的范围[f, t]内中止操作。 + +注意，这是一个两步的过程， region_add()和 region_abort()在事先调用 region_chg()后保证 +成功。 region_chg()负责预先分配任何必要的数据结构以确保后续操作（特别是 region_add()）的 +成功。 + +如上所述，region_chg()确定该范围内当前没有在映射中表示的页面的数量。region_add()返回添加 +到映射中的范围内的页数。在大多数情况下， region_add() 的返回值与 region_chg() 的返回值相 +同。然而，在共享映射的情况下，有可能在调用 region_chg() 和 region_add() 之间对预留映射进 +行更改。在这种情况下，regi_add()的返回值将与regi_chg()的返回值不符。在这种情况下，全局计数 +和子池计数很可能是不正确的，需要调整。检查这种情况并进行适当的调整是调用者的责任。 + +函数region_del()被调用以从预留映射中移除区域。 +它通常在以下情况下被调用: + +- 当hugetlbfs文件系统中的一个文件被删除时，该节点将被释放，预留映射也被释放。在释放预留映射 + 之前，所有单独的file_region结构体必须被释放。在这种情况下，region_del的范围是[0, LONG_MAX]。 +- 当一个hugetlbfs文件正在被截断时。在这种情况下，所有在新文件大小之后分配的页面必须被释放。 + 此外，预留映射中任何超过新文件大小的file_region条目必须被删除。在这种情况下，region_del + 的范围是[new_end_of_file, LONG_MAX]。 +- 当在一个hugetlbfs文件中打洞时。在这种情况下，巨页被一次次从文件的中间移除。当这些页被移除 + 时，region_del()被调用以从预留映射中移除相应的条目。在这种情况下，region_del被传递的范 + 围是[page_idx, page_idx + 1]。 + +在任何情况下，region_del()都会返回从预留映射中删除的页面数量。在非常罕见的情况下，region_del() +会失败。这只能发生在打洞的情况下，即它必须分割一个现有的file_region条目，而不能分配一个新的 +结构体。在这种错误情况下，region_del()将返回-ENOMEM。这里的问题是，预留映射将显示对该页有 +预留。然而，子池和全局预留计数将不反映该预留。为了处理这种情况，调用函数hugetlb_fix_reserve_counts() +来调整计数器，使其与不能被删除的预留映射条目相对应。 + +region_count()在解除私有巨页映射时被调用。在私有映射中，预留映射中没有条目表明存在一个预留。 +因此，通过计算预留映射中的条目数，我们知道有多少预留被消耗了，有多少预留是未完成的 +（Outstanding = (end - start) - region_count（resv, start, end））。由于映射正在消 +失，子池和全局预留计数被未完成的预留数量所减去。 + +预留映射帮助函数 +================ + +有几个辅助函数可以查询和修改预留映射。这些函数只对特定的巨页的预留感兴趣，所以它们只是传入一个 +地址而不是一个范围。此外，它们还传入相关的VMA。从VMA中，可以确定映射的类型（私有或共享）和预留 +映射的位置（inode或VMA）。这些函数只是调用 “预留映射的修改” 一节中描述的基础函数。然而， +它们确实考虑到了私有和共享映射的预留映射条目的 “相反” 含义，并向调用者隐藏了这个细节:: + + long vma_needs_reservation(struct hstate *h, + struct vm_area_struct *vma, + unsigned long addr) + +该函数为指定的页面调用 region_chg()。如果不存在预留，则返回1。如果存在预留，则返回0:: + + long vma_commit_reservation(struct hstate *h, + struct vm_area_struct *vma, + unsigned long addr) + +这将调用 region_add()，用于指定的页面。与region_chg和region_add的情况一样，该函数应在 +先前调用的vma_needs_reservation后调用。它将为该页添加一个预留条目。如果预留被添加，它将 +返回1，如果没有则返回0。返回值应与之前调用vma_needs_reservation的返回值进行比较。如果出 +现意外的差异，说明在两次调用之间修改了预留映射:: + + void vma_end_reservation(struct hstate *h, + struct vm_area_struct *vma, + unsigned long addr) + +这将调用指定页面的 region_abort()。与region_chg和region_abort的情况一样，该函数应在 +先前调用的vma_needs_reservation后被调用。它将中止/结束正在进行的预留添加操作:: + + long vma_add_reservation(struct hstate *h, + struct vm_area_struct *vma, + unsigned long addr) + +这是一个特殊的包装函数，有助于在错误路径上清理预留。它只从repare_reserve_on_error()函数 +中调用。该函数与vma_needs_reservation一起使用，试图将一个预留添加到预留映射中。它考虑到 +了私有和共享映射的不同预留映射语义。因此，region_add被调用用于共享映射（因为映射中的条目表 +示预留），而region_del被调用用于私有映射（因为映射中没有条目表示预留）。关于在错误路径上需 +要做什么的更多信息，请参见 “错误路径中的预留清理” 。 + + +错误路径中的预留清理 +==================== + +正如在:ref:`预留映射帮助函数` 一节中提到的，预留的修改分两步进行。首 +先，在分配页面之前调用vma_needs_reservation。如果分配成功，则调用vma_commit_reservation。 +如果不是，则调用vma_end_reservation。全局和子池的预留计数根据操作的成功或失败进行调整， +一切都很好。 + +此外，在一个巨页被实例化后，PagePrivate标志被清空，这样，当页面最终被释放时，计数是 +正确的。 + +然而，有几种情况是，在一个巨页被分配后，但在它被实例化之前，就遇到了错误。在这种情况下， +页面分配已经消耗了预留，并进行了适当的子池、预留映射和全局计数调整。如果页面在这个时候被释放 +（在实例化和清除PagePrivate之前），那么free_huge_page将增加全局预留计数。然而，预留映射 +显示报留被消耗了。这种不一致的状态将导致预留的巨页的 “泄漏” 。全局预留计数将比它原本的要高， +并阻止分配一个预先分配的页面。 + +函数 restore_reserve_on_error() 试图处理这种情况。它有相当完善的文档。这个函数的目的 +是将预留映射恢复到页面分配前的状态。通过这种方式，预留映射的状态将与页面释放后的全局预留计 +数相对应。 + +函数restore_reserve_on_error本身在试图恢复预留映射条目时可能会遇到错误。在这种情况下， +它将简单地清除该页的PagePrivate标志。这样一来，当页面被释放时，全局预留计数将不会被递增。 +然而，预留映射将继续看起来像预留被消耗了一样。一个页面仍然可以被分配到该地址，但它不会像最 +初设想的那样使用一个预留页。 + +有一些代码（最明显的是userfaultfd）不能调用restore_reserve_on_error。在这种情况下， +它简单地修改了PagePrivate，以便在释放巨页时不会泄露预留。 + + +预留和内存策略 +============== +当git第一次被用来管理Linux代码时，每个节点的巨页列表就存在于hstate结构中。预留的概念是 +在一段时间后加入的。当预留被添加时，没有尝试将内存策略考虑在内。虽然cpusets与内存策略不 +完全相同，但hugetlb_acct_memory中的这个注释总结了预留和cpusets/内存策略之间的相互作 +用:: + + + /* + * 当cpuset被配置时，它打破了严格的hugetlb页面预留，因为计数是在一个全局变量上完 + * 成的。在有cpuset的情况下，这样的预留完全是垃圾，因为预留没有根据当前cpuset的 + * 页面可用性来检查。在任务所在的cpuset中缺乏空闲的htlb页面时，应用程序仍然有可能 + * 被内核OOM'ed。试图用cpuset来执行严格的计数几乎是不可能的（或者说太难看了），因 + * 为cpuset太不稳定了，任务或内存节点可以在cpuset之间动态移动。与cpuset共享 + * hugetlb映射的语义变化是不可取的。然而，为了预留一些语义，我们退回到检查当前空闲 + * 页的可用性，作为一种最好的尝试，希望能将cpuset改变语义的影响降到最低。 + */ + +添加巨页预留是为了防止在缺页异常时出现意外的页面分配失败（OOM）。然而，如果一个应用 +程序使用cpusets或内存策略，就不能保证在所需的节点上有巨页可用。即使有足够数量的全局 +预留，也是如此。 + +Hugetlbfs回归测试 +================= + +最完整的hugetlb测试集在libhugetlbfs仓库。如果你修改了任何hugetlb相关的代码，请使用 +libhugetlbfs测试套件来检查回归情况。此外，如果你添加了任何新的hugetlb功能，请在 +libhugetlbfs中添加适当的测试。 + +-- +Mike Kravetz，2017年4月7日 diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index c7148125e659..61cd39cefdcf 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -29,6 +29,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） ksm frontswap hwpoison + hugetlbfs_reserv memory-model mmu_notifier overcommit-accounting -- cgit From 532578ed4d91bc8bc315fa5aa67606bf63ad45c3 Mon Sep 17 00:00:00 2001 From: Zhou Yuheng Date: Wed, 16 Mar 2022 07:24:28 +0800 Subject: docs/zh_CN: Fix typo in process/howto.rst Correct the url of linux-next Signed-off-by: Zhou Yuheng Reviewed-by: Alex Shi Acked-by: Tang Yizhou Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/process/howto.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst index 2903d7161bc8..1334cdb32a3c 100644 --- a/Documentation/translations/zh_CN/process/howto.rst +++ b/Documentation/translations/zh_CN/process/howto.rst @@ -252,7 +252,7 @@ Linux-next 集成测试树 在将子系统树的更新合并到主线树之前，需要对它们进行集成测试。为此，存在一个 特殊的测试存储库，其中几乎每天都会提取所有子系统树： - https://git.kernel.org/？p=linux/kernel/git/next/linux-next.git + https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git 通过这种方式，Linux-next 对下一个合并阶段将进入主线内核的内容给出了一个概要 展望。非常欢冒险的测试者运行测试Linux-next。 -- cgit From e01159c71394f4137aff1bcb75402bec7754dc1c Mon Sep 17 00:00:00 2001 From: Bagas Sanjaya Date: Thu, 7 Apr 2022 11:58:30 +0700 Subject: Documentation: arch_pgtable_helpers: demote pgtable list headings All page title headings in arch_pgtable_helpers.txt except "Architecture Page Table Helpers" should have been subheadings instead. Demote them to chapter headings. Cc: Andrew Morton Cc: Anshuman Khandual Signed-off-by: Bagas Sanjaya Signed-off-by: Jonathan Corbet --- Documentation/vm/arch_pgtable_helpers.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/arch_pgtable_helpers.rst b/Documentation/vm/arch_pgtable_helpers.rst index f8b225fc9190..cbaee9e59241 100644 --- a/Documentation/vm/arch_pgtable_helpers.rst +++ b/Documentation/vm/arch_pgtable_helpers.rst @@ -13,7 +13,7 @@ Following tables describe the expected semantics which can also be tested during boot via CONFIG_DEBUG_VM_PGTABLE option. All future changes in here or the debug test need to be in sync. -====================== + PTE Page Table Helpers ====================== @@ -79,7 +79,7 @@ PTE Page Table Helpers | ptep_set_access_flags | Converts into a more permissive PTE | +---------------------------+--------------------------------------------------+ -====================== + PMD Page Table Helpers ====================== @@ -153,7 +153,7 @@ PMD Page Table Helpers | pmdp_set_access_flags | Converts into a more permissive PMD | +---------------------------+--------------------------------------------------+ -====================== + PUD Page Table Helpers ====================== @@ -209,7 +209,7 @@ PUD Page Table Helpers | pudp_set_access_flags | Converts into a more permissive PUD | +---------------------------+--------------------------------------------------+ -========================== + HugeTLB Page Table Helpers ========================== @@ -235,7 +235,7 @@ HugeTLB Page Table Helpers | huge_ptep_set_access_flags | Converts into a more permissive HugeTLB | +---------------------------+--------------------------------------------------+ -======================== + SWAP Page Table Helpers ======================== -- cgit From bad3fbb2568abf8a9744720c5ef3a5ffc97531c9 Mon Sep 17 00:00:00 2001 From: Dylan Yudaken Date: Tue, 5 Apr 2022 02:54:14 -0700 Subject: docs: fault-injection: fix defaults ignore-gfp-wait and ignore-gfp-highmem defaults are actually true (Y) in both failslab and fail_page_alloc, not false as the docs suggest. See page_alloc.c:3762 and failslab.c:13 At the same time use 'Y' instead of '1' in the example scripts just for consistency. (though 1 would work) Signed-off-by: Dylan Yudaken Reviewed-by: Akinobu Mita Signed-off-by: Jonathan Corbet --- Documentation/fault-injection/fault-injection.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst index 4a25c5eb6f07..eb9c2d9a4f5f 100644 --- a/Documentation/fault-injection/fault-injection.rst +++ b/Documentation/fault-injection/fault-injection.rst @@ -132,16 +132,16 @@ configuration of fault-injection capabilities. Format: { 'Y' | 'N' } - default is 'N', setting it to 'Y' won't inject failures into - highmem/user allocations. + default is 'Y', setting it to 'N' will also inject failures into + highmem/user allocations (__GFP_HIGHMEM allocations). - /sys/kernel/debug/failslab/ignore-gfp-wait: - /sys/kernel/debug/fail_page_alloc/ignore-gfp-wait: Format: { 'Y' | 'N' } - default is 'N', setting it to 'Y' will inject failures - only into non-sleep allocations (GFP_ATOMIC allocations). + default is 'Y', setting it to 'N' will also inject failures + into allocations that can sleep (__GFP_DIRECT_RECLAIM allocations). - /sys/kernel/debug/fail_page_alloc/min-order: @@ -280,7 +280,7 @@ Application Examples printf %#x -1 > /sys/kernel/debug/$FAILTYPE/times echo 0 > /sys/kernel/debug/$FAILTYPE/space echo 2 > /sys/kernel/debug/$FAILTYPE/verbose - echo 1 > /sys/kernel/debug/$FAILTYPE/ignore-gfp-wait + echo Y > /sys/kernel/debug/$FAILTYPE/ignore-gfp-wait faulty_system() { @@ -334,8 +334,8 @@ Application Examples printf %#x -1 > /sys/kernel/debug/$FAILTYPE/times echo 0 > /sys/kernel/debug/$FAILTYPE/space echo 2 > /sys/kernel/debug/$FAILTYPE/verbose - echo 1 > /sys/kernel/debug/$FAILTYPE/ignore-gfp-wait - echo 1 > /sys/kernel/debug/$FAILTYPE/ignore-gfp-highmem + echo Y > /sys/kernel/debug/$FAILTYPE/ignore-gfp-wait + echo Y > /sys/kernel/debug/$FAILTYPE/ignore-gfp-highmem echo 10 > /sys/kernel/debug/$FAILTYPE/stacktrace-depth trap "echo 0 > /sys/kernel/debug/$FAILTYPE/probability" SIGINT SIGTERM EXIT -- cgit From 82850028aab5b44923e2c8a2fe875ecd32590835 Mon Sep 17 00:00:00 2001 From: Akihiko Odaki Date: Mon, 21 Mar 2022 13:58:53 +0900 Subject: x86/efi: Remove references of EFI earlyprintk from documentation x86 EFI earlyprink was removed with commit 69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation"). Signed-off-by: Akihiko Odaki Reviewed-by: Ard Biesheuvel Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/kernel-parameters.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 3f1cc5e317ed..1e023ba5bea8 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1282,7 +1282,7 @@ Append ",keep" to not disable it when the real console takes over. - Only one of vga, efi, serial, or usb debug port can + Only one of vga, serial, or usb debug port can be used at a time. Currently only ttyS0 and ttyS1 may be specified by @@ -1297,7 +1297,7 @@ Interaction with the standard serial driver is not very good. - The VGA and EFI output is eventually overwritten by + The VGA output is eventually overwritten by the real console. The xen option can only be used in Xen domains. -- cgit From 59bdbbd5bcd4c4d4266ac7e4e35e98c9fe8bde70 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sat, 2 Apr 2022 22:48:20 -0700 Subject: Docs: admin/kernel-parameters: edit a few boot options Clean up some of admin-guide/kernel-parameters.txt: a. "smt" should be "smt=" (S390) b. (dropped) c. Sparc supports the vdso= boot option d. make the tp_printk options (2) formatting similar to other options by adding spacing e. add "trace_clock=" with a reference to Documentation/trace/ftrace.rst f. use [IA-64] as documented instead of [ia64] g. fix formatting and text for test_suspend= h. fix formatting for swapaccount= i. fix formatting and grammar for video.brightness_switch_enabled= Signed-off-by: Randy Dunlap Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Alexander Gordeev Cc: Christian Borntraeger Cc: Sven Schnelle Cc: linux-s390@vger.kernel.org Cc: Steven Rostedt Cc: Ingo Molnar Cc: "David S. Miller" Cc: sparclinux@vger.kernel.org Cc: Michael Ellerman Cc: linux-ia64@vger.kernel.org Cc: "Rafael J. Wysocki" Cc: Pavel Machek Cc: Len Brown Cc: linux-pm@vger.kernel.org Cc: linux-acpi@vger.kernel.org Cc: Johannes Weiner Cc: Andrew Morton Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Acked-by: Rafael J. Wysocki Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/kernel-parameters.txt | 47 +++++++++++++++++++------ 1 file changed, 36 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 1e023ba5bea8..d524ad2b5fe3 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2814,7 +2814,7 @@ different yeeloong laptops. Example: machtype=lemote-yeeloong-2f-7inch - max_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory greater + max_addr=nn[KMG] [KNL,BOOT,IA-64] All physical memory greater than or equal to this physical address is ignored. maxcpus= [SMP] Maximum number of processors that an SMP kernel @@ -3057,7 +3057,7 @@ mga= [HW,DRM] - min_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory below this + min_addr=nn[KMG] [KNL,BOOT,IA-64] All physical memory below this physical address is ignored. mini2440= [ARM,HW,KNL] @@ -5388,7 +5388,7 @@ 1: Fast pin select (default) 2: ATC IRMode - smt [KNL,S390] Set the maximum number of threads (logical + smt= [KNL,S390] Set the maximum number of threads (logical CPUs) to use per physical CPU on systems capable of symmetric multithreading (SMT). Will be capped to the actual hardware limit. @@ -5743,8 +5743,9 @@ This parameter controls use of the Protected Execution Facility on pSeries. - swapaccount=[0|1] - [KNL] Enable accounting of swap in memory resource + swapaccount= [KNL] + Format: [0|1] + Enable accounting of swap in memory resource controller if no parameter or 1 is given or disable it if 0 is given (See Documentation/admin-guide/cgroup-v1/memory.rst) @@ -5790,7 +5791,8 @@ tdfx= [HW,DRM] - test_suspend= [SUSPEND][,N] + test_suspend= [SUSPEND] + Format: { "mem" | "standby" | "freeze" }[,N] Specify "mem" (for Suspend-to-RAM) or "standby" (for standby suspend) or "freeze" (for suspend type freeze) as the system sleep state during system startup with @@ -5877,6 +5879,28 @@ trace_buf_size=nn[KMG] [FTRACE] will set tracing buffer size on each cpu. + trace_clock= [FTRACE] Set the clock used for tracing events + at boot up. + local - Use the per CPU time stamp counter + (converted into nanoseconds). Fast, but + depending on the architecture, may not be + in sync between CPUs. + global - Event time stamps are synchronize across + CPUs. May be slower than the local clock, + but better for some race conditions. + counter - Simple counting of events (1, 2, ..) + note, some counts may be skipped due to the + infrastructure grabbing the clock more than + once per event. + uptime - Use jiffies as the time stamp. + perf - Use the same clock that perf uses. + mono - Use ktime_get_mono_fast_ns() for time stamps. + mono_raw - Use ktime_get_raw_fast_ns() for time + stamps. + boot - Use ktime_get_boot_fast_ns() for time stamps. + Architectures may add more clocks. See + Documentation/trace/ftrace.rst for more details. + trace_event=[event-list] [FTRACE] Set and start specified trace events in order to facilitate early boot debugging. The event-list is a @@ -5899,7 +5923,7 @@ See also Documentation/trace/ftrace.rst "trace options" section. - tp_printk[FTRACE] + tp_printk [FTRACE] Have the tracepoints sent to printk as well as the tracing ring buffer. This is useful for early boot up where the system hangs or reboots and does not give the @@ -5921,7 +5945,7 @@ frequency tracepoints such as irq or sched, can cause the system to live lock. - tp_printk_stop_on_boot[FTRACE] + tp_printk_stop_on_boot [FTRACE] When tp_printk (above) is set, it can cause a lot of noise on the console. It may be useful to only include the printing of events during boot up, as user space may @@ -6270,7 +6294,7 @@ HIGHMEM regardless of setting of CONFIG_HIGHPTE. - vdso= [X86,SH] + vdso= [X86,SH,SPARC] On X86_32, this is an alias for vdso32=. Otherwise: vdso=1: enable VDSO (the default) @@ -6296,11 +6320,12 @@ video= [FB] Frame buffer configuration See Documentation/fb/modedb.rst. - video.brightness_switch_enabled= [0,1] + video.brightness_switch_enabled= [ACPI] + Format: [0|1] If set to 1, on receiving an ACPI notify event generated by hotkey, video driver will adjust brightness level and then send out the event to user space through - the allocated input device; If set to 0, video driver + the allocated input device. If set to 0, video driver will only send out the event without touching backlight brightness level. default: 1 -- cgit From d2fc83c149a7a690ec2ef98e540950c5f18e983f Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sat, 2 Apr 2022 22:48:21 -0700 Subject: Docs/admin: alphabetize some kernel-parameters (part 1) Move some out-of-place kernel parameters into their correct locations. Move one out-of-order keyword/legend in kernel-parameters.rst. Add some missing keyword legends in kernel-parameters.rst: HIBERNATION HYPER_V and drop some obsolete/removed keyword legends: EIDE IOSCHED OSS TS XT Correct the location of the setup.h file. Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Cc: "Rafael J. Wysocki" Cc: Pavel Machek Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/kernel-parameters.rst | 11 +-- Documentation/admin-guide/kernel-parameters.txt | 113 ++++++++++++------------ 2 files changed, 61 insertions(+), 63 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst index 01ba293a2d70..959f73a32712 100644 --- a/Documentation/admin-guide/kernel-parameters.rst +++ b/Documentation/admin-guide/kernel-parameters.rst @@ -99,6 +99,7 @@ parameter is applicable:: ALSA ALSA sound support is enabled. APIC APIC support is enabled. APM Advanced Power Management support is enabled. + APPARMOR AppArmor support is enabled. ARM ARM architecture is enabled. ARM64 ARM64 architecture is enabled. AX25 Appropriate AX.25 support is enabled. @@ -108,15 +109,15 @@ parameter is applicable:: DYNAMIC_DEBUG Build in debug messages and enable them at runtime EDD BIOS Enhanced Disk Drive Services (EDD) is enabled EFI EFI Partitioning (GPT) is enabled - EIDE EIDE/ATAPI support is enabled. EVM Extended Verification Module FB The frame buffer device is enabled. FTRACE Function tracing enabled. GCOV GCOV profiling is enabled. + HIBERNATION HIBERNATION is enabled. HW Appropriate hardware is enabled. + HYPER_V HYPERV support is enabled. IA-64 IA-64 architecture is enabled. IMA Integrity measurement architecture is enabled. - IOSCHED More than one I/O scheduler is enabled. IP_PNP IP DHCP, BOOTP, or RARP is enabled. IPV6 IPv6 support is enabled. ISAPNP ISA PnP code is enabled. @@ -140,7 +141,6 @@ parameter is applicable:: NUMA NUMA support is enabled. NFS Appropriate NFS support is enabled. OF Devicetree is enabled. - OSS OSS sound support is enabled. PV_OPS A paravirtualized kernel is enabled. PARIDE The ParIDE (parallel port IDE) subsystem is enabled. PARISC The PA-RISC architecture is enabled. @@ -160,7 +160,6 @@ parameter is applicable:: the Documentation/scsi/ sub-directory. SECURITY Different security models are enabled. SELINUX SELinux support is enabled. - APPARMOR AppArmor support is enabled. SERIAL Serial support is enabled. SH SuperH architecture is enabled. SMP The kernel is an SMP kernel. @@ -168,7 +167,6 @@ parameter is applicable:: SWSUSP Software suspend (hibernation) is enabled. SUSPEND System suspend states are enabled. TPM TPM drivers are enabled. - TS Appropriate touchscreen support is enabled. UMS USB Mass Storage support is enabled. USB USB support is enabled. USBHID USB Human Interface Device support is enabled. @@ -177,7 +175,6 @@ parameter is applicable:: VGA The VGA console has been enabled. VT Virtual terminal support is enabled. WDT Watchdog support is enabled. - XT IBM PC/XT MFM hard disk support is enabled. X86-32 X86-32, aka i386 architecture is enabled. X86-64 X86-64 architecture is enabled. More X86-64 boot options can be found in @@ -211,7 +208,7 @@ The number of kernel parameters is not limited, but the length of the complete command line (parameters including spaces etc.) is limited to a fixed number of characters. This limit depends on the architecture and is between 256 and 4096 characters. It is defined in the file -./include/asm/setup.h as COMMAND_LINE_SIZE. +./include/uapi/asm-generic/setup.h as COMMAND_LINE_SIZE. Finally, the [KMG] suffix is commonly described after a number of kernel parameter values. These 'K', 'M', and 'G' letters represent the _binary_ diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index d524ad2b5fe3..427926e5b2f1 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -563,6 +563,20 @@ cio_ignore= [S390] See Documentation/s390/common_io.rst for details. + + clearcpuid=BITNUM[,BITNUM...] [X86] + Disable CPUID feature X for the kernel. See + arch/x86/include/asm/cpufeatures.h for the valid bit + numbers. Note the Linux specific bits are not necessarily + stable over kernel options, but the vendor specific + ones should be. + Also note that user programs calling CPUID directly + or using the feature without checking anything + will still see it. This just prevents it from + being used by the kernel or shown in /proc/cpuinfo. + Also note the kernel might malfunction if you disable + some critical bits. + clk_ignore_unused [CLK] Prevents the clock framework from automatically gating @@ -631,19 +645,6 @@ Defaults to zero when built as a module and to 10 seconds when built into the kernel. - clearcpuid=BITNUM[,BITNUM...] [X86] - Disable CPUID feature X for the kernel. See - arch/x86/include/asm/cpufeatures.h for the valid bit - numbers. Note the Linux specific bits are not necessarily - stable over kernel options, but the vendor specific - ones should be. - Also note that user programs calling CPUID directly - or using the feature without checking anything - will still see it. This just prevents it from - being used by the kernel or shown in /proc/cpuinfo. - Also note the kernel might malfunction if you disable - some critical bits. - cma=nn[MG]@[start[MG][-end[MG]]] [KNL,CMA] Sets the size of kernel global memory area for @@ -950,6 +951,8 @@ dump out devices still on the deferred probe list after retrying. + delayacct [KNL] Enable per-task delay accounting + dell_smm_hwmon.ignore_dmi= [HW] Continue probing hardware even if DMI data indicates that the driver is running on unsupported @@ -1003,17 +1006,6 @@ disable= [IPV6] See Documentation/networking/ipv6.rst. - hardened_usercopy= - [KNL] Under CONFIG_HARDENED_USERCOPY, whether - hardening is enabled for this boot. Hardened - usercopy checking is used to protect the kernel - from reading or writing beyond known memory - allocation boundaries as a proactive defense - against bounds-checking flaws in the kernel's - copy_to_user()/copy_from_user() interface. - on Perform hardened usercopy checks (default). - off Disable hardened usercopy checks. - disable_radix [PPC] Disable RADIX MMU mode on POWER9 @@ -1316,17 +1308,6 @@ force: enforce the use of EDAC to report H/W event. default: on. - ekgdboc= [X86,KGDB] Allow early kernel console debugging - ekgdboc=kbd - - This is designed to be used in conjunction with - the boot argument: earlyprintk=vga - - This parameter works in place of the kgdboc parameter - but can only be used if the backing tty is available - very early in the boot process. For early debugging - via a serial port see kgdboc_earlycon instead. - edd= [EDD] Format: {"off" | "on" | "skip[mbr]"} @@ -1388,6 +1369,17 @@ eisa_irq_edge= [PARISC,HW] See header of drivers/parisc/eisa.c. + ekgdboc= [X86,KGDB] Allow early kernel console debugging + Format: ekgdboc=kbd + + This is designed to be used in conjunction with + the boot argument: earlyprintk=vga + + This parameter works in place of the kgdboc parameter + but can only be used if the backing tty is available + very early in the boot process. For early debugging + via a serial port see kgdboc_earlycon instead. + elanfreq= [X86-32] See comment before function elanfreq_setup() in arch/x86/kernel/cpu/cpufreq/elanfreq.c. @@ -1586,6 +1578,17 @@ Format: such that (rxsize & ~0x1fffc0) == 0. Default: 1024 + hardened_usercopy= + [KNL] Under CONFIG_HARDENED_USERCOPY, whether + hardening is enabled for this boot. Hardened + usercopy checking is used to protect the kernel + from reading or writing beyond known memory + allocation boundaries as a proactive defense + against bounds-checking flaws in the kernel's + copy_to_user()/copy_from_user() interface. + on Perform hardened usercopy checks (default). + off Disable hardened usercopy checks. + hardlockup_all_cpu_backtrace= [KNL] Should the hard-lockup detector generate backtraces on all cpus. @@ -1606,6 +1609,15 @@ corresponding firmware-first mode error processing logic will be disabled. + hibernate= [HIBERNATION] + noresume Don't check if there's a hibernation image + present during boot. + nocompress Don't compress/decompress hibernation images. + no Disable hibernation and resume. + protect_image Turn on image protection during restoration + (that will set all pages holding image data + during restoration read-only). + highmem=nn[KMG] [KNL,BOOT] forces the highmem zone to have an exact size of . This works even on boxes that have no highmem otherwise. This also works to reduce highmem @@ -3185,16 +3197,6 @@ firmware feature for updating multiple TCE entries at a time. - onenand.bdry= [HW,MTD] Flex-OneNAND Boundary Configuration - - Format: [die0_boundary][,die0_lock][,die1_boundary][,die1_lock] - - boundary - index of last SLC block on Flex-OneNAND. - The remaining blocks are configured as MLC blocks. - lock - Configure if Flex-OneNAND boundary should be locked. - Once locked, the boundary cannot be changed. - 1 indicates lock status, 0 indicates unlock status. - mtdset= [ARM] ARM/S3C2412 JIVE boot control @@ -3441,8 +3443,6 @@ noclflush [BUGS=X86] Don't use the CLFLUSH instruction - delayacct [KNL] Enable per-task delay accounting - nodsp [SH] Disable hardware DSP at boot time. noefi Disable EFI runtime services support. @@ -3744,6 +3744,16 @@ For example, to override I2C bus2: omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100 + onenand.bdry= [HW,MTD] Flex-OneNAND Boundary Configuration + + Format: [die0_boundary][,die0_lock][,die1_boundary][,die1_lock] + + boundary - index of last SLC block on Flex-OneNAND. + The remaining blocks are configured as MLC blocks. + lock - Configure if Flex-OneNAND boundary should be locked. + Once locked, the boundary cannot be changed. + 1 indicates lock status, 0 indicates unlock status. + oops=panic Always panic on oopses. Default is to just kill the process, but there is a small probability of deadlocking the machine. @@ -5077,15 +5087,6 @@ Useful for devices that are detected asynchronously (e.g. USB and MMC devices). - hibernate= [HIBERNATION] - noresume Don't check if there's a hibernation image - present during boot. - nocompress Don't compress/decompress hibernation images. - no Disable hibernation and resume. - protect_image Turn on image protection during restoration - (that will set all pages holding image data - during restoration read-only). - retain_initrd [RAM] Keep initrd memory after extraction rfkill.default_state= -- cgit From 389cfd96703ea7390c2ba3968dbdac0e48c396cf Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sat, 2 Apr 2022 22:48:22 -0700 Subject: docs/admin: alphabetize parts of kernel-parameters.txt (part 2) Alphabetize several of the kernel boot parameters in kernel-parameters.txt. Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/kernel-parameters.txt | 166 ++++++++++++------------ 1 file changed, 83 insertions(+), 83 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 427926e5b2f1..7ca823a3d5ba 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -461,6 +461,12 @@ Format: ,, See header of drivers/net/hamradio/baycom_ser_hdx.c. + bert_disable [ACPI] + Disable BERT OS support on buggy BIOSes. + + bgrt_disable [ACPI][X86] + Disable BGRT to avoid flickering OEM logo. + blkdevparts= Manual partition parsing of block device(s) for embedded devices based on command line input. See Documentation/block/cmdline-partition.rst @@ -476,12 +482,6 @@ See Documentation/admin-guide/bootconfig.rst - bert_disable [ACPI] - Disable BERT OS support on buggy BIOSes. - - bgrt_disable [ACPI][X86] - Disable BGRT to avoid flickering OEM logo. - bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards) bttv.radio= Most important insmod options are available as kernel args too. @@ -766,6 +766,24 @@ 0: default value, disable debugging 1: enable debugging at boot time + cpcihp_generic= [HW,PCI] Generic port I/O CompactPCI driver + Format: + ,,,[,] + + cpu0_hotplug [X86] Turn on CPU0 hotplug feature when + CONFIG_BOOTPARAM_HOTPLUG_CPU0 is off. + Some features depend on CPU0. Known dependencies are: + 1. Resume from suspend/hibernate depends on CPU0. + Suspend/hibernate will fail if CPU0 is offline and you + need to online CPU0 before suspend/hibernate. + 2. PIC interrupts also depend on CPU0. CPU0 can't be + removed if a PIC interrupt is detected. + It's said poweroff/reboot may depend on CPU0 on some + machines although I haven't seen such issues so far + after CPU0 is offline on a few tested machines. + If the dependencies are under your control, you can + turn on cpu0_hotplug. + cpuidle.off=1 [CPU_IDLE] disable the cpuidle sub-system @@ -786,9 +804,13 @@ on every CPU online, such as boot, and resume from suspend. Default: 10000 - cpcihp_generic= [HW,PCI] Generic port I/O CompactPCI driver - Format: - ,,,[,] + crash_kexec_post_notifiers + Run kdump after running panic-notifiers and dumping + kmsg. This only for the users who doubt kdump always + succeeds in any situation. + Note that this also increases risks of kdump failure, + because some panic notifiers can make the crashed + kernel more unstable. crashkernel=size[KMG][@offset[KMG]] [KNL] Using kexec, Linux can switch to a 'crash kernel' @@ -1640,16 +1662,6 @@ hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET registers. Default set by CONFIG_HPET_MMAP_DEFAULT. - hugetlb_cma= [HW,CMA] The size of a CMA area used for allocation - of gigantic hugepages. Or using node format, the size - of a CMA area per node can be specified. - Format: nn[KMGTPE] or (node format) - :nn[KMGTPE][,:nn[KMGTPE]] - - Reserve a CMA area of given size and allocate gigantic - hugepages using the CMA allocator. If enabled, the - boot-time allocation of gigantic hugepages is skipped. - hugepages= [HW] Number of HugeTLB pages to allocate at boot. If this follows hugepagesz (below), it specifies the number of pages of hugepagesz to be allocated. @@ -1671,6 +1683,16 @@ Documentation/admin-guide/mm/hugetlbpage.rst. Format: size[KMG] + hugetlb_cma= [HW,CMA] The size of a CMA area used for allocation + of gigantic hugepages. Or using node format, the size + of a CMA area per node can be specified. + Format: nn[KMGTPE] or (node format) + :nn[KMGTPE][,:nn[KMGTPE]] + + Reserve a CMA area of given size and allocate gigantic + hugepages using the CMA allocator. If enabled, the + boot-time allocation of gigantic hugepages is skipped. + hugetlb_free_vmemmap= [KNL] Reguires CONFIG_HUGETLB_PAGE_FREE_VMEMMAP enabled. @@ -2683,8 +2705,6 @@ If there are multiple matching configurations changing the same attribute, the last one is used. - memblock=debug [KNL] Enable memblock debug messages. - load_ramdisk= [RAM] [Deprecated] lockd.nlm_grace_period=P [NFS] Assign grace period. @@ -2926,6 +2946,8 @@ mem=nopentium [BUGS=X86-32] Disable usage of 4MB pages for kernel memory. + memblock=debug [KNL] Enable memblock debug messages. + memchunk=nn[KMG] [KNL,SH] Allow user to override the default size for per-device physically contiguous DMA buffers. @@ -3193,10 +3215,6 @@ mtdparts= [MTD] See drivers/mtd/parsers/cmdlinepart.c - multitce=off [PPC] This parameter disables the use of the pSeries - firmware feature for updating multiple TCE entries - at a time. - mtdset= [ARM] ARM/S3C2412 JIVE boot control @@ -3223,6 +3241,10 @@ Used for mtrr cleanup. It is spare mtrr entries number. Set to 2 or more if your graphical card needs more. + multitce=off [PPC] This parameter disables the use of the pSeries + firmware feature for updating multiple TCE entries + at a time. + n2= [NET] SDL Inc. RISCom/N2 synchronous serial card netdev= [NET] Network devices parameters @@ -3232,6 +3254,11 @@ This usage is only documented in each driver source file if at all. + netpoll.carrier_timeout= + [NET] Specifies amount of time (in seconds) that + netpoll should wait for a carrier. By default netpoll + waits 4 seconds. + nf_conntrack.acct= [NETFILTER] Enable connection tracking flow accounting 0 to disable accounting @@ -3382,11 +3409,6 @@ These settings can be accessed at runtime via the nmi_watchdog and hardlockup_panic sysctls. - netpoll.carrier_timeout= - [NET] Specifies amount of time (in seconds) that - netpoll should wait for a carrier. By default netpoll - waits 4 seconds. - no387 [BUGS=X86-32] Tells the kernel to use the 387 maths emulation library even if a 387 maths coprocessor is present. @@ -3678,20 +3700,6 @@ nox2apic [X86-64,APIC] Do not enable x2APIC mode. - cpu0_hotplug [X86] Turn on CPU0 hotplug feature when - CONFIG_BOOTPARAM_HOTPLUG_CPU0 is off. - Some features depend on CPU0. Known dependencies are: - 1. Resume from suspend/hibernate depends on CPU0. - Suspend/hibernate will fail if CPU0 is offline and you - need to online CPU0 before suspend/hibernate. - 2. PIC interrupts also depend on CPU0. CPU0 can't be - removed if a PIC interrupt is detected. - It's said poweroff/reboot may depend on CPU0 on some - machines although I haven't seen such issues so far - after CPU0 is offline on a few tested machines. - If the dependencies are under your control, you can - turn on cpu0_hotplug. - nps_mtm_hs_ctr= [KNL,ARC] This parameter sets the maximum duration, in cycles, each HW thread of the CTOP can run @@ -3824,14 +3832,6 @@ panic_on_warn panic() instead of WARN(). Useful to cause kdump on a WARN(). - crash_kexec_post_notifiers - Run kdump after running panic-notifiers and dumping - kmsg. This only for the users who doubt kdump always - succeeds in any situation. - Note that this also increases risks of kdump failure, - because some panic notifiers can make the crashed - kernel more unstable. - parkbd.port= [HW] Parallel port number the keyboard adapter is connected to, default is 0. Format: @@ -5877,6 +5877,37 @@ This will guarantee that all the other pcrs are saved. + tp_printk [FTRACE] + Have the tracepoints sent to printk as well as the + tracing ring buffer. This is useful for early boot up + where the system hangs or reboots and does not give the + option for reading the tracing buffer or performing a + ftrace_dump_on_oops. + + To turn off having tracepoints sent to printk, + echo 0 > /proc/sys/kernel/tracepoint_printk + Note, echoing 1 into this file without the + tracepoint_printk kernel cmdline option has no effect. + + The tp_printk_stop_on_boot (see below) can also be used + to stop the printing of events to console at + late_initcall_sync. + + ** CAUTION ** + + Having tracepoints sent to printk() and activating high + frequency tracepoints such as irq or sched, can cause + the system to live lock. + + tp_printk_stop_on_boot [FTRACE] + When tp_printk (above) is set, it can cause a lot of noise + on the console. It may be useful to only include the + printing of events during boot up, as user space may + make the system inoperable. + + This command line option will stop the printing of events + to console at the late_initcall_sync() time frame. + trace_buf_size=nn[KMG] [FTRACE] will set tracing buffer size on each cpu. @@ -5924,37 +5955,6 @@ See also Documentation/trace/ftrace.rst "trace options" section. - tp_printk [FTRACE] - Have the tracepoints sent to printk as well as the - tracing ring buffer. This is useful for early boot up - where the system hangs or reboots and does not give the - option for reading the tracing buffer or performing a - ftrace_dump_on_oops. - - To turn off having tracepoints sent to printk, - echo 0 > /proc/sys/kernel/tracepoint_printk - Note, echoing 1 into this file without the - tracepoint_printk kernel cmdline option has no effect. - - The tp_printk_stop_on_boot (see below) can also be used - to stop the printing of events to console at - late_initcall_sync. - - ** CAUTION ** - - Having tracepoints sent to printk() and activating high - frequency tracepoints such as irq or sched, can cause - the system to live lock. - - tp_printk_stop_on_boot [FTRACE] - When tp_printk (above) is set, it can cause a lot of noise - on the console. It may be useful to only include the - printing of events during boot up, as user space may - make the system inoperable. - - This command line option will stop the printing of events - to console at the late_initcall_sync() time frame. - traceoff_on_warning [FTRACE] enable this option to disable tracing when a warning is hit. This turns off "tracing_on". Tracing can -- cgit From 6c757e9f55f02fbc226823f8d441cd03cc282109 Mon Sep 17 00:00:00 2001 From: Jui-Tse Huang Date: Fri, 15 Apr 2022 11:36:18 +0800 Subject: docs/scheduler: fix unit error The unit mentioned in the documentation of scheduler statistics is outdated which may mislead the readers. The unit of statistics that is reported by /proc/schedstat is modified to nanosecond, and the unit of statistics that is reported by /proc/PID/schedstat is provided as well to make the context consistent. The rq_cpu_time and the rq_sched_info.run_delay of a run queue, and the sched_info.run_delay of a task are all updated based on the clock of the run queue, while the se.sum_exec_runtime of a task is updated based on the clock_task of the run queue of the task. Both the clock and clock_task are relied on the return value of the function sched_clock() which is in the unit of nanosecond. Signed-off-by: Jui-Tse Huang Signed-off-by: Jonathan Corbet --- Documentation/scheduler/sched-stats.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scheduler/sched-stats.rst b/Documentation/scheduler/sched-stats.rst index 9078a27a4137..03c062915998 100644 --- a/Documentation/scheduler/sched-stats.rst +++ b/Documentation/scheduler/sched-stats.rst @@ -155,8 +155,8 @@ schedstats also adds a new /proc//schedstat file to include some of the same information on a per-process level. There are three fields in this file correlating for that process to: - 1) time spent on the cpu - 2) time spent waiting on a runqueue + 1) time spent on the cpu (in nanoseconds) + 2) time spent waiting on a runqueue (in nanoseconds) 3) # of timeslices run on this cpu A program could be easily written to make use of these extra fields to -- cgit From 402fc936d5a9328779f175893b30ae165d45a11e Mon Sep 17 00:00:00 2001 From: Rex-BC Chen Date: Mon, 11 Apr 2022 11:58:41 +0800 Subject: dt-bindings: display: mediatek: Update disp_aal binding for MT8183 The driver data of MT8183 and MT8173 are different. For MT8173, the gamma module is inside disp_aal. When we need to adjust gamma value, we need to use "has_gamma" to control gamma function inside disp_aal to adjust the gamma value. For successors like MT8183, disp_gamma is separated from disp_aal. We just need to control disp_gamma directly and don't need to control gamma function inside disp_aal. With this modification, the driver doesn't require any functional changes. We only update the dt-binding and DTS node to make it clear. Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220411035843.19847-2-rex-bc.chen@mediatek.com/ Signed-off-by: Rex-BC Chen Reviewed-by: AngeloGioacchino Del Regno Acked-by: Rob Herring Signed-off-by: Chun-Kuang Hu --- .../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index cb4a2f39ff88..f118075e4a89 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -21,12 +21,12 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8173-disp-aal + - enum: + - mediatek,mt8173-disp-aal + - mediatek,mt8183-disp-aal - items: - enum: - mediatek,mt2712-disp-aal - - mediatek,mt8183-disp-aal - mediatek,mt8192-disp-aal - mediatek,mt8195-disp-aal - const: mediatek,mt8173-disp-aal -- cgit From 4ee7b96163f2e16f0a919398968115420008bcf4 Mon Sep 17 00:00:00 2001 From: Rex-BC Chen Date: Mon, 11 Apr 2022 11:58:43 +0800 Subject: dt-bindings: display: mediatek: Update disp_aal binding for MT8192 and MT8195 Disp_aal of MT8192 and MT8195 are fully compatible with disp_aal of MT8183. Therefore, we move the them to item "mediatek,mt8183-disp-aal". Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220406094654.29722-4-rex-bc.chen@mediatek.com/ Signed-off-by: Rex-BC Chen Acked-by: Rob Herring Signed-off-by: Chun-Kuang Hu --- Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index f118075e4a89..d4d585485e7b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -27,12 +27,12 @@ properties: - items: - enum: - mediatek,mt2712-disp-aal - - mediatek,mt8192-disp-aal - - mediatek,mt8195-disp-aal - const: mediatek,mt8173-disp-aal - items: - enum: - mediatek,mt8186-disp-aal + - mediatek,mt8192-disp-aal + - mediatek,mt8195-disp-aal - const: mediatek,mt8183-disp-aal reg: -- cgit From f9a2fb73318eb4dbf8cd84866b8b0dd012d8b116 Mon Sep 17 00:00:00 2001 From: Arun Ajith S Date: Fri, 15 Apr 2022 08:34:02 +0000 Subject: net/ipv6: Introduce accept_unsolicited_na knob to implement router-side changes for RFC9131 Add a new neighbour cache entry in STALE state for routers on receiving an unsolicited (gratuitous) neighbour advertisement with target link-layer-address option specified. This is similar to the arp_accept configuration for IPv4. A new sysctl endpoint is created to turn on this behaviour: /proc/sys/net/ipv6/conf/interface/accept_unsolicited_na. Signed-off-by: Arun Ajith S Reviewed-by: David Ahern Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.rst | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index b0024aa7b051..433f2e4a5fed 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -2467,6 +2467,33 @@ drop_unsolicited_na - BOOLEAN By default this is turned off. +accept_unsolicited_na - BOOLEAN + Add a new neighbour cache entry in STALE state for routers on receiving an + unsolicited neighbour advertisement with target link-layer address option + specified. This is as per router-side behavior documented in RFC9131. + This has lower precedence than drop_unsolicited_na. + + ==== ====== ====== ============================================== + drop accept fwding behaviour + ---- ------ ------ ---------------------------------------------- + 1 X X Drop NA packet and don't pass up the stack + 0 0 X Pass NA packet up the stack, don't update NC + 0 1 0 Pass NA packet up the stack, don't update NC + 0 1 1 Pass NA packet up the stack, and add a STALE + NC entry + ==== ====== ====== ============================================== + + This will optimize the return path for the initial off-link communication + that is initiated by a directly connected host, by ensuring that + the first-hop router which turns on this setting doesn't have to + buffer the initial return packets to do neighbour-solicitation. + The prerequisite is that the host is configured to send + unsolicited neighbour advertisements on interface bringup. + This setting should be used in conjunction with the ndisc_notify setting + on the host to satisfy this prerequisite. + + By default this is turned off. + enhanced_dad - BOOLEAN Include a nonce option in the IPv6 neighbor solicitation messages used for duplicate address detection per RFC7527. A received DAD NS will only signal -- cgit From 6d289c378af46e4832b3425fb31d96438b2b38e6 Mon Sep 17 00:00:00 2001 From: Bhupesh Sharma Date: Sun, 27 Feb 2022 00:10:25 +0530 Subject: dt-bindings: qcom,pdc: Add compatible for SM8150 Add the compatible string for SM8150 SoC from Qualcomm. Cc: Bjorn Andersson Cc: Vinod Koul Cc: Marc Zyngier Acked-by: Rob Herring Signed-off-by: Bhupesh Sharma Reviewed-by: Bjorn Andersson Reviewed-by: Vinod Koul Link: https://lore.kernel.org/r/20220226184028.111566-2-bhupesh.sharma@linaro.org Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt index 98d89e53013d..bd3539644d3f 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt @@ -21,6 +21,7 @@ Properties: - "qcom,sc7180-pdc": For SC7180 - "qcom,sc7280-pdc": For SC7280 - "qcom,sdm845-pdc": For SDM845 + - "qcom,sdm8150-pdc": For SM8150 - "qcom,sdm8250-pdc": For SM8250 - "qcom,sdm8350-pdc": For SM8350 -- cgit From 9247752bac3a66a752f3f926c40996935da14e69 Mon Sep 17 00:00:00 2001 From: Chris Packham Date: Fri, 15 Apr 2022 11:30:52 +1200 Subject: dt-bindings: pinctrl: mvebu: Document bindings for AC5 Add JSON schema for marvell,ac5-pinctrl present on the Marvell 98DX2530 SoC. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220414233055.586962-2-chris.packham@alliedtelesis.co.nz Signed-off-by: Linus Walleij --- .../bindings/pinctrl/marvell,ac5-pinctrl.yaml | 72 ++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml new file mode 100644 index 000000000000..a651b2744caf --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/marvell,ac5-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell AC5 pin controller + +maintainers: + - Chris Packham + +description: + Bindings for Marvell's AC5 memory-mapped pin controller. + +properties: + compatible: + items: + - const: marvell,ac5-pinctrl + + reg: + maxItems: 1 + +patternProperties: + '-pins$': + type: object + $ref: pinmux-node.yaml# + + properties: + marvell,function: + $ref: "/schemas/types.yaml#/definitions/string" + description: + Indicates the function to select. + enum: [ dev_init_done, ge, gpio, i2c0, i2c1, int_out, led, nand, pcie, ptp, sdio, + spi0, spi1, synce, tsen_int, uart0, uart1, uart2, uart3, uartsd, wd_int, xg ] + + marvell,pins: + $ref: /schemas/types.yaml#/definitions/string-array + description: + Array of MPP pins to be used for the given function. + minItems: 1 + items: + enum: [ mpp0, mpp1, mpp2, mpp3, mpp4, mpp5, mpp6, mpp7, mpp8, mpp9, + mpp10, mpp11, mpp12, mpp13, mpp14, mpp15, mpp16, mpp17, mpp18, mpp19, + mpp20, mpp21, mpp22, mpp23, mpp24, mpp25, mpp26, mpp27, mpp28, mpp29, + mpp30, mpp31, mpp32, mpp33, mpp34, mpp35, mpp36, mpp37, mpp38, mpp39, + mpp40, mpp41, mpp42, mpp43, mpp44, mpp45 ] + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + pinctrl@80020100 { + compatible = "marvell,ac5-pinctrl"; + reg = <0x80020100 0x20>; + + i2c0_pins: i2c0-pins { + marvell,pins = "mpp26", "mpp27"; + marvell,function = "i2c0"; + }; + + i2c0_gpio: i2c0-gpio-pins { + marvell,pins = "mpp26", "mpp27"; + marvell,function = "gpio"; + }; + }; -- cgit From d08afeb445ca8e97e25976e1082631e9fc07cf23 Mon Sep 17 00:00:00 2001 From: Jae Hyun Yoo Date: Tue, 29 Mar 2022 10:39:28 -0700 Subject: dt-bindings: pinctrl: aspeed-g6: remove FWQSPID group FWQSPID is not a group of FWSPID so remove it. Fixes: 7488838f2315 ("dt-bindings: pinctrl: aspeed: Document AST2600 pinmux") Signed-off-by: Jae Hyun Yoo Reviewed-by: Andrew Jeffery Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220329173932.2588289-4-quic_jaehyoo@quicinc.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml index 57b68d6c7c70..eb6e2f2dc9eb 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml @@ -58,7 +58,7 @@ patternProperties: $ref: "/schemas/types.yaml#/definitions/string" enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMCG1, EMMCG4, - EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWQSPID, FWSPIWP, + EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, HVI3C3, HVI3C4, I2C1, I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, -- cgit From 925fbe1f7eb6fa7077d92b591b7ced1367358563 Mon Sep 17 00:00:00 2001 From: Jae Hyun Yoo Date: Tue, 29 Mar 2022 10:39:30 -0700 Subject: dt-bindings: pinctrl: aspeed-g6: add FWQSPI function/group Add FWQSPI function/group to support QSPI mode on the dedicated FWSPI interface. Signed-off-by: Jae Hyun Yoo Reviewed-by: Andrew Jeffery Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220329173932.2588289-6-quic_jaehyoo@quicinc.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml index eb6e2f2dc9eb..3666ac5b6518 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml @@ -33,7 +33,7 @@ patternProperties: $ref: "/schemas/types.yaml#/definitions/string" enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMC, ESPI, ESPIALT, - FSI1, FSI2, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3, + FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, I2C1, I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, @@ -58,7 +58,7 @@ patternProperties: $ref: "/schemas/types.yaml#/definitions/string" enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMCG1, EMMCG4, - EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWSPIWP, + EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, HVI3C3, HVI3C4, I2C1, I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, -- cgit From fcdc8ce23a309c26a67fc613a741d9b21a248311 Mon Sep 17 00:00:00 2001 From: Jiri Pirko Date: Mon, 18 Apr 2022 09:42:26 +0300 Subject: devlink: implement line card provisioning In order to be able to configure all needed stuff on a port/netdevice of a line card without the line card being present, introduce line card provisioning. Basically by setting a type, provisioning process will start and driver is supposed to create a placeholder for instances (ports/netdevices) for a line card type. Allow the user to query the supported line card types over line card get command. Then implement two netlink command SET to allow user to set/unset the card type. On the driver API side, add provision/unprovision ops and supported types array to be advertised. Upon provision op call, the driver should take care of creating the instances for the particular line card type. Introduce provision_set/clear() functions to be called by the driver once the provisioning/unprovisioning is done on its side. These helpers are not to be called directly due to the async nature of provisioning. Example: $ devlink port # No ports are listed $ devlink lc pci/0000:01:00.0: lc 1 state unprovisioned supported_types: 16x100G lc 2 state unprovisioned supported_types: 16x100G lc 3 state unprovisioned supported_types: 16x100G lc 4 state unprovisioned supported_types: 16x100G lc 5 state unprovisioned supported_types: 16x100G lc 6 state unprovisioned supported_types: 16x100G lc 7 state unprovisioned supported_types: 16x100G lc 8 state unprovisioned supported_types: 16x100G $ devlink lc set pci/0000:01:00.0 lc 8 type 16x100G $ devlink lc show pci/0000:01:00.0 lc 8 pci/0000:01:00.0: lc 8 state active type 16x100G supported_types: 16x100G $ devlink port pci/0000:01:00.0/0: type notset flavour cpu port 0 splittable false pci/0000:01:00.0/53: type eth netdev enp1s0nl8p1 flavour physical lc 8 port 1 splittable true lanes 4 pci/0000:01:00.0/54: type eth netdev enp1s0nl8p2 flavour physical lc 8 port 2 splittable true lanes 4 pci/0000:01:00.0/55: type eth netdev enp1s0nl8p3 flavour physical lc 8 port 3 splittable true lanes 4 pci/0000:01:00.0/56: type eth netdev enp1s0nl8p4 flavour physical lc 8 port 4 splittable true lanes 4 pci/0000:01:00.0/57: type eth netdev enp1s0nl8p5 flavour physical lc 8 port 5 splittable true lanes 4 pci/0000:01:00.0/58: type eth netdev enp1s0nl8p6 flavour physical lc 8 port 6 splittable true lanes 4 pci/0000:01:00.0/59: type eth netdev enp1s0nl8p7 flavour physical lc 8 port 7 splittable true lanes 4 pci/0000:01:00.0/60: type eth netdev enp1s0nl8p8 flavour physical lc 8 port 8 splittable true lanes 4 pci/0000:01:00.0/61: type eth netdev enp1s0nl8p9 flavour physical lc 8 port 9 splittable true lanes 4 pci/0000:01:00.0/62: type eth netdev enp1s0nl8p10 flavour physical lc 8 port 10 splittable true lanes 4 pci/0000:01:00.0/63: type eth netdev enp1s0nl8p11 flavour physical lc 8 port 11 splittable true lanes 4 pci/0000:01:00.0/64: type eth netdev enp1s0nl8p12 flavour physical lc 8 port 12 splittable true lanes 4 pci/0000:01:00.0/125: type eth netdev enp1s0nl8p13 flavour physical lc 8 port 13 splittable true lanes 4 pci/0000:01:00.0/126: type eth netdev enp1s0nl8p14 flavour physical lc 8 port 14 splittable true lanes 4 pci/0000:01:00.0/127: type eth netdev enp1s0nl8p15 flavour physical lc 8 port 15 splittable true lanes 4 pci/0000:01:00.0/128: type eth netdev enp1s0nl8p16 flavour physical lc 8 port 16 splittable true lanes 4 $ devlink lc set pci/0000:01:00.0 lc 8 notype Signed-off-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller --- .../networking/devlink/devlink-linecard.rst | 121 +++++++++++++++++++++ Documentation/networking/devlink/index.rst | 1 + 2 files changed, 122 insertions(+) create mode 100644 Documentation/networking/devlink/devlink-linecard.rst (limited to 'Documentation') diff --git a/Documentation/networking/devlink/devlink-linecard.rst b/Documentation/networking/devlink/devlink-linecard.rst new file mode 100644 index 000000000000..63ccd17f40ac --- /dev/null +++ b/Documentation/networking/devlink/devlink-linecard.rst @@ -0,0 +1,121 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================= +Devlink Line card +================= + +Background +========== + +The ``devlink-linecard`` mechanism is targeted for manipulation of +line cards that serve as a detachable PHY modules for modular switch +system. Following operations are provided: + + * Get a list of supported line card types. + * Provision of a slot with specific line card type. + * Get and monitor of line card state and its change. + +Line card according to the type may contain one or more gearboxes +to mux the lanes with certain speed to multiple ports with lanes +of different speed. Line card ensures N:M mapping between +the switch ASIC modules and physical front panel ports. + +Overview +======== + +Each line card devlink object is created by device driver, +according to the physical line card slots available on the device. + +Similar to splitter cable, where the device might have no way +of detection of the splitter cable geometry, the device +might not have a way to detect line card type. For that devices, +concept of provisioning is introduced. It allows the user to: + + * Provision a line card slot with certain line card type + + - Device driver would instruct the ASIC to prepare all + resources accordingly. The device driver would + create all instances, namely devlink port and netdevices + that reside on the line card, according to the line card type + * Manipulate of line card entities even without line card + being physically connected or powered-up + * Setup splitter cable on line card ports + + - As on the ordinary ports, user may provision a splitter + cable of a certain type, without the need to + be physically connected to the port + * Configure devlink ports and netdevices + +Netdevice carrier is decided as follows: + + * Line card is not inserted or powered-down + + - The carrier is always down + * Line card is inserted and powered up + + - The carrier is decided as for ordinary port netdevice + +Line card state +=============== + +The ``devlink-linecard`` mechanism supports the following line card states: + + * ``unprovisioned``: Line card is not provisioned on the slot. + * ``unprovisioning``: Line card slot is currently being unprovisioned. + * ``provisioning``: Line card slot is currently in a process of being provisioned + with a line card type. + * ``provisioning_failed``: Provisioning was not successful. + * ``provisioned``: Line card slot is provisioned with a type. + +The following diagram provides a general overview of ``devlink-linecard`` +state transitions:: + + +-------------------------+ + | | + +----------------------------------> unprovisioned | + | | | + | +--------|-------^--------+ + | | | + | | | + | +--------v-------|--------+ + | | | + | | provisioning | + | | | + | +------------|------------+ + | | + | +-----------------------------+ + | | | + | +------------v------------+ +------------v------------+ + | | | | | + +----- provisioning_failed | | provisioned | + | | | | | + | +------------^------------+ +------------|------------+ + | | | + | | | + | | +------------v------------+ + | | | | + | | | unprovisioning | + | | | | + | | +------------|------------+ + | | | + | +-----------------------------+ + | | + +-----------------------------------------------+ + + +Example usage +============= + +.. code:: shell + + $ devlink lc show [ DEV [ lc LC_INDEX ] ] + $ devlink lc set DEV lc LC_INDEX [ { type LC_TYPE | notype } ] + + # Show current line card configuration and status for all slots: + $ devlink lc + + # Set slot 8 to be provisioned with type "16x100G": + $ devlink lc set pci/0000:01:00.0 lc 8 type 16x100G + + # Set slot 8 to be unprovisioned: + $ devlink lc set pci/0000:01:00.0 lc 8 notype diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst index c17cdb079611..850715512293 100644 --- a/Documentation/networking/devlink/index.rst +++ b/Documentation/networking/devlink/index.rst @@ -39,6 +39,7 @@ general. devlink-resource devlink-reload devlink-trap + devlink-linecard Driver-specific documentation ----------------------------- -- cgit From fc9f50d5b366cd9f35bdee22fe3f8d77833cb1d8 Mon Sep 17 00:00:00 2001 From: Jiri Pirko Date: Mon, 18 Apr 2022 09:42:27 +0300 Subject: devlink: implement line card active state Allow driver to mark a line card as active. Expose this state to the userspace over devlink netlink interface with proper notifications. 'active' state means that line card was plugged in after being provisioned. Signed-off-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller --- Documentation/networking/devlink/devlink-linecard.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/devlink-linecard.rst b/Documentation/networking/devlink/devlink-linecard.rst index 63ccd17f40ac..6c0b8928bc13 100644 --- a/Documentation/networking/devlink/devlink-linecard.rst +++ b/Documentation/networking/devlink/devlink-linecard.rst @@ -66,6 +66,7 @@ The ``devlink-linecard`` mechanism supports the following line card states: with a line card type. * ``provisioning_failed``: Provisioning was not successful. * ``provisioned``: Line card slot is provisioned with a type. + * ``active``: Line card is powered-up and active. The following diagram provides a general overview of ``devlink-linecard`` state transitions:: @@ -85,11 +86,11 @@ state transitions:: | | | +-----------------------------+ | | | - | +------------v------------+ +------------v------------+ - | | | | | - +----- provisioning_failed | | provisioned | - | | | | | - | +------------^------------+ +------------|------------+ + | +------------v------------+ +------------v------------+ +-------------------------+ + | | | | ----> | + +----- provisioning_failed | | provisioned | | active | + | | | | <---- | + | +------------^------------+ +------------|------------+ +-------------------------+ | | | | | | | | +------------v------------+ -- cgit From a997157e42e3119b13c644549a3d8381a1d825d6 Mon Sep 17 00:00:00 2001 From: Luiz Angelo Daros de Luca Date: Sat, 16 Apr 2022 02:27:37 -0300 Subject: docs: net: dsa: describe issues with checksum offload DSA tags before IP header (categories 1 and 2) or after the payload (3) might introduce offload checksum issues. Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller --- Documentation/networking/dsa/dsa.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index ddc1dd039337..ed7fa76e7a40 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -193,6 +193,23 @@ protocol. If not all packets are of equal size, the tagger can implement the default behavior by specifying the correct offset incurred by each individual RX packet. Tail taggers do not cause issues to the flow dissector. +Checksum offload should work with category 1 and 2 taggers when the DSA master +driver declares NETIF_F_HW_CSUM in vlan_features and looks at csum_start and +csum_offset. For those cases, DSA will shift the checksum start and offset by +the tag size. If the DSA master driver still uses the legacy NETIF_F_IP_CSUM +or NETIF_F_IPV6_CSUM in vlan_features, the offload might only work if the +offload hardware already expects that specific tag (perhaps due to matching +vendors). DSA slaves inherit those flags from the master port, and it is up to +the driver to correctly fall back to software checksum when the IP header is not +where the hardware expects. If that check is ineffective, the packets might go +to the network without a proper checksum (the checksum field will have the +pseudo IP header sum). For category 3, when the offload hardware does not +already expect the switch tag in use, the checksum must be calculated before any +tag is inserted (i.e. inside the tagger). Otherwise, the DSA master would +include the tail tag in the (software or hardware) checksum calculation. Then, +when the tag gets stripped by the switch during transmission, it will leave an +incorrect IP checksum in place. + Due to various reasons (most common being category 1 taggers being associated with DSA-unaware masters, mangling what the master perceives as MAC DA), the tagging protocol may require the DSA master to operate in promiscuous mode, to -- cgit From 74273035c7e486fa046ee7f80fbdb9c19169ef19 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Tue, 15 Mar 2022 15:27:16 +0000 Subject: dt-bindings: pinctrl: renesas: Document RZ/G2UL pinctrl Document Renesas RZ/G2UL pinctrl bindings. RZ/G2UL GPIO block is almost identical to RZ/G2L and has lesser pins compared to RZ/G2L. Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220315152717.20045-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml index 9ccf54870aa4..52df1b146174 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml @@ -11,8 +11,8 @@ maintainers: - Lad Prabhakar description: - The Renesas SoCs of the RZ/{G2L,V2L} series feature a combined Pin and GPIO - controller. + The Renesas SoCs of the RZ/{G2L,V2L} alike series feature a combined Pin and + GPIO controller. Pin multiplexing and GPIO configuration is performed on a per-pin basis. Each port features up to 8 pins, each of them configurable for GPIO function (port mode) or in alternate function mode. @@ -23,6 +23,7 @@ properties: oneOf: - items: - enum: + - renesas,r9a07g043-pinctrl # RZ/G2UL{Type-1,Type-2} - renesas,r9a07g044-pinctrl # RZ/G2{L,LC} - items: -- cgit From 5644b66a9c63c3cadc6ba85faf5a15604e6cf29a Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Tue, 19 Apr 2022 15:18:46 +0100 Subject: Documentation: Update the recommended pattern for GPIO irqchips Update the documentation to get rid of the per-gpio_irq_chip irq_chip structure, and give examples of the new pattern. Reviewed-by: Andy Shevchenko Reviewed-by: Bartosz Golaszewski Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220419141846.598305-11-maz@kernel.org --- Documentation/driver-api/gpio/driver.rst | 175 +++++++++++++++++++++++++------ 1 file changed, 142 insertions(+), 33 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index bbc53920d4dd..a1ddefa1f55f 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -417,30 +417,66 @@ struct gpio_irq_chip inside struct gpio_chip before adding the gpio_chip. If you do this, the additional irq_chip will be set up by gpiolib at the same time as setting up the rest of the GPIO functionality. The following is a typical example of a chained cascaded interrupt handler using -the gpio_irq_chip: +the gpio_irq_chip. Note how the mask/unmask (or disable/enable) functions +call into the core gpiolib code: .. code-block:: c - /* Typical state container with dynamic irqchip */ + /* Typical state container */ struct my_gpio { struct gpio_chip gc; - struct irq_chip irq; + }; + + static void my_gpio_mask_irq(struct irq_data *d) + { + struct gpio_chip *gc = irq_desc_get_handler_data(d); + + /* + * Perform any necessary action to mask the interrupt, + * and then call into the core code to synchronise the + * state. + */ + + gpiochip_disable_irq(gc, d->hwirq); + } + + static void my_gpio_unmask_irq(struct irq_data *d) + { + struct gpio_chip *gc = irq_desc_get_handler_data(d); + + gpiochip_enable_irq(gc, d->hwirq); + + /* + * Perform any necessary action to unmask the interrupt, + * after having called into the core code to synchronise + * the state. + */ + } + + /* + * Statically populate the irqchip. Note that it is made const + * (further indicated by the IRQCHIP_IMMUTABLE flag), and that + * the GPIOCHIP_IRQ_RESOURCE_HELPER macro adds some extra + * callbacks to the structure. + */ + static const struct irq_chip my_gpio_irq_chip = { + .name = "my_gpio_irq", + .irq_ack = my_gpio_ack_irq, + .irq_mask = my_gpio_mask_irq, + .irq_unmask = my_gpio_unmask_irq, + .irq_set_type = my_gpio_set_irq_type, + .flags = IRQCHIP_IMMUTABLE, + /* Provide the gpio resource callbacks */ + GPIOCHIP_IRQ_RESOURCE_HELPERS, }; int irq; /* from platform etc */ struct my_gpio *g; struct gpio_irq_chip *girq; - /* Set up the irqchip dynamically */ - g->irq.name = "my_gpio_irq"; - g->irq.irq_ack = my_gpio_ack_irq; - g->irq.irq_mask = my_gpio_mask_irq; - g->irq.irq_unmask = my_gpio_unmask_irq; - g->irq.irq_set_type = my_gpio_set_irq_type; - /* Get a pointer to the gpio_irq_chip */ girq = &g->gc.irq; - girq->chip = &g->irq; + gpio_irq_chip_set_chip(girq, &my_gpio_irq_chip); girq->parent_handler = ftgpio_gpio_irq_handler; girq->num_parents = 1; girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents), @@ -458,23 +494,58 @@ the interrupt separately and go with it: .. code-block:: c - /* Typical state container with dynamic irqchip */ + /* Typical state container */ struct my_gpio { struct gpio_chip gc; - struct irq_chip irq; + }; + + static void my_gpio_mask_irq(struct irq_data *d) + { + struct gpio_chip *gc = irq_desc_get_handler_data(d); + + /* + * Perform any necessary action to mask the interrupt, + * and then call into the core code to synchronise the + * state. + */ + + gpiochip_disable_irq(gc, d->hwirq); + } + + static void my_gpio_unmask_irq(struct irq_data *d) + { + struct gpio_chip *gc = irq_desc_get_handler_data(d); + + gpiochip_enable_irq(gc, d->hwirq); + + /* + * Perform any necessary action to unmask the interrupt, + * after having called into the core code to synchronise + * the state. + */ + } + + /* + * Statically populate the irqchip. Note that it is made const + * (further indicated by the IRQCHIP_IMMUTABLE flag), and that + * the GPIOCHIP_IRQ_RESOURCE_HELPER macro adds some extra + * callbacks to the structure. + */ + static const struct irq_chip my_gpio_irq_chip = { + .name = "my_gpio_irq", + .irq_ack = my_gpio_ack_irq, + .irq_mask = my_gpio_mask_irq, + .irq_unmask = my_gpio_unmask_irq, + .irq_set_type = my_gpio_set_irq_type, + .flags = IRQCHIP_IMMUTABLE, + /* Provide the gpio resource callbacks */ + GPIOCHIP_IRQ_RESOURCE_HELPERS, }; int irq; /* from platform etc */ struct my_gpio *g; struct gpio_irq_chip *girq; - /* Set up the irqchip dynamically */ - g->irq.name = "my_gpio_irq"; - g->irq.irq_ack = my_gpio_ack_irq; - g->irq.irq_mask = my_gpio_mask_irq; - g->irq.irq_unmask = my_gpio_unmask_irq; - g->irq.irq_set_type = my_gpio_set_irq_type; - ret = devm_request_threaded_irq(dev, irq, NULL, irq_thread_fn, IRQF_ONESHOT, "my-chip", g); if (ret < 0) @@ -482,7 +553,7 @@ the interrupt separately and go with it: /* Get a pointer to the gpio_irq_chip */ girq = &g->gc.irq; - girq->chip = &g->irq; + gpio_irq_chip_set_chip(girq, &my_gpio_irq_chip); /* This will let us handle the parent IRQ in the driver */ girq->parent_handler = NULL; girq->num_parents = 0; @@ -500,24 +571,61 @@ In this case the typical set-up will look like this: /* Typical state container with dynamic irqchip */ struct my_gpio { struct gpio_chip gc; - struct irq_chip irq; struct fwnode_handle *fwnode; }; - int irq; /* from platform etc */ + static void my_gpio_mask_irq(struct irq_data *d) + { + struct gpio_chip *gc = irq_desc_get_handler_data(d); + + /* + * Perform any necessary action to mask the interrupt, + * and then call into the core code to synchronise the + * state. + */ + + gpiochip_disable_irq(gc, d->hwirq); + irq_mask_mask_parent(d); + } + + static void my_gpio_unmask_irq(struct irq_data *d) + { + struct gpio_chip *gc = irq_desc_get_handler_data(d); + + gpiochip_enable_irq(gc, d->hwirq); + + /* + * Perform any necessary action to unmask the interrupt, + * after having called into the core code to synchronise + * the state. + */ + + irq_mask_unmask_parent(d); + } + + /* + * Statically populate the irqchip. Note that it is made const + * (further indicated by the IRQCHIP_IMMUTABLE flag), and that + * the GPIOCHIP_IRQ_RESOURCE_HELPER macro adds some extra + * callbacks to the structure. + */ + static const struct irq_chip my_gpio_irq_chip = { + .name = "my_gpio_irq", + .irq_ack = my_gpio_ack_irq, + .irq_mask = my_gpio_mask_irq, + .irq_unmask = my_gpio_unmask_irq, + .irq_set_type = my_gpio_set_irq_type, + .flags = IRQCHIP_IMMUTABLE, + /* Provide the gpio resource callbacks */ + GPIOCHIP_IRQ_RESOURCE_HELPERS, + }; + struct my_gpio *g; struct gpio_irq_chip *girq; - /* Set up the irqchip dynamically */ - g->irq.name = "my_gpio_irq"; - g->irq.irq_ack = my_gpio_ack_irq; - g->irq.irq_mask = my_gpio_mask_irq; - g->irq.irq_unmask = my_gpio_unmask_irq; - g->irq.irq_set_type = my_gpio_set_irq_type; - /* Get a pointer to the gpio_irq_chip */ girq = &g->gc.irq; - girq->chip = &g->irq; + gpio_irq_chip_set_chip(girq, &my_gpio_irq_chip); girq->default_type = IRQ_TYPE_NONE; girq->handler = handle_bad_irq; girq->fwnode = g->fwnode; @@ -605,8 +713,9 @@ When implementing an irqchip inside a GPIO driver, these two functions should typically be called in the .irq_disable() and .irq_enable() callbacks from the irqchip. -When using the gpiolib irqchip helpers, these callbacks are automatically -assigned. +When IRQCHIP_IMMUTABLE is not advertised by the irqchip, these callbacks +are automatically assigned. This behaviour is deprecated and on its way +to be removed from the kernel. Real-Time compliance for GPIO IRQ chips -- cgit From 501f94d09b7df2d121a626590e824d6ae6e6e095 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Tue, 19 Apr 2022 16:39:57 +0200 Subject: dt-bindings: display: bridge: lt9211: Add Lontium LT9211 bridge driver Add bindings for Lontium LT9211 Single/Dual-Link DSI/LVDS or Single DPI to Single-link/Dual-Link DSI/LVDS or Single DPI bridge. This chip is highly capable at converting formats, but sadly it is also highly undocumented. Reviewed-by: Rob Herring Signed-off-by: Marek Vasut Cc: Laurent Pinchart Cc: Lucas Stach Cc: Maxime Ripard Cc: Rob Herring Cc: Robert Foss Cc: Sam Ravnborg Cc: Thomas Zimmermann Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220419143958.94873-1-marex@denx.de --- .../bindings/display/bridge/lontium,lt9211.yaml | 117 +++++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml new file mode 100644 index 000000000000..9a6e9b25d14a --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/lontium,lt9211.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Lontium LT9211 DSI/LVDS/DPI to DSI/LVDS/DPI bridge. + +maintainers: + - Marek Vasut + +description: | + The LT9211 are bridge devices which convert Single/Dual-Link DSI/LVDS + or Single DPI to Single/Dual-Link DSI/LVDS or Single DPI. + +properties: + compatible: + enum: + - lontium,lt9211 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + reset-gpios: + maxItems: 1 + description: GPIO connected to active high RESET pin. + + vccio-supply: + description: Regulator for 1.8V IO power. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + Primary MIPI DSI port-1 for MIPI input or + LVDS port-1 for LVDS input or DPI input. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Additional MIPI port-2 for MIPI input or LVDS port-2 + for LVDS input. Used in combination with primary + port-1 to drive higher resolution displays + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: + Primary MIPI DSI port-1 for MIPI output or + LVDS port-1 for LVDS output or DPI output. + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: + Additional MIPI port-2 for MIPI output or LVDS port-2 + for LVDS output. Used in combination with primary + port-1 to drive higher resolution displays. + + required: + - port@0 + - port@2 + +required: + - compatible + - reg + - vccio-supply + - ports + +additionalProperties: false + +examples: + - | + #include + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + hdmi-bridge@3b { + compatible = "lontium,lt9211"; + reg = <0x3b>; + + reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>; + interrupts-extended = <&tlmm 84 IRQ_TYPE_EDGE_FALLING>; + + vccio-supply = <<9211_1v8>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + + port@2 { + reg = <2>; + + endpoint { + remote-endpoint = <&panel_in_lvds>; + }; + }; + }; + }; + }; + +... -- cgit From 1da90b8a7bae09358569dba26e784d1f471b4aa0 Mon Sep 17 00:00:00 2001 From: "jason-jh.lin" Date: Tue, 19 Apr 2022 11:32:33 +0800 Subject: dt-bindings: arm: mediatek: mmsys: add power and gce properties Power: 1. Add description for power-domains property. GCE: 1. Add description for mboxes property. 2. Add description for mediatek,gce-client-reg property. Signed-off-by: jason-jh.lin Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: CK Hu Link: https://lore.kernel.org/r/20220419033237.23405-2-rex-bc.chen@mediatek.com Signed-off-by: Matthias Brugger --- .../bindings/arm/mediatek/mediatek,mmsys.yaml | 31 ++++++++++++++++++++++ 1 file changed, 31 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index b31d90dc9eb4..6c2c3edcd443 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -41,6 +41,30 @@ properties: reg: maxItems: 1 + power-domains: + description: + A phandle and PM domain specifier as defined by bindings + of the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + mboxes: + description: + Using mailbox to communicate with GCE, it should have this + property and list of phandle, mailbox specifiers. See + Documentation/devicetree/bindings/mailbox/mtk-gce.txt for details. + $ref: /schemas/types.yaml#/definitions/phandle-array + + mediatek,gce-client-reg: + description: + The register of client driver can be configured by gce with 4 arguments + defined in this property, such as phandle of gce, subsys id, + register offset and size. + Each subsys id is mapping to a base address of display function blocks + register which is defined in the gce header + include/dt-bindings/gce/-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + "#clock-cells": const: 1 @@ -56,9 +80,16 @@ additionalProperties: false examples: - | + #include + #include + mmsys: syscon@14000000 { compatible = "mediatek,mt8173-mmsys", "syscon"; reg = <0x14000000 0x1000>; + power-domains = <&spm MT8173_POWER_DOMAIN_MM>; #clock-cells = <1>; #reset-cells = <1>; + mboxes = <&gce 0 CMDQ_THR_PRIO_HIGHEST>, + <&gce 1 CMDQ_THR_PRIO_HIGHEST>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0 0x1000>; }; -- cgit From 81c5a41d10b968ea89d5f44fe1e5c2fc70289209 Mon Sep 17 00:00:00 2001 From: "jason-jh.lin" Date: Tue, 19 Apr 2022 11:32:34 +0800 Subject: dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding In the SoC before, such as mt8173, it has 2 pipelines binding to one mmsys with the same clock driver and the same power domain. In mt8195, there are 4 pipelines binding to 4 different mmsys, such as vdosys0, vdosys1, vppsys0 and vppsys1. Each mmsys uses different clock drivers and different power domain. Since each mmsys has its own mmio base address, they could be identified by their different address during probe time. Signed-off-by: jason-jh.lin Reviewed-by: CK Hu Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220419033237.23405-3-rex-bc.chen@mediatek.com Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index 6c2c3edcd443..6ad023eec193 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -31,6 +31,7 @@ properties: - mediatek,mt8183-mmsys - mediatek,mt8186-mmsys - mediatek,mt8192-mmsys + - mediatek,mt8195-mmsys - mediatek,mt8365-mmsys - const: syscon - items: -- cgit From 44b6b105dd2411735175af21f76ca1a2604d022e Mon Sep 17 00:00:00 2001 From: Wolfram Sang Date: Fri, 1 Apr 2022 17:37:43 +0200 Subject: dt-bindings: can: renesas,rcar-canfd: document r8a77961 support This patch adds documentation for the r8a77961 to the renesas,rcar-canfd binding. Link: https://lore.kernel.org/all/20220401153743.77871-1-wsa+renesas@sang-engineering.com Cc: devicetree@vger.kernel.org Signed-off-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Acked-by: Rob Herring Signed-off-by: Marc Kleine-Budde --- Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml index f98c53dc1894..648740270731 100644 --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml @@ -23,6 +23,7 @@ properties: - renesas,r8a774e1-canfd # RZ/G2H - renesas,r8a7795-canfd # R-Car H3 - renesas,r8a7796-canfd # R-Car M3-W + - renesas,r8a77961-canfd # R-Car M3-W+ - renesas,r8a77965-canfd # R-Car M3-N - renesas,r8a77970-canfd # R-Car V3M - renesas,r8a77980-canfd # R-Car V3H -- cgit From 6211197648502315d52b19dbbe5d9f533fe242ef Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde Date: Tue, 22 Mar 2022 09:19:13 +0100 Subject: dt-binding: can: mcp251xfd: add binding information for mcp251863 The MCP251863 device is a CAN-FD controller (MCP2518FD) with an integrated Transceiver (ATA6563). Add the microchip,mcp251863 as a new compatible to the binding. Link: https://lore.kernel.org/all/20220419072805.2840340-2-mkl@pengutronix.de Cc: devicetree@vger.kernel.org Cc: Thomas Kopp Signed-off-by: Marc Kleine-Budde --- .../bindings/net/can/microchip,mcp251xfd.yaml | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml index b3826af6bd6e..7a73057707b4 100644 --- a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml +++ b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml @@ -5,8 +5,8 @@ $id: http://devicetree.org/schemas/net/can/microchip,mcp251xfd.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: - Microchip MCP2517FD and MCP2518FD stand-alone CAN controller device tree - bindings + Microchip MCP2517FD, MCP2518FD and MCP251863 stand-alone CAN + controller device tree bindings maintainers: - Marc Kleine-Budde @@ -17,13 +17,14 @@ allOf: properties: compatible: oneOf: - - const: microchip,mcp2517fd - description: for MCP2517FD - - const: microchip,mcp2518fd - description: for MCP2518FD - - const: microchip,mcp251xfd - description: to autodetect chip variant - + - enum: + - microchip,mcp2517fd + - microchip,mcp2518fd + - microchip,mcp251xfd + - items: + - enum: + - microchip,mcp251863 + - const: microchip,mcp2518fd reg: maxItems: 1 -- cgit From fb23e43a0a9ce48031dd608f19b3298ce6a88d83 Mon Sep 17 00:00:00 2001 From: Pavel Pisa Date: Tue, 22 Mar 2022 00:32:28 +0100 Subject: dt-bindings: vendor-prefix: add prefix for the Czech Technical University in Prague. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Czech Technical University in Prague (CTU) is one of the biggest and oldest (founded 1707) technical universities in Europe. The abbreviation in Czech language is ČVUT according to official name in Czech language České vysoké učení technické v Praze The English translation The Czech Technical University in Prague The university pages in English https://www.cvut.cz/en Link: https://lore.kernel.org/all/ff3a7216114fcd83530e70b994ef0e4277ddf000.1647904780.git.pisa@cmp.felk.cvut.cz Signed-off-by: Pavel Pisa Acked-by: Rob Herring Acked-by: Pavel Machek Signed-off-by: Marc Kleine-Budde --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 01430973ecec..e12a75e10456 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -283,6 +283,8 @@ patternProperties: description: Shenzen Chuangsiqi Technology Co.,Ltd. "^ctera,.*": description: CTERA Networks Intl. + "^ctu,.*": + description: Czech Technical University in Prague "^cubietech,.*": description: Cubietech, Ltd. "^cui,.*": -- cgit From 1da9d6e35b6bf307c0d498bd1908c1ef9bdb4298 Mon Sep 17 00:00:00 2001 From: Pavel Pisa Date: Tue, 22 Mar 2022 00:32:29 +0100 Subject: dt-bindings: net: can: binding for CTU CAN FD open-source IP core. The device-tree bindings for open-source/open-hardware CAN FD IP core designed at the Czech Technical University in Prague. CTU CAN FD IP core and other CTU CAN bus related projects listing and documentation page http://canbus.pages.fel.cvut.cz/ Link: https://lore.kernel.org/all/c5a37fc470ae065b21e79caa65863539393c0d7c.1647904780.git.pisa@cmp.felk.cvut.cz Signed-off-by: Pavel Pisa Reviewed-by: Rob Herring Acked-by: Pavel Machek Signed-off-by: Marc Kleine-Budde --- .../devicetree/bindings/net/can/ctu,ctucanfd.yaml | 63 ++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml new file mode 100644 index 000000000000..fb34d971dcb3 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/ctu,ctucanfd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: CTU CAN FD Open-source IP Core Device Tree Bindings + +description: | + Open-source CAN FD IP core developed at the Czech Technical University in Prague + + The core sources and documentation on project page + [1] sources : https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core + [2] datasheet : https://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/doc/Datasheet.pdf + + Integration in Xilinx Zynq SoC based system together with + OpenCores SJA1000 compatible controllers + [3] project : https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top + Martin Jerabek dimploma thesis with integration and testing + framework description + [4] PDF : https://dspace.cvut.cz/bitstream/handle/10467/80366/F3-DP-2019-Jerabek-Martin-Jerabek-thesis-2019-canfd.pdf + +maintainers: + - Pavel Pisa + - Ondrej Ille + - Martin Jerabek + +properties: + compatible: + oneOf: + - items: + - const: ctu,ctucanfd-2 + - const: ctu,ctucanfd + - const: ctu,ctucanfd + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + description: | + phandle of reference clock (100 MHz is appropriate + for FPGA implementation on Zynq-7000 system). + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + ctu_can_fd_0: can@43c30000 { + compatible = "ctu,ctucanfd"; + interrupts = <0 30 4>; + clocks = <&clkc 15>; + reg = <0x43c30000 0x10000>; + }; -- cgit From c3a0addefbdec09affe7e9c597f1fceed4e7410a Mon Sep 17 00:00:00 2001 From: Pavel Pisa Date: Tue, 22 Mar 2022 08:21:09 +0100 Subject: docs: ctucanfd: CTU CAN FD open-source IP core documentation. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit CTU CAN FD IP core documentation based on Martin Jeřábek's diploma theses Open-source and Open-hardware CAN FD Protocol Support https://dspace.cvut.cz/handle/10467/80366 . Link: https://lore.kernel.org/all/692b965999ff6c272239df0fe1c76b68d02b134d.1647932262.git.pisa@cmp.felk.cvut.cz Signed-off-by: Pavel Pisa Signed-off-by: Martin Jerabek Signed-off-by: Ondrej Ille Signed-off-by: Marc Kleine-Budde --- .../device_drivers/can/ctu/ctucanfd-driver.rst | 639 +++++++++++++++++++++ .../device_drivers/can/ctu/fsm_txt_buffer_user.svg | 151 +++++ 2 files changed, 790 insertions(+) create mode 100644 Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst create mode 100644 Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst b/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst new file mode 100644 index 000000000000..797fb45be187 --- /dev/null +++ b/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst @@ -0,0 +1,639 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +CTU CAN FD Driver +================= + +Author: Martin Jerabek + + +About CTU CAN FD IP Core +------------------------ + +`CTU CAN FD `_ +is an open source soft core written in VHDL. +It originated in 2015 as Ondrej Ille's project +at the `Department of Measurement `_ +of `FEE `_ at `CTU `_. + +The SocketCAN driver for Xilinx Zynq SoC based MicroZed board +`Vivado integration `_ +and Intel Cyclone V 5CSEMA4U23C6 based DE0-Nano-SoC Terasic board +`QSys integration `_ +has been developed as well as support for +`PCIe integration `_ of the core. + +In the case of Zynq, the core is connected via the APB system bus, which does +not have enumeration support, and the device must be specified in Device Tree. +This kind of devices is called platform device in the kernel and is +handled by a platform device driver. + +The basic functional model of the CTU CAN FD peripheral has been +accepted into QEMU mainline. See QEMU `CAN emulation support `_ +for CAN FD buses, host connection and CTU CAN FD core emulation. The development +version of emulation support can be cloned from ctu-canfd branch of QEMU local +development `repository `_. + + +About SocketCAN +--------------- + +SocketCAN is a standard common interface for CAN devices in the Linux +kernel. As the name suggests, the bus is accessed via sockets, similarly +to common network devices. The reasoning behind this is in depth +described in `Linux SocketCAN `_. +In short, it offers a +natural way to implement and work with higher layer protocols over CAN, +in the same way as, e.g., UDP/IP over Ethernet. + +Device probe +~~~~~~~~~~~~ + +Before going into detail about the structure of a CAN bus device driver, +let's reiterate how the kernel gets to know about the device at all. +Some buses, like PCI or PCIe, support device enumeration. That is, when +the system boots, it discovers all the devices on the bus and reads +their configuration. The kernel identifies the device via its vendor ID +and device ID, and if there is a driver registered for this identifier +combination, its probe method is invoked to populate the driver's +instance for the given hardware. A similar situation goes with USB, only +it allows for device hot-plug. + +The situation is different for peripherals which are directly embedded +in the SoC and connected to an internal system bus (AXI, APB, Avalon, +and others). These buses do not support enumeration, and thus the kernel +has to learn about the devices from elsewhere. This is exactly what the +Device Tree was made for. + +Device tree +~~~~~~~~~~~ + +An entry in device tree states that a device exists in the system, how +it is reachable (on which bus it resides) and its configuration – +registers address, interrupts and so on. An example of such a device +tree is given in . + +.. code:: raw + + / { + /* ... */ + amba: amba { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + + CTU_CAN_FD_0: CTU_CAN_FD@43c30000 { + compatible = "ctu,ctucanfd"; + interrupt-parent = <&intc>; + interrupts = <0 30 4>; + clocks = <&clkc 15>; + reg = <0x43c30000 0x10000>; + }; + }; + }; + + +.. _sec:socketcan:drv: + +Driver structure +~~~~~~~~~~~~~~~~ + +The driver can be divided into two parts – platform-dependent device +discovery and set up, and platform-independent CAN network device +implementation. + +.. _sec:socketcan:platdev: + +Platform device driver +^^^^^^^^^^^^^^^^^^^^^^ + +In the case of Zynq, the core is connected via the AXI system bus, which +does not have enumeration support, and the device must be specified in +Device Tree. This kind of devices is called *platform device* in the +kernel and is handled by a *platform device driver*\ [1]_. + +A platform device driver provides the following things: + +- A *probe* function + +- A *remove* function + +- A table of *compatible* devices that the driver can handle + +The *probe* function is called exactly once when the device appears (or +the driver is loaded, whichever happens later). If there are more +devices handled by the same driver, the *probe* function is called for +each one of them. Its role is to allocate and initialize resources +required for handling the device, as well as set up low-level functions +for the platform-independent layer, e.g., *read_reg* and *write_reg*. +After that, the driver registers the device to a higher layer, in our +case as a *network device*. + +The *remove* function is called when the device disappears, or the +driver is about to be unloaded. It serves to free the resources +allocated in *probe* and to unregister the device from higher layers. + +Finally, the table of *compatible* devices states which devices the +driver can handle. The Device Tree entry ``compatible`` is matched +against the tables of all *platform drivers*. + +.. code:: c + + /* Match table for OF platform binding */ + static const struct of_device_id ctucan_of_match[] = { + { .compatible = "ctu,canfd-2", }, + { .compatible = "ctu,ctucanfd", }, + { /* end of list */ }, + }; + MODULE_DEVICE_TABLE(of, ctucan_of_match); + + static int ctucan_probe(struct platform_device *pdev); + static int ctucan_remove(struct platform_device *pdev); + + static struct platform_driver ctucanfd_driver = { + .probe = ctucan_probe, + .remove = ctucan_remove, + .driver = { + .name = DRIVER_NAME, + .of_match_table = ctucan_of_match, + }, + }; + module_platform_driver(ctucanfd_driver); + + +.. _sec:socketcan:netdev: + +Network device driver +^^^^^^^^^^^^^^^^^^^^^ + +Each network device must support at least these operations: + +- Bring the device up: ``ndo_open`` + +- Bring the device down: ``ndo_close`` + +- Submit TX frames to the device: ``ndo_start_xmit`` + +- Signal TX completion and errors to the network subsystem: ISR + +- Submit RX frames to the network subsystem: ISR and NAPI + +There are two possible event sources: the device and the network +subsystem. Device events are usually signaled via an interrupt, handled +in an Interrupt Service Routine (ISR). Handlers for the events +originating in the network subsystem are then specified in +``struct net_device_ops``. + +When the device is brought up, e.g., by calling ``ip link set can0 up``, +the driver’s function ``ndo_open`` is called. It should validate the +interface configuration and configure and enable the device. The +analogous opposite is ``ndo_close``, called when the device is being +brought down, be it explicitly or implicitly. + +When the system should transmit a frame, it does so by calling +``ndo_start_xmit``, which enqueues the frame into the device. If the +device HW queue (FIFO, mailboxes or whatever the implementation is) +becomes full, the ``ndo_start_xmit`` implementation informs the network +subsystem that it should stop the TX queue (via ``netif_stop_queue``). +It is then re-enabled later in ISR when the device has some space +available again and is able to enqueue another frame. + +All the device events are handled in ISR, namely: + +#. **TX completion**. When the device successfully finishes transmitting + a frame, the frame is echoed locally. On error, an informative error + frame [2]_ is sent to the network subsystem instead. In both cases, + the software TX queue is resumed so that more frames may be sent. + +#. **Error condition**. If something goes wrong (e.g., the device goes + bus-off or RX overrun happens), error counters are updated, and + informative error frames are enqueued to SW RX queue. + +#. **RX buffer not empty**. In this case, read the RX frames and enqueue + them to SW RX queue. Usually NAPI is used as a middle layer (see ). + +.. _sec:socketcan:napi: + +NAPI +~~~~ + +The frequency of incoming frames can be high and the overhead to invoke +the interrupt service routine for each frame can cause significant +system load. There are multiple mechanisms in the Linux kernel to deal +with this situation. They evolved over the years of Linux kernel +development and enhancements. For network devices, the current standard +is NAPI – *the New API*. It is similar to classical top-half/bottom-half +interrupt handling in that it only acknowledges the interrupt in the ISR +and signals that the rest of the processing should be done in softirq +context. On top of that, it offers the possibility to *poll* for new +frames for a while. This has a potential to avoid the costly round of +enabling interrupts, handling an incoming IRQ in ISR, re-enabling the +softirq and switching context back to softirq. + +More detailed documentation of NAPI may be found on the pages of Linux +Foundation ``_. + +Integrating the core to Xilinx Zynq +----------------------------------- + +The core interfaces a simple subset of the Avalon +(search for Intel **Avalon Interface Specifications**) +bus as it was originally used on +Alterra FPGA chips, yet Xilinx natively interfaces with AXI +(search for ARM **AMBA AXI and ACE Protocol Specification AXI3, +AXI4, and AXI4-Lite, ACE and ACE-Lite**). +The most obvious solution would be to use +an Avalon/AXI bridge or implement some simple conversion entity. +However, the core’s interface is half-duplex with no handshake +signaling, whereas AXI is full duplex with two-way signaling. Moreover, +even AXI-Lite slave interface is quite resource-intensive, and the +flexibility and speed of AXI are not required for a CAN core. + +Thus a much simpler bus was chosen – APB (Advanced Peripheral Bus) +(search for ARM **AMBA APB Protocol Specification**). +APB-AXI bridge is directly available in +Xilinx Vivado, and the interface adaptor entity is just a few simple +combinatorial assignments. + +Finally, to be able to include the core in a block diagram as a custom +IP, the core, together with the APB interface, has been packaged as a +Vivado component. + +CTU CAN FD Driver design +------------------------ + +The general structure of a CAN device driver has already been examined +in . The next paragraphs provide a more detailed description of the CTU +CAN FD core driver in particular. + +Low-level driver +~~~~~~~~~~~~~~~~ + +The core is not intended to be used solely with SocketCAN, and thus it +is desirable to have an OS-independent low-level driver. This low-level +driver can then be used in implementations of OS driver or directly +either on bare metal or in a user-space application. Another advantage +is that if the hardware slightly changes, only the low-level driver +needs to be modified. + +The code [3]_ is in part automatically generated and in part written +manually by the core author, with contributions of the thesis’ author. +The low-level driver supports operations such as: set bit timing, set +controller mode, enable/disable, read RX frame, write TX frame, and so +on. + +Configuring bit timing +~~~~~~~~~~~~~~~~~~~~~~ + +On CAN, each bit is divided into four segments: SYNC, PROP, PHASE1, and +PHASE2. Their duration is expressed in multiples of a Time Quantum +(details in `CAN Specification, Version 2.0 `_, chapter 8). +When configuring +bitrate, the durations of all the segments (and time quantum) must be +computed from the bitrate and Sample Point. This is performed +independently for both the Nominal bitrate and Data bitrate for CAN FD. + +SocketCAN is fairly flexible and offers either highly customized +configuration by setting all the segment durations manually, or a +convenient configuration by setting just the bitrate and sample point +(and even that is chosen automatically per Bosch recommendation if not +specified). However, each CAN controller may have different base clock +frequency and different width of segment duration registers. The +algorithm thus needs the minimum and maximum values for the durations +(and clock prescaler) and tries to optimize the numbers to fit both the +constraints and the requested parameters. + +.. code:: c + + struct can_bittiming_const { + char name[16]; /* Name of the CAN controller hardware */ + __u32 tseg1_min; /* Time segment 1 = prop_seg + phase_seg1 */ + __u32 tseg1_max; + __u32 tseg2_min; /* Time segment 2 = phase_seg2 */ + __u32 tseg2_max; + __u32 sjw_max; /* Synchronisation jump width */ + __u32 brp_min; /* Bit-rate prescaler */ + __u32 brp_max; + __u32 brp_inc; + }; + + +[lst:can_bittiming_const] + +A curious reader will notice that the durations of the segments PROP_SEG +and PHASE_SEG1 are not determined separately but rather combined and +then, by default, the resulting TSEG1 is evenly divided between PROP_SEG +and PHASE_SEG1. In practice, this has virtually no consequences as the +sample point is between PHASE_SEG1 and PHASE_SEG2. In CTU CAN FD, +however, the duration registers ``PROP`` and ``PH1`` have different +widths (6 and 7 bits, respectively), so the auto-computed values might +overflow the shorter register and must thus be redistributed among the +two [4]_. + +Handling RX +~~~~~~~~~~~ + +Frame reception is handled in NAPI queue, which is enabled from ISR when +the RXNE (RX FIFO Not Empty) bit is set. Frames are read one by one +until either no frame is left in the RX FIFO or the maximum work quota +has been reached for the NAPI poll run (see ). Each frame is then passed +to the network interface RX queue. + +An incoming frame may be either a CAN 2.0 frame or a CAN FD frame. The +way to distinguish between these two in the kernel is to allocate either +``struct can_frame`` or ``struct canfd_frame``, the two having different +sizes. In the controller, the information about the frame type is stored +in the first word of RX FIFO. + +This brings us a chicken-egg problem: we want to allocate the ``skb`` +for the frame, and only if it succeeds, fetch the frame from FIFO; +otherwise keep it there for later. But to be able to allocate the +correct ``skb``, we have to fetch the first work of FIFO. There are +several possible solutions: + +#. Read the word, then allocate. If it fails, discard the rest of the + frame. When the system is low on memory, the situation is bad anyway. + +#. Always allocate ``skb`` big enough for an FD frame beforehand. Then + tweak the ``skb`` internals to look like it has been allocated for + the smaller CAN 2.0 frame. + +#. Add option to peek into the FIFO instead of consuming the word. + +#. If the allocation fails, store the read word into driver’s data. On + the next try, use the stored word instead of reading it again. + +Option 1 is simple enough, but not very satisfying if we could do +better. Option 2 is not acceptable, as it would require modifying the +private state of an integral kernel structure. The slightly higher +memory consumption is just a virtual cherry on top of the “cake”. Option +3 requires non-trivial HW changes and is not ideal from the HW point of +view. + +Option 4 seems like a good compromise, with its disadvantage being that +a partial frame may stay in the FIFO for a prolonged time. Nonetheless, +there may be just one owner of the RX FIFO, and thus no one else should +see the partial frame (disregarding some exotic debugging scenarios). +Basides, the driver resets the core on its initialization, so the +partial frame cannot be “adopted” either. In the end, option 4 was +selected [5]_. + +.. _subsec:ctucanfd:rxtimestamp: + +Timestamping RX frames +^^^^^^^^^^^^^^^^^^^^^^ + +The CTU CAN FD core reports the exact timestamp when the frame has been +received. The timestamp is by default captured at the sample point of +the last bit of EOF but is configurable to be captured at the SOF bit. +The timestamp source is external to the core and may be up to 64 bits +wide. At the time of writing, passing the timestamp from kernel to +userspace is not yet implemented, but is planned in the future. + +Handling TX +~~~~~~~~~~~ + +The CTU CAN FD core has 4 independent TX buffers, each with its own +state and priority. When the core wants to transmit, a TX buffer in +Ready state with the highest priority is selected. + +The priorities are 3bit numbers in register TX_PRIORITY +(nibble-aligned). This should be flexible enough for most use cases. +SocketCAN, however, supports only one FIFO queue for outgoing +frames [6]_. The buffer priorities may be used to simulate the FIFO +behavior by assigning each buffer a distinct priority and *rotating* the +priorities after a frame transmission is completed. + +In addition to priority rotation, the SW must maintain head and tail +pointers into the FIFO formed by the TX buffers to be able to determine +which buffer should be used for next frame (``txb_head``) and which +should be the first completed one (``txb_tail``). The actual buffer +indices are (obviously) modulo 4 (number of TX buffers), but the +pointers must be at least one bit wider to be able to distinguish +between FIFO full and FIFO empty – in this situation, +:math:`txb\_head \equiv txb\_tail\ (\textrm{mod}\ 4)`. An example of how +the FIFO is maintained, together with priority rotation, is depicted in + +| + ++------+---+---+---+---+ +| TXB# | 0 | 1 | 2 | 3 | ++======+===+===+===+===+ +| Seq | A | B | C | | ++------+---+---+---+---+ +| Prio | 7 | 6 | 5 | 4 | ++------+---+---+---+---+ +| | | T | | H | ++------+---+---+---+---+ + +| + ++------+---+---+---+---+ +| TXB# | 0 | 1 | 2 | 3 | ++======+===+===+===+===+ +| Seq | | B | C | | ++------+---+---+---+---+ +| Prio | 4 | 7 | 6 | 5 | ++------+---+---+---+---+ +| | | T | | H | ++------+---+---+---+---+ + +| + ++------+---+---+---+---+----+ +| TXB# | 0 | 1 | 2 | 3 | 0’ | ++======+===+===+===+===+====+ +| Seq | E | B | C | D | | ++------+---+---+---+---+----+ +| Prio | 4 | 7 | 6 | 5 | | ++------+---+---+---+---+----+ +| | | T | | | H | ++------+---+---+---+---+----+ + +| + +.. figure:: fsm_txt_buffer_user.svg + + TX Buffer states with possible transitions + +.. _subsec:ctucanfd:txtimestamp: + +Timestamping TX frames +^^^^^^^^^^^^^^^^^^^^^^ + +When submitting a frame to a TX buffer, one may specify the timestamp at +which the frame should be transmitted. The frame transmission may start +later, but not sooner. Note that the timestamp does not participate in +buffer prioritization – that is decided solely by the mechanism +described above. + +Support for time-based packet transmission was recently merged to Linux +v4.19 `Time-based packet transmission `_, +but it remains yet to be researched +whether this functionality will be practical for CAN. + +Also similarly to retrieving the timestamp of RX frames, the core +supports retrieving the timestamp of TX frames – that is the time when +the frame was successfully delivered. The particulars are very similar +to timestamping RX frames and are described in . + +Handling RX buffer overrun +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When a received frame does no more fit into the hardware RX FIFO in its +entirety, RX FIFO overrun flag (STATUS[DOR]) is set and Data Overrun +Interrupt (DOI) is triggered. When servicing the interrupt, care must be +taken first to clear the DOR flag (via COMMAND[CDO]) and after that +clear the DOI interrupt flag. Otherwise, the interrupt would be +immediately [7]_ rearmed. + +**Note**: During development, it was discussed whether the internal HW +pipelining cannot disrupt this clear sequence and whether an additional +dummy cycle is necessary between clearing the flag and the interrupt. On +the Avalon interface, it indeed proved to be the case, but APB being +safe because it uses 2-cycle transactions. Essentially, the DOR flag +would be cleared, but DOI register’s Preset input would still be high +the cycle when the DOI clear request would also be applied (by setting +the register’s Reset input high). As Set had higher priority than Reset, +the DOI flag would not be reset. This has been already fixed by swapping +the Set/Reset priority (see issue #187). + +Reporting Error Passive and Bus Off conditions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It may be desirable to report when the node reaches *Error Passive*, +*Error Warning*, and *Bus Off* conditions. The driver is notified about +error state change by an interrupt (EPI, EWLI), and then proceeds to +determine the core’s error state by reading its error counters. + +There is, however, a slight race condition here – there is a delay +between the time when the state transition occurs (and the interrupt is +triggered) and when the error counters are read. When EPI is received, +the node may be either *Error Passive* or *Bus Off*. If the node goes +*Bus Off*, it obviously remains in the state until it is reset. +Otherwise, the node is *or was* *Error Passive*. However, it may happen +that the read state is *Error Warning* or even *Error Active*. It may be +unclear whether and what exactly to report in that case, but I +personally entertain the idea that the past error condition should still +be reported. Similarly, when EWLI is received but the state is later +detected to be *Error Passive*, *Error Passive* should be reported. + + +CTU CAN FD Driver Sources Reference +----------------------------------- + +.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd.h + :internal: + +.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd_base.c + :internal: + +.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd_pci.c + :internal: + +.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd_platform.c + :internal: + +CTU CAN FD IP Core and Driver Development Acknowledgment +--------------------------------------------------------- + +* Odrej Ille + + * started the project as student at Department of Measurement, FEE, CTU + * invested great amount of personal time and enthusiasm to the project over years + * worked on more funded tasks + +* `Department of Measurement `_, + `Faculty of Electrical Engineering `_, + `Czech Technical University `_ + + * is the main investor into the project over many years + * uses project in their CAN/CAN FD diagnostics framework for `Skoda Auto `_ + +* `Digiteq Automotive `_ + + * funding of the project CAN FD Open Cores Support Linux Kernel Based Systems + * negotiated and paid CTU to allow public access to the project + * provided additional funding of the work + +* `Department of Control Engineering `_, + `Faculty of Electrical Engineering `_, + `Czech Technical University `_ + + * solving the project CAN FD Open Cores Support Linux Kernel Based Systems + * providing GitLab management + * virtual servers and computational power for continuous integration + * providing hardware for HIL continuous integration tests + +* `PiKRON Ltd. `_ + + * minor funding to initiate preparation of the project open-sourcing + +* Petr Porazil + + * design of PCIe transceiver addon board and assembly of boards + * design and assembly of MZ_APO baseboard for MicroZed/Zynq based system + +* Martin Jerabek + + * Linux driver development + * continuous integration platform architect and GHDL updates + * theses `Open-source and Open-hardware CAN FD Protocol Support `_ + +* Jiri Novak + + * project initiation, management and use at Department of Measurement, FEE, CTU + +* Pavel Pisa + + * initiate open-sourcing, project coordination, management at Department of Control Engineering, FEE, CTU + +* Jaroslav Beran + + * system integration for Intel SoC, core and driver testing and updates + +* Carsten Emde (`OSADL `_) + + * provided OSADL expertise to discuss IP core licensing + * pointed to possible deadlock for LGPL and CAN bus possible patent case which lead to relicense IP core design to BSD like license + +* Reiner Zitzmann and Holger Zeltwanger (`CAN in Automation `_) + + * provided suggestions and help to inform community about the project and invited us to events focused on CAN bus future development directions + +* Jan Charvat + + * implemented CTU CAN FD functional model for QEMU which has been integrated into QEMU mainline (`docs/system/devices/can.rst `_) + * Bachelor theses Model of CAN FD Communication Controller for QEMU Emulator + +Notes +----- + + +.. [1] + Other buses have their own specific driver interface to set up the + device. + +.. [2] + Not to be mistaken with CAN Error Frame. This is a ``can_frame`` with + ``CAN_ERR_FLAG`` set and some error info in its ``data`` field. + +.. [3] + Available in CTU CAN FD repository + ``_ + +.. [4] + As is done in the low-level driver functions + ``ctucan_hw_set_nom_bittiming`` and + ``ctucan_hw_set_data_bittiming``. + +.. [5] + At the time of writing this thesis, option 1 is still being used and + the modification is queued in gitlab issue #222 + +.. [6] + Strictly speaking, multiple CAN TX queues are supported since v4.19 + `can: enable multi-queue for SocketCAN devices `_ but no mainline driver is using + them yet. + +.. [7] + Or rather in the next clock cycle diff --git a/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg b/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg new file mode 100644 index 000000000000..b371650788f4 --- /dev/null +++ b/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg @@ -0,0 +1,151 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + Accessiblefor SW + Inaccessiblefor SW + + Ready + TX OK + Aborted + TX failed + TX inprogress + Abort inprogress + Empty + + + + + + + + + + + + + + + + + + + + + + + Setabort + Transmissionunsuccesfull + + Transmissionstarts + Transmissionsuccesfull + Transmissionsborted + + + Retransmitlimit reached ornode went bus off + Transmission result + Legend: + + + SW command + Set ready + Set ready + Set empty + Set abort + + + -- cgit From f2701e0ffd2195a2610d14d289785513100d5dfd Mon Sep 17 00:00:00 2001 From: Drew Fustini Date: Thu, 14 Apr 2022 12:27:23 -0700 Subject: dt-bindings: wkup-m3-ipc: Add ti,set-io-isolation property Add documentation for the ti,set-io-isolation DT property on the wkup_m3_ipc node which tells the wkup_m3_ipc driver to use the wkup_m3 to enable IO Isolation during low power mode transitions on am43xx platforms. Signed-off-by: Dave Gerlach [dfustini: convert to YAML, make DTS example that passes check] Signed-off-by: Drew Fustini Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220414192722.2978837-2-dfustini@baylibre.com --- .../devicetree/bindings/soc/ti/wkup-m3-ipc.yaml | 79 ++++++++++++++++++++-- 1 file changed, 74 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml b/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml index 7f4a75c5fcaa..88d690de050c 100644 --- a/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml +++ b/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml @@ -24,14 +24,22 @@ description: |+ A wkup_m3_ipc device node is used to represent the IPC registers within an SoC. - Support for VTT Toggle - ================================== + Support for VTT Toggle with GPIO pin + ==================================== On some boards like the AM335x EVM-SK and the AM437x GP EVM, a GPIO pin is connected to the enable pin on the DDR VTT regulator. This allows the regulator to be disabled upon suspend and enabled upon resume. Please note that the GPIO pin must be part of the GPIO0 module as only this GPIO module is in the wakeup power domain. + Support for IO Isolation + ======================== + On AM437x SoCs, certain pins can be forced into an alternate state when IO + isolation is activated. Those pins have pad control registers prefixed by + 'CTRL_CONF_' that contain DS0 (e.g. deep sleep) configuration bits that can + override the pin's existing bias (pull-up/pull-down) and value (high/low) when + IO isolation is active. + properties: compatible: enum: @@ -63,6 +71,25 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 description: GPIO pin connected to enable pin on VTT regulator + ti,set-io-isolation: + type: boolean + description: + If this property is present, then the wkup_m3_ipc driver will instruct + the CM3 firmware to activate IO isolation when suspending to deep sleep. + This can be leveraged by a board design to put other devices on the board + into a low power state. + +allOf: + - if: + properties: + compatible: + not: + contains: + const: ti,am4372-wkup-m3-ipc + then: + properties: + ti,set-io-isolation: false + required: - compatible - reg @@ -74,21 +101,63 @@ additionalProperties: false examples: - | + /* Example for AM335x SoC */ soc { #address-cells = <1>; #size-cells = <1>; - mailbox: mailbox { + am335x_mailbox: mailbox { #mbox-cells = <1>; }; - wkup_m3_ipc: wkup_m3_ipc@1324 { + wkup_m3_ipc@1324 { compatible = "ti,am3352-wkup-m3-ipc"; reg = <0x1324 0x24>; interrupts = <78>; ti,rproc = <&wkup_m3>; - mboxes = <&mailbox &mbox_wkupm3>; + mboxes = <&am335x_mailbox &mbox_wkupm3>; ti,vtt-gpio-pin = <7>; }; }; + + - | + /* + * Example for AM473x SoC: + * On the AM437x-GP-EVM board, gpio5_7 is wired to enable pin of the DDR VTT + * regulator. The 'ddr_vtt_toggle_default' pinmux node configures gpio5_7 + * for pull-up during normal system operation. However, the DS0 (deep sleep) + * state of the pin is configured for pull-down and thus the VTT regulator + * will be disabled to save power when IO isolation is active. Note that + * this method is an alternative to using the 'ti,vtt-gpio-pin' property. + */ + #include + soc { + #address-cells = <1>; + #size-cells = <1>; + + am437x_mailbox: mailbox { + #mbox-cells = <1>; + }; + + am43xx_pinmux { + pinctrl-names = "default"; + pinctrl-0 = <&ddr3_vtt_toggle_default>; + + ddr3_vtt_toggle_default: ddr_vtt_toggle_default { + pinctrl-single,pins = < + 0x25C (DS0_PULL_UP_DOWN_EN | PIN_OUTPUT_PULLUP | DS0_FORCE_OFF_MODE | MUX_MODE7) + >; + }; + }; + + wkup_m3_ipc@1324 { + compatible = "ti,am4372-wkup-m3-ipc"; + reg = <0x1324 0x24>; + interrupts = <78>; + ti,rproc = <&wkup_m3>; + mboxes = <&am437x_mailbox &mbox_wkupm3>; + ti,set-io-isolation; + }; + }; + ... -- cgit From e930244918092d44b60a7b538cf60d737010ceef Mon Sep 17 00:00:00 2001 From: Bryan O'Donoghue Date: Tue, 19 Apr 2022 00:18:57 +0100 Subject: dt-bindings: soc: qcom: smd-rpm: Fix missing MSM8936 compatible Add compatible msm8936. msm8936 covers both msm8936 and msm8939. The relevant driver already has the compat string but, we haven't documented it. Fixes: d6e52482f5ab ("drivers: soc: Add MSM8936 SMD RPM compatible") Signed-off-by: Bryan O'Donoghue Acked-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220418231857.3061053-1-bryan.odonoghue@linaro.org --- Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index b32457c2fc0b..3361218e278f 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -34,6 +34,7 @@ properties: - qcom,rpm-ipq6018 - qcom,rpm-msm8226 - qcom,rpm-msm8916 + - qcom,rpm-msm8936 - qcom,rpm-msm8953 - qcom,rpm-msm8974 - qcom,rpm-msm8976 -- cgit From 0b9fe9b7792f31674fbc8eb165c3b22a32d0a434 Mon Sep 17 00:00:00 2001 From: Michael Srba Date: Mon, 11 Apr 2022 09:21:54 +0200 Subject: dt-bindings: bus: add device tree bindings for qcom,ssc-block-bus Adds bindings for the AHB bus which exposes the SSC block in the global address space. This bus (and the SSC block itself) is present on certain qcom SoCs. In typical configuration, this bus (as some of the clocks and registers that we need to manipulate) is not accessible to the OS, and the resources on this bus are indirectly accessed by communicating with a hexagon CPU core residing in the SSC block. In this configuration, the hypervisor is the one performing the bus initialization for the purposes of bringing the haxagon CPU core out of reset. However, it is possible to change the configuration, in which case this binding serves to allow the OS to initialize the bus. Signed-off-by: Michael Srba Reviewed-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220411072156.24451-4-michael.srba@seznam.cz --- .../bindings/bus/qcom,ssc-block-bus.yaml | 147 +++++++++++++++++++++ 1 file changed, 147 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml b/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml new file mode 100644 index 000000000000..5b9705079015 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml @@ -0,0 +1,147 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/qcom,ssc-block-bus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: The AHB Bus Providing a Global View of the SSC Block on (some) qcom SoCs + +maintainers: + - Michael Srba + +description: | + This binding describes the dependencies (clocks, resets, power domains) which + need to be turned on in a sequence before communication over the AHB bus + becomes possible. + + Additionally, the reg property is used to pass to the driver the location of + two sadly undocumented registers which need to be poked as part of the sequence. + + The SSC (Snapdragon Sensor Core) block contains a gpio controller, i2c/spi/uart + controllers, a hexagon core, and a clock controller which provides clocks for + the above. + +properties: + compatible: + items: + - const: qcom,msm8998-ssc-block-bus + - const: qcom,ssc-block-bus + + reg: + description: | + Shall contain the addresses of the SSCAON_CONFIG0 and SSCAON_CONFIG1 + registers + minItems: 2 + maxItems: 2 + + reg-names: + items: + - const: mpm_sscaon_config0 + - const: mpm_sscaon_config1 + + '#address-cells': + enum: [ 1, 2 ] + + '#size-cells': + enum: [ 1, 2 ] + + ranges: true + + clocks: + minItems: 6 + maxItems: 6 + + clock-names: + items: + - const: xo + - const: aggre2 + - const: gcc_im_sleep + - const: aggre2_north + - const: ssc_xo + - const: ssc_ahbs + + power-domains: + description: Power domain phandles for the ssc_cx and ssc_mx power domains + minItems: 2 + maxItems: 2 + + power-domain-names: + items: + - const: ssc_cx + - const: ssc_mx + + resets: + description: | + Reset phandles for the ssc_reset and ssc_bcr resets (note: ssc_bcr is the + branch control register associated with the ssc_xo and ssc_ahbs clocks) + minItems: 2 + maxItems: 2 + + reset-names: + items: + - const: ssc_reset + - const: ssc_bcr + + qcom,halt-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: describes how to locate the ssc AXI halt register + items: + - items: + - description: Phandle reference to a syscon representing TCSR + - description: offset for the ssc AXI halt register + +required: + - compatible + - reg + - reg-names + - '#address-cells' + - '#size-cells' + - ranges + - clocks + - clock-names + - power-domains + - power-domain-names + - resets + - reset-names + - qcom,halt-regs + +additionalProperties: + type: object + +examples: + - | + #include + #include + #include + + soc { + #address-cells = <1>; + #size-cells = <1>; + + // devices under this node are physically located in the SSC block, connected to an ssc-internal bus; + ssc_ahb_slave: bus@10ac008 { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + compatible = "qcom,msm8998-ssc-block-bus", "qcom,ssc-block-bus"; + reg = <0x10ac008 0x4>, <0x10ac010 0x4>; + reg-names = "mpm_sscaon_config0", "mpm_sscaon_config1"; + + clocks = <&xo>, + <&rpmcc RPM_SMD_AGGR2_NOC_CLK>, + <&gcc GCC_IM_SLEEP>, + <&gcc AGGRE2_SNOC_NORTH_AXI>, + <&gcc SSC_XO>, + <&gcc SSC_CNOC_AHBS_CLK>; + clock-names = "xo", "aggre2", "gcc_im_sleep", "aggre2_north", "ssc_xo", "ssc_ahbs"; + + resets = <&gcc GCC_SSC_RESET>, <&gcc GCC_SSC_BCR>; + reset-names = "ssc_reset", "ssc_bcr"; + + power-domains = <&rpmpd MSM8998_SSCCX>, <&rpmpd MSM8998_SSCMX>; + power-domain-names = "ssc_cx", "ssc_mx"; + + qcom,halt-regs = <&tcsr_mutex_regs 0x26000>; + }; + }; -- cgit From 29d699a4c006940cf06f647ed02cc083234e8e33 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Thu, 7 Apr 2022 20:56:16 +0200 Subject: dt-bindings: display: bridge: icn6211: Document DSI data-lanes property It is necessary to specify the number of connected/used DSI data lanes when using the DSI input port of this bridge. Document the 'data-lanes' property of the DSI input port. Signed-off-by: Marek Vasut Cc: Jagan Teki Cc: Laurent Pinchart Cc: Maxime Ripard Cc: Rob Herring Cc: Robert Foss Cc: Sam Ravnborg Cc: Thomas Zimmermann Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220407185617.179573-1-marex@denx.de --- .../bindings/display/bridge/chipone,icn6211.yaml | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml index 7257fd0ae4da..4f0b7c71313c 100644 --- a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml +++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml @@ -41,10 +41,26 @@ properties: properties: port@0: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: Video port for MIPI DSI input + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + description: array of physical DSI data lane indexes. + minItems: 1 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + port@1: $ref: /schemas/graph.yaml#/properties/port description: -- cgit From 6954e5baa055c91bc878695ceca57cbf0787d277 Mon Sep 17 00:00:00 2001 From: Tales Lelo da Aparecida Date: Fri, 15 Apr 2022 16:50:26 -0300 Subject: Documentation/gpu: Add entries to amdgpu glossary MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add missing acronyms to the amdgppu glossary. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1939 Acked-by: Christian König Signed-off-by: Tales Lelo da Aparecida Signed-off-by: Alex Deucher --- Documentation/gpu/amdgpu/amdgpu-glossary.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/amdgpu/amdgpu-glossary.rst b/Documentation/gpu/amdgpu/amdgpu-glossary.rst index 859dcec6c6f9..db924d37f93e 100644 --- a/Documentation/gpu/amdgpu/amdgpu-glossary.rst +++ b/Documentation/gpu/amdgpu/amdgpu-glossary.rst @@ -8,12 +8,19 @@ we have a dedicated glossary for Display Core at .. glossary:: + active_cu_number + The number of CUs that are active on the system. The number of active + CUs may be less than SE * SH * CU depending on the board configuration. + CP Command Processor CPLIB Content Protection Library + CU + Compute Unit + DFS Digital Frequency Synthesizer @@ -74,6 +81,12 @@ we have a dedicated glossary for Display Core at SDMA System DMA + SE + Shader Engine + + SH + SHader array + SMU System Management Unit -- cgit From 38d46b0f41ec57c734f1a647055644c2131c3d8f Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 11 Apr 2022 10:59:35 +0200 Subject: dt-bindings: soc: qcom,rpmh-rsc: convert to dtschema Convert the Qualcomm RPMH RSC bindings to DT Schema. Changes against original bindings: 1. Add qcom,tcs-offset as a property instead of one of reg (not used that way). 2. Add limits to interrupts. 3. Add child nodes (bcm-voter, clock-controller, power-controller). 4. Extend the example with more complex one. The device description and DTS examples were copied from existing sources, so keep the license as GPL-2.0-only. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220411085935.130072-4-krzysztof.kozlowski@linaro.org --- .../bindings/interconnect/qcom,bcm-voter.yaml | 8 +- .../bindings/soc/qcom/qcom,rpmh-rsc.yaml | 272 +++++++++++++++++++++ .../devicetree/bindings/soc/qcom/rpmh-rsc.txt | 137 ----------- 3 files changed, 276 insertions(+), 141 deletions(-) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml delete mode 100644 Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml b/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml index e23df4836c6f..eec987640b37 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml @@ -45,20 +45,20 @@ additionalProperties: false examples: # Example 1: apps bcm_voter on SDM845 SoC should be defined inside &apps_rsc node - # as defined in Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt + # as defined in Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml - | - apps_bcm_voter: bcm_voter { + apps_bcm_voter: bcm-voter { compatible = "qcom,bcm-voter"; }; # Example 2: disp bcm_voter on SDM845 should be defined inside &disp_rsc node - # as defined in Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt + # as defined in Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml - | #include - disp_bcm_voter: bcm_voter { + disp_bcm_voter: bcm-voter { compatible = "qcom,bcm-voter"; qcom,tcs-wait = ; }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml new file mode 100644 index 000000000000..f5ecf4a8c377 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml @@ -0,0 +1,272 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/qcom/qcom,rpmh-rsc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm RPMH RSC + +maintainers: + - Bjorn Andersson + +description: | + Resource Power Manager Hardened (RPMH) is the mechanism for communicating + with the hardened resource accelerators on Qualcomm SoCs. Requests to the + resources can be written to the Trigger Command Set (TCS) registers and + using a (addr, val) pair and triggered. Messages in the TCS are then sent in + sequence over an internal bus. + + The hardware block (Direct Resource Voter or DRV) is a part of the h/w entity + (Resource State Coordinator a.k.a RSC) that can handle multiple sleep and + active/wake resource requests. Multiple such DRVs can exist in a SoC and can + be written to from Linux. The structure of each DRV follows the same template + with a few variations that are captured by the properties here. + + A TCS may be triggered from Linux or triggered by the F/W after all the CPUs + have powered off to facilitate idle power saving. TCS could be classified as:: + ACTIVE - Triggered by Linux + SLEEP - Triggered by F/W + WAKE - Triggered by F/W + CONTROL - Triggered by F/W + See also:: + + The order in which they are described in the DT, should match the hardware + configuration. + + Requests can be made for the state of a resource, when the subsystem is + active or idle. When all subsystems like Modem, GPU, CPU are idle, the + resource state will be an aggregate of the sleep votes from each of those + subsystems. Clients may request a sleep value for their shared resources in + addition to the active mode requests. + + Drivers that want to use the RSC to communicate with RPMH must specify their + bindings as child nodes of the RSC controllers they wish to communicate with. + +properties: + compatible: + const: qcom,rpmh-rsc + + interrupts: + minItems: 1 + maxItems: 4 + description: + The interrupt that trips when a message complete/response is received for + this DRV from the accelerators. + Number of interrupts must match number of DRV blocks. + + label: + description: + Name for the RSC. The name would be used in trace logs. + + qcom,drv-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The ID of the DRV in the RSC block that will be used by this controller. + + qcom,tcs-config: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + - items: + - description: TCS type + enum: [ 0, 1, 2, 3 ] + - description: Number of TCS + - items: + - description: TCS type + enum: [ 0, 1, 2, 3 ] + - description: Number of TCS + - items: + - description: TCS type + enum: [ 0, 1, 2, 3] + - description: Numbe r of TCS + - items: + - description: TCS type + enum: [ 0, 1, 2, 3 ] + - description: Number of TCS + description: | + The tuple defining the configuration of TCS. Must have two cells which + describe each TCS type. The order of the TCS must match the hardware + configuration. + Cell 1 (TCS Type):: TCS types to be specified:: + - ACTIVE_TCS + - SLEEP_TCS + - WAKE_TCS + - CONTROL_TCS + Cell 2 (Number of TCS):: + + qcom,tcs-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The offset of the TCS blocks. + + reg: + minItems: 1 + maxItems: 4 + + reg-names: + minItems: 1 + items: + - const: drv-0 + - const: drv-1 + - const: drv-2 + - const: drv-3 + + bcm-voter: + $ref: /schemas/interconnect/qcom,bcm-voter.yaml# + + clock-controller: + $ref: /schemas/clock/qcom,rpmhcc.yaml# + + power-controller: + $ref: /schemas/power/qcom,rpmpd.yaml# + +patternProperties: + '-regulators$': + $ref: /schemas/regulator/qcom,rpmh-regulator.yaml# + +required: + - compatible + - interrupts + - qcom,drv-id + - qcom,tcs-config + - qcom,tcs-offset + - reg + - reg-names + +additionalProperties: false + +examples: + - | + // For a TCS whose RSC base address is 0x179C0000 and is at a DRV id of + // 2, the register offsets for DRV2 start at 0D00, the register + // calculations are like this:: + // DRV0: 0x179C0000 + // DRV2: 0x179C0000 + 0x10000 = 0x179D0000 + // DRV2: 0x179C0000 + 0x10000 * 2 = 0x179E0000 + // TCS-OFFSET: 0xD00 + #include + #include + + rsc@179c0000 { + compatible = "qcom,rpmh-rsc"; + reg = <0x179c0000 0x10000>, + <0x179d0000 0x10000>, + <0x179e0000 0x10000>; + reg-names = "drv-0", "drv-1", "drv-2"; + interrupts = , + , + ; + label = "apps_rsc"; + qcom,tcs-offset = <0xd00>; + qcom,drv-id = <2>; + qcom,tcs-config = , + , + , + ; + }; + + - | + // For a TCS whose RSC base address is 0xAF20000 and is at DRV id of 0, the + // register offsets for DRV0 start at 01C00, the register calculations are + // like this:: + // DRV0: 0xAF20000 + // TCS-OFFSET: 0x1C00 + #include + #include + + rsc@af20000 { + compatible = "qcom,rpmh-rsc"; + reg = <0xaf20000 0x10000>; + reg-names = "drv-0"; + interrupts = ; + label = "disp_rsc"; + qcom,tcs-offset = <0x1c00>; + qcom,drv-id = <0>; + qcom,tcs-config = , + , + , + ; + }; + + - | + #include + #include + #include + + rsc@18200000 { + compatible = "qcom,rpmh-rsc"; + reg = <0x18200000 0x10000>, + <0x18210000 0x10000>, + <0x18220000 0x10000>; + reg-names = "drv-0", "drv-1", "drv-2"; + interrupts = , + , + ; + label = "apps_rsc"; + qcom,tcs-offset = <0xd00>; + qcom,drv-id = <2>; + qcom,tcs-config = , + , + , + ; + + clock-controller { + compatible = "qcom,sm8350-rpmh-clk"; + #clock-cells = <1>; + clock-names = "xo"; + clocks = <&xo_board>; + }; + + power-controller { + compatible = "qcom,sm8350-rpmhpd"; + #power-domain-cells = <1>; + operating-points-v2 = <&rpmhpd_opp_table>; + + rpmhpd_opp_table: opp-table { + compatible = "operating-points-v2"; + + rpmhpd_opp_ret: opp1 { + opp-level = ; + }; + + rpmhpd_opp_min_svs: opp2 { + opp-level = ; + }; + + rpmhpd_opp_low_svs: opp3 { + opp-level = ; + }; + + rpmhpd_opp_svs: opp4 { + opp-level = ; + }; + + rpmhpd_opp_svs_l1: opp5 { + opp-level = ; + }; + + rpmhpd_opp_nom: opp6 { + opp-level = ; + }; + + rpmhpd_opp_nom_l1: opp7 { + opp-level = ; + }; + + rpmhpd_opp_nom_l2: opp8 { + opp-level = ; + }; + + rpmhpd_opp_turbo: opp9 { + opp-level = ; + }; + + rpmhpd_opp_turbo_l1: opp10 { + opp-level = ; + }; + }; + }; + + bcm-voter { + compatible = "qcom,bcm-voter"; + }; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt b/Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt deleted file mode 100644 index 9b86d1eff219..000000000000 --- a/Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt +++ /dev/null @@ -1,137 +0,0 @@ -RPMH RSC: ------------- - -Resource Power Manager Hardened (RPMH) is the mechanism for communicating with -the hardened resource accelerators on Qualcomm SoCs. Requests to the resources -can be written to the Trigger Command Set (TCS) registers and using a (addr, -val) pair and triggered. Messages in the TCS are then sent in sequence over an -internal bus. - -The hardware block (Direct Resource Voter or DRV) is a part of the h/w entity -(Resource State Coordinator a.k.a RSC) that can handle multiple sleep and -active/wake resource requests. Multiple such DRVs can exist in a SoC and can -be written to from Linux. The structure of each DRV follows the same template -with a few variations that are captured by the properties here. - -A TCS may be triggered from Linux or triggered by the F/W after all the CPUs -have powered off to facilitate idle power saving. TCS could be classified as - - - ACTIVE /* Triggered by Linux */ - SLEEP /* Triggered by F/W */ - WAKE /* Triggered by F/W */ - CONTROL /* Triggered by F/W */ - -The order in which they are described in the DT, should match the hardware -configuration. - -Requests can be made for the state of a resource, when the subsystem is active -or idle. When all subsystems like Modem, GPU, CPU are idle, the resource state -will be an aggregate of the sleep votes from each of those subsystems. Clients -may request a sleep value for their shared resources in addition to the active -mode requests. - -Properties: - -- compatible: - Usage: required - Value type: - Definition: Should be "qcom,rpmh-rsc". - -- reg: - Usage: required - Value type: - Definition: The first register specifies the base address of the - DRV(s). The number of DRVs in the dependent on the RSC. - The tcs-offset specifies the start address of the - TCS in the DRVs. - -- reg-names: - Usage: required - Value type: - Definition: Maps the register specified in the reg property. Must be - "drv-0", "drv-1", "drv-2" etc and "tcs-offset". The - -- interrupts: - Usage: required - Value type: - Definition: The interrupt that trips when a message complete/response - is received for this DRV from the accelerators. - -- qcom,drv-id: - Usage: required - Value type: - Definition: The id of the DRV in the RSC block that will be used by - this controller. - -- qcom,tcs-config: - Usage: required - Value type: - Definition: The tuple defining the configuration of TCS. - Must have 2 cells which describe each TCS type. - . - The order of the TCS must match the hardware - configuration. - - Cell #1 (TCS Type): TCS types to be specified - - ACTIVE_TCS - SLEEP_TCS - WAKE_TCS - CONTROL_TCS - - Cell #2 (Number of TCS): - -- label: - Usage: optional - Value type: - Definition: Name for the RSC. The name would be used in trace logs. - -Drivers that want to use the RSC to communicate with RPMH must specify their -bindings as child nodes of the RSC controllers they wish to communicate with. - -Example 1: - -For a TCS whose RSC base address is is 0x179C0000 and is at a DRV id of 2, the -register offsets for DRV2 start at 0D00, the register calculations are like -this - -DRV0: 0x179C0000 -DRV2: 0x179C0000 + 0x10000 = 0x179D0000 -DRV2: 0x179C0000 + 0x10000 * 2 = 0x179E0000 -TCS-OFFSET: 0xD00 - - apps_rsc: rsc@179c0000 { - label = "apps_rsc"; - compatible = "qcom,rpmh-rsc"; - reg = <0x179c0000 0x10000>, - <0x179d0000 0x10000>, - <0x179e0000 0x10000>; - reg-names = "drv-0", "drv-1", "drv-2"; - interrupts = , - , - ; - qcom,tcs-offset = <0xd00>; - qcom,drv-id = <2>; - qcom,tcs-config = , - , - , - ; - }; - -Example 2: - -For a TCS whose RSC base address is 0xAF20000 and is at DRV id of 0, the -register offsets for DRV0 start at 01C00, the register calculations are like -this - -DRV0: 0xAF20000 -TCS-OFFSET: 0x1C00 - - disp_rsc: rsc@af20000 { - label = "disp_rsc"; - compatible = "qcom,rpmh-rsc"; - reg = <0xaf20000 0x10000>; - reg-names = "drv-0"; - interrupts = ; - qcom,tcs-offset = <0x1c00>; - qcom,drv-id = <0>; - qcom,tcs-config = , - , - , - ; - }; -- cgit From fcf2c0f7cbcad29f1decb88567e54c2451b60ba5 Mon Sep 17 00:00:00 2001 From: Kuldeep Singh Date: Mon, 4 Apr 2022 23:59:35 +0530 Subject: dt-bindings: qcom: geni-se: Update I2C schema reference We now have geni based QUP I2C controller binding in place as dt-bindigs/i2c/qcom,i2c-geni-qcom.yaml similar to other controllers, update reference in parent schema and while at it, also remove properties defined for the controller from common wrapper. Signed-off-by: Kuldeep Singh Reviewed-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220404182938.29492-3-singh.kuldeep87k@gmail.com --- .../devicetree/bindings/soc/qcom/qcom,geni-se.yaml | 26 +--------------------- 1 file changed, 1 insertion(+), 25 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index 1ca081b1664e..d3c89a6dd9f3 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -108,31 +108,7 @@ patternProperties: "i2c@[0-9a-f]+$": type: object description: GENI serial engine based I2C controller. - $ref: /schemas/i2c/i2c-controller.yaml# - - properties: - compatible: - enum: - - qcom,geni-i2c - - interrupts: - maxItems: 1 - - "#address-cells": - const: 1 - - "#size-cells": - const: 0 - - clock-frequency: - description: Desired I2C bus clock frequency in Hz. - default: 100000 - - required: - - compatible - - interrupts - - "#address-cells" - - "#size-cells" + $ref: /schemas/i2c/qcom,i2c-geni-qcom.yaml# "serial@[0-9a-f]+$": type: object -- cgit From 6579f39290bf056442850094b8f4b95163c17996 Mon Sep 17 00:00:00 2001 From: Kuldeep Singh Date: Mon, 4 Apr 2022 23:59:37 +0530 Subject: dt-bindings: qcom: geni-se: Update UART schema reference We now have geni based QUP UART controller individual binding, update reference in parent schema and remove properties from common wrapper. With removal of last child node schema, remove common properties of all the controllers as they have become obsolete now. Signed-off-by: Kuldeep Singh Reviewed-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220404182938.29492-5-singh.kuldeep87k@gmail.com --- .../devicetree/bindings/soc/qcom/qcom,geni-se.yaml | 51 +--------------------- 1 file changed, 1 insertion(+), 50 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index d3c89a6dd9f3..006e9f6f4dc5 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -64,39 +64,6 @@ required: - ranges patternProperties: - "^.*@[0-9a-f]+$": - type: object - description: Common properties for GENI Serial Engine based I2C, SPI and - UART controller. - - properties: - reg: - description: GENI Serial Engine register address and length. - maxItems: 1 - - clock-names: - const: se - - clocks: - description: Serial engine core clock needed by the device. - maxItems: 1 - - interconnects: - minItems: 2 - maxItems: 3 - - interconnect-names: - minItems: 2 - items: - - const: qup-core - - const: qup-config - - const: qup-memory - - required: - - reg - - clock-names - - clocks - "spi@[0-9a-f]+$": type: object description: GENI serial engine based SPI controller. SPI in master mode @@ -113,23 +80,7 @@ patternProperties: "serial@[0-9a-f]+$": type: object description: GENI Serial Engine based UART Controller. - $ref: /schemas/serial.yaml# - - properties: - compatible: - enum: - - qcom,geni-uart - - qcom,geni-debug-uart - - interrupts: - minItems: 1 - items: - - description: UART core irq - - description: Wakeup irq (RX GPIO) - - required: - - compatible - - interrupts + $ref: /schemas/serial/qcom,serial-geni-qcom.yaml# additionalProperties: false -- cgit From 5f9e72a4025b232ef0ddd5b6e4189e81091322fe Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 11 Apr 2022 17:55:28 +0200 Subject: dt-bindings: soc: qcom,smp2p: convert to dtschema Convert the Qualcomm Shared Memory Point 2 Point bindings to DT Schema. Changes against original bindings: enforce only specific names of child nodes, instead of any names. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220411155528.502889-1-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/soc/qcom/qcom,smp2p.txt | 110 ---------------- .../devicetree/bindings/soc/qcom/qcom,smp2p.yaml | 145 +++++++++++++++++++++ 2 files changed, 145 insertions(+), 110 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt deleted file mode 100644 index 49e1d72d3648..000000000000 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt +++ /dev/null @@ -1,110 +0,0 @@ -Qualcomm Shared Memory Point 2 Point binding - -The Shared Memory Point to Point (SMP2P) protocol facilitates communication of -a single 32-bit value between two processors. Each value has a single writer -(the local side) and a single reader (the remote side). Values are uniquely -identified in the system by the directed edge (local processor ID to remote -processor ID) and a string identifier. - -- compatible: - Usage: required - Value type: - Definition: must be one of: - "qcom,smp2p" - -- interrupts: - Usage: required - Value type: - Definition: one entry specifying the smp2p notification interrupt - -- mboxes: - Usage: required - Value type: - Definition: reference to the associated doorbell in APCS, as described - in mailbox/mailbox.txt - -- qcom,ipc: - Usage: required, unless mboxes is specified - Value type: - Definition: three entries specifying the outgoing ipc bit used for - signaling the remote end of the smp2p edge: - - phandle to a syscon node representing the apcs registers - - u32 representing offset to the register within the syscon - - u32 representing the ipc bit within the register - -- qcom,smem: - Usage: required - Value type: - Definition: two identifiers of the inbound and outbound smem items used - for this edge - -- qcom,local-pid: - Usage: required - Value type: - Definition: specifies the identifier of the local endpoint of this edge - -- qcom,remote-pid: - Usage: required - Value type: - Definition: specifies the identifier of the remote endpoint of this edge - -= SUBNODES -Each SMP2P pair contain a set of inbound and outbound entries, these are -described in subnodes of the smp2p device node. The node names are not -important. - -- qcom,entry-name: - Usage: required - Value type: - Definition: specifies the name of this entry, for inbound entries this - will be used to match against the remotely allocated entry - and for outbound entries this name is used for allocating - entries - -- interrupt-controller: - Usage: required for incoming entries - Value type: - Definition: marks the entry as inbound; the node should be specified - as a two cell interrupt-controller as defined in - "../interrupt-controller/interrupts.txt" - If not specified this node will denote the outgoing entry - -- #interrupt-cells: - Usage: required for incoming entries - Value type: - Definition: must be 2 - denoting the bit in the entry and IRQ flags - -- #qcom,smem-state-cells: - Usage: required for outgoing entries - Value type: - Definition: must be 1 - denoting the bit in the entry - -= EXAMPLE -The following example shows the SMP2P setup with the wireless processor, -defined from the 8974 apps processor's point-of-view. It encompasses one -inbound and one outbound entry: - -wcnss-smp2p { - compatible = "qcom,smp2p"; - qcom,smem = <431>, <451>; - - interrupts = <0 143 1>; - - qcom,ipc = <&apcs 8 18>; - - qcom,local-pid = <0>; - qcom,remote-pid = <4>; - - wcnss_smp2p_out: master-kernel { - qcom,entry-name = "master-kernel"; - - #qcom,smem-state-cells = <1>; - }; - - wcnss_smp2p_in: slave-kernel { - qcom,entry-name = "slave-kernel"; - - interrupt-controller; - #interrupt-cells = <2>; - }; -}; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml new file mode 100644 index 000000000000..795bd8cd4104 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml @@ -0,0 +1,145 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/qcom/qcom,smp2p.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Shared Memory Point 2 Point + +maintainers: + - Andy Gross + - Bjorn Andersson + - Krzysztof Kozlowski + +description: + The Shared Memory Point to Point (SMP2P) protocol facilitates communication + of a single 32-bit value between two processors. Each value has a single + writer (the local side) and a single reader (the remote side). Values are + uniquely identified in the system by the directed edge (local processor ID to + remote processor ID) and a string identifier. + +properties: + compatible: + const: qcom,smp2p + + interrupts: + maxItems: 1 + + mboxes: + maxItems: 1 + description: + Reference to the mailbox representing the outgoing doorbell in APCS for + this client. + + qcom,ipc: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to a syscon node representing the APCS registers + - description: u32 representing offset to the register within the syscon + - description: u32 representing the ipc bit within the register + description: + Three entries specifying the outgoing ipc bit used for signaling the + remote end of the smp2p edge. + + qcom,local-pid: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The identifier of the local endpoint of this edge. + + qcom,remote-pid: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The identifier of the remote endpoint of this edge. + + qcom,smem: + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + maxItems: 2 + description: + Two identifiers of the inbound and outbound smem items used for this edge. + +patternProperties: + "^master-kernel|slave-kernel|ipa-ap-to-modem|ipa-modem-to-ap$": + type: object + description: + Each SMP2P pair contain a set of inbound and outbound entries, these are + described in subnodes of the smp2p device node. The node names are not + important. + + properties: + interrupt-controller: + description: + Marks the entry as inbound; the node should be specified as a two + cell interrupt-controller. If not specified this node will denote + the outgoing entry. + + '#interrupt-cells': + const: 2 + + qcom,entry-name: + $ref: /schemas/types.yaml#/definitions/string + description: + The name of this entry, for inbound entries this will be used to + match against the remotely allocated entry and for outbound entries + this name is used for allocating entries. + + '#qcom,smem-state-cells': + $ref: /schemas/types.yaml#/definitions/uint32 + const: 1 + description: + Required for outgoing entries. + + required: + - qcom,entry-name + + oneOf: + - required: + - interrupt-controller + - '#interrupt-cells' + - required: + - '#qcom,smem-state-cells' + + additionalProperties: false + +required: + - compatible + - interrupts + - qcom,local-pid + - qcom,remote-pid + - qcom,smem + +oneOf: + - required: + - mboxes + - required: + - qcom,ipc + +additionalProperties: false + +examples: + # The following example shows the SMP2P setup with the wireless processor, + # defined from the 8974 apps processor's point-of-view. It encompasses one + # inbound and one outbound entry. + - | + #include + + shared-memory { + compatible = "qcom,smp2p"; + qcom,smem = <431>, <451>; + interrupts = ; + qcom,ipc = <&apcs 8 18>; + qcom,local-pid = <0>; + qcom,remote-pid = <4>; + + wcnss_smp2p_out: master-kernel { + qcom,entry-name = "master-kernel"; + #qcom,smem-state-cells = <1>; + }; + + wcnss_smp2p_in: slave-kernel { + qcom,entry-name = "slave-kernel"; + interrupt-controller; + #interrupt-cells = <2>; + }; + }; -- cgit From fe7ff911938eaf31a5481bdd8136c9210dd52a9b Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 19 Apr 2022 10:49:42 +0200 Subject: docs: dt: writing-schema: mention yamllint The dtschema uses yamllint, if present, to check the syntax of the files, so document this. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220419084942.27409-1-krzysztof.kozlowski@linaro.org --- Documentation/devicetree/bindings/writing-schema.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/writing-schema.rst b/Documentation/devicetree/bindings/writing-schema.rst index 2916edf829db..4a381d20f2b4 100644 --- a/Documentation/devicetree/bindings/writing-schema.rst +++ b/Documentation/devicetree/bindings/writing-schema.rst @@ -134,6 +134,8 @@ installed first. On Debian/Ubuntu systems:: Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default). +Recommended is also to install yamllint (used by dtschema when present). + Running checks ~~~~~~~~~~~~~~ -- cgit From 1c5fdf0f79f4d292fad0c746d0925cf8b209f3c3 Mon Sep 17 00:00:00 2001 From: "Nícolas F. R. A. Prado" Date: Tue, 15 Mar 2022 17:19:33 -0400 Subject: dt-bindings: pinctrl: mt8192: Add wrapping node for pin configurations MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On mt8192, the pinctrl node has pinctrl groups to group pin configurations. Each pinctrl group contains one or more pinmux subnodes to list needed pins and their configurations. By supporting multiple subnodes, we can configure different pin characteristics (driving/pull-up/pull-down/etc.) in a pinctrl group. Update the mt8192 pinctrl dt-binding to add the missing pinctrl group node that wraps the pinmux subnodes and update the example at the end. While at it, also remove the example embedded in the description since it is redundant to the already supplied example at the end. This same change was done for mt8195 in commit 79dcd4e840cc ("dt-bindings: pinctrl: mt8195: add wrapping node of pin configurations"). Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Rob Herring Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220315211936.442708-2-nfraprado@collabora.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/pinctrl-mt8192.yaml | 92 +++++++++++----------- 1 file changed, 47 insertions(+), 45 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml index 3c84676a167d..d63e23d9ed16 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml @@ -51,62 +51,55 @@ properties: #PIN CONFIGURATION NODES patternProperties: - '^pins': + '-pins$': type: object - description: | - A pinctrl node should contain at least one subnodes representing the - pinctrl groups available on the machine. Each subnode will list the - pins it needs, and how they should be configured, with regard to muxer - configuration, pullups, drive strength, input enable/disable and - input schmitt. - An example of using macro: - pincontroller { - /* GPIO0 set as multifunction GPIO0 */ - state_0_node_a { - pinmux = ; - }; - /* GPIO1 set as multifunction PWM */ - state_0_node_b { - pinmux = ; - }; - }; - $ref: "pinmux-node.yaml" - - properties: - pinmux: + additionalProperties: false + patternProperties: + '^pins': + type: object description: | - Integer array, represents gpio pin number and mux setting. - Supported pin number and mux varies for different SoCs, and are defined - as macros in dt-bindings/pinctrl/-pinfunc.h directly. + A pinctrl node should contain at least one subnodes representing the + pinctrl groups available on the machine. Each subnode will list the + pins it needs, and how they should be configured, with regard to muxer + configuration, pullups, drive strength, input enable/disable and + input schmitt. + $ref: "pinmux-node.yaml" - drive-strength: - description: | - It can support some arguments, such as MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See - dt-bindings/pinctrl/mt65xx.h. It can only support 2/4/6/8/10/12/14/16mA in mt8192. - enum: [2, 4, 6, 8, 10, 12, 14, 16] + properties: + pinmux: + description: | + Integer array, represents gpio pin number and mux setting. + Supported pin number and mux varies for different SoCs, and are defined + as macros in dt-bindings/pinctrl/-pinfunc.h directly. - bias-pull-down: true + drive-strength: + description: | + It can support some arguments, such as MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See + dt-bindings/pinctrl/mt65xx.h. It can only support 2/4/6/8/10/12/14/16mA in mt8192. + enum: [2, 4, 6, 8, 10, 12, 14, 16] - bias-pull-up: true + bias-pull-down: true - bias-disable: true + bias-pull-up: true - output-high: true + bias-disable: true - output-low: true + output-high: true - input-enable: true + output-low: true - input-disable: true + input-enable: true - input-schmitt-enable: true + input-disable: true - input-schmitt-disable: true + input-schmitt-enable: true - required: - - pinmux + input-schmitt-disable: true - additionalProperties: false + required: + - pinmux + + additionalProperties: false allOf: - $ref: "pinctrl.yaml#" @@ -151,8 +144,17 @@ examples: interrupts = ; #interrupt-cells = <2>; - pins { - pinmux = ; - output-low; + spi1-default-pins { + pins-cs-mosi-clk { + pinmux = , + , + ; + bias-disable; + }; + + pins-miso { + pinmux = ; + bias-pull-down; + }; }; }; -- cgit From 4ac68333ff6dea9bee318e4eb4a91c0b37566600 Mon Sep 17 00:00:00 2001 From: "Nícolas F. R. A. Prado" Date: Tue, 15 Mar 2022 17:19:34 -0400 Subject: dt-bindings: pinctrl: mt8192: Add mediatek,drive-strength-adv property MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the mediatek,drive-strength-adv property to the pinctrl-mt8192 dt-binding to allow further drive current adjustments for I2C nodes on MT8192. It is the same as in mt8183-pinctrl. Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Rob Herring Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220315211936.442708-3-nfraprado@collabora.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/pinctrl-mt8192.yaml | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml index d63e23d9ed16..b52d8d0eb2d0 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml @@ -78,6 +78,32 @@ patternProperties: dt-bindings/pinctrl/mt65xx.h. It can only support 2/4/6/8/10/12/14/16mA in mt8192. enum: [2, 4, 6, 8, 10, 12, 14, 16] + mediatek,drive-strength-adv: + description: | + Describe the specific driving setup property. + For I2C pins, the existing generic driving setup can only support + 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they + can support 0.125/0.25/0.5/1mA adjustment. If we enable specific + driving setup, the existing generic setup will be disabled. + The specific driving setup is controlled by E1E0EN. + When E1=0/E0=0, the strength is 0.125mA. + When E1=0/E0=1, the strength is 0.25mA. + When E1=1/E0=0, the strength is 0.5mA. + When E1=1/E0=1, the strength is 1mA. + EN is used to enable or disable the specific driving setup. + Valid arguments are described as below: + 0: (E1, E0, EN) = (0, 0, 0) + 1: (E1, E0, EN) = (0, 0, 1) + 2: (E1, E0, EN) = (0, 1, 0) + 3: (E1, E0, EN) = (0, 1, 1) + 4: (E1, E0, EN) = (1, 0, 0) + 5: (E1, E0, EN) = (1, 0, 1) + 6: (E1, E0, EN) = (1, 1, 0) + 7: (E1, E0, EN) = (1, 1, 1) + So the valid arguments are from 0 to 7. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4, 5, 6, 7] + bias-pull-down: true bias-pull-up: true -- cgit From edbacb36ea50527672e985e7ab062562dbe4a7f0 Mon Sep 17 00:00:00 2001 From: "Nícolas F. R. A. Prado" Date: Tue, 15 Mar 2022 17:19:35 -0400 Subject: dt-bindings: pinctrl: mt8192: Add mediatek,pull-up-adv property MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the mediatek,pull-up-adv property to the pinctrl-mt8192 dt-binding to allow configuring pull-up resistors on the pins of MT8192. It is the same as in mt8183-pinctrl. Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Rob Herring Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220315211936.442708-4-nfraprado@collabora.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml index b52d8d0eb2d0..e27cbcc6e8f9 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml @@ -104,6 +104,17 @@ patternProperties: $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1, 2, 3, 4, 5, 6, 7] + mediatek,pull-up-adv: + description: | + Pull up settings for 2 pull resistors, R0 and R1. User can + configure those special pins. Valid arguments are described as below: + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + bias-pull-down: true bias-pull-up: true -- cgit From 1a08cb7303cfd898cb9b5c5b1a185e7ed329919f Mon Sep 17 00:00:00 2001 From: "Nícolas F. R. A. Prado" Date: Tue, 15 Mar 2022 17:19:36 -0400 Subject: dt-bindings: pinctrl: mt8192: Add gpio-line-names property MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the gpio-line-names optional property to the pinctrl-mt8192 binding to prevent dt_binding_check warnings when it is present in the pinctrl node in the Devicetree. Signed-off-by: Nícolas F. R. A. Prado Acked-by: Rob Herring Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220315211936.442708-5-nfraprado@collabora.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml index e27cbcc6e8f9..c90a132fbc79 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml @@ -29,6 +29,8 @@ properties: description: gpio valid number range. maxItems: 1 + gpio-line-names: true + reg: description: | Physical address base for gpio base registers. There are 11 GPIO -- cgit From f9b0593dd4fc6ea766175d881a82f8d76b9d18a2 Mon Sep 17 00:00:00 2001 From: Liu Ying Date: Tue, 19 Apr 2022 09:08:50 +0800 Subject: dt-bindings: phy: Convert mixel,mipi-dsi-phy to json-schema MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This patch converts the mixel,mipi-dsi-phy binding to DT schema format using json-schema. Comparing to the plain text version, the new binding adds the 'assigned-clocks', 'assigned-clock-parents' and 'assigned-clock-rates' properites, otherwise 'make dtbs_check' would complain that there are mis-matches. Also, the new binding requires the 'power-domains' property since all potential SoCs that embed this PHY would provide a power domain for it. The example of the new binding takes reference to the latest dphy node in imx8mq.dtsi. Cc: Guido Günther Cc: Kishon Vijay Abraham I Cc: Vinod Koul Cc: Rob Herring Cc: NXP Linux Team Reviewed-by: Rob Herring Reviewed-by: Guido Günther Signed-off-by: Liu Ying Link: https://lore.kernel.org/r/20220419010852.452169-4-victor.liu@nxp.com Signed-off-by: Vinod Koul --- .../devicetree/bindings/phy/mixel,mipi-dsi-phy.txt | 29 --------- .../bindings/phy/mixel,mipi-dsi-phy.yaml | 72 ++++++++++++++++++++++ 2 files changed, 72 insertions(+), 29 deletions(-) delete mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt create mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt deleted file mode 100644 index 9b23407233c0..000000000000 --- a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt +++ /dev/null @@ -1,29 +0,0 @@ -Mixel DSI PHY for i.MX8 - -The Mixel MIPI-DSI PHY IP block is e.g. found on i.MX8 platforms (along the -MIPI-DSI IP from Northwest Logic). It represents the physical layer for the -electrical signals for DSI. - -Required properties: -- compatible: Must be: - - "fsl,imx8mq-mipi-dphy" -- clocks: Must contain an entry for each entry in clock-names. -- clock-names: Must contain the following entries: - - "phy_ref": phandle and specifier referring to the DPHY ref clock -- reg: the register range of the PHY controller -- #phy-cells: number of cells in PHY, as defined in - Documentation/devicetree/bindings/phy/phy-bindings.txt - this must be <0> - -Optional properties: -- power-domains: phandle to power domain - -Example: - dphy: dphy@30a0030 { - compatible = "fsl,imx8mq-mipi-dphy"; - clocks = <&clk IMX8MQ_CLK_DSI_PHY_REF>; - clock-names = "phy_ref"; - reg = <0x30a00300 0x100>; - power-domains = <&pd_mipi0>; - #phy-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml new file mode 100644 index 000000000000..c34f2e6d6bd5 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/mixel,mipi-dsi-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mixel DSI PHY for i.MX8 + +maintainers: + - Guido Günther + +description: | + The Mixel MIPI-DSI PHY IP block is e.g. found on i.MX8 platforms (along the + MIPI-DSI IP from Northwest Logic). It represents the physical layer for the + electrical signals for DSI. + +properties: + compatible: + enum: + - fsl,imx8mq-mipi-dphy + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: phy_ref + + assigned-clocks: + maxItems: 1 + + assigned-clock-parents: + maxItems: 1 + + assigned-clock-rates: + maxItems: 1 + + "#phy-cells": + const: 0 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - assigned-clocks + - assigned-clock-parents + - assigned-clock-rates + - "#phy-cells" + - power-domains + +additionalProperties: false + +examples: + - | + #include + dphy: dphy@30a0030 { + compatible = "fsl,imx8mq-mipi-dphy"; + reg = <0x30a00300 0x100>; + clocks = <&clk IMX8MQ_CLK_DSI_PHY_REF>; + clock-names = "phy_ref"; + assigned-clocks = <&clk IMX8MQ_CLK_DSI_PHY_REF>; + assigned-clock-parents = <&clk IMX8MQ_VIDEO_PLL1_OUT>; + assigned-clock-rates = <24000000>; + #phy-cells = <0>; + power-domains = <&pgc_mipi>; + }; -- cgit From 0ccb8385e92af90443791b7706675feb45b8b9f9 Mon Sep 17 00:00:00 2001 From: Liu Ying Date: Tue, 19 Apr 2022 09:08:51 +0800 Subject: dt-bindings: phy: mixel: mipi-dsi-phy: Add Mixel combo PHY support for i.MX8qxp MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add support for Mixel MIPI DPHY + LVDS PHY combo IP as found on Freescale i.MX8qxp SoC. Cc: Guido Günther Cc: Kishon Vijay Abraham I Cc: Vinod Koul Cc: Rob Herring Cc: NXP Linux Team Reviewed-by: Rob Herring Reviewed-by: Guido Günther Signed-off-by: Liu Ying Link: https://lore.kernel.org/r/20220419010852.452169-5-victor.liu@nxp.com Signed-off-by: Vinod Koul --- .../bindings/phy/mixel,mipi-dsi-phy.yaml | 41 ++++++++++++++++++++-- 1 file changed, 38 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml index c34f2e6d6bd5..786cfd71cb7e 100644 --- a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml @@ -14,10 +14,14 @@ description: | MIPI-DSI IP from Northwest Logic). It represents the physical layer for the electrical signals for DSI. + The Mixel PHY IP block found on i.MX8qxp is a combo PHY that can work + in either MIPI-DSI PHY mode or LVDS PHY mode. + properties: compatible: enum: - fsl,imx8mq-mipi-dphy + - fsl,imx8qxp-mipi-dphy reg: maxItems: 1 @@ -40,6 +44,11 @@ properties: "#phy-cells": const: 0 + fsl,syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: | + A phandle which points to Control and Status Registers(CSR) module. + power-domains: maxItems: 1 @@ -48,12 +57,38 @@ required: - reg - clocks - clock-names - - assigned-clocks - - assigned-clock-parents - - assigned-clock-rates - "#phy-cells" - power-domains +allOf: + - if: + properties: + compatible: + contains: + const: fsl,imx8mq-mipi-dphy + then: + properties: + fsl,syscon: false + + required: + - assigned-clocks + - assigned-clock-parents + - assigned-clock-rates + + - if: + properties: + compatible: + contains: + const: fsl,imx8qxp-mipi-dphy + then: + properties: + assigned-clocks: false + assigned-clock-parents: false + assigned-clock-rates: false + + required: + - fsl,syscon + additionalProperties: false examples: -- cgit From 898ee22c32bed56685552fd3352ef9bd6a68af1f Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Mon, 18 Apr 2022 18:10:21 -0700 Subject: Drop Documentation/ide/ Drop all Documentation/ide/ since IDE support was deleted by Christoph Hellwig , Jun 16 2021. Fixes: b7fb14d3ac63 ("ide: remove the legacy ide driver") Signed-off-by: Randy Dunlap Acked-by: Jens Axboe Acked-by: Damien Le Moal Reviewed-by: Christoph Hellwig Signed-off-by: Jonathan Corbet --- Documentation/ide/ChangeLog.ide-cd.1994-2004 | 268 ----------------------- Documentation/ide/ChangeLog.ide-floppy.1996-2002 | 63 ------ Documentation/ide/ChangeLog.ide-tape.1995-2002 | 257 ---------------------- Documentation/ide/changelogs.rst | 17 -- Documentation/ide/ide-tape.rst | 68 ------ Documentation/ide/ide.rst | 265 ---------------------- Documentation/ide/index.rst | 21 -- Documentation/ide/warm-plug-howto.rst | 18 -- Documentation/index.rst | 1 - 9 files changed, 978 deletions(-) delete mode 100644 Documentation/ide/ChangeLog.ide-cd.1994-2004 delete mode 100644 Documentation/ide/ChangeLog.ide-floppy.1996-2002 delete mode 100644 Documentation/ide/ChangeLog.ide-tape.1995-2002 delete mode 100644 Documentation/ide/changelogs.rst delete mode 100644 Documentation/ide/ide-tape.rst delete mode 100644 Documentation/ide/ide.rst delete mode 100644 Documentation/ide/index.rst delete mode 100644 Documentation/ide/warm-plug-howto.rst (limited to 'Documentation') diff --git a/Documentation/ide/ChangeLog.ide-cd.1994-2004 b/Documentation/ide/ChangeLog.ide-cd.1994-2004 deleted file mode 100644 index 4cc3ad99f39b..000000000000 --- a/Documentation/ide/ChangeLog.ide-cd.1994-2004 +++ /dev/null @@ -1,268 +0,0 @@ -/* - * 1.00 Oct 31, 1994 -- Initial version. - * 1.01 Nov 2, 1994 -- Fixed problem with starting request in - * cdrom_check_status. - * 1.03 Nov 25, 1994 -- leaving unmask_intr[] as a user-setting (as for disks) - * (from mlord) -- minor changes to cdrom_setup() - * -- renamed ide_dev_s to ide_drive_t, enable irq on command - * 2.00 Nov 27, 1994 -- Generalize packet command interface; - * add audio ioctls. - * 2.01 Dec 3, 1994 -- Rework packet command interface to handle devices - * which send an interrupt when ready for a command. - * 2.02 Dec 11, 1994 -- Cache the TOC in the driver. - * Don't use SCMD_PLAYAUDIO_TI; it's not included - * in the current version of ATAPI. - * Try to use LBA instead of track or MSF addressing - * when possible. - * Don't wait for READY_STAT. - * 2.03 Jan 10, 1995 -- Rewrite block read routines to handle block sizes - * other than 2k and to move multiple sectors in a - * single transaction. - * 2.04 Apr 21, 1995 -- Add work-around for Creative Labs CD220E drives. - * Thanks to Nick Saw for - * help in figuring this out. Ditto for Acer and - * Aztech drives, which seem to have the same problem. - * 2.04b May 30, 1995 -- Fix to match changes in ide.c version 3.16 -ml - * 2.05 Jun 8, 1995 -- Don't attempt to retry after an illegal request - * or data protect error. - * Use HWIF and DEV_HWIF macros as in ide.c. - * Always try to do a request_sense after - * a failed command. - * Include an option to give textual descriptions - * of ATAPI errors. - * Fix a bug in handling the sector cache which - * showed up if the drive returned data in 512 byte - * blocks (like Pioneer drives). Thanks to - * Richard Hirst for diagnosing this. - * Properly supply the page number field in the - * MODE_SELECT command. - * PLAYAUDIO12 is broken on the Aztech; work around it. - * 2.05x Aug 11, 1995 -- lots of data structure renaming/restructuring in ide.c - * (my apologies to Scott, but now ide-cd.c is independent) - * 3.00 Aug 22, 1995 -- Implement CDROMMULTISESSION ioctl. - * Implement CDROMREADAUDIO ioctl (UNTESTED). - * Use input_ide_data() and output_ide_data(). - * Add door locking. - * Fix usage count leak in cdrom_open, which happened - * when a read-write mount was attempted. - * Try to load the disk on open. - * Implement CDROMEJECT_SW ioctl (off by default). - * Read total cdrom capacity during open. - * Rearrange logic in cdrom_decode_status. Issue - * request sense commands for failed packet commands - * from here instead of from cdrom_queue_packet_command. - * Fix a race condition in retrieving error information. - * Suppress printing normal unit attention errors and - * some drive not ready errors. - * Implement CDROMVOLREAD ioctl. - * Implement CDROMREADMODE1/2 ioctls. - * Fix race condition in setting up interrupt handlers - * when the `serialize' option is used. - * 3.01 Sep 2, 1995 -- Fix ordering of reenabling interrupts in - * cdrom_queue_request. - * Another try at using ide_[input,output]_data. - * 3.02 Sep 16, 1995 -- Stick total disk capacity in partition table as well. - * Make VERBOSE_IDE_CD_ERRORS dump failed command again. - * Dump out more information for ILLEGAL REQUEST errs. - * Fix handling of errors occurring before the - * packet command is transferred. - * Fix transfers with odd bytelengths. - * 3.03 Oct 27, 1995 -- Some Creative drives have an id of just `CD'. - * `DCI-2S10' drives are broken too. - * 3.04 Nov 20, 1995 -- So are Vertos drives. - * 3.05 Dec 1, 1995 -- Changes to go with overhaul of ide.c and ide-tape.c - * 3.06 Dec 16, 1995 -- Add support needed for partitions. - * More workarounds for Vertos bugs (based on patches - * from Holger Dietze ). - * Try to eliminate byteorder assumptions. - * Use atapi_cdrom_subchnl struct definition. - * Add STANDARD_ATAPI compilation option. - * 3.07 Jan 29, 1996 -- More twiddling for broken drives: Sony 55D, - * Vertos 300. - * Add NO_DOOR_LOCKING configuration option. - * Handle drive_cmd requests w/NULL args (for hdparm -t). - * Work around sporadic Sony55e audio play problem. - * 3.07a Feb 11, 1996 -- check drive->id for NULL before dereferencing, to fix - * problem with "hde=cdrom" with no drive present. -ml - * 3.08 Mar 6, 1996 -- More Vertos workarounds. - * 3.09 Apr 5, 1996 -- Add CDROMCLOSETRAY ioctl. - * Switch to using MSF addressing for audio commands. - * Reformat to match kernel tabbing style. - * Add CDROM_GET_UPC ioctl. - * 3.10 Apr 10, 1996 -- Fix compilation error with STANDARD_ATAPI. - * 3.11 Apr 29, 1996 -- Patch from Heiko Eißfeldt - * to remove redundant verify_area calls. - * 3.12 May 7, 1996 -- Rudimentary changer support. Based on patches - * from Gerhard Zuber . - * Let open succeed even if there's no loaded disc. - * 3.13 May 19, 1996 -- Fixes for changer code. - * 3.14 May 29, 1996 -- Add work-around for Vertos 600. - * (From Hennus Bergman .) - * 3.15 July 2, 1996 -- Added support for Sanyo 3 CD changers - * from Ben Galliart with - * special help from Jeff Lightfoot - * - * 3.15a July 9, 1996 -- Improved Sanyo 3 CD changer identification - * 3.16 Jul 28, 1996 -- Fix from Gadi to reduce kernel stack usage for ioctl. - * 3.17 Sep 17, 1996 -- Tweak audio reads for some drives. - * Start changing CDROMLOADFROMSLOT to CDROM_SELECT_DISC. - * 3.18 Oct 31, 1996 -- Added module and DMA support. - * - * 4.00 Nov 5, 1996 -- New ide-cd maintainer, - * Erik B. Andersen - * -- Newer Creative drives don't always set the error - * register correctly. Make sure we see media changes - * regardless. - * -- Integrate with generic cdrom driver. - * -- CDROMGETSPINDOWN and CDROMSETSPINDOWN ioctls, based on - * a patch from Ciro Cattuto <>. - * -- Call set_device_ro. - * -- Implement CDROMMECHANISMSTATUS and CDROMSLOTTABLE - * ioctls, based on patch by Erik Andersen - * -- Add some probes of drive capability during setup. - * - * 4.01 Nov 11, 1996 -- Split into ide-cd.c and ide-cd.h - * -- Removed CDROMMECHANISMSTATUS and CDROMSLOTTABLE - * ioctls in favor of a generalized approach - * using the generic cdrom driver. - * -- Fully integrated with the 2.1.X kernel. - * -- Other stuff that I forgot (lots of changes) - * - * 4.02 Dec 01, 1996 -- Applied patch from Gadi Oxman - * to fix the drive door locking problems. - * - * 4.03 Dec 04, 1996 -- Added DSC overlap support. - * 4.04 Dec 29, 1996 -- Added CDROMREADRAW ioclt based on patch - * by Ales Makarov (xmakarov@sun.felk.cvut.cz) - * - * 4.05 Nov 20, 1997 -- Modified to print more drive info on init - * Minor other changes - * Fix errors on CDROMSTOP (If you have a "Dolphin", - * you must define IHAVEADOLPHIN) - * Added identifier so new Sanyo CD-changer works - * Better detection if door locking isn't supported - * - * 4.06 Dec 17, 1997 -- fixed endless "tray open" messages -ml - * 4.07 Dec 17, 1997 -- fallback to set pc->stat on "tray open" - * 4.08 Dec 18, 1997 -- spew less noise when tray is empty - * -- fix speed display for ACER 24X, 18X - * 4.09 Jan 04, 1998 -- fix handling of the last block so we return - * an end of file instead of an I/O error (Gadi) - * 4.10 Jan 24, 1998 -- fixed a bug so now changers can change to a new - * slot when there is no disc in the current slot. - * -- Fixed a memory leak where info->changer_info was - * malloc'ed but never free'd when closing the device. - * -- Cleaned up the global namespace a bit by making more - * functions static that should already have been. - * 4.11 Mar 12, 1998 -- Added support for the CDROM_SELECT_SPEED ioctl - * based on a patch for 2.0.33 by Jelle Foks - * , a patch for 2.0.33 - * by Toni Giorgino , the SCSI - * version, and my own efforts. -erik - * -- Fixed a stupid bug which egcs was kind enough to - * inform me of where "Illegal mode for this track" - * was never returned due to a comparison on data - * types of limited range. - * 4.12 Mar 29, 1998 -- Fixed bug in CDROM_SELECT_SPEED so write speed is - * now set ionly for CD-R and CD-RW drives. I had - * removed this support because it produced errors. - * It produced errors _only_ for non-writers. duh. - * 4.13 May 05, 1998 -- Suppress useless "in progress of becoming ready" - * messages, since this is not an error. - * -- Change error messages to be const - * -- Remove a "\t" which looks ugly in the syslogs - * 4.14 July 17, 1998 -- Change to pointing to .ps version of ATAPI spec - * since the .pdf version doesn't seem to work... - * -- Updated the TODO list to something more current. - * - * 4.15 Aug 25, 1998 -- Updated ide-cd.h to respect machine endianness, - * patch thanks to "Eddie C. Dost" - * - * 4.50 Oct 19, 1998 -- New maintainers! - * Jens Axboe - * Chris Zwilling - * - * 4.51 Dec 23, 1998 -- Jens Axboe - * - ide_cdrom_reset enabled since the ide subsystem - * handles resets fine now. - * - Transfer size fix for Samsung CD-ROMs, thanks to - * "Ville Hallik" . - * - other minor stuff. - * - * 4.52 Jan 19, 1999 -- Jens Axboe - * - Detect DVD-ROM/RAM drives - * - * 4.53 Feb 22, 1999 - Include other model Samsung and one Goldstar - * drive in transfer size limit. - * - Fix the I/O error when doing eject without a medium - * loaded on some drives. - * - CDROMREADMODE2 is now implemented through - * CDROMREADRAW, since many drives don't support - * MODE2 (even though ATAPI 2.6 says they must). - * - Added ignore parameter to ide-cd (as a module), eg - * insmod ide-cd ignore='hda hdb' - * Useful when using ide-cd in conjunction with - * ide-scsi. TODO: non-modular way of doing the - * same. - * - * 4.54 Aug 5, 1999 - Support for MMC2 class commands through the generic - * packet interface to cdrom.c. - * - Unified audio ioctl support, most of it. - * - cleaned up various deprecated verify_area(). - * - Added ide_cdrom_packet() as the interface for - * the Uniform generic_packet(). - * - bunch of other stuff, will fill in logs later. - * - report 1 slot for non-changers, like the other - * cd-rom drivers. don't report select disc for - * non-changers as well. - * - mask out audio playing, if the device can't do it. - * - * 4.55 Sep 1, 1999 - Eliminated the rest of the audio ioctls, except - * for CDROMREADTOC[ENTRY|HEADER]. Some of the drivers - * use this independently of the actual audio handling. - * They will disappear later when I get the time to - * do it cleanly. - * - Minimize the TOC reading - only do it when we - * know a media change has occurred. - * - Moved all the CDROMREADx ioctls to the Uniform layer. - * - Heiko Eißfeldt supplied - * some fixes for CDI. - * - CD-ROM leaving door locked fix from Andries - * Brouwer - * - Erik Andersen unified - * commands across the various drivers and how - * sense errors are handled. - * - * 4.56 Sep 12, 1999 - Removed changer support - it is now in the - * Uniform layer. - * - Added partition based multisession handling. - * - Mode sense and mode select moved to the - * Uniform layer. - * - Fixed a problem with WPI CDS-32X drive - it - * failed the capabilities - * - * 4.57 Apr 7, 2000 - Fixed sense reporting. - * - Fixed possible oops in ide_cdrom_get_last_session() - * - Fix locking mania and make ide_cdrom_reset relock - * - Stop spewing errors to log when magicdev polls with - * TEST_UNIT_READY on some drives. - * - Various fixes from Tobias Ringstrom: - * tray if it was locked prior to the reset. - * - cdrom_read_capacity returns one frame too little. - * - Fix real capacity reporting. - * - * 4.58 May 1, 2000 - Clean up ACER50 stuff. - * - Fix small problem with ide_cdrom_capacity - * - * 4.59 Aug 11, 2000 - Fix changer problem in cdrom_read_toc, we weren't - * correctly sensing a disc change. - * - Rearranged some code - * - Use extended sense on drives that support it for - * correctly reporting tray status -- from - * Michael D Johnson - * 4.60 Dec 17, 2003 - Add mt rainier support - * - Bump timeout for packet commands, matches sr - * - Odd stuff - * 4.61 Jan 22, 2004 - support hardware sector sizes other than 2kB, - * Pascal Schmidt - */ diff --git a/Documentation/ide/ChangeLog.ide-floppy.1996-2002 b/Documentation/ide/ChangeLog.ide-floppy.1996-2002 deleted file mode 100644 index 46c19ef32a9e..000000000000 --- a/Documentation/ide/ChangeLog.ide-floppy.1996-2002 +++ /dev/null @@ -1,63 +0,0 @@ -/* - * Many thanks to Lode Leroy , who tested so many - * ALPHA patches to this driver on an EASYSTOR LS-120 ATAPI floppy drive. - * - * Ver 0.1 Oct 17 96 Initial test version, mostly based on ide-tape.c. - * Ver 0.2 Oct 31 96 Minor changes. - * Ver 0.3 Dec 2 96 Fixed error recovery bug. - * Ver 0.4 Jan 26 97 Add support for the HDIO_GETGEO ioctl. - * Ver 0.5 Feb 21 97 Add partitions support. - * Use the minimum of the LBA and CHS capacities. - * Avoid hwgroup->rq == NULL on the last irq. - * Fix potential null dereferencing with DEBUG_LOG. - * Ver 0.8 Dec 7 97 Increase irq timeout from 10 to 50 seconds. - * Add media write-protect detection. - * Issue START command only if TEST UNIT READY fails. - * Add work-around for IOMEGA ZIP revision 21.D. - * Remove idefloppy_get_capabilities(). - * Ver 0.9 Jul 4 99 Fix a bug which might have caused the number of - * bytes requested on each interrupt to be zero. - * Thanks to for pointing this out. - * Ver 0.9.sv Jan 6 01 Sam Varshavchik - * Implement low level formatting. Reimplemented - * IDEFLOPPY_CAPABILITIES_PAGE, since we need the srfp - * bit. My LS-120 drive barfs on - * IDEFLOPPY_CAPABILITIES_PAGE, but maybe it's just me. - * Compromise by not reporting a failure to get this - * mode page. Implemented four IOCTLs in order to - * implement formatting. IOCTls begin with 0x4600, - * 0x46 is 'F' as in Format. - * Jan 9 01 Userland option to select format verify. - * Added PC_SUPPRESS_ERROR flag - some idefloppy drives - * do not implement IDEFLOPPY_CAPABILITIES_PAGE, and - * return a sense error. Suppress error reporting in - * this particular case in order to avoid spurious - * errors in syslog. The culprit is - * idefloppy_get_capability_page(), so move it to - * idefloppy_begin_format() so that it's not used - * unless absolutely necessary. - * If drive does not support format progress indication - * monitor the dsc bit in the status register. - * Also, O_NDELAY on open will allow the device to be - * opened without a disk available. This can be used to - * open an unformatted disk, or get the device capacity. - * Ver 0.91 Dec 11 99 Added IOMEGA Clik! drive support by - * - * Ver 0.92 Oct 22 00 Paul Bristow became official maintainer for this - * driver. Included Powerbook internal zip kludge. - * Ver 0.93 Oct 24 00 Fixed bugs for Clik! drive - * no disk on insert and disk change now works - * Ver 0.94 Oct 27 00 Tidied up to remove strstr(Clik) everywhere - * Ver 0.95 Nov 7 00 Brought across to kernel 2.4 - * Ver 0.96 Jan 7 01 Actually in line with release version of 2.4.0 - * including set_bit patch from Rusty Russell - * Ver 0.97 Jul 22 01 Merge 0.91-0.96 onto 0.9.sv for ac series - * Ver 0.97.sv Aug 3 01 Backported from 2.4.7-ac3 - * Ver 0.98 Oct 26 01 Split idefloppy_transfer_pc into two pieces to - * fix a lost interrupt problem. It appears the busy - * bit was being deasserted by my IOMEGA ATAPI ZIP 100 - * drive before the drive was actually ready. - * Ver 0.98a Oct 29 01 Expose delay value so we can play. - * Ver 0.99 Feb 24 02 Remove duplicate code, modify clik! detection code - * to support new PocketZip drives - */ diff --git a/Documentation/ide/ChangeLog.ide-tape.1995-2002 b/Documentation/ide/ChangeLog.ide-tape.1995-2002 deleted file mode 100644 index 877fac8770b3..000000000000 --- a/Documentation/ide/ChangeLog.ide-tape.1995-2002 +++ /dev/null @@ -1,257 +0,0 @@ -/* - * Ver 0.1 Nov 1 95 Pre-working code :-) - * Ver 0.2 Nov 23 95 A short backup (few megabytes) and restore procedure - * was successful ! (Using tar cvf ... on the block - * device interface). - * A longer backup resulted in major swapping, bad - * overall Linux performance and eventually failed as - * we received non serial read-ahead requests from the - * buffer cache. - * Ver 0.3 Nov 28 95 Long backups are now possible, thanks to the - * character device interface. Linux's responsiveness - * and performance doesn't seem to be much affected - * from the background backup procedure. - * Some general mtio.h magnetic tape operations are - * now supported by our character device. As a result, - * popular tape utilities are starting to work with - * ide tapes :-) - * The following configurations were tested: - * 1. An IDE ATAPI TAPE shares the same interface - * and irq with an IDE ATAPI CDROM. - * 2. An IDE ATAPI TAPE shares the same interface - * and irq with a normal IDE disk. - * Both configurations seemed to work just fine ! - * However, to be on the safe side, it is meanwhile - * recommended to give the IDE TAPE its own interface - * and irq. - * The one thing which needs to be done here is to - * add a "request postpone" feature to ide.c, - * so that we won't have to wait for the tape to finish - * performing a long media access (DSC) request (such - * as a rewind) before we can access the other device - * on the same interface. This effect doesn't disturb - * normal operation most of the time because read/write - * requests are relatively fast, and once we are - * performing one tape r/w request, a lot of requests - * from the other device can be queued and ide.c will - * service all of them after this single tape request. - * Ver 1.0 Dec 11 95 Integrated into Linux 1.3.46 development tree. - * On each read / write request, we now ask the drive - * if we can transfer a constant number of bytes - * (a parameter of the drive) only to its buffers, - * without causing actual media access. If we can't, - * we just wait until we can by polling the DSC bit. - * This ensures that while we are not transferring - * more bytes than the constant referred to above, the - * interrupt latency will not become too high and - * we won't cause an interrupt timeout, as happened - * occasionally in the previous version. - * While polling for DSC, the current request is - * postponed and ide.c is free to handle requests from - * the other device. This is handled transparently to - * ide.c. The hwgroup locking method which was used - * in the previous version was removed. - * Use of new general features which are provided by - * ide.c for use with atapi devices. - * (Programming done by Mark Lord) - * Few potential bug fixes (Again, suggested by Mark) - * Single character device data transfers are now - * not limited in size, as they were before. - * We are asking the tape about its recommended - * transfer unit and send a larger data transfer - * as several transfers of the above size. - * For best results, use an integral number of this - * basic unit (which is shown during driver - * initialization). I will soon add an ioctl to get - * this important parameter. - * Our data transfer buffer is allocated on startup, - * rather than before each data transfer. This should - * ensure that we will indeed have a data buffer. - * Ver 1.1 Dec 14 95 Fixed random problems which occurred when the tape - * shared an interface with another device. - * (poll_for_dsc was a complete mess). - * Removed some old (non-active) code which had - * to do with supporting buffer cache originated - * requests. - * The block device interface can now be opened, so - * that general ide driver features like the unmask - * interrupts flag can be selected with an ioctl. - * This is the only use of the block device interface. - * New fast pipelined operation mode (currently only on - * writes). When using the pipelined mode, the - * throughput can potentially reach the maximum - * tape supported throughput, regardless of the - * user backup program. On my tape drive, it sometimes - * boosted performance by a factor of 2. Pipelined - * mode is enabled by default, but since it has a few - * downfalls as well, you may want to disable it. - * A short explanation of the pipelined operation mode - * is available below. - * Ver 1.2 Jan 1 96 Eliminated pipelined mode race condition. - * Added pipeline read mode. As a result, restores - * are now as fast as backups. - * Optimized shared interface behavior. The new behavior - * typically results in better IDE bus efficiency and - * higher tape throughput. - * Pre-calculation of the expected read/write request - * service time, based on the tape's parameters. In - * the pipelined operation mode, this allows us to - * adjust our polling frequency to a much lower value, - * and thus to dramatically reduce our load on Linux, - * without any decrease in performance. - * Implemented additional mtio.h operations. - * The recommended user block size is returned by - * the MTIOCGET ioctl. - * Additional minor changes. - * Ver 1.3 Feb 9 96 Fixed pipelined read mode bug which prevented the - * use of some block sizes during a restore procedure. - * The character device interface will now present a - * continuous view of the media - any mix of block sizes - * during a backup/restore procedure is supported. The - * driver will buffer the requests internally and - * convert them to the tape's recommended transfer - * unit, making performance almost independent of the - * chosen user block size. - * Some improvements in error recovery. - * By cooperating with ide-dma.c, bus mastering DMA can - * now sometimes be used with IDE tape drives as well. - * Bus mastering DMA has the potential to dramatically - * reduce the CPU's overhead when accessing the device, - * and can be enabled by using hdparm -d1 on the tape's - * block device interface. For more info, read the - * comments in ide-dma.c. - * Ver 1.4 Mar 13 96 Fixed serialize support. - * Ver 1.5 Apr 12 96 Fixed shared interface operation, broken in 1.3.85. - * Fixed pipelined read mode inefficiency. - * Fixed nasty null dereferencing bug. - * Ver 1.6 Aug 16 96 Fixed FPU usage in the driver. - * Fixed end of media bug. - * Ver 1.7 Sep 10 96 Minor changes for the CONNER CTT8000-A model. - * Ver 1.8 Sep 26 96 Attempt to find a better balance between good - * interactive response and high system throughput. - * Ver 1.9 Nov 5 96 Automatically cross encountered filemarks rather - * than requiring an explicit FSF command. - * Abort pending requests at end of media. - * MTTELL was sometimes returning incorrect results. - * Return the real block size in the MTIOCGET ioctl. - * Some error recovery bug fixes. - * Ver 1.10 Nov 5 96 Major reorganization. - * Reduced CPU overhead a bit by eliminating internal - * bounce buffers. - * Added module support. - * Added multiple tape drives support. - * Added partition support. - * Rewrote DSC handling. - * Some portability fixes. - * Removed ide-tape.h. - * Additional minor changes. - * Ver 1.11 Dec 2 96 Bug fix in previous DSC timeout handling. - * Use ide_stall_queue() for DSC overlap. - * Use the maximum speed rather than the current speed - * to compute the request service time. - * Ver 1.12 Dec 7 97 Fix random memory overwriting and/or last block data - * corruption, which could occur if the total number - * of bytes written to the tape was not an integral - * number of tape blocks. - * Add support for INTERRUPT DRQ devices. - * Ver 1.13 Jan 2 98 Add "speed == 0" work-around for HP COLORADO 5GB - * Ver 1.14 Dec 30 98 Partial fixes for the Sony/AIWA tape drives. - * Replace cli()/sti() with hwgroup spinlocks. - * Ver 1.15 Mar 25 99 Fix SMP race condition by replacing hwgroup - * spinlock with private per-tape spinlock. - * Ver 1.16 Sep 1 99 Add OnStream tape support. - * Abort read pipeline on EOD. - * Wait for the tape to become ready in case it returns - * "in the process of becoming ready" on open(). - * Fix zero padding of the last written block in - * case the tape block size is larger than PAGE_SIZE. - * Decrease the default disconnection time to tn. - * Ver 1.16e Oct 3 99 Minor fixes. - * Ver 1.16e1 Oct 13 99 Patches by Arnold Niessen, - * niessen@iae.nl / arnold.niessen@philips.com - * GO-1) Undefined code in idetape_read_position - * according to Gadi's email - * AJN-1) Minor fix asc == 11 should be asc == 0x11 - * in idetape_issue_packet_command (did effect - * debugging output only) - * AJN-2) Added more debugging output, and - * added ide-tape: where missing. I would also - * like to add tape->name where possible - * AJN-3) Added different debug_level's - * via /proc/ide/hdc/settings - * "debug_level" determines amount of debugging output; - * can be changed using /proc/ide/hdx/settings - * 0 : almost no debugging output - * 1 : 0+output errors only - * 2 : 1+output all sensekey/asc - * 3 : 2+follow all chrdev related procedures - * 4 : 3+follow all procedures - * 5 : 4+include pc_stack rq_stack info - * 6 : 5+USE_COUNT updates - * AJN-4) Fixed timeout for retension in idetape_queue_pc_tail - * from 5 to 10 minutes - * AJN-5) Changed maximum number of blocks to skip when - * reading tapes with multiple consecutive write - * errors from 100 to 1000 in idetape_get_logical_blk - * Proposed changes to code: - * 1) output "logical_blk_num" via /proc - * 2) output "current_operation" via /proc - * 3) Either solve or document the fact that `mt rewind' is - * required after reading from /dev/nhtx to be - * able to rmmod the idetape module; - * Also, sometimes an application finishes but the - * device remains `busy' for some time. Same cause ? - * Proposed changes to release-notes: - * 4) write a simple `quickstart' section in the - * release notes; I volunteer if you don't want to - * 5) include a pointer to video4linux in the doc - * to stimulate video applications - * 6) release notes lines 331 and 362: explain what happens - * if the application data rate is higher than 1100 KB/s; - * similar approach to lower-than-500 kB/s ? - * 7) 6.6 Comparison; wouldn't it be better to allow different - * strategies for read and write ? - * Wouldn't it be better to control the tape buffer - * contents instead of the bandwidth ? - * 8) line 536: replace will by would (if I understand - * this section correctly, a hypothetical and unwanted situation - * is being described) - * Ver 1.16f Dec 15 99 Change place of the secondary OnStream header frames. - * Ver 1.17 Nov 2000 / Jan 2001 Marcel Mol, marcel@mesa.nl - * - Add idetape_onstream_mode_sense_tape_parameter_page - * function to get tape capacity in frames: tape->capacity. - * - Add support for DI-50 drives( or any DI- drive). - * - 'workaround' for read error/blank block around block 3000. - * - Implement Early warning for end of media for Onstream. - * - Cosmetic code changes for readability. - * - Idetape_position_tape should not use SKIP bit during - * Onstream read recovery. - * - Add capacity, logical_blk_num and first/last_frame_position - * to /proc/ide/hd?/settings. - * - Module use count was gone in the Linux 2.4 driver. - * Ver 1.17a Apr 2001 Willem Riede osst@riede.org - * - Get drive's actual block size from mode sense block descriptor - * - Limit size of pipeline - * Ver 1.17b Oct 2002 Alan Stern - * Changed IDETAPE_MIN_PIPELINE_STAGES to 1 and actually used - * it in the code! - * Actually removed aborted stages in idetape_abort_pipeline - * instead of just changing the command code. - * Made the transfer byte count for Request Sense equal to the - * actual length of the data transfer. - * Changed handling of partial data transfers: they do not - * cause DMA errors. - * Moved initiation of DMA transfers to the correct place. - * Removed reference to unallocated memory. - * Made __idetape_discard_read_pipeline return the number of - * sectors skipped, not the number of stages. - * Replaced errant kfree() calls with __idetape_kfree_stage(). - * Fixed off-by-one error in testing the pipeline length. - * Fixed handling of filemarks in the read pipeline. - * Small code optimization for MTBSF and MTBSFM ioctls. - * Don't try to unlock the door during device close if is - * already unlocked! - * Cosmetic fixes to miscellaneous debugging output messages. - * Set the minimum /proc/ide/hd?/settings values for "pipeline", - * "pipeline_min", and "pipeline_max" to 1. - */ diff --git a/Documentation/ide/changelogs.rst b/Documentation/ide/changelogs.rst deleted file mode 100644 index fdf9d0fb8027..000000000000 --- a/Documentation/ide/changelogs.rst +++ /dev/null @@ -1,17 +0,0 @@ -Changelog for ide cd --------------------- - - .. include:: ChangeLog.ide-cd.1994-2004 - :literal: - -Changelog for ide floppy ------------------------- - - .. include:: ChangeLog.ide-floppy.1996-2002 - :literal: - -Changelog for ide tape ----------------------- - - .. include:: ChangeLog.ide-tape.1995-2002 - :literal: diff --git a/Documentation/ide/ide-tape.rst b/Documentation/ide/ide-tape.rst deleted file mode 100644 index 3e061d9c0e38..000000000000 --- a/Documentation/ide/ide-tape.rst +++ /dev/null @@ -1,68 +0,0 @@ -=============================== -IDE ATAPI streaming tape driver -=============================== - -This driver is a part of the Linux ide driver. - -The driver, in co-operation with ide.c, basically traverses the -request-list for the block device interface. The character device -interface, on the other hand, creates new requests, adds them -to the request-list of the block device, and waits for their completion. - -The block device major and minor numbers are determined from the -tape's relative position in the ide interfaces, as explained in ide.c. - -The character device interface consists of the following devices:: - - ht0 major 37, minor 0 first IDE tape, rewind on close. - ht1 major 37, minor 1 second IDE tape, rewind on close. - ... - nht0 major 37, minor 128 first IDE tape, no rewind on close. - nht1 major 37, minor 129 second IDE tape, no rewind on close. - ... - -The general magnetic tape commands compatible interface, as defined by -include/linux/mtio.h, is accessible through the character device. - -General ide driver configuration options, such as the interrupt-unmask -flag, can be configured by issuing an ioctl to the block device interface, -as any other ide device. - -Our own ide-tape ioctl's can be issued to either the block device or -the character device interface. - -Maximal throughput with minimal bus load will usually be achieved in the -following scenario: - - 1. ide-tape is operating in the pipelined operation mode. - 2. No buffering is performed by the user backup program. - -Testing was done with a 2 GB CONNER CTMA 4000 IDE ATAPI Streaming Tape Drive. - -Here are some words from the first releases of hd.c, which are quoted -in ide.c and apply here as well: - -* Special care is recommended. Have Fun! - -Possible improvements -===================== - -1. Support for the ATAPI overlap protocol. - -In order to maximize bus throughput, we currently use the DSC -overlap method which enables ide.c to service requests from the -other device while the tape is busy executing a command. The -DSC overlap method involves polling the tape's status register -for the DSC bit, and servicing the other device while the tape -isn't ready. - -In the current QIC development standard (December 1995), -it is recommended that new tape drives will *in addition* -implement the ATAPI overlap protocol, which is used for the -same purpose - efficient use of the IDE bus, but is interrupt -driven and thus has much less CPU overhead. - -ATAPI overlap is likely to be supported in most new ATAPI -devices, including new ATAPI cdroms, and thus provides us -a method by which we can achieve higher throughput when -sharing a (fast) ATA-2 disk with any (slow) new ATAPI device. diff --git a/Documentation/ide/ide.rst b/Documentation/ide/ide.rst deleted file mode 100644 index 88bdcba92f7d..000000000000 --- a/Documentation/ide/ide.rst +++ /dev/null @@ -1,265 +0,0 @@ -============================================ -Information regarding the Enhanced IDE drive -============================================ - - The hdparm utility can be used to control various IDE features on a - running system. It is packaged separately. Please Look for it on popular - linux FTP sites. - -------------------------------------------------------------------------------- - -.. important:: - - BUGGY IDE CHIPSETS CAN CORRUPT DATA!! - - PCI versions of the CMD640 and RZ1000 interfaces are now detected - automatically at startup when PCI BIOS support is configured. - - Linux disables the "prefetch" ("readahead") mode of the RZ1000 - to prevent data corruption possible due to hardware design flaws. - - For the CMD640, linux disables "IRQ unmasking" (hdparm -u1) on any - drive for which the "prefetch" mode of the CMD640 is turned on. - If "prefetch" is disabled (hdparm -p8), then "IRQ unmasking" can be - used again. - - For the CMD640, linux disables "32bit I/O" (hdparm -c1) on any drive - for which the "prefetch" mode of the CMD640 is turned off. - If "prefetch" is enabled (hdparm -p9), then "32bit I/O" can be - used again. - - The CMD640 is also used on some Vesa Local Bus (VLB) cards, and is *NOT* - automatically detected by Linux. For safe, reliable operation with such - interfaces, one *MUST* use the "cmd640.probe_vlb" kernel option. - - Use of the "serialize" option is no longer necessary. - -------------------------------------------------------------------------------- - -Common pitfalls -=============== - -- 40-conductor IDE cables are capable of transferring data in DMA modes up to - udma2, but no faster. - -- If possible devices should be attached to separate channels if they are - available. Typically the disk on the first and CD-ROM on the second. - -- If you mix devices on the same cable, please consider using similar devices - in respect of the data transfer mode they support. - -- Even better try to stick to the same vendor and device type on the same - cable. - -This is the multiple IDE interface driver, as evolved from hd.c -=============================================================== - -It supports up to 9 IDE interfaces per default, on one or more IRQs (usually -14 & 15). There can be up to two drives per interface, as per the ATA-6 spec.:: - - Primary: ide0, port 0x1f0; major=3; hda is minor=0; hdb is minor=64 - Secondary: ide1, port 0x170; major=22; hdc is minor=0; hdd is minor=64 - Tertiary: ide2, port 0x1e8; major=33; hde is minor=0; hdf is minor=64 - Quaternary: ide3, port 0x168; major=34; hdg is minor=0; hdh is minor=64 - fifth.. ide4, usually PCI, probed - sixth.. ide5, usually PCI, probed - -To access devices on interfaces > ide0, device entries please make sure that -device files for them are present in /dev. If not, please create such -entries, by using /dev/MAKEDEV. - -This driver automatically probes for most IDE interfaces (including all PCI -ones), for the drives/geometries attached to those interfaces, and for the IRQ -lines being used by the interfaces (normally 14, 15 for ide0/ide1). - -Any number of interfaces may share a single IRQ if necessary, at a slight -performance penalty, whether on separate cards or a single VLB card. -The IDE driver automatically detects and handles this. However, this may -or may not be harmful to your hardware.. two or more cards driving the same IRQ -can potentially burn each other's bus driver, though in practice this -seldom occurs. Be careful, and if in doubt, don't do it! - -Drives are normally found by auto-probing and/or examining the CMOS/BIOS data. -For really weird situations, the apparent (fdisk) geometry can also be specified -on the kernel "command line" using LILO. The format of such lines is:: - - ide_core.chs=[interface_number.device_number]:cyls,heads,sects - -or:: - - ide_core.cdrom=[interface_number.device_number] - -For example:: - - ide_core.chs=1.0:1050,32,64 ide_core.cdrom=1.1 - -The results of successful auto-probing may override the physical geometry/irq -specified, though the "original" geometry may be retained as the "logical" -geometry for partitioning purposes (fdisk). - -If the auto-probing during boot time confuses a drive (ie. the drive works -with hd.c but not with ide.c), then an command line option may be specified -for each drive for which you'd like the drive to skip the hardware -probe/identification sequence. For example:: - - ide_core.noprobe=0.1 - -or:: - - ide_core.chs=1.0:768,16,32 - ide_core.noprobe=1.0 - -Note that when only one IDE device is attached to an interface, it should be -jumpered as "single" or "master", *not* "slave". Many folks have had -"trouble" with cdroms because of this requirement, so the driver now probes -for both units, though success is more likely when the drive is jumpered -correctly. - -Courtesy of Scott Snyder and others, the driver supports ATAPI cdrom drives -such as the NEC-260 and the new MITSUMI triple/quad speed drives. -Such drives will be identified at boot time, just like a hard disk. - -If for some reason your cdrom drive is *not* found at boot time, you can force -the probe to look harder by supplying a kernel command line parameter -via LILO, such as::: - - ide_core.cdrom=1.0 /* "master" on second interface (hdc) */ - -or:: - - ide_core.cdrom=1.1 /* "slave" on second interface (hdd) */ - -For example, a GW2000 system might have a hard drive on the primary -interface (/dev/hda) and an IDE cdrom drive on the secondary interface -(/dev/hdc). To mount a CD in the cdrom drive, one would use something like:: - - ln -sf /dev/hdc /dev/cdrom - mkdir /mnt/cdrom - mount /dev/cdrom /mnt/cdrom -t iso9660 -o ro - -If, after doing all of the above, mount doesn't work and you see -errors from the driver (with dmesg) complaining about `status=0xff`, -this means that the hardware is not responding to the driver's attempts -to read it. One of the following is probably the problem: - - - Your hardware is broken. - - - You are using the wrong address for the device, or you have the - drive jumpered wrong. Review the configuration instructions above. - - - Your IDE controller requires some nonstandard initialization sequence - before it will work properly. If this is the case, there will often - be a separate MS-DOS driver just for the controller. IDE interfaces - on sound cards usually fall into this category. Such configurations - can often be made to work by first booting MS-DOS, loading the - appropriate drivers, and then warm-booting linux (without powering - off). This can be automated using loadlin in the MS-DOS autoexec. - -If you always get timeout errors, interrupts from the drive are probably -not making it to the host. Check how you have the hardware jumpered -and make sure it matches what the driver expects (see the configuration -instructions above). If you have a PCI system, also check the BIOS -setup; I've had one report of a system which was shipped with IRQ 15 -disabled by the BIOS. - -The kernel is able to execute binaries directly off of the cdrom, -provided it is mounted with the default block size of 1024 (as above). - -Please pass on any feedback on any of this stuff to the maintainer, -whose address can be found in linux/MAINTAINERS. - -The IDE driver is modularized. The high level disk/CD-ROM/tape/floppy -drivers can always be compiled as loadable modules, the chipset drivers -can only be compiled into the kernel, and the core code (ide.c) can be -compiled as a loadable module provided no chipset support is needed. - -When using ide.c as a module in combination with kmod, add:: - - alias block-major-3 ide-probe - -to a configuration file in /etc/modprobe.d/. - -When ide.c is used as a module, you can pass command line parameters to the -driver using the "options=" keyword to insmod, while replacing any ',' with -';'. - - -Summary of ide driver parameters for kernel command line -======================================================== - -For legacy IDE VLB host drivers (ali14xx/dtc2278/ht6560b/qd65xx/umc8672) -you need to explicitly enable probing by using "probe" kernel parameter, -i.e. to enable probing for ALI M14xx chipsets (ali14xx host driver) use: - -* "ali14xx.probe" boot option when ali14xx driver is built-in the kernel - -* "probe" module parameter when ali14xx driver is compiled as module - ("modprobe ali14xx probe") - -Also for legacy CMD640 host driver (cmd640) you need to use "probe_vlb" -kernel paremeter to enable probing for VLB version of the chipset (PCI ones -are detected automatically). - -You also need to use "probe" kernel parameter for ide-4drives driver -(support for IDE generic chipset with four drives on one port). - -To enable support for IDE doublers on Amiga use "doubler" kernel parameter -for gayle host driver (i.e. "gayle.doubler" if the driver is built-in). - -To force ignoring cable detection (this should be needed only if you're using -short 40-wires cable which cannot be automatically detected - if this is not -a case please report it as a bug instead) use "ignore_cable" kernel parameter: - -* "ide_core.ignore_cable=[interface_number]" boot option if IDE is built-in - (i.e. "ide_core.ignore_cable=1" to force ignoring cable for "ide1") - -* "ignore_cable=[interface_number]" module parameter (for ide_core module) - if IDE is compiled as module - -Other kernel parameters for ide_core are: - -* "nodma=[interface_number.device_number]" to disallow DMA for a device - -* "noflush=[interface_number.device_number]" to disable flush requests - -* "nohpa=[interface_number.device_number]" to disable Host Protected Area - -* "noprobe=[interface_number.device_number]" to skip probing - -* "nowerr=[interface_number.device_number]" to ignore the WRERR_STAT bit - -* "cdrom=[interface_number.device_number]" to force device as a CD-ROM - -* "chs=[interface_number.device_number]" to force device as a disk (using CHS) - - -Some Terminology -================ - -IDE - Integrated Drive Electronics, meaning that each drive has a built-in - controller, which is why an "IDE interface card" is not a "controller card". - -ATA - AT (the old IBM 286 computer) Attachment Interface, a draft American - National Standard for connecting hard drives to PCs. This is the official - name for "IDE". - - The latest standards define some enhancements, known as the ATA-6 spec, - which grew out of vendor-specific "Enhanced IDE" (EIDE) implementations. - -ATAPI - ATA Packet Interface, a new protocol for controlling the drives, - similar to SCSI protocols, created at the same time as the ATA2 standard. - ATAPI is currently used for controlling CDROM, TAPE and FLOPPY (ZIP or - LS120/240) devices, removable R/W cartridges, and for high capacity hard disk - drives. - -mlord@pobox.com - - -Wed Apr 17 22:52:44 CEST 2002 edited by Marcin Dalecki, the current -maintainer. - -Wed Aug 20 22:31:29 CEST 2003 updated ide boot options to current ide.c -comments at 2.6.0-test4 time. Maciej Soltysiak diff --git a/Documentation/ide/index.rst b/Documentation/ide/index.rst deleted file mode 100644 index 813dfe611a31..000000000000 --- a/Documentation/ide/index.rst +++ /dev/null @@ -1,21 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -================================== -Integrated Drive Electronics (IDE) -================================== - -.. toctree:: - :maxdepth: 1 - - ide - ide-tape - warm-plug-howto - - changelogs - -.. only:: subproject and html - - Indices - ======= - - * :ref:`genindex` diff --git a/Documentation/ide/warm-plug-howto.rst b/Documentation/ide/warm-plug-howto.rst deleted file mode 100644 index c245242ef2f1..000000000000 --- a/Documentation/ide/warm-plug-howto.rst +++ /dev/null @@ -1,18 +0,0 @@ -=================== -IDE warm-plug HOWTO -=================== - -To warm-plug devices on a port 'idex':: - - # echo -n "1" > /sys/class/ide_port/idex/delete_devices - -unplug old device(s) and plug new device(s):: - - # echo -n "1" > /sys/class/ide_port/idex/scan - -done - -NOTE: please make sure that partitions are unmounted and that there are -no other active references to devices before doing "delete_devices" step, -also do not attempt "scan" step on devices currently in use -- otherwise -results may be unpredictable and lead to data loss if you're unlucky diff --git a/Documentation/index.rst b/Documentation/index.rst index 1988c19d9daf..6b7e45348558 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -103,7 +103,6 @@ needed). block/index cdrom/index cpu-freq/index - ide/index fb/index fpga/index hid/index -- cgit From c2fe645e5f147122646a0c2731255bf6c33ec2c0 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sun, 17 Apr 2022 18:14:50 -0700 Subject: rtla: Documentation: fix email addresses Correct lkml@vger to linux-kernel@vger. Add linux-trace-devel since that is what is in the MAINTAINERS file. Fixes: d40d48e1f1f2 ("rtla: Add Documentation") Signed-off-by: Randy Dunlap Acked-by: Daniel Bristot de Oliveira Cc: Steven Rostedt Signed-off-by: Jonathan Corbet --- Documentation/tools/rtla/common_appendix.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/tools/rtla/common_appendix.rst b/Documentation/tools/rtla/common_appendix.rst index b494084acccd..b5cf2dc223df 100644 --- a/Documentation/tools/rtla/common_appendix.rst +++ b/Documentation/tools/rtla/common_appendix.rst @@ -1,6 +1,7 @@ REPORTING BUGS ============== -Report bugs to +Report bugs to +and LICENSE ======= -- cgit From c20f80d0b89cf43be964797e6170f085b312ea01 Mon Sep 17 00:00:00 2001 From: Paul Kocialkowski Date: Fri, 15 Apr 2022 17:21:31 +0200 Subject: dt-bindings: sun6i-a31-mipi-dphy: Add optional direction property The Allwinner A31 MIPI D-PHY block supports both tx and rx directions, although each instance of the block is meant to be used in one direction only. There will typically be one instance for MIPI DSI and one for MIPI CSI-2 (it seems unlikely to ever see a shared instance). Describe the direction with a new allwinner,direction property. For backwards compatibility, the property is optional and tx mode should be assumed by default. Signed-off-by: Paul Kocialkowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220415152138.635525-2-paul.kocialkowski@bootlin.com Signed-off-by: Vinod Koul --- .../bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml index d0b541a461f3..22636c9fdab8 100644 --- a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml +++ b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml @@ -37,6 +37,18 @@ properties: resets: maxItems: 1 + allwinner,direction: + $ref: '/schemas/types.yaml#/definitions/string' + description: | + Direction of the D-PHY: + - "rx" for receiving (e.g. when used with MIPI CSI-2); + - "tx" for transmitting (e.g. when used with MIPI DSI). + + enum: + - tx + - rx + default: tx + required: - "#phy-cells" - compatible -- cgit From c6a4254c18c6a2195cdf01f58a362392fbe81e85 Mon Sep 17 00:00:00 2001 From: Nicolas Dichtel Date: Wed, 13 Apr 2022 16:00:00 +0200 Subject: doc/ip-sysctl: add bc_forwarding Let's describe this sysctl. Fixes: 5cbf777cfdf6 ("route: add support for directed broadcast forwarding") Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.rst | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index b0024aa7b051..66828293d9cb 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -267,6 +267,13 @@ ipfrag_max_dist - INTEGER from different IP datagrams, which could result in data corruption. Default: 64 +bc_forwarding - INTEGER + bc_forwarding enables the feature described in rfc1812#section-5.3.5.2 + and rfc2644. It allows the router to forward directed broadcast. + To enable this feature, the 'all' entry and the input interface entry + should be set to 1. + Default: 0 + INET peer storage ================= -- cgit From 6f2d04ccae9b9dc7884c641833823e50db8472fa Mon Sep 17 00:00:00 2001 From: Luiz Angelo Daros de Luca Date: Mon, 18 Apr 2022 20:35:57 -0300 Subject: dt-bindings: net: dsa: realtek: cleanup compatible strings MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Compatible strings are used to help the driver find the chip ID/version register for each chip family. After that, the driver can setup the switch accordingly. Keep only the first supported model for each family as a compatible string and reference other chip models in the description. The removed compatible strings have never been used in a released kernel. CC: devicetree@vger.kernel.org Link: https://lore.kernel.org/netdev/20220414014055.m4wbmr7tdz6hsa3m@bang-olufsen.dk/ Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Andrew Lunn Acked-by: Arınç ÜNAL Reviewed-by: Alvin Šipraga Signed-off-by: David S. Miller --- .../devicetree/bindings/net/dsa/realtek.yaml | 35 +++++++++------------- 1 file changed, 14 insertions(+), 21 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/realtek.yaml b/Documentation/devicetree/bindings/net/dsa/realtek.yaml index 8756060895a8..99ee4b5b9346 100644 --- a/Documentation/devicetree/bindings/net/dsa/realtek.yaml +++ b/Documentation/devicetree/bindings/net/dsa/realtek.yaml @@ -27,32 +27,25 @@ description: The realtek-mdio driver is an MDIO driver and it must be inserted inside an MDIO node. + The compatible string is only used to identify which (silicon) family the + switch belongs to. Roughly speaking, a family is any set of Realtek switches + whose chip identification register(s) have a common location and semantics. + The different models in a given family can be automatically disambiguated by + parsing the chip identification register(s) according to the given family, + avoiding the need for a unique compatible string for each model. + properties: compatible: enum: - realtek,rtl8365mb - - realtek,rtl8366 - realtek,rtl8366rb - - realtek,rtl8366s - - realtek,rtl8367 - - realtek,rtl8367b - - realtek,rtl8367rb - - realtek,rtl8367s - - realtek,rtl8368s - - realtek,rtl8369 - - realtek,rtl8370 description: | - realtek,rtl8365mb: 4+1 ports - realtek,rtl8366: 5+1 ports - realtek,rtl8366rb: 5+1 ports - realtek,rtl8366s: 5+1 ports - realtek,rtl8367: - realtek,rtl8367b: - realtek,rtl8367rb: 5+2 ports - realtek,rtl8367s: 5+2 ports - realtek,rtl8368s: 8 ports - realtek,rtl8369: 8+1 ports - realtek,rtl8370: 8+2 ports + realtek,rtl8365mb: + Use with models RTL8363NB, RTL8363NB-VB, RTL8363SC, RTL8363SC-VB, + RTL8364NB, RTL8364NB-VB, RTL8365MB, RTL8366SC, RTL8367RB-VB, RTL8367S, + RTL8367SB, RTL8370MB, RTL8310SR + realtek,rtl8366rb: + Use with models RTL8366RB, RTL8366S mdc-gpios: description: GPIO line for the MDC clock line. @@ -335,7 +328,7 @@ examples: #size-cells = <0>; switch@29 { - compatible = "realtek,rtl8367s"; + compatible = "realtek,rtl8365mb"; reg = <29>; reset-gpios = <&gpio2 20 GPIO_ACTIVE_LOW>; -- cgit From 766b540df8a374f75d7ad7084da026439c107825 Mon Sep 17 00:00:00 2001 From: Radhey Shyam Pandey Date: Thu, 14 Apr 2022 17:54:21 +0530 Subject: dt-bindings: dmaengine: xilinx_dma: Add MCMDA channel ID index description MCDMA IP provides up to 16 multiple channels of data movement each on MM2S and S2MM paths. Inline with implementation, in the binding add description for the channel ID start index and mention that it's fixed irrespective of the MCDMA IP configuration(number of read/write channels). Signed-off-by: Radhey Shyam Pandey Acked-by: Rob Herring Link: https://lore.kernel.org/r/1649939061-6675-1-git-send-email-radhey.shyam.pandey@xilinx.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt index 325aca52cd43..d1700a5c36bf 100644 --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt @@ -110,7 +110,11 @@ axi_vdma_0: axivdma@40030000 { Required properties: - dmas: a list of <[Video DMA device phandle] [Channel ID]> pairs, where Channel ID is '0' for write/tx and '1' for read/rx - channel. + channel. For MCMDA, MM2S channel(write/tx) ID start from + '0' and is in [0-15] range. S2MM channel(read/rx) ID start + from '16' and is in [16-31] range. These channels ID are + fixed irrespective of IP configuration. + - dma-names: a list of DMA channel names, one per "dmas" entry Example: -- cgit From 578245307f4afefd8da2ca66979d40b9ef517d67 Mon Sep 17 00:00:00 2001 From: Vinod Koul Date: Thu, 14 Apr 2022 12:12:16 +0530 Subject: dt-bindings: dmaengine: qcom: gpi: add compatible for sc7280 Document the compatible for GPI DMA controller on SC7280 SoC Signed-off-by: Vinod Koul Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220414064216.1182177-1-vkoul@kernel.org Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/qcom,gpi.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml index 67f046a4a442..8a790ffbdaac 100644 --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml @@ -19,6 +19,7 @@ allOf: properties: compatible: enum: + - qcom,sc7280-gpi-dma - qcom,sdm845-gpi-dma - qcom,sm8150-gpi-dma - qcom,sm8250-gpi-dma -- cgit From fc44ff0ae9f2aa20b64c4e63ab4614156df80240 Mon Sep 17 00:00:00 2001 From: Ben Walker Date: Tue, 1 Mar 2022 11:25:48 -0700 Subject: dmaengine: Document dmaengine_prep_dma_memset Document this function to make clear the expected behavior of the 'value' parameter. It was intended to match the behavior of POSIX memset as laid out here: https://lore.kernel.org/dmaengine/YejrA5ZWZ3lTRO%2F1@matsya/ Signed-off-by: Ben Walker Link: https://lore.kernel.org/r/20220301182551.883474-2-benjamin.walker@intel.com Signed-off-by: Vinod Koul --- Documentation/driver-api/dmaengine/provider.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst index d3fa80e333b1..1e0f1f85d10e 100644 --- a/Documentation/driver-api/dmaengine/provider.rst +++ b/Documentation/driver-api/dmaengine/provider.rst @@ -206,6 +206,12 @@ Currently, the types available are: - The device is able to perform parity check using RAID6 P+Q algorithm against a memory buffer. +- DMA_MEMSET + + - The device is able to fill memory with the provided pattern + + - The pattern is treated as a single byte signed value. + - DMA_INTERRUPT - The device is able to trigger a dummy transfer that will -- cgit From 69bb02ebc38ace438c9cd7c5315cfe43862b51fe Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Wed, 20 Apr 2022 13:21:12 +0100 Subject: arm64: Add HWCAP advertising FEAT_WFXT In order to allow userspace to enjoy WFET, add a new HWCAP that advertises it when available. Signed-off-by: Marc Zyngier Acked-by: Catalin Marinas Link: https://lore.kernel.org/r/20220419182755.601427-9-maz@kernel.org --- Documentation/arm64/cpu-feature-registers.rst | 2 ++ Documentation/arm64/elf_hwcaps.rst | 4 ++++ 2 files changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm64/cpu-feature-registers.rst b/Documentation/arm64/cpu-feature-registers.rst index 749ae970c319..04ba83e1965f 100644 --- a/Documentation/arm64/cpu-feature-registers.rst +++ b/Documentation/arm64/cpu-feature-registers.rst @@ -290,6 +290,8 @@ infrastructure: +------------------------------+---------+---------+ | RPRES | [7-4] | y | +------------------------------+---------+---------+ + | WFXT | [3-0] | y | + +------------------------------+---------+---------+ Appendix I: Example diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst index a8f30963e550..af3ab524e826 100644 --- a/Documentation/arm64/elf_hwcaps.rst +++ b/Documentation/arm64/elf_hwcaps.rst @@ -264,6 +264,10 @@ HWCAP2_MTE3 Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described by Documentation/arm64/memory-tagging-extension.rst. +HWCAP2_WFXT + + Functionality implied by ID_AA64ISAR2_EL1.WFXT == 0b0010. + 4. Unused AT_HWCAP bits ----------------------- -- cgit From 7495a5bbf89f68c8880757c112fd0994f5dba309 Mon Sep 17 00:00:00 2001 From: Vinod Koul Date: Thu, 14 Apr 2022 12:12:35 +0530 Subject: dt-bindings: dmaengine: qcom: gpi: Add minItems for interrupts Add the minItems for interrupts property as well. In the absence of this, we get warning if interrupts are less than 13 arch/arm64/boot/dts/qcom/qrb5165-rb5.dtb: dma-controller@800000: interrupts: [[0, 588, 4], [0, 589, 4], [0, 590, 4], [0, 591, 4], [0, 592, 4], [0, 593, 4], [0, 594, 4], [0, 595, 4], [0, 596, 4], [0, 597, 4]] is too short Signed-off-by: Vinod Koul Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220414064235.1182195-1-vkoul@kernel.org Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/qcom,gpi.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml index e614fe3187bb..d09d79d7406a 100644 --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml @@ -29,6 +29,7 @@ properties: interrupts: description: Interrupt lines for each GPI instance + minItems: 1 maxItems: 13 "#dma-cells": -- cgit From 2a72b1b2db9dbe12c730754009196a132500f007 Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Tue, 19 Apr 2022 09:43:02 +0200 Subject: Documentation: fix tty link The commit below causes the following warnings: Documentation/driver-api/index.rst:14: WARNING: toctree contains reference to nonexisting document 'driver-api/tty' Documentation/driver-api/tty/index.rst: WARNING: document isn't included in any toctree This is because I omitted the "/index" part from the link. That part is needed for directories and I was confused by the surrounding links which are links to files. Fix it in this patch. Fixes: b96cd8b05ead ("Documentation: move tty to driver-api") Cc: Jonathan Corbet Reported-by: Stephen Rothwell Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20220419074302.29632-1-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index bbbbcf20b7ce..d76a60d95b58 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -101,7 +101,7 @@ available subsections can be seen below. surface_aggregator/index switchtec sync_file - tty + tty/index vfio-mediated-device vfio vfio-pci-device-specific-driver-acceptance -- cgit From 36bf0611600dd3187fe478833ba804e7976fcae5 Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas Date: Tue, 19 Apr 2022 23:48:19 +0200 Subject: dt-bindings: display: ssd1307fb: Deprecate "-i2c" compatible strings The current compatible strings for SSD130x I2C controllers contain both an "fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver and also that are for devices that can be accessed over an I2C bus. But a DT is supposed to describe the hardware and not Linux implementation details. So let's deprecate those compatible strings and add new ones that only contain the vendor and device name, without any of these suffixes. These will just describe the device and can be matched by both I2C and SPI DRM drivers. The required properties should still be enforced for old ones. While being there, just drop the "sinowealth,sh1106-i2c" compatible string since that was never present in a released Linux version. Signed-off-by: Javier Martinez Canillas Acked-by: Mark Brown Reviewed-by: Geert Uytterhoeven Reviewed-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-2-javierm@redhat.com --- .../bindings/display/solomon,ssd1307fb.yaml | 44 +++++++++++++++------- 1 file changed, 31 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index ade61d502edd..7653b6c3fcb6 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -12,12 +12,22 @@ maintainers: properties: compatible: - enum: - - sinowealth,sh1106-i2c - - solomon,ssd1305fb-i2c - - solomon,ssd1306fb-i2c - - solomon,ssd1307fb-i2c - - solomon,ssd1309fb-i2c + oneOf: + # Deprecated compatible strings + - items: + - enum: + - solomon,ssd1305fb-i2c + - solomon,ssd1306fb-i2c + - solomon,ssd1307fb-i2c + - solomon,ssd1309fb-i2c + deprecated: true + - items: + - enum: + - sinowealth,sh1106 + - solomon,ssd1305 + - solomon,ssd1306 + - solomon,ssd1307 + - solomon,ssd1309 reg: maxItems: 1 @@ -136,7 +146,7 @@ allOf: properties: compatible: contains: - const: sinowealth,sh1106-i2c + const: sinowealth,sh1106 then: properties: solomon,dclk-div: @@ -148,7 +158,9 @@ allOf: properties: compatible: contains: - const: solomon,ssd1305fb-i2c + enum: + - solomon,ssd1305-i2c + - solomon,ssd1305 then: properties: solomon,dclk-div: @@ -160,7 +172,9 @@ allOf: properties: compatible: contains: - const: solomon,ssd1306fb-i2c + enum: + - solomon,ssd1306-i2c + - solomon,ssd1306 then: properties: solomon,dclk-div: @@ -172,7 +186,9 @@ allOf: properties: compatible: contains: - const: solomon,ssd1307fb-i2c + enum: + - solomon,ssd1307-i2c + - solomon,ssd1307 then: properties: solomon,dclk-div: @@ -186,7 +202,9 @@ allOf: properties: compatible: contains: - const: solomon,ssd1309fb-i2c + enum: + - solomon,ssd1309-i2c + - solomon,ssd1309 then: properties: solomon,dclk-div: @@ -203,14 +221,14 @@ examples: #size-cells = <0>; ssd1307: oled@3c { - compatible = "solomon,ssd1307fb-i2c"; + compatible = "solomon,ssd1307"; reg = <0x3c>; pwms = <&pwm 4 3000>; reset-gpios = <&gpio2 7>; }; ssd1306: oled@3d { - compatible = "solomon,ssd1306fb-i2c"; + compatible = "solomon,ssd1306"; reg = <0x3c>; pwms = <&pwm 4 3000>; reset-gpios = <&gpio2 7>; -- cgit From 1b6a7961908882b65def0bd2cffba3f2eba44226 Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas Date: Tue, 19 Apr 2022 23:48:20 +0200 Subject: dt-bindings: display: ssd1307fb: Extend schema for SPI controllers The Solomon SSD130x OLED displays can either have an I2C or SPI interface, add to the schema the properties and examples for OLED devices under SPI. Signed-off-by: Javier Martinez Canillas Acked-by: Mark Brown Reviewed-by: Geert Uytterhoeven Reviewed-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-3-javierm@redhat.com --- .../bindings/display/solomon,ssd1307fb.yaml | 42 ++++++++++++++++++++-- 1 file changed, 40 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index 7653b6c3fcb6..3fbd87c2c120 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -38,9 +38,20 @@ properties: reset-gpios: maxItems: 1 + # Only required for SPI + dc-gpios: + description: + GPIO connected to the controller's D/C# (Data/Command) pin, + that is needed for 4-wire SPI to tell the controller if the + data sent is for a command register or the display data RAM + maxItems: 1 + vbat-supply: description: The supply for VBAT + # Only required for SPI + spi-max-frequency: true + solomon,height: $ref: /schemas/types.yaml#/definitions/uint32 default: 16 @@ -220,14 +231,14 @@ examples: #address-cells = <1>; #size-cells = <0>; - ssd1307: oled@3c { + ssd1307_i2c: oled@3c { compatible = "solomon,ssd1307"; reg = <0x3c>; pwms = <&pwm 4 3000>; reset-gpios = <&gpio2 7>; }; - ssd1306: oled@3d { + ssd1306_i2c: oled@3d { compatible = "solomon,ssd1306"; reg = <0x3c>; pwms = <&pwm 4 3000>; @@ -238,3 +249,30 @@ examples: solomon,lookup-table = /bits/ 8 <0x3f 0x3f 0x3f 0x3f>; }; }; + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + ssd1307_spi: oled@0 { + compatible = "solomon,ssd1307"; + reg = <0x0>; + pwms = <&pwm 4 3000>; + reset-gpios = <&gpio2 7>; + dc-gpios = <&gpio2 8>; + spi-max-frequency = <10000000>; + }; + + ssd1306_spi: oled@1 { + compatible = "solomon,ssd1306"; + reg = <0x1>; + pwms = <&pwm 4 3000>; + reset-gpios = <&gpio2 7>; + dc-gpios = <&gpio2 8>; + spi-max-frequency = <10000000>; + solomon,com-lrremap; + solomon,com-invdir; + solomon,com-offset = <32>; + solomon,lookup-table = /bits/ 8 <0x3f 0x3f 0x3f 0x3f>; + }; + }; -- cgit From 930e2607638de8325686319b2789323cc85ea671 Mon Sep 17 00:00:00 2001 From: Jaegeuk Kim Date: Tue, 12 Apr 2022 14:45:50 -0700 Subject: f2fs: remove obsolete whint_mode This patch removes obsolete whint_mode. Fixes: 41d36a9f3e53 ("fs: remove kiocb.ki_hint") Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/filesystems/f2fs.rst | 70 -------------------------------------- 1 file changed, 70 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index 4a2426f0485a..ad8dc8c040a2 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -235,12 +235,6 @@ offgrpjquota Turn off group journalled quota. offprjjquota Turn off project journalled quota. quota Enable plain user disk quota accounting. noquota Disable all plain disk quota option. -whint_mode=%s Control which write hints are passed down to block - layer. This supports "off", "user-based", and - "fs-based". In "off" mode (default), f2fs does not pass - down hints. In "user-based" mode, f2fs tries to pass - down hints given by users. And in "fs-based" mode, f2fs - passes down hints with its policy. alloc_mode=%s Adjust block allocation policy, which supports "reuse" and "default". fsync_mode=%s Control the policy of fsync. Currently supports "posix", @@ -751,70 +745,6 @@ In order to identify whether the data in the victim segment are valid or not, F2FS manages a bitmap. Each bit represents the validity of a block, and the bitmap is composed of a bit stream covering whole blocks in main area. -Write-hint Policy ------------------ - -1) whint_mode=off. F2FS only passes down WRITE_LIFE_NOT_SET. - -2) whint_mode=user-based. F2FS tries to pass down hints given by -users. - -===================== ======================== =================== -User F2FS Block -===================== ======================== =================== -N/A META WRITE_LIFE_NOT_SET -N/A HOT_NODE " -N/A WARM_NODE " -N/A COLD_NODE " -ioctl(COLD) COLD_DATA WRITE_LIFE_EXTREME -extension list " " - --- buffered io -WRITE_LIFE_EXTREME COLD_DATA WRITE_LIFE_EXTREME -WRITE_LIFE_SHORT HOT_DATA WRITE_LIFE_SHORT -WRITE_LIFE_NOT_SET WARM_DATA WRITE_LIFE_NOT_SET -WRITE_LIFE_NONE " " -WRITE_LIFE_MEDIUM " " -WRITE_LIFE_LONG " " - --- direct io -WRITE_LIFE_EXTREME COLD_DATA WRITE_LIFE_EXTREME -WRITE_LIFE_SHORT HOT_DATA WRITE_LIFE_SHORT -WRITE_LIFE_NOT_SET WARM_DATA WRITE_LIFE_NOT_SET -WRITE_LIFE_NONE " WRITE_LIFE_NONE -WRITE_LIFE_MEDIUM " WRITE_LIFE_MEDIUM -WRITE_LIFE_LONG " WRITE_LIFE_LONG -===================== ======================== =================== - -3) whint_mode=fs-based. F2FS passes down hints with its policy. - -===================== ======================== =================== -User F2FS Block -===================== ======================== =================== -N/A META WRITE_LIFE_MEDIUM; -N/A HOT_NODE WRITE_LIFE_NOT_SET -N/A WARM_NODE " -N/A COLD_NODE WRITE_LIFE_NONE -ioctl(COLD) COLD_DATA WRITE_LIFE_EXTREME -extension list " " - --- buffered io -WRITE_LIFE_EXTREME COLD_DATA WRITE_LIFE_EXTREME -WRITE_LIFE_SHORT HOT_DATA WRITE_LIFE_SHORT -WRITE_LIFE_NOT_SET WARM_DATA WRITE_LIFE_LONG -WRITE_LIFE_NONE " " -WRITE_LIFE_MEDIUM " " -WRITE_LIFE_LONG " " - --- direct io -WRITE_LIFE_EXTREME COLD_DATA WRITE_LIFE_EXTREME -WRITE_LIFE_SHORT HOT_DATA WRITE_LIFE_SHORT -WRITE_LIFE_NOT_SET WARM_DATA WRITE_LIFE_NOT_SET -WRITE_LIFE_NONE " WRITE_LIFE_NONE -WRITE_LIFE_MEDIUM " WRITE_LIFE_MEDIUM -WRITE_LIFE_LONG " WRITE_LIFE_LONG -===================== ======================== =================== - Fallocate(2) Policy ------------------- -- cgit From 6172de3c7f1171e55314bfc5ee4ae6edd225b048 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Thu, 17 Feb 2022 12:26:00 -0800 Subject: docs: Add documentation for rude and trace RCU flavors This commit belatedly adds documentation of Tasks Rude RCU and Tasks Trace RCU to RCU's requirements document. Tested-by: Bagas Sanjaya Reviewed-by: Steven Rostedt (Google) Signed-off-by: Paul E. McKenney --- .../RCU/Design/Requirements/Requirements.rst | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'Documentation') diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index 45278e2974c0..ff2be1ac54c4 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -2654,6 +2654,38 @@ synchronize_rcu(), and rcu_barrier(), respectively. In three APIs are therefore implemented by separate functions that check for voluntary context switches. +Tasks Rude RCU +~~~~~~~~~~~~~~ + +Some forms of tracing need to wait for all preemption-disabled regions +of code running on any online CPU, including those executed when RCU is +not watching. This means that synchronize_rcu() is insufficient, and +Tasks Rude RCU must be used instead. This flavor of RCU does its work by +forcing a workqueue to be scheduled on each online CPU, hence the "Rude" +moniker. And this operation is considered to be quite rude by real-time +workloads that don't want their ``nohz_full`` CPUs receiving IPIs and +by battery-powered systems that don't want their idle CPUs to be awakened. + +The tasks-rude-RCU API is also reader-marking-free and thus quite compact, +consisting of call_rcu_tasks_rude(), synchronize_rcu_tasks_rude(), +and rcu_barrier_tasks_rude(). + +Tasks Trace RCU +~~~~~~~~~~~~~~~ + +Some forms of tracing need to sleep in readers, but cannot tolerate +SRCU's read-side overhead, which includes a full memory barrier in both +srcu_read_lock() and srcu_read_unlock(). This need is handled by a +Tasks Trace RCU that uses scheduler locking and IPIs to synchronize with +readers. Real-time systems that cannot tolerate IPIs may build their +kernels with ``CONFIG_TASKS_TRACE_RCU_READ_MB=y``, which avoids the IPIs at +the expense of adding full memory barriers to the read-side primitives. + +The tasks-trace-RCU API is also reasonably compact, +consisting of rcu_read_lock_trace(), rcu_read_unlock_trace(), +rcu_read_lock_trace_held(), call_rcu_tasks_trace(), +synchronize_rcu_tasks_trace(), and rcu_barrier_tasks_trace(). + Possible Future Changes ----------------------- -- cgit From 404147faaaf28319ba8e60392ba9d4f3b6055ad5 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Wed, 30 Mar 2022 23:41:00 +0900 Subject: docs: Update RCU cross-references as suggested in doc-guide The RCU documentation contains old-style cross references which do not follow the best practices outlined in doc-guide/sphinx.rst. In addition, some of the cross references use URLs that should be replaced by pathnames. Update all of these cross references and adjust the surrounding words. Summary of changes: - out-of-date plaintext file names (*.txt) -> *.rst - references by :ref: tags -> path names of *.rst * use relative paths to .rst files under the RCU/ subdirectory * use abs paths of Documentation/xxx for other .rst files - references by URL under https://www.kernel.org/ -> paths of *.rst - adjust surrounding words of some of updated references. Note: The automarkup.py script interprets references via "*.txt" as if they were via "*.rst", so the *.txt -> *.rst changes should be regarded as cleanups rather than bug fixes. Cc: rcu@vger.kernel.org Cc: linux-doc@vger.kernel.org Tested-by: Bagas Sanjaya Reviewed-by: Steven Rostedt (Google) Signed-off-by: Akira Yokosawa Signed-off-by: Paul E. McKenney --- .../RCU/Design/Data-Structures/Data-Structures.rst | 2 +- .../Expedited-Grace-Periods.rst | 2 +- Documentation/RCU/Design/Requirements/Requirements.rst | 4 ++-- Documentation/RCU/arrayRCU.rst | 4 ++-- Documentation/RCU/checklist.rst | 9 ++++----- Documentation/RCU/rcu.rst | 13 ++++++------- Documentation/RCU/rculist_nulls.rst | 2 +- Documentation/RCU/whatisRCU.rst | 18 ++++++++---------- 8 files changed, 25 insertions(+), 29 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RCU/Design/Data-Structures/Data-Structures.rst b/Documentation/RCU/Design/Data-Structures/Data-Structures.rst index f4efd6897b09..b34990c7c377 100644 --- a/Documentation/RCU/Design/Data-Structures/Data-Structures.rst +++ b/Documentation/RCU/Design/Data-Structures/Data-Structures.rst @@ -973,7 +973,7 @@ The ``->dynticks`` field counts the corresponding CPU's transitions to and from either dyntick-idle or user mode, so that this counter has an even value when the CPU is in dyntick-idle mode or user mode and an odd value otherwise. The transitions to/from user mode need to be counted -for user mode adaptive-ticks support (see timers/NO_HZ.txt). +for user mode adaptive-ticks support (see Documentation/timers/no_hz.rst). The ``->rcu_need_heavy_qs`` field is used to record the fact that the RCU core code would really like to see a quiescent state from the diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst index 6f89cf1e567d..c9c957c85bac 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst @@ -406,7 +406,7 @@ In earlier implementations, the task requesting the expedited grace period also drove it to completion. This straightforward approach had the disadvantage of needing to account for POSIX signals sent to user tasks, so more recent implemementations use the Linux kernel's -`workqueues `__. +workqueues (see Documentation/core-api/workqueue.rst). The requesting task still does counter snapshotting and funnel-lock processing, but the task reaching the top of the funnel lock does a diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index ff2be1ac54c4..04ed8bf27a0e 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -370,8 +370,8 @@ pointer fetched by rcu_dereference() may not be used outside of the outermost RCU read-side critical section containing that rcu_dereference(), unless protection of the corresponding data element has been passed from RCU to some other synchronization -mechanism, most commonly locking or `reference -counting `__. +mechanism, most commonly locking or reference counting +(see ../../rcuref.rst). .. |high-quality implementation of C11 memory_order_consume [PDF]| replace:: high-quality implementation of C11 ``memory_order_consume`` [PDF] .. _high-quality implementation of C11 memory_order_consume [PDF]: http://www.rdrop.com/users/paulmck/RCU/consume.2015.07.13a.pdf diff --git a/Documentation/RCU/arrayRCU.rst b/Documentation/RCU/arrayRCU.rst index 4051ea3871ef..a5f2ff8fc54c 100644 --- a/Documentation/RCU/arrayRCU.rst +++ b/Documentation/RCU/arrayRCU.rst @@ -33,8 +33,8 @@ Situation 1: Hash Tables Hash tables are often implemented as an array, where each array entry has a linked-list hash chain. Each hash chain can be protected by RCU -as described in the listRCU.txt document. This approach also applies -to other array-of-list situations, such as radix trees. +as described in listRCU.rst. This approach also applies to other +array-of-list situations, such as radix trees. .. _static_arrays: diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index f4545b7c9a63..42cc5d891bd2 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -140,8 +140,7 @@ over a rather long period of time, but improvements are always welcome! prevents destructive compiler optimizations. However, with a bit of devious creativity, it is possible to mishandle the return value from rcu_dereference(). - Please see rcu_dereference.txt in this directory for - more information. + Please see rcu_dereference.rst for more information. The rcu_dereference() primitive is used by the various "_rcu()" list-traversal primitives, such @@ -151,7 +150,7 @@ over a rather long period of time, but improvements are always welcome! primitives. This is particularly useful in code that is common to readers and updaters. However, lockdep will complain if you access rcu_dereference() outside - of an RCU read-side critical section. See lockdep.txt + of an RCU read-side critical section. See lockdep.rst to learn what to do about this. Of course, neither rcu_dereference() nor the "_rcu()" @@ -323,7 +322,7 @@ over a rather long period of time, but improvements are always welcome! primitives when the update-side lock is held is that doing so can be quite helpful in reducing code bloat when common code is shared between readers and updaters. Additional primitives - are provided for this case, as discussed in lockdep.txt. + are provided for this case, as discussed in lockdep.rst. One exception to this rule is when data is only ever added to the linked data structure, and is never removed during any @@ -480,4 +479,4 @@ over a rather long period of time, but improvements are always welcome! both rcu_barrier() and synchronize_rcu(), if necessary, using something like workqueues to to execute them concurrently. - See rcubarrier.txt for more information. + See rcubarrier.rst for more information. diff --git a/Documentation/RCU/rcu.rst b/Documentation/RCU/rcu.rst index 0e03c6ef3147..3cfe01ba9a49 100644 --- a/Documentation/RCU/rcu.rst +++ b/Documentation/RCU/rcu.rst @@ -10,9 +10,8 @@ A "grace period" must elapse between the two parts, and this grace period must be long enough that any readers accessing the item being deleted have since dropped their references. For example, an RCU-protected deletion from a linked list would first remove the item from the list, wait for -a grace period to elapse, then free the element. See the -:ref:`Documentation/RCU/listRCU.rst ` for more information on -using RCU with linked lists. +a grace period to elapse, then free the element. See listRCU.rst for more +information on using RCU with linked lists. Frequently Asked Questions -------------------------- @@ -50,7 +49,7 @@ Frequently Asked Questions - If I am running on a uniprocessor kernel, which can only do one thing at a time, why should I wait for a grace period? - See :ref:`Documentation/RCU/UP.rst ` for more information. + See UP.rst for more information. - How can I see where RCU is currently used in the Linux kernel? @@ -64,13 +63,13 @@ Frequently Asked Questions - What guidelines should I follow when writing code that uses RCU? - See the checklist.txt file in this directory. + See checklist.rst. - Why the name "RCU"? "RCU" stands for "read-copy update". - :ref:`Documentation/RCU/listRCU.rst ` has more information on where - this name came from, search for "read-copy update" to find it. + listRCU.rst has more information on where this name came from, search + for "read-copy update" to find it. - I hear that RCU is patented? What is with that? diff --git a/Documentation/RCU/rculist_nulls.rst b/Documentation/RCU/rculist_nulls.rst index a9fc774bc400..ca4692775ad4 100644 --- a/Documentation/RCU/rculist_nulls.rst +++ b/Documentation/RCU/rculist_nulls.rst @@ -8,7 +8,7 @@ This section describes how to use hlist_nulls to protect read-mostly linked lists and objects using SLAB_TYPESAFE_BY_RCU allocations. -Please read the basics in Documentation/RCU/listRCU.rst +Please read the basics in listRCU.rst. Using 'nulls' ============= diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst index c34d2212eaca..77ea260efd12 100644 --- a/Documentation/RCU/whatisRCU.rst +++ b/Documentation/RCU/whatisRCU.rst @@ -224,7 +224,7 @@ synchronize_rcu() be delayed. This property results in system resilience in face of denial-of-service attacks. Code using call_rcu() should limit update rate in order to gain this same sort of resilience. See - checklist.txt for some approaches to limiting the update rate. + checklist.rst for some approaches to limiting the update rate. rcu_assign_pointer() ^^^^^^^^^^^^^^^^^^^^ @@ -318,7 +318,7 @@ rcu_dereference() must prohibit. The rcu_dereference_protected() variant takes a lockdep expression to indicate which locks must be acquired by the caller. If the indicated protection is not provided, - a lockdep splat is emitted. See Documentation/RCU/Design/Requirements/Requirements.rst + a lockdep splat is emitted. See Design/Requirements/Requirements.rst and the API's code comments for more details and example usage. .. [2] If the list_for_each_entry_rcu() instance might be used by @@ -399,8 +399,7 @@ for specialized uses, but are relatively uncommon. This section shows a simple use of the core RCU API to protect a global pointer to a dynamically allocated structure. More-typical -uses of RCU may be found in :ref:`listRCU.rst `, -:ref:`arrayRCU.rst `, and :ref:`NMI-RCU.rst `. +uses of RCU may be found in listRCU.rst, arrayRCU.rst, and NMI-RCU.rst. :: struct foo { @@ -482,10 +481,9 @@ So, to sum up: RCU read-side critical sections that might be referencing that data item. -See checklist.txt for additional rules to follow when using RCU. -And again, more-typical uses of RCU may be found in :ref:`listRCU.rst -`, :ref:`arrayRCU.rst `, and :ref:`NMI-RCU.rst -`. +See checklist.rst for additional rules to follow when using RCU. +And again, more-typical uses of RCU may be found in listRCU.rst, +arrayRCU.rst, and NMI-RCU.rst. .. _4_whatisRCU: @@ -579,7 +577,7 @@ to avoid having to write your own callback:: kfree_rcu(old_fp, rcu); -Again, see checklist.txt for additional rules governing the use of RCU. +Again, see checklist.rst for additional rules governing the use of RCU. .. _5_whatisRCU: @@ -663,7 +661,7 @@ been able to write-acquire the lock otherwise. The smp_mb__after_spinlock() promotes synchronize_rcu() to a full memory barrier in compliance with the "Memory-Barrier Guarantees" listed in: - Documentation/RCU/Design/Requirements/Requirements.rst + Design/Requirements/Requirements.rst It is possible to nest rcu_read_lock(), since reader-writer locks may be recursively acquired. Note also that rcu_read_lock() is immune -- cgit From ae4303886652248ed2568c9cb2ab0da485bfd7a7 Mon Sep 17 00:00:00 2001 From: Damien Le Moal Date: Mon, 18 Apr 2022 09:06:17 +0900 Subject: documentation: zonefs: Cleanup the mount options section Use subsections to separate the descriptions of the "error=" and "explicit-open" mount sections. Signed-off-by: Damien Le Moal Reviewed-by: Johannes Thumshirn Reviewed-by: Hans Holmberg --- Documentation/filesystems/zonefs.rst | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/zonefs.rst b/Documentation/filesystems/zonefs.rst index 6b213fe9a33e..72d4baba0b6a 100644 --- a/Documentation/filesystems/zonefs.rst +++ b/Documentation/filesystems/zonefs.rst @@ -306,8 +306,15 @@ Further notes: Mount options ------------- -zonefs define the "errors=" mount option to allow the user to specify -zonefs behavior in response to I/O errors, inode size inconsistencies or zone +zonefs defines several mount options: +* errors= +* explicit-open + +"errors=" option +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The "errors=" option mount option allows the user to specify zonefs +behavior in response to I/O errors, inode size inconsistencies or zone condition changes. The defined behaviors are as follow: * remount-ro (default) @@ -326,6 +333,9 @@ discover the amount of data that has been written to the zone. In the case of a read-only zone discovered at run-time, as indicated in the previous section. The size of the zone file is left unchanged from its last updated value. +"explicit-open" option +~~~~~~~~~~~~~~~~~~~~~~ + A zoned block device (e.g. an NVMe Zoned Namespace device) may have limits on the number of zones that can be active, that is, zones that are in the implicit open, explicit open or closed conditions. This potential limitation -- cgit From 3791a22374715b36ad806db13d8b2afb1b57fd36 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Mon, 28 Feb 2022 18:08:33 -0800 Subject: kernel/smp: Provide boot-time timeout for CSD lock diagnostics Debugging of problems involving insanely long-running SMI handlers proceeds better if the CSD-lock timeout can be adjusted. This commit therefore provides a new smp.csd_lock_timeout kernel boot parameter that specifies the timeout in milliseconds. The default remains at the previously hard-coded value of five seconds. [ paulmck: Apply feedback from Juergen Gross. ] Cc: Rik van Riel Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Sebastian Andrzej Siewior Reviewed-by: Juergen Gross Signed-off-by: Paul E. McKenney --- Documentation/admin-guide/kernel-parameters.txt | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 3f1cc5e317ed..645c4c001b16 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5377,6 +5377,17 @@ smart2= [HW] Format: [,[,...,]] + smp.csd_lock_timeout= [KNL] + Specify the period of time in milliseconds + that smp_call_function() and friends will wait + for a CPU to release the CSD lock. This is + useful when diagnosing bugs involving CPUs + disabling interrupts for extended periods + of time. Defaults to 5,000 milliseconds, and + setting a value of zero disables this feature. + This feature may be more efficiently disabled + using the csdlock_debug- kernel parameter. + smsc-ircc2.nopnp [HW] Don't use PNP to discover SMC devices smsc-ircc2.ircc_cfg= [HW] Device configuration I/O port smsc-ircc2.ircc_sir= [HW] SIR base I/O port -- cgit From 0f1f7a6661394fe4a53db254c346d6aa2dd64397 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 21 Apr 2022 08:41:00 +0200 Subject: ALSA: usb-audio: Add quirk bits for enabling/disabling generic implicit fb For making easier to test, add the new quirk_flags bits 17 and 18 to enable and disable the generic implicit feedback mode. The bit 17 is equivalent with implicit_fb=1 option, applying the generic implicit feedback sync mode. OTOH, the bit 18 disables the implicit fb mode forcibly. Link: https://lore.kernel.org/r/20220421064101.12456-1-tiwai@suse.de Signed-off-by: Takashi Iwai --- Documentation/sound/alsa-configuration.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst index 34888d4fc4a8..21ab5e6f7062 100644 --- a/Documentation/sound/alsa-configuration.rst +++ b/Documentation/sound/alsa-configuration.rst @@ -2246,7 +2246,7 @@ implicit_fb Apply the generic implicit feedback sync mode. When this is set and the playback stream sync mode is ASYNC, the driver tries to tie an adjacent ASYNC capture stream as the implicit feedback - source. + source. This is equivalent with quirk_flags bit 17. use_vmalloc Use vmalloc() for allocations of the PCM buffers (default: yes). For architectures with non-coherent memory like ARM or MIPS, the @@ -2288,6 +2288,8 @@ quirk_flags * bit 14: Ignore errors for mixer access * bit 15: Support generic DSD raw U32_BE format * bit 16: Set up the interface at first like UAC1 + * bit 17: Apply the generic implicit feedback sync mode + * bit 18: Don't apply implicit feedback sync mode This module supports multiple devices, autoprobe and hotplugging. -- cgit From bcfcc0a61debc152788a83dc7afaeda2445677e4 Mon Sep 17 00:00:00 2001 From: Jayesh Choudhary Date: Tue, 12 Apr 2022 13:00:15 +0530 Subject: dt-bindings: crypto: ti,sa2ul: Add a new compatible for AM62 Add the AM62 version of sa3ul to the compatible list. Signed-off-by: Jayesh Choudhary Acked-by: Krzysztof Kozlowski Signed-off-by: Herbert Xu --- Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml index a410d2cedde6..02f47c2e7998 100644 --- a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml +++ b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml @@ -15,6 +15,7 @@ properties: - ti,j721e-sa2ul - ti,am654-sa2ul - ti,am64-sa2ul + - ti,am62-sa3ul reg: maxItems: 1 -- cgit From 6c7f98b334a32df5cac8abac8983ac4ce17cab57 Mon Sep 17 00:00:00 2001 From: Jason Gunthorpe Date: Mon, 11 Apr 2022 16:13:59 +0200 Subject: vfio/mdev: Remove vfio_mdev.c Now that all mdev drivers directly create their own mdev_device driver and directly register with the vfio core's vfio_device_ops this is all dead code. Delete vfio_mdev.c and the mdev_parent_ops members that are connected to it. Signed-off-by: Jason Gunthorpe Signed-off-by: Christoph Hellwig Signed-off-by: Zhi Wang Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-31-hch@lst.de Reviewed-by: Kirti Wankhede Reviewed-by: Zhi Wang --- Documentation/driver-api/vfio-mediated-device.rst | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst index 9f26079cacae..5a6e18a651a1 100644 --- a/Documentation/driver-api/vfio-mediated-device.rst +++ b/Documentation/driver-api/vfio-mediated-device.rst @@ -138,9 +138,6 @@ The structures in the mdev_parent_ops structure are as follows: * supported_config: attributes to define supported configurations * device_driver: device driver to bind for mediated device instances -The mdev_parent_ops also still has various functions pointers. Theses exist -for historical reasons only and shall not be used for new drivers. - When a driver wants to add the GUID creation sysfs to an existing device it has probe'd to then it should call:: -- cgit From 6b42f491e17ce13f5ff7f2d1f49c73a0f4c47b20 Mon Sep 17 00:00:00 2001 From: Jason Gunthorpe Date: Mon, 11 Apr 2022 16:14:01 +0200 Subject: vfio/mdev: Remove mdev_parent_ops The last useful member in this struct is the supported_type_groups, move it to the mdev_driver and delete mdev_parent_ops. Replace it with mdev_driver as an argument to mdev_register_device() Signed-off-by: Jason Gunthorpe Signed-off-by: Christoph Hellwig Signed-off-by: Zhi Wang Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-33-hch@lst.de Reviewed-by: Kirti Wankhede Reviewed-by: Zhi Wang --- Documentation/driver-api/vfio-mediated-device.rst | 24 +++++------------------ 1 file changed, 5 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst index 5a6e18a651a1..784bbeb22adc 100644 --- a/Documentation/driver-api/vfio-mediated-device.rst +++ b/Documentation/driver-api/vfio-mediated-device.rst @@ -105,6 +105,7 @@ structure to represent a mediated device's driver:: struct mdev_driver { int (*probe) (struct mdev_device *dev); void (*remove) (struct mdev_device *dev); + struct attribute_group **supported_type_groups; struct device_driver driver; }; @@ -119,30 +120,15 @@ to register and unregister itself with the core driver: extern void mdev_unregister_driver(struct mdev_driver *drv); -The mediated bus driver is responsible for adding mediated devices to the VFIO -group when devices are bound to the driver and removing mediated devices from -the VFIO when devices are unbound from the driver. - - -Physical Device Driver Interface --------------------------------- - -The physical device driver interface provides the mdev_parent_ops[3] structure -to define the APIs to manage work in the mediated core driver that is related -to the physical device. - -The structures in the mdev_parent_ops structure are as follows: - -* dev_attr_groups: attributes of the parent device -* mdev_attr_groups: attributes of the mediated device -* supported_config: attributes to define supported configurations -* device_driver: device driver to bind for mediated device instances +The mediated bus driver's probe function should create a vfio_device on top of +the mdev_device and connect it to an appropriate implementation of +vfio_device_ops. When a driver wants to add the GUID creation sysfs to an existing device it has probe'd to then it should call:: extern int mdev_register_device(struct device *dev, - const struct mdev_parent_ops *ops); + struct mdev_driver *mdev_driver); This will provide the 'mdev_supported_types/XX/create' files which can then be used to trigger the creation of a mdev_device. The created mdev_device will be -- cgit From 2d71025ec454b7a3e9a7f00cb506efca24fd1963 Mon Sep 17 00:00:00 2001 From: Rohit Agarwal Date: Mon, 4 Apr 2022 10:34:09 +0530 Subject: dt-bindings: pinctrl: qcom-pmic-gpio: Add pmx65 support Add support for the PMX65 GPIO support to the Qualcomm PMIC GPIO binding. Signed-off-by: Rohit Agarwal Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/1649048650-14059-2-git-send-email-quic_rohiagar@quicinc.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml index fe2bcf0694d9..22dbcba752d0 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -53,6 +53,7 @@ properties: - qcom,pmr735b-gpio - qcom,pms405-gpio - qcom,pmx55-gpio + - qcom,pmx65-gpio - enum: - qcom,spmi-gpio @@ -140,6 +141,7 @@ $defs: and gpio10) - gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10 and gpio11) + - gpio1-gpio16 for pmx65 items: pattern: "^gpio([0-9]+)$" -- cgit From 61b23e484f9f95d2d5710e2c9078373143c1436e Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Sat, 19 Mar 2022 21:46:28 +0100 Subject: dt-bindings: pinctrl: convert ocelot-pinctrl to YAML format Convert the ocelot-pinctrl device tree binding to the new YAML format. Additionally to the original binding documentation, add interrupt properties which are optional and already used on several SoCs like SparX-5, Luton, Ocelot and LAN966x but were not documented before. Also, on the sparx5 and the lan966x SoCs there are two items for the reg property. Signed-off-by: Michael Walle Acked-by: Linus Walleij Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220319204628.1759635-7-michael@walle.cc Signed-off-by: Linus Walleij --- .../bindings/pinctrl/mscc,ocelot-pinctrl.txt | 42 -------- .../bindings/pinctrl/mscc,ocelot-pinctrl.yaml | 108 +++++++++++++++++++++ 2 files changed, 108 insertions(+), 42 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt deleted file mode 100644 index 5d84fd299ccf..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt +++ /dev/null @@ -1,42 +0,0 @@ -Microsemi Ocelot pin controller Device Tree Bindings ----------------------------------------------------- - -Required properties: - - compatible : Should be "mscc,ocelot-pinctrl", - "mscc,jaguar2-pinctrl", "microchip,sparx5-pinctrl", - "mscc,luton-pinctrl", "mscc,serval-pinctrl", - "microchip,lan966x-pinctrl" or "mscc,servalt-pinctrl" - - reg : Address and length of the register set for the device - - gpio-controller : Indicates this device is a GPIO controller - - #gpio-cells : Must be 2. - The first cell is the pin number and the - second cell specifies GPIO flags, as defined in - . - - gpio-ranges : Range of pins managed by the GPIO controller. - - -The ocelot-pinctrl driver uses the generic pin multiplexing and generic pin -configuration documented in pinctrl-bindings.txt. - -The following generic properties are supported: - - function - - pins - -Example: - gpio: pinctrl@71070034 { - compatible = "mscc,ocelot-pinctrl"; - reg = <0x71070034 0x28>; - gpio-controller; - #gpio-cells = <2>; - gpio-ranges = <&gpio 0 0 22>; - - uart_pins: uart-pins { - pins = "GPIO_6", "GPIO_7"; - function = "uart"; - }; - - uart2_pins: uart2-pins { - pins = "GPIO_12", "GPIO_13"; - function = "uart2"; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml new file mode 100644 index 000000000000..7149a6655623 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml @@ -0,0 +1,108 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/mscc,ocelot-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microsemi Ocelot pin controller + +maintainers: + - Alexandre Belloni + - Lars Povlsen + +properties: + compatible: + enum: + - microchip,lan966x-pinctrl + - microchip,sparx5-pinctrl + - mscc,jaguar2-pinctrl + - mscc,luton-pinctrl + - mscc,ocelot-pinctrl + - mscc,serval-pinctrl + - mscc,servalt-pinctrl + + reg: + items: + - description: Base address + - description: Extended pin configuration registers + minItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + gpio-ranges: true + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + +patternProperties: + '-pins$': + type: object + allOf: + - $ref: "pinmux-node.yaml" + - $ref: "pincfg-node.yaml" + + properties: + function: true + pins: true + output-high: true + output-low: true + drive-strength: true + + required: + - function + - pins + + additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +allOf: + - $ref: "pinctrl.yaml#" + - if: + properties: + compatible: + contains: + enum: + - microchip,lan966x-pinctrl + - microchip,sparx5-pinctrl + then: + properties: + reg: + minItems: 2 + +additionalProperties: false + +examples: + - | + gpio: pinctrl@71070034 { + compatible = "mscc,ocelot-pinctrl"; + reg = <0x71070034 0x28>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&gpio 0 0 22>; + + uart_pins: uart-pins { + pins = "GPIO_6", "GPIO_7"; + function = "uart"; + }; + + uart2_pins: uart2-pins { + pins = "GPIO_12", "GPIO_13"; + function = "uart2"; + }; + }; + +... -- cgit From 68514c9f6aa676f98328844336fc4400244a8479 Mon Sep 17 00:00:00 2001 From: Steve Lee Date: Wed, 20 Apr 2022 13:49:00 +0900 Subject: ASoC: dt-bindings: max98390: add reset gpio bindings This adds support for the reset gpio binding. Signed-off-by: Steve Lee Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220420044900.2989-2-steve.lee.analog@gmail.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/maxim,max98390.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/maxim,max98390.yaml b/Documentation/devicetree/bindings/sound/maxim,max98390.yaml index fea9a1b6619a..deaa6886c42f 100644 --- a/Documentation/devicetree/bindings/sound/maxim,max98390.yaml +++ b/Documentation/devicetree/bindings/sound/maxim,max98390.yaml @@ -29,6 +29,9 @@ properties: minimum: 1 maximum: 8388607 + reset-gpios: + maxItems: 1 + required: - compatible - reg @@ -37,6 +40,7 @@ additionalProperties: false examples: - | + #include i2c { #address-cells = <1>; #size-cells = <0>; @@ -45,5 +49,6 @@ examples: reg = <0x38>; maxim,temperature_calib = <1024>; maxim,r0_calib = <100232>; + reset-gpios = <&gpio 9 GPIO_ACTIVE_LOW>; }; }; -- cgit From 324e4f85070f89b58c5f9926370ad19dea907dc7 Mon Sep 17 00:00:00 2001 From: Dan Vacura Date: Fri, 1 Apr 2022 11:04:45 -0500 Subject: usb: gadget: uvc: allow changing interface name via configfs Add a configfs entry, "function_name", to change the iInterface field for VideoControl. This name is used on host devices for user selection, useful when multiple cameras are present. The default will remain "UVC Camera". Signed-off-by: Dan Vacura Link: https://lore.kernel.org/r/20220401160447.5919-1-w36195@motorola.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/configfs-usb-gadget-uvc | 1 + Documentation/usb/gadget-testing.rst | 1 + 2 files changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc b/Documentation/ABI/testing/configfs-usb-gadget-uvc index 889ed45be4ca..611b23e6488d 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uvc +++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc @@ -7,6 +7,7 @@ Description: UVC function directory streaming_maxburst 0..15 (ss only) streaming_maxpacket 1..1023 (fs), 1..3072 (hs/ss) streaming_interval 1..16 + function_name string [32] =================== ============================= What: /config/usb-gadget/gadget/functions/uvc.name/control diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index c6d034abce3a..1c37159fa171 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -787,6 +787,7 @@ The uvc function provides these attributes in its function directory: streaming_maxpacket maximum packet size this endpoint is capable of sending or receiving when this configuration is selected + function_name name of the interface =================== ================================================ There are also "control" and "streaming" subdirectories, each of which contain -- cgit From ee11ae36b2c8e3b11a6eff4bf51eb3065ce5f94b Mon Sep 17 00:00:00 2001 From: Aswath Govindraju Date: Thu, 14 Apr 2022 16:02:08 +0530 Subject: dt-bindings: usb: Add documentation for AM62 USB Wrapper module Add bindings for the TI's AM62 wrapper module for the Synopsys USBSS-DRD controller. Reviewed-by: Rob Herring Signed-off-by: Aswath Govindraju Link: https://lore.kernel.org/r/20220414103211.16202-2-a-govindraju@ti.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/ti,am62-usb.yaml | 103 +++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/ti,am62-usb.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml new file mode 100644 index 000000000000..d25fc708e32c --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/ti,am62-usb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI's AM62 wrapper module for the Synopsys USBSS-DRD controller + +maintainers: + - Aswath Govindraju + +properties: + compatible: + const: ti,am62-usb + + reg: + maxItems: 1 + + ranges: true + + power-domains: + description: + PM domain provider node and an args specifier containing + the USB ISO device id value. See, + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml + maxItems: 1 + + clocks: + description: Clock phandle to usb2_refclk + maxItems: 1 + + clock-names: + items: + - const: ref + + ti,vbus-divider: + description: + Should be present if USB VBUS line is connected to the + VBUS pin of the SoC via a 1/3 voltage divider. + type: boolean + + ti,syscon-phy-pll-refclk: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: Phandle to the SYSCON entry + - description: USB phy control register offset within SYSCON + description: + Specifier for conveying frequency of ref clock input, for the + operation of USB2PHY. + + '#address-cells': + const: 2 + + '#size-cells': + const: 2 + +patternProperties: + "^usb@[0-9a-f]+$": + $ref: snps,dwc3.yaml# + description: Required child node + +required: + - compatible + - reg + - power-domains + - clocks + - clock-names + - ti,syscon-phy-pll-refclk + +additionalProperties: false + +examples: + - | + #include + #include + #include + + bus { + #address-cells = <2>; + #size-cells = <2>; + + usbss1: usb@f910000 { + compatible = "ti,am62-usb"; + reg = <0x00 0x0f910000 0x00 0x800>; + clocks = <&k3_clks 162 3>; + clock-names = "ref"; + ti,syscon-phy-pll-refclk = <&wkup_conf 0x4018>; + power-domains = <&k3_pds 179 TI_SCI_PD_EXCLUSIVE>; + #address-cells = <2>; + #size-cells = <2>; + + usb@31100000 { + compatible = "snps,dwc3"; + reg =<0x00 0x31100000 0x00 0x50000>; + interrupts = , /* irq.0 */ + ; /* irq.0 */ + interrupt-names = "host", "peripheral"; + maximum-speed = "high-speed"; + dr_mode = "otg"; + }; + }; + }; -- cgit From 0cade7885fd5bc47039986b632f3e5585f6b7c22 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 7 Apr 2022 21:23:38 +0200 Subject: dt-bindings: usb: samsung,exynos-usb2: add missing required reg "reg" property is required on Samsung S5PV210/Exynos EHCI/OHCI controllers. Fixes: 4bf2283cb208 ("dt-bindings: usb: samsung,exynos-usb2: convert to dtschema") Reviewed-by: Alim Akhtar Acked-by: Rob Herring Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220407192338.14849-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml index fbf07d6e707a..ef42c6fce73c 100644 --- a/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml +++ b/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml @@ -62,6 +62,7 @@ required: - interrupts - phys - phy-names + - reg allOf: - if: -- cgit From 1e2b2f06c1be6f9676ed99f36bc263f1cda12c9c Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 19 Apr 2022 14:10:13 +0200 Subject: dt-bindings: usb: samsung,exynos-usb2: include usb-hcd schema Remove parts duplicated with usb-hcd.yaml DT schema and include it directly. Reviewed-by: Rob Herring Reviewed-by: Alim Akhtar Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220419121013.250023-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/samsung,exynos-usb2.yaml | 15 ++------------- 1 file changed, 2 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml index fbf07d6e707a..c21139dcc91f 100644 --- a/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml +++ b/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml @@ -15,9 +15,6 @@ properties: - samsung,exynos4210-ehci - samsung,exynos4210-ohci - '#address-cells': - const: 1 - clocks: maxItems: 1 @@ -46,15 +43,6 @@ properties: Only for controller in EHCI mode, if present, specifies the GPIO that needs to be pulled up for the bus to be powered. - '#size-cells': - const: 0 - -patternProperties: - "^.*@[0-9a-f]{1,2}$": - description: The hard wired USB devices - type: object - $ref: /usb/usb-device.yaml - required: - compatible - clocks @@ -64,6 +52,7 @@ required: - phy-names allOf: + - $ref: usb-hcd.yaml# - if: properties: compatible: @@ -73,7 +62,7 @@ allOf: properties: samsung,vbus-gpio: false -additionalProperties: false +unevaluatedProperties: false examples: - | -- cgit From 8a722fe86e5678b12ea576f4d07c2374603ec181 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 19 Apr 2022 14:08:27 +0200 Subject: dt-bindings: usb: samsung,exynos-usb2: add missing required reg "reg" property is required on Samsung S5PV210/Exynos EHCI/OHCI controllers. Fixes: 4bf2283cb208 ("dt-bindings: usb: samsung,exynos-usb2: convert to dtschema") Reviewed-by: Alim Akhtar Acked-by: Rob Herring Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220419120827.249627-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml index c21139dcc91f..76e25b9efebd 100644 --- a/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml +++ b/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml @@ -50,6 +50,7 @@ required: - interrupts - phys - phy-names + - reg allOf: - $ref: usb-hcd.yaml# -- cgit From f21949c1496807571ed3d09ed22e0ebeaec3e643 Mon Sep 17 00:00:00 2001 From: Alex Williamson Date: Wed, 20 Apr 2022 14:45:05 -0600 Subject: PCI/doc: Update obsolete pci_set_dma_mask() references The function is dma_set_mask(), fix a missed instance of the old pci_set_dma_mask() and a reference to a function that doesn't exist. Fixes: 05b0ebd06ae6 ("PCI/doc: cleanup references to the legacy PCI DMA API") Link: https://lore.kernel.org/r/165048747271.2959320.13475081883467312497.stgit@omen Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Reviewed-by: Christoph Hellwig --- Documentation/PCI/pci.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst index 67a850b55617..cced568d78e9 100644 --- a/Documentation/PCI/pci.rst +++ b/Documentation/PCI/pci.rst @@ -273,12 +273,12 @@ Set the DMA mask size While all drivers should explicitly indicate the DMA capability (e.g. 32 or 64 bit) of the PCI bus master, devices with more than 32-bit bus master capability for streaming data need the driver -to "register" this capability by calling pci_set_dma_mask() with +to "register" this capability by calling dma_set_mask() with appropriate parameters. In general this allows more efficient DMA on systems where System RAM exists above 4G _physical_ address. Drivers for all PCI-X and PCIe compliant devices must call -set_dma_mask() as they are 64-bit DMA devices. +dma_set_mask() as they are 64-bit DMA devices. Similarly, drivers must also "register" this capability if the device can directly address "coherent memory" in System RAM above 4G physical -- cgit From 9cd6576f46be175f7ef0769554ce120470bb2ccf Mon Sep 17 00:00:00 2001 From: "周琰杰 (Zhou Yanjie)" Date: Fri, 15 Apr 2022 03:25:35 +0800 Subject: dt-bindings: dwc2: Add bindings for new Ingenic SoCs. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the dwc2 bindings for the JZ4775 SoC, the JZ4780 SoC, the X1000 SoC, the X1600 SoC, the X1700 SoC, the X1830 SoC, and the X2000 SoC from Ingenic. Acked-by: Rob Herring Signed-off-by: 周琰杰 (Zhou Yanjie) Link: https://lore.kernel.org/r/1649964337-114337-2-git-send-email-zhouyanjie@wanyeetech.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/dwc2.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index 4cebce682d16..c6e8c0b7a4e1 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -17,6 +17,13 @@ properties: oneOf: - const: brcm,bcm2835-usb - const: hisilicon,hi6220-usb + - const: ingenic,jz4775-otg + - const: ingenic,jz4780-otg + - const: ingenic,x1000-otg + - const: ingenic,x1600-otg + - const: ingenic,x1700-otg + - const: ingenic,x1830-otg + - const: ingenic,x2000-otg - items: - const: rockchip,rk3066-usb - const: snps,dwc2 -- cgit From ea3364db9068e37bd8e12b9a99c7c92385593ed7 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Fri, 8 Apr 2022 14:48:34 -0700 Subject: dt-bindings: interconnect: qcom: Add sc8280xp binding The Qualcomm SC8280XP platform has the usual set of busses, add a binding for these interconnect providers and port definitions to allow interconnect paths to be expressed in the sc8280xp DeviceTree. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220408214835.624494-1-bjorn.andersson@linaro.org Signed-off-by: Georgi Djakov --- .../devicetree/bindings/interconnect/qcom,rpmh.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index 5a911be0c2ea..0286f40fdc44 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -60,6 +60,18 @@ properties: - qcom,sc8180x-mc-virt - qcom,sc8180x-mmss-noc - qcom,sc8180x-system-noc + - qcom,sc8280xp-aggre1-noc + - qcom,sc8280xp-aggre2-noc + - qcom,sc8280xp-clk-virt + - qcom,sc8280xp-config-noc + - qcom,sc8280xp-dc-noc + - qcom,sc8280xp-gem-noc + - qcom,sc8280xp-lpass-ag-noc + - qcom,sc8280xp-mc-virt + - qcom,sc8280xp-mmss-noc + - qcom,sc8280xp-nspa-noc + - qcom,sc8280xp-nspb-noc + - qcom,sc8280xp-system-noc - qcom,sdm845-aggre1-noc - qcom,sdm845-aggre2-noc - qcom,sdm845-config-noc -- cgit From 890d550d7dbac7a31ecaa78732aa22be282bb6b8 Mon Sep 17 00:00:00 2001 From: Chengming Zhou Date: Fri, 8 Apr 2022 20:19:14 +0800 Subject: sched/psi: report zeroes for CPU full at the system level Martin find it confusing when look at the /proc/pressure/cpu output, and found no hint about that CPU "full" line in psi Documentation. % cat /proc/pressure/cpu some avg10=0.92 avg60=0.91 avg300=0.73 total=933490489 full avg10=0.22 avg60=0.23 avg300=0.16 total=358783277 The PSI_CPU_FULL state is introduced by commit e7fcd7622823 ("psi: Add PSI_CPU_FULL state"), which mainly for cgroup level, but also counted at the system level as a side effect. Naturally, the FULL state doesn't exist for the CPU resource at the system level. These "full" numbers can come from CPU idle schedule latency. For example, t1 is the time when task wakeup on an idle CPU, t2 is the time when CPU pick and switch to it. The delta of (t2 - t1) will be in CPU_FULL state. Another case all processes can be stalled is when all cgroups have been throttled at the same time, which unlikely to happen. Anyway, CPU_FULL metric is meaningless and confusing at the system level. So this patch will report zeroes for CPU full at the system level, and update psi Documentation accordingly. Fixes: e7fcd7622823 ("psi: Add PSI_CPU_FULL state") Reported-by: Martin Steigerwald Suggested-by: Johannes Weiner Signed-off-by: Chengming Zhou Signed-off-by: Peter Zijlstra (Intel) Acked-by: Johannes Weiner Link: https://lore.kernel.org/r/20220408121914.82855-1-zhouchengming@bytedance.com --- Documentation/accounting/psi.rst | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/accounting/psi.rst b/Documentation/accounting/psi.rst index 860fe651d645..5e40b3f437f9 100644 --- a/Documentation/accounting/psi.rst +++ b/Documentation/accounting/psi.rst @@ -37,11 +37,7 @@ Pressure interface Pressure information for each resource is exported through the respective file in /proc/pressure/ -- cpu, memory, and io. -The format for CPU is as such:: - - some avg10=0.00 avg60=0.00 avg300=0.00 total=0 - -and for memory and IO:: +The format is as such:: some avg10=0.00 avg60=0.00 avg300=0.00 total=0 full avg10=0.00 avg60=0.00 avg300=0.00 total=0 @@ -58,6 +54,9 @@ situation from a state where some tasks are stalled but the CPU is still doing productive work. As such, time spent in this subset of the stall state is tracked separately and exported in the "full" averages. +CPU full is undefined at the system level, but has been reported +since 5.13, so it is set to zero for backward compatibility. + The ratios (in %) are tracked as recent trends over ten, sixty, and three hundred second windows, which gives insight into short term events as well as medium and long term trends. The total absolute stall time -- cgit From dfd2b37edf7ef469574ef7f36e3a1905ac9ead62 Mon Sep 17 00:00:00 2001 From: ChiYuan Huang Date: Fri, 22 Apr 2022 14:50:55 +0800 Subject: regulator: dt-bindings: Revise the rt5190a buck/ldo description Revise the rt5190a bucks and ldo property description. Signed-off-by: ChiYuan Huang Link: https://lore.kernel.org/r/1650610255-6180-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml index 28725c5467fc..edb411be0390 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml @@ -58,7 +58,7 @@ properties: type: object $ref: regulator.yaml# description: | - regulator description for buck1 and buck4. + regulator description for buck1 to buck4, and ldo. properties: regulator-allowed-modes: -- cgit From 3ac8316e09b0a0fd299fb40a27546de9e1a48216 Mon Sep 17 00:00:00 2001 From: Radhey Shyam Pandey Date: Wed, 20 Apr 2022 16:33:09 +0530 Subject: dt-bindings: net: cdns,macb: Drop phy-names property for ZynqMP SGMII PHY In zynqmp SGMII initialization, there is a single PHY so remove phy-names property as there is no real need of having it. Signed-off-by: Radhey Shyam Pandey Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/cdns,macb.yaml | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/cdns,macb.yaml b/Documentation/devicetree/bindings/net/cdns,macb.yaml index 6cd3d853dcba..e5b628736930 100644 --- a/Documentation/devicetree/bindings/net/cdns,macb.yaml +++ b/Documentation/devicetree/bindings/net/cdns,macb.yaml @@ -84,13 +84,6 @@ properties: phys: maxItems: 1 - phy-names: - const: sgmii-phy - description: - Required with ZynqMP SoC when in SGMII mode. - Should reference PS-GTR generic PHY device for this controller - instance. See ZynqMP example. - resets: maxItems: 1 description: @@ -204,7 +197,6 @@ examples: reset-names = "gem1_rst"; status = "okay"; phy-mode = "sgmii"; - phy-names = "sgmii-phy"; phys = <&psgtr 1 PHY_TYPE_SGMII 1 1>; fixed-link { speed = <1000>; -- cgit From e41a2999f746e67f1230dd42930497d4e011eb9a Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas Date: Wed, 20 Apr 2022 09:24:11 +0200 Subject: drm/doc: Add sections about tiny drivers and external refs to intro page Learning about the DRM subsystem could be quite overwhelming for newcomers but there are lots of useful talks, slides and articles available that can help to understand the needed concepts and ease the learning curve. There are also simple DRM drivers that can be used as example about how a DRM driver should look like. Add sections to the introduction page, that contains references to these. Suggested-by: Daniel Vetter Signed-off-by: Javier Martinez Canillas Acked-by: Pekka Paalanen Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20220420072411.15104-1-javierm@redhat.com --- Documentation/gpu/introduction.rst | 60 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index 25a56e9c0cfd..f05eccd2c07c 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -112,3 +112,63 @@ Please conduct yourself in a respectful and civilised manner when interacting with community members on mailing lists, IRC, or bug trackers. The community represents the project as a whole, and abusive or bullying behaviour is not tolerated by the project. + +Simple DRM drivers to use as examples +===================================== + +The DRM subsystem contains a lot of helper functions to ease writing drivers for +simple graphic devices. For example, the `drivers/gpu/drm/tiny/` directory has a +set of drivers that are simple enough to be implemented in a single source file. + +These drivers make use of the `struct drm_simple_display_pipe_funcs`, that hides +any complexity of the DRM subsystem and just requires drivers to implement a few +functions needed to operate the device. This could be used for devices that just +need a display pipeline with one full-screen scanout buffer feeding one output. + +The tiny DRM drivers are good examples to understand how DRM drivers should look +like. Since are just a few hundreds lines of code, they are quite easy to read. + +External References +=================== + +Delving into a Linux kernel subsystem for the first time can be an overwhelming +experience, one needs to get familiar with all the concepts and learn about the +subsystem's internals, among other details. + +To shallow the learning curve, this section contains a list of presentations +and documents that can be used to learn about DRM/KMS and graphics in general. + +There are different reasons why someone might want to get into DRM: porting an +existing fbdev driver, write a DRM driver for a new hardware, fixing bugs that +could face when working on the graphics user-space stack, etc. For this reason, +the learning material covers many aspects of the Linux graphics stack. From an +overview of the kernel and user-space stacks to very specific topics. + +The list is sorted in reverse chronological order, to keep the most up-to-date +material at the top. But all of them contain useful information, and it can be +valuable to go through older material to understand the rationale and context +in which the changes to the DRM subsystem were made. + +Conference talks +---------------- + +* `An Overview of the Linux and Userspace Graphics Stack `_ - Paul Kocialkowski (2020) +* `Getting pixels on screen on Linux: introduction to Kernel Mode Setting `_ - Simon Ser (2020) +* `Everything Great about Upstream Graphics `_ - Daniel Vetter (2019) +* `An introduction to the Linux DRM subsystem `_ - Maxime Ripard (2017) +* `Embrace the Atomic (Display) Age `_ - Daniel Vetter (2016) +* `Anatomy of an Atomic KMS Driver `_ - Laurent Pinchart (2015) +* `Atomic Modesetting for Drivers `_ - Daniel Vetter (2015) +* `Anatomy of an Embedded KMS Driver `_ - Laurent Pinchart (2013) + +Slides and articles +------------------- + +* `Understanding the Linux Graphics Stack `_ - Bootlin (2022) +* `DRM KMS overview `_ - STMicroelectronics (2021) +* `Linux graphic stack `_ - Nathan Gauër (2017) +* `Atomic mode setting design overview, part 1 `_ - Daniel Vetter (2015) +* `Atomic mode setting design overview, part 2 `_ - Daniel Vetter (2015) +* `The DRM/KMS subsystem from a newbie’s point of view `_ - Boris Brezillon (2014) +* `A brief introduction to the Linux graphics stack `_ - Iago Toral (2014) +* `The Linux Graphics Stack `_ - Jasper St. Pierre (2012) -- cgit From c78c5a660439d4d341a03b651541fda3ebe76160 Mon Sep 17 00:00:00 2001 From: Lorenzo Bianconi Date: Wed, 20 Apr 2022 16:07:07 +0200 Subject: dt-bindings: net: mediatek,net: convert to the json-schema This patch converts the existing mediatek-net.txt binding file in yaml format. Signed-off-by: Lorenzo Bianconi Reviewed-by: Rob Herring Signed-off-by: David S. Miller --- .../devicetree/bindings/net/mediatek,net.yaml | 297 +++++++++++++++++++++ .../devicetree/bindings/net/mediatek-net.txt | 108 -------- 2 files changed, 297 insertions(+), 108 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/mediatek,net.yaml delete mode 100644 Documentation/devicetree/bindings/net/mediatek-net.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml new file mode 100644 index 000000000000..43cc4024ef98 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml @@ -0,0 +1,297 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mediatek,net.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Frame Engine Ethernet controller + +maintainers: + - Lorenzo Bianconi + - Felix Fietkau + +description: + The frame engine ethernet controller can be found on MediaTek SoCs. These SoCs + have dual GMAC ports. + +properties: + compatible: + enum: + - mediatek,mt2701-eth + - mediatek,mt7623-eth + - mediatek,mt7622-eth + - mediatek,mt7629-eth + - ralink,rt5350-eth + + reg: + maxItems: 1 + + interrupts: + minItems: 3 + maxItems: 3 + + power-domains: + maxItems: 1 + + resets: + maxItems: 3 + + reset-names: + items: + - const: fe + - const: gmac + - const: ppe + + mediatek,ethsys: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon node that handles the port setup. + + cci-control-port: true + + mediatek,hifsys: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the mediatek hifsys controller used to provide various clocks + and reset to the system. + + mediatek,sgmiisys: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 2 + items: + maxItems: 1 + description: + A list of phandle to the syscon node that handles the SGMII setup which is required for + those SoCs equipped with SGMII. + + dma-coherent: true + + mdio-bus: + $ref: mdio.yaml# + unevaluatedProperties: false + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +allOf: + - $ref: "ethernet-controller.yaml#" + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt2701-eth + - mediatek,mt7623-eth + then: + properties: + clocks: + minItems: 4 + maxItems: 4 + + clock-names: + items: + - const: ethif + - const: esw + - const: gp1 + - const: gp2 + + mediatek,pctl: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon node that handles the ports slew rate and + driver current. + + - if: + properties: + compatible: + contains: + const: mediatek,mt7622-eth + then: + properties: + clocks: + minItems: 11 + maxItems: 11 + + clock-names: + items: + - const: ethif + - const: esw + - const: gp0 + - const: gp1 + - const: gp2 + - const: sgmii_tx250m + - const: sgmii_rx250m + - const: sgmii_cdr_ref + - const: sgmii_cdr_fb + - const: sgmii_ck + - const: eth2pll + + mediatek,sgmiisys: + minItems: 1 + maxItems: 1 + + mediatek,wed: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 2 + maxItems: 2 + items: + maxItems: 1 + description: + List of phandles to wireless ethernet dispatch nodes. + + mediatek,pcie-mirror: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the mediatek pcie-mirror controller. + + - if: + properties: + compatible: + contains: + const: mediatek,mt7629-eth + then: + properties: + clocks: + minItems: 17 + maxItems: 17 + + clock-names: + items: + - const: ethif + - const: sgmiitop + - const: esw + - const: gp0 + - const: gp1 + - const: gp2 + - const: fe + - const: sgmii_tx250m + - const: sgmii_rx250m + - const: sgmii_cdr_ref + - const: sgmii_cdr_fb + - const: sgmii2_tx250m + - const: sgmii2_rx250m + - const: sgmii2_cdr_ref + - const: sgmii2_cdr_fb + - const: sgmii_ck + - const: eth2pll + + mediatek,infracfg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon node that handles the path from GMAC to + PHY variants. + + mediatek,sgmiisys: + minItems: 2 + maxItems: 2 + +patternProperties: + "^mac@[0-1]$": + type: object + additionalProperties: false + allOf: + - $ref: ethernet-controller.yaml# + description: + Ethernet MAC node + properties: + compatible: + const: mediatek,eth-mac + + reg: + maxItems: 1 + + phy-handle: true + + phy-mode: true + + required: + - reg + - compatible + - phy-handle + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + - mediatek,ethsys + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + #include + + soc { + #address-cells = <2>; + #size-cells = <2>; + + ethernet: ethernet@1b100000 { + compatible = "mediatek,mt7622-eth"; + reg = <0 0x1b100000 0 0x20000>; + interrupts = , + , + ; + clocks = <&topckgen CLK_TOP_ETH_SEL>, + <ðsys CLK_ETH_ESW_EN>, + <ðsys CLK_ETH_GP0_EN>, + <ðsys CLK_ETH_GP1_EN>, + <ðsys CLK_ETH_GP2_EN>, + <&sgmiisys CLK_SGMII_TX250M_EN>, + <&sgmiisys CLK_SGMII_RX250M_EN>, + <&sgmiisys CLK_SGMII_CDR_REF>, + <&sgmiisys CLK_SGMII_CDR_FB>, + <&topckgen CLK_TOP_SGMIIPLL>, + <&apmixedsys CLK_APMIXED_ETH2PLL>; + clock-names = "ethif", "esw", "gp0", "gp1", "gp2", + "sgmii_tx250m", "sgmii_rx250m", + "sgmii_cdr_ref", "sgmii_cdr_fb", "sgmii_ck", + "eth2pll"; + power-domains = <&scpsys MT7622_POWER_DOMAIN_ETHSYS>; + mediatek,ethsys = <ðsys>; + mediatek,sgmiisys = <&sgmiisys>; + cci-control-port = <&cci_control2>; + mediatek,pcie-mirror = <&pcie_mirror>; + mediatek,hifsys = <&hifsys>; + dma-coherent; + + #address-cells = <1>; + #size-cells = <0>; + + mdio0: mdio-bus { + #address-cells = <1>; + #size-cells = <0>; + + phy0: ethernet-phy@0 { + reg = <0>; + }; + + phy1: ethernet-phy@1 { + reg = <1>; + }; + }; + + gmac0: mac@0 { + compatible = "mediatek,eth-mac"; + phy-mode = "rgmii"; + phy-handle = <&phy0>; + reg = <0>; + }; + + gmac1: mac@1 { + compatible = "mediatek,eth-mac"; + phy-mode = "rgmii"; + phy-handle = <&phy1>; + reg = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt deleted file mode 100644 index f18d70189375..000000000000 --- a/Documentation/devicetree/bindings/net/mediatek-net.txt +++ /dev/null @@ -1,108 +0,0 @@ -MediaTek Frame Engine Ethernet controller -========================================= - -The frame engine ethernet controller can be found on MediaTek SoCs. These SoCs -have dual GMAC each represented by a child node.. - -* Ethernet controller node - -Required properties: -- compatible: Should be - "mediatek,mt2701-eth": for MT2701 SoC - "mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC - "mediatek,mt7622-eth": for MT7622 SoC - "mediatek,mt7629-eth": for MT7629 SoC - "ralink,rt5350-eth": for Ralink Rt5350F and MT7628/88 SoC -- reg: Address and length of the register set for the device -- interrupts: Should contain the three frame engines interrupts in numeric - order. These are fe_int0, fe_int1 and fe_int2. -- clocks: the clock used by the core -- clock-names: the names of the clock listed in the clocks property. These are - "ethif", "esw", "gp2", "gp1" : For MT2701 and MT7623 SoC - "ethif", "esw", "gp0", "gp1", "gp2", "sgmii_tx250m", "sgmii_rx250m", - "sgmii_cdr_ref", "sgmii_cdr_fb", "sgmii_ck", "eth2pll" : For MT7622 SoC - "ethif", "sgmiitop", "esw", "gp0", "gp1", "gp2", "fe", "sgmii_tx250m", - "sgmii_rx250m", "sgmii_cdr_ref", "sgmii_cdr_fb", "sgmii2_tx250m", - "sgmii2_rx250m", "sgmii2_cdr_ref", "sgmii2_cdr_fb", "sgmii_ck", - "eth2pll" : For MT7629 SoC. -- power-domains: phandle to the power domain that the ethernet is part of -- resets: Should contain phandles to the ethsys reset signals -- reset-names: Should contain the names of reset signal listed in the resets - property - These are "fe", "gmac" and "ppe" -- mediatek,ethsys: phandle to the syscon node that handles the port setup -- mediatek,infracfg: phandle to the syscon node that handles the path from - GMAC to PHY variants, which is required for MT7629 SoC. -- mediatek,sgmiisys: a list of phandles to the syscon node that handles the - SGMII setup which is required for those SoCs equipped with SGMII such - as MT7622 and MT7629 SoC. And MT7622 have only one set of SGMII shared - by GMAC1 and GMAC2; MT7629 have two independent sets of SGMII directed - to GMAC1 and GMAC2, respectively. -- mediatek,pctl: phandle to the syscon node that handles the ports slew rate - and driver current: only for MT2701 and MT7623 SoC - -Optional properties: -- dma-coherent: present if dma operations are coherent -- mediatek,cci-control: phandle to the cache coherent interconnect node -- mediatek,hifsys: phandle to the mediatek hifsys controller used to provide - various clocks and reset to the system. -- mediatek,wed: a list of phandles to wireless ethernet dispatch nodes for - MT7622 SoC. -- mediatek,pcie-mirror: phandle to the mediatek pcie-mirror controller for - MT7622 SoC. - -* Ethernet MAC node - -Required properties: -- compatible: Should be "mediatek,eth-mac" -- reg: The number of the MAC -- phy-handle: see ethernet.txt file in the same directory and - the phy-mode "trgmii" required being provided when reg - is equal to 0 and the MAC uses fixed-link to connect - with internal switch such as MT7530. - -Example: - -eth: ethernet@1b100000 { - compatible = "mediatek,mt7623-eth"; - reg = <0 0x1b100000 0 0x20000>; - clocks = <&topckgen CLK_TOP_ETHIF_SEL>, - <ðsys CLK_ETHSYS_ESW>, - <ðsys CLK_ETHSYS_GP2>, - <ðsys CLK_ETHSYS_GP1>; - clock-names = "ethif", "esw", "gp2", "gp1"; - interrupts = ; - power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>; - resets = <ðsys MT2701_ETHSYS_ETH_RST>; - reset-names = "eth"; - mediatek,ethsys = <ðsys>; - mediatek,pctl = <&syscfg_pctl_a>; - #address-cells = <1>; - #size-cells = <0>; - - gmac1: mac@0 { - compatible = "mediatek,eth-mac"; - reg = <0>; - phy-handle = <&phy0>; - }; - - gmac2: mac@1 { - compatible = "mediatek,eth-mac"; - reg = <1>; - phy-handle = <&phy1>; - }; - - mdio-bus { - phy0: ethernet-phy@0 { - reg = <0>; - phy-mode = "rgmii"; - }; - - phy1: ethernet-phy@1 { - reg = <1>; - phy-mode = "rgmii"; - }; - }; -}; -- cgit From e8c5e1a0f78fbfc4396866959fef43b258318b6f Mon Sep 17 00:00:00 2001 From: Grant Seltzer Date: Thu, 21 Apr 2022 23:10:50 -0400 Subject: libbpf: Improve libbpf API documentation link position This puts the link for libbpf API documentation into the sidebar for much easier navigation. You can preview this change at: https://libbpf-test.readthedocs.io/en/latest/ Note that the link is hardcoded to the production version, so you can see that it self references itself here for now: https://libbpf-test.readthedocs.io/en/latest/api.html This will need to make its way into the libbpf mirror, before being deployed to libbpf.readthedocs.org Signed-off-by: Grant Seltzer Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220422031050.303984-1-grantseltzer@gmail.com --- Documentation/bpf/libbpf/index.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bpf/libbpf/index.rst b/Documentation/bpf/libbpf/index.rst index 4e8c656b539a..3722537d1384 100644 --- a/Documentation/bpf/libbpf/index.rst +++ b/Documentation/bpf/libbpf/index.rst @@ -6,14 +6,13 @@ libbpf .. toctree:: :maxdepth: 1 + API Documentation libbpf_naming_convention libbpf_build This is documentation for libbpf, a userspace library for loading and interacting with bpf programs. -For API documentation see the `versioned API documentation site `_. - All general BPF questions, including kernel functionality, libbpf APIs and their application, should be sent to bpf@vger.kernel.org mailing list. You can `subscribe `_ to the -- cgit From f9f4545b968ba607dc54ca96c03312894679528c Mon Sep 17 00:00:00 2001 From: "Zhiyong.Tao" Date: Mon, 11 Apr 2022 10:27:23 +0800 Subject: dt-bindings: pwrap: mediatek: Update pwrap document for mt8195 Update pwrap document description for mt8195 Signed-off-by: Zhiyong Tao Signed-off-by: Tinghan Shen Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220411022724.11005-2-tinghan.shen@mediatek.com Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/soc/mediatek/pwrap.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt index 214a34633824..0581dbda4828 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt @@ -31,20 +31,20 @@ Required properties in pwrap device node. "mediatek,mt8195-pwrap" for MT8195 SoCs "mediatek,mt8516-pwrap" for MT8516 SoCs - interrupts: IRQ for pwrap in SOC -- reg-names: Must include the following entries: +- reg-names: "pwrap" is required; "pwrap-bridge" is optional. "pwrap": Main registers base "pwrap-bridge": bridge base (IP Pairing) - reg: Must contain an entry for each entry in reg-names. -- reset-names: Must include the following entries: - "pwrap" - "pwrap-bridge" (IP Pairing) -- resets: Must contain an entry for each entry in reset-names. - clock-names: Must include the following entries: "spi": SPI bus clock "wrap": Main module clock - clocks: Must contain an entry for each entry in clock-names. Optional properities: +- reset-names: Some SoCs include the following entries: + "pwrap" + "pwrap-bridge" (IP Pairing) +- resets: Must contain an entry for each entry in reset-names. - pmic: Using either MediaTek PMIC MFD as the child device of pwrap See the following for child node definitions: Documentation/devicetree/bindings/mfd/mt6397.txt -- cgit From b7da6f517214c307efece604ac9dc58dc6123c07 Mon Sep 17 00:00:00 2001 From: "Nícolas F. R. A. Prado" Date: Fri, 25 Feb 2022 17:58:52 -0500 Subject: dt-bindings: remoteproc: mediatek: Add interrupts property to mtk,scp MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The SCP node can have an associated interrupt. Add a property for it. Signed-off-by: Nícolas F. R. A. Prado Acked-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220225225854.81038-2-nfraprado@collabora.com --- Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml index 5b693a2d049c..823a236242de 100644 --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml @@ -42,6 +42,9 @@ properties: clock-names: const: main + interrupts: + maxItems: 1 + required: - compatible - reg -- cgit From 77930ee4d5b35e4a88a33e83fe8bf91a7a7016f9 Mon Sep 17 00:00:00 2001 From: Andreas-Christian Hagau Date: Sun, 17 Apr 2022 10:37:51 +0200 Subject: Documentation: kunit: change complete_and_exit to kthread_complete_and_exit Commit cead18552660 ("exit: Rename complete_and_exit to kthread_complete_and_exit") renamed complete_and_exit to kthread_complete_and_exit. Signed-off-by: Andreas-Christian Hagau Reviewed-by: Brendan Higgins Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/kunit/architecture.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/architecture.rst b/Documentation/dev-tools/kunit/architecture.rst index ff9c85a0bff2..cf9e6e3eeae4 100644 --- a/Documentation/dev-tools/kunit/architecture.rst +++ b/Documentation/dev-tools/kunit/architecture.rst @@ -125,7 +125,7 @@ All expectations/assertions are formatted as: ``void __noreturn kunit_try_catch_throw(struct kunit_try_catch *try_catch)``. - ``kunit_try_catch_throw`` calls function: - ``void complete_and_exit(struct completion *, long) __noreturn;`` + ``void kthread_complete_and_exit(struct completion *, long) __noreturn;`` and terminates the special thread context. - ```` denotes a check with options: ``TRUE`` (supplied property -- cgit From 69ef0920bdd3ce234cf6916342d9c16251d9ccb6 Mon Sep 17 00:00:00 2001 From: Bruno Moreira-Guedes Date: Tue, 19 Apr 2022 11:48:15 -0300 Subject: Docs: Add cpio requirement to changes.rst The install target requires cpio to run the `kernel/gen_kheaders.sh` script, but it's missing in the requirements list at 'Documentation/process/changes.rst'. This patch adds it to the list. Signed-off-by: Bruno Moreira-Guedes Signed-off-by: Jonathan Corbet --- Documentation/process/changes.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index a337e8eabfe1..41a44e5f47e6 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -56,6 +56,7 @@ iptables 1.4.2 iptables -V openssl & libcrypto 1.0.0 openssl version bc 1.06.95 bc --version Sphinx\ [#f1]_ 1.7 sphinx-build --version +cpio any cpio --version ====================== =============== ======================================== .. [#f1] Sphinx is needed only to build the Kernel documentation @@ -458,6 +459,11 @@ mcelog - +cpio +---- + +- + Networking ********** -- cgit From 5a5866c28b43e26dc7594b735b2a44e538ec63a4 Mon Sep 17 00:00:00 2001 From: Bruno Moreira-Guedes Date: Tue, 19 Apr 2022 11:48:52 -0300 Subject: Docs: Replace version by 'current' in changes.rst The file 'Documentation/process/changes.rst' states the listed requirements are for the 4.x kernel version. However, there are requirements updated for the 5.x version, as there might be in other future versions. This patch updates it to 'latest' so the document won't be outdated in the future. Signed-off-by: Bruno Moreira-Guedes Signed-off-by: Jonathan Corbet --- Documentation/process/changes.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index 41a44e5f47e6..34415ae1af1b 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -7,7 +7,7 @@ Intro ===== This document is designed to provide a list of the minimum levels of -software necessary to run the 4.x kernels. +software necessary to run the current kernel version. This document is originally based on my "Changes" file for 2.0.x kernels and therefore owes credit to the same people as that file (Jared Mauch, -- cgit From f5461124d59bfb62bd9e231ee64cbaf757343ad5 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Mon, 18 Apr 2022 19:54:16 -0700 Subject: Documentation: move watch_queue to core-api Move watch_queue documentation to the core-api index and subdirectory. Fixes: c73be61cede5 ("pipe: Add general notification queue support") Signed-off-by: Randy Dunlap Cc: David Howells Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Signed-off-by: Jonathan Corbet --- Documentation/core-api/index.rst | 1 + Documentation/core-api/watch_queue.rst | 343 +++++++++++++++++++++++++++++++++ Documentation/index.rst | 1 - Documentation/watch_queue.rst | 343 --------------------------------- 4 files changed, 344 insertions(+), 344 deletions(-) create mode 100644 Documentation/core-api/watch_queue.rst delete mode 100644 Documentation/watch_queue.rst (limited to 'Documentation') diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index 972d46a5ddf6..2bfbf7093338 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -18,6 +18,7 @@ it. kernel-api workqueue + watch_queue printk-basics printk-formats symbol-namespaces diff --git a/Documentation/core-api/watch_queue.rst b/Documentation/core-api/watch_queue.rst new file mode 100644 index 000000000000..54f13ad5fc17 --- /dev/null +++ b/Documentation/core-api/watch_queue.rst @@ -0,0 +1,343 @@ +============================== +General notification mechanism +============================== + +The general notification mechanism is built on top of the standard pipe driver +whereby it effectively splices notification messages from the kernel into pipes +opened by userspace. This can be used in conjunction with:: + + * Key/keyring notifications + + +The notifications buffers can be enabled by: + + "General setup"/"General notification queue" + (CONFIG_WATCH_QUEUE) + +This document has the following sections: + +.. contents:: :local: + + +Overview +======== + +This facility appears as a pipe that is opened in a special mode. The pipe's +internal ring buffer is used to hold messages that are generated by the kernel. +These messages are then read out by read(). Splice and similar are disabled on +such pipes due to them wanting to, under some circumstances, revert their +additions to the ring - which might end up interleaved with notification +messages. + +The owner of the pipe has to tell the kernel which sources it would like to +watch through that pipe. Only sources that have been connected to a pipe will +insert messages into it. Note that a source may be bound to multiple pipes and +insert messages into all of them simultaneously. + +Filters may also be emplaced on a pipe so that certain source types and +subevents can be ignored if they're not of interest. + +A message will be discarded if there isn't a slot available in the ring or if +no preallocated message buffer is available. In both of these cases, read() +will insert a WATCH_META_LOSS_NOTIFICATION message into the output buffer after +the last message currently in the buffer has been read. + +Note that when producing a notification, the kernel does not wait for the +consumers to collect it, but rather just continues on. This means that +notifications can be generated whilst spinlocks are held and also protects the +kernel from being held up indefinitely by a userspace malfunction. + + +Message Structure +================= + +Notification messages begin with a short header:: + + struct watch_notification { + __u32 type:24; + __u32 subtype:8; + __u32 info; + }; + +"type" indicates the source of the notification record and "subtype" indicates +the type of record from that source (see the Watch Sources section below). The +type may also be "WATCH_TYPE_META". This is a special record type generated +internally by the watch queue itself. There are two subtypes: + + * WATCH_META_REMOVAL_NOTIFICATION + * WATCH_META_LOSS_NOTIFICATION + +The first indicates that an object on which a watch was installed was removed +or destroyed and the second indicates that some messages have been lost. + +"info" indicates a bunch of things, including: + + * The length of the message in bytes, including the header (mask with + WATCH_INFO_LENGTH and shift by WATCH_INFO_LENGTH__SHIFT). This indicates + the size of the record, which may be between 8 and 127 bytes. + + * The watch ID (mask with WATCH_INFO_ID and shift by WATCH_INFO_ID__SHIFT). + This indicates that caller's ID of the watch, which may be between 0 + and 255. Multiple watches may share a queue, and this provides a means to + distinguish them. + + * A type-specific field (WATCH_INFO_TYPE_INFO). This is set by the + notification producer to indicate some meaning specific to the type and + subtype. + +Everything in info apart from the length can be used for filtering. + +The header can be followed by supplementary information. The format of this is +at the discretion is defined by the type and subtype. + + +Watch List (Notification Source) API +==================================== + +A "watch list" is a list of watchers that are subscribed to a source of +notifications. A list may be attached to an object (say a key or a superblock) +or may be global (say for device events). From a userspace perspective, a +non-global watch list is typically referred to by reference to the object it +belongs to (such as using KEYCTL_NOTIFY and giving it a key serial number to +watch that specific key). + +To manage a watch list, the following functions are provided: + + * :: + + void init_watch_list(struct watch_list *wlist, + void (*release_watch)(struct watch *wlist)); + + Initialise a watch list. If ``release_watch`` is not NULL, then this + indicates a function that should be called when the watch_list object is + destroyed to discard any references the watch list holds on the watched + object. + + * ``void remove_watch_list(struct watch_list *wlist);`` + + This removes all of the watches subscribed to a watch_list and frees them + and then destroys the watch_list object itself. + + +Watch Queue (Notification Output) API +===================================== + +A "watch queue" is the buffer allocated by an application that notification +records will be written into. The workings of this are hidden entirely inside +of the pipe device driver, but it is necessary to gain a reference to it to set +a watch. These can be managed with: + + * ``struct watch_queue *get_watch_queue(int fd);`` + + Since watch queues are indicated to the kernel by the fd of the pipe that + implements the buffer, userspace must hand that fd through a system call. + This can be used to look up an opaque pointer to the watch queue from the + system call. + + * ``void put_watch_queue(struct watch_queue *wqueue);`` + + This discards the reference obtained from ``get_watch_queue()``. + + +Watch Subscription API +====================== + +A "watch" is a subscription on a watch list, indicating the watch queue, and +thus the buffer, into which notification records should be written. The watch +queue object may also carry filtering rules for that object, as set by +userspace. Some parts of the watch struct can be set by the driver:: + + struct watch { + union { + u32 info_id; /* ID to be OR'd in to info field */ + ... + }; + void *private; /* Private data for the watched object */ + u64 id; /* Internal identifier */ + ... + }; + +The ``info_id`` value should be an 8-bit number obtained from userspace and +shifted by WATCH_INFO_ID__SHIFT. This is OR'd into the WATCH_INFO_ID field of +struct watch_notification::info when and if the notification is written into +the associated watch queue buffer. + +The ``private`` field is the driver's data associated with the watch_list and +is cleaned up by the ``watch_list::release_watch()`` method. + +The ``id`` field is the source's ID. Notifications that are posted with a +different ID are ignored. + +The following functions are provided to manage watches: + + * ``void init_watch(struct watch *watch, struct watch_queue *wqueue);`` + + Initialise a watch object, setting its pointer to the watch queue, using + appropriate barriering to avoid lockdep complaints. + + * ``int add_watch_to_object(struct watch *watch, struct watch_list *wlist);`` + + Subscribe a watch to a watch list (notification source). The + driver-settable fields in the watch struct must have been set before this + is called. + + * :: + + int remove_watch_from_object(struct watch_list *wlist, + struct watch_queue *wqueue, + u64 id, false); + + Remove a watch from a watch list, where the watch must match the specified + watch queue (``wqueue``) and object identifier (``id``). A notification + (``WATCH_META_REMOVAL_NOTIFICATION``) is sent to the watch queue to + indicate that the watch got removed. + + * ``int remove_watch_from_object(struct watch_list *wlist, NULL, 0, true);`` + + Remove all the watches from a watch list. It is expected that this will be + called preparatory to destruction and that the watch list will be + inaccessible to new watches by this point. A notification + (``WATCH_META_REMOVAL_NOTIFICATION``) is sent to the watch queue of each + subscribed watch to indicate that the watch got removed. + + +Notification Posting API +======================== + +To post a notification to watch list so that the subscribed watches can see it, +the following function should be used:: + + void post_watch_notification(struct watch_list *wlist, + struct watch_notification *n, + const struct cred *cred, + u64 id); + +The notification should be preformatted and a pointer to the header (``n``) +should be passed in. The notification may be larger than this and the size in +units of buffer slots is noted in ``n->info & WATCH_INFO_LENGTH``. + +The ``cred`` struct indicates the credentials of the source (subject) and is +passed to the LSMs, such as SELinux, to allow or suppress the recording of the +note in each individual queue according to the credentials of that queue +(object). + +The ``id`` is the ID of the source object (such as the serial number on a key). +Only watches that have the same ID set in them will see this notification. + + +Watch Sources +============= + +Any particular buffer can be fed from multiple sources. Sources include: + + * WATCH_TYPE_KEY_NOTIFY + + Notifications of this type indicate changes to keys and keyrings, including + the changes of keyring contents or the attributes of keys. + + See Documentation/security/keys/core.rst for more information. + + +Event Filtering +=============== + +Once a watch queue has been created, a set of filters can be applied to limit +the events that are received using:: + + struct watch_notification_filter filter = { + ... + }; + ioctl(fd, IOC_WATCH_QUEUE_SET_FILTER, &filter) + +The filter description is a variable of type:: + + struct watch_notification_filter { + __u32 nr_filters; + __u32 __reserved; + struct watch_notification_type_filter filters[]; + }; + +Where "nr_filters" is the number of filters in filters[] and "__reserved" +should be 0. The "filters" array has elements of the following type:: + + struct watch_notification_type_filter { + __u32 type; + __u32 info_filter; + __u32 info_mask; + __u32 subtype_filter[8]; + }; + +Where: + + * ``type`` is the event type to filter for and should be something like + "WATCH_TYPE_KEY_NOTIFY" + + * ``info_filter`` and ``info_mask`` act as a filter on the info field of the + notification record. The notification is only written into the buffer if:: + + (watch.info & info_mask) == info_filter + + This could be used, for example, to ignore events that are not exactly on + the watched point in a mount tree. + + * ``subtype_filter`` is a bitmask indicating the subtypes that are of + interest. Bit 0 of subtype_filter[0] corresponds to subtype 0, bit 1 to + subtype 1, and so on. + +If the argument to the ioctl() is NULL, then the filters will be removed and +all events from the watched sources will come through. + + +Userspace Code Example +====================== + +A buffer is created with something like the following:: + + pipe2(fds, O_TMPFILE); + ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256); + +It can then be set to receive keyring change notifications:: + + keyctl(KEYCTL_WATCH_KEY, KEY_SPEC_SESSION_KEYRING, fds[1], 0x01); + +The notifications can then be consumed by something like the following:: + + static void consumer(int rfd, struct watch_queue_buffer *buf) + { + unsigned char buffer[128]; + ssize_t buf_len; + + while (buf_len = read(rfd, buffer, sizeof(buffer)), + buf_len > 0 + ) { + void *p = buffer; + void *end = buffer + buf_len; + while (p < end) { + union { + struct watch_notification n; + unsigned char buf1[128]; + } n; + size_t largest, len; + + largest = end - p; + if (largest > 128) + largest = 128; + memcpy(&n, p, largest); + + len = (n->info & WATCH_INFO_LENGTH) >> + WATCH_INFO_LENGTH__SHIFT; + if (len == 0 || len > largest) + return; + + switch (n.n.type) { + case WATCH_TYPE_META: + got_meta(&n.n); + case WATCH_TYPE_KEY_NOTIFY: + saw_key_change(&n.n); + break; + } + + p += len; + } + } + } diff --git a/Documentation/index.rst b/Documentation/index.rst index 6b7e45348558..062cf88c2216 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -168,7 +168,6 @@ to ReStructured Text format, or are simply too old. tools/index staging/index - watch_queue Translations diff --git a/Documentation/watch_queue.rst b/Documentation/watch_queue.rst deleted file mode 100644 index 54f13ad5fc17..000000000000 --- a/Documentation/watch_queue.rst +++ /dev/null @@ -1,343 +0,0 @@ -============================== -General notification mechanism -============================== - -The general notification mechanism is built on top of the standard pipe driver -whereby it effectively splices notification messages from the kernel into pipes -opened by userspace. This can be used in conjunction with:: - - * Key/keyring notifications - - -The notifications buffers can be enabled by: - - "General setup"/"General notification queue" - (CONFIG_WATCH_QUEUE) - -This document has the following sections: - -.. contents:: :local: - - -Overview -======== - -This facility appears as a pipe that is opened in a special mode. The pipe's -internal ring buffer is used to hold messages that are generated by the kernel. -These messages are then read out by read(). Splice and similar are disabled on -such pipes due to them wanting to, under some circumstances, revert their -additions to the ring - which might end up interleaved with notification -messages. - -The owner of the pipe has to tell the kernel which sources it would like to -watch through that pipe. Only sources that have been connected to a pipe will -insert messages into it. Note that a source may be bound to multiple pipes and -insert messages into all of them simultaneously. - -Filters may also be emplaced on a pipe so that certain source types and -subevents can be ignored if they're not of interest. - -A message will be discarded if there isn't a slot available in the ring or if -no preallocated message buffer is available. In both of these cases, read() -will insert a WATCH_META_LOSS_NOTIFICATION message into the output buffer after -the last message currently in the buffer has been read. - -Note that when producing a notification, the kernel does not wait for the -consumers to collect it, but rather just continues on. This means that -notifications can be generated whilst spinlocks are held and also protects the -kernel from being held up indefinitely by a userspace malfunction. - - -Message Structure -================= - -Notification messages begin with a short header:: - - struct watch_notification { - __u32 type:24; - __u32 subtype:8; - __u32 info; - }; - -"type" indicates the source of the notification record and "subtype" indicates -the type of record from that source (see the Watch Sources section below). The -type may also be "WATCH_TYPE_META". This is a special record type generated -internally by the watch queue itself. There are two subtypes: - - * WATCH_META_REMOVAL_NOTIFICATION - * WATCH_META_LOSS_NOTIFICATION - -The first indicates that an object on which a watch was installed was removed -or destroyed and the second indicates that some messages have been lost. - -"info" indicates a bunch of things, including: - - * The length of the message in bytes, including the header (mask with - WATCH_INFO_LENGTH and shift by WATCH_INFO_LENGTH__SHIFT). This indicates - the size of the record, which may be between 8 and 127 bytes. - - * The watch ID (mask with WATCH_INFO_ID and shift by WATCH_INFO_ID__SHIFT). - This indicates that caller's ID of the watch, which may be between 0 - and 255. Multiple watches may share a queue, and this provides a means to - distinguish them. - - * A type-specific field (WATCH_INFO_TYPE_INFO). This is set by the - notification producer to indicate some meaning specific to the type and - subtype. - -Everything in info apart from the length can be used for filtering. - -The header can be followed by supplementary information. The format of this is -at the discretion is defined by the type and subtype. - - -Watch List (Notification Source) API -==================================== - -A "watch list" is a list of watchers that are subscribed to a source of -notifications. A list may be attached to an object (say a key or a superblock) -or may be global (say for device events). From a userspace perspective, a -non-global watch list is typically referred to by reference to the object it -belongs to (such as using KEYCTL_NOTIFY and giving it a key serial number to -watch that specific key). - -To manage a watch list, the following functions are provided: - - * :: - - void init_watch_list(struct watch_list *wlist, - void (*release_watch)(struct watch *wlist)); - - Initialise a watch list. If ``release_watch`` is not NULL, then this - indicates a function that should be called when the watch_list object is - destroyed to discard any references the watch list holds on the watched - object. - - * ``void remove_watch_list(struct watch_list *wlist);`` - - This removes all of the watches subscribed to a watch_list and frees them - and then destroys the watch_list object itself. - - -Watch Queue (Notification Output) API -===================================== - -A "watch queue" is the buffer allocated by an application that notification -records will be written into. The workings of this are hidden entirely inside -of the pipe device driver, but it is necessary to gain a reference to it to set -a watch. These can be managed with: - - * ``struct watch_queue *get_watch_queue(int fd);`` - - Since watch queues are indicated to the kernel by the fd of the pipe that - implements the buffer, userspace must hand that fd through a system call. - This can be used to look up an opaque pointer to the watch queue from the - system call. - - * ``void put_watch_queue(struct watch_queue *wqueue);`` - - This discards the reference obtained from ``get_watch_queue()``. - - -Watch Subscription API -====================== - -A "watch" is a subscription on a watch list, indicating the watch queue, and -thus the buffer, into which notification records should be written. The watch -queue object may also carry filtering rules for that object, as set by -userspace. Some parts of the watch struct can be set by the driver:: - - struct watch { - union { - u32 info_id; /* ID to be OR'd in to info field */ - ... - }; - void *private; /* Private data for the watched object */ - u64 id; /* Internal identifier */ - ... - }; - -The ``info_id`` value should be an 8-bit number obtained from userspace and -shifted by WATCH_INFO_ID__SHIFT. This is OR'd into the WATCH_INFO_ID field of -struct watch_notification::info when and if the notification is written into -the associated watch queue buffer. - -The ``private`` field is the driver's data associated with the watch_list and -is cleaned up by the ``watch_list::release_watch()`` method. - -The ``id`` field is the source's ID. Notifications that are posted with a -different ID are ignored. - -The following functions are provided to manage watches: - - * ``void init_watch(struct watch *watch, struct watch_queue *wqueue);`` - - Initialise a watch object, setting its pointer to the watch queue, using - appropriate barriering to avoid lockdep complaints. - - * ``int add_watch_to_object(struct watch *watch, struct watch_list *wlist);`` - - Subscribe a watch to a watch list (notification source). The - driver-settable fields in the watch struct must have been set before this - is called. - - * :: - - int remove_watch_from_object(struct watch_list *wlist, - struct watch_queue *wqueue, - u64 id, false); - - Remove a watch from a watch list, where the watch must match the specified - watch queue (``wqueue``) and object identifier (``id``). A notification - (``WATCH_META_REMOVAL_NOTIFICATION``) is sent to the watch queue to - indicate that the watch got removed. - - * ``int remove_watch_from_object(struct watch_list *wlist, NULL, 0, true);`` - - Remove all the watches from a watch list. It is expected that this will be - called preparatory to destruction and that the watch list will be - inaccessible to new watches by this point. A notification - (``WATCH_META_REMOVAL_NOTIFICATION``) is sent to the watch queue of each - subscribed watch to indicate that the watch got removed. - - -Notification Posting API -======================== - -To post a notification to watch list so that the subscribed watches can see it, -the following function should be used:: - - void post_watch_notification(struct watch_list *wlist, - struct watch_notification *n, - const struct cred *cred, - u64 id); - -The notification should be preformatted and a pointer to the header (``n``) -should be passed in. The notification may be larger than this and the size in -units of buffer slots is noted in ``n->info & WATCH_INFO_LENGTH``. - -The ``cred`` struct indicates the credentials of the source (subject) and is -passed to the LSMs, such as SELinux, to allow or suppress the recording of the -note in each individual queue according to the credentials of that queue -(object). - -The ``id`` is the ID of the source object (such as the serial number on a key). -Only watches that have the same ID set in them will see this notification. - - -Watch Sources -============= - -Any particular buffer can be fed from multiple sources. Sources include: - - * WATCH_TYPE_KEY_NOTIFY - - Notifications of this type indicate changes to keys and keyrings, including - the changes of keyring contents or the attributes of keys. - - See Documentation/security/keys/core.rst for more information. - - -Event Filtering -=============== - -Once a watch queue has been created, a set of filters can be applied to limit -the events that are received using:: - - struct watch_notification_filter filter = { - ... - }; - ioctl(fd, IOC_WATCH_QUEUE_SET_FILTER, &filter) - -The filter description is a variable of type:: - - struct watch_notification_filter { - __u32 nr_filters; - __u32 __reserved; - struct watch_notification_type_filter filters[]; - }; - -Where "nr_filters" is the number of filters in filters[] and "__reserved" -should be 0. The "filters" array has elements of the following type:: - - struct watch_notification_type_filter { - __u32 type; - __u32 info_filter; - __u32 info_mask; - __u32 subtype_filter[8]; - }; - -Where: - - * ``type`` is the event type to filter for and should be something like - "WATCH_TYPE_KEY_NOTIFY" - - * ``info_filter`` and ``info_mask`` act as a filter on the info field of the - notification record. The notification is only written into the buffer if:: - - (watch.info & info_mask) == info_filter - - This could be used, for example, to ignore events that are not exactly on - the watched point in a mount tree. - - * ``subtype_filter`` is a bitmask indicating the subtypes that are of - interest. Bit 0 of subtype_filter[0] corresponds to subtype 0, bit 1 to - subtype 1, and so on. - -If the argument to the ioctl() is NULL, then the filters will be removed and -all events from the watched sources will come through. - - -Userspace Code Example -====================== - -A buffer is created with something like the following:: - - pipe2(fds, O_TMPFILE); - ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256); - -It can then be set to receive keyring change notifications:: - - keyctl(KEYCTL_WATCH_KEY, KEY_SPEC_SESSION_KEYRING, fds[1], 0x01); - -The notifications can then be consumed by something like the following:: - - static void consumer(int rfd, struct watch_queue_buffer *buf) - { - unsigned char buffer[128]; - ssize_t buf_len; - - while (buf_len = read(rfd, buffer, sizeof(buffer)), - buf_len > 0 - ) { - void *p = buffer; - void *end = buffer + buf_len; - while (p < end) { - union { - struct watch_notification n; - unsigned char buf1[128]; - } n; - size_t largest, len; - - largest = end - p; - if (largest > 128) - largest = 128; - memcpy(&n, p, largest); - - len = (n->info & WATCH_INFO_LENGTH) >> - WATCH_INFO_LENGTH__SHIFT; - if (len == 0 || len > largest) - return; - - switch (n.n.type) { - case WATCH_TYPE_META: - got_meta(&n.n); - case WATCH_TYPE_KEY_NOTIFY: - saw_key_change(&n.n); - break; - } - - p += len; - } - } - } -- cgit From f643490e1bf941600f6105e4d27c49054fb6d562 Mon Sep 17 00:00:00 2001 From: Sean Anderson Date: Thu, 3 Mar 2022 17:35:42 -0500 Subject: dt-bindings: pwm: Add Xilinx AXI Timer This adds a binding for the Xilinx LogiCORE IP AXI Timer. This device is a "soft" block, so it has some parameters which would not be configurable in most hardware. This binding is usually automatically generated by Xilinx's tools, so the names and values of some properties should be kept as they are, if possible. In addition, this binding is already in the kernel at arch/microblaze/boot/dts/system.dts, and in user software such as QEMU. The existing driver uses the clock-frequency property, or alternatively the /cpus/timebase-frequency property as its frequency input. Because these properties are deprecated, they have not been included with this schema. All new bindings should use the clocks/clock-names properties to specify the parent clock. Because we need to init timer devices so early in boot, we determine if we should use the PWM driver or the clocksource/clockevent driver by the presence/absence, respectively, of #pwm-cells. Because both counters are used by the PWM, there is no need for a separate property specifying which counters are to be used for the PWM. Signed-off-by: Sean Anderson Reviewed-by: Rob Herring Signed-off-by: Thierry Reding --- .../devicetree/bindings/timer/xlnx,xps-timer.yaml | 92 ++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml b/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml new file mode 100644 index 000000000000..dd168d41d2e0 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/xlnx,xps-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx LogiCORE IP AXI Timer Device Tree Binding + +maintainers: + - Sean Anderson + +properties: + compatible: + contains: + const: xlnx,xps-timer-1.00.a + + clocks: + maxItems: 1 + + clock-names: + const: s_axi_aclk + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + '#pwm-cells': true + + xlnx,count-width: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16, 32] + default: 32 + description: + The width of the counter(s), in bits. + + xlnx,one-timer-only: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1 ] + description: + Whether only one timer is present in this block. + +required: + - compatible + - reg + - xlnx,one-timer-only + +allOf: + - if: + required: + - '#pwm-cells' + then: + allOf: + - required: + - clocks + - properties: + xlnx,one-timer-only: + const: 0 + else: + required: + - interrupts + - if: + required: + - clocks + then: + required: + - clock-names + +additionalProperties: false + +examples: + - | + timer@800e0000 { + clock-names = "s_axi_aclk"; + clocks = <&zynqmp_clk 71>; + compatible = "xlnx,xps-timer-1.00.a"; + reg = <0x800e0000 0x10000>; + interrupts = <0 39 2>; + xlnx,count-width = <16>; + xlnx,one-timer-only = <0x0>; + }; + + timer@800f0000 { + #pwm-cells = <0>; + clock-names = "s_axi_aclk"; + clocks = <&zynqmp_clk 71>; + compatible = "xlnx,xps-timer-1.00.a"; + reg = <0x800e0000 0x10000>; + xlnx,count-width = <32>; + xlnx,one-timer-only = <0x0>; + }; -- cgit From 1a406a38bc1d66f68bac30cf8d83fcff621ff79c Mon Sep 17 00:00:00 2001 From: Sergiu Moga Date: Mon, 7 Mar 2022 17:36:55 +0200 Subject: dt-bindings: pwm: Convert atmel pwm to json-schema Convert PWM binding for Atmel/Microchip SoCs to Device Tree Schema format. Signed-off-by: Sergiu Moga Reviewed-by: Krzysztof Kozlowski Signed-off-by: Thierry Reding --- .../devicetree/bindings/pwm/atmel,at91sam-pwm.yaml | 42 ++++++++++++++++++++++ .../devicetree/bindings/pwm/atmel-pwm.txt | 35 ------------------ 2 files changed, 42 insertions(+), 35 deletions(-) create mode 100644 Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml delete mode 100644 Documentation/devicetree/bindings/pwm/atmel-pwm.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml b/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml new file mode 100644 index 000000000000..5e8bb5a8095d --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/atmel,at91sam-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel/Microchip PWM controller + +maintainers: + - Claudiu Beznea + +allOf: + - $ref: "pwm.yaml#" + +properties: + compatible: + enum: + - atmel,at91sam9rl-pwm + - atmel,sama5d3-pwm + - atmel,sama5d2-pwm + - microchip,sam9x60-pwm + + reg: + maxItems: 1 + + "#pwm-cells": + const: 3 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + pwm0: pwm@f8034000 { + compatible = "atmel,at91sam9rl-pwm"; + reg = <0xf8034000 0x400>; + #pwm-cells = <3>; + }; diff --git a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt deleted file mode 100644 index fbb5325be1f0..000000000000 --- a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt +++ /dev/null @@ -1,35 +0,0 @@ -Atmel PWM controller - -Required properties: - - compatible: should be one of: - - "atmel,at91sam9rl-pwm" - - "atmel,sama5d3-pwm" - - "atmel,sama5d2-pwm" - - "microchip,sam9x60-pwm" - - reg: physical base address and length of the controller's registers - - #pwm-cells: Should be 3. See pwm.yaml in this directory for a - description of the cells format. - -Example: - - pwm0: pwm@f8034000 { - compatible = "atmel,at91sam9rl-pwm"; - reg = <0xf8034000 0x400>; - #pwm-cells = <3>; - }; - - pwmleds { - compatible = "pwm-leds"; - - d1 { - label = "d1"; - pwms = <&pwm0 3 5000 0> - max-brightness = <255>; - }; - - d2 { - label = "d2"; - pwms = <&pwm0 1 5000 1> - max-brightness = <255>; - }; - }; -- cgit From f30673a9df34931cbfb9b51da00dd185a3cd4566 Mon Sep 17 00:00:00 2001 From: Sergiu Moga Date: Mon, 7 Mar 2022 17:36:56 +0200 Subject: dt-bindings: pwm: at91: Add SAMA7G5 compatible strings list Add compatible strings list for SAMA7G5. Signed-off-by: Sergiu Moga Reviewed-by: Krzysztof Kozlowski Signed-off-by: Thierry Reding --- .../devicetree/bindings/pwm/atmel,at91sam-pwm.yaml | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml b/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml index 5e8bb5a8095d..ab45df80345d 100644 --- a/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml @@ -15,11 +15,16 @@ allOf: properties: compatible: - enum: - - atmel,at91sam9rl-pwm - - atmel,sama5d3-pwm - - atmel,sama5d2-pwm - - microchip,sam9x60-pwm + oneOf: + - items: + - enum: + - atmel,at91sam9rl-pwm + - atmel,sama5d3-pwm + - atmel,sama5d2-pwm + - microchip,sam9x60-pwm + - items: + - const: microchip,sama7g5-pwm + - const: atmel,sama5d2-pwm reg: maxItems: 1 -- cgit From 15452ce3c9467bdd15002f5bc56cd2c13e7b1aa0 Mon Sep 17 00:00:00 2001 From: Hammer Hsieh Date: Tue, 22 Mar 2022 18:43:00 +0800 Subject: dt-bindings: pwm: Add bindings doc for Sunplus SoC SP7021 PWM Driver Add bindings doc for Sunplus SoC SP7021 PWM Driver Reviewed-by: Krzysztof Kozlowski Signed-off-by: Hammer Hsieh Acked-by: Rob Herring Signed-off-by: Thierry Reding --- .../bindings/pwm/sunplus,sp7021-pwm.yaml | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/sunplus,sp7021-pwm.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/sunplus,sp7021-pwm.yaml b/Documentation/devicetree/bindings/pwm/sunplus,sp7021-pwm.yaml new file mode 100644 index 000000000000..d4fc9e8db1d1 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/sunplus,sp7021-pwm.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) Sunplus Co., Ltd. 2021 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/sunplus,sp7021-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sunplus SoC SP7021 PWM Controller + +maintainers: + - Hammer Hsieh + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + const: sunplus,sp7021-pwm + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + '#pwm-cells': + const: 2 + +unevaluatedProperties: false + +required: + - reg + - clocks + +examples: + - | + pwm: pwm@9c007a00 { + compatible = "sunplus,sp7021-pwm"; + reg = <0x9c007a00 0x80>; + clocks = <&clkc 0xa2>; + #pwm-cells = <2>; + }; -- cgit From b09b179bac0aa3d58d79729260a7492df8a1e312 Mon Sep 17 00:00:00 2001 From: Xinlei Lee Date: Mon, 18 Apr 2022 20:20:52 +0800 Subject: dt-bindings: pwm: Convert pwm-mtk-disp.txt to mediatek,pwm-disp.yaml format Convert pwm-mtk-disp.txt to mediatek,pwm-disp.yaml format as suggested by maintainer. Signed-off-by: Xinlei Lee Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Miles Chen Reviewed-by: Rob Herring Signed-off-by: Thierry Reding --- .../devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 66 ++++++++++++++++++++++ .../devicetree/bindings/pwm/pwm-mtk-disp.txt | 45 --------------- 2 files changed, 66 insertions(+), 45 deletions(-) create mode 100644 Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml new file mode 100644 index 000000000000..36f877f819fa --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/mediatek,pwm-disp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek DISP_PWM Controller Device Tree Bindings + +maintainers: + - Jitao Shi + - Xinlei Lee + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + oneOf: + - enum: + - mediatek,mt2701-disp-pwm + - mediatek,mt6595-disp-pwm + - mediatek,mt8173-disp-pwm + - mediatek,mt8183-disp-pwm + - items: + - const: mediatek,mt8167-disp-pwm + - const: mediatek,mt8173-disp-pwm + + reg: + maxItems: 1 + + "#pwm-cells": + const: 2 + + clocks: + items: + - description: Main Clock + - description: Mm Clock + + clock-names: + items: + - const: main + - const: mm + +required: + - compatible + - reg + - "#pwm-cells" + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + #include + #include + + pwm0: pwm@1401e000 { + compatible = "mediatek,mt8173-disp-pwm"; + reg = <0x1401e000 0x1000>; + #pwm-cells = <2>; + clocks = <&mmsys CLK_MM_DISP_PWM026M>, + <&mmsys CLK_MM_DISP_PWM0MM>; + clock-names = "main", "mm"; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt deleted file mode 100644 index 691e58b6c223..000000000000 --- a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt +++ /dev/null @@ -1,45 +0,0 @@ -MediaTek display PWM controller - -Required properties: - - compatible: should be "mediatek,-disp-pwm": - - "mediatek,mt2701-disp-pwm": found on mt2701 SoC. - - "mediatek,mt6595-disp-pwm": found on mt6595 SoC. - - "mediatek,mt8167-disp-pwm", "mediatek,mt8173-disp-pwm": found on mt8167 SoC. - - "mediatek,mt8173-disp-pwm": found on mt8173 SoC. - - "mediatek,mt8183-disp-pwm": found on mt8183 SoC.$ - - reg: physical base address and length of the controller's registers. - - #pwm-cells: must be 2. See pwm.yaml in this directory for a description of - the cell format. - - clocks: phandle and clock specifier of the PWM reference clock. - - clock-names: must contain the following: - - "main": clock used to generate PWM signals. - - "mm": sync signals from the modules of mmsys. - - pinctrl-names: Must contain a "default" entry. - - pinctrl-0: One property must exist for each entry in pinctrl-names. - See pinctrl/pinctrl-bindings.txt for details of the property values. - -Example: - pwm0: pwm@1401e000 { - compatible = "mediatek,mt8173-disp-pwm", - "mediatek,mt6595-disp-pwm"; - reg = <0 0x1401e000 0 0x1000>; - #pwm-cells = <2>; - clocks = <&mmsys CLK_MM_DISP_PWM026M>, - <&mmsys CLK_MM_DISP_PWM0MM>; - clock-names = "main", "mm"; - pinctrl-names = "default"; - pinctrl-0 = <&disp_pwm0_pins>; - }; - - backlight_lcd: backlight_lcd { - compatible = "pwm-backlight"; - pwms = <&pwm0 0 1000000>; - brightness-levels = < - 0 16 32 48 64 80 96 112 - 128 144 160 176 192 208 224 240 - 255 - >; - default-brightness-level = <9>; - power-supply = <&mt6397_vio18_reg>; - enable-gpios = <&pio 95 GPIO_ACTIVE_HIGH>; - }; -- cgit From b8ba2b42b0e9cf6d2788e423f8fe2ba4fcc2539d Mon Sep 17 00:00:00 2001 From: Xinlei Lee Date: Mon, 18 Apr 2022 20:20:53 +0800 Subject: dt-bindings: pwm: Add compatible for MediaTek MT8192 Add dt-binding documentation of pwm for MediaTek MT8192 SoC. Signed-off-by: Xinlei Lee Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Krzysztof Kozlowski Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml index 36f877f819fa..4bfa8eb42186 100644 --- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml @@ -24,6 +24,10 @@ properties: - items: - const: mediatek,mt8167-disp-pwm - const: mediatek,mt8173-disp-pwm + - items: + - enum: + - mediatek,mt8192-disp-pwm + - const: mediatek,mt8183-disp-pwm reg: maxItems: 1 -- cgit From 7eafddce08617b4fdbd9485fa88bb749c8c7125a Mon Sep 17 00:00:00 2001 From: Xinlei Lee Date: Mon, 18 Apr 2022 20:20:54 +0800 Subject: dt-bindings: pwm: Add compatible for MediaTek MT8195 Add dt-binding documentation of pwm for MediaTek MT8195 SoC. Signed-off-by: Xinlei Lee Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Krzysztof Kozlowski Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml index 4bfa8eb42186..e5da918eaa33 100644 --- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml @@ -27,6 +27,7 @@ properties: - items: - enum: - mediatek,mt8192-disp-pwm + - mediatek,mt8195-disp-pwm - const: mediatek,mt8183-disp-pwm reg: -- cgit From 6ddb156ba4749a64293b5c4079406de178e2e5cd Mon Sep 17 00:00:00 2001 From: Xinlei Lee Date: Mon, 18 Apr 2022 20:20:55 +0800 Subject: dt-bindings: pwm: Add compatible for MediaTek MT8186 Add dt-binding documentation of pwm for MediaTek MT8186 SoC. Signed-off-by: Xinlei Lee Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Krzysztof Kozlowski Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml index e5da918eaa33..4b71bd668d33 100644 --- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml @@ -26,6 +26,7 @@ properties: - const: mediatek,mt8173-disp-pwm - items: - enum: + - mediatek,mt8186-disp-pwm - mediatek,mt8192-disp-pwm - mediatek,mt8195-disp-pwm - const: mediatek,mt8183-disp-pwm -- cgit From 2bf8ee0faa988b5cec3503ebf2f970a0e84d24ee Mon Sep 17 00:00:00 2001 From: Xinlei Lee Date: Mon, 18 Apr 2022 20:20:56 +0800 Subject: dt-bindings: pwm: Add interrupts property for MediaTek MT8192 Add interrupts property of pwm for MediaTek MT8192 SoC. Signed-off-by: Xinlei Lee Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml index 4b71bd668d33..e4fe2d1bfef5 100644 --- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml @@ -37,6 +37,9 @@ properties: "#pwm-cells": const: 2 + interrupts: + maxItems: 1 + clocks: items: - description: Main Clock -- cgit From 96d32e630935c1636b0236c88779e81eff120e0a Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Tue, 19 Apr 2022 12:22:12 +0100 Subject: arm64/sme: Provide ABI documentation for SME Provide ABI documentation for SME similar to that for SVE. Due to the very large overlap around streaming SVE mode in both implementation and interfaces documentation for streaming mode SVE is added to the SVE document rather than the SME one. Signed-off-by: Mark Brown Reviewed-by: Catalin Marinas Reviewed-by: Szabolcs Nagy Link: https://lore.kernel.org/r/20220419112247.711548-5-broonie@kernel.org Signed-off-by: Catalin Marinas --- Documentation/arm64/index.rst | 1 + Documentation/arm64/sme.rst | 428 ++++++++++++++++++++++++++++++++++++++++++ Documentation/arm64/sve.rst | 70 ++++++- 3 files changed, 489 insertions(+), 10 deletions(-) create mode 100644 Documentation/arm64/sme.rst (limited to 'Documentation') diff --git a/Documentation/arm64/index.rst b/Documentation/arm64/index.rst index 4f840bac083e..ae21f8118830 100644 --- a/Documentation/arm64/index.rst +++ b/Documentation/arm64/index.rst @@ -21,6 +21,7 @@ ARM64 Architecture perf pointer-authentication silicon-errata + sme sve tagged-address-abi tagged-pointers diff --git a/Documentation/arm64/sme.rst b/Documentation/arm64/sme.rst new file mode 100644 index 000000000000..8ba677b87e90 --- /dev/null +++ b/Documentation/arm64/sme.rst @@ -0,0 +1,428 @@ +=================================================== +Scalable Matrix Extension support for AArch64 Linux +=================================================== + +This document outlines briefly the interface provided to userspace by Linux in +order to support use of the ARM Scalable Matrix Extension (SME). + +This is an outline of the most important features and issues only and not +intended to be exhaustive. It should be read in conjunction with the SVE +documentation in sve.rst which provides details on the Streaming SVE mode +included in SME. + +This document does not aim to describe the SME architecture or programmer's +model. To aid understanding, a minimal description of relevant programmer's +model features for SME is included in Appendix A. + + +1. General +----------- + +* PSTATE.SM, PSTATE.ZA, the streaming mode vector length, the ZA + register state and TPIDR2_EL0 are tracked per thread. + +* The presence of SME is reported to userspace via HWCAP2_SME in the aux vector + AT_HWCAP2 entry. Presence of this flag implies the presence of the SME + instructions and registers, and the Linux-specific system interfaces + described in this document. SME is reported in /proc/cpuinfo as "sme". + +* Support for the execution of SME instructions in userspace can also be + detected by reading the CPU ID register ID_AA64PFR1_EL1 using an MRS + instruction, and checking that the value of the SME field is nonzero. [3] + + It does not guarantee the presence of the system interfaces described in the + following sections: software that needs to verify that those interfaces are + present must check for HWCAP2_SME instead. + +* There are a number of optional SME features, presence of these is reported + through AT_HWCAP2 through: + + HWCAP2_SME_I16I64 + HWCAP2_SME_F64F64 + HWCAP2_SME_I8I32 + HWCAP2_SME_F16F32 + HWCAP2_SME_B16F32 + HWCAP2_SME_F32F32 + HWCAP2_SME_FA64 + + This list may be extended over time as the SME architecture evolves. + + These extensions are also reported via the CPU ID register ID_AA64SMFR0_EL1, + which userspace can read using an MRS instruction. See elf_hwcaps.txt and + cpu-feature-registers.txt for details. + +* Debuggers should restrict themselves to interacting with the target via the + NT_ARM_SVE, NT_ARM_SSVE and NT_ARM_ZA regsets. The recommended way + of detecting support for these regsets is to connect to a target process + first and then attempt a + + ptrace(PTRACE_GETREGSET, pid, NT_ARM_, &iov). + +* Whenever ZA register values are exchanged in memory between userspace and + the kernel, the register value is encoded in memory as a series of horizontal + vectors from 0 to VL/8-1 stored in the same endianness invariant format as is + used for SVE vectors. + +* On thread creation TPIDR2_EL0 is preserved unless CLONE_SETTLS is specified, + in which case it is set to 0. + +2. Vector lengths +------------------ + +SME defines a second vector length similar to the SVE vector length which is +controls the size of the streaming mode SVE vectors and the ZA matrix array. +The ZA matrix is square with each side having as many bytes as a streaming +mode SVE vector. + + +3. Sharing of streaming and non-streaming mode SVE state +--------------------------------------------------------- + +It is implementation defined which if any parts of the SVE state are shared +between streaming and non-streaming modes. When switching between modes +via software interfaces such as ptrace if no register content is provided as +part of switching no state will be assumed to be shared and everything will +be zeroed. + + +4. System call behaviour +------------------------- + +* On syscall PSTATE.ZA is preserved, if PSTATE.ZA==1 then the contents of the + ZA matrix are preserved. + +* On syscall PSTATE.SM will be cleared and the SVE registers will be handled + as per the standard SVE ABI. + +* Neither the SVE registers nor ZA are used to pass arguments to or receive + results from any syscall. + +* On process creation (eg, clone()) the newly created process will have + PSTATE.SM cleared. + +* All other SME state of a thread, including the currently configured vector + length, the state of the PR_SME_VL_INHERIT flag, and the deferred vector + length (if any), is preserved across all syscalls, subject to the specific + exceptions for execve() described in section 6. + + +5. Signal handling +------------------- + +* Signal handlers are invoked with streaming mode and ZA disabled. + +* A new signal frame record za_context encodes the ZA register contents on + signal delivery. [1] + +* The signal frame record for ZA always contains basic metadata, in particular + the thread's vector length (in za_context.vl). + +* The ZA matrix may or may not be included in the record, depending on + the value of PSTATE.ZA. The registers are present if and only if: + za_context.head.size >= ZA_SIG_CONTEXT_SIZE(sve_vq_from_vl(za_context.vl)) + in which case PSTATE.ZA == 1. + +* If matrix data is present, the remainder of the record has a vl-dependent + size and layout. Macros ZA_SIG_* are defined [1] to facilitate access to + them. + +* The matrix is stored as a series of horizontal vectors in the same format as + is used for SVE vectors. + +* If the ZA context is too big to fit in sigcontext.__reserved[], then extra + space is allocated on the stack, an extra_context record is written in + __reserved[] referencing this space. za_context is then written in the + extra space. Refer to [1] for further details about this mechanism. + + +5. Signal return +----------------- + +When returning from a signal handler: + +* If there is no za_context record in the signal frame, or if the record is + present but contains no register data as described in the previous section, + then ZA is disabled. + +* If za_context is present in the signal frame and contains matrix data then + PSTATE.ZA is set to 1 and ZA is populated with the specified data. + +* The vector length cannot be changed via signal return. If za_context.vl in + the signal frame does not match the current vector length, the signal return + attempt is treated as illegal, resulting in a forced SIGSEGV. + + +6. prctl extensions +-------------------- + +Some new prctl() calls are added to allow programs to manage the SME vector +length: + +prctl(PR_SME_SET_VL, unsigned long arg) + + Sets the vector length of the calling thread and related flags, where + arg == vl | flags. Other threads of the calling process are unaffected. + + vl is the desired vector length, where sve_vl_valid(vl) must be true. + + flags: + + PR_SME_VL_INHERIT + + Inherit the current vector length across execve(). Otherwise, the + vector length is reset to the system default at execve(). (See + Section 9.) + + PR_SME_SET_VL_ONEXEC + + Defer the requested vector length change until the next execve() + performed by this thread. + + The effect is equivalent to implicit execution of the following + call immediately after the next execve() (if any) by the thread: + + prctl(PR_SME_SET_VL, arg & ~PR_SME_SET_VL_ONEXEC) + + This allows launching of a new program with a different vector + length, while avoiding runtime side effects in the caller. + + Without PR_SME_SET_VL_ONEXEC, the requested change takes effect + immediately. + + + Return value: a nonnegative on success, or a negative value on error: + EINVAL: SME not supported, invalid vector length requested, or + invalid flags. + + + On success: + + * Either the calling thread's vector length or the deferred vector length + to be applied at the next execve() by the thread (dependent on whether + PR_SME_SET_VL_ONEXEC is present in arg), is set to the largest value + supported by the system that is less than or equal to vl. If vl == + SVE_VL_MAX, the value set will be the largest value supported by the + system. + + * Any previously outstanding deferred vector length change in the calling + thread is cancelled. + + * The returned value describes the resulting configuration, encoded as for + PR_SME_GET_VL. The vector length reported in this value is the new + current vector length for this thread if PR_SME_SET_VL_ONEXEC was not + present in arg; otherwise, the reported vector length is the deferred + vector length that will be applied at the next execve() by the calling + thread. + + * Changing the vector length causes all of ZA, P0..P15, FFR and all bits of + Z0..Z31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become + unspecified, including both streaming and non-streaming SVE state. + Calling PR_SME_SET_VL with vl equal to the thread's current vector + length, or calling PR_SME_SET_VL with the PR_SVE_SET_VL_ONEXEC flag, + does not constitute a change to the vector length for this purpose. + + * Changing the vector length causes PSTATE.ZA and PSTATE.SM to be cleared. + Calling PR_SME_SET_VL with vl equal to the thread's current vector + length, or calling PR_SME_SET_VL with the PR_SVE_SET_VL_ONEXEC flag, + does not constitute a change to the vector length for this purpose. + + +prctl(PR_SME_GET_VL) + + Gets the vector length of the calling thread. + + The following flag may be OR-ed into the result: + + PR_SME_VL_INHERIT + + Vector length will be inherited across execve(). + + There is no way to determine whether there is an outstanding deferred + vector length change (which would only normally be the case between a + fork() or vfork() and the corresponding execve() in typical use). + + To extract the vector length from the result, bitwise and it with + PR_SME_VL_LEN_MASK. + + Return value: a nonnegative value on success, or a negative value on error: + EINVAL: SME not supported. + + +7. ptrace extensions +--------------------- + +* A new regset NT_ARM_SSVE is defined for access to streaming mode SVE + state via PTRACE_GETREGSET and PTRACE_SETREGSET, this is documented in + sve.rst. + +* A new regset NT_ARM_ZA is defined for ZA state for access to ZA state via + PTRACE_GETREGSET and PTRACE_SETREGSET. + + Refer to [2] for definitions. + +The regset data starts with struct user_za_header, containing: + + size + + Size of the complete regset, in bytes. + This depends on vl and possibly on other things in the future. + + If a call to PTRACE_GETREGSET requests less data than the value of + size, the caller can allocate a larger buffer and retry in order to + read the complete regset. + + max_size + + Maximum size in bytes that the regset can grow to for the target + thread. The regset won't grow bigger than this even if the target + thread changes its vector length etc. + + vl + + Target thread's current streaming vector length, in bytes. + + max_vl + + Maximum possible streaming vector length for the target thread. + + flags + + Zero or more of the following flags, which have the same + meaning and behaviour as the corresponding PR_SET_VL_* flags: + + SME_PT_VL_INHERIT + + SME_PT_VL_ONEXEC (SETREGSET only). + +* The effects of changing the vector length and/or flags are equivalent to + those documented for PR_SME_SET_VL. + + The caller must make a further GETREGSET call if it needs to know what VL is + actually set by SETREGSET, unless is it known in advance that the requested + VL is supported. + +* The size and layout of the payload depends on the header fields. The + SME_PT_ZA_*() macros are provided to facilitate access to the data. + +* In either case, for SETREGSET it is permissible to omit the payload, in which + case the vector length and flags are changed and PSTATE.ZA is set to 0 + (along with any consequences of those changes). If a payload is provided + then PSTATE.ZA will be set to 1. + +* For SETREGSET, if the requested VL is not supported, the effect will be the + same as if the payload were omitted, except that an EIO error is reported. + No attempt is made to translate the payload data to the correct layout + for the vector length actually set. It is up to the caller to translate the + payload layout for the actual VL and retry. + +* The effect of writing a partial, incomplete payload is unspecified. + + +8. ELF coredump extensions +--------------------------- + +* NT_ARM_SSVE notes will be added to each coredump for + each thread of the dumped process. The contents will be equivalent to the + data that would have been read if a PTRACE_GETREGSET of the corresponding + type were executed for each thread when the coredump was generated. + +* A NT_ARM_ZA note will be added to each coredump for each thread of the + dumped process. The contents will be equivalent to the data that would have + been read if a PTRACE_GETREGSET of NT_ARM_ZA were executed for each thread + when the coredump was generated. + + +9. System runtime configuration +-------------------------------- + +* To mitigate the ABI impact of expansion of the signal frame, a policy + mechanism is provided for administrators, distro maintainers and developers + to set the default vector length for userspace processes: + +/proc/sys/abi/sme_default_vector_length + + Writing the text representation of an integer to this file sets the system + default vector length to the specified value, unless the value is greater + than the maximum vector length supported by the system in which case the + default vector length is set to that maximum. + + The result can be determined by reopening the file and reading its + contents. + + At boot, the default vector length is initially set to 32 or the maximum + supported vector length, whichever is smaller and supported. This + determines the initial vector length of the init process (PID 1). + + Reading this file returns the current system default vector length. + +* At every execve() call, the new vector length of the new process is set to + the system default vector length, unless + + * PR_SME_VL_INHERIT (or equivalently SME_PT_VL_INHERIT) is set for the + calling thread, or + + * a deferred vector length change is pending, established via the + PR_SME_SET_VL_ONEXEC flag (or SME_PT_VL_ONEXEC). + +* Modifying the system default vector length does not affect the vector length + of any existing process or thread that does not make an execve() call. + + +Appendix A. SME programmer's model (informative) +================================================= + +This section provides a minimal description of the additions made by SVE to the +ARMv8-A programmer's model that are relevant to this document. + +Note: This section is for information only and not intended to be complete or +to replace any architectural specification. + +A.1. Registers +--------------- + +In A64 state, SME adds the following: + +* A new mode, streaming mode, in which a subset of the normal FPSIMD and SVE + features are available. When supported EL0 software may enter and leave + streaming mode at any time. + + For best system performance it is strongly encouraged for software to enable + streaming mode only when it is actively being used. + +* A new vector length controlling the size of ZA and the Z registers when in + streaming mode, separately to the vector length used for SVE when not in + streaming mode. There is no requirement that either the currently selected + vector length or the set of vector lengths supported for the two modes in + a given system have any relationship. The streaming mode vector length + is referred to as SVL. + +* A new ZA matrix register. This is a square matrix of SVLxSVL bits. Most + operations on ZA require that streaming mode be enabled but ZA can be + enabled without streaming mode in order to load, save and retain data. + + For best system performance it is strongly encouraged for software to enable + ZA only when it is actively being used. + +* Two new 1 bit fields in PSTATE which may be controlled via the SMSTART and + SMSTOP instructions or by access to the SVCR system register: + + * PSTATE.ZA, if this is 1 then the ZA matrix is accessible and has valid + data while if it is 0 then ZA can not be accessed. When PSTATE.ZA is + changed from 0 to 1 all bits in ZA are cleared. + + * PSTATE.SM, if this is 1 then the PE is in streaming mode. When the value + of PSTATE.SM is changed then it is implementation defined if the subset + of the floating point register bits valid in both modes may be retained. + Any other bits will be cleared. + + +References +========== + +[1] arch/arm64/include/uapi/asm/sigcontext.h + AArch64 Linux signal ABI definitions + +[2] arch/arm64/include/uapi/asm/ptrace.h + AArch64 Linux ptrace ABI definitions + +[3] Documentation/arm64/cpu-feature-registers.rst diff --git a/Documentation/arm64/sve.rst b/Documentation/arm64/sve.rst index 9d9a4de5bc34..93c2c2990584 100644 --- a/Documentation/arm64/sve.rst +++ b/Documentation/arm64/sve.rst @@ -7,7 +7,9 @@ Author: Dave Martin Date: 4 August 2017 This document outlines briefly the interface provided to userspace by Linux in -order to support use of the ARM Scalable Vector Extension (SVE). +order to support use of the ARM Scalable Vector Extension (SVE), including +interactions with Streaming SVE mode added by the Scalable Matrix Extension +(SME). This is an outline of the most important features and issues only and not intended to be exhaustive. @@ -23,6 +25,10 @@ model features for SVE is included in Appendix A. * SVE registers Z0..Z31, P0..P15 and FFR and the current vector length VL, are tracked per-thread. +* In streaming mode FFR is not accessible unless HWCAP2_SME_FA64 is present + in the system, when it is not supported and these interfaces are used to + access streaming mode FFR is read and written as zero. + * The presence of SVE is reported to userspace via HWCAP_SVE in the aux vector AT_HWCAP entry. Presence of this flag implies the presence of the SVE instructions and registers, and the Linux-specific system interfaces @@ -53,10 +59,19 @@ model features for SVE is included in Appendix A. which userspace can read using an MRS instruction. See elf_hwcaps.txt and cpu-feature-registers.txt for details. +* On hardware that supports the SME extensions, HWCAP2_SME will also be + reported in the AT_HWCAP2 aux vector entry. Among other things SME adds + streaming mode which provides a subset of the SVE feature set using a + separate SME vector length and the same Z/V registers. See sme.rst + for more details. + * Debuggers should restrict themselves to interacting with the target via the NT_ARM_SVE regset. The recommended way of detecting support for this regset is to connect to a target process first and then attempt a - ptrace(PTRACE_GETREGSET, pid, NT_ARM_SVE, &iov). + ptrace(PTRACE_GETREGSET, pid, NT_ARM_SVE, &iov). Note that when SME is + present and streaming SVE mode is in use the FPSIMD subset of registers + will be read via NT_ARM_SVE and NT_ARM_SVE writes will exit streaming mode + in the target. * Whenever SVE scalable register values (Zn, Pn, FFR) are exchanged in memory between userspace and the kernel, the register value is encoded in memory in @@ -126,6 +141,11 @@ the SVE instruction set architecture. are only present in fpsimd_context. For convenience, the content of V0..V31 is duplicated between sve_context and fpsimd_context. +* The record contains a flag field which includes a flag SVE_SIG_FLAG_SM which + if set indicates that the thread is in streaming mode and the vector length + and register data (if present) describe the streaming SVE data and vector + length. + * The signal frame record for SVE always contains basic metadata, in particular the thread's vector length (in sve_context.vl). @@ -170,6 +190,11 @@ When returning from a signal handler: the signal frame does not match the current vector length, the signal return attempt is treated as illegal, resulting in a forced SIGSEGV. +* It is permitted to enter or leave streaming mode by setting or clearing + the SVE_SIG_FLAG_SM flag but applications should take care to ensure that + when doing so sve_context.vl and any register data are appropriate for the + vector length in the new mode. + 6. prctl extensions -------------------- @@ -265,8 +290,14 @@ prctl(PR_SVE_GET_VL) 7. ptrace extensions --------------------- -* A new regset NT_ARM_SVE is defined for use with PTRACE_GETREGSET and - PTRACE_SETREGSET. +* New regsets NT_ARM_SVE and NT_ARM_SSVE are defined for use with + PTRACE_GETREGSET and PTRACE_SETREGSET. NT_ARM_SSVE describes the + streaming mode SVE registers and NT_ARM_SVE describes the + non-streaming mode SVE registers. + + In this description a register set is referred to as being "live" when + the target is in the appropriate streaming or non-streaming mode and is + using data beyond the subset shared with the FPSIMD Vn registers. Refer to [2] for definitions. @@ -297,7 +328,7 @@ The regset data starts with struct user_sve_header, containing: flags - either + at most one of SVE_PT_REGS_FPSIMD @@ -331,6 +362,10 @@ The regset data starts with struct user_sve_header, containing: SVE_PT_VL_ONEXEC (SETREGSET only). + If neither FPSIMD nor SVE flags are provided then no register + payload is available, this is only possible when SME is implemented. + + * The effects of changing the vector length and/or flags are equivalent to those documented for PR_SVE_SET_VL. @@ -346,6 +381,13 @@ The regset data starts with struct user_sve_header, containing: case only the vector length and flags are changed (along with any consequences of those changes). +* In systems supporting SME when in streaming mode a GETREGSET for + NT_REG_SVE will return only the user_sve_header with no register data, + similarly a GETREGSET for NT_REG_SSVE will not return any register data + when not in streaming mode. + +* A GETREGSET for NT_ARM_SSVE will never return SVE_PT_REGS_FPSIMD. + * For SETREGSET, if an SVE_PT_REGS_SVE payload is present and the requested VL is not supported, the effect will be the same as if the payload were omitted, except that an EIO error is reported. No @@ -355,17 +397,25 @@ The regset data starts with struct user_sve_header, containing: unspecified. It is up to the caller to translate the payload layout for the actual VL and retry. +* Where SME is implemented it is not possible to GETREGSET the register + state for normal SVE when in streaming mode, nor the streaming mode + register state when in normal mode, regardless of the implementation defined + behaviour of the hardware for sharing data between the two modes. + +* Any SETREGSET of NT_ARM_SVE will exit streaming mode if the target was in + streaming mode and any SETREGSET of NT_ARM_SSVE will enter streaming mode + if the target was not in streaming mode. + * The effect of writing a partial, incomplete payload is unspecified. 8. ELF coredump extensions --------------------------- -* A NT_ARM_SVE note will be added to each coredump for each thread of the - dumped process. The contents will be equivalent to the data that would have - been read if a PTRACE_GETREGSET of NT_ARM_SVE were executed for each thread - when the coredump was generated. - +* NT_ARM_SVE and NT_ARM_SSVE notes will be added to each coredump for + each thread of the dumped process. The contents will be equivalent to the + data that would have been read if a PTRACE_GETREGSET of the corresponding + type were executed for each thread when the coredump was generated. 9. System runtime configuration -------------------------------- -- cgit From 5e64b862c4823ab53aac028042abd918c2f27041 Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Tue, 19 Apr 2022 12:22:16 +0100 Subject: arm64/sme: Basic enumeration support This patch introduces basic cpufeature support for discovering the presence of the Scalable Matrix Extension. Signed-off-by: Mark Brown Reviewed-by: Catalin Marinas Link: https://lore.kernel.org/r/20220419112247.711548-9-broonie@kernel.org Signed-off-by: Catalin Marinas --- Documentation/arm64/elf_hwcaps.rst | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst index a8f30963e550..f8d818eaaff5 100644 --- a/Documentation/arm64/elf_hwcaps.rst +++ b/Documentation/arm64/elf_hwcaps.rst @@ -264,6 +264,39 @@ HWCAP2_MTE3 Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described by Documentation/arm64/memory-tagging-extension.rst. +HWCAP2_SME + + Functionality implied by ID_AA64PFR1_EL1.SME == 0b0001, as described + by Documentation/arm64/sme.rst. + +HWCAP2_SME_I16I64 + + Functionality implied by ID_AA64SMFR0_EL1.I16I64 == 0b1111. + +HWCAP2_SME_F64F64 + + Functionality implied by ID_AA64SMFR0_EL1.F64F64 == 0b1. + +HWCAP2_SME_I8I32 + + Functionality implied by ID_AA64SMFR0_EL1.I8I32 == 0b1111. + +HWCAP2_SME_F16F32 + + Functionality implied by ID_AA64SMFR0_EL1.F16F32 == 0b1. + +HWCAP2_SME_B16F32 + + Functionality implied by ID_AA64SMFR0_EL1.B16F32 == 0b1. + +HWCAP2_SME_F32F32 + + Functionality implied by ID_AA64SMFR0_EL1.F32F32 == 0b1. + +HWCAP2_SME_FA64 + + Functionality implied by ID_AA64SMFR0_EL1.FA64 == 0b1. + 4. Unused AT_HWCAP bits ----------------------- -- cgit From 4764f39e367679e29823467b6c7fc60d8af4f117 Mon Sep 17 00:00:00 2001 From: Alexander Stein Date: Thu, 3 Mar 2022 16:06:52 +0100 Subject: dt-bindings: pinctrl: Convert i.MX7D to json-schema Convert the i.MX7D pinctrl binding to DT schema format using json-schema Signed-off-by: Alexander Stein Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220303150653.1903910-1-alexander.stein@ew.tq-group.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/fsl,imx7d-pinctrl.txt | 87 ---------------- .../bindings/pinctrl/fsl,imx7d-pinctrl.yaml | 113 +++++++++++++++++++++ 2 files changed, 113 insertions(+), 87 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt deleted file mode 100644 index bfab5ca49fd1..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt +++ /dev/null @@ -1,87 +0,0 @@ -* Freescale i.MX7 Dual IOMUX Controller - -iMX7D supports two iomuxc controllers, fsl,imx7d-iomuxc controller is similar -as previous iMX SoC generation and fsl,imx7d-iomuxc-lpsr which provides low -power state retention capabilities on gpios that are part of iomuxc-lpsr -(GPIO1_IO7..GPIO1_IO0). While iomuxc-lpsr provides its own set of registers for -mux and pad control settings, it shares the input select register from main -iomuxc controller for daisy chain settings, the fsl,input-sel property extends -fsl,imx-pinctrl driver to support iomuxc-lpsr controller. - -iomuxc_lpsr: iomuxc-lpsr@302c0000 { - compatible = "fsl,imx7d-iomuxc-lpsr"; - reg = <0x302c0000 0x10000>; - fsl,input-sel = <&iomuxc>; -}; - -iomuxc: iomuxc@30330000 { - compatible = "fsl,imx7d-iomuxc"; - reg = <0x30330000 0x10000>; -}; - -Peripherals using pads from iomuxc-lpsr support low state retention power -state, under LPSR mode GPIO's state of pads are retain. - -Please refer to fsl,imx-pinctrl.txt in this directory for common binding part -and usage. - -Required properties: -- compatible: "fsl,imx7d-iomuxc" for main IOMUXC controller, or - "fsl,imx7d-iomuxc-lpsr" for Low Power State Retention IOMUXC controller. -- fsl,pins: each entry consists of 6 integers and represents the mux and config - setting for one pin. The first 5 integers are specified using a PIN_FUNC_ID macro, which can be found in - imx7d-pinfunc.h under device tree source folder. The last integer CONFIG is - the pad setting value like pull-up on this pin. Please refer to i.MX7 Dual - Reference Manual for detailed CONFIG settings. -- fsl,input-sel: required property for iomuxc-lpsr controller, this property is - a phandle for main iomuxc controller which shares the input select register for - daisy chain settings. - -CONFIG bits definition: -PAD_CTL_PUS_100K_DOWN (0 << 5) -PAD_CTL_PUS_5K_UP (1 << 5) -PAD_CTL_PUS_47K_UP (2 << 5) -PAD_CTL_PUS_100K_UP (3 << 5) -PAD_CTL_PUE (1 << 4) -PAD_CTL_HYS (1 << 3) -PAD_CTL_SRE_SLOW (1 << 2) -PAD_CTL_SRE_FAST (0 << 2) -PAD_CTL_DSE_X1 (0 << 0) -PAD_CTL_DSE_X4 (1 << 0) -PAD_CTL_DSE_X2 (2 << 0) -PAD_CTL_DSE_X6 (3 << 0) - -Examples: -While iomuxc-lpsr is intended to be used by dedicated peripherals to take -advantages of LPSR power mode, is also possible that an IP to use pads from -any of the iomux controllers. For example the I2C1 IP can use SCL pad from -iomuxc-lpsr controller and SDA pad from iomuxc controller as: - -i2c1: i2c@30a20000 { - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_i2c1_1>, <&pinctrl_i2c1_2>; -}; - -iomuxc-lpsr@302c0000 { - compatible = "fsl,imx7d-iomuxc-lpsr"; - reg = <0x302c0000 0x10000>; - fsl,input-sel = <&iomuxc>; - - pinctrl_i2c1_1: i2c1grp-1 { - fsl,pins = < - MX7D_PAD_GPIO1_IO04__I2C1_SCL 0x4000007f - >; - }; -}; - -iomuxc@30330000 { - compatible = "fsl,imx7d-iomuxc"; - reg = <0x30330000 0x10000>; - - pinctrl_i2c1_2: i2c1grp-2 { - fsl,pins = < - MX7D_PAD_I2C1_SDA__I2C1_SDA 0x4000007f - >; - }; -}; diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml new file mode 100644 index 000000000000..621038662188 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/fsl,imx7d-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale IMX7D IOMUX Controller + +maintainers: + - Dong Aisheng + +description: + Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory + for common binding part and usage. + +properties: + compatible: + oneOf: + - enum: + - fsl,imx7d-iomuxc + - fsl,imx7d-iomuxc-lpsr + + reg: + maxItems: 1 + + fsl,input-sel: + description: + phandle for main iomuxc controller which shares the input select + register for daisy chain settings. + $ref: /schemas/types.yaml#/definitions/phandle + +# Client device subnode's properties +patternProperties: + 'grp$': + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + + properties: + fsl,pins: + description: + each entry consists of 6 integers and represents the mux and config + setting for one pin. The first 5 integers are specified using a PIN_FUNC_ID macro, which can + be found in . The last integer + CONFIG is the pad setting value like pull-up on this pin. Please + refer to i.MX7D Reference Manual for detailed CONFIG settings. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "mux_reg" indicates the offset of mux register. + - description: | + "conf_reg" indicates the offset of pad configuration register. + - description: | + "input_reg" indicates the offset of select input register. + - description: | + "mux_val" indicates the mux value to be applied. + - description: | + "input_val" indicates the select input value to be applied. + - description: | + "pad_setting" indicates the pad configuration value to be applied. + + required: + - fsl,pins + + additionalProperties: false + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + - reg + +if: + properties: + compatible: + contains: + enum: + - fsl,imx7d-iomuxc-lpsr + +then: + required: + - fsl,input-sel + +additionalProperties: false + +examples: + - | + iomuxc: pinctrl@30330000 { + compatible = "fsl,imx7d-iomuxc"; + reg = <0x30330000 0x10000>; + + pinctrl_uart5: uart5grp { + fsl,pins = + <0x0160 0x03D0 0x0714 0x1 0x0 0x7e>, + <0x0164 0x03D4 0x0000 0x1 0x0 0x76>; + }; + }; + - | + iomuxc_lpsr: pinctrl@302c0000 { + compatible = "fsl,imx7d-iomuxc-lpsr"; + reg = <0x302c0000 0x10000>; + fsl,input-sel = <&iomuxc>; + + pinctrl_gpio_lpsr: gpio1-grp { + fsl,pins = + <0x0008 0x0038 0x0000 0x0 0x0 0x59>, + <0x000C 0x003C 0x0000 0x0 0x0 0x59>; + }; + }; -- cgit From f01143f291b2e560a1641647c96e7da7b4064ddc Mon Sep 17 00:00:00 2001 From: Johan Jonker Date: Wed, 30 Mar 2022 15:39:51 +0200 Subject: dt-bindings: pinctrl: add rockchip,rk3036-pinctrl compatible string Add the compatible string "rockchip,rk3036-pinctrl" in already in use in rk3036.dtsi to rockchip,pinctrl.yaml. Signed-off-by: Johan Jonker Reviewed-by: Heiko Stuebner Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220330133952.1949-1-jbx6244@gmail.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml index b0eae3a67ab1..9e90faf9b9d3 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml @@ -33,6 +33,7 @@ properties: enum: - rockchip,px30-pinctrl - rockchip,rk2928-pinctrl + - rockchip,rk3036-pinctrl - rockchip,rk3066a-pinctrl - rockchip,rk3066b-pinctrl - rockchip,rk3128-pinctrl -- cgit From ad984c428c311a7df4b33c038be40d795a9299bf Mon Sep 17 00:00:00 2001 From: William Zhang Date: Wed, 13 Apr 2022 12:26:41 -0700 Subject: dt-bindings: arm: add bcmbca device tree binding document Add arch bcmbca device tree binding document for Broadcom ARM based broadband SoC chipsets. In this change, only BCM47622 is added. Other chipsets will be added in the future. Signed-off-by: William Zhang Acked-by: Krzysztof Kozlowski Signed-off-by: Florian Fainelli --- .../devicetree/bindings/arm/bcm/brcm,bcmbca.yaml | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml new file mode 100644 index 000000000000..5fb455840417 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/bcm/brcm,bcmbca.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Broadband SoC device tree bindings + +description: + Broadcom Broadband SoCs include family of high performance DSL/PON/Wireless + chips that can be used as home gateway, router and WLAN AP for residential, + enterprise and carrier applications. + +maintainers: + - William Zhang + - Anand Gore + - Kursad Oney + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: BCM47622 based boards + items: + - enum: + - brcm,bcm947622 + - const: brcm,bcm47622 + - const: brcm,bcmbca + +additionalProperties: true + +... -- cgit From 30b7fa3a98de79683d3e2b33d945a42554c00c32 Mon Sep 17 00:00:00 2001 From: Sebastian Reichel Date: Fri, 22 Apr 2022 19:09:12 +0200 Subject: dt-bindings: pinctrl: rockchip: add rk3588 Add compatible string for rk3588 pin controller. No other changes are required, since the new controller can use the old binding. Signed-off-by: Sebastian Reichel Link: https://lore.kernel.org/r/20220422170920.401914-12-sebastian.reichel@collabora.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml index 9e90faf9b9d3..5b742513aecb 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml @@ -45,6 +45,7 @@ properties: - rockchip,rk3368-pinctrl - rockchip,rk3399-pinctrl - rockchip,rk3568-pinctrl + - rockchip,rk3588-pinctrl - rockchip,rv1108-pinctrl rockchip,grf: -- cgit From e343cff747f7af3f7898668e9058a7ad68903c8b Mon Sep 17 00:00:00 2001 From: Srinivasa Rao Mandadapu Date: Mon, 18 Apr 2022 18:07:01 +0530 Subject: dt-bindings: pinctrl: qcom: Update lpass lpi file name to SoC specific Change generic lpass lpi pincotrol bindings file to SoC specific file, to distinguish and accomadate other SoC specific dt bindings. Signed-off-by: Srinivasa Rao Mandadapu Co-developed-by: Venkata Prasad Potturu Signed-off-by: Venkata Prasad Potturu Acked-by: Rob Herring Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/1650285427-19752-2-git-send-email-quic_srivasam@quicinc.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml | 133 --------------------- .../pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml | 133 +++++++++++++++++++++ 2 files changed, 133 insertions(+), 133 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml deleted file mode 100644 index 5c5542f1627c..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml +++ /dev/null @@ -1,133 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/pinctrl/qcom,lpass-lpi-pinctrl.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Qualcomm Technologies, Inc. Low Power Audio SubSystem (LPASS) - Low Power Island (LPI) TLMM block - -maintainers: - - Srinivas Kandagatla - -description: | - This binding describes the Top Level Mode Multiplexer block found in the - LPASS LPI IP on most Qualcomm SoCs - -properties: - compatible: - const: qcom,sm8250-lpass-lpi-pinctrl - - reg: - minItems: 2 - maxItems: 2 - - clocks: - items: - - description: LPASS Core voting clock - - description: LPASS Audio voting clock - - clock-names: - items: - - const: core - - const: audio - - gpio-controller: true - - '#gpio-cells': - description: Specifying the pin number and flags, as defined in - include/dt-bindings/gpio/gpio.h - const: 2 - - gpio-ranges: - maxItems: 1 - -#PIN CONFIGURATION NODES -patternProperties: - '-pins$': - type: object - description: - Pinctrl node's client devices use subnodes for desired pin configuration. - Client device subnodes use below standard properties. - $ref: "/schemas/pinctrl/pincfg-node.yaml" - - properties: - pins: - description: - List of gpio pins affected by the properties specified in this - subnode. - items: - oneOf: - - pattern: "^gpio([0-9]|[1-9][0-9])$" - minItems: 1 - maxItems: 14 - - function: - enum: [ gpio, swr_tx_clk, qua_mi2s_sclk, swr_tx_data, qua_mi2s_ws, - qua_mi2s_data, swr_rx_clk, swr_rx_data, dmic1_clk, i2s1_clk, - dmic1_data, i2s1_ws, dmic2_clk, dmic2_data, i2s1_data, - i2s2_clk, wsa_swr_clk, i2s2_ws, wsa_swr_data, dmic3_clk, - dmic3_data, i2s2_data ] - description: - Specify the alternative function to be configured for the specified - pins. - - drive-strength: - enum: [2, 4, 6, 8, 10, 12, 14, 16] - default: 2 - description: - Selects the drive strength for the specified pins, in mA. - - slew-rate: - enum: [0, 1, 2, 3] - default: 0 - description: | - 0: No adjustments - 1: Higher Slew rate (faster edges) - 2: Lower Slew rate (slower edges) - 3: Reserved (No adjustments) - - bias-pull-down: true - - bias-pull-up: true - - bias-disable: true - - output-high: true - - output-low: true - - required: - - pins - - function - - additionalProperties: false - -allOf: - - $ref: "pinctrl.yaml#" - -required: - - compatible - - reg - - clocks - - clock-names - - gpio-controller - - '#gpio-cells' - - gpio-ranges - -additionalProperties: false - -examples: - - | - #include - lpi_tlmm: pinctrl@33c0000 { - compatible = "qcom,sm8250-lpass-lpi-pinctrl"; - reg = <0x33c0000 0x20000>, - <0x3550000 0x10000>; - clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>, - <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>; - clock-names = "core", "audio"; - gpio-controller; - #gpio-cells = <2>; - gpio-ranges = <&lpi_tlmm 0 0 14>; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml new file mode 100644 index 000000000000..06efb1382876 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml @@ -0,0 +1,133 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. Low Power Audio SubSystem (LPASS) + Low Power Island (LPI) TLMM block + +maintainers: + - Srinivas Kandagatla + +description: | + This binding describes the Top Level Mode Multiplexer block found in the + LPASS LPI IP on most Qualcomm SoCs + +properties: + compatible: + const: qcom,sm8250-lpass-lpi-pinctrl + + reg: + minItems: 2 + maxItems: 2 + + clocks: + items: + - description: LPASS Core voting clock + - description: LPASS Audio voting clock + + clock-names: + items: + - const: core + - const: audio + + gpio-controller: true + + '#gpio-cells': + description: Specifying the pin number and flags, as defined in + include/dt-bindings/gpio/gpio.h + const: 2 + + gpio-ranges: + maxItems: 1 + +#PIN CONFIGURATION NODES +patternProperties: + '-pins$': + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "/schemas/pinctrl/pincfg-node.yaml" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9])$" + minItems: 1 + maxItems: 14 + + function: + enum: [ gpio, swr_tx_clk, qua_mi2s_sclk, swr_tx_data, qua_mi2s_ws, + qua_mi2s_data, swr_rx_clk, swr_rx_data, dmic1_clk, i2s1_clk, + dmic1_data, i2s1_ws, dmic2_clk, dmic2_data, i2s1_data, + i2s2_clk, wsa_swr_clk, i2s2_ws, wsa_swr_data, dmic3_clk, + dmic3_data, i2s2_data ] + description: + Specify the alternative function to be configured for the specified + pins. + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + default: 2 + description: + Selects the drive strength for the specified pins, in mA. + + slew-rate: + enum: [0, 1, 2, 3] + default: 0 + description: | + 0: No adjustments + 1: Higher Slew rate (faster edges) + 2: Lower Slew rate (slower edges) + 3: Reserved (No adjustments) + + bias-pull-down: true + + bias-pull-up: true + + bias-disable: true + + output-high: true + + output-low: true + + required: + - pins + - function + + additionalProperties: false + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + - reg + - clocks + - clock-names + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include + lpi_tlmm: pinctrl@33c0000 { + compatible = "qcom,sm8250-lpass-lpi-pinctrl"; + reg = <0x33c0000 0x20000>, + <0x3550000 0x10000>; + clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>, + <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>; + clock-names = "core", "audio"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&lpi_tlmm 0 0 14>; + }; -- cgit From 6af63b663d3beb2afba6ca867fa21baedb8640ed Mon Sep 17 00:00:00 2001 From: Srinivasa Rao Mandadapu Date: Mon, 18 Apr 2022 18:07:02 +0530 Subject: dt-bindings: pinctrl: qcom: Add sc7280 lpass lpi pinctrl bindings Add device tree binding Documentation details for Qualcomm SC7280 LPASS LPI pinctrl driver. Signed-off-by: Srinivasa Rao Mandadapu Co-developed-by: Venkata Prasad Potturu Signed-off-by: Venkata Prasad Potturu Reviewed-by: Rob Herring Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/1650285427-19752-3-git-send-email-quic_srivasam@quicinc.com Signed-off-by: Linus Walleij --- .../pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml | 115 +++++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml new file mode 100644 index 000000000000..d32ee32776e8 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml @@ -0,0 +1,115 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. Low Power Audio SubSystem (LPASS) + Low Power Island (LPI) TLMM block + +maintainers: + - Srinivasa Rao Mandadapu + - Srinivas Kandagatla + +description: | + This binding describes the Top Level Mode Multiplexer block found in the + LPASS LPI IP on most Qualcomm SoCs + +properties: + compatible: + const: qcom,sc7280-lpass-lpi-pinctrl + + reg: + minItems: 2 + maxItems: 2 + + gpio-controller: true + + '#gpio-cells': + description: Specifying the pin number and flags, as defined in + include/dt-bindings/gpio/gpio.h + const: 2 + + gpio-ranges: + maxItems: 1 + +#PIN CONFIGURATION NODES +patternProperties: + '-pins$': + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "/schemas/pinctrl/pincfg-node.yaml" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9])$" + minItems: 1 + maxItems: 15 + + function: + enum: [ gpio, swr_tx_clk, qua_mi2s_sclk, swr_tx_data, qua_mi2s_ws, + qua_mi2s_data, swr_rx_clk, swr_rx_data, dmic1_clk, i2s1_clk, + dmic1_data, i2s1_ws, dmic2_clk, dmic2_data, i2s1_data, + i2s2_clk, wsa_swr_clk, i2s2_ws, wsa_swr_data, dmic3_clk, + dmic3_data, i2s2_data ] + description: + Specify the alternative function to be configured for the specified + pins. + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + default: 2 + description: + Selects the drive strength for the specified pins, in mA. + + slew-rate: + enum: [0, 1, 2, 3] + default: 0 + description: | + 0: No adjustments + 1: Higher Slew rate (faster edges) + 2: Lower Slew rate (slower edges) + 3: Reserved (No adjustments) + + bias-pull-down: true + + bias-pull-up: true + + bias-disable: true + + output-high: true + + output-low: true + + required: + - pins + - function + + additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + lpass_tlmm: pinctrl@33c0000 { + compatible = "qcom,sc7280-lpass-lpi-pinctrl"; + reg = <0x33c0000 0x20000>, + <0x3550000 0x10000>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&lpass_tlmm 0 0 15>; + }; -- cgit From 23e37546b25edc2e44d9a23ba6e92ef6270cd988 Mon Sep 17 00:00:00 2001 From: Arınç ÜNAL Date: Thu, 14 Apr 2022 20:39:12 +0300 Subject: dt-bindings: pinctrl: rt2880: fix binding name, pin groups and functions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Deprecate the old property "ralink,rt2880-pinmux". Add the new property "ralink,rt2880-pinctrl". The old property name was inaccurate as the hardware block is called pinctrl across the Mediatek/Ralink architecture. Current pin group and function bindings are for MT7621. Put bindings for RT2880 instead. Add me as a maintainer. Signed-off-by: Arınç ÜNAL Reviewed-by: Rob Herring Acked-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20220414173916.5552-11-arinc.unal@arinc9.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/ralink,rt2880-pinctrl.yaml | 68 ++++++++++++++++++++++ .../bindings/pinctrl/ralink,rt2880-pinmux.yaml | 68 ---------------------- 2 files changed, 68 insertions(+), 68 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml delete mode 100644 Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml new file mode 100644 index 000000000000..56e5becabcfd --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/ralink,rt2880-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ralink RT2880 Pin Controller + +maintainers: + - Arınç ÜNAL + - Sergio Paracuellos + +description: + Ralink RT2880 pin controller for RT2880 SoC. + The pin controller can only set the muxing of pin groups. Muxing individual + pins is not supported. There is no pinconf support. + +properties: + compatible: + const: ralink,rt2880-pinctrl + +patternProperties: + '-pins$': + type: object + patternProperties: + '^(.*-)?pinmux$': + type: object + description: node for pinctrl. + $ref: pinmux-node.yaml# + + properties: + groups: + description: The pin group to select. + enum: [i2c, spi, uartlite, jtag, mdio, sdram, pci] + + function: + description: The mux function to select. + enum: [gpio, i2c, spi, uartlite, jtag, mdio, sdram, pci] + + required: + - groups + - function + + additionalProperties: false + + additionalProperties: false + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + +additionalProperties: false + +examples: + # Pinmux controller node + - | + pinctrl { + compatible = "ralink,rt2880-pinctrl"; + + i2c_pins: i2c0-pins { + pinmux { + groups = "i2c"; + function = "i2c"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml deleted file mode 100644 index 9de8b0c075e2..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml +++ /dev/null @@ -1,68 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/pinctrl/ralink,rt2880-pinmux.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Ralink rt2880 pinmux controller - -maintainers: - - Sergio Paracuellos - -description: - The rt2880 pinmux can only set the muxing of pin groups. Muxing indiviual pins - is not supported. There is no pinconf support. - -properties: - compatible: - const: ralink,rt2880-pinmux - -patternProperties: - '-pins$': - type: object - patternProperties: - '^(.*-)?pinmux$': - type: object - description: node for pinctrl. - $ref: pinmux-node.yaml# - - properties: - groups: - description: Name of the pin group to use for the functions. - enum: [i2c, jtag, mdio, pcie, rgmii1, rgmii2, sdhci, spi, - uart1, uart2, uart3, wdt] - function: - description: The mux function to select - enum: [gpio, i2c, i2s, jtag, mdio, nand1, nand2, pcie refclk, - pcie rst, pcm, rgmii1, rgmii2, sdhci, spdif2, spdif3, - spi, uart1, uart2, uart3, wdt refclk, wdt rst] - - required: - - groups - - function - - additionalProperties: false - - additionalProperties: false - -allOf: - - $ref: "pinctrl.yaml#" - -required: - - compatible - -additionalProperties: false - -examples: - # Pinmux controller node - - | - pinctrl { - compatible = "ralink,rt2880-pinmux"; - - i2c_pins: i2c0-pins { - pinmux { - groups = "i2c"; - function = "i2c"; - }; - }; - }; -- cgit From fdcd7c8d1588dac8846ec4f057684fd94f5614ef Mon Sep 17 00:00:00 2001 From: Arınç ÜNAL Date: Thu, 14 Apr 2022 20:39:13 +0300 Subject: dt-bindings: pinctrl: add binding for Ralink MT7620 pinctrl MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add binding for the Ralink MT7620 pin controller for MT7620, MT7628 and MT7688 SoCs. Signed-off-by: Arınç ÜNAL Reviewed-by: Rob Herring Acked-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20220414173916.5552-12-arinc.unal@arinc9.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/ralink,mt7620-pinctrl.yaml | 91 ++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml new file mode 100644 index 000000000000..4d820df24b89 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/ralink,mt7620-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ralink MT7620 Pin Controller + +maintainers: + - Arınç ÜNAL + - Sergio Paracuellos + +description: + Ralink MT7620 pin controller for MT7620, MT7628 and MT7688 SoCs. + The pin controller can only set the muxing of pin groups. Muxing individual + pins is not supported. There is no pinconf support. + +properties: + compatible: + const: ralink,mt7620-pinctrl + +patternProperties: + '-pins$': + type: object + patternProperties: + '^(.*-)?pinmux$': + type: object + description: node for pinctrl. + $ref: pinmux-node.yaml# + + properties: + groups: + description: The pin group to select. + enum: [ + # For MT7620 SoC + ephy, i2c, mdio, nd_sd, pa, pcie, rgmii1, rgmii2, spi, spi refclk, + uartf, uartlite, wdt, wled, + + # For MT7628 and MT7688 SoCs + gpio, i2c, i2s, p0led_an, p0led_kn, p1led_an, p1led_kn, p2led_an, + p2led_kn, p3led_an, p3led_kn, p4led_an, p4led_kn, perst, pwm0, + pwm1, refclk, sdmode, spi, spi cs1, spis, uart0, uart1, uart2, + wdt, wled_an, wled_kn, + ] + + function: + description: The mux function to select. + enum: [ + # For MT7620 SoC + ephy, gpio, gpio i2s, gpio uartf, i2c, i2s uartf, mdio, nand, pa, + pcie refclk, pcie rst, pcm gpio, pcm i2s, pcm uartf, refclk, + rgmii1, rgmii2, sd, spi, spi refclk, uartf, uartlite, wdt refclk, + wdt rst, wled, + + # For MT7628 and MT7688 SoCs + antenna, debug, gpio, i2c, i2s, jtag, p0led_an, p0led_kn, + p1led_an, p1led_kn, p2led_an, p2led_kn, p3led_an, p3led_kn, + p4led_an, p4led_kn, pcie, pcm, perst, pwm, pwm0, pwm1, pwm_uart2, + refclk, rsvd, sdxc, sdxc d5 d4, sdxc d6, sdxc d7, spi, spi cs1, + spis, sw_r, uart0, uart1, uart2, utif, wdt, wled_an, wled_kn, -, + ] + + required: + - groups + - function + + additionalProperties: false + + additionalProperties: false + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + +additionalProperties: false + +examples: + # Pinmux controller node + - | + pinctrl { + compatible = "ralink,mt7620-pinctrl"; + + i2c_pins: i2c0-pins { + pinmux { + groups = "i2c"; + function = "i2c"; + }; + }; + }; -- cgit From a8bf29d253a8e4c2e71d28d935fa2f0b6c65738c Mon Sep 17 00:00:00 2001 From: Arınç ÜNAL Date: Thu, 14 Apr 2022 20:39:14 +0300 Subject: dt-bindings: pinctrl: add binding for Ralink MT7621 pinctrl MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add binding for the Ralink MT7621 pin controller for MT7621 SoC. Signed-off-by: Arınç ÜNAL Reviewed-by: Rob Herring Acked-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20220414173916.5552-13-arinc.unal@arinc9.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/ralink,mt7621-pinctrl.yaml | 71 ++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml new file mode 100644 index 000000000000..61e5c847e8c8 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/ralink,mt7621-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ralink MT7621 Pin Controller + +maintainers: + - Arınç ÜNAL + - Sergio Paracuellos + +description: + Ralink MT7621 pin controller for MT7621 SoC. + The pin controller can only set the muxing of pin groups. Muxing individual + pins is not supported. There is no pinconf support. + +properties: + compatible: + const: ralink,mt7621-pinctrl + +patternProperties: + '-pins$': + type: object + patternProperties: + '^(.*-)?pinmux$': + type: object + description: node for pinctrl. + $ref: pinmux-node.yaml# + + properties: + groups: + description: The pin group to select. + enum: [i2c, jtag, mdio, pcie, rgmii1, rgmii2, sdhci, spi, uart1, + uart2, uart3, wdt] + + function: + description: The mux function to select. + enum: [gpio, i2c, i2s, jtag, mdio, nand1, nand2, pcie refclk, + pcie rst, pcm, rgmii1, rgmii2, sdhci, spdif2, spdif3, spi, + uart1, uart2, uart3, wdt refclk, wdt rst] + + required: + - groups + - function + + additionalProperties: false + + additionalProperties: false + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + +additionalProperties: false + +examples: + # Pinmux controller node + - | + pinctrl { + compatible = "ralink,mt7621-pinctrl"; + + i2c_pins: i2c0-pins { + pinmux { + groups = "i2c"; + function = "i2c"; + }; + }; + }; -- cgit From b6a3a007a99ac372a6eb3dbc6954f61cff5e2985 Mon Sep 17 00:00:00 2001 From: Arınç ÜNAL Date: Thu, 14 Apr 2022 20:39:15 +0300 Subject: dt-bindings: pinctrl: add binding for Ralink RT305X pinctrl MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add binding for the Ralink RT305X pin controller for RT3050, RT3052, RT3350, RT3352 and RT5350 SoCs. Signed-off-by: Arınç ÜNAL Acked-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20220414173916.5552-14-arinc.unal@arinc9.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/ralink,rt305x-pinctrl.yaml | 92 ++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml new file mode 100644 index 000000000000..425401c54269 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/ralink,rt305x-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ralink RT305X Pin Controller + +maintainers: + - Arınç ÜNAL + - Sergio Paracuellos + +description: + Ralink RT305X pin controller for RT3050, RT3052, RT3350, RT3352 and RT5350 + SoCs. + The pin controller can only set the muxing of pin groups. Muxing individual + pins is not supported. There is no pinconf support. + +properties: + compatible: + const: ralink,rt305x-pinctrl + +patternProperties: + '-pins$': + type: object + patternProperties: + '^(.*-)?pinmux$': + type: object + description: node for pinctrl. + $ref: pinmux-node.yaml# + + properties: + groups: + description: The pin group to select. + enum: [ + # For RT3050, RT3052 and RT3350 SoCs + i2c, jtag, mdio, rgmii, sdram, spi, uartf, uartlite, + + # For RT3352 SoC + i2c, jtag, led, lna, mdio, pa, rgmii, spi, spi_cs1, uartf, + uartlite, + + # For RT5350 SoC + i2c, jtag, led, spi, spi_cs1, uartf, uartlite, + ] + + function: + description: The mux function to select. + enum: [ + # For RT3050, RT3052 and RT3350 SoCs + gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, mdio, pcm gpio, + pcm i2s, pcm uartf, rgmii, sdram, spi, uartf, uartlite, + + # For RT3352 SoC + gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, led, lna, mdio, + pa, pcm gpio, pcm i2s, pcm uartf, rgmii, spi, spi_cs1, uartf, + uartlite, wdg_cs1, + + # For RT5350 SoC + gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, led, pcm gpio, + pcm i2s, pcm uartf, spi, spi_cs1, uartf, uartlite, wdg_cs1, + ] + + required: + - groups + - function + + additionalProperties: false + + additionalProperties: false + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + +additionalProperties: false + +examples: + # Pinmux controller node + - | + pinctrl { + compatible = "ralink,rt305x-pinctrl"; + + i2c_pins: i2c0-pins { + pinmux { + groups = "i2c"; + function = "i2c"; + }; + }; + }; -- cgit From 69ab1e16d3823c05892371cd2c89e7852ac87067 Mon Sep 17 00:00:00 2001 From: Arınç ÜNAL Date: Thu, 14 Apr 2022 20:39:16 +0300 Subject: dt-bindings: pinctrl: add binding for Ralink RT3883 pinctrl MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add binding for the Ralink RT3883 pin controller for RT3883 SoC. Signed-off-by: Arınç ÜNAL Reviewed-by: Rob Herring Acked-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20220414173916.5552-15-arinc.unal@arinc9.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/ralink,rt3883-pinctrl.yaml | 71 ++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml new file mode 100644 index 000000000000..feb6e66dcb61 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/ralink,rt3883-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ralink RT3883 Pin Controller + +maintainers: + - Arınç ÜNAL + - Sergio Paracuellos + +description: + Ralink RT3883 pin controller for RT3883 SoC. + The pin controller can only set the muxing of pin groups. Muxing individual + pins is not supported. There is no pinconf support. + +properties: + compatible: + const: ralink,rt3883-pinctrl + +patternProperties: + '-pins$': + type: object + patternProperties: + '^(.*-)?pinmux$': + type: object + description: node for pinctrl. + $ref: pinmux-node.yaml# + + properties: + groups: + description: The pin group to select. + enum: [ge1, ge2, i2c, jtag, lna a, lna g, mdio, pci, spi, uartf, + uartlite] + + function: + description: The mux function to select. + enum: [ge1, ge2, gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, + lna a, lna g, mdio, pci-dev, pci-fnc, pci-host1, pci-host2, + pcm gpio, pcm i2s, pcm uartf, spi, uartf, uartlite] + + required: + - groups + - function + + additionalProperties: false + + additionalProperties: false + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + +additionalProperties: false + +examples: + # Pinmux controller node + - | + pinctrl { + compatible = "ralink,rt3883-pinctrl"; + + i2c_pins: i2c0-pins { + pinmux { + groups = "i2c"; + function = "i2c"; + }; + }; + }; -- cgit From b391719191c1b1f5d89330b00c98f21775e5fd8c Mon Sep 17 00:00:00 2001 From: Luiz Angelo Daros de Luca Date: Mon, 18 Apr 2022 20:35:57 -0300 Subject: dt-bindings: net: dsa: realtek: cleanup compatible strings MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Compatible strings are used to help the driver find the chip ID/version register for each chip family. After that, the driver can setup the switch accordingly. Keep only the first supported model for each family as a compatible string and reference other chip models in the description. The removed compatible strings have never been used in a released kernel. Link: https://lore.kernel.org/netdev/20220414014055.m4wbmr7tdz6hsa3m@bang-olufsen.dk/ Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Andrew Lunn Acked-by: Arınç ÜNAL Reviewed-by: Alvin Šipraga Link: https://lore.kernel.org/r/20220418233558.13541-1-luizluca@gmail.com Signed-off-by: Jakub Kicinski --- .../devicetree/bindings/net/dsa/realtek.yaml | 35 +++++++++------------- 1 file changed, 14 insertions(+), 21 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/realtek.yaml b/Documentation/devicetree/bindings/net/dsa/realtek.yaml index 8756060895a8..99ee4b5b9346 100644 --- a/Documentation/devicetree/bindings/net/dsa/realtek.yaml +++ b/Documentation/devicetree/bindings/net/dsa/realtek.yaml @@ -27,32 +27,25 @@ description: The realtek-mdio driver is an MDIO driver and it must be inserted inside an MDIO node. + The compatible string is only used to identify which (silicon) family the + switch belongs to. Roughly speaking, a family is any set of Realtek switches + whose chip identification register(s) have a common location and semantics. + The different models in a given family can be automatically disambiguated by + parsing the chip identification register(s) according to the given family, + avoiding the need for a unique compatible string for each model. + properties: compatible: enum: - realtek,rtl8365mb - - realtek,rtl8366 - realtek,rtl8366rb - - realtek,rtl8366s - - realtek,rtl8367 - - realtek,rtl8367b - - realtek,rtl8367rb - - realtek,rtl8367s - - realtek,rtl8368s - - realtek,rtl8369 - - realtek,rtl8370 description: | - realtek,rtl8365mb: 4+1 ports - realtek,rtl8366: 5+1 ports - realtek,rtl8366rb: 5+1 ports - realtek,rtl8366s: 5+1 ports - realtek,rtl8367: - realtek,rtl8367b: - realtek,rtl8367rb: 5+2 ports - realtek,rtl8367s: 5+2 ports - realtek,rtl8368s: 8 ports - realtek,rtl8369: 8+1 ports - realtek,rtl8370: 8+2 ports + realtek,rtl8365mb: + Use with models RTL8363NB, RTL8363NB-VB, RTL8363SC, RTL8363SC-VB, + RTL8364NB, RTL8364NB-VB, RTL8365MB, RTL8366SC, RTL8367RB-VB, RTL8367S, + RTL8367SB, RTL8370MB, RTL8310SR + realtek,rtl8366rb: + Use with models RTL8366RB, RTL8366S mdc-gpios: description: GPIO line for the MDC clock line. @@ -335,7 +328,7 @@ examples: #size-cells = <0>; switch@29 { - compatible = "realtek,rtl8367s"; + compatible = "realtek,rtl8365mb"; reg = <29>; reset-gpios = <&gpio2 20 GPIO_ACTIVE_LOW>; -- cgit From ee651cd1e944df7d1553bb2c5593e887f12d6cda Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Fri, 8 Apr 2022 15:05:38 -0700 Subject: dt-bindings: remoteproc: qcom: pas: Add sc8280xp adsp and nsp pair Add the Qualcomm sc8280xp ADSP and NSP pairs to the binding. Signed-off-by: Bjorn Andersson Reviewed-by: Krzysztof Kozlowski Reviewed-by: Vinod Koul Link: https://lore.kernel.org/r/20220408220539.625301-1-bjorn.andersson@linaro.org --- .../devicetree/bindings/remoteproc/qcom,adsp.yaml | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index a4409c398193..df8286296c37 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -29,6 +29,9 @@ properties: - qcom,sc8180x-adsp-pas - qcom,sc8180x-cdsp-pas - qcom,sc8180x-mpss-pas + - qcom,sc8280xp-adsp-pas + - qcom,sc8280xp-nsp0-pas + - qcom,sc8280xp-nsp1-pas - qcom,sdm660-adsp-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas @@ -169,6 +172,9 @@ allOf: - qcom,sc8180x-adsp-pas - qcom,sc8180x-cdsp-pas - qcom,sc8180x-mpss-pas + - qcom,sc8280xp-adsp-pas + - qcom,sc8280xp-nsp0-pas + - qcom,sc8280xp-nsp1-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas - qcom,sm6350-adsp-pas @@ -284,6 +290,9 @@ allOf: - qcom,qcs404-wcss-pas - qcom,sc8180x-adsp-pas - qcom,sc8180x-cdsp-pas + - qcom,sc8280xp-adsp-pas + - qcom,sc8280xp-nsp0-pas + - qcom,sc8280xp-nsp1-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas - qcom,sm6350-adsp-pas @@ -471,6 +480,7 @@ allOf: enum: - qcom,sc8180x-adsp-pas - qcom,sc8180x-cdsp-pas + - qcom,sc8280xp-adsp-pas - qcom,sm6350-adsp-pas - qcom,sm8150-slpi-pas - qcom,sm8250-adsp-pas @@ -508,6 +518,22 @@ allOf: - const: cx - const: mxc + - if: + properties: + compatible: + contains: + enum: + - qcom,sc8280xp-nsp0-pas + - qcom,sc8280xp-nsp1-pas + then: + properties: + power-domains: + items: + - description: NSP power domain + power-domain-names: + items: + - const: nsp + - if: properties: compatible: -- cgit From 3ebb9fdf466a246bb17164b70039dce584a0b959 Mon Sep 17 00:00:00 2001 From: Conor Dooley Date: Wed, 13 Apr 2022 08:58:31 +0100 Subject: dt-bindings: clk: mpfs document msspll dri registers As there are two sections of registers that are responsible for clock configuration on the PolarFire SoC: add the dynamic reconfiguration interface section to the binding & describe what each of the sections are used for. Fixes: 2145bb687e3f ("dt-bindings: clk: microchip: Add Microchip PolarFire host binding") Reviewed-by: Daire McNamara Acked-by: Krzysztof Kozlowski Signed-off-by: Conor Dooley Link: https://lore.kernel.org/r/20220413075835.3354193-5-conor.dooley@microchip.com Acked-by: Palmer Dabbelt Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/microchip,mpfs.yaml | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/microchip,mpfs.yaml b/Documentation/devicetree/bindings/clock/microchip,mpfs.yaml index 0c15afa2214c..016a4f378b9b 100644 --- a/Documentation/devicetree/bindings/clock/microchip,mpfs.yaml +++ b/Documentation/devicetree/bindings/clock/microchip,mpfs.yaml @@ -22,7 +22,16 @@ properties: const: microchip,mpfs-clkcfg reg: - maxItems: 1 + items: + - description: | + clock config registers: + These registers contain enable, reset & divider tables for the, cpu, + axi, ahb and rtc/mtimer reference clocks as well as enable and reset + for the peripheral clocks. + - description: | + mss pll dri registers: + Block of registers responsible for dynamic reconfiguration of the mss + pll clocks: maxItems: 1 @@ -51,7 +60,7 @@ examples: #size-cells = <2>; clkcfg: clock-controller@20002000 { compatible = "microchip,mpfs-clkcfg"; - reg = <0x0 0x20002000 0x0 0x1000>; + reg = <0x0 0x20002000 0x0 0x1000>, <0x0 0x3E001000 0x0 0x1000>; clocks = <&ref>; #clock-cells = <1>; }; -- cgit From 8e8fbab4f1e659f9955bc946a2fc71b8c3ba17e0 Mon Sep 17 00:00:00 2001 From: Conor Dooley Date: Wed, 13 Apr 2022 08:58:33 +0100 Subject: dt-bindings: rtc: add refclk to mpfs-rtc The rtc on PolarFire SoC does not use the AHB clock as its reference frequency, but rather a 1 MHz refclk that it shares with MTIMER. Add this second clock to the binding as a required property. Fixes: 4cbcc0d7b397 ("dt-bindings: rtc: add bindings for microchip mpfs rtc") Reviewed-by: Daire McNamara Acked-by: Krzysztof Kozlowski Signed-off-by: Conor Dooley Link: https://lore.kernel.org/r/20220413075835.3354193-7-conor.dooley@microchip.com Acked-by: Palmer Dabbelt Signed-off-by: Stephen Boyd --- .../devicetree/bindings/rtc/microchip,mfps-rtc.yaml | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml b/Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml index a2e984ea3553..500c62becd6b 100644 --- a/Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml @@ -31,11 +31,19 @@ properties: to that of the RTC's count register. clocks: - maxItems: 1 + items: + - description: | + AHB clock + - description: | + Reference clock: divided by the prescaler to create a time-based + strobe (typically 1 Hz) for the calendar counter. By default, the rtc + on the PolarFire SoC shares it's reference with MTIMER so this will + be a 1 MHz clock. clock-names: items: - const: rtc + - const: rtcref required: - compatible @@ -48,11 +56,12 @@ additionalProperties: false examples: - | + #include "dt-bindings/clock/microchip,mpfs-clock.h" rtc@20124000 { compatible = "microchip,mpfs-rtc"; reg = <0x20124000 0x1000>; - clocks = <&clkcfg 21>; - clock-names = "rtc"; + clocks = <&clkcfg CLK_RTC>, <&clkcfg CLK_RTCREF>; + clock-names = "rtc", "rtcref"; interrupts = <80>, <81>; }; ... -- cgit From 4ce2b909dcf578c79faf1e47589f59731e331b14 Mon Sep 17 00:00:00 2001 From: Georgi Vlaev Date: Fri, 15 Apr 2022 22:03:42 +0300 Subject: dt-bindings: clock: ehrpwm: Add AM62 specific compatible Introduce AM62 specific compatible for EPWM time-base sub-module clock. The time-base clock setup is identical to AM64. The only difference is AM62 provides 3 time-base clocks instead of the 9 found in AM64. Signed-off-by: Georgi Vlaev Tested-by: Vignesh Raghavendra Reviewed-by: Nishanth Menon Link: https://lore.kernel.org/r/20220415190343.6284-2-g-vlaev@ti.com Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml index 9b537bc876b5..66765116aff5 100644 --- a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml +++ b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml @@ -15,6 +15,7 @@ properties: - enum: - ti,am654-ehrpwm-tbclk - ti,am64-epwm-tbclk + - ti,am62-epwm-tbclk - const: syscon "#clock-cells": -- cgit From 038010bb30684c0219fa4f93a13149038f28291a Mon Sep 17 00:00:00 2001 From: John Crispin Date: Mon, 14 Mar 2022 09:44:03 +0100 Subject: dt-bindings: Add en7523-scu device tree binding documentation Adds device tree binding documentation for clocks in the EN7523 SOC. Reviewed-by: Rob Herring Signed-off-by: John Crispin Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20220314084409.84394-2-nbd@nbd.name Signed-off-by: Stephen Boyd --- .../bindings/clock/airoha,en7523-scu.yaml | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml new file mode 100644 index 000000000000..d60e74654809 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/airoha,en7523-scu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: EN7523 Clock Device Tree Bindings + +maintainers: + - Felix Fietkau + - John Crispin + +description: | + This node defines the System Control Unit of the EN7523 SoC, + a collection of registers configuring many different aspects of the SoC. + + The clock driver uses it to read and configure settings of the + PLL controller, which provides clocks for the CPU, the bus and + other SoC internal peripherals. + + Each clock is assigned an identifier and client nodes use this identifier + to specify which clock they consume. + + All these identifiers can be found in: + [1]: . + + The clocks are provided inside a system controller node. + +properties: + compatible: + items: + - const: airoha,en7523-scu + + reg: + maxItems: 2 + + "#clock-cells": + description: + The first cell indicates the clock number, see [1] for available + clocks. + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include + scu: system-controller@1fa20000 { + compatible = "airoha,en7523-scu"; + reg = <0x1fa20000 0x400>, + <0x1fb00000 0x1000>; + #clock-cells = <1>; + }; -- cgit From 95c33ae41b822c37dc841cf80ca388fea376e36d Mon Sep 17 00:00:00 2001 From: Jeffrey Hugo Date: Mon, 18 Apr 2022 11:18:47 -0600 Subject: bus: mhi: host: Add soc_reset sysfs The MHI bus supports a standardized hardware reset, which is known as the "SoC Reset". This reset is similar to the reset sysfs for PCI devices - a hardware mechanism to reset the state back to square one. The MHI SoC Reset is described in the spec as a reset of last resort. If some unrecoverable error has occurred where other resets have failed, SoC Reset is the "big hammer" that ungracefully resets the device. This is effectivly the same as yanking the power on the device, and reapplying it. However, depending on the nature of the particular issue, the underlying transport link may remain active and configured. If the link remains up, the device will flag a MHI system error early in the boot process after the reset is executed, which allows the MHI bus to process a fatal error event, and clean up appropiately. While the SoC Reset is generally intended as a means of recovery when all else has failed, it can be useful in non-error scenarios. For example, if the device loads firmware from the host filesystem, the device may need to be fully rebooted inorder to pick up the new firmware. In this scenario, the system administrator may use the soc_reset sysfs to cause the device to pick up the new firmware that the admin placed on the filesystem. Signed-off-by: Jeffrey Hugo Reviewed-by: Bhaumik Bhatt Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/1650302327-30439-1-git-send-email-quic_jhugo@quicinc.com Signed-off-by: Manivannan Sadhasivam --- Documentation/ABI/stable/sysfs-bus-mhi | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-bus-mhi b/Documentation/ABI/stable/sysfs-bus-mhi index ecfe7662f8d0..96ccc3385a2b 100644 --- a/Documentation/ABI/stable/sysfs-bus-mhi +++ b/Documentation/ABI/stable/sysfs-bus-mhi @@ -19,3 +19,13 @@ Description: The file holds the OEM PK Hash value of the endpoint device read without having the device power on at least once, the file will read all 0's. Users: Any userspace application or clients interested in device info. + +What: /sys/bus/mhi/devices/.../soc_reset +Date: April 2022 +KernelVersion: 5.19 +Contact: mhi@lists.linux.dev +Description: Initiates a SoC reset on the MHI controller. A SoC reset is + a reset of last resort, and will require a complete re-init. + This can be useful as a method of recovery if the device is + non-responsive, or as a means of loading new firmware as a + system administration task. -- cgit From f1b57164305d6342b9f77a4f4482cde492b56983 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Thu, 3 Feb 2022 12:11:15 +0000 Subject: media: cec: add optional adap_configured callback This new optional callback is called when the adapter is fully configured or fully unconfigured. Some drivers may have to take action when this happens. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/media/cec-core.rst | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/media/cec-core.rst b/Documentation/driver-api/media/cec-core.rst index c6194ee81c41..ae0d20798edc 100644 --- a/Documentation/driver-api/media/cec-core.rst +++ b/Documentation/driver-api/media/cec-core.rst @@ -109,6 +109,7 @@ your driver: int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable); int (*adap_monitor_pin_enable)(struct cec_adapter *adap, bool enable); int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr); + void (*adap_configured)(struct cec_adapter *adap, bool configured); int (*adap_transmit)(struct cec_adapter *adap, u8 attempts, u32 signal_free_time, struct cec_msg *msg); void (*adap_status)(struct cec_adapter *adap, struct seq_file *file); @@ -117,7 +118,7 @@ your driver: /* Error injection callbacks */ ... - /* High-level callbacks */ + /* High-level callback */ ... }; @@ -178,6 +179,16 @@ can receive directed messages to that address. Note that adap_log_addr must return 0 if logical_addr is CEC_LOG_ADDR_INVALID. +Called when the adapter is fully configured or unconfigured:: + + void (*adap_configured)(struct cec_adapter *adap, bool configured); + +If configured == true, then the adapter is fully configured, i.e. all logical +addresses have been successfully claimed. If configured == false, then the +adapter is unconfigured. If the driver has to take specific actions after +(un)configuration, then that can be done through this optional callback. + + To transmit a new message:: int (*adap_transmit)(struct cec_adapter *adap, u8 attempts, -- cgit From 4e4dab4bb6029dbee63f12a249ddc44b0124ea63 Mon Sep 17 00:00:00 2001 From: Daniel Scally Date: Wed, 2 Mar 2022 22:03:01 +0000 Subject: media: media.h: Add new media link type To describe in the kernel the connection between devices and their supporting peripherals (for example, a camera sensor and the vcm driving the focusing lens for it), add a new type of media link to introduce the concept of these ancillary links. Add some elements to the uAPI documentation to explain the new link type, their purpose and some aspects of their current implementation. Reviewed-by: Laurent Pinchart Signed-off-by: Daniel Scally Reviewed-by: Jean-Michel Hautbois Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- .../media/mediactl/media-controller-model.rst | 6 ++++++ .../userspace-api/media/mediactl/media-types.rst | 17 ++++++++++++----- 2 files changed, 18 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/mediactl/media-controller-model.rst b/Documentation/userspace-api/media/mediactl/media-controller-model.rst index 222cb99debb5..78bfdfb2a322 100644 --- a/Documentation/userspace-api/media/mediactl/media-controller-model.rst +++ b/Documentation/userspace-api/media/mediactl/media-controller-model.rst @@ -33,3 +33,9 @@ are: - An **interface link** is a point-to-point bidirectional control connection between a Linux Kernel interface and an entity. + +- An **ancillary link** is a point-to-point connection denoting that two + entities form a single logical unit. For example this could represent the + fact that a particular camera sensor and lens controller form a single + physical module, meaning this lens controller drives the lens for this + camera sensor. \ No newline at end of file diff --git a/Documentation/userspace-api/media/mediactl/media-types.rst b/Documentation/userspace-api/media/mediactl/media-types.rst index 0a26397bd01d..0ffeece1e0c8 100644 --- a/Documentation/userspace-api/media/mediactl/media-types.rst +++ b/Documentation/userspace-api/media/mediactl/media-types.rst @@ -412,14 +412,21 @@ must be set for every pad. is set by drivers and is read-only for applications. * - ``MEDIA_LNK_FL_LINK_TYPE`` - - This is a bitmask that defines the type of the link. Currently, - two types of links are supported: + - This is a bitmask that defines the type of the link. The following + link types are currently supported: .. _MEDIA-LNK-FL-DATA-LINK: - ``MEDIA_LNK_FL_DATA_LINK`` if the link is between two pads + ``MEDIA_LNK_FL_DATA_LINK`` for links that represent a data connection + between two pads. .. _MEDIA-LNK-FL-INTERFACE-LINK: - ``MEDIA_LNK_FL_INTERFACE_LINK`` if the link is between an - interface and an entity + ``MEDIA_LNK_FL_INTERFACE_LINK`` for links that associate an entity to its + interface. + + .. _MEDIA-LNK-FL-ANCILLARY-LINK: + + ``MEDIA_LNK_FL_ANCILLARY_LINK`` for links that represent a physical + relationship between two entities. The link may or may not be + immutable, so applications must not assume either case. -- cgit From 660440a9076b4dcfcc08f56c3cc8c41e3ed6376e Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Tue, 12 Apr 2022 10:42:49 +0100 Subject: media: Documentation: add documentation about subdev state Add documentation about centrally managed subdev state. Signed-off-by: Tomi Valkeinen Reviewed-by: Jacopo Mondi Reviewed-by: Hans Verkuil Reviewed-by: Laurent Pinchart Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/media/v4l2-subdev.rst | 69 ++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-api/media/v4l2-subdev.rst b/Documentation/driver-api/media/v4l2-subdev.rst index 08ea2673b19e..cf3b52bdbfb9 100644 --- a/Documentation/driver-api/media/v4l2-subdev.rst +++ b/Documentation/driver-api/media/v4l2-subdev.rst @@ -518,6 +518,75 @@ The :c:func:`v4l2_i2c_new_subdev` function will call :c:type:`i2c_board_info` structure using the ``client_type`` and the ``addr`` to fill it. +Centrally managed subdev active state +------------------------------------- + +Traditionally V4L2 subdev drivers maintained internal state for the active +device configuration. This is often implemented as e.g. an array of struct +v4l2_mbus_framefmt, one entry for each pad, and similarly for crop and compose +rectangles. + +In addition to the active configuration, each subdev file handle has an array of +struct v4l2_subdev_pad_config, managed by the V4L2 core, which contains the try +configuration. + +To simplify the subdev drivers the V4L2 subdev API now optionally supports a +centrally managed active configuration represented by +:c:type:`v4l2_subdev_state`. One instance of state, which contains the active +device configuration, is stored in the sub-device itself as part of +the :c:type:`v4l2_subdev` structure, while the core associates a try state to +each open file handle, to store the try configuration related to that file +handle. + +Sub-device drivers can opt-in and use state to manage their active configuration +by initializing the subdevice state with a call to v4l2_subdev_init_finalize() +before registering the sub-device. They must also call v4l2_subdev_cleanup() +to release all the allocated resources before unregistering the sub-device. +The core automatically allocates and initializes a state for each open file +handle to store the try configurations and frees it when closing the file +handle. + +V4L2 sub-device operations that use both the :ref:`ACTIVE and TRY formats +` receive the correct state to operate on through +the 'state' parameter. The state must be locked and unlocked by the +caller by calling :c:func:`v4l2_subdev_lock_state()` and +:c:func:`v4l2_subdev_unlock_state()`. The caller can do so by calling the subdev +operation through the :c:func:`v4l2_subdev_call_state_active()` macro. + +Operations that do not receive a state parameter implicitly operate on the +subdevice active state, which drivers can exclusively access by +calling :c:func:`v4l2_subdev_lock_and_get_active_state()`. The sub-device active +state must equally be released by calling :c:func:`v4l2_subdev_unlock_state()`. + +Drivers must never manually access the state stored in the :c:type:`v4l2_subdev` +or in the file handle without going through the designated helpers. + +While the V4L2 core passes the correct try or active state to the subdevice +operations, many existing device drivers pass a NULL state when calling +operations with :c:func:`v4l2_subdev_call()`. This legacy construct causes +issues with subdevice drivers that let the V4L2 core manage the active state, +as they expect to receive the appropriate state as a parameter. To help the +conversion of subdevice drivers to a managed active state without having to +convert all callers at the same time, an additional wrapper layer has been +added to v4l2_subdev_call(), which handles the NULL case by geting and locking +the callee's active state with :c:func:`v4l2_subdev_lock_and_get_active_state()`, +and unlocking the state after the call. + +The whole subdev state is in reality split into three parts: the +v4l2_subdev_state, subdev controls and subdev driver's internal state. In the +future these parts should be combined into a single state. For the time being +we need a way to handle the locking for these parts. This can be accomplished +by sharing a lock. The v4l2_ctrl_handler already supports this via its 'lock' +pointer and the same model is used with states. The driver can do the following +before calling v4l2_subdev_init_finalize(): + +.. code-block:: c + + sd->ctrl_handler->lock = &priv->mutex; + sd->state_lock = &priv->mutex; + +This shares the driver's private mutex between the controls and the states. + V4L2 sub-device functions and data structures --------------------------------------------- -- cgit From 2308d5aff8d083a44aa02197d2f5687b73d98f82 Mon Sep 17 00:00:00 2001 From: Stanimir Varbanov Date: Thu, 3 Mar 2022 15:06:31 +0000 Subject: media: v4l: Add Qualcomm custom compressed pixel formats Add custom Qualcomm raw compressed pixel formats. They are used in Qualcomm SoCs to optimize the interconnect bandwidth. Signed-off-by: Stanimir Varbanov Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/v4l/pixfmt-reserved.rst | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst index cabfa34b7db5..0ff68cd8cf62 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst @@ -239,6 +239,25 @@ please make a proposal on the linux-media mailing list. It remains an opaque intermediate format and the MDP hardware must be used to convert ``V4L2_PIX_FMT_MT21C`` to ``V4L2_PIX_FMT_NV12M``, ``V4L2_PIX_FMT_YUV420M`` or ``V4L2_PIX_FMT_YVU420``. + * .. _V4L2-PIX-FMT-QC08C: + + - ``V4L2_PIX_FMT_QC08C`` + - 'QC08C' + - Compressed Macro-tile 8-Bit YUV420 format used by Qualcomm platforms. + It is an opaque intermediate format. The used compression is lossless + and it is used by various multimedia hardware blocks like GPU, display + controllers, ISP and video accelerators. + It contains four planes for progressive video and eight planes for + interlaced video. + * .. _V4L2-PIX-FMT-QC10C: + + - ``V4L2_PIX_FMT_QC10C`` + - 'QC10C' + - Compressed Macro-tile 10-Bit YUV420 format used by Qualcomm platforms. + It is an opaque intermediate format. The used compression is lossless + and it is used by various multimedia hardware blocks like GPU, display + controllers, ISP and video accelerators. + It contains four planes for progressive video. .. raw:: latex \normalsize -- cgit From fcbc4acf8b8dff5fc420a14026bd4ab1798cf465 Mon Sep 17 00:00:00 2001 From: Dikshita Agarwal Date: Tue, 19 Apr 2022 06:06:42 +0100 Subject: media: v4l2-ctrls: Add intra-refresh type control Add a control to set intra-refresh type. Signed-off-by: Dikshita Agarwal Reviewed-by: Nicolas Dufresne Acked-by: Hans Verkuil Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/v4l/ext-ctrls-codec.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index 4cd7c541fc30..c24977fa7329 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1180,6 +1180,28 @@ enum v4l2_mpeg_video_h264_entropy_mode - is set to non zero value. Applicable to H264, H263 and MPEG4 encoder. +``V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD_TYPE (enum)`` + +enum v4l2_mpeg_video_intra_refresh_period_type - + Sets the type of intra refresh. The period to refresh + the whole frame is specified by V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD. + Note that if this control is not present, then it is undefined what + refresh type is used and it is up to the driver to decide. + Applicable to H264 and HEVC encoders. Possible values are: + +.. tabularcolumns:: |p{9.6cm}|p{7.9cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + * - ``V4L2_MPEG_VIDEO_INTRA_REFRESH_PERIOD_TYPE_RANDOM`` + - The whole frame is completely refreshed randomly + after the specified period. + * - ``V4L2_MPEG_VIDEO_INTRA_REFRESH_PERIOD_TYPE_CYCLIC`` + - The whole frame MBs are completely refreshed in cyclic order + after the specified period. + ``V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD (integer)`` Intra macroblock refresh period. This sets the period to refresh the whole frame. In other words, this defines the number of frames -- cgit From 03b49ec8715a99192c35dfa86bdd31b61fbf303e Mon Sep 17 00:00:00 2001 From: Kwang Son Date: Thu, 7 Apr 2022 07:26:07 +0100 Subject: media: docs: Fix vimc default pipeline graph RGB/YUV Input is sensor type and it should be sub-dev node. To generate this dot graph sudo modprobe vimc media-ctl --print-dot Signed-off-by: Kwang Son Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/admin-guide/media/vimc.dot | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/media/vimc.dot b/Documentation/admin-guide/media/vimc.dot index 57863a13fa39..8e829c164626 100644 --- a/Documentation/admin-guide/media/vimc.dot +++ b/Documentation/admin-guide/media/vimc.dot @@ -9,14 +9,14 @@ digraph board { n00000003:port0 -> n00000008:port0 [style=bold] n00000003:port0 -> n0000000f [style=bold] n00000005 [label="{{ 0} | Debayer A\n/dev/v4l-subdev2 | { 1}}", shape=Mrecord, style=filled, fillcolor=green] - n00000005:port1 -> n00000017:port0 + n00000005:port1 -> n00000015:port0 n00000008 [label="{{ 0} | Debayer B\n/dev/v4l-subdev3 | { 1}}", shape=Mrecord, style=filled, fillcolor=green] - n00000008:port1 -> n00000017:port0 [style=dashed] + n00000008:port1 -> n00000015:port0 [style=dashed] n0000000b [label="Raw Capture 0\n/dev/video0", shape=box, style=filled, fillcolor=yellow] n0000000f [label="Raw Capture 1\n/dev/video1", shape=box, style=filled, fillcolor=yellow] - n00000013 [label="RGB/YUV Input\n/dev/video2", shape=box, style=filled, fillcolor=yellow] - n00000013 -> n00000017:port0 [style=dashed] - n00000017 [label="{{ 0} | Scaler\n/dev/v4l-subdev4 | { 1}}", shape=Mrecord, style=filled, fillcolor=green] - n00000017:port1 -> n0000001a [style=bold] - n0000001a [label="RGB/YUV Capture\n/dev/video3", shape=box, style=filled, fillcolor=yellow] + n00000013 [label="{{} | RGB/YUV Input\n/dev/v4l-subdev4 | { 0}}", shape=Mrecord, style=filled, fillcolor=green] + n00000013:port0 -> n00000015:port0 [style=dashed] + n00000015 [label="{{ 0} | Scaler\n/dev/v4l-subdev5 | { 1}}", shape=Mrecord, style=filled, fillcolor=green] + n00000015:port1 -> n00000018 [style=bold] + n00000018 [label="RGB/YUV Capture\n/dev/video2", shape=box, style=filled, fillcolor=yellow] } -- cgit From acd134bca2ac4390eb4920d54bdfeecc7fe47bcb Mon Sep 17 00:00:00 2001 From: Piotr Oniszczuk Date: Mon, 14 Feb 2022 21:29:55 +0000 Subject: media: dt-bindings: media: rockchip-vpu: Add RK3568 compatible RK356x has Hantro G1 video decoder capable to decode MPEG2/H.264/VP8 video formats. This patch adds RK3568 compatible in rockchip-vpu dt-bindings. Tested on [1] with FFmpeg v4l2_request code taken from [2] with MPEG2, H.642 and VP8 samples with results [3]. [1] https://github.com/warpme/minimyth2 [2] https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/v4l2-request/ffmpeg-001-v4l2-request.patch [3] https://github.com/warpme/minimyth2/blob/master/video-test-summary.txt Signed-off-by: Piotr Oniszczuk Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml index bacb60a34989..6cc4d3e5a61d 100644 --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml @@ -23,6 +23,7 @@ properties: - rockchip,rk3328-vpu - rockchip,rk3399-vpu - rockchip,px30-vpu + - rockchip,rk3568-vpu - items: - const: rockchip,rk3188-vpu - const: rockchip,rk3066-vpu -- cgit From 5fe580196dd9b7d8eb2a99629055bb4ffa00f262 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 7 Apr 2022 21:41:27 +0200 Subject: dt-bindings: timer: exynos4210-mct: describe known hardware and its interrupts Most of the Samsung Exynos SoCs use almost the same Multi-Core Timer block, so only two compatibles were used so far (for Exynos4210 and Exynos4412 flavors) with Exynos4210-one being used in most of the SoCs. However the Exynos4210 flavor actually differs by number of interrupts. Add new compatibles, maintaining backward compatibility with Exynos4210, and constraints for number of interrupts. This allows to exactly match the Exynos MCT hardware. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Alim Akhtar Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220407194127.19004-1-krzysztof.kozlowski@linaro.org --- .../bindings/timer/samsung,exynos4210-mct.yaml | 67 +++++++++++++++++++++- 1 file changed, 64 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml index f11cbc7ccc14..1584944c7ac4 100644 --- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml +++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml @@ -19,9 +19,20 @@ description: |+ properties: compatible: - enum: - - samsung,exynos4210-mct - - samsung,exynos4412-mct + oneOf: + - enum: + - samsung,exynos4210-mct + - samsung,exynos4412-mct + - items: + - enum: + - samsung,exynos3250-mct + - samsung,exynos5250-mct + - samsung,exynos5260-mct + - samsung,exynos5420-mct + - samsung,exynos5433-mct + - samsung,exynos850-mct + - tesla,fsd-mct + - const: samsung,exynos4210-mct clocks: minItems: 2 @@ -63,6 +74,56 @@ required: - interrupts - reg +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos3250-mct + then: + properties: + interrupts: + minItems: 8 + maxItems: 8 + + - if: + properties: + compatible: + contains: + const: samsung,exynos5250-mct + then: + properties: + interrupts: + minItems: 6 + maxItems: 6 + + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos5260-mct + - samsung,exynos5420-mct + - samsung,exynos5433-mct + - samsung,exynos850-mct + then: + properties: + interrupts: + minItems: 12 + maxItems: 12 + + - if: + properties: + compatible: + contains: + enum: + - tesla,fsd-mct + then: + properties: + interrupts: + minItems: 16 + maxItems: 16 + additionalProperties: false examples: -- cgit From 26b954e4ef46f35cda5cb9807e49e779e3f166b9 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Fri, 22 Apr 2022 12:22:41 +0200 Subject: dt-bindings: display: simple: Add DataImage FG040346DSSWBG04 compatible string Add DataImage FG040346DSSWBG04 4.3" 480x272 TFT LCD 24bit DPI panel compatible string. Acked-by: Thomas Zimmermann Signed-off-by: Marek Vasut Cc: Rob Herring Cc: Sam Ravnborg Cc: Thomas Zimmermann Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Acked-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20220422102242.18959-1-marex@denx.de --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 1eb9dd4f8f58..cfe7bb9f89de 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -105,6 +105,8 @@ properties: - chunghwa,claa101wb01 # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel - chunghwa,claa101wb03 + # DataImage, Inc. 4.3" WQVGA (480x272) TFT LCD panel with 24-bit parallel interface. + - dataimage,fg040346dsswbg04 # DataImage, Inc. 7" WVGA (800x480) TFT LCD panel with 24-bit parallel interface. - dataimage,scf0700c48ggu18 # DLC Display Co. DLC1010GIG 10.1" WXGA TFT LCD Panel -- cgit From 9547c4e74f6b4b56c2f9e4e7a286ce126fd333fa Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 8 Apr 2022 08:37:20 +0200 Subject: dt-bindings: mtd: jedec, spi-nor: remove unneeded properties After conversion the jedec,spi-nor DT schema to reference other schemas (SPI and MTD) and use unevaluatedProperties, few properties are redundant. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Pratyush Yadav Reviewed-by: Rob Herring Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220408063720.12826-1-krzysztof.kozlowski@linaro.org --- Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml index 4abfb4cfc157..7149784a36ac 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml @@ -50,10 +50,6 @@ properties: minItems: 1 maxItems: 2 - spi-max-frequency: true - spi-rx-bus-width: true - spi-tx-bus-width: true - m25p,fast-read: type: boolean description: @@ -74,8 +70,6 @@ properties: be used on such systems, to denote the absence of a reliable reset mechanism. - label: true - partitions: type: object @@ -99,8 +93,6 @@ examples: #size-cells = <0>; flash@0 { - #address-cells = <1>; - #size-cells = <1>; compatible = "spansion,m25p80", "jedec,spi-nor"; reg = <0>; spi-max-frequency = <40000000>; -- cgit From 4e969459604632d4096ff536f72552a9d365845e Mon Sep 17 00:00:00 2001 From: Vincent Whitchurch Date: Tue, 12 Apr 2022 15:53:00 +0200 Subject: dt-bindings: reserved-memory: Support MTD/block device Add bindings to allow MTD/block devices to be used in reserved-memory regions using the "phram" (MTD in PHysical RAM) driver. This allows things like partitioning to be specified via the existing devicetree bindings. Signed-off-by: Vincent Whitchurch Reviewed-by: Rob Herring Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220412135302.1682890-3-vincent.whitchurch@axis.com --- .../devicetree/bindings/reserved-memory/phram.yaml | 47 ++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 Documentation/devicetree/bindings/reserved-memory/phram.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reserved-memory/phram.yaml b/Documentation/devicetree/bindings/reserved-memory/phram.yaml new file mode 100644 index 000000000000..6c4db28015f1 --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/phram.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reserved-memory/phram.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MTD/block device in RAM + +description: | + Specifies that the reserved memory region can be used as an MTD or block + device. + + The "phram" node is named after the "MTD in PHysical RAM" driver which + provides an implementation of this functionality in Linux. + +maintainers: + - Vincent Whitchurch + +allOf: + - $ref: "reserved-memory.yaml" + - $ref: "/schemas/mtd/mtd.yaml" + +properties: + compatible: + const: phram + + reg: + description: region of memory that can be used as an MTD/block device + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + + phram: flash@12340000 { + compatible = "phram"; + label = "rootfs"; + reg = <0x12340000 0x00800000>; + }; + }; -- cgit From 13b4d179c6641f66f3385c5ed6f2715f5b99f003 Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda Date: Wed, 20 Apr 2022 17:42:46 +0900 Subject: dt-bindings: clock: renesas,cpg-mssr: Document r8a779g0 Add binding documentation for the R-Car V4H (R8A779G0) Clock Pulse Generator. Signed-off-by: Yoshihiro Shimoda Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220420084255.375700-7-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml index e0b86214f0f5..e57bc40d307a 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml @@ -49,6 +49,7 @@ properties: - renesas,r8a77995-cpg-mssr # R-Car D3 - renesas,r8a779a0-cpg-mssr # R-Car V3U - renesas,r8a779f0-cpg-mssr # R-Car S4-8 + - renesas,r8a779g0-cpg-mssr # R-Car V4H reg: maxItems: 1 -- cgit From 6cd3233242eebfd81c8eb83fa965959471a2cd97 Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda Date: Wed, 20 Apr 2022 17:42:41 +0900 Subject: dt-bindings: arm: renesas: Document R-Car V4H White Hawk DT bindings Add device tree binding documentation for the Renesas R-Car V4H (r8a779g0) SoC and the Renesas White Hawk CPU and BreakOut boards. Signed-off-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20220420084255.375700-2-yoshihiro.shimoda.uh@renesas.com Link: https://lore.kernel.org/r/20220420084255.375700-3-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/arm/renesas.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index f61807103867..5408b154d05e 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -327,6 +327,18 @@ properties: - const: renesas,spider-cpu - const: renesas,r8a779f0 + - description: R-Car V4H (R8A779G0) + items: + - enum: + - renesas,white-hawk-cpu # White Hawk CPU board (RTP8A779G0ASKB0FC0SA000) + - const: renesas,r8a779g0 + + - items: + - enum: + - renesas,white-hawk-breakout # White Hawk BreakOut board (RTP8A779G0ASKB0SB0SA000) + - const: renesas,white-hawk-cpu + - const: renesas,r8a779g0 + - description: R-Car H3e (R8A779M0) items: - enum: -- cgit From 8ff93be3259fda0f7b7667ee1717b1dc9c4c8d07 Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda Date: Wed, 20 Apr 2022 17:42:43 +0900 Subject: dt-bindings: reset: renesas,rst: Document r8a779g0 reset module Document bindings for the R-Car V4H (R8A779G0) reset module. Signed-off-by: Yoshihiro Shimoda Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220420084255.375700-4-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/reset/renesas,rst.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.yaml b/Documentation/devicetree/bindings/reset/renesas,rst.yaml index bbe313bf1796..0d1b89e2fe9c 100644 --- a/Documentation/devicetree/bindings/reset/renesas,rst.yaml +++ b/Documentation/devicetree/bindings/reset/renesas,rst.yaml @@ -49,6 +49,7 @@ properties: - renesas,r8a77995-rst # R-Car D3 - renesas,r8a779a0-rst # R-Car V3U - renesas,r8a779f0-rst # R-Car S4-8 + - renesas,r8a779g0-rst # R-Car V4H reg: maxItems: 1 -- cgit From da68386d9edb1f57abf886febe5c5169ebd4d2c9 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Thu, 21 Apr 2022 09:31:02 +0200 Subject: drm: Rename dp/ to display/ Rename dp/ to display/ to account for additional display-related helpers, such as HDMI. Update all related include statements. No functional changes. Various drivers, such as i915 and amdgpu, use similar naming scheme by putting code for video-output standards into a local display/ directory. The new directory's name is aligned with this convention. v2: * update commit message (Javier) Signed-off-by: Thomas Zimmermann Reviewed-by: Lyude Paul Reviewed-by: Javier Martinez Canillas Reviewed-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-3-tzimmermann@suse.de --- Documentation/gpu/drm-kms-helpers.rst | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index c3ce91eecbc1..2584f5bff66f 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -232,34 +232,34 @@ HDCP Helper Functions Reference Display Port Helper Functions Reference ======================================= -.. kernel-doc:: drivers/gpu/drm/dp/drm_dp.c +.. kernel-doc:: drivers/gpu/drm/display/drm_dp_helper.c :doc: dp helpers -.. kernel-doc:: include/drm/dp/drm_dp_helper.h +.. kernel-doc:: include/drm/display/drm_dp_helper.h :internal: -.. kernel-doc:: drivers/gpu/drm/dp/drm_dp.c +.. kernel-doc:: drivers/gpu/drm/display/drm_dp_helper.c :export: Display Port CEC Helper Functions Reference =========================================== -.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_cec.c +.. kernel-doc:: drivers/gpu/drm/display/drm_dp_cec.c :doc: dp cec helpers -.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_cec.c +.. kernel-doc:: drivers/gpu/drm/display/drm_dp_cec.c :export: Display Port Dual Mode Adaptor Helper Functions Reference ========================================================= -.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_dual_mode_helper.c +.. kernel-doc:: drivers/gpu/drm/display/drm_dp_dual_mode_helper.c :doc: dp dual mode helpers -.. kernel-doc:: include/drm/dp/drm_dp_dual_mode_helper.h +.. kernel-doc:: include/drm/display/drm_dp_dual_mode_helper.h :internal: -.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_dual_mode_helper.c +.. kernel-doc:: drivers/gpu/drm/display/drm_dp_dual_mode_helper.c :export: Display Port MST Helpers @@ -268,19 +268,19 @@ Display Port MST Helpers Overview -------- -.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/display/drm_dp_mst_topology.c :doc: dp mst helper -.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/display/drm_dp_mst_topology.c :doc: Branch device and port refcounting Functions Reference ------------------- -.. kernel-doc:: include/drm/dp/drm_dp_mst_helper.h +.. kernel-doc:: include/drm/display/drm_dp_mst_helper.h :internal: -.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/display/drm_dp_mst_topology.c :export: Topology Lifetime Internals @@ -289,7 +289,7 @@ Topology Lifetime Internals These functions aren't exported to drivers, but are documented here to help make the MST topology helpers easier to understand -.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/display/drm_dp_mst_topology.c :functions: drm_dp_mst_topology_try_get_mstb drm_dp_mst_topology_get_mstb drm_dp_mst_topology_put_mstb drm_dp_mst_topology_try_get_port drm_dp_mst_topology_get_port -- cgit From 5d1b8b4a14f798c1bc627fb788112067ee26d1da Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Thu, 21 Apr 2022 09:31:04 +0200 Subject: drm/display: Split DisplayPort header into core and helper Move DisplayPort protocol constants and structures into the new header drm_dp.h, which can be used by DRM core components. The existing header drm_dp_helper.h now only contains helper code for graphics drivers. No functional changes. Signed-off-by: Thomas Zimmermann Reviewed-by: Lyude Paul Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-5-tzimmermann@suse.de --- Documentation/gpu/drm-kms-helpers.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 2584f5bff66f..09463ee99730 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -235,6 +235,9 @@ Display Port Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/display/drm_dp_helper.c :doc: dp helpers +.. kernel-doc:: include/drm/display/drm_dp.h + :internal: + .. kernel-doc:: include/drm/display/drm_dp_helper.h :internal: -- cgit From 2a64b147350f5b28f6b41873fcb453aaebea01c3 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Thu, 21 Apr 2022 09:31:05 +0200 Subject: drm/display: Move DSC header and helpers into display-helper module DSC is the Display Stream Compression standard for DisplayPort. Move the DSC code into display/ and split the header into files for protocol core and DRM helpers. Adapt all users of the code. No functional changes. To avoid the proliferation of Kconfig options, DSC is part of DRM's support for DisplayPort. If necessary, a new option could make DSC an independent feature. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-6-tzimmermann@suse.de --- Documentation/gpu/drm-kms-helpers.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 09463ee99730..7af55fb4072c 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -326,13 +326,13 @@ MIPI DSI Helper Functions Reference Display Stream Compression Helper Functions Reference ===================================================== -.. kernel-doc:: drivers/gpu/drm/drm_dsc.c +.. kernel-doc:: drivers/gpu/drm/display/drm_dsc_helper.c :doc: dsc helpers -.. kernel-doc:: include/drm/drm_dsc.h +.. kernel-doc:: include/drm/display/drm_dsc.h :internal: -.. kernel-doc:: drivers/gpu/drm/drm_dsc.c +.. kernel-doc:: drivers/gpu/drm/display/drm_dsc_helper.c :export: Output Probing Helper Functions Reference -- cgit From 6a99099fe1d6c46cbcd74298eeb386c4b9048f77 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Thu, 21 Apr 2022 09:31:06 +0200 Subject: drm/display: Move HDCP helpers into display-helper module Move DRM's HDCP helper library into the display/ subdirectory and add it to DRM's display helpers. Split the header file into core and helpers. Update all affected drivers. No functional changes. v3: * fix Kconfig dependencies v2: * fix include statements (Jani, Javier) * update Kconfig symbols Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-7-tzimmermann@suse.de --- Documentation/gpu/drm-kms-helpers.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 7af55fb4072c..cfda5a092a48 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -226,7 +226,7 @@ Panel Self Refresh Helper Reference HDCP Helper Functions Reference =============================== -.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c +.. kernel-doc:: drivers/gpu/drm/display/drm_hdcp_helper.c :export: Display Port Helper Functions Reference -- cgit From 644edf52b6305506ba7fd552323c1dfaa9cf6d8d Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Thu, 21 Apr 2022 09:31:08 +0200 Subject: drm/display: Move SCDC helpers into display-helper library SCDC is the Status and Control Data Channel for HDMI. Move the SCDC helpers into display/ and split the header into files for core and helpers. Update all affected drivers. No functional changes. To avoid the proliferation of Kconfig options, SCDC is part of DRM's support for HDMI. If necessary, a new option could make SCDC an independent feature. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-9-tzimmermann@suse.de --- Documentation/gpu/drm-kms-helpers.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index cfda5a092a48..2d473bc64c9f 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -356,13 +356,13 @@ EDID Helper Functions Reference SCDC Helper Functions Reference =============================== -.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c +.. kernel-doc:: drivers/gpu/drm/display/drm_scdc_helper.c :doc: scdc helpers -.. kernel-doc:: include/drm/drm_scdc_helper.h +.. kernel-doc:: include/drm/display/drm_scdc_helper.h :internal: -.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c +.. kernel-doc:: drivers/gpu/drm/display/drm_scdc_helper.c :export: HDMI Infoframes Helper Reference -- cgit From 276910aecc6a4076f5fbfd8160ff70695d6c1eb5 Mon Sep 17 00:00:00 2001 From: Jiri Pirko Date: Mon, 25 Apr 2022 06:44:22 +0300 Subject: devlink: introduce line card info get message Allow the driver to provide per line card info get op to fill-up info, similar to the "devlink dev info". Example: $ devlink lc info pci/0000:01:00.0 lc 8 pci/0000:01:00.0: lc 8 versions: fixed: hw.revision 0 running: ini.version 4 Signed-off-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller --- Documentation/networking/devlink/devlink-linecard.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/devlink-linecard.rst b/Documentation/networking/devlink/devlink-linecard.rst index 6c0b8928bc13..5a8d5989702a 100644 --- a/Documentation/networking/devlink/devlink-linecard.rst +++ b/Documentation/networking/devlink/devlink-linecard.rst @@ -14,6 +14,7 @@ system. Following operations are provided: * Get a list of supported line card types. * Provision of a slot with specific line card type. * Get and monitor of line card state and its change. + * Get information about line card versions. Line card according to the type may contain one or more gearboxes to mux the lanes with certain speed to multiple ports with lanes @@ -120,3 +121,6 @@ Example usage # Set slot 8 to be unprovisioned: $ devlink lc set pci/0000:01:00.0 lc 8 notype + + # Set info for slot 8: + $ devlink lc info pci/0000:01:00.0 lc 8 -- cgit From 28b2d1f1ac41dda0b239830765d85c7ae4434182 Mon Sep 17 00:00:00 2001 From: Jiri Pirko Date: Mon, 25 Apr 2022 06:44:23 +0300 Subject: devlink: introduce line card device info infrastructure Extend the line card info message with information (e.g., FW version) about devices found on the line card. Example: $ devlink lc info pci/0000:01:00.0 lc 8 pci/0000:01:00.0: lc 8 versions: fixed: hw.revision 0 running: ini.version 4 devices: device 0 versions: running: fw 19.2010.1310 device 1 versions: running: fw 19.2010.1310 device 2 versions: running: fw 19.2010.1310 device 3 versions: running: fw 19.2010.1310 Signed-off-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller --- Documentation/networking/devlink/devlink-linecard.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/devlink-linecard.rst b/Documentation/networking/devlink/devlink-linecard.rst index 5a8d5989702a..a98b468ad479 100644 --- a/Documentation/networking/devlink/devlink-linecard.rst +++ b/Documentation/networking/devlink/devlink-linecard.rst @@ -14,7 +14,7 @@ system. Following operations are provided: * Get a list of supported line card types. * Provision of a slot with specific line card type. * Get and monitor of line card state and its change. - * Get information about line card versions. + * Get information about line card versions and devices. Line card according to the type may contain one or more gearboxes to mux the lanes with certain speed to multiple ports with lanes -- cgit From 3b37130f48555f64be626e619e362e708c2cbd79 Mon Sep 17 00:00:00 2001 From: Jiri Pirko Date: Mon, 25 Apr 2022 06:44:27 +0300 Subject: mlxsw: core_linecards: Expose HW revision and INI version Implement info_get() to expose HW revision of a linecard and loaded INI version. Signed-off-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller --- Documentation/networking/devlink/mlxsw.rst | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/mlxsw.rst b/Documentation/networking/devlink/mlxsw.rst index cf857cb4ba8f..da1fbb265a11 100644 --- a/Documentation/networking/devlink/mlxsw.rst +++ b/Documentation/networking/devlink/mlxsw.rst @@ -58,6 +58,24 @@ The ``mlxsw`` driver reports the following versions - running - Three digit firmware version +Line card info versions +======================= + +The ``mlxsw`` driver reports the following versions for line cards + +.. list-table:: devlink line card info versions implemented + :widths: 5 5 90 + + * - Name + - Type + - Description + * - ``hw.revision`` + - fixed + - The hardware revision for this line card + * - ``ini.version`` + - running + - Version of line card INI loaded + Driver-specific Traps ===================== -- cgit From e932b4bdbd7cf51907d733376ddcd5b679c02923 Mon Sep 17 00:00:00 2001 From: Jiri Pirko Date: Mon, 25 Apr 2022 06:44:30 +0300 Subject: mlxsw: core_linecards: Expose device FW version over device info Extend MDDQ to obtain FW version of line card device and implement device_info_get() op to fill up the info with that. Signed-off-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller --- Documentation/networking/devlink/mlxsw.rst | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/mlxsw.rst b/Documentation/networking/devlink/mlxsw.rst index da1fbb265a11..0af345680510 100644 --- a/Documentation/networking/devlink/mlxsw.rst +++ b/Documentation/networking/devlink/mlxsw.rst @@ -76,6 +76,21 @@ The ``mlxsw`` driver reports the following versions for line cards - running - Version of line card INI loaded +Line card device info versions +============================== + +The ``mlxsw`` driver reports the following versions for line card devices + +.. list-table:: devlink line card device info versions implemented + :widths: 5 5 90 + + * - Name + - Type + - Description + * - ``fw.version`` + - running + - Three digit firmware version + Driver-specific Traps ===================== -- cgit From a498db69dc6d7511d76a4f04ec19c5e378db1c3b Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 25 Apr 2022 09:24:54 +0200 Subject: regulator: dt-bindings: richtek,rt4801: use existing ena_gpiod feature The binding and driver duplicated regulator core feature of controlling regulators with GPIOs (of_parse_cb + ena_gpiod) and created its own enable-gpios property with multiple GPIOs. This is a less preferred way, because enable-gpios should enable only one element, not multiple. It also duplicates existing solution. Deprecate the original 'enable-gpios' and add per-regulator property. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220425072455.27356-2-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown --- .../bindings/regulator/richtek,rt4801-regulator.yaml | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml index 4a4dfa7d9d09..091150c4e579 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml @@ -32,8 +32,11 @@ properties: If only one gpio is specified, only one gpio used to control ENP/ENM. Else if both are specified, DSVP/DSVN could be controlled individually. If this property not specified, treat both as always-on regulators. + + Property is deprecated. Use enable-gpios in each regulator. minItems: 1 maxItems: 2 + deprecated: true patternProperties: "^DSV(P|N)$": @@ -42,6 +45,14 @@ patternProperties: description: Properties for single display bias regulator. + properties: + enable-gpios: + description: + GPIO to use to enable DSVP/DSVN regulator. One GPIO can be configured + for controlling both regulators. If this property not specified for + any regulator, treat both as always-on regulators. + maxItems: 1 + required: - compatible - reg @@ -57,19 +68,20 @@ examples: rt4801@73 { compatible = "richtek,rt4801"; reg = <0x73>; - enable-gpios = <&gpio26 2 0>, <&gpio26 3 0>; dsvp: DSVP { regulator-name = "rt4801,dsvp"; regulator-min-microvolt = <4000000>; regulator-max-microvolt = <6000000>; regulator-boot-on; + enable-gpios = <&gpio26 2 0>; }; dsvn: DSVN { regulator-name = "rt4801,dsvn"; regulator-min-microvolt = <4000000>; regulator-max-microvolt = <6000000>; regulator-boot-on; + enable-gpios = <&gpio26 3 0>; }; }; -- cgit From aecec8bbb225965c6f775b946ad7bf40736c8f09 Mon Sep 17 00:00:00 2001 From: "周琰杰 (Zhou Yanjie)" Date: Sat, 23 Apr 2022 22:38:44 +0800 Subject: spi: Add bindings for new Ingenic SoCs. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the SPI bindings for the JZ4775 SoC, the X1000 SoC, and the X2000 SoC from Ingenic. Signed-off-by: 周琰杰 (Zhou Yanjie) Acked-by: Krzysztof Kozlowski Acked-by: Paul Cercueil Link: https://lore.kernel.org/r/1650724725-93758-3-git-send-email-zhouyanjie@wanyeetech.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/ingenic,spi.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/ingenic,spi.yaml b/Documentation/devicetree/bindings/spi/ingenic,spi.yaml index 5b1c7a2a6a31..360f76c226d9 100644 --- a/Documentation/devicetree/bindings/spi/ingenic,spi.yaml +++ b/Documentation/devicetree/bindings/spi/ingenic,spi.yaml @@ -18,7 +18,10 @@ properties: oneOf: - enum: - ingenic,jz4750-spi + - ingenic,jz4775-spi - ingenic,jz4780-spi + - ingenic,x1000-spi + - ingenic,x2000-spi - items: - enum: - ingenic,jz4760-spi -- cgit From 41e3958475ed3f9ad09facbe04cb8eafcee14546 Mon Sep 17 00:00:00 2001 From: Rui Miguel Silva Date: Fri, 8 Apr 2022 14:19:21 +0100 Subject: dt-bindings: Add Arm corstone1000 platform Add bindings to describe the FPGA in a prototyping board (MPS3) implementation and the Fixed Virtual Platform implementation of the ARM Corstone1000 platform. Link: https://lore.kernel.org/r/20220408131922.3864348-2-rui.silva@linaro.org Reviewed-by: Rob Herring Signed-off-by: Rui Miguel Silva Signed-off-by: Sudeep Holla --- .../devicetree/bindings/arm/arm,corstone1000.yaml | 45 ++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/arm,corstone1000.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/arm,corstone1000.yaml b/Documentation/devicetree/bindings/arm/arm,corstone1000.yaml new file mode 100644 index 000000000000..a77f88223801 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,corstone1000.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,corstone1000.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Corstone1000 Device Tree Bindings + +maintainers: + - Vishnu Banavath + - Rui Miguel Silva + +description: |+ + ARM's Corstone1000 includes pre-verified Corstone SSE-710 subsystem that + provides a flexible compute architecture that combines Cortex‑A and Cortex‑M + processors. + + Support for Cortex‑A32, Cortex‑A35 and Cortex‑A53 processors. Two expansion + systems for M-Class (or other) processors for adding sensors, connectivity, + video, audio and machine learning at the edge System and security IPs to build + a secure SoC for a range of rich IoT applications, for example gateways, smart + cameras and embedded systems. + + Integrated Secure Enclave providing hardware Root of Trust and supporting + seamless integration of the optional CryptoCell™-312 cryptographic + accelerator. + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: Corstone1000 MPS3 it has 1 Cortex-A35 CPU core in a FPGA + implementation of the Corstone1000 in the MPS3 prototyping board. See + ARM document DAI0550. + items: + - const: arm,corstone1000-mps3 + - description: Corstone1000 FVP is the Fixed Virtual Platform + implementation of this system. See ARM ecosystems FVP's. + items: + - const: arm,corstone1000-fvp + +additionalProperties: true + +... -- cgit From ec862155c3ccbde59644336eec58468e7d07519b Mon Sep 17 00:00:00 2001 From: Bagas Sanjaya Date: Sun, 17 Apr 2022 14:50:57 +0700 Subject: Documentation: siphash: convert danger note to warning for HalfSipHash Render danger paragraph into warning block for emphasization. Cc: Jonathan Corbet Cc: Eric Biggers Cc: Herbert Xu Cc: Mauro Carvalho Chehab Cc: linux-kernel@vger.kernel.org Signed-off-by: Bagas Sanjaya Signed-off-by: Jonathan Corbet Signed-off-by: Jason A. Donenfeld --- Documentation/security/siphash.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/security/siphash.rst b/Documentation/security/siphash.rst index bd9363025fcb..42794a7e052f 100644 --- a/Documentation/security/siphash.rst +++ b/Documentation/security/siphash.rst @@ -121,12 +121,12 @@ even scarier, uses an easily brute-forcable 64-bit key (with a 32-bit output) instead of SipHash's 128-bit key. However, this may appeal to some high-performance `jhash` users. -Danger! - -Do not ever use HalfSipHash except for as a hashtable key function, and only -then when you can be absolutely certain that the outputs will never be -transmitted out of the kernel. This is only remotely useful over `jhash` as a -means of mitigating hashtable flooding denial of service attacks. +.. warning:: + Do not ever use HalfSipHash except for as a hashtable key function, and + only then when you can be absolutely certain that the outputs will never + be transmitted out of the kernel. This is only remotely useful over + `jhash` as a means of mitigating hashtable flooding denial of service + attacks. Generating a HalfSipHash key ============================ -- cgit From 2fbfeb4fa61684955980b99603c29d2002a67118 Mon Sep 17 00:00:00 2001 From: Bagas Sanjaya Date: Sun, 17 Apr 2022 14:50:58 +0700 Subject: Documentation: siphash: enclose HalfSipHash usage example in the literal block Render usage example of HalfSipHash function as code block by using literal block syntax. Cc: Jonathan Corbet Cc: Eric Biggers Cc: Herbert Xu Cc: Mauro Carvalho Chehab Cc: linux-kernel@vger.kernel.org Signed-off-by: Bagas Sanjaya Signed-off-by: Jonathan Corbet Signed-off-by: Jason A. Donenfeld --- Documentation/security/siphash.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/security/siphash.rst b/Documentation/security/siphash.rst index 42794a7e052f..96b1492f4773 100644 --- a/Documentation/security/siphash.rst +++ b/Documentation/security/siphash.rst @@ -132,10 +132,10 @@ Generating a HalfSipHash key ============================ Keys should always be generated from a cryptographically secure source of -random numbers, either using get_random_bytes or get_random_once: +random numbers, either using get_random_bytes or get_random_once:: -hsiphash_key_t key; -get_random_bytes(&key, sizeof(key)); + hsiphash_key_t key; + get_random_bytes(&key, sizeof(key)); If you're not deriving your key from here, you're doing it wrong. -- cgit From 5a7e470e460fb90657343d843732325e53bb875f Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Thu, 21 Apr 2022 17:27:31 -0700 Subject: Documentation: siphash: disambiguate HalfSipHash algorithm from hsiphash functions Fix the documentation for the hsiphash functions to avoid conflating the HalfSipHash algorithm with the hsiphash functions, since these functions actually implement either HalfSipHash or SipHash, and random.c now uses HalfSipHash (in a very special way) without the hsiphash functions. Signed-off-by: Eric Biggers Signed-off-by: Jason A. Donenfeld --- Documentation/security/siphash.rst | 34 ++++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/security/siphash.rst b/Documentation/security/siphash.rst index 96b1492f4773..a10380cb78e5 100644 --- a/Documentation/security/siphash.rst +++ b/Documentation/security/siphash.rst @@ -121,15 +121,25 @@ even scarier, uses an easily brute-forcable 64-bit key (with a 32-bit output) instead of SipHash's 128-bit key. However, this may appeal to some high-performance `jhash` users. +HalfSipHash support is provided through the "hsiphash" family of functions. + .. warning:: - Do not ever use HalfSipHash except for as a hashtable key function, and - only then when you can be absolutely certain that the outputs will never - be transmitted out of the kernel. This is only remotely useful over - `jhash` as a means of mitigating hashtable flooding denial of service + Do not ever use the hsiphash functions except for as a hashtable key + function, and only then when you can be absolutely certain that the outputs + will never be transmitted out of the kernel. This is only remotely useful + over `jhash` as a means of mitigating hashtable flooding denial of service attacks. -Generating a HalfSipHash key -============================ +On 64-bit kernels, the hsiphash functions actually implement SipHash-1-3, a +reduced-round variant of SipHash, instead of HalfSipHash-1-3. This is because in +64-bit code, SipHash-1-3 is no slower than HalfSipHash-1-3, and can be faster. +Note, this does *not* mean that in 64-bit kernels the hsiphash functions are the +same as the siphash ones, or that they are secure; the hsiphash functions still +use a less secure reduced-round algorithm and truncate their outputs to 32 +bits. + +Generating a hsiphash key +========================= Keys should always be generated from a cryptographically secure source of random numbers, either using get_random_bytes or get_random_once:: @@ -139,8 +149,8 @@ random numbers, either using get_random_bytes or get_random_once:: If you're not deriving your key from here, you're doing it wrong. -Using the HalfSipHash functions -=============================== +Using the hsiphash functions +============================ There are two variants of the function, one that takes a list of integers, and one that takes a buffer:: @@ -183,7 +193,7 @@ You may then iterate like usual over the returned hash bucket. Performance =========== -HalfSipHash is roughly 3 times slower than JenkinsHash. For many replacements, -this will not be a problem, as the hashtable lookup isn't the bottleneck. And -in general, this is probably a good sacrifice to make for the security and DoS -resistance of HalfSipHash. +hsiphash() is roughly 3 times slower than jhash(). For many replacements, this +will not be a problem, as the hashtable lookup isn't the bottleneck. And in +general, this is probably a good sacrifice to make for the security and DoS +resistance of hsiphash(). -- cgit From 067c098766c6af667a9002d4e33cf1f3c998abbe Mon Sep 17 00:00:00 2001 From: Frank Rowand Date: Wed, 20 Apr 2022 17:25:05 -0500 Subject: of: overlay: rework overlay apply and remove kfree()s Fix various kfree() issues related to of_overlay_apply(). - Double kfree() of fdt and tree when init_overlay_changeset() returns an error. - free_overlay_changeset() free the root of the unflattened overlay (variable tree) instead of the memory that contains the unflattened overlay. - For the case of a failure during applying an overlay, move kfree() of new_fdt and overlay_mem into free_overlay_changeset(), which is called by the function that allocated them. - For the case of removing an overlay, the kfree() of new_fdt and overlay_mem remains in free_overlay_changeset(). - Check return value of of_fdt_unflatten_tree() for error instead of checking the returned value of overlay_root. - When storing pointers to allocated objects in ovcs, do so as near to the allocation as possible instead of in deeply layered function. More clearly document policy related to lifetime of pointers into overlay memory. Double kfree() Reported-by: Slawomir Stepien Signed-off-by: Frank Rowand Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220420222505.928492-3-frowand.list@gmail.com --- Documentation/devicetree/overlay-notes.rst | 30 ++++++++++++++++++++++++++---- 1 file changed, 26 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/overlay-notes.rst b/Documentation/devicetree/overlay-notes.rst index b2b8db765b8c..e139f22b363e 100644 --- a/Documentation/devicetree/overlay-notes.rst +++ b/Documentation/devicetree/overlay-notes.rst @@ -119,10 +119,32 @@ Finally, if you need to remove all overlays in one-go, just call of_overlay_remove_all() which will remove every single one in the correct order. -In addition, there is the option to register notifiers that get called on +There is the option to register notifiers that get called on overlay operations. See of_overlay_notifier_register/unregister and enum of_overlay_notify_action for details. -Note that a notifier callback is not supposed to store pointers to a device -tree node or its content beyond OF_OVERLAY_POST_REMOVE corresponding to the -respective node it received. +A notifier callback for OF_OVERLAY_PRE_APPLY, OF_OVERLAY_POST_APPLY, or +OF_OVERLAY_PRE_REMOVE may store pointers to a device tree node in the overlay +or its content but these pointers must not persist past the notifier callback +for OF_OVERLAY_POST_REMOVE. The memory containing the overlay will be +kfree()ed after OF_OVERLAY_POST_REMOVE notifiers are called. Note that the +memory will be kfree()ed even if the notifier for OF_OVERLAY_POST_REMOVE +returns an error. + +The changeset notifiers in drivers/of/dynamic.c are a second type of notifier +that could be triggered by applying or removing an overlay. These notifiers +are not allowed to store pointers to a device tree node in the overlay +or its content. The overlay code does not protect against such pointers +remaining active when the memory containing the overlay is freed as a result +of removing the overlay. + +Any other code that retains a pointer to the overlay nodes or data is +considered to be a bug because after removing the overlay the pointer +will refer to freed memory. + +Users of overlays must be especially aware of the overall operations that +occur on the system to ensure that other kernel code does not retain any +pointers to the overlay nodes or data. Any example of an inadvertent use +of such pointers is if a driver or subsystem module is loaded after an +overlay has been applied, and the driver or subsystem scans the entire +devicetree or a large portion of it, including the overlay nodes. -- cgit From b6ba1a89f73f11000f6b3062c4dc2503531bd3d2 Mon Sep 17 00:00:00 2001 From: Peter Collingbourne Date: Fri, 22 Apr 2022 13:29:12 -0700 Subject: arm64: document the boot requirements for MTE When booting the kernel we access system registers such as GCR_EL1 if MTE is supported. These accesses are defined to trap to EL3 if SCR_EL3.ATA is disabled. Furthermore, tag accesses will not behave as expected if SCR_EL3.ATA is not set, or if HCR_EL2.ATA is not set and we were booted at EL1. Therefore, require that these bits are enabled when appropriate. Signed-off-by: Peter Collingbourne Reviewed-by: Mark Brown Link: https://linux-review.googlesource.com/id/Iadcfd4dcd9ba3279b2813970b44d7485b0116709 Link: https://lore.kernel.org/r/20220422202912.292039-1-pcc@google.com Signed-off-by: Catalin Marinas --- Documentation/arm64/booting.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index 29884b261aa9..8aefa1001ae5 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -350,6 +350,16 @@ Before jumping into the kernel, the following conditions must be met: - SMCR_EL2.FA64 (bit 31) must be initialised to 0b1. + For CPUs with the Memory Tagging Extension feature (FEAT_MTE2): + + - If EL3 is present: + + - SCR_EL3.ATA (bit 26) must be initialised to 0b1. + + - If the kernel is entered at EL1 and EL2 is present: + + - HCR_EL2.ATA (bit 56) must be initialised to 0b1. + The requirements described above for CPU mode, caches, MMUs, architected timers, coherency and system registers apply to all CPUs. All CPUs must enter the kernel in the same exception level. Where the values documented -- cgit From 6588cb81e546e24f8271987ce0df120305cd4c80 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 25 Apr 2022 20:46:31 +0200 Subject: dt-bindings: gpio: add common consumer GPIO lines Typical GPIO lines like enable, powerdown, reset or wakeup are not documented as common, which leads to new variations of these (e.g. pwdn-gpios). Add a common schema which serves also as a documentation for preferred naming. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Bartosz Golaszewski --- .../bindings/gpio/gpio-consumer-common.yaml | 64 ++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-consumer-common.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-consumer-common.yaml b/Documentation/devicetree/bindings/gpio/gpio-consumer-common.yaml new file mode 100644 index 000000000000..40d0be31e200 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-consumer-common.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-consumer-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common GPIO lines + +maintainers: + - Bartosz Golaszewski + - Linus Walleij + +description: + Pay attention to using proper GPIO flag (e.g. GPIO_ACTIVE_LOW) for the GPIOs + using inverted signal (e.g. RESETN). + +select: true + +properties: + enable-gpios: + maxItems: 1 + description: + GPIO connected to the enable control pin. + + reset-gpios: + description: + GPIO (or GPIOs for power sequence) connected to the device reset pin + (e.g. RESET or RESETN). + + powerdown-gpios: + maxItems: 1 + description: + GPIO connected to the power down pin (hardware power down or power cut, + e.g. PD or PWDN). + + pwdn-gpios: + maxItems: 1 + description: Use powerdown-gpios + deprecated: true + + wakeup-gpios: + maxItems: 1 + description: + GPIO connected to the pin waking up the device from suspend or other + power-saving modes. + +allOf: + - if: + properties: + compatible: + contains: + enum: + - mmc-pwrseq-simple + then: + properties: + reset-gpios: + minItems: 1 + maxItems: 32 + else: + properties: + reset-gpios: + maxItems: 1 + +additionalProperties: true -- cgit From 74de379201cdede5a49ebc5b1b069e227a2217c9 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Mon, 25 Apr 2022 15:29:47 +0200 Subject: dt-bindings: gnss: Rewrite Mediatek bindings in YAML This rewrites the Mediatek GNSS bindings in YAML. Cc: devicetree@vger.kernel.org Cc: Krzysztof Kozlowski Signed-off-by: Linus Walleij Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220425132947.1311171-1-linus.walleij@linaro.org --- .../devicetree/bindings/gnss/mediatek.txt | 35 ------------- .../devicetree/bindings/gnss/mediatek.yaml | 59 ++++++++++++++++++++++ 2 files changed, 59 insertions(+), 35 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gnss/mediatek.txt create mode 100644 Documentation/devicetree/bindings/gnss/mediatek.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gnss/mediatek.txt b/Documentation/devicetree/bindings/gnss/mediatek.txt deleted file mode 100644 index 80cb802813c5..000000000000 --- a/Documentation/devicetree/bindings/gnss/mediatek.txt +++ /dev/null @@ -1,35 +0,0 @@ -Mediatek-based GNSS Receiver DT binding - -Mediatek chipsets are used in GNSS-receiver modules produced by several -vendors and can use a UART interface. - -Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic -properties. - -Required properties: - -- compatible : Must be - - "globaltop,pa6h" - -- vcc-supply : Main voltage regulator (pin name: VCC) - -Optional properties: - -- current-speed : Default UART baud rate -- gnss-fix-gpios : GPIO used to determine device position fix state - (pin name: FIX, 3D_FIX) -- reset-gpios : GPIO used to reset the device (pin name: RESET, NRESET) -- timepulse-gpios : Time pulse GPIO (pin name: PPS1, 1PPS) -- vbackup-supply : Backup voltage regulator (pin name: VBAT, VBACKUP) - -Example: - -serial@1234 { - compatible = "ns16550a"; - - gnss { - compatible = "globaltop,pa6h"; - vcc-supply = <&vcc_3v3>; - }; -}; diff --git a/Documentation/devicetree/bindings/gnss/mediatek.yaml b/Documentation/devicetree/bindings/gnss/mediatek.yaml new file mode 100644 index 000000000000..45cf01b27700 --- /dev/null +++ b/Documentation/devicetree/bindings/gnss/mediatek.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gnss/mediatek.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek GNSS Receiver Device Tree Bindings + +maintainers: + - Johan Hovold + +description: + Mediatek chipsets are used in GNSS-receiver modules produced by several + vendors and can use a UART interface. + +allOf: + - $ref: gnss-common.yaml# + +properties: + compatible: + const: globaltop,pa6h + + vcc-supply: + description: + Main voltage regulator, pin name VCC. + + reset-gpios: + maxItems: 1 + description: An optional reset line, with names such as RESET or NRESET. + If the line is active low it should be flagged with GPIO_ACTIVE_LOW. + + timepulse-gpios: + description: Comes with pin names such as PPS1 or 1PPS. + + gnss-fix-gpios: + maxItems: 1 + description: GPIO used to determine device position fix state, pin names + FIX or 3D_FIX. + + vbackup-supply: + description: + Regulator providing backup voltage, pin names such as VBAT or VBACKUP. + +required: + - compatible + - vcc-supply + +unevaluatedProperties: false + +examples: + - | + #include + serial { + gnss { + compatible = "globaltop,pa6h"; + vcc-supply = <&vcc_3v3>; + reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>; + }; + }; -- cgit From db92a6eb8349c42b3d195ef7686bda5fdd98290e Mon Sep 17 00:00:00 2001 From: Biju Das Date: Mon, 25 Apr 2022 14:31:52 +0100 Subject: dt-bindings: i2c: renesas,riic: Document RZ/G2UL SoC Document RZ/G2UL I2C bindings. RZ/G2UL I2C is identical to one found on the RZ/G2L SoC. No driver changes are required as RZ/G2L compatible string "renesas,riic-rz" will be used as a fallback. Signed-off-by: Biju Das Acked-by: Krzysztof Kozlowski Reviewed-by: Geert Uytterhoeven Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220425133152.176949-1-biju.das.jz@bp.renesas.com --- Documentation/devicetree/bindings/i2c/renesas,riic.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml index f4b235a87ac6..2f315489aaae 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml +++ b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml @@ -19,6 +19,7 @@ properties: - enum: - renesas,riic-r7s72100 # RZ/A1H - renesas,riic-r7s9210 # RZ/A2M + - renesas,riic-r9a07g043 # RZ/G2UL - renesas,riic-r9a07g044 # RZ/G2{L,LC} - renesas,riic-r9a07g054 # RZ/V2L - const: renesas,riic-rz # RZ/A or RZ/G2L @@ -75,6 +76,7 @@ if: compatible: contains: enum: + - renesas,riic-r9a07g043 - renesas,riic-r9a07g044 - renesas,riic-r9a07g054 then: -- cgit From ac6583f56f548b0d83ae78e73a090af4b027b4e9 Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Mon, 25 Apr 2022 16:04:33 +0200 Subject: dt-bindings: fsl: convert fsl,layerscape-dcfg to YAML Convert the fsl,layerscape-dcfg binding to the new YAML format. In the device trees, the device node always have a "syscon" compatible, which wasn't mentioned in the previous binding. One thing added here, compared to the original binding is the clock controller subnode of the LS1028A SoC and its "simple-mfd" compatible as used in arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi as well as the little-endian and big-endian properties. Signed-off-by: Michael Walle Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220425140433.33936-1-michael@walle.cc --- .../bindings/arm/freescale/fsl,layerscape-dcfg.txt | 19 ------ .../bindings/soc/fsl/fsl,layerscape-dcfg.yaml | 68 ++++++++++++++++++++++ 2 files changed, 68 insertions(+), 19 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt create mode 100644 Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt deleted file mode 100644 index 10a91cc8b997..000000000000 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt +++ /dev/null @@ -1,19 +0,0 @@ -Freescale DCFG - -DCFG is the device configuration unit, that provides general purpose -configuration and status for the device. Such as setting the secondary -core start address and release the secondary core from holdoff and startup. - -Required properties: - - compatible: Should contain a chip-specific compatible string, - Chip-specific strings are of the form "fsl,-dcfg", - The following s are known to be supported: - ls1012a, ls1021a, ls1043a, ls1046a, ls2080a, lx2160a - - - reg : should contain base address and length of DCFG memory-mapped registers - -Example: - dcfg: dcfg@1ee0000 { - compatible = "fsl,ls1021a-dcfg"; - reg = <0x0 0x1ee0000 0x0 0x10000>; - }; diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml new file mode 100644 index 000000000000..397f75909b20 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/fsl/fsl,layerscape-dcfg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Layerscape Device Configuration Unit + +maintainers: + - Shawn Guo + - Li Yang + +description: | + DCFG is the device configuration unit, that provides general purpose + configuration and status for the device. Such as setting the secondary + core start address and release the secondary core from holdoff and + startup. + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,ls1012a-dcfg + - fsl,ls1021a-dcfg + - fsl,ls1043a-dcfg + - fsl,ls1046a-dcfg + - fsl,ls1088a-dcfg + - fsl,ls2080a-dcfg + - fsl,lx2160a-dcfg + - const: syscon + + - items: + - enum: + - fsl,ls1028a-dcfg + - const: syscon + - const: simple-mfd + + reg: + maxItems: 1 + + little-endian: true + big-endian: true + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + ranges: true + +patternProperties: + "^clock-controller@[0-9a-z]+$": + $ref: /schemas/clock/fsl,flexspi-clock.yaml# + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + syscon@1ee0000 { + compatible = "fsl,ls1021a-dcfg", "syscon"; + reg = <0x1ee0000 0x10000>; + }; -- cgit From f14eb061fe89de0a090837c28ea15a79403730ee Mon Sep 17 00:00:00 2001 From: Biju Das Date: Mon, 25 Apr 2022 15:18:28 +0100 Subject: dt-bindings: timer: renesas: ostm: Document Renesas RZ/G2UL OSTM Document the General Timer Module(a.k.a OSTM) found on the RZ/G2UL SoC. OSTM module is identical to one found RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,ostm" will be used as a fallback. Signed-off-by: Biju Das Acked-by: Krzysztof Kozlowski Reviewed-by: Geert Uytterhoeven Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220425141828.197321-1-biju.das.jz@bp.renesas.com --- Documentation/devicetree/bindings/timer/renesas,ostm.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml index c399a019dde7..7207929e5cd6 100644 --- a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml @@ -23,6 +23,7 @@ properties: - enum: - renesas,r7s72100-ostm # RZ/A1H - renesas,r7s9210-ostm # RZ/A2M + - renesas,r9a07g043-ostm # RZ/G2UL - renesas,r9a07g044-ostm # RZ/G2{L,LC} - renesas,r9a07g054-ostm # RZ/V2L - const: renesas,ostm # Generic @@ -54,6 +55,7 @@ if: compatible: contains: enum: + - renesas,r9a07g043-ostm - renesas,r9a07g044-ostm - renesas,r9a07g054-ostm then: -- cgit From 82b9a6bb4b7a350619650b32e7d64ca945e0f234 Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Thu, 14 Apr 2022 11:58:06 +0300 Subject: dt-bindings: timer: Update TI timer to yaml Let's update the TI timer binding to use yaml. As this binding is specific to the TI dual-mode timers also known as dm-timers, let's use file name ti,timer-dm.yaml to avoid confusion with other timers. We add checks for the deprecated ti,hwmods property as done for other TI device driver bindings earlier. We also correct the issue with the old binding that was out of date for several properties. The am43 related timers are undocumented, but compatible with the am3 timers. Let's add the am43 timers too. The dm814 and dm816 timers are missing, let's add them. Some timers on some SoCs are dual mapped, like the ABE timers on omap4 and 5. The reg property maxItems must be updated to 2. The timer clocks can be managed by the parent interconnect target module with no clocks assigned for the timer node. And in some cases, the SoC may need to configure additional system clock for the timer in addition to the functional clock. The clock names are optional and not specific to the comptible property. For example, dra7 timers on l3 interconnect do not need clock-names, while the timers on dra7 l4 interconnect need them with both being compatible with ti,omap5430-timer. Cc: Daniel Lezcano Cc: Grygorii Strashko Cc: Keerthy Cc: Nishanth Menon Cc: Vignesh Raghavendra Signed-off-by: Tony Lindgren Reviewed-by: Krzysztof Kozlowski Reviewed-by: Grygorii Strashko Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220414085807.7389-2-tony@atomide.com --- .../devicetree/bindings/pwm/pwm-omap-dmtimer.txt | 2 +- .../devicetree/bindings/timer/ti,timer-dm.yaml | 142 +++++++++++++++++++++ .../devicetree/bindings/timer/ti,timer.txt | 44 ------- 3 files changed, 143 insertions(+), 45 deletions(-) create mode 100644 Documentation/devicetree/bindings/timer/ti,timer-dm.yaml delete mode 100644 Documentation/devicetree/bindings/timer/ti,timer.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt b/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt index d722ae3be363..25ecfe14c698 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt @@ -2,7 +2,7 @@ Required properties: - compatible: Shall contain "ti,omap-dmtimer-pwm". -- ti,timers: phandle to PWM capable OMAP timer. See timer/ti,timer.txt for info +- ti,timers: phandle to PWM capable OMAP timer. See timer/ti,timer-dm.yaml for info about these timers. - #pwm-cells: Should be 3. See pwm.yaml in this directory for a description of the cells format. diff --git a/Documentation/devicetree/bindings/timer/ti,timer-dm.yaml b/Documentation/devicetree/bindings/timer/ti,timer-dm.yaml new file mode 100644 index 000000000000..7c0eb53a944b --- /dev/null +++ b/Documentation/devicetree/bindings/timer/ti,timer-dm.yaml @@ -0,0 +1,142 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/ti,timer-dm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI dual-mode timer + +maintainers: + - Tony Lindgren + +description: | + The TI dual-mode timer is a general purpose timer with PWM capabilities. + +properties: + compatible: + oneOf: + - items: + - enum: + - ti,am335x-timer + - ti,am335x-timer-1ms + - ti,dm814-timer + - ti,dm816-timer + - ti,omap2420-timer + - ti,omap3430-timer + - ti,omap4430-timer + - ti,omap5430-timer + - items: + - const: ti,am4372-timer + - const: ti,am335x-timer + - items: + - const: ti,am4372-timer-1ms + - const: ti,am335x-timer-1ms + + reg: + items: + - description: IO address + - description: L3 to L4 mapping for omap4/5 L4 ABE + minItems: 1 + + clocks: + items: + - description: Functional clock + - description: System clock for omap4/5 and dra7 + minItems: 1 + + clock-names: + items: + - const: fck + - const: timer_sys_ck + minItems: 1 + + interrupts: + description: + Interrupt if available. The timer PWM features may be usable + in a limited way even without interrupts. + maxItems: 1 + + ti,timer-alwon: + description: + Timer is always enabled when the SoC is powered. Note that some SoCs like + am335x can suspend to PM coprocessor RTC only mode and in that case the + SoC power is cut including timers. + type: boolean + + ti,timer-dsp: + description: + Timer is routable to the DSP in addition to the operating system. + type: boolean + + ti,timer-pwm: + description: + Timer has been wired for PWM capability. + type: boolean + + ti,timer-secure: + description: + Timer access has been limited to secure mode only. + type: boolean + + ti,hwmods: + description: + Name of the HWMOD associated with timer. This is for legacy + omap2/3 platforms only. + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +allOf: + - if: + not: + properties: + compatible: + contains: + enum: + - ti,omap3430-timer + - ti,omap4430-timer + - ti,omap5430-timer + then: + properties: + reg: + maxItems: 1 + clocks: + maxItems: 1 + clock-names: + maxItems: 1 + + - if: + properties: + compatible: + contains: + enum: + - ti,dm814-timer + - ti,dm816-timer + - ti,omap2420-timer + - ti,omap3430-timer + then: + properties: + ti,hwmods: + items: + - pattern: "^timer([1-9]|1[0-2])$" + else: + properties: + ti,hwmods: false + +examples: + - | + timer1: timer@0 { + compatible = "ti,am335x-timer-1ms"; + reg = <0x0 0x400>; + interrupts = <67>; + ti,timer-alwon; + clocks = <&timer1_fck>; + clock-names = "fck"; + }; +... diff --git a/Documentation/devicetree/bindings/timer/ti,timer.txt b/Documentation/devicetree/bindings/timer/ti,timer.txt deleted file mode 100644 index d02e27c764ec..000000000000 --- a/Documentation/devicetree/bindings/timer/ti,timer.txt +++ /dev/null @@ -1,44 +0,0 @@ -OMAP Timer bindings - -Required properties: -- compatible: Should be set to one of the below. Please note that - OMAP44xx devices have timer instances that are 100% - register compatible with OMAP3xxx devices as well as - newer timers that are not 100% register compatible. - So for OMAP44xx devices timer instances may use - different compatible strings. - - ti,omap2420-timer (applicable to OMAP24xx devices) - ti,omap3430-timer (applicable to OMAP3xxx/44xx devices) - ti,omap4430-timer (applicable to OMAP44xx devices) - ti,omap5430-timer (applicable to OMAP543x devices) - ti,am335x-timer (applicable to AM335x devices) - ti,am335x-timer-1ms (applicable to AM335x devices) - -- reg: Contains timer register address range (base address and - length). -- interrupts: Contains the interrupt information for the timer. The - format is being dependent on which interrupt controller - the OMAP device uses. -- ti,hwmods: Name of the hwmod associated to the timer, "timer", - where is the instance number of the timer from the - HW spec. - -Optional properties: -- ti,timer-alwon: Indicates the timer is in an alway-on power domain. -- ti,timer-dsp: Indicates the timer can interrupt the on-chip DSP in - addition to the ARM CPU. -- ti,timer-pwm: Indicates the timer can generate a PWM output. -- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device - and therefore cannot be used by the kernel. - -Example: - -timer12: timer@48304000 { - compatible = "ti,omap3430-timer"; - reg = <0x48304000 0x400>; - interrupts = <95>; - ti,hwmods = "timer12" - ti,timer-alwon; - ti,timer-secure; -}; -- cgit From c4f3f823c2a63853fae5bbd61548dc281bd3a9ff Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Thu, 14 Apr 2022 11:58:07 +0300 Subject: dt-bindings: timer: Add compatible for am6 for TI timer-dm Let's add compatible for ti,am654-timer for TI am64, am65 and j72 SoCs. As the timer hardware is the same between am64, am65 and j72 we use the compatible name for the earliest SoC with this timer. The timer interrupts are not routable for the operating system for some timers on am6. Let's make sure the interrupts are configured for the timers on all other SoCs. Cc: Daniel Lezcano Cc: Grygorii Strashko Cc: Keerthy Cc: Nishanth Menon Cc: Vignesh Raghavendra Acked-by: Krzysztof Kozlowski Signed-off-by: Tony Lindgren Reviewed-by: Grygorii Strashko Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220414085807.7389-3-tony@atomide.com --- Documentation/devicetree/bindings/timer/ti,timer-dm.yaml | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/ti,timer-dm.yaml b/Documentation/devicetree/bindings/timer/ti,timer-dm.yaml index 7c0eb53a944b..e32df21e63a0 100644 --- a/Documentation/devicetree/bindings/timer/ti,timer-dm.yaml +++ b/Documentation/devicetree/bindings/timer/ti,timer-dm.yaml @@ -19,6 +19,7 @@ properties: - enum: - ti,am335x-timer - ti,am335x-timer-1ms + - ti,am654-timer - ti,dm814-timer - ti,dm816-timer - ti,omap2420-timer @@ -88,11 +89,20 @@ properties: required: - compatible - reg - - interrupts additionalProperties: false allOf: + - if: + not: + properties: + compatible: + contains: + const: ti,am654-timer + then: + required: + - interrupts + - if: not: properties: -- cgit From 6c1c1eb8c87de221051b9198d40971640060842f Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Mon, 25 Apr 2022 07:36:14 +0100 Subject: media: ext-ctrls-codec.rst: fix indentation The indentation was wrong, causing the documentation build to fail with: Sphinx parallel build error: docutils.utils.SystemMessagePropagation: Error parsing content block for the "flat-table" directive: two-level bullet list expected, but row 1 does not contain a second-level bullet list... flat-table:: :header-rows: 0 :stub-columns: 0 * - ``V4L2_MPEG_VIDEO_INTRA_REFRESH_PERIOD_TYPE_RANDOM`` - The whole frame is completely refreshed randomly after the specified period. * - ``V4L2_MPEG_VIDEO_INTRA_REFRESH_PERIOD_TYPE_CYCLIC`` - The whole frame MBs are completely refreshed in cyclic order after the specified period. make[1]: *** [Documentation/Makefile:96: htmldocs] Error 2 make: *** [Makefile:1678: htmldocs] Error 2 Link: https://lore.kernel.org/linux-media/62b53cbb-f3e2-ed8a-bba2-3f4145d9b8db@xs4all.nl Fixes: fcbc4acf8b8d ("media: v4l2-ctrls: Add intra-refresh type control") Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index c24977fa7329..6183f43f4d73 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1197,10 +1197,10 @@ enum v4l2_mpeg_video_intra_refresh_period_type - * - ``V4L2_MPEG_VIDEO_INTRA_REFRESH_PERIOD_TYPE_RANDOM`` - The whole frame is completely refreshed randomly - after the specified period. + after the specified period. * - ``V4L2_MPEG_VIDEO_INTRA_REFRESH_PERIOD_TYPE_CYCLIC`` - The whole frame MBs are completely refreshed in cyclic order - after the specified period. + after the specified period. ``V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD (integer)`` Intra macroblock refresh period. This sets the period to refresh -- cgit From 7335631fcd5eecfa84555bd57433e6446d06ad21 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Fri, 15 Apr 2022 00:17:47 +0200 Subject: dt-bindings: clock: u8500: Add clkout clock bindings This adds device tree bindings for the externally routed clocks CLKOUT1 and CLKOUT2 clocks found in the DB8500. Cc: devicetree@vger.kernel.org Reviewed-by: Ulf Hansson Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220414221751.323525-2-linus.walleij@linaro.org Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- .../bindings/clock/stericsson,u8500-clks.yaml | 57 ++++++++++++++++++++++ 1 file changed, 57 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/stericsson,u8500-clks.yaml b/Documentation/devicetree/bindings/clock/stericsson,u8500-clks.yaml index 9bc95a308477..2150307219a0 100644 --- a/Documentation/devicetree/bindings/clock/stericsson,u8500-clks.yaml +++ b/Documentation/devicetree/bindings/clock/stericsson,u8500-clks.yaml @@ -109,6 +109,25 @@ properties: additionalProperties: false + clkout-clock: + description: A subnode with three clock cells for externally routed clocks, + output clocks. These are two PRCMU-internal clocks that can be divided and + muxed out on the pads of the DB8500 SoC. + type: object + + properties: + '#clock-cells': + description: + The first cell indicates which output clock we are using, + possible values are 0 (CLKOUT1) and 1 (CLKOUT2). + The second cell indicates which clock we want to use as source, + possible values are 0 thru 7, see the defines for the different + source clocks. + The third cell is a divider, legal values are 1 thru 63. + const: 3 + + additionalProperties: false + required: - compatible - reg @@ -119,3 +138,41 @@ required: - smp-twd-clock additionalProperties: false + +examples: + - | + #include + clocks@8012 { + compatible = "stericsson,u8500-clks"; + reg = <0x8012f000 0x1000>, <0x8011f000 0x1000>, + <0x8000f000 0x1000>, <0xa03ff000 0x1000>, + <0xa03cf000 0x1000>; + + prcmu_clk: prcmu-clock { + #clock-cells = <1>; + }; + + prcc_pclk: prcc-periph-clock { + #clock-cells = <2>; + }; + + prcc_kclk: prcc-kernel-clock { + #clock-cells = <2>; + }; + + prcc_reset: prcc-reset-controller { + #reset-cells = <2>; + }; + + rtc_clk: rtc32k-clock { + #clock-cells = <0>; + }; + + smp_twd_clk: smp-twd-clock { + #clock-cells = <0>; + }; + + clkout_clk: clkout-clock { + #clock-cells = <3>; + }; + }; -- cgit From f113a51aa2cfbd22c376d8722b5c9fef469be162 Mon Sep 17 00:00:00 2001 From: Chun-Jie Chen Date: Sat, 9 Apr 2022 21:22:37 +0800 Subject: dt-bindings: ARM: MediaTek: Add new document bindings of MT8186 clock This patch adds the new binding documentation for system clock and functional clock on MediaTek MT8186. Signed-off-by: Chun-Jie Chen Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220409132251.31725-2-chun-jie.chen@mediatek.com Signed-off-by: Stephen Boyd --- .../arm/mediatek/mediatek,mt8186-clock.yaml | 56 ++++++++++++++++++++++ .../arm/mediatek/mediatek,mt8186-sys-clock.yaml | 54 +++++++++++++++++++++ 2 files changed, 110 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml new file mode 100644 index 000000000000..cf1002c3efa6 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-clock.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek Functional Clock Controller for MT8186 + +maintainers: + - Chun-Jie Chen + +description: | + The clock architecture in MediaTek like below + PLLs --> + dividers --> + muxes + --> + clock gate + + The devices provide clock gate control in different IP blocks. + +properties: + compatible: + items: + - enum: + - mediatek,mt8186-imp_iic_wrap + - mediatek,mt8186-mfgsys + - mediatek,mt8186-wpesys + - mediatek,mt8186-imgsys1 + - mediatek,mt8186-imgsys2 + - mediatek,mt8186-vdecsys + - mediatek,mt8186-vencsys + - mediatek,mt8186-camsys + - mediatek,mt8186-camsys_rawa + - mediatek,mt8186-camsys_rawb + - mediatek,mt8186-mdpsys + - mediatek,mt8186-ipesys + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + imp_iic_wrap: clock-controller@11017000 { + compatible = "mediatek,mt8186-imp_iic_wrap"; + reg = <0x11017000 0x1000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml new file mode 100644 index 000000000000..0886e2e335bb --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-sys-clock.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek System Clock Controller for MT8186 + +maintainers: + - Chun-Jie Chen + +description: | + The clock architecture in MediaTek like below + PLLs --> + dividers --> + muxes + --> + clock gate + + The apmixedsys provides most of PLLs which generated from SoC 26m. + The topckgen provides dividers and muxes which provide the clock source to other IP blocks. + The infracfg_ao provides clock gate in peripheral and infrastructure IP blocks. + The mcusys provides mux control to select the clock source in AP MCU. + The device nodes also provide the system control capacity for configuration. + +properties: + compatible: + items: + - enum: + - mediatek,mt8186-mcusys + - mediatek,mt8186-topckgen + - mediatek,mt8186-infracfg_ao + - mediatek,mt8186-apmixedsys + - const: syscon + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + topckgen: syscon@10000000 { + compatible = "mediatek,mt8186-topckgen", "syscon"; + reg = <0x10000000 0x1000>; + #clock-cells = <1>; + }; -- cgit From 31a644b3c2ae6d0c47e84614ded3ce9bef1adb7a Mon Sep 17 00:00:00 2001 From: Damien Le Moal Date: Mon, 18 Apr 2022 09:32:57 +0900 Subject: documentation: zonefs: Document sysfs attributes Document the max_wro_seq_files, nr_wro_seq_files, max_active_seq_files and nr_active_seq_files sysfs attributes. Signed-off-by: Damien Le Moal Reviewed-by: Johannes Thumshirn Reviewed-by: Hans Holmberg Reviewed-by: Sergey Shtylyov --- Documentation/filesystems/zonefs.rst | 38 ++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/zonefs.rst b/Documentation/filesystems/zonefs.rst index 72d4baba0b6a..394b9f15dce0 100644 --- a/Documentation/filesystems/zonefs.rst +++ b/Documentation/filesystems/zonefs.rst @@ -351,6 +351,44 @@ guaranteed that write requests can be processed. Conversely, the to the device on the last close() of a zone file if the zone is not full nor empty. +Runtime sysfs attributes +------------------------ + +zonefs defines several sysfs attributes for mounted devices. All attributes +are user readable and can be found in the directory /sys/fs/zonefs//, +where is the name of the mounted zoned block device. + +The attributes defined are as follows. + +* **max_wro_seq_files**: This attribute reports the maximum number of + sequential zone files that can be open for writing. This number corresponds + to the maximum number of explicitly or implicitly open zones that the device + supports. A value of 0 means that the device has no limit and that any zone + (any file) can be open for writing and written at any time, regardless of the + state of other zones. When the *explicit-open* mount option is used, zonefs + will fail any open() system call requesting to open a sequential zone file for + writing when the number of sequential zone files already open for writing has + reached the *max_wro_seq_files* limit. +* **nr_wro_seq_files**: This attribute reports the current number of sequential + zone files open for writing. When the "explicit-open" mount option is used, + this number can never exceed *max_wro_seq_files*. If the *explicit-open* + mount option is not used, the reported number can be greater than + *max_wro_seq_files*. In such case, it is the responsibility of the + application to not write simultaneously more than *max_wro_seq_files* + sequential zone files. Failure to do so can result in write errors. +* **max_active_seq_files**: This attribute reports the maximum number of + sequential zone files that are in an active state, that is, sequential zone + files that are partially writen (not empty nor full) or that have a zone that + is explicitly open (which happens only if the *explicit-open* mount option is + used). This number is always equal to the maximum number of active zones that + the device supports. A value of 0 means that the mounted device has no limit + on the number of sequential zone files that can be active. +* **nr_active_seq_files**: This attributes reports the current number of + sequential zone files that are active. If *max_active_seq_files* is not 0, + then the value of *nr_active_seq_files* can never exceed the value of + *nr_active_seq_files*, regardless of the use of the *explicit-open* mount + option. + Zonefs User Space Tools ======================= -- cgit From 15a1c2d80ae192261b5e4759d8d987ab30f6c3f4 Mon Sep 17 00:00:00 2001 From: Sumit Gupta Date: Tue, 5 Apr 2022 18:31:16 +0530 Subject: dt-bindings: Document Tegra CCPLEX Cluster The Tegra CPU COMPLEX CLUSTER area contains memory-mapped registers that initiate CPU frequency/voltage transitions. Signed-off-by: Sumit Gupta Reviewed-by: Rob Herring Signed-off-by: Viresh Kumar --- .../arm/tegra/nvidia,tegra-ccplex-cluster.yaml | 52 ++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml new file mode 100644 index 000000000000..8c6543b5c0dc --- /dev/null +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra-ccplex-cluster.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: NVIDIA Tegra CPU COMPLEX CLUSTER area device tree bindings + +maintainers: + - Sumit Gupta + - Mikko Perttunen + - Jon Hunter + - Thierry Reding + +description: |+ + The Tegra CPU COMPLEX CLUSTER area contains memory-mapped + registers that initiate CPU frequency/voltage transitions. + +properties: + $nodename: + pattern: "ccplex@([0-9a-f]+)$" + + compatible: + enum: + - nvidia,tegra186-ccplex-cluster + - nvidia,tegra234-ccplex-cluster + + reg: + maxItems: 1 + + nvidia,bpmp: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: | + Specifies the BPMP node that needs to be queried to get + operating point data for all CPUs. + +additionalProperties: false + +required: + - compatible + - reg + - nvidia,bpmp + - status + +examples: + - | + ccplex@e000000 { + compatible = "nvidia,tegra234-ccplex-cluster"; + reg = <0x0e000000 0x5ffff>; + nvidia,bpmp = <&bpmp>; + status = "okay"; + }; -- cgit From b59add5e6e5a66ae3f6a42a573b6e56b6dbaee41 Mon Sep 17 00:00:00 2001 From: Allen-KH Cheng Date: Tue, 19 Apr 2022 17:20:30 +0800 Subject: dt-bindings: arm: Add compatible for Mediatek MT8192 This commit adds dt-binding documentation for the Mediatek MT8192 reference board. Signed-off-by: Allen-KH Cheng Link: https://lore.kernel.org/r/20220419092030.30519-1-allen-kh.cheng@mediatek.com Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index ab0593c77321..3a9b92ee915b 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -131,6 +131,10 @@ properties: - enum: - mediatek,mt8183-evb - const: mediatek,mt8183 + - items: + - enum: + - mediatek,mt8192-evb + - const: mediatek,mt8192 - items: - enum: - mediatek,mt8195-evb -- cgit From cc9d1e59f47562a3b9c812c29d84996e36234308 Mon Sep 17 00:00:00 2001 From: Fabien Parent Date: Fri, 15 Apr 2022 17:00:00 +0200 Subject: dt-bindings: arm64: dts: mediatek: Add mt8195-demo board Add bindings for the MediaTek mt8195-demo board. Signed-off-by: Fabien Parent Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220415150003.1793063-2-fparent@baylibre.com Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/arm/mediatek.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 3a9b92ee915b..4a2bd9759c47 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -137,6 +137,7 @@ properties: - const: mediatek,mt8192 - items: - enum: + - mediatek,mt8195-demo - mediatek,mt8195-evb - const: mediatek,mt8195 - description: Google Burnet (HP Chromebook x360 11MK G3 EE) -- cgit From 97730bbb242cde22b7140acd202ffd88823886c9 Mon Sep 17 00:00:00 2001 From: Russ Weight Date: Thu, 21 Apr 2022 14:22:00 -0700 Subject: firmware_loader: Add firmware-upload support Extend the firmware subsystem to support a persistent sysfs interface that userspace may use to initiate a firmware update. For example, FPGA based PCIe cards load firmware and FPGA images from local FLASH when the card boots. The images in FLASH may be updated with new images provided by the user at his/her convenience. A device driver may call firmware_upload_register() to expose persistent "loading" and "data" sysfs files. These files are used in the same way as the fallback sysfs "loading" and "data" files. When 0 is written to "loading" to complete the write of firmware data, the data is transferred to the lower-level driver using pre-registered call-back functions. The data transfer is done in the context of a kernel worker thread. Reviewed-by: Luis Chamberlain Reviewed-by: Tianfei zhang Tested-by: Matthew Gerlach Signed-off-by: Russ Weight Link: https://lore.kernel.org/r/20220421212204.36052-5-russell.h.weight@intel.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-class-firmware | 32 +++++++ Documentation/driver-api/firmware/fw_upload.rst | 107 ++++++++++++++++++++++++ Documentation/driver-api/firmware/index.rst | 1 + 3 files changed, 140 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-firmware create mode 100644 Documentation/driver-api/firmware/fw_upload.rst (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-firmware b/Documentation/ABI/testing/sysfs-class-firmware new file mode 100644 index 000000000000..18336c23b70d --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-firmware @@ -0,0 +1,32 @@ +What: /sys/class/firmware/.../data +Date: July 2022 +KernelVersion: 5.19 +Contact: Russ Weight +Description: The data sysfs file is used for firmware-fallback and for + firmware uploads. Cat a firmware image to this sysfs file + after you echo 1 to the loading sysfs file. When the firmware + image write is complete, echo 0 to the loading sysfs file. This + sequence will signal the completion of the firmware write and + signal the lower-level driver that the firmware data is + available. + +What: /sys/class/firmware/.../loading +Date: July 2022 +KernelVersion: 5.19 +Contact: Russ Weight +Description: The loading sysfs file is used for both firmware-fallback and + for firmware uploads. Echo 1 onto the loading file to indicate + you are writing a firmware file to the data sysfs node. Echo + -1 onto this file to abort the data write or echo 0 onto this + file to indicate that the write is complete. For firmware + uploads, the zero value also triggers the transfer of the + firmware data to the lower-level device driver. + +What: /sys/class/firmware/.../timeout +Date: July 2022 +KernelVersion: 5.19 +Contact: Russ Weight +Description: This file supports the timeout mechanism for firmware + fallback. This file has no affect on firmware uploads. For + more information on timeouts please see the documentation + for firmware fallback. diff --git a/Documentation/driver-api/firmware/fw_upload.rst b/Documentation/driver-api/firmware/fw_upload.rst new file mode 100644 index 000000000000..afbd8baca0d7 --- /dev/null +++ b/Documentation/driver-api/firmware/fw_upload.rst @@ -0,0 +1,107 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================== +Firmware Upload API +=================== + +A device driver that registers with the firmware loader will expose +persistent sysfs nodes to enable users to initiate firmware updates for +that device. It is the responsibility of the device driver and/or the +device itself to perform any validation on the data received. Firmware +upload uses the same *loading* and *data* sysfs files described in the +documentation for firmware fallback. + +Register for firmware upload +============================ + +A device driver registers for firmware upload by calling +firmware_upload_register(). Among the parameter list is a name to +identify the device under /sys/class/firmware. A user may initiate a +firmware upload by echoing a 1 to the *loading* sysfs file for the target +device. Next, the user writes the firmware image to the *data* sysfs +file. After writing the firmware data, the user echos 0 to the *loading* +sysfs file to signal completion. Echoing 0 to *loading* also triggers the +transfer of the firmware to the lower-lever device driver in the context +of a kernel worker thread. + +To use the firmware upload API, write a driver that implements a set of +ops. The probe function calls firmware_upload_register() and the remove +function calls firmware_upload_unregister() such as:: + + static const struct fw_upload_ops m10bmc_ops = { + .prepare = m10bmc_sec_prepare, + .write = m10bmc_sec_write, + .poll_complete = m10bmc_sec_poll_complete, + .cancel = m10bmc_sec_cancel, + .cleanup = m10bmc_sec_cleanup, + }; + + static int m10bmc_sec_probe(struct platform_device *pdev) + { + const char *fw_name, *truncate; + struct m10bmc_sec *sec; + struct fw_upload *fwl; + unsigned int len; + + sec = devm_kzalloc(&pdev->dev, sizeof(*sec), GFP_KERNEL); + if (!sec) + return -ENOMEM; + + sec->dev = &pdev->dev; + sec->m10bmc = dev_get_drvdata(pdev->dev.parent); + dev_set_drvdata(&pdev->dev, sec); + + fw_name = dev_name(sec->dev); + truncate = strstr(fw_name, ".auto"); + len = (truncate) ? truncate - fw_name : strlen(fw_name); + sec->fw_name = kmemdup_nul(fw_name, len, GFP_KERNEL); + + fwl = firmware_upload_register(sec->dev, sec->fw_name, &m10bmc_ops, sec); + if (IS_ERR(fwl)) { + dev_err(sec->dev, "Firmware Upload driver failed to start\n"); + kfree(sec->fw_name); + return PTR_ERR(fwl); + } + + sec->fwl = fwl; + return 0; + } + + static int m10bmc_sec_remove(struct platform_device *pdev) + { + struct m10bmc_sec *sec = dev_get_drvdata(&pdev->dev); + + firmware_upload_unregister(sec->fwl); + kfree(sec->fw_name); + return 0; + } + +firmware_upload_register +------------------------ +.. kernel-doc:: drivers/base/firmware_loader/sysfs_upload.c + :identifiers: firmware_upload_register + +firmware_upload_unregister +-------------------------- +.. kernel-doc:: drivers/base/firmware_loader/sysfs_upload.c + :identifiers: firmware_upload_unregister + +Firmware Upload Ops +------------------- +.. kernel-doc:: include/linux/firmware.h + :identifiers: fw_upload_ops + +Firmware Upload Progress Codes +------------------------------ +The following progress codes are used internally by the firmware loader: + +.. kernel-doc:: drivers/base/firmware_loader/sysfs_upload.h + :identifiers: fw_upload_prog + +Firmware Upload Error Codes +--------------------------- +The following error codes may be returned by the driver ops in case of +failure: + +.. kernel-doc:: include/linux/firmware.h + :identifiers: fw_upload_err diff --git a/Documentation/driver-api/firmware/index.rst b/Documentation/driver-api/firmware/index.rst index 57415d657173..9d2c19dc8e36 100644 --- a/Documentation/driver-api/firmware/index.rst +++ b/Documentation/driver-api/firmware/index.rst @@ -8,6 +8,7 @@ Linux Firmware API core efi/index request_firmware + fw_upload other_interfaces .. only:: subproject and html -- cgit From 536fd8184b7dfa30e28e5b459e7c5c91c3a8063f Mon Sep 17 00:00:00 2001 From: Russ Weight Date: Thu, 21 Apr 2022 14:22:01 -0700 Subject: firmware_loader: Add sysfs nodes to monitor fw_upload Add additional sysfs nodes to monitor the transfer of firmware upload data to the target device: cancel: Write 1 to cancel the data transfer error: Display error status for a failed firmware upload remaining_size: Display the remaining amount of data to be transferred status: Display the progress of the firmware upload Reviewed-by: Luis Chamberlain Reviewed-by: Tianfei zhang Tested-by: Matthew Gerlach Signed-off-by: Russ Weight Link: https://lore.kernel.org/r/20220421212204.36052-6-russell.h.weight@intel.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-class-firmware | 45 +++++++++++++++++++++++++ Documentation/driver-api/firmware/fw_upload.rst | 23 +++++++++++-- 2 files changed, 66 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-firmware b/Documentation/ABI/testing/sysfs-class-firmware index 18336c23b70d..978d3d500400 100644 --- a/Documentation/ABI/testing/sysfs-class-firmware +++ b/Documentation/ABI/testing/sysfs-class-firmware @@ -10,6 +10,30 @@ Description: The data sysfs file is used for firmware-fallback and for signal the lower-level driver that the firmware data is available. +What: /sys/class/firmware/.../cancel +Date: July 2022 +KernelVersion: 5.19 +Contact: Russ Weight +Description: Write-only. For firmware uploads, write a "1" to this file to + request that the transfer of firmware data to the lower-level + device be canceled. This request will be rejected (EBUSY) if + the update cannot be canceled (e.g. a FLASH write is in + progress) or (ENODEV) if there is no firmware update in progress. + +What: /sys/class/firmware/.../error +Date: July 2022 +KernelVersion: 5.19 +Contact: Russ Weight +Description: Read-only. Returns a string describing a failed firmware + upload. This string will be in the form of :, + where will be one of the status strings described + for the status sysfs file and will be one of the + following: "hw-error", "timeout", "user-abort", "device-busy", + "invalid-file-size", "read-write-error", "flash-wearout". The + error sysfs file is only meaningful when the current firmware + upload status is "idle". If this file is read while a firmware + transfer is in progress, then the read will fail with EBUSY. + What: /sys/class/firmware/.../loading Date: July 2022 KernelVersion: 5.19 @@ -22,6 +46,27 @@ Description: The loading sysfs file is used for both firmware-fallback and uploads, the zero value also triggers the transfer of the firmware data to the lower-level device driver. +What: /sys/class/firmware/.../remaining_size +Date: July 2022 +KernelVersion: 5.19 +Contact: Russ Weight +Description: Read-only. For firmware upload, this file contains the size + of the firmware data that remains to be transferred to the + lower-level device driver. The size value is initialized to + the full size of the firmware image that was previously + written to the data sysfs file. This value is periodically + updated during the "transferring" phase of the firmware + upload. + Format: "%u". + +What: /sys/class/firmware/.../status +Date: July 2022 +KernelVersion: 5.19 +Contact: Russ Weight +Description: Read-only. Returns a string describing the current status of + a firmware upload. The string will be one of the following: + idle, "receiving", "preparing", "transferring", "programming". + What: /sys/class/firmware/.../timeout Date: July 2022 KernelVersion: 5.19 diff --git a/Documentation/driver-api/firmware/fw_upload.rst b/Documentation/driver-api/firmware/fw_upload.rst index afbd8baca0d7..76922591e446 100644 --- a/Documentation/driver-api/firmware/fw_upload.rst +++ b/Documentation/driver-api/firmware/fw_upload.rst @@ -9,7 +9,8 @@ persistent sysfs nodes to enable users to initiate firmware updates for that device. It is the responsibility of the device driver and/or the device itself to perform any validation on the data received. Firmware upload uses the same *loading* and *data* sysfs files described in the -documentation for firmware fallback. +documentation for firmware fallback. It also adds additional sysfs files +to provide status on the transfer of the firmware image to the device. Register for firmware upload ============================ @@ -93,7 +94,9 @@ Firmware Upload Ops Firmware Upload Progress Codes ------------------------------ -The following progress codes are used internally by the firmware loader: +The following progress codes are used internally by the firmware loader. +Corresponding strings are reported through the status sysfs node that +is described below and are documented in the ABI documentation. .. kernel-doc:: drivers/base/firmware_loader/sysfs_upload.h :identifiers: fw_upload_prog @@ -105,3 +108,19 @@ failure: .. kernel-doc:: include/linux/firmware.h :identifiers: fw_upload_err + +Sysfs Attributes +================ + +In addition to the *loading* and *data* sysfs files, there are additional +sysfs files to monitor the status of the data transfer to the target +device and to determine the final pass/fail status of the transfer. +Depending on the device and the size of the firmware image, a firmware +update could take milliseconds or minutes. + +The additional sysfs files are: + +* status - provides an indication of the progress of a firmware update +* error - provides error information for a failed firmware update +* remaining_size - tracks the data transfer portion of an update +* cancel - echo 1 to this file to cancel the update -- cgit From d405ac52ab19301622bddabf4bf925d199937823 Mon Sep 17 00:00:00 2001 From: Rohit Agarwal Date: Wed, 13 Apr 2022 18:23:34 +0530 Subject: dt-bindings: interconnect: Add Qualcomm SDX65 DT bindings Add interconnect IDs for Qualcomm SDX65 platform. Signed-off-by: Rohit Agarwal Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/1649854415-11174-2-git-send-email-quic_rohiagar@quicinc.com Signed-off-by: Georgi Djakov --- Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index 5a911be0c2ea..9ee2a51d6ad7 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -72,6 +72,9 @@ properties: - qcom,sdx55-mc-virt - qcom,sdx55-mem-noc - qcom,sdx55-system-noc + - qcom,sdx65-mc-virt + - qcom,sdx65-mem-noc + - qcom,sdx65-system-noc - qcom,sm8150-aggre1-noc - qcom,sm8150-aggre2-noc - qcom,sm8150-camnoc-noc -- cgit From 85a503c9ea7d4978db5f98de941e6c04b44623f1 Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda Date: Mon, 25 Apr 2022 15:41:57 +0900 Subject: dt-bindings: serial: renesas,hscif: Document r8a779g0 bindings R-Car V4H (R8A779G0) SoC has the R-Car Gen4 compatible HSCIF ports, so document the SoC specific bindings. Signed-off-by: Yoshihiro Shimoda Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220425064201.459633-4-yoshihiro.shimoda.uh@renesas.com Reviewed-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/renesas,hscif.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml index ee9804cd49bb..d688a07a0e29 100644 --- a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml @@ -55,6 +55,12 @@ properties: - const: renesas,rcar-gen3-hscif # R-Car Gen3 and RZ/G2 - const: renesas,hscif # generic HSCIF compatible UART + - items: + - enum: + - renesas,hscif-r8a779g0 # R-Car V4H + - const: renesas,rcar-gen4-hscif # R-Car Gen4 + - const: renesas,hscif # generic HSCIF compatible UART + reg: maxItems: 1 @@ -113,6 +119,7 @@ if: enum: - renesas,rcar-gen2-hscif - renesas,rcar-gen3-hscif + - renesas,rcar-gen4-hscif then: required: - resets -- cgit From 7a60fa06e80596dba5381fb018f5102ae4897658 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Mon, 25 Apr 2022 15:02:15 +0100 Subject: dt-bindings: usb: renesas,usbhs: Document RZ/G2UL bindings Document RZ/G2ULSoC bindings. USBHS block is identical to one found on RZ/A2 SoC. No driver changes are required as generic compatible string "renesas,rza2-usbhs" will be used as a fallback. While at it, make the resets property required on RZ/{G2L,G2UL,V2L} SoC. Reviewed-by: Geert Uytterhoeven Acked-by: Krzysztof Kozlowski Signed-off-by: Biju Das Link: https://lore.kernel.org/r/20220425140215.186797-1-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/renesas,usbhs.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml index 0bb841b28003..bad55dfb2fa0 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml @@ -19,6 +19,7 @@ properties: - items: - enum: - renesas,usbhs-r7s9210 # RZ/A2 + - renesas,usbhs-r9a07g043 # RZ/G2UL - renesas,usbhs-r9a07g044 # RZ/G2{L,LC} - renesas,usbhs-r9a07g054 # RZ/V2L - const: renesas,rza2-usbhs @@ -118,6 +119,7 @@ allOf: compatible: contains: enum: + - renesas,usbhs-r9a07g043 - renesas,usbhs-r9a07g044 - renesas,usbhs-r9a07g054 then: @@ -128,6 +130,8 @@ allOf: - description: U2P_INT_DMA[0] - description: U2P_INT_DMA[1] - description: U2P_INT_DMAERR + required: + - resets else: properties: interrupts: -- cgit From 01afa882f12dbd4a452c86215dbb6d2d05f69e4c Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Fri, 22 Apr 2022 15:23:50 -0700 Subject: dt-bindings: usb: Add binding for fcs,fsa4480 The Fairchild/ON Semiconductor FSA4480 Analog Audio switch is used in USB Type-C configurations for muxing analog audio onto the USB connector, and as such used to control the SBU signals for altmodes such as DisplayPort. Add a binding for this hardware block. Reviewed-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220422222351.1297276-7-bjorn.andersson@linaro.org Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/fcs,fsa4480.yaml | 72 ++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml new file mode 100644 index 000000000000..9473f26b0621 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/usb/fcs,fsa4480.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: ON Semiconductor Analog Audio Switch + +maintainers: + - Bjorn Andersson + +properties: + compatible: + enum: + - fcs,fsa4480 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vcc-supply: + description: power supply (2.7V-5.5V) + + mode-switch: + description: Flag the port as possible handle of altmode switching + type: boolean + + orientation-switch: + description: Flag the port as possible handler of orientation switching + type: boolean + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + A port node to link the FSA4480 to a TypeC controller for the purpose of + handling altmode muxing and orientation switching. + +required: + - compatible + - reg + - port + +additionalProperties: false + +examples: + - | + #include + i2c13 { + #address-cells = <1>; + #size-cells = <0>; + + fsa4480@42 { + compatible = "fcs,fsa4480"; + reg = <0x42>; + + interrupts-extended = <&tlmm 2 IRQ_TYPE_LEVEL_LOW>; + + vcc-supply = <&vreg_bob>; + + mode-switch; + orientation-switch; + + port { + fsa4480_ept: endpoint { + remote-endpoint = <&typec_controller>; + }; + }; + }; + }; +... -- cgit From 501c12a6a774ee25c1f07e724c08f72ec7042f88 Mon Sep 17 00:00:00 2001 From: Nick Hawkins Date: Thu, 21 Apr 2022 14:21:29 -0500 Subject: dt-bindings: usb: generic-ehci: Add HPE GXP ehci binding Add hpe,gxp-ehci to the generic-ehci list. This is to enable the device tree. Signed-off-by: Nick Hawkins Link: https://lore.kernel.org/r/20220421192132.109954-9-nick.hawkins@hpe.com Acked-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/generic-ehci.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml index 8913497624de..0b4524b6409e 100644 --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml @@ -55,6 +55,7 @@ properties: - brcm,bcm7420-ehci - brcm,bcm7425-ehci - brcm,bcm7435-ehci + - hpe,gxp-ehci - ibm,476gtr-ehci - nxp,lpc1850-ehci - qca,ar7100-ehci -- cgit From 9c1c0fdd04b5758aa35ac0f7ea802a1a599777a2 Mon Sep 17 00:00:00 2001 From: Nick Hawkins Date: Thu, 21 Apr 2022 14:21:30 -0500 Subject: dt-bindings: usb: generic-ohci: Add HPE GXP ohci binding Add hpe,gxp-ohci to the generic-ohci list. This is to enable the device tree support. Signed-off-by: Nick Hawkins Link: https://lore.kernel.org/r/20220421192132.109954-10-nick.hawkins@hpe.com Acked-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/generic-ohci.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml index acbf94fa5f74..e2ac84665316 100644 --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml @@ -42,6 +42,7 @@ properties: - brcm,bcm7420-ohci - brcm,bcm7425-ohci - brcm,bcm7435-ohci + - hpe,gxp-ohci - ibm,476gtr-ohci - ingenic,jz4740-ohci - snps,hsdk-v1.0-ohci -- cgit From 0298b4b95cb373c21e6323c905589f8dac42c5b4 Mon Sep 17 00:00:00 2001 From: Matthias Kaehlcke Date: Thu, 17 Feb 2022 10:42:53 -0800 Subject: usb: misc: Add onboard_usb_hub driver The main issue this driver addresses is that a USB hub needs to be powered before it can be discovered. For discrete onboard hubs (an example for such a hub is the Realtek RTS5411) this is often solved by supplying the hub with an 'always-on' regulator, which is kind of a hack. Some onboard hubs may require further initialization steps, like changing the state of a GPIO or enabling a clock, which requires even more hacks. This driver creates a platform device representing the hub which performs the necessary initialization. Currently it only supports switching on a single regulator, support for multiple regulators or other actions can be added as needed. Different initialization sequences can be supported based on the compatible string. Besides performing the initialization the driver can be configured to power the hub off during system suspend. This can help to extend battery life on battery powered devices which have no requirements to keep the hub powered during suspend. The driver can also be configured to leave the hub powered when a wakeup capable USB device is connected when suspending, and power it off otherwise. Technically the driver consists of two drivers, the platform driver described above and a very thin USB driver that subclasses the generic driver. The purpose of this driver is to provide the platform driver with the USB devices corresponding to the hub(s) (a hub controller may provide multiple 'logical' hubs, e.g. one to support USB 2.0 and another for USB 3.x). Note: the current series only supports hubs connected directly to a root hub, support for other configurations could be added if needed. Co-developed-by: Ravi Chandra Sadineni Reviewed-by: Douglas Anderson Acked-by: Alan Stern Signed-off-by: Ravi Chandra Sadineni Signed-off-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20220217104219.v21.2.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub b/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub new file mode 100644 index 000000000000..af818d9d90c1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub @@ -0,0 +1,8 @@ +What: /sys/bus/platform/devices//always_powered_in_suspend +Date: February 2022 +KernelVersion: 5.18 +Contact: Matthias Kaehlcke + linux-usb@vger.kernel.org +Description: + (RW) Controls whether the USB hub remains always powered + during system suspend or not. \ No newline at end of file -- cgit From 3ddfa03d8162264b32b95b26eccb902ed4e07f3f Mon Sep 17 00:00:00 2001 From: Chris Packham Date: Wed, 30 Mar 2022 11:05:44 +1300 Subject: dt-bindings: mmc: xenon: Convert to JSON schema Convert the marvell,xenon-sdhci binding to JSON schema. Currently the in-tree dts files don't validate because they use sdhci@ instead of mmc@ as required by the generic mmc-controller schema. The compatible "marvell,sdhci-xenon" was not documented in the old binding but it accompanies the of "marvell,armada-3700-sdhci" in the armada-37xx SoC dtsi so this combination is added to the new binding document. Signed-off-by: Chris Packham Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220329220544.2132135-3-chris.packham@alliedtelesis.co.nz Signed-off-by: Ulf Hansson --- .../bindings/mmc/marvell,xenon-sdhci.txt | 173 ------------- .../bindings/mmc/marvell,xenon-sdhci.yaml | 275 +++++++++++++++++++++ 2 files changed, 275 insertions(+), 173 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt deleted file mode 100644 index c51a62d751dc..000000000000 --- a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt +++ /dev/null @@ -1,173 +0,0 @@ -Marvell Xenon SDHCI Controller device tree bindings -This file documents differences between the core mmc properties -described by mmc.txt and the properties used by the Xenon implementation. - -Multiple SDHCs might be put into a single Xenon IP, to save size and cost. -Each SDHC is independent and owns independent resources, such as register sets, -clock and PHY. -Each SDHC should have an independent device tree node. - -Required Properties: -- compatible: should be one of the following - - "marvell,armada-3700-sdhci": For controllers on Armada-3700 SoC. - Must provide a second register area and marvell,pad-type. - - "marvell,armada-ap806-sdhci": For controllers on Armada AP806. - - "marvell,armada-ap807-sdhci": For controllers on Armada AP807. - - "marvell,armada-cp110-sdhci": For controllers on Armada CP110. - -- clocks: - Array of clocks required for SDHC. - Require at least input clock for Xenon IP core. For Armada AP806 and - CP110, the AXI clock is also mandatory. - -- clock-names: - Array of names corresponding to clocks property. - The input clock for Xenon IP core should be named as "core". - The input clock for the AXI bus must be named as "axi". - -- reg: - * For "marvell,armada-3700-sdhci", two register areas. - The first one for Xenon IP register. The second one for the Armada 3700 SoC - PHY PAD Voltage Control register. - Please follow the examples with compatible "marvell,armada-3700-sdhci" - in below. - Please also check property marvell,pad-type in below. - - * For other compatible strings, one register area for Xenon IP. - -Optional Properties: -- marvell,xenon-sdhc-id: - Indicate the corresponding bit index of current SDHC in - SDHC System Operation Control Register Bit[7:0]. - Set/clear the corresponding bit to enable/disable current SDHC. - If Xenon IP contains only one SDHC, this property is optional. - -- marvell,xenon-phy-type: - Xenon support multiple types of PHYs. - To select eMMC 5.1 PHY, set: - marvell,xenon-phy-type = "emmc 5.1 phy" - eMMC 5.1 PHY is the default choice if this property is not provided. - To select eMMC 5.0 PHY, set: - marvell,xenon-phy-type = "emmc 5.0 phy" - - All those types of PHYs can support eMMC, SD and SDIO. - Please note that this property only presents the type of PHY. - It doesn't stand for the entire SDHC type or property. - For example, "emmc 5.1 phy" doesn't mean that this Xenon SDHC only - supports eMMC 5.1. - -- marvell,xenon-phy-znr: - Set PHY ZNR value. - Only available for eMMC PHY. - Valid range = [0:0x1F]. - ZNR is set as 0xF by default if this property is not provided. - -- marvell,xenon-phy-zpr: - Set PHY ZPR value. - Only available for eMMC PHY. - Valid range = [0:0x1F]. - ZPR is set as 0xF by default if this property is not provided. - -- marvell,xenon-phy-nr-success-tun: - Set the number of required consecutive successful sampling points - used to identify a valid sampling window, in tuning process. - Valid range = [1:7]. - Set as 0x4 by default if this property is not provided. - -- marvell,xenon-phy-tun-step-divider: - Set the divider for calculating TUN_STEP. - Set as 64 by default if this property is not provided. - -- marvell,xenon-phy-slow-mode: - If this property is selected, transfers will bypass PHY. - Only available when bus frequency lower than 55MHz in SDR mode. - Disabled by default. Please only try this property if timing issues - always occur with PHY enabled in eMMC HS SDR, SD SDR12, SD SDR25, - SD Default Speed and HS mode and eMMC legacy speed mode. - -- marvell,xenon-tun-count: - Xenon SDHC SoC usually doesn't provide re-tuning counter in - Capabilities Register 3 Bit[11:8]. - This property provides the re-tuning counter. - If this property is not set, default re-tuning counter will - be set as 0x9 in driver. - -- marvell,pad-type: - Type of Armada 3700 SoC PHY PAD Voltage Controller register. - Only valid when "marvell,armada-3700-sdhci" is selected. - Two types: "sd" and "fixed-1-8v". - If "sd" is selected, SoC PHY PAD is set as 3.3V at the beginning and is - switched to 1.8V when later in higher speed mode. - If "fixed-1-8v" is selected, SoC PHY PAD is fixed 1.8V, such as for eMMC. - Please follow the examples with compatible "marvell,armada-3700-sdhci" - in below. - -Example: -- For eMMC: - - sdhci@aa0000 { - compatible = "marvell,armada-ap806-sdhci"; - reg = <0xaa0000 0x1000>; - interrupts = - clocks = <&emmc_clk>,<&axi_clk>; - clock-names = "core", "axi"; - bus-width = <4>; - marvell,xenon-phy-slow-mode; - marvell,xenon-tun-count = <11>; - non-removable; - no-sd; - no-sdio; - - /* Vmmc and Vqmmc are both fixed */ - }; - -- For SD/SDIO: - - sdhci@ab0000 { - compatible = "marvell,armada-cp110-sdhci"; - reg = <0xab0000 0x1000>; - interrupts = - vqmmc-supply = <&sd_vqmmc_regulator>; - vmmc-supply = <&sd_vmmc_regulator>; - clocks = <&sdclk>, <&axi_clk>; - clock-names = "core", "axi"; - bus-width = <4>; - marvell,xenon-tun-count = <9>; - }; - -- For eMMC with compatible "marvell,armada-3700-sdhci": - - sdhci@aa0000 { - compatible = "marvell,armada-3700-sdhci"; - reg = <0xaa0000 0x1000>, - ; - interrupts = - clocks = <&emmcclk>; - clock-names = "core"; - bus-width = <8>; - mmc-ddr-1_8v; - mmc-hs400-1_8v; - non-removable; - no-sd; - no-sdio; - - /* Vmmc and Vqmmc are both fixed */ - - marvell,pad-type = "fixed-1-8v"; - }; - -- For SD/SDIO with compatible "marvell,armada-3700-sdhci": - - sdhci@ab0000 { - compatible = "marvell,armada-3700-sdhci"; - reg = <0xab0000 0x1000>, - ; - interrupts = - vqmmc-supply = <&sd_regulator>; - /* Vmmc is fixed */ - clocks = <&sdclk>; - clock-names = "core"; - bus-width = <4>; - - marvell,pad-type = "sd"; - }; diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml new file mode 100644 index 000000000000..c79639e9027e --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml @@ -0,0 +1,275 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell Xenon SDHCI Controller + +description: | + This file documents differences between the core MMC properties described by + mmc-controller.yaml and the properties used by the Xenon implementation. + + Multiple SDHCs might be put into a single Xenon IP, to save size and cost. + Each SDHC is independent and owns independent resources, such as register + sets, clock and PHY. + + Each SDHC should have an independent device tree node. + +maintainers: + - Ulf Hansson + +properties: + compatible: + oneOf: + - enum: + - marvell,armada-cp110-sdhci + - marvell,armada-ap806-sdhci + + - items: + - const: marvell,armada-ap807-sdhci + - const: marvell,armada-ap806-sdhci + + - items: + - const: marvell,armada-3700-sdhci + - const: marvell,sdhci-xenon + + reg: + minItems: 1 + maxItems: 2 + description: | + For "marvell,armada-3700-sdhci", two register areas. The first one + for Xenon IP register. The second one for the Armada 3700 SoC PHY PAD + Voltage Control register. Please follow the examples with compatible + "marvell,armada-3700-sdhci" in below. + Please also check property marvell,pad-type in below. + + For other compatible strings, one register area for Xenon IP. + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + items: + - const: core + - const: axi + + marvell,xenon-sdhc-id: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + description: | + Indicate the corresponding bit index of current SDHC in SDHC System + Operation Control Register Bit[7:0]. Set/clear the corresponding bit to + enable/disable current SDHC. + + marvell,xenon-phy-type: + $ref: /schemas/types.yaml#/definitions/string + enum: + - "emmc 5.1 phy" + - "emmc 5.0 phy" + description: | + Xenon support multiple types of PHYs. To select eMMC 5.1 PHY, set: + marvell,xenon-phy-type = "emmc 5.1 phy" eMMC 5.1 PHY is the default + choice if this property is not provided. To select eMMC 5.0 PHY, set: + marvell,xenon-phy-type = "emmc 5.0 phy" + + All those types of PHYs can support eMMC, SD and SDIO. Please note that + this property only presents the type of PHY. It doesn't stand for the + entire SDHC type or property. For example, "emmc 5.1 phy" doesn't mean + that this Xenon SDHC only supports eMMC 5.1. + + marvell,xenon-phy-znr: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 0x1f + default: 0xf + description: | + Set PHY ZNR value. + Only available for eMMC PHY. + + marvell,xenon-phy-zpr: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 0x1f + default: 0xf + description: | + Set PHY ZPR value. + Only available for eMMC PHY. + + marvell,xenon-phy-nr-success-tun: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 7 + default: 0x4 + description: | + Set the number of required consecutive successful sampling points + used to identify a valid sampling window, in tuning process. + + marvell,xenon-phy-tun-step-divider: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 64 + description: | + Set the divider for calculating TUN_STEP. + + marvell,xenon-phy-slow-mode: + type: boolean + description: | + If this property is selected, transfers will bypass PHY. + Only available when bus frequency lower than 55MHz in SDR mode. + Disabled by default. Please only try this property if timing issues + always occur with PHY enabled in eMMC HS SDR, SD SDR12, SD SDR25, + SD Default Speed and HS mode and eMMC legacy speed mode. + + marvell,xenon-tun-count: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0x9 + description: | + Xenon SDHC SoC usually doesn't provide re-tuning counter in + Capabilities Register 3 Bit[11:8]. + This property provides the re-tuning counter. + +allOf: + - $ref: mmc-controller.yaml# + - if: + properties: + compatible: + contains: + const: marvell,armada-3700-sdhci + + then: + properties: + reg: + items: + - description: Xenon IP registers + - description: Armada 3700 SoC PHY PAD Voltage Control register + minItems: 2 + + marvell,pad-type: + $ref: /schemas/types.yaml#/definitions/string + enum: + - sd + - fixed-1-8v + description: | + Type of Armada 3700 SoC PHY PAD Voltage Controller register. + If "sd" is selected, SoC PHY PAD is set as 3.3V at the beginning + and is switched to 1.8V when later in higher speed mode. + If "fixed-1-8v" is selected, SoC PHY PAD is fixed 1.8V, such as for + eMMC. + Please follow the examples with compatible + "marvell,armada-3700-sdhci" in below. + + required: + - marvell,pad-type + + - if: + properties: + compatible: + contains: + enum: + - marvell,armada-cp110-sdhci + - marvell,armada-ap807-sdhci + - marvell,armada-ap806-sdhci + + then: + properties: + clocks: + minItems: 2 + + clock-names: + items: + - const: core + - const: axi + + +required: + - compatible + - reg + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + // For eMMC + #include + #include + + mmc@aa0000 { + compatible = "marvell,armada-ap807-sdhci", "marvell,armada-ap806-sdhci"; + reg = <0xaa0000 0x1000>; + interrupts = ; + clocks = <&emmc_clk 0>, <&axi_clk 0>; + clock-names = "core", "axi"; + bus-width = <4>; + marvell,xenon-phy-slow-mode; + marvell,xenon-tun-count = <11>; + non-removable; + no-sd; + no-sdio; + + /* Vmmc and Vqmmc are both fixed */ + }; + + - | + // For SD/SDIO + #include + #include + + mmc@ab0000 { + compatible = "marvell,armada-cp110-sdhci"; + reg = <0xab0000 0x1000>; + interrupts = ; + vqmmc-supply = <&sd_vqmmc_regulator>; + vmmc-supply = <&sd_vmmc_regulator>; + clocks = <&sdclk 0>, <&axi_clk 0>; + clock-names = "core", "axi"; + bus-width = <4>; + marvell,xenon-tun-count = <9>; + }; + + - | + // For eMMC with compatible "marvell,armada-3700-sdhci": + #include + #include + + mmc@aa0000 { + compatible = "marvell,armada-3700-sdhci", "marvell,sdhci-xenon"; + reg = <0xaa0000 0x1000>, + <0x17808 0x4>; + interrupts = ; + clocks = <&emmcclk 0>; + clock-names = "core"; + bus-width = <8>; + mmc-ddr-1_8v; + mmc-hs400-1_8v; + non-removable; + no-sd; + no-sdio; + + /* Vmmc and Vqmmc are both fixed */ + + marvell,pad-type = "fixed-1-8v"; + }; + + - | + // For SD/SDIO with compatible "marvell,armada-3700-sdhci": + #include + #include + + mmc@ab0000 { + compatible = "marvell,armada-3700-sdhci", "marvell,sdhci-xenon"; + reg = <0xab0000 0x1000>, + <0x17808 0x4>; + interrupts = ; + vqmmc-supply = <&sd_regulator>; + /* Vmmc is fixed */ + clocks = <&sdclk 0>; + clock-names = "core"; + bus-width = <4>; + + marvell,pad-type = "sd"; + }; -- cgit From 7792fdf626c20aa4e0d2b0daacf4e30df3ff9583 Mon Sep 17 00:00:00 2001 From: Tinghan Shen Date: Wed, 30 Mar 2022 17:45:31 +0800 Subject: dt-bindings: mmc: mtk-sd: increase reg items MediaTek has a new version of mmc IP since mt8183. Some IO registers are moved to top to improve hardware design and named as "host top registers". Add host top register in the reg binding description for mt8183 and successors. Signed-off-by: Wenbin Mei Signed-off-by: Tinghan Shen Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220330094532.21721-2-tinghan.shen@mediatek.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/mtk-sd.yaml | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index 297ada03e3de..2a2e9fa8c188 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -40,7 +40,10 @@ properties: - const: mediatek,mt8183-mmc reg: - maxItems: 1 + minItems: 1 + items: + - description: base register (required). + - description: top base register (required for MT8183). clocks: description: @@ -168,6 +171,16 @@ required: - vmmc-supply - vqmmc-supply +if: + properties: + compatible: + contains: + const: mediatek,mt8183-mmc +then: + properties: + reg: + minItems: 2 + unevaluatedProperties: false examples: -- cgit From 6c1757be927ab1800754b14df01ad56da795339a Mon Sep 17 00:00:00 2001 From: Adam Ford Date: Sun, 10 Apr 2022 14:35:41 -0500 Subject: dt-bindings: mmc: imx-esdhc: Update compatible fallbacks The SDHC controller in the imx8mn and imx8mp have the same controller as the imx8mm which is slightly different than that of the imx7d. Using the fallback of the imx8mm enables the controllers to support HS400-ES which is not available on the imx7d. After discussion with NXP, it turns out that the imx8qm should fall back to the imx8qxp, because those have some additional flags not present in the imx8mm. Mark the current state of the fallbacks as deprecated, and add the proper fallbacks so in the future, the deprecated combination can be removed and prevent any future devices from using the wrong fallback. Suggested-by: haibo.chen@nxp.com Signed-off-by: Adam Ford Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220410193544.1745684-1-aford173@gmail.com Signed-off-by: Ulf Hansson --- .../devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 30 +++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index 7dbbcae9485c..58447095f000 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -34,22 +34,46 @@ properties: - fsl,imx6ull-usdhc - fsl,imx7d-usdhc - fsl,imx7ulp-usdhc + - fsl,imx8mm-usdhc - fsl,imxrt1050-usdhc - nxp,s32g2-usdhc + - items: + - enum: + - fsl,imx8mq-usdhc + - const: fsl,imx7d-usdhc + - items: + - enum: + - fsl,imx8mn-usdhc + - fsl,imx8mp-usdhc + - fsl,imx93-usdhc + - fsl,imx8ulp-usdhc + - const: fsl,imx8mm-usdhc + - items: + - enum: + - fsl,imx8qm-usdhc + - const: fsl,imx8qxp-usdhc - items: - enum: - fsl,imx8mm-usdhc - fsl,imx8mn-usdhc - fsl,imx8mp-usdhc - - fsl,imx8mq-usdhc - fsl,imx8qm-usdhc - fsl,imx8qxp-usdhc - const: fsl,imx7d-usdhc + deprecated: true - items: - enum: - - fsl,imx93-usdhc - - fsl,imx8ulp-usdhc + - fsl,imx8mn-usdhc + - fsl,imx8mp-usdhc - const: fsl,imx8mm-usdhc + - const: fsl,imx7d-usdhc + deprecated: true + - items: + - enum: + - fsl,imx8qm-usdhc + - const: fsl,imx8qxp-usdhc + - const: fsl,imx7d-usdhc + deprecated: true reg: maxItems: 1 -- cgit From de6e855b28f4c54eb04582cd468c6fa17577c8cc Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Sun, 17 Apr 2022 16:42:23 +0200 Subject: dt-bindings: mmc: Add small binding note on level shifters The VQMMC is often provided by a level shifter, so drop a small note in the bindings that this can be the case and how that is done. It is helpful information since this is pretty common. Cc: devicetree@vger.kernel.org Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220417144223.649201-1-linus.walleij@linaro.org Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/mmc-controller.yaml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml index 513f3c8758aa..ff5ce89e5111 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml @@ -298,7 +298,10 @@ properties: vqmmc-supply: description: - Supply for the bus IO line power + Supply for the bus IO line power, such as a level shifter. + If the level shifter is controlled by a GPIO line, this shall + be modeled as a "regulator-fixed" with a GPIO line for + switching the level shifter on/off. mmc-pwrseq: $ref: /schemas/types.yaml#/definitions/phandle -- cgit From a778dbd9a8ef30c07eaa7f46292d88f0a3b51e23 Mon Sep 17 00:00:00 2001 From: Chris Packham Date: Tue, 19 Apr 2022 14:46:10 +1200 Subject: dt-bindings: mmc: convert orion-sdio to JSON schema Convert the orion-sdio binding to JSON schema. Signed-off-by: Chris Packham Reviewed-by: Krzysztof Kozlowski Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20220419024611.1327525-4-chris.packham@alliedtelesis.co.nz Signed-off-by: Ulf Hansson --- .../bindings/mmc/marvell,orion-sdio.yaml | 44 ++++++++++++++++++++++ .../devicetree/bindings/mmc/orion-sdio.txt | 16 -------- 2 files changed, 44 insertions(+), 16 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/marvell,orion-sdio.yaml delete mode 100644 Documentation/devicetree/bindings/mmc/orion-sdio.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/marvell,orion-sdio.yaml b/Documentation/devicetree/bindings/mmc/marvell,orion-sdio.yaml new file mode 100644 index 000000000000..8a97ded15aed --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/marvell,orion-sdio.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/marvell,orion-sdio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell orion-sdio controller + +maintainers: + - Nicolas Pitre + - Ulf Hansson + +allOf: + - $ref: mmc-controller.yaml# + +properties: + compatible: + const: marvell,orion-sdio + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + mmc@d00d4000 { + compatible = "marvell,orion-sdio"; + reg = <0xd00d4000 0x200>; + interrupts = <54>; + clocks = <&gateclk 17>; + }; diff --git a/Documentation/devicetree/bindings/mmc/orion-sdio.txt b/Documentation/devicetree/bindings/mmc/orion-sdio.txt deleted file mode 100644 index 10f0818a34c5..000000000000 --- a/Documentation/devicetree/bindings/mmc/orion-sdio.txt +++ /dev/null @@ -1,16 +0,0 @@ -* Marvell orion-sdio controller - -This file documents differences between the core properties in mmc.txt -and the properties used by the orion-sdio driver. - -- compatible: Should be "marvell,orion-sdio" -- clocks: reference to the clock of the SDIO interface - -Example: - - mvsdio@d00d4000 { - compatible = "marvell,orion-sdio"; - reg = <0xd00d4000 0x200>; - interrupts = <54>; - clocks = <&gateclk 17>; - }; -- cgit From a18f3e46537434537bc3c11d33ef529c52370815 Mon Sep 17 00:00:00 2001 From: Chris Packham Date: Tue, 19 Apr 2022 14:46:11 +1200 Subject: dt-bindings: mmc: convert sdhci-dove to JSON schema Convert the sdhci-dove binding to JSON schema. The optional clocks property was not in the original binding document but has been in the dove.dtsi since commit 5b03df9ace68 ("ARM: dove: switch to DT clock providers"). Signed-off-by: Chris Packham Reviewed-by: Krzysztof Kozlowski Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20220419024611.1327525-5-chris.packham@alliedtelesis.co.nz Signed-off-by: Ulf Hansson --- .../bindings/mmc/marvell,dove-sdhci.yaml | 44 ++++++++++++++++++++++ .../devicetree/bindings/mmc/sdhci-dove.txt | 14 ------- 2 files changed, 44 insertions(+), 14 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/marvell,dove-sdhci.yaml delete mode 100644 Documentation/devicetree/bindings/mmc/sdhci-dove.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/marvell,dove-sdhci.yaml b/Documentation/devicetree/bindings/mmc/marvell,dove-sdhci.yaml new file mode 100644 index 000000000000..7c9c652ad59c --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/marvell,dove-sdhci.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/marvell,dove-sdhci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell sdhci-dove controller + +maintainers: + - Adrian Hunter + - Ulf Hansson + +allOf: + - $ref: mmc-controller.yaml# + +properties: + compatible: + const: marvell,dove-sdhci + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + sdio0: mmc@92000 { + compatible = "marvell,dove-sdhci"; + reg = <0x92000 0x100>; + interrupts = <35>; + clocks = <&gate_clk 9>; + }; diff --git a/Documentation/devicetree/bindings/mmc/sdhci-dove.txt b/Documentation/devicetree/bindings/mmc/sdhci-dove.txt deleted file mode 100644 index ae9aab9abcd7..000000000000 --- a/Documentation/devicetree/bindings/mmc/sdhci-dove.txt +++ /dev/null @@ -1,14 +0,0 @@ -* Marvell sdhci-dove controller - -This file documents differences between the core properties in mmc.txt -and the properties used by the sdhci-pxav2 and sdhci-pxav3 drivers. - -- compatible: Should be "marvell,dove-sdhci". - -Example: - -sdio0: sdio@92000 { - compatible = "marvell,dove-sdhci"; - reg = <0x92000 0x100>; - interrupts = <35>; -}; -- cgit From cfb646613649c013591a9d5a4dc8f5db3e7ac25b Mon Sep 17 00:00:00 2001 From: Abel Vesa Date: Tue, 19 Apr 2022 14:35:12 +0300 Subject: dt-bindings: mmc: imx-esdhc: Add i.MX8DXL compatible string Add i.MX8DXL compatible string. It also needs "fsl,imx8qm-fec" compatible. Signed-off-by: Abel Vesa Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220419113516.1827863-10-abel.vesa@nxp.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index 58447095f000..29339d0196ec 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -54,6 +54,7 @@ properties: - const: fsl,imx8qxp-usdhc - items: - enum: + - fsl,imx8dxl-usdhc - fsl,imx8mm-usdhc - fsl,imx8mn-usdhc - fsl,imx8mp-usdhc -- cgit From 7a0587496a6233b9ffa8441573d38f8844751066 Mon Sep 17 00:00:00 2001 From: Aswath Govindraju Date: Mon, 25 Apr 2022 12:01:19 +0530 Subject: dt-bindings: mmc: sdhci-am654: Add flag to force setting of TESTCD bit The ARASAN MMC controller on Keystone 3 class of devices needs the SDCD line to be connected for proper functioning. Similar to the issue pointed out in sdhci-of-arasan.c driver, commit 3794c542641f ("mmc: sdhci-of-arasan: Set controller to test mode when no CD bit"). In cases where SDCD line is not connected, adding "ti,fails-without-test-cd" in the DT node helps to indicate the controller, that the SDCD line has been pulled down, using the TESTCD bit. Signed-off-by: Aswath Govindraju Link: https://lore.kernel.org/r/20220425063120.10135-2-a-govindraju@ti.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/sdhci-am654.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml index 0566493c4def..0ab07759b472 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml @@ -186,6 +186,13 @@ properties: description: Clock Delay Buffer Select $ref: "/schemas/types.yaml#/definitions/uint32" + ti,fails-without-test-cd: + $ref: /schemas/types.yaml#/definitions/flag + description: + When present, indicates that the CD line is not connected + and the controller is required to be forced into Test mode + to set the TESTCD bit. + required: - compatible - reg -- cgit From 2368a93789513d5725885b4b7df6a14e72dc3e35 Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Sun, 24 Apr 2022 11:26:19 -0500 Subject: dt-bindings: display: Separate clock item lists by compatible So far, the binding and driver have relied on the fact that the H6 clocks are both a prefix and a subset of the R40 clocks. This allows them to share the clocks/clock-names items and the clock-output-names order between the hardware variants. However, the D1 hardware has TCON TV0 and DSI, but no TCON TV1. This cannot be supported by the existing scheme because it puts a gap in the middle of the item lists. To prepare for adding D1 support, use separate lists for variants with different combinations of clocks. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Samuel Holland Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20220424162633.12369-2-samuel@sholland.org --- .../display/allwinner,sun8i-r40-tcon-top.yaml | 105 ++++++++++++--------- 1 file changed, 61 insertions(+), 44 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml index 61ef7b337218..449fa99aa51b 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml @@ -48,31 +48,15 @@ properties: clocks: minItems: 2 - items: - - description: The TCON TOP interface clock - - description: The TCON TOP TV0 clock - - description: The TCON TOP TVE0 clock - - description: The TCON TOP TV1 clock - - description: The TCON TOP TVE1 clock - - description: The TCON TOP MIPI DSI clock + maxItems: 6 clock-names: minItems: 2 - items: - - const: bus - - const: tcon-tv0 - - const: tve0 - - const: tcon-tv1 - - const: tve1 - - const: dsi + maxItems: 6 clock-output-names: minItems: 1 maxItems: 3 - description: > - The first item is the name of the clock created for the TV0 - channel, the second item is the name of the TCON TV1 channel - clock and the third one is the name of the DSI channel clock. resets: maxItems: 1 @@ -129,32 +113,65 @@ required: additionalProperties: false -if: - properties: - compatible: - contains: - const: allwinner,sun50i-h6-tcon-top - -then: - properties: - clocks: - maxItems: 2 - - clock-output-names: - maxItems: 1 - -else: - properties: - clocks: - minItems: 6 - - clock-output-names: - minItems: 3 - - ports: - required: - - port@2 - - port@3 +allOf: + - if: + properties: + compatible: + contains: + const: allwinner,sun8i-r40-tcon-top + + then: + properties: + clocks: + items: + - description: The TCON TOP interface clock + - description: The TCON TOP TV0 clock + - description: The TCON TOP TVE0 clock + - description: The TCON TOP TV1 clock + - description: The TCON TOP TVE1 clock + - description: The TCON TOP MIPI DSI clock + + clock-names: + items: + - const: bus + - const: tcon-tv0 + - const: tve0 + - const: tcon-tv1 + - const: tve1 + - const: dsi + + clock-output-names: + items: + - description: TCON TV0 output clock name + - description: TCON TV1 output clock name + - description: DSI output clock name + + ports: + required: + - port@2 + - port@3 + + - if: + properties: + compatible: + contains: + const: allwinner,sun50i-h6-tcon-top + + then: + properties: + clocks: + items: + - description: The TCON TOP interface clock + - description: The TCON TOP TV0 clock + + clock-names: + items: + - const: bus + - const: tcon-tv0 + + clock-output-names: + items: + - description: TCON TV0 output clock name examples: - | -- cgit From ae5a5d26c15c65cb9bea2f90c9a6405d300e7c76 Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Sun, 24 Apr 2022 11:26:20 -0500 Subject: dt-bindings: display: Add D1 display engine compatibles Allwinner D1 contains a display engine 2.0. It features two mixers, a TCON TOP (with DSI and HDMI), one TCON LCD, and one TCON TV. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Samuel Holland Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20220424162633.12369-3-samuel@sholland.org --- .../allwinner,sun4i-a10-display-engine.yaml | 1 + .../bindings/display/allwinner,sun4i-a10-tcon.yaml | 2 ++ .../display/allwinner,sun8i-a83t-de2-mixer.yaml | 2 ++ .../display/allwinner,sun8i-r40-tcon-top.yaml | 28 ++++++++++++++++++++++ 4 files changed, 33 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml index d4412aea7b73..c388ae5da1e4 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml @@ -62,6 +62,7 @@ properties: - allwinner,sun8i-r40-display-engine - allwinner,sun8i-v3s-display-engine - allwinner,sun9i-a80-display-engine + - allwinner,sun20i-d1-display-engine - allwinner,sun50i-a64-display-engine - allwinner,sun50i-h6-display-engine diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml index 3a7d5d731712..4a92a4c7dcd7 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml @@ -33,6 +33,8 @@ properties: - const: allwinner,sun8i-v3s-tcon - const: allwinner,sun9i-a80-tcon-lcd - const: allwinner,sun9i-a80-tcon-tv + - const: allwinner,sun20i-d1-tcon-lcd + - const: allwinner,sun20i-d1-tcon-tv - items: - enum: diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml index 4f91eec26de9..cb243bc58ef7 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml @@ -19,6 +19,8 @@ properties: - allwinner,sun8i-r40-de2-mixer-0 - allwinner,sun8i-r40-de2-mixer-1 - allwinner,sun8i-v3s-de2-mixer + - allwinner,sun20i-d1-de2-mixer-0 + - allwinner,sun20i-d1-de2-mixer-1 - allwinner,sun50i-a64-de2-mixer-0 - allwinner,sun50i-a64-de2-mixer-1 - allwinner,sun50i-h6-de3-mixer-0 diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml index 449fa99aa51b..845e226d7aff 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml @@ -41,6 +41,7 @@ properties: compatible: enum: - allwinner,sun8i-r40-tcon-top + - allwinner,sun20i-d1-tcon-top - allwinner,sun50i-h6-tcon-top reg: @@ -151,6 +152,33 @@ allOf: - port@2 - port@3 + - if: + properties: + compatible: + contains: + const: allwinner,sun20i-d1-tcon-top + + then: + properties: + clocks: + items: + - description: The TCON TOP interface clock + - description: The TCON TOP TV0 clock + - description: The TCON TOP TVE0 clock + - description: The TCON TOP MIPI DSI clock + + clock-names: + items: + - const: bus + - const: tcon-tv0 + - const: tve0 + - const: dsi + + clock-output-names: + items: + - description: TCON TV0 output clock name + - description: DSI output clock name + - if: properties: compatible: -- cgit From 103dcf2ea2df2669d3e4496974e6bb0911ff515f Mon Sep 17 00:00:00 2001 From: Ilpo Järvinen Date: Tue, 26 Apr 2022 15:24:41 +0300 Subject: dt_bindings: rs485: Add receiver enable polarity MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add polarity property for receiver enable. Some UARTs have separate enable pins for tx (RTS or DE) and rx (RE). As most RS485 transceivers have !RE pin, the default is active low in contrast to rs485-rts-active-low that defaults to active high. Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring Signed-off-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20220426122448.38997-4-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/rs485.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/rs485.yaml b/Documentation/devicetree/bindings/serial/rs485.yaml index 0c9fa694f85c..f2c9c9fe6aa7 100644 --- a/Documentation/devicetree/bindings/serial/rs485.yaml +++ b/Documentation/devicetree/bindings/serial/rs485.yaml @@ -33,6 +33,11 @@ properties: description: drive RTS low when sending (default is high). $ref: /schemas/types.yaml#/definitions/flag + rs485-rx-active-high: + description: Polarity of receiver enable signal (when separate from RTS). + True indicates active high (default is low). + $ref: /schemas/types.yaml#/definitions/flag + linux,rs485-enabled-at-boot-time: description: enables the rs485 feature at boot time. It can be disabled later with proper ioctl. -- cgit From 1e70d57e7285996bcf0a226eac8c5ba43a89f85d Mon Sep 17 00:00:00 2001 From: Ilpo Järvinen Date: Tue, 26 Apr 2022 15:24:42 +0300 Subject: ACPI / property: Document RS485 _DSD properties MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document RS485 related properties returned from ACPI _DSD as device properties. Signed-off-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20220426122448.38997-5-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman --- Documentation/firmware-guide/acpi/enumeration.rst | 25 +++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index 47fb4d6d4557..f584a6a0c5e3 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -390,6 +390,31 @@ descriptors once the device is released. See Documentation/firmware-guide/acpi/gpio-properties.rst for more information about the _DSD binding related to GPIOs. +RS-485 support +============== + +ACPI _DSD (Device Specific Data) can be used to describe RS-485 capability +of UART. + +For example:: + + Device (DEV) + { + ... + + // ACPI 5.1 _DSD used for RS-485 capabilities + Name (_DSD, Package () + { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () + { + Package () {"rs485-rts-active-low", Zero}, + Package () {"rs485-rx-active-high", Zero}, + Package () {"rs485-rx-during-tx", Zero}, + } + }) + ... + MFD devices =========== -- cgit From 3a2c9a553f4785555408b32d59ebfe125d8b9f09 Mon Sep 17 00:00:00 2001 From: Ryan Lee Date: Mon, 25 Apr 2022 10:37:15 -0700 Subject: ASoC: dt-bindings: max98396: add amplifier driver This patch adds dt-bindings information for Analog Devices MAX98396 and MAX98397 Smart Amplifier. Signed-off-by: Ryan Lee Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220425173715.1827706-1-ryan.lee.analog@gmail.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/adi,max98396.yaml | 79 ++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/adi,max98396.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/adi,max98396.yaml b/Documentation/devicetree/bindings/sound/adi,max98396.yaml new file mode 100644 index 000000000000..ec4c10c2598a --- /dev/null +++ b/Documentation/devicetree/bindings/sound/adi,max98396.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/adi,max98396.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices MAX98396 Speaker Amplifier Device Tree Bindings + +maintainers: + - Ryan Lee + +description: + The MAX98396 is a mono Class-DG speaker amplifier with I/V sense. + The device provides a PCM interface for audio data and a standard + I2C interface for control data communication. + The MAX98397 is a variant of MAX98396 with wide input supply range. + +properties: + compatible: + enum: + - adi,max98396 + - adi,max98397 + reg: + maxItems: 1 + description: I2C address of the device. + + adi,vmon-slot-no: + description: slot number of the voltage sense monitor + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 15 + default: 0 + + adi,imon-slot-no: + description: slot number of the current sense monitor + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 15 + default: 0 + + adi,spkfb-slot-no: + description: slot number of speaker DSP monitor + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 15 + default: 0 + + adi,interleave-mode: + description: + For cases where a single combined channel for the I/V sense data + is not sufficient, the device can also be configured to share + a single data output channel on alternating frames. + In this configuration, the current and voltage data will be frame + interleaved on a single output channel. + type: boolean + + reset-gpios: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + max98396: amplifier@39 { + compatible = "adi,max98396"; + reg = <0x39>; + adi,vmon-slot-no = <0>; + adi,imon-slot-no = <1>; + reset-gpios = <&gpio 4 GPIO_ACTIVE_LOW>; + }; + }; -- cgit From d496d68d6ba6debcc135794edb5fdc5a5b4531f1 Mon Sep 17 00:00:00 2001 From: Markuss Broks Date: Sat, 23 Apr 2022 11:53:15 +0300 Subject: dt-bindings: regulator: Add bindings for Silicon Mitus SM5703 regulators This patch adds device-tree bindings for regulators on Silicon Mitus SM5703 MFD. Signed-off-by: Markuss Broks Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220423085319.483524-3-markuss.broks@gmail.com Signed-off-by: Mark Brown --- .../regulator/siliconmitus,sm5703-regulator.yaml | 49 ++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/siliconmitus,sm5703-regulator.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/siliconmitus,sm5703-regulator.yaml b/Documentation/devicetree/bindings/regulator/siliconmitus,sm5703-regulator.yaml new file mode 100644 index 000000000000..75ff16b58000 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/siliconmitus,sm5703-regulator.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/siliconmitus,sm5703-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silicon Mitus SM5703 multi function device regulators + +maintainers: + - Markuss Broks + +description: | + SM5703 regulators node should be a sub node of the SM5703 MFD node. See SM5703 MFD + bindings at Documentation/devicetree/bindings/mfd/siliconmitus,sm5703.yaml + Regulator nodes should be named as USBLDO_, BUCK, VBUS, LDO_. + The definition for each of these nodes is defined using the standard + binding for regulators at Documentation/devicetree/bindings/regulator/regulator.txt. + +properties: + buck: + type: object + $ref: regulators.yaml# + unevaluatedProperties: false + description: + Properties for the BUCK regulator. + + vbus: + type: object + $ref: regulators.yaml# + unevaluatedProperties: false + description: + Properties for the VBUS regulator. + +patternProperties: + "^ldo[1-3]$": + type: object + $ref: regulators.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + "^usbldo[1-2]$": + type: object + $ref: regulators.yaml# + unevaluatedProperties: false + description: + Properties for a single USBLDO regulator. + +additionalProperties: false -- cgit From 5bdcae1fe1c567c08e8bb7ef20fc70d0b70d5fc4 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 4 Apr 2022 08:40:16 +0200 Subject: spi: dt-bindings: qcom,spi-geni-qcom: convert to dtschema Convert the GENI based Qualcomm Universal Peripheral (QUP) Serial Peripheral Interface (SPI) bindings to DT Schema. The original bindings in TXT were not complete, so add during conversion properties already used in DTS and/or in the driver: dmas, interconnects, operating points and power-domains. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220404064017.68634-1-krzysztof.kozlowski@linaro.org --- .../devicetree/bindings/spi/qcom,spi-geni-qcom.txt | 39 ------- .../bindings/spi/qcom,spi-geni-qcom.yaml | 116 +++++++++++++++++++++ 2 files changed, 116 insertions(+), 39 deletions(-) delete mode 100644 Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.txt create mode 100644 Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.txt b/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.txt deleted file mode 100644 index c8c1e913f4e7..000000000000 --- a/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.txt +++ /dev/null @@ -1,39 +0,0 @@ -GENI based Qualcomm Universal Peripheral (QUP) Serial Peripheral Interface (SPI) - -The QUP v3 core is a GENI based AHB slave that provides a common data path -(an output FIFO and an input FIFO) for serial peripheral interface (SPI) -mini-core. - -SPI in master mode supports up to 50MHz, up to four chip selects, programmable -data path from 4 bits to 32 bits and numerous protocol variants. - -Required properties: -- compatible: Must contain "qcom,geni-spi". -- reg: Must contain SPI register location and length. -- interrupts: Must contain SPI controller interrupts. -- clock-names: Must contain "se". -- clocks: Serial engine core clock needed by the device. -- #address-cells: Must be <1> to define a chip select address on - the SPI bus. -- #size-cells: Must be <0>. - -SPI Controller nodes must be child of GENI based Qualcomm Universal -Peripharal. Please refer GENI based QUP wrapper controller node bindings -described in Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml. - -SPI slave nodes must be children of the SPI master node and conform to SPI bus -binding as described in Documentation/devicetree/bindings/spi/spi-bus.txt. - -Example: - spi0: spi@a84000 { - compatible = "qcom,geni-spi"; - reg = <0xa84000 0x4000>; - interrupts = ; - clock-names = "se"; - clocks = <&clock_gcc GCC_QUPV3_WRAP0_S0_CLK>; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&qup_1_spi_2_active>; - pinctrl-1 = <&qup_1_spi_2_sleep>; - #address-cells = <1>; - #size-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml new file mode 100644 index 000000000000..e2c7b934c50d --- /dev/null +++ b/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml @@ -0,0 +1,116 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/qcom,spi-geni-qcom.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GENI based Qualcomm Universal Peripheral (QUP) Serial Peripheral Interface (SPI) + +maintainers: + - Andy Gross + - Bjorn Andersson + - Krzysztof Kozlowski + +description: + The QUP v3 core is a GENI based AHB slave that provides a common data path + (an output FIFO and an input FIFO) for serial peripheral interface (SPI) + mini-core. + + SPI in master mode supports up to 50MHz, up to four chip selects, + programmable data path from 4 bits to 32 bits and numerous protocol variants. + + SPI Controller nodes must be child of GENI based Qualcomm Universal + Peripharal. Please refer GENI based QUP wrapper controller node bindings + described in Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml. + +allOf: + - $ref: /schemas/spi/spi-controller.yaml# + +properties: + compatible: + const: qcom,geni-spi + + clocks: + maxItems: 1 + + clock-names: + const: se + + dmas: + maxItems: 2 + + dma-names: + items: + - const: tx + - const: rx + + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: qup-core + - const: qup-config + + interrupts: + maxItems: 1 + + operating-points-v2: true + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - interrupts + - reg + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + #include + + spi@880000 { + compatible = "qcom,geni-spi"; + reg = <0x00880000 0x4000>; + clock-names = "se"; + clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>; + pinctrl-names = "default"; + pinctrl-0 = <&qup_spi0_default>; + interrupts = ; + #address-cells = <1>; + #size-cells = <0>; + power-domains = <&rpmhpd SC7180_CX>; + operating-points-v2 = <&qup_opp_table>; + interconnects = <&qup_virt MASTER_QUP_CORE_0 0 &qup_virt SLAVE_QUP_CORE_0 0>, + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>; + interconnect-names = "qup-core", "qup-config"; + }; + + - | + #include + + spi@884000 { + compatible = "qcom,geni-spi"; + reg = <0x00884000 0x4000>; + clock-names = "se"; + clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>; + dmas = <&gpi_dma0 0 1 QCOM_GPI_SPI>, + <&gpi_dma0 1 1 QCOM_GPI_SPI>; + dma-names = "tx", "rx"; + pinctrl-names = "default"; + pinctrl-0 = <&qup_spi1_default>; + interrupts = ; + spi-max-frequency = <50000000>; + #address-cells = <1>; + #size-cells = <0>; + }; -- cgit From 31976eb180a199bc8d3e19b3e493158b1337c579 Mon Sep 17 00:00:00 2001 From: Allen-KH Cheng Date: Tue, 19 Apr 2022 20:33:30 +0800 Subject: dt-bindings: remoteproc: mediatek: Add firmware-name property The SCP needs firmware which differs between other platforms and SoCs. Add a new property "firmware-name" to allow the DT to specify the platform/board specific path to this firmware file. Signed-off-by: Allen-KH Cheng Reviewed-by: AngeloGioacchino Del Regno Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220419123331.14377-2-allen-kh.cheng@mediatek.com Signed-off-by: Mathieu Poirier --- Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml index 823a236242de..abc11ac92818 100644 --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml @@ -45,6 +45,13 @@ properties: interrupts: maxItems: 1 + firmware-name: + $ref: /schemas/types.yaml#/definitions/string + description: + If present, name (or relative path) of the file within the + firmware search path containing the firmware image used when + initializing SCP. + required: - compatible - reg -- cgit From e53da8c490046e214528bad245521ffe9e7713c0 Mon Sep 17 00:00:00 2001 From: Gene Chen Date: Thu, 24 Dec 2020 11:19:49 +0800 Subject: dt-bindings: mfd: mediatek: Add bindings for MT6360 PMIC Add bindings for MT6360 PMIC Signed-off-by: Gene Chen Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/1608779989-9641-1-git-send-email-gene.chen.richtek@gmail.com --- .../devicetree/bindings/leds/leds-mt6360.yaml | 2 +- .../devicetree/bindings/mfd/mediatek,mt6360.yaml | 67 ++++++++++++++++++++++ .../bindings/usb/mediatek,mt6360-tcpc.yaml | 5 ++ 3 files changed, 73 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/mfd/mediatek,mt6360.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/leds-mt6360.yaml b/Documentation/devicetree/bindings/leds/leds-mt6360.yaml index b2fe6eb89389..a4a04ea39bbb 100644 --- a/Documentation/devicetree/bindings/leds/leds-mt6360.yaml +++ b/Documentation/devicetree/bindings/leds/leds-mt6360.yaml @@ -11,7 +11,7 @@ maintainers: description: | This module is part of the MT6360 MFD device. - see Documentation/devicetree/bindings/mfd/mt6360.yaml + see Documentation/devicetree/bindings/mfd/mediatek,mt6360.yaml Add MT6360 LED driver include 2-channel Flash LED with torch/strobe mode, and 4-channel RGB LED support Register/Flash/Breath Mode diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6360.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6360.yaml new file mode 100644 index 000000000000..4d8769f3748c --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6360.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/mediatek,mt6360.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MT6360 PMIC from MediaTek Integrated + +maintainers: + - Gene Chen + +description: | + MT6360 is a PMIC device with the following sub modules. + It is interfaced to host controller using I2C interface. + + This document describes the binding for PMIC device and its sub module. + +properties: + compatible: + const: mediatek,mt6360 + + reg: + maxItems: 1 + + wakeup-source: true + + interrupts: + maxItems: 1 + + interrupt-names: + const: IRQB + + interrupt-controller: true + + "#interrupt-cells": + const: 1 + description: + The first cell is the IRQ number. + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - "#interrupt-cells" + +additionalProperties: + type: object + +examples: + - | + #include + #include + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@34 { + compatible = "mediatek,mt6360"; + reg = <0x34>; + wakeup-source; + interrupts-extended = <&gpio26 0 IRQ_TYPE_LEVEL_LOW>; + interrupt-names = "IRQB"; + interrupt-controller; + #interrupt-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml index 1e8e1c22180e..8db1f8b597c3 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml @@ -50,6 +50,11 @@ examples: mt6360@34 { compatible = "mediatek,mt6360"; reg = <0x34>; + interrupts-extended = <&gpio26 0 IRQ_TYPE_LEVEL_LOW>; + interrupt-names = "IRQB"; + interrupt-controller; + #interrupt-cells = <1>; + tcpc { compatible = "mediatek,mt6360-tcpc"; interrupts-extended = <&gpio26 3 IRQ_TYPE_LEVEL_LOW>; -- cgit From 942680d6192058ed56f50657250e34d8a2cc90e7 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 22 Apr 2022 14:19:57 -0500 Subject: dt-bindings: Drop empty and unreferenced binding .txt files Drop a couple of old, empty .txt binding files which are no longer referenced. Signed-off-by: Rob Herring Acked-by: Alexandre Belloni Acked-by: Miquel Raynal Link: https://lore.kernel.org/r/20220422191958.2589318-1-robh@kernel.org --- Documentation/devicetree/bindings/eeprom/at24.txt | 1 - Documentation/devicetree/bindings/mtd/common.txt | 1 - Documentation/devicetree/bindings/rtc/rtc.txt | 1 - 3 files changed, 3 deletions(-) delete mode 100644 Documentation/devicetree/bindings/eeprom/at24.txt delete mode 100644 Documentation/devicetree/bindings/mtd/common.txt delete mode 100644 Documentation/devicetree/bindings/rtc/rtc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt b/Documentation/devicetree/bindings/eeprom/at24.txt deleted file mode 100644 index c94acbb8cb0c..000000000000 --- a/Documentation/devicetree/bindings/eeprom/at24.txt +++ /dev/null @@ -1 +0,0 @@ -This file has been moved to at24.yaml. diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt deleted file mode 100644 index ae16f9ea8606..000000000000 --- a/Documentation/devicetree/bindings/mtd/common.txt +++ /dev/null @@ -1 +0,0 @@ -This file has been moved to mtd.yaml. diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt b/Documentation/devicetree/bindings/rtc/rtc.txt deleted file mode 100644 index b8d36fce5e2d..000000000000 --- a/Documentation/devicetree/bindings/rtc/rtc.txt +++ /dev/null @@ -1 +0,0 @@ -This file has been moved to rtc.yaml. -- cgit From 3474b838f4204c21d108183d9268611d961a428f Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 22 Apr 2022 14:21:21 -0500 Subject: dt-bindings: Drop undocumented i.MX iomuxc-gpr bindings in examples The i.MX iomuxc-gpr bindings are undocumented and a mess. Drop their use from the examples. The problem with the binding beyond the just random variations is that the iomuxc-gpr is not a separate block, but registers within the iomuxc block containing random leftover controls. As a separate DT node, it creates nodes with overlapping memory addresses. Signed-off-by: Rob Herring Acked-by: Peter Rosin Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220422192121.2592030-1-robh@kernel.org --- Documentation/devicetree/bindings/mfd/syscon.yaml | 8 -------- Documentation/devicetree/bindings/mux/reg-mux.yaml | 1 - 2 files changed, 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index 13baa452cc9d..fb784045013f 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -100,12 +100,4 @@ examples: compatible = "allwinner,sun8i-h3-system-controller", "syscon"; reg = <0x01c00000 0x1000>; }; - - - | - gpr: iomuxc-gpr@20e0000 { - compatible = "fsl,imx6q-iomuxc-gpr", "syscon"; - reg = <0x020e0000 0x38>; - hwlocks = <&hwlock1 1>; - }; - ... diff --git a/Documentation/devicetree/bindings/mux/reg-mux.yaml b/Documentation/devicetree/bindings/mux/reg-mux.yaml index 60d5746eb39d..df4db96b5391 100644 --- a/Documentation/devicetree/bindings/mux/reg-mux.yaml +++ b/Documentation/devicetree/bindings/mux/reg-mux.yaml @@ -96,7 +96,6 @@ examples: #include syscon@1000 { - compatible = "fsl,imx7d-iomuxc-gpr", "fsl,imx6q-iomuxc-gpr", "syscon", "simple-mfd"; reg = <0x1000 0x100>; mux2: mux-controller { -- cgit From cd9fdd06b0e8aafc715f239153ff41cbf12c991a Mon Sep 17 00:00:00 2001 From: Yassine Oudjana Date: Sun, 24 Apr 2022 12:46:45 +0400 Subject: dt-bindings: arm: mediatek: topckgen: Convert to DT schema Convert topckgen bindings to DT schema format. MT2701, MT7623 and MT7629 device trees currently have the syscon compatible without it being mentioned in the old DT bindings file which introduces dtbs_check errors when converting to DT schema as-is, so mediatek,mt2701-topckgen and mediatek,mt7629-topckgen are placed in the last items list with the syscon compatible, and syscon is added to the mediatek,mt7623-topckgen list. Signed-off-by: Yassine Oudjana Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220424084647.76577-2-y.oudjana@protonmail.com --- .../bindings/arm/mediatek/mediatek,topckgen.txt | 35 ------------- .../bindings/clock/mediatek,topckgen.yaml | 61 ++++++++++++++++++++++ 2 files changed, 61 insertions(+), 35 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt create mode 100644 Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt deleted file mode 100644 index b82422bb717f..000000000000 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt +++ /dev/null @@ -1,35 +0,0 @@ -Mediatek topckgen controller -============================ - -The Mediatek topckgen controller provides various clocks to the system. - -Required Properties: - -- compatible: Should be one of: - - "mediatek,mt2701-topckgen" - - "mediatek,mt2712-topckgen", "syscon" - - "mediatek,mt6765-topckgen", "syscon" - - "mediatek,mt6779-topckgen", "syscon" - - "mediatek,mt6797-topckgen" - - "mediatek,mt7622-topckgen" - - "mediatek,mt7623-topckgen", "mediatek,mt2701-topckgen" - - "mediatek,mt7629-topckgen" - - "mediatek,mt7986-topckgen", "syscon" - - "mediatek,mt8135-topckgen" - - "mediatek,mt8167-topckgen", "syscon" - - "mediatek,mt8173-topckgen" - - "mediatek,mt8183-topckgen", "syscon" - - "mediatek,mt8516-topckgen" -- #clock-cells: Must be 1 - -The topckgen controller uses the common clk binding from -Documentation/devicetree/bindings/clock/clock-bindings.txt -The available clocks are defined in dt-bindings/clock/mt*-clk.h. - -Example: - -topckgen: power-controller@10000000 { - compatible = "mediatek,mt8173-topckgen"; - reg = <0 0x10000000 0 0x1000>; - #clock-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml new file mode 100644 index 000000000000..5b8b37a2e594 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/clock/mediatek,topckgen.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek Top Clock Generator Controller + +maintainers: + - Michael Turquette + - Stephen Boyd + +description: + The Mediatek topckgen controller provides various clocks to the system. + The clock values can be found in . + +properties: + compatible: + oneOf: + - enum: + - mediatek,mt6797-topckgen + - mediatek,mt7622-topckgen + - mediatek,mt8135-topckgen + - mediatek,mt8173-topckgen + - mediatek,mt8516-topckgen + - items: + - const: mediatek,mt7623-topckgen + - const: mediatek,mt2701-topckgen + - const: syscon + - items: + - enum: + - mediatek,mt2701-topckgen + - mediatek,mt2712-topckgen + - mediatek,mt6765-topckgen + - mediatek,mt6779-topckgen + - mediatek,mt7629-topckgen + - mediatek,mt7986-topckgen + - mediatek,mt8167-topckgen + - mediatek,mt8183-topckgen + - const: syscon + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + topckgen: clock-controller@10000000 { + compatible = "mediatek,mt8173-topckgen"; + reg = <0x10000000 0x1000>; + #clock-cells = <1>; + }; -- cgit From 16a146735df3b67941ebf09a5fc871ac4584892d Mon Sep 17 00:00:00 2001 From: Yassine Oudjana Date: Sun, 24 Apr 2022 12:46:46 +0400 Subject: dt-bindings: arm: mediatek: apmixedsys: Convert to DT schema Convert apmixedsys bindings to DT schema format. MT2701, MT7623 and MT7629 device trees currently have the syscon compatible without it being mentioned in the old DT bindings file which introduces dtbs_check errors when converting to DT schema as-is, so mediatek,mt2701-apmixedsys and mediatek,mt7629-apmixedsys are placed in the last items list with the syscon compatible, and syscon is added to the mediatek,mt7623-apmixedsys list. Signed-off-by: Yassine Oudjana Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220424084647.76577-3-y.oudjana@protonmail.com --- .../bindings/arm/mediatek/mediatek,apmixedsys.txt | 35 ------------- .../bindings/clock/mediatek,apmixedsys.yaml | 61 ++++++++++++++++++++++ 2 files changed, 61 insertions(+), 35 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt create mode 100644 Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt deleted file mode 100644 index 3fa755866528..000000000000 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt +++ /dev/null @@ -1,35 +0,0 @@ -Mediatek apmixedsys controller -============================== - -The Mediatek apmixedsys controller provides the PLLs to the system. - -Required Properties: - -- compatible: Should be one of: - - "mediatek,mt2701-apmixedsys" - - "mediatek,mt2712-apmixedsys", "syscon" - - "mediatek,mt6765-apmixedsys", "syscon" - - "mediatek,mt6779-apmixedsys", "syscon" - - "mediatek,mt6797-apmixedsys" - - "mediatek,mt7622-apmixedsys" - - "mediatek,mt7623-apmixedsys", "mediatek,mt2701-apmixedsys" - - "mediatek,mt7629-apmixedsys" - - "mediatek,mt7986-apmixedsys" - - "mediatek,mt8135-apmixedsys" - - "mediatek,mt8167-apmixedsys", "syscon" - - "mediatek,mt8173-apmixedsys" - - "mediatek,mt8183-apmixedsys", "syscon" - - "mediatek,mt8516-apmixedsys" -- #clock-cells: Must be 1 - -The apmixedsys controller uses the common clk binding from -Documentation/devicetree/bindings/clock/clock-bindings.txt -The available clocks are defined in dt-bindings/clock/mt*-clk.h. - -Example: - -apmixedsys: clock-controller@10209000 { - compatible = "mediatek,mt8173-apmixedsys"; - reg = <0 0x10209000 0 0x1000>; - #clock-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml new file mode 100644 index 000000000000..770546195fb5 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/clock/mediatek,apmixedsys.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek AP Mixedsys Controller + +maintainers: + - Michael Turquette + - Stephen Boyd + +description: + The Mediatek apmixedsys controller provides PLLs to the system. + The clock values can be found in . + +properties: + compatible: + oneOf: + - enum: + - mediatek,mt6797-apmixedsys + - mediatek,mt7622-apmixedsys + - mediatek,mt7986-apmixedsys + - mediatek,mt8135-apmixedsys + - mediatek,mt8173-apmixedsys + - mediatek,mt8516-apmixedsys + - items: + - const: mediatek,mt7623-apmixedsys + - const: mediatek,mt2701-apmixedsys + - const: syscon + - items: + - enum: + - mediatek,mt2701-apmixedsys + - mediatek,mt2712-apmixedsys + - mediatek,mt6765-apmixedsys + - mediatek,mt6779-apmixedsys + - mediatek,mt7629-apmixedsys + - mediatek,mt8167-apmixedsys + - mediatek,mt8183-apmixedsys + - const: syscon + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + apmixedsys: clock-controller@10209000 { + compatible = "mediatek,mt8173-apmixedsys"; + reg = <0x10209000 0x1000>; + #clock-cells = <1>; + }; -- cgit From 4ae547cee61252b105115eabee27ec7466861179 Mon Sep 17 00:00:00 2001 From: Yassine Oudjana Date: Sun, 24 Apr 2022 12:46:47 +0400 Subject: dt-bindings: arm: mediatek: infracfg: Convert to DT schema Convert infracfg bindings to DT schema format. Not all drivers currently implement resets, so #reset-cells is made a required property only for those that do. Using power-controller in the example node name makes #power-domain-cells required causing a dt_binding_check error. To solve this, the node is renamed to syscon@10001000. Signed-off-by: Yassine Oudjana Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220424084647.76577-4-y.oudjana@protonmail.com --- .../bindings/arm/mediatek/mediatek,infracfg.txt | 42 ----------- .../bindings/arm/mediatek/mediatek,infracfg.yaml | 81 ++++++++++++++++++++++ 2 files changed, 81 insertions(+), 42 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt deleted file mode 100644 index f66bd720571d..000000000000 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt +++ /dev/null @@ -1,42 +0,0 @@ -Mediatek infracfg controller -============================ - -The Mediatek infracfg controller provides various clocks and reset -outputs to the system. - -Required Properties: - -- compatible: Should be one of: - - "mediatek,mt2701-infracfg", "syscon" - - "mediatek,mt2712-infracfg", "syscon" - - "mediatek,mt6765-infracfg", "syscon" - - "mediatek,mt6779-infracfg_ao", "syscon" - - "mediatek,mt6797-infracfg", "syscon" - - "mediatek,mt7622-infracfg", "syscon" - - "mediatek,mt7623-infracfg", "mediatek,mt2701-infracfg", "syscon" - - "mediatek,mt7629-infracfg", "syscon" - - "mediatek,mt7986-infracfg", "syscon" - - "mediatek,mt8135-infracfg", "syscon" - - "mediatek,mt8167-infracfg", "syscon" - - "mediatek,mt8173-infracfg", "syscon" - - "mediatek,mt8183-infracfg", "syscon" - - "mediatek,mt8516-infracfg", "syscon" -- #clock-cells: Must be 1 -- #reset-cells: Must be 1 - -The infracfg controller uses the common clk binding from -Documentation/devicetree/bindings/clock/clock-bindings.txt -The available clocks are defined in dt-bindings/clock/mt*-clk.h. -Also it uses the common reset controller binding from -Documentation/devicetree/bindings/reset/reset.txt. -The available reset outputs are defined in -dt-bindings/reset/mt*-resets.h - -Example: - -infracfg: power-controller@10001000 { - compatible = "mediatek,mt8173-infracfg", "syscon"; - reg = <0 0x10001000 0 0x1000>; - #clock-cells = <1>; - #reset-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml new file mode 100644 index 000000000000..8681b785ed6d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek Infrastructure System Configuration Controller + +maintainers: + - Matthias Brugger + +description: + The Mediatek infracfg controller provides various clocks and reset outputs + to the system. The clock values can be found in , + and reset values in and + . + +properties: + compatible: + oneOf: + - items: + - enum: + - mediatek,mt2701-infracfg + - mediatek,mt2712-infracfg + - mediatek,mt6765-infracfg + - mediatek,mt6779-infracfg_ao + - mediatek,mt6797-infracfg + - mediatek,mt7622-infracfg + - mediatek,mt7629-infracfg + - mediatek,mt7986-infracfg + - mediatek,mt8135-infracfg + - mediatek,mt8167-infracfg + - mediatek,mt8173-infracfg + - mediatek,mt8183-infracfg + - mediatek,mt8516-infracfg + - const: syscon + - items: + - const: mediatek,mt7623-infracfg + - const: mediatek,mt2701-infracfg + - const: syscon + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +if: + properties: + compatible: + contains: + enum: + - mediatek,mt2701-infracfg + - mediatek,mt2712-infracfg + - mediatek,mt7622-infracfg + - mediatek,mt7986-infracfg + - mediatek,mt8135-infracfg + - mediatek,mt8173-infracfg + - mediatek,mt8183-infracfg +then: + required: + - '#reset-cells' + +additionalProperties: false + +examples: + - | + infracfg: clock-controller@10001000 { + compatible = "mediatek,mt8173-infracfg", "syscon"; + reg = <0x10001000 0x1000>; + #clock-cells = <1>; + #reset-cells = <1>; + }; -- cgit From 2f51efc6b71dc7e47acd26e4610107905feb074b Mon Sep 17 00:00:00 2001 From: Masami Hiramatsu Date: Wed, 6 Apr 2022 11:31:30 +0900 Subject: docs: bootconfig: Add how to embed the bootconfig into kernel Add a description how to embed the bootconfig file into kernel. Link: https://lkml.kernel.org/r/164921228987.1090670.16843569536974147213.stgit@devnote2 Cc: Padmanabha Srinivasaiah Cc: Jonathan Corbet Cc: Randy Dunlap Cc: Nick Desaulniers Cc: Sami Tolvanen Cc: Nathan Chancellor Cc: Masahiro Yamada Cc: Linux Kbuild mailing list Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (Google) --- Documentation/admin-guide/bootconfig.rst | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/bootconfig.rst b/Documentation/admin-guide/bootconfig.rst index a1860fc0ca88..d99994345d41 100644 --- a/Documentation/admin-guide/bootconfig.rst +++ b/Documentation/admin-guide/bootconfig.rst @@ -158,9 +158,15 @@ Each key-value pair is shown in each line with following style:: Boot Kernel With a Boot Config ============================== -Since the boot configuration file is loaded with initrd, it will be added -to the end of the initrd (initramfs) image file with padding, size, -checksum and 12-byte magic word as below. +There are two options to boot the kernel with bootconfig: attaching the +bootconfig to the initrd image or embedding it in the kernel itself. + +Attaching a Boot Config to Initrd +--------------------------------- + +Since the boot configuration file is loaded with initrd by default, +it will be added to the end of the initrd (initramfs) image file with +padding, size, checksum and 12-byte magic word as below. [initrd][bootconfig][padding][size(le32)][checksum(le32)][#BOOTCONFIG\n] @@ -196,6 +202,25 @@ To remove the config from the image, you can use -d option as below:: Then add "bootconfig" on the normal kernel command line to tell the kernel to look for the bootconfig at the end of the initrd file. +Embedding a Boot Config into Kernel +----------------------------------- + +If you can not use initrd, you can also embed the bootconfig file in the +kernel by Kconfig options. In this case, you need to recompile the kernel +with the following configs:: + + CONFIG_BOOT_CONFIG_EMBED=y + CONFIG_BOOT_CONFIG_EMBED_FILE="/PATH/TO/BOOTCONFIG/FILE" + +``CONFIG_BOOT_CONFIG_EMBED_FILE`` requires an absolute path or a relative +path to the bootconfig file from source tree or object tree. +The kernel will embed it as the default bootconfig. + +Just as when attaching the bootconfig to the initrd, you need ``bootconfig`` +option on the kernel command line to enable the embedded bootconfig. + +Note that even if you set this option, you can override the embedded +bootconfig by another bootconfig which attached to the initrd. Kernel parameters via Boot Config ================================= -- cgit From 3e1fac9324f8feaeffc724fd9aca7709caa6d3cc Mon Sep 17 00:00:00 2001 From: Yassine Oudjana Date: Sat, 9 Apr 2022 04:17:35 +0000 Subject: dt-bindings: opp: opp-v2-kryo-cpu: Remove SMEM qcom-cpufreq-nvmem no longer uses SMEM. Remove all references to SMEM and change the description and maximum value of opp-supported-hw to reflect the new set of possible values. Signed-off-by: Yassine Oudjana Acked-by: Rob Herring Signed-off-by: Viresh Kumar --- .../devicetree/bindings/opp/opp-v2-kryo-cpu.yaml | 56 ++++++++++------------ 1 file changed, 26 insertions(+), 30 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml index 8c2e9ac5f68d..30f7b596d609 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml @@ -17,10 +17,10 @@ description: | the CPU frequencies subset and voltage value of each OPP varies based on the silicon variant in use. Qualcomm Technologies, Inc. Process Voltage Scaling Tables - defines the voltage and frequency value based on the msm-id in SMEM - and speedbin blown in the efuse combination. - The qcom-cpufreq-nvmem driver reads the msm-id and efuse value from the SoC - to provide the OPP framework with required information (existing HW bitmap). + defines the voltage and frequency value based on the speedbin blown in + the efuse combination. + The qcom-cpufreq-nvmem driver reads the efuse value from the SoC to provide + the OPP framework with required information (existing HW bitmap). This is used to determine the voltage and frequency value for each OPP of operating-points-v2 table when it is parsed by the OPP framework. @@ -50,15 +50,11 @@ patternProperties: description: | A single 32 bit bitmap value, representing compatible HW. Bitmap: - 0: MSM8996 V3, speedbin 0 - 1: MSM8996 V3, speedbin 1 - 2: MSM8996 V3, speedbin 2 - 3: unused - 4: MSM8996 SG, speedbin 0 - 5: MSM8996 SG, speedbin 1 - 6: MSM8996 SG, speedbin 2 - 7-31: unused - maximum: 0x77 + 0: MSM8996, speedbin 0 + 1: MSM8996, speedbin 1 + 2: MSM8996, speedbin 2 + 3-31: unused + maximum: 0x7 clock-latency-ns: true @@ -184,19 +180,19 @@ examples: opp-307200000 { opp-hz = /bits/ 64 <307200000>; opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x77>; + opp-supported-hw = <0x7>; clock-latency-ns = <200000>; }; - opp-1593600000 { - opp-hz = /bits/ 64 <1593600000>; + opp-1401600000 { + opp-hz = /bits/ 64 <1401600000>; opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x71>; + opp-supported-hw = <0x5>; clock-latency-ns = <200000>; }; - opp-2188800000 { - opp-hz = /bits/ 64 <2188800000>; + opp-1593600000 { + opp-hz = /bits/ 64 <1593600000>; opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x10>; + opp-supported-hw = <0x1>; clock-latency-ns = <200000>; }; }; @@ -209,25 +205,25 @@ examples: opp-307200000 { opp-hz = /bits/ 64 <307200000>; opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x77>; + opp-supported-hw = <0x7>; clock-latency-ns = <200000>; }; - opp-1593600000 { - opp-hz = /bits/ 64 <1593600000>; + opp-1804800000 { + opp-hz = /bits/ 64 <1804800000>; opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; + opp-supported-hw = <0x6>; clock-latency-ns = <200000>; }; - opp-2150400000 { - opp-hz = /bits/ 64 <2150400000>; + opp-1900800000 { + opp-hz = /bits/ 64 <1900800000>; opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x31>; + opp-supported-hw = <0x4>; clock-latency-ns = <200000>; }; - opp-2342400000 { - opp-hz = /bits/ 64 <2342400000>; + opp-2150400000 { + opp-hz = /bits/ 64 <2150400000>; opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x10>; + opp-supported-hw = <0x1>; clock-latency-ns = <200000>; }; }; -- cgit From 6423d2951087231706246f81851067f7f0593d4a Mon Sep 17 00:00:00 2001 From: Won Chung Date: Mon, 14 Mar 2022 19:54:58 +0000 Subject: driver core: Add sysfs support for physical location of a device When ACPI table includes _PLD fields for a device, create a new directory (physical_location) in sysfs to share _PLD fields. Currently without PLD information, when there are multiple of same devices, it is hard to distinguish which device corresponds to which physical device at which location. For example, when there are two Type C connectors, it is hard to find out which connector corresponds to the Type C port on the left panel versus the Type C port on the right panel. With PLD information provided, we can determine which specific device at which location is doing what. _PLD output includes much more fields, but only generic fields are added and exposed to sysfs, so that non-ACPI devices can also support it in the future. The minimal generic fields needed for locating a device are the following. - panel - vertical_position - horizontal_position - dock - lid Signed-off-by: Won Chung Link: https://lore.kernel.org/r/20220314195458.271430-1-wonchung@google.com Signed-off-by: Greg Kroah-Hartman --- .../ABI/testing/sysfs-devices-physical_location | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-devices-physical_location (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-physical_location b/Documentation/ABI/testing/sysfs-devices-physical_location new file mode 100644 index 000000000000..202324b87083 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-physical_location @@ -0,0 +1,42 @@ +What: /sys/devices/.../physical_location +Date: March 2022 +Contact: Won Chung +Description: + This directory contains information on physical location of + the device connection point with respect to the system's + housing. + +What: /sys/devices/.../physical_location/panel +Date: March 2022 +Contact: Won Chung +Description: + Describes which panel surface of the system’s housing the + device connection point resides on. + +What: /sys/devices/.../physical_location/vertical_position +Date: March 2022 +Contact: Won Chung +Description: + Describes vertical position of the device connection point on + the panel surface. + +What: /sys/devices/.../physical_location/horizontal_position +Date: March 2022 +Contact: Won Chung +Description: + Describes horizontal position of the device connection point on + the panel surface. + +What: /sys/devices/.../physical_location/dock +Date: March 2022 +Contact: Won Chung +Description: + "Yes" if the device connection point resides in a docking + station or a port replicator. "No" otherwise. + +What: /sys/devices/.../physical_location/lid +Date: March 2022 +Contact: Won Chung +Description: + "Yes" if the device connection point resides on the lid of + laptop system. "No" otherwise. -- cgit From c1a519919d041f058a4451e93d7cf7c879f1a8b0 Mon Sep 17 00:00:00 2001 From: Horatiu Vultur Date: Wed, 27 Apr 2022 08:51:23 +0200 Subject: dt-bindings: net: lan966x: Extend with the ptp external interrupt. Extend dt-bindings for lan966x with ptp external interrupt. This is generated when an external 1pps signal is received on the ptp pin. Signed-off-by: Horatiu Vultur Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml index 13812768b923..131dc5a652de 100644 --- a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml +++ b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml @@ -39,6 +39,7 @@ properties: - description: frame dma based extraction - description: analyzer interrupt - description: ptp interrupt + - description: ptp external interrupt interrupt-names: minItems: 1 @@ -47,6 +48,7 @@ properties: - const: fdma - const: ana - const: ptp + - const: ptp-ext resets: items: -- cgit From 89fbca3307d40d5a48bc41919a543dc46298cf7a Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 26 Apr 2022 10:54:34 -0700 Subject: net: wan: remove support for COSA and SRP synchronous serial boards Looks like all the changes to this driver had been automated churn since git era begun. The driver is using virt_to_bus() so it should be updated to a proper DMA API or removed. Given the latest "news" entry on the website is from 1999 I'm opting for the latter. I'm marking the allocated char device major number as [REMOVED], I reckon we can't reuse it in case some SW out there assumes its COSA? Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller --- Documentation/admin-guide/devices.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt index c07dc0ee860e..9764d6edb189 100644 --- a/Documentation/admin-guide/devices.txt +++ b/Documentation/admin-guide/devices.txt @@ -1933,7 +1933,7 @@ ... 255= /dev/umem/d15p15 15th partition of 16th board. - 117 char COSA/SRP synchronous serial card + 117 char [REMOVED] COSA/SRP synchronous serial card 0 = /dev/cosa0c0 1st board, 1st channel 1 = /dev/cosa0c1 1st board, 2nd channel ... -- cgit From bc6df26f1f785be9b4c10d37e50ac40b46428984 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Tue, 26 Apr 2022 10:54:35 -0700 Subject: net: wan: remove support for Z85230-based devices Looks like all the changes to this driver had been automated churn since git era begun. The driver is using virt_to_bus(), it's just a maintenance burden unlikely to have any users. Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller --- Documentation/networking/device_drivers/index.rst | 1 - .../networking/device_drivers/wan/index.rst | 18 -- .../networking/device_drivers/wan/z8530book.rst | 256 --------------------- 3 files changed, 275 deletions(-) delete mode 100644 Documentation/networking/device_drivers/wan/index.rst delete mode 100644 Documentation/networking/device_drivers/wan/z8530book.rst (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/index.rst b/Documentation/networking/device_drivers/index.rst index 5f5cfdb2a300..601eacaf12f3 100644 --- a/Documentation/networking/device_drivers/index.rst +++ b/Documentation/networking/device_drivers/index.rst @@ -17,7 +17,6 @@ Contents: fddi/index hamradio/index qlogic/index - wan/index wifi/index wwan/index diff --git a/Documentation/networking/device_drivers/wan/index.rst b/Documentation/networking/device_drivers/wan/index.rst deleted file mode 100644 index 9d9ae94f00b4..000000000000 --- a/Documentation/networking/device_drivers/wan/index.rst +++ /dev/null @@ -1,18 +0,0 @@ -.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) - -Classic WAN Device Drivers -========================== - -Contents: - -.. toctree:: - :maxdepth: 2 - - z8530book - -.. only:: subproject and html - - Indices - ======= - - * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/wan/z8530book.rst b/Documentation/networking/device_drivers/wan/z8530book.rst deleted file mode 100644 index fea2c40e7973..000000000000 --- a/Documentation/networking/device_drivers/wan/z8530book.rst +++ /dev/null @@ -1,256 +0,0 @@ -======================= -Z8530 Programming Guide -======================= - -:Author: Alan Cox - -Introduction -============ - -The Z85x30 family synchronous/asynchronous controller chips are used on -a large number of cheap network interface cards. The kernel provides a -core interface layer that is designed to make it easy to provide WAN -services using this chip. - -The current driver only support synchronous operation. Merging the -asynchronous driver support into this code to allow any Z85x30 device to -be used as both a tty interface and as a synchronous controller is a -project for Linux post the 2.4 release - -Driver Modes -============ - -The Z85230 driver layer can drive Z8530, Z85C30 and Z85230 devices in -three different modes. Each mode can be applied to an individual channel -on the chip (each chip has two channels). - -The PIO synchronous mode supports the most common Z8530 wiring. Here the -chip is interface to the I/O and interrupt facilities of the host -machine but not to the DMA subsystem. When running PIO the Z8530 has -extremely tight timing requirements. Doing high speeds, even with a -Z85230 will be tricky. Typically you should expect to achieve at best -9600 baud with a Z8C530 and 64Kbits with a Z85230. - -The DMA mode supports the chip when it is configured to use dual DMA -channels on an ISA bus. The better cards tend to support this mode of -operation for a single channel. With DMA running the Z85230 tops out -when it starts to hit ISA DMA constraints at about 512Kbits. It is worth -noting here that many PC machines hang or crash when the chip is driven -fast enough to hold the ISA bus solid. - -Transmit DMA mode uses a single DMA channel. The DMA channel is used for -transmission as the transmit FIFO is smaller than the receive FIFO. it -gives better performance than pure PIO mode but is nowhere near as ideal -as pure DMA mode. - -Using the Z85230 driver -======================= - -The Z85230 driver provides the back end interface to your board. To -configure a Z8530 interface you need to detect the board and to identify -its ports and interrupt resources. It is also your problem to verify the -resources are available. - -Having identified the chip you need to fill in a struct z8530_dev, -which describes each chip. This object must exist until you finally -shutdown the board. Firstly zero the active field. This ensures nothing -goes off without you intending it. The irq field should be set to the -interrupt number of the chip. (Each chip has a single interrupt source -rather than each channel). You are responsible for allocating the -interrupt line. The interrupt handler should be set to -:c:func:`z8530_interrupt()`. The device id should be set to the -z8530_dev structure pointer. Whether the interrupt can be shared or not -is board dependent, and up to you to initialise. - -The structure holds two channel structures. Initialise chanA.ctrlio and -chanA.dataio with the address of the control and data ports. You can or -this with Z8530_PORT_SLEEP to indicate your interface needs the 5uS -delay for chip settling done in software. The PORT_SLEEP option is -architecture specific. Other flags may become available on future -platforms, eg for MMIO. Initialise the chanA.irqs to &z8530_nop to -start the chip up as disabled and discarding interrupt events. This -ensures that stray interrupts will be mopped up and not hang the bus. -Set chanA.dev to point to the device structure itself. The private and -name field you may use as you wish. The private field is unused by the -Z85230 layer. The name is used for error reporting and it may thus make -sense to make it match the network name. - -Repeat the same operation with the B channel if your chip has both -channels wired to something useful. This isn't always the case. If it is -not wired then the I/O values do not matter, but you must initialise -chanB.dev. - -If your board has DMA facilities then initialise the txdma and rxdma -fields for the relevant channels. You must also allocate the ISA DMA -channels and do any necessary board level initialisation to configure -them. The low level driver will do the Z8530 and DMA controller -programming but not board specific magic. - -Having initialised the device you can then call -:c:func:`z8530_init()`. This will probe the chip and reset it into -a known state. An identification sequence is then run to identify the -chip type. If the checks fail to pass the function returns a non zero -error code. Typically this indicates that the port given is not valid. -After this call the type field of the z8530_dev structure is -initialised to either Z8530, Z85C30 or Z85230 according to the chip -found. - -Once you have called z8530_init you can also make use of the utility -function :c:func:`z8530_describe()`. This provides a consistent -reporting format for the Z8530 devices, and allows all the drivers to -provide consistent reporting. - -Attaching Network Interfaces -============================ - -If you wish to use the network interface facilities of the driver, then -you need to attach a network device to each channel that is present and -in use. In addition to use the generic HDLC you need to follow some -additional plumbing rules. They may seem complex but a look at the -example hostess_sv11 driver should reassure you. - -The network device used for each channel should be pointed to by the -netdevice field of each channel. The hdlc-> priv field of the network -device points to your private data - you will need to be able to find -your private data from this. - -The way most drivers approach this particular problem is to create a -structure holding the Z8530 device definition and put that into the -private field of the network device. The network device fields of the -channels then point back to the network devices. - -If you wish to use the generic HDLC then you need to register the HDLC -device. - -Before you register your network device you will also need to provide -suitable handlers for most of the network device callbacks. See the -network device documentation for more details on this. - -Configuring And Activating The Port -=================================== - -The Z85230 driver provides helper functions and tables to load the port -registers on the Z8530 chips. When programming the register settings for -a channel be aware that the documentation recommends initialisation -orders. Strange things happen when these are not followed. - -:c:func:`z8530_channel_load()` takes an array of pairs of -initialisation values in an array of u8 type. The first value is the -Z8530 register number. Add 16 to indicate the alternate register bank on -the later chips. The array is terminated by a 255. - -The driver provides a pair of public tables. The z8530_hdlc_kilostream -table is for the UK 'Kilostream' service and also happens to cover most -other end host configurations. The z8530_hdlc_kilostream_85230 table -is the same configuration using the enhancements of the 85230 chip. The -configuration loaded is standard NRZ encoded synchronous data with HDLC -bitstuffing. All of the timing is taken from the other end of the link. - -When writing your own tables be aware that the driver internally tracks -register values. It may need to reload values. You should therefore be -sure to set registers 1-7, 9-11, 14 and 15 in all configurations. Where -the register settings depend on DMA selection the driver will update the -bits itself when you open or close. Loading a new table with the -interface open is not recommended. - -There are three standard configurations supported by the core code. In -PIO mode the interface is programmed up to use interrupt driven PIO. -This places high demands on the host processor to avoid latency. The -driver is written to take account of latency issues but it cannot avoid -latencies caused by other drivers, notably IDE in PIO mode. Because the -drivers allocate buffers you must also prevent MTU changes while the -port is open. - -Once the port is open it will call the rx_function of each channel -whenever a completed packet arrived. This is invoked from interrupt -context and passes you the channel and a network buffer (struct -sk_buff) holding the data. The data includes the CRC bytes so most -users will want to trim the last two bytes before processing the data. -This function is very timing critical. When you wish to simply discard -data the support code provides the function -:c:func:`z8530_null_rx()` to discard the data. - -To active PIO mode sending and receiving the ``z8530_sync_open`` is called. -This expects to be passed the network device and the channel. Typically -this is called from your network device open callback. On a failure a -non zero error status is returned. -The :c:func:`z8530_sync_close()` function shuts down a PIO -channel. This must be done before the channel is opened again and before -the driver shuts down and unloads. - -The ideal mode of operation is dual channel DMA mode. Here the kernel -driver will configure the board for DMA in both directions. The driver -also handles ISA DMA issues such as controller programming and the -memory range limit for you. This mode is activated by calling the -:c:func:`z8530_sync_dma_open()` function. On failure a non zero -error value is returned. Once this mode is activated it can be shut down -by calling the :c:func:`z8530_sync_dma_close()`. You must call -the close function matching the open mode you used. - -The final supported mode uses a single DMA channel to drive the transmit -side. As the Z85C30 has a larger FIFO on the receive channel this tends -to increase the maximum speed a little. This is activated by calling the -``z8530_sync_txdma_open``. This returns a non zero error code on failure. The -:c:func:`z8530_sync_txdma_close()` function closes down the Z8530 -interface from this mode. - -Network Layer Functions -======================= - -The Z8530 layer provides functions to queue packets for transmission. -The driver internally buffers the frame currently being transmitted and -one further frame (in order to keep back to back transmission running). -Any further buffering is up to the caller. - -The function :c:func:`z8530_queue_xmit()` takes a network buffer -in sk_buff format and queues it for transmission. The caller must -provide the entire packet with the exception of the bitstuffing and CRC. -This is normally done by the caller via the generic HDLC interface -layer. It returns 0 if the buffer has been queued and non zero values -for queue full. If the function accepts the buffer it becomes property -of the Z8530 layer and the caller should not free it. - -The function :c:func:`z8530_get_stats()` returns a pointer to an -internally maintained per interface statistics block. This provides most -of the interface code needed to implement the network layer get_stats -callback. - -Porting The Z8530 Driver -======================== - -The Z8530 driver is written to be portable. In DMA mode it makes -assumptions about the use of ISA DMA. These are probably warranted in -most cases as the Z85230 in particular was designed to glue to PC type -machines. The PIO mode makes no real assumptions. - -Should you need to retarget the Z8530 driver to another architecture the -only code that should need changing are the port I/O functions. At the -moment these assume PC I/O port accesses. This may not be appropriate -for all platforms. Replacing :c:func:`z8530_read_port()` and -``z8530_write_port`` is intended to be all that is required to port -this driver layer. - -Known Bugs And Assumptions -========================== - -Interrupt Locking - The locking in the driver is done via the global cli/sti lock. This - makes for relatively poor SMP performance. Switching this to use a - per device spin lock would probably materially improve performance. - -Occasional Failures - We have reports of occasional failures when run for very long - periods of time and the driver starts to receive junk frames. At the - moment the cause of this is not clear. - -Public Functions Provided -========================= - -.. kernel-doc:: drivers/net/wan/z85230.c - :export: - -Internal Functions -================== - -.. kernel-doc:: drivers/net/wan/z85230.c - :internal: -- cgit From d63670d23e60f00210635ca7c62bce27bec55f1b Mon Sep 17 00:00:00 2001 From: Tom Lendacky Date: Wed, 20 Apr 2022 09:14:14 -0500 Subject: virt: sevguest: Rename the sevguest dir and files to sev-guest Rename the drivers/virt/coco/sevguest directory and files to sev-guest so as to match the driver name. [ bp: Rename Documentation/virt/coco/sevguest.rst too, as reported by sfr: https://lore.kernel.org/r/20220427101059.3bf55262@canb.auug.org.au ] Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/2f5c9cb16e3a67599c8e3170f6c72c8712c47d53.1650464054.git.thomas.lendacky@amd.com --- Documentation/virt/coco/sev-guest.rst | 155 ++++++++++++++++++++++++++++++++++ Documentation/virt/coco/sevguest.rst | 155 ---------------------------------- Documentation/virt/index.rst | 2 +- 3 files changed, 156 insertions(+), 156 deletions(-) create mode 100644 Documentation/virt/coco/sev-guest.rst delete mode 100644 Documentation/virt/coco/sevguest.rst (limited to 'Documentation') diff --git a/Documentation/virt/coco/sev-guest.rst b/Documentation/virt/coco/sev-guest.rst new file mode 100644 index 000000000000..bf593e88cfd9 --- /dev/null +++ b/Documentation/virt/coco/sev-guest.rst @@ -0,0 +1,155 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================================================== +The Definitive SEV Guest API Documentation +=================================================================== + +1. General description +====================== + +The SEV API is a set of ioctls that are used by the guest or hypervisor +to get or set a certain aspect of the SEV virtual machine. The ioctls belong +to the following classes: + + - Hypervisor ioctls: These query and set global attributes which affect the + whole SEV firmware. These ioctl are used by platform provisioning tools. + + - Guest ioctls: These query and set attributes of the SEV virtual machine. + +2. API description +================== + +This section describes ioctls that is used for querying the SEV guest report +from the SEV firmware. For each ioctl, the following information is provided +along with a description: + + Technology: + which SEV technology provides this ioctl. SEV, SEV-ES, SEV-SNP or all. + + Type: + hypervisor or guest. The ioctl can be used inside the guest or the + hypervisor. + + Parameters: + what parameters are accepted by the ioctl. + + Returns: + the return value. General error numbers (-ENOMEM, -EINVAL) + are not detailed, but errors with specific meanings are. + +The guest ioctl should be issued on a file descriptor of the /dev/sev-guest device. +The ioctl accepts struct snp_user_guest_request. The input and output structure is +specified through the req_data and resp_data field respectively. If the ioctl fails +to execute due to a firmware error, then fw_err code will be set otherwise the +fw_err will be set to 0x00000000000000ff. + +The firmware checks that the message sequence counter is one greater than +the guests message sequence counter. If guest driver fails to increment message +counter (e.g. counter overflow), then -EIO will be returned. + +:: + + struct snp_guest_request_ioctl { + /* Message version number */ + __u32 msg_version; + + /* Request and response structure address */ + __u64 req_data; + __u64 resp_data; + + /* firmware error code on failure (see psp-sev.h) */ + __u64 fw_err; + }; + +2.1 SNP_GET_REPORT +------------------ + +:Technology: sev-snp +:Type: guest ioctl +:Parameters (in): struct snp_report_req +:Returns (out): struct snp_report_resp on success, -negative on error + +The SNP_GET_REPORT ioctl can be used to query the attestation report from the +SEV-SNP firmware. The ioctl uses the SNP_GUEST_REQUEST (MSG_REPORT_REQ) command +provided by the SEV-SNP firmware to query the attestation report. + +On success, the snp_report_resp.data will contains the report. The report +contain the format described in the SEV-SNP specification. See the SEV-SNP +specification for further details. + +2.2 SNP_GET_DERIVED_KEY +----------------------- +:Technology: sev-snp +:Type: guest ioctl +:Parameters (in): struct snp_derived_key_req +:Returns (out): struct snp_derived_key_resp on success, -negative on error + +The SNP_GET_DERIVED_KEY ioctl can be used to get a key derive from a root key. +The derived key can be used by the guest for any purpose, such as sealing keys +or communicating with external entities. + +The ioctl uses the SNP_GUEST_REQUEST (MSG_KEY_REQ) command provided by the +SEV-SNP firmware to derive the key. See SEV-SNP specification for further details +on the various fields passed in the key derivation request. + +On success, the snp_derived_key_resp.data contains the derived key value. See +the SEV-SNP specification for further details. + + +2.3 SNP_GET_EXT_REPORT +---------------------- +:Technology: sev-snp +:Type: guest ioctl +:Parameters (in/out): struct snp_ext_report_req +:Returns (out): struct snp_report_resp on success, -negative on error + +The SNP_GET_EXT_REPORT ioctl is similar to the SNP_GET_REPORT. The difference is +related to the additional certificate data that is returned with the report. +The certificate data returned is being provided by the hypervisor through the +SNP_SET_EXT_CONFIG. + +The ioctl uses the SNP_GUEST_REQUEST (MSG_REPORT_REQ) command provided by the SEV-SNP +firmware to get the attestation report. + +On success, the snp_ext_report_resp.data will contain the attestation report +and snp_ext_report_req.certs_address will contain the certificate blob. If the +length of the blob is smaller than expected then snp_ext_report_req.certs_len will +be updated with the expected value. + +See GHCB specification for further detail on how to parse the certificate blob. + +3. SEV-SNP CPUID Enforcement +============================ + +SEV-SNP guests can access a special page that contains a table of CPUID values +that have been validated by the PSP as part of the SNP_LAUNCH_UPDATE firmware +command. It provides the following assurances regarding the validity of CPUID +values: + + - Its address is obtained via bootloader/firmware (via CC blob), and those + binaries will be measured as part of the SEV-SNP attestation report. + - Its initial state will be encrypted/pvalidated, so attempts to modify + it during run-time will result in garbage being written, or #VC exceptions + being generated due to changes in validation state if the hypervisor tries + to swap the backing page. + - Attempts to bypass PSP checks by the hypervisor by using a normal page, or + a non-CPUID encrypted page will change the measurement provided by the + SEV-SNP attestation report. + - The CPUID page contents are *not* measured, but attempts to modify the + expected contents of a CPUID page as part of guest initialization will be + gated by the PSP CPUID enforcement policy checks performed on the page + during SNP_LAUNCH_UPDATE, and noticeable later if the guest owner + implements their own checks of the CPUID values. + +It is important to note that this last assurance is only useful if the kernel +has taken care to make use of the SEV-SNP CPUID throughout all stages of boot. +Otherwise, guest owner attestation provides no assurance that the kernel wasn't +fed incorrect values at some point during boot. + + +Reference +--------- + +SEV-SNP and GHCB specification: developer.amd.com/sev + +The driver is based on SEV-SNP firmware spec 0.9 and GHCB spec version 2.0. diff --git a/Documentation/virt/coco/sevguest.rst b/Documentation/virt/coco/sevguest.rst deleted file mode 100644 index bf593e88cfd9..000000000000 --- a/Documentation/virt/coco/sevguest.rst +++ /dev/null @@ -1,155 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -=================================================================== -The Definitive SEV Guest API Documentation -=================================================================== - -1. General description -====================== - -The SEV API is a set of ioctls that are used by the guest or hypervisor -to get or set a certain aspect of the SEV virtual machine. The ioctls belong -to the following classes: - - - Hypervisor ioctls: These query and set global attributes which affect the - whole SEV firmware. These ioctl are used by platform provisioning tools. - - - Guest ioctls: These query and set attributes of the SEV virtual machine. - -2. API description -================== - -This section describes ioctls that is used for querying the SEV guest report -from the SEV firmware. For each ioctl, the following information is provided -along with a description: - - Technology: - which SEV technology provides this ioctl. SEV, SEV-ES, SEV-SNP or all. - - Type: - hypervisor or guest. The ioctl can be used inside the guest or the - hypervisor. - - Parameters: - what parameters are accepted by the ioctl. - - Returns: - the return value. General error numbers (-ENOMEM, -EINVAL) - are not detailed, but errors with specific meanings are. - -The guest ioctl should be issued on a file descriptor of the /dev/sev-guest device. -The ioctl accepts struct snp_user_guest_request. The input and output structure is -specified through the req_data and resp_data field respectively. If the ioctl fails -to execute due to a firmware error, then fw_err code will be set otherwise the -fw_err will be set to 0x00000000000000ff. - -The firmware checks that the message sequence counter is one greater than -the guests message sequence counter. If guest driver fails to increment message -counter (e.g. counter overflow), then -EIO will be returned. - -:: - - struct snp_guest_request_ioctl { - /* Message version number */ - __u32 msg_version; - - /* Request and response structure address */ - __u64 req_data; - __u64 resp_data; - - /* firmware error code on failure (see psp-sev.h) */ - __u64 fw_err; - }; - -2.1 SNP_GET_REPORT ------------------- - -:Technology: sev-snp -:Type: guest ioctl -:Parameters (in): struct snp_report_req -:Returns (out): struct snp_report_resp on success, -negative on error - -The SNP_GET_REPORT ioctl can be used to query the attestation report from the -SEV-SNP firmware. The ioctl uses the SNP_GUEST_REQUEST (MSG_REPORT_REQ) command -provided by the SEV-SNP firmware to query the attestation report. - -On success, the snp_report_resp.data will contains the report. The report -contain the format described in the SEV-SNP specification. See the SEV-SNP -specification for further details. - -2.2 SNP_GET_DERIVED_KEY ------------------------ -:Technology: sev-snp -:Type: guest ioctl -:Parameters (in): struct snp_derived_key_req -:Returns (out): struct snp_derived_key_resp on success, -negative on error - -The SNP_GET_DERIVED_KEY ioctl can be used to get a key derive from a root key. -The derived key can be used by the guest for any purpose, such as sealing keys -or communicating with external entities. - -The ioctl uses the SNP_GUEST_REQUEST (MSG_KEY_REQ) command provided by the -SEV-SNP firmware to derive the key. See SEV-SNP specification for further details -on the various fields passed in the key derivation request. - -On success, the snp_derived_key_resp.data contains the derived key value. See -the SEV-SNP specification for further details. - - -2.3 SNP_GET_EXT_REPORT ----------------------- -:Technology: sev-snp -:Type: guest ioctl -:Parameters (in/out): struct snp_ext_report_req -:Returns (out): struct snp_report_resp on success, -negative on error - -The SNP_GET_EXT_REPORT ioctl is similar to the SNP_GET_REPORT. The difference is -related to the additional certificate data that is returned with the report. -The certificate data returned is being provided by the hypervisor through the -SNP_SET_EXT_CONFIG. - -The ioctl uses the SNP_GUEST_REQUEST (MSG_REPORT_REQ) command provided by the SEV-SNP -firmware to get the attestation report. - -On success, the snp_ext_report_resp.data will contain the attestation report -and snp_ext_report_req.certs_address will contain the certificate blob. If the -length of the blob is smaller than expected then snp_ext_report_req.certs_len will -be updated with the expected value. - -See GHCB specification for further detail on how to parse the certificate blob. - -3. SEV-SNP CPUID Enforcement -============================ - -SEV-SNP guests can access a special page that contains a table of CPUID values -that have been validated by the PSP as part of the SNP_LAUNCH_UPDATE firmware -command. It provides the following assurances regarding the validity of CPUID -values: - - - Its address is obtained via bootloader/firmware (via CC blob), and those - binaries will be measured as part of the SEV-SNP attestation report. - - Its initial state will be encrypted/pvalidated, so attempts to modify - it during run-time will result in garbage being written, or #VC exceptions - being generated due to changes in validation state if the hypervisor tries - to swap the backing page. - - Attempts to bypass PSP checks by the hypervisor by using a normal page, or - a non-CPUID encrypted page will change the measurement provided by the - SEV-SNP attestation report. - - The CPUID page contents are *not* measured, but attempts to modify the - expected contents of a CPUID page as part of guest initialization will be - gated by the PSP CPUID enforcement policy checks performed on the page - during SNP_LAUNCH_UPDATE, and noticeable later if the guest owner - implements their own checks of the CPUID values. - -It is important to note that this last assurance is only useful if the kernel -has taken care to make use of the SEV-SNP CPUID throughout all stages of boot. -Otherwise, guest owner attestation provides no assurance that the kernel wasn't -fed incorrect values at some point during boot. - - -Reference ---------- - -SEV-SNP and GHCB specification: developer.amd.com/sev - -The driver is based on SEV-SNP firmware spec 0.9 and GHCB spec version 2.0. diff --git a/Documentation/virt/index.rst b/Documentation/virt/index.rst index 40ad0d20032e..492f0920b988 100644 --- a/Documentation/virt/index.rst +++ b/Documentation/virt/index.rst @@ -13,7 +13,7 @@ Linux Virtualization Support guest-halt-polling ne_overview acrn/index - coco/sevguest + coco/sev-guest .. only:: html and subproject -- cgit From 69bb9b29bf67e850beece45e9c99ca707eac7e41 Mon Sep 17 00:00:00 2001 From: Chuanhong Guo Date: Sun, 24 Apr 2022 11:25:26 +0800 Subject: spi: dt-bindings: add binding doc for spi-mtk-snfi Add device-tree binding documentation for Mediatek SPI-NAND Flash Interface. Signed-off-by: Chuanhong Guo Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220424032527.673605-5-gch981213@gmail.com Signed-off-by: Mark Brown --- .../bindings/spi/mediatek,spi-mtk-snfi.yaml | 88 ++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/mediatek,spi-mtk-snfi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-snfi.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-snfi.yaml new file mode 100644 index 000000000000..6e6e02c91780 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-snfi.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/mediatek,spi-mtk-snfi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SPI-NAND flash controller for MediaTek ARM SoCs + +maintainers: + - Chuanhong Guo + +description: | + The Mediatek SPI-NAND flash controller is an extended version of + the Mediatek NAND flash controller. It can perform standard SPI + instructions with one continuous write and one read for up-to 0xa0 + bytes. It also supports typical SPI-NAND page cache operations + in single, dual or quad IO mode with pipelined ECC encoding/decoding + using the accompanying ECC engine. There should be only one spi + slave device following generic spi bindings. + +allOf: + - $ref: /schemas/spi/spi-controller.yaml# + +properties: + compatible: + enum: + - mediatek,mt7622-snand + - mediatek,mt7629-snand + + reg: + items: + - description: core registers + + interrupts: + items: + - description: NFI interrupt + + clocks: + items: + - description: clock used for the controller + - description: clock used for the SPI bus + + clock-names: + items: + - const: nfi_clk + - const: pad_clk + + nand-ecc-engine: + description: device-tree node of the accompanying ECC engine. + $ref: /schemas/types.yaml#/definitions/phandle + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - nand-ecc-engine + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + soc { + #address-cells = <2>; + #size-cells = <2>; + snfi: spi@1100d000 { + compatible = "mediatek,mt7622-snand"; + reg = <0 0x1100d000 0 0x1000>; + interrupts = ; + clocks = <&pericfg CLK_PERI_NFI_PD>, <&pericfg CLK_PERI_SNFI_PD>; + clock-names = "nfi_clk", "pad_clk"; + nand-ecc-engine = <&bch>; + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + compatible = "spi-nand"; + reg = <0>; + spi-tx-bus-width = <4>; + spi-rx-bus-width = <4>; + nand-ecc-engine = <&snfi>; + }; + }; + }; -- cgit From f9095ac1ba1ce407cecc1df93c05ad4ac504661c Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 27 Apr 2022 08:58:02 +0200 Subject: dt-bindings: ufs: cdns,ufshc: Add power-domains The Cadence UFS controller can be part of power domain (as it is in example DTS of TI J721e UFS Host Controller Glue), so allow such property. Reported-by: Rob Herring Signed-off-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220427065802.110402-1-krzysztof.kozlowski@linaro.org --- Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml b/Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml index d227dea368be..fb45f66d6454 100644 --- a/Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml +++ b/Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml @@ -43,6 +43,9 @@ properties: - const: phy_clk - const: ref_clk + power-domains: + maxItems: 1 + reg: maxItems: 1 -- cgit From e17fd4bf54fb579d03566ab22a02dc03b36f4d06 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 26 Apr 2022 08:35:08 -0500 Subject: dt-bindings: leds-mt6360: Drop redundant 'unevaluatedProperties' The binding has both 'unevaluatedProperties: false' and 'additionalProperties: false' which is redundant. 'additionalProperties' is the stricter of the two, so drop 'unevaluatedProperties'. Fixes: e05cab34e417 ("dt-bindings: leds: Add bindings for MT6360 LED") Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220426133508.1849580-1-robh@kernel.org --- Documentation/devicetree/bindings/leds/leds-mt6360.yaml | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/leds-mt6360.yaml b/Documentation/devicetree/bindings/leds/leds-mt6360.yaml index b2fe6eb89389..10f95bf1d666 100644 --- a/Documentation/devicetree/bindings/leds/leds-mt6360.yaml +++ b/Documentation/devicetree/bindings/leds/leds-mt6360.yaml @@ -43,8 +43,6 @@ patternProperties: - 4 # LED output FLASH1 - 5 # LED output FLASH2 -unevaluatedProperties: false - required: - compatible - "#address-cells" -- cgit From 5603f9bdea68406f54132125b6fdddeeb5c0d2e4 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Wed, 27 Apr 2022 12:41:59 -0700 Subject: docs: vm/page_owner: use literal blocks for param description Sphinx generates hard-to-read lists of parameters at the bottom of the page. Fix them by putting literal-block markers of "::" in front of them. Link: https://lkml.kernel.org/r/cfd3bcc0-b51d-0c68-c065-ca1c4c202447@gmail.com Signed-off-by: Akira Yokosawa Fixes: 57f2b54a9379 ("Documentation/vm/page_owner.rst: update the documentation") Cc: Shenghong Han Cc: Haowen Bai Cc: Jonathan Corbet Cc: Alex Shi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/page_owner.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index 65204d7f004f..7e0c3f574e78 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -110,7 +110,7 @@ Usage If you want to sort by the page nums of buf, use the ``-m`` parameter. The detailed parameters are: - fundamental function: + fundamental function:: Sort: -a Sort by memory allocation time. @@ -122,7 +122,7 @@ Usage -s Sort by stack trace. -t Sort by times (default). - additional function: + additional function:: Cull: --cull @@ -153,6 +153,7 @@ Usage STANDARD FORMAT SPECIFIERS ========================== +:: KEY LONG DESCRIPTION p pid process ID -- cgit From 4d1257bbc220603d9e5c5157552448c066111c71 Mon Sep 17 00:00:00 2001 From: Kurt Kanzenbach Date: Thu, 14 Apr 2022 11:18:05 +0200 Subject: tracing: Add documentation for trace clock tai Add documentation for newly introduced trace clock "tai". This clock corresponds to CLOCK_TAI. Link: https://lkml.kernel.org/r/20220414091805.89667-4-kurt@linutronix.de Signed-off-by: Kurt Kanzenbach Signed-off-by: Steven Rostedt (Google) --- Documentation/trace/ftrace.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index 45b8c56af67a..b37dc19e4d40 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -517,6 +517,18 @@ of ftrace. Here is a list of some of the key files: processing should be able to handle them. See comments in the ktime_get_boot_fast_ns() function for more information. + tai: + This is the tai clock (CLOCK_TAI) and is derived from the wall- + clock time. However, this clock does not experience + discontinuities and backwards jumps caused by NTP inserting leap + seconds. Since the clock access is designed for use in tracing, + side effects are possible. The clock access may yield wrong + readouts in case the internal TAI offset is updated e.g., caused + by setting the system time or using adjtimex() with an offset. + These effects are rare and post processing should be able to + handle them. See comments in the ktime_get_tai_fast_ns() + function for more information. + To set a clock, simply echo the clock name into this file:: # echo global > trace_clock -- cgit From 65e42ad98e225cf796d8ef869a712dec6821bfe8 Mon Sep 17 00:00:00 2001 From: Dylan Hung Date: Wed, 27 Apr 2022 11:54:59 +0800 Subject: dt-bindings: net: add reset property for aspeed, ast2600-mdio binding The AST2600 MDIO bus controller has a reset control bit and must be deasserted before manipulating the MDIO controller. By default, the hardware asserts the reset so the driver only need to deassert it. Regarding to the old DT blobs which don't have reset property in them, the reset deassertion is usually done by the bootloader so the reset property is optional to work with them. Signed-off-by: Dylan Hung Reviewed-by: Krzysztof Kozlowski Reviewed-by: Andrew Jeffery Signed-off-by: Paolo Abeni --- Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml index 1c88820cbcdf..f81eda8cb0a5 100644 --- a/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml +++ b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml @@ -20,10 +20,14 @@ allOf: properties: compatible: const: aspeed,ast2600-mdio + reg: maxItems: 1 description: The register range of the MDIO controller instance + resets: + maxItems: 1 + required: - compatible - reg @@ -34,11 +38,13 @@ unevaluatedProperties: false examples: - | + #include mdio0: mdio@1e650000 { compatible = "aspeed,ast2600-mdio"; reg = <0x1e650000 0x8>; #address-cells = <1>; #size-cells = <0>; + resets = <&syscon ASPEED_RESET_MII>; ethphy0: ethernet-phy@0 { compatible = "ethernet-phy-ieee802.3-c22"; -- cgit From 380422ad344d461901dca85970ecc976e182f0c9 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 27 Apr 2022 17:58:36 +0200 Subject: dt-bindings: mfd: samsung,exynos5433-lpass: Fix 'dma-channels/requests' properties pl330 DMA controller bindings documented 'dma-channels' and 'dma-requests' properties (without leading hash sign), so fix the DTS to match the bindings. Fixes: e18183cefc8b ("mfd: Add DT bindings documentation for Samsung Exynos LPASS") Reported-by: Rob Herring Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Reviewed-by: Alim Akhtar Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220427155840.596535-7-krzysztof.kozlowski@linaro.org --- Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml index bae55c98961c..4a21b0ec68e3 100644 --- a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml +++ b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml @@ -79,8 +79,8 @@ examples: clocks = <&cmu_aud CLK_ACLK_DMAC>; clock-names = "apb_pclk"; #dma-cells = <1>; - #dma-channels = <8>; - #dma-requests = <32>; + dma-channels = <8>; + dma-requests = <32>; power-domains = <&pd_aud>; }; -- cgit From c35fe2a68f29a0bda15ae994154cacaae5f69791 Mon Sep 17 00:00:00 2001 From: Catalin Marinas Date: Mon, 25 Apr 2022 16:18:33 +0100 Subject: elf: Fix the arm64 MTE ELF segment name and value Unfortunately, the name/value choice for the MTE ELF segment type (PT_ARM_MEMTAG_MTE) was pretty poor: LOPROC+1 is already in use by PT_AARCH64_UNWIND, as defined in the AArch64 ELF ABI (https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst). Update the ELF segment type value to LOPROC+2 and also change the define to PT_AARCH64_MEMTAG_MTE to match the AArch64 ELF ABI namespace. The AArch64 ELF ABI document is updating accordingly (segment type not previously mentioned in the document). Signed-off-by: Catalin Marinas Fixes: 761b9b366cec ("elf: Introduce the ARM MTE ELF segment type") Cc: Will Deacon Cc: Jonathan Corbet Cc: Eric Biederman Cc: Kees Cook Cc: Luis Machado Cc: Richard Earnshaw Link: https://lore.kernel.org/r/20220425151833.2603830-1-catalin.marinas@arm.com Signed-off-by: Will Deacon --- Documentation/arm64/memory-tagging-extension.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arm64/memory-tagging-extension.rst index dd27f78d7608..dbae47bba25e 100644 --- a/Documentation/arm64/memory-tagging-extension.rst +++ b/Documentation/arm64/memory-tagging-extension.rst @@ -228,10 +228,10 @@ Core dump support ----------------- The allocation tags for user memory mapped with ``PROT_MTE`` are dumped -in the core file as additional ``PT_ARM_MEMTAG_MTE`` segments. The +in the core file as additional ``PT_AARCH64_MEMTAG_MTE`` segments. The program header for such segment is defined as: -:``p_type``: ``PT_ARM_MEMTAG_MTE`` +:``p_type``: ``PT_AARCH64_MEMTAG_MTE`` :``p_flags``: 0 :``p_offset``: segment file offset :``p_vaddr``: segment virtual address, same as the corresponding -- cgit From 5b1553bf18de019388c5e9de03d9330f92507695 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 22 Apr 2022 14:21:03 -0500 Subject: dt-bindings: iommu: Drop client node in examples There's no need to show consumer side in provider examples. The ones used here are undocumented or undocumented in schemas which results in warnings. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220422192104.2591462-1-robh@kernel.org Signed-off-by: Joerg Roedel --- Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml | 10 ---------- Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml | 10 ---------- 2 files changed, 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index 97e8c471a5e8..e0389539194f 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -173,13 +173,3 @@ examples: <&larb3>, <&larb4>, <&larb5>; #iommu-cells = <1>; }; - - - | - #include - - /* Example for a client device */ - display { - compatible = "mediatek,mt8173-disp"; - iommus = <&iommu M4U_PORT_DISP_OVL0>, - <&iommu M4U_PORT_DISP_RDMA0>; - }; diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml index af51b91c893e..24d8d129dc4c 100644 --- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml +++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml @@ -86,16 +86,6 @@ examples: - | #include - gsc_0: scaler@13e00000 { - compatible = "samsung,exynos5-gsc"; - reg = <0x13e00000 0x1000>; - interrupts = <0 85 0>; - power-domains = <&pd_gsc>; - clocks = <&clock CLK_GSCL0>; - clock-names = "gscl"; - iommus = <&sysmmu_gsc0>; - }; - sysmmu_gsc0: iommu@13e80000 { compatible = "samsung,exynos-sysmmu"; reg = <0x13E80000 0x1000>; -- cgit From 2a8d78d566faa3d92214f161fdd7134957407871 Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Fri, 22 Apr 2022 15:26:56 -0400 Subject: Documentation: x86: rework IOMMU documentation Add preliminary documentation for AMD IOMMU and combine with the existing Intel IOMMU documentation and clean up and modernize some of the existing documentation to align with the current state of the kernel. Signed-off-by: Alex Deucher Acked-by: Joerg Roedel Link: https://lore.kernel.org/r/20220422192656.624920-1-alexander.deucher@amd.com Signed-off-by: Jonathan Corbet --- Documentation/x86/index.rst | 2 +- Documentation/x86/intel-iommu.rst | 115 ----------------------------- Documentation/x86/iommu.rst | 151 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 152 insertions(+), 116 deletions(-) delete mode 100644 Documentation/x86/intel-iommu.rst create mode 100644 Documentation/x86/iommu.rst (limited to 'Documentation') diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index 91b2fa456618..1f720227bb73 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -22,7 +22,7 @@ x86-specific Documentation mtrr pat intel-hfi - intel-iommu + iommu intel_txt amd-memory-encryption amd_hsmp diff --git a/Documentation/x86/intel-iommu.rst b/Documentation/x86/intel-iommu.rst deleted file mode 100644 index 099f13d51d5f..000000000000 --- a/Documentation/x86/intel-iommu.rst +++ /dev/null @@ -1,115 +0,0 @@ -=================== -Linux IOMMU Support -=================== - -The architecture spec can be obtained from the below location. - -http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf - -This guide gives a quick cheat sheet for some basic understanding. - -Some Keywords - -- DMAR - DMA remapping -- DRHD - DMA Remapping Hardware Unit Definition -- RMRR - Reserved memory Region Reporting Structure -- ZLR - Zero length reads from PCI devices -- IOVA - IO Virtual address. - -Basic stuff ------------ - -ACPI enumerates and lists the different DMA engines in the platform, and -device scope relationships between PCI devices and which DMA engine controls -them. - -What is RMRR? -------------- - -There are some devices the BIOS controls, for e.g USB devices to perform -PS2 emulation. The regions of memory used for these devices are marked -reserved in the e820 map. When we turn on DMA translation, DMA to those -regions will fail. Hence BIOS uses RMRR to specify these regions along with -devices that need to access these regions. OS is expected to setup -unity mappings for these regions for these devices to access these regions. - -How is IOVA generated? ----------------------- - -Well behaved drivers call pci_map_*() calls before sending command to device -that needs to perform DMA. Once DMA is completed and mapping is no longer -required, device performs a pci_unmap_*() calls to unmap the region. - -The Intel IOMMU driver allocates a virtual address per domain. Each PCIE -device has its own domain (hence protection). Devices under p2p bridges -share the virtual address with all devices under the p2p bridge due to -transaction id aliasing for p2p bridges. - -IOVA generation is pretty generic. We used the same technique as vmalloc() -but these are not global address spaces, but separate for each domain. -Different DMA engines may support different number of domains. - -We also allocate guard pages with each mapping, so we can attempt to catch -any overflow that might happen. - - -Graphics Problems? ------------------- -If you encounter issues with graphics devices, you can try adding -option intel_iommu=igfx_off to turn off the integrated graphics engine. -If this fixes anything, please ensure you file a bug reporting the problem. - -Some exceptions to IOVA ------------------------ -Interrupt ranges are not address translated, (0xfee00000 - 0xfeefffff). -The same is true for peer to peer transactions. Hence we reserve the -address from PCI MMIO ranges so they are not allocated for IOVA addresses. - - -Fault reporting ---------------- -When errors are reported, the DMA engine signals via an interrupt. The fault -reason and device that caused it with fault reason is printed on console. - -See below for sample. - - -Boot Message Sample -------------------- - -Something like this gets printed indicating presence of DMAR tables -in ACPI. - -ACPI: DMAR (v001 A M I OEMDMAR 0x00000001 MSFT 0x00000097) @ 0x000000007f5b5ef0 - -When DMAR is being processed and initialized by ACPI, prints DMAR locations -and any RMRR's processed:: - - ACPI DMAR:Host address width 36 - ACPI DMAR:DRHD (flags: 0x00000000)base: 0x00000000fed90000 - ACPI DMAR:DRHD (flags: 0x00000000)base: 0x00000000fed91000 - ACPI DMAR:DRHD (flags: 0x00000001)base: 0x00000000fed93000 - ACPI DMAR:RMRR base: 0x00000000000ed000 end: 0x00000000000effff - ACPI DMAR:RMRR base: 0x000000007f600000 end: 0x000000007fffffff - -When DMAR is enabled for use, you will notice.. - -PCI-DMA: Using DMAR IOMMU -------------------------- - -Fault reporting -^^^^^^^^^^^^^^^ - -:: - - DMAR:[DMA Write] Request device [00:02.0] fault addr 6df084000 - DMAR:[fault reason 05] PTE Write access is not set - DMAR:[DMA Write] Request device [00:02.0] fault addr 6df084000 - DMAR:[fault reason 05] PTE Write access is not set - -TBD ----- - -- For compatibility testing, could use unity map domain for all devices, just - provide a 1-1 for all useful memory under a single domain for all devices. -- API for paravirt ops for abstracting functionality for VMM folks. diff --git a/Documentation/x86/iommu.rst b/Documentation/x86/iommu.rst new file mode 100644 index 000000000000..42c7a6faa39a --- /dev/null +++ b/Documentation/x86/iommu.rst @@ -0,0 +1,151 @@ +================= +x86 IOMMU Support +================= + +The architecture specs can be obtained from the below locations. + +- Intel: http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf +- AMD: https://www.amd.com/system/files/TechDocs/48882_IOMMU.pdf + +This guide gives a quick cheat sheet for some basic understanding. + +Basic stuff +----------- + +ACPI enumerates and lists the different IOMMUs on the platform, and +device scope relationships between devices and which IOMMU controls +them. + +Some ACPI Keywords: + +- DMAR - Intel DMA Remapping table +- DRHD - Intel DMA Remapping Hardware Unit Definition +- RMRR - Intel Reserved Memory Region Reporting Structure +- IVRS - AMD I/O Virtualization Reporting Structure +- IVDB - AMD I/O Virtualization Definition Block +- IVHD - AMD I/O Virtualization Hardware Definition + +What is Intel RMRR? +^^^^^^^^^^^^^^^^^^^ + +There are some devices the BIOS controls, for e.g USB devices to perform +PS2 emulation. The regions of memory used for these devices are marked +reserved in the e820 map. When we turn on DMA translation, DMA to those +regions will fail. Hence BIOS uses RMRR to specify these regions along with +devices that need to access these regions. OS is expected to setup +unity mappings for these regions for these devices to access these regions. + +What is AMD IVRS? +^^^^^^^^^^^^^^^^^ + +The architecture defines an ACPI-compatible data structure called an I/O +Virtualization Reporting Structure (IVRS) that is used to convey information +related to I/O virtualization to system software. The IVRS describes the +configuration and capabilities of the IOMMUs contained in the platform as +well as information about the devices that each IOMMU virtualizes. + +The IVRS provides information about the following: + +- IOMMUs present in the platform including their capabilities and proper configuration +- System I/O topology relevant to each IOMMU +- Peripheral devices that cannot be otherwise enumerated +- Memory regions used by SMI/SMM, platform firmware, and platform hardware. These are generally exclusion ranges to be configured by system software. + +How is an I/O Virtual Address (IOVA) generated? +----------------------------------------------- + +Well behaved drivers call dma_map_*() calls before sending command to device +that needs to perform DMA. Once DMA is completed and mapping is no longer +required, driver performs dma_unmap_*() calls to unmap the region. + +Intel Specific Notes +-------------------- + +Graphics Problems? +^^^^^^^^^^^^^^^^^^ + +If you encounter issues with graphics devices, you can try adding +option intel_iommu=igfx_off to turn off the integrated graphics engine. +If this fixes anything, please ensure you file a bug reporting the problem. + +Some exceptions to IOVA +^^^^^^^^^^^^^^^^^^^^^^^ + +Interrupt ranges are not address translated, (0xfee00000 - 0xfeefffff). +The same is true for peer to peer transactions. Hence we reserve the +address from PCI MMIO ranges so they are not allocated for IOVA addresses. + +AMD Specific Notes +------------------ + +Graphics Problems? +^^^^^^^^^^^^^^^^^^ + +If you encounter issues with integrated graphics devices, you can try adding +option iommu=pt to the kernel command line use a 1:1 mapping for the IOMMU. If +this fixes anything, please ensure you file a bug reporting the problem. + +Fault reporting +--------------- +When errors are reported, the IOMMU signals via an interrupt. The fault +reason and device that caused it is printed on the console. + + +Kernel Log Samples +------------------ + +Intel Boot Messages +^^^^^^^^^^^^^^^^^^^ + +Something like this gets printed indicating presence of DMAR tables +in ACPI: + +:: + + ACPI: DMAR (v001 A M I OEMDMAR 0x00000001 MSFT 0x00000097) @ 0x000000007f5b5ef0 + +When DMAR is being processed and initialized by ACPI, prints DMAR locations +and any RMRR's processed: + +:: + + ACPI DMAR:Host address width 36 + ACPI DMAR:DRHD (flags: 0x00000000)base: 0x00000000fed90000 + ACPI DMAR:DRHD (flags: 0x00000000)base: 0x00000000fed91000 + ACPI DMAR:DRHD (flags: 0x00000001)base: 0x00000000fed93000 + ACPI DMAR:RMRR base: 0x00000000000ed000 end: 0x00000000000effff + ACPI DMAR:RMRR base: 0x000000007f600000 end: 0x000000007fffffff + +When DMAR is enabled for use, you will notice: + +:: + + PCI-DMA: Using DMAR IOMMU + +Intel Fault reporting +^^^^^^^^^^^^^^^^^^^^^ + +:: + + DMAR:[DMA Write] Request device [00:02.0] fault addr 6df084000 + DMAR:[fault reason 05] PTE Write access is not set + DMAR:[DMA Write] Request device [00:02.0] fault addr 6df084000 + DMAR:[fault reason 05] PTE Write access is not set + +AMD Boot Messages +^^^^^^^^^^^^^^^^^ + +Something like this gets printed indicating presence of the IOMMU: + +:: + + iommu: Default domain type: Translated + iommu: DMA domain TLB invalidation policy: lazy mode + +AMD Fault reporting +^^^^^^^^^^^^^^^^^^^ + +:: + + AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0007 address=0xffffc02000 flags=0x0000] + AMD-Vi: Event logged [IO_PAGE_FAULT device=07:00.0 domain=0x0007 address=0xffffc02000 flags=0x0000] -- cgit From 7a5ae564198d536a53bb11ed0eb6679ee0fced10 Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda Date: Wed, 20 Apr 2022 17:42:44 +0900 Subject: dt-bindings: power: renesas,rcar-sysc: Document r8a779g0 SYSC bindings Document bindings for the R-Car V4H (aka R8A779G0) SYSC block. Signed-off-by: Yoshihiro Shimoda Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220420084255.375700-5-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml index 62a49ca319ec..72039401af3d 100644 --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml @@ -42,6 +42,7 @@ properties: - renesas,r8a77995-sysc # R-Car D3 - renesas,r8a779a0-sysc # R-Car V3U - renesas,r8a779f0-sysc # R-Car S4-8 + - renesas,r8a779g0-sysc # R-Car V4H reg: maxItems: 1 -- cgit From 358d1cef2a88f590a183a0357b944674097ec0ab Mon Sep 17 00:00:00 2001 From: Phil Edworthy Date: Wed, 30 Mar 2022 16:40:12 +0100 Subject: dt-bindings: arm: renesas: Document Renesas RZ/V2M SoC and EVK board Details of the SoC can be found here: https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-cortex-a-mpus/rzv2m-dual-cortex-a53-lpddr4x32bit-ai-accelerator-isp-4k-video-codec-4k-camera-input-fhd-display-output The RZ/V2M Evaluation Kit (V2MEVK) consists of the RZ/V2M Main Board, RZ/V2M Base Board, and CIS IMX415 Board (CIS). Signed-off-by: Phil Edworthy Reviewed-by: Biju Das Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220330154024.112270-2-phil.edworthy@renesas.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/arm/renesas.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index 5408b154d05e..ff80152f092f 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -444,6 +444,12 @@ properties: - renesas,r9a07g054l2 # Dual Cortex-A55 RZ/V2L - const: renesas,r9a07g054 + - description: RZ/V2M (R9A09G011) + items: + - enum: + - renesas,rzv2mevk2 # RZ/V2M Eval Board v2.0 + - const: renesas,r9a09g011 + additionalProperties: true ... -- cgit From 67b97e58423247b4c7ae1b639ccfef4dddf8a8fa Mon Sep 17 00:00:00 2001 From: Tiezhu Yang Date: Thu, 28 Apr 2022 17:55:52 +0800 Subject: bpf, docs: Remove duplicated word "instructions" The word "instructions" is duplicated, remove it. Signed-off-by: Tiezhu Yang Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/1651139754-4838-2-git-send-email-yangtiezhu@loongson.cn --- Documentation/bpf/instruction-set.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst index 5300837ac2c9..30b019c595ba 100644 --- a/Documentation/bpf/instruction-set.rst +++ b/Documentation/bpf/instruction-set.rst @@ -130,7 +130,7 @@ Byte swap instructions The byte swap instructions use an instruction class of ``BFP_ALU`` and a 4-bit code field of ``BPF_END``. -The byte swap instructions instructions operate on the destination register +The byte swap instructions operate on the destination register only and do not use a separate source register or immediate value. The 1-bit source operand field in the opcode is used to to select what byte -- cgit From c821d80bb890b1a8220e278984f3c64f5fd9adf9 Mon Sep 17 00:00:00 2001 From: Tiezhu Yang Date: Thu, 28 Apr 2022 17:55:53 +0800 Subject: bpf, docs: BPF_FROM_BE exists as alias for BPF_TO_BE According to include/uapi/linux/bpf.h: #define BPF_FROM_LE BPF_TO_LE #define BPF_FROM_BE BPF_TO_BE BPF_FROM_BE exists as alias for BPF_TO_BE instead of BPF_TO_LE. Signed-off-by: Tiezhu Yang Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/1651139754-4838-3-git-send-email-yangtiezhu@loongson.cn --- Documentation/bpf/instruction-set.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst index 30b019c595ba..00b080056d0e 100644 --- a/Documentation/bpf/instruction-set.rst +++ b/Documentation/bpf/instruction-set.rst @@ -157,7 +157,7 @@ Examples: dst_reg = htobe64(dst_reg) ``BPF_FROM_LE`` and ``BPF_FROM_BE`` exist as aliases for ``BPF_TO_LE`` and -``BPF_TO_LE`` respetively. +``BPF_TO_BE`` respetively. Jump instructions -- cgit From 9a9a90ca1327024f669b670b02f61021306033dc Mon Sep 17 00:00:00 2001 From: Tiezhu Yang Date: Thu, 28 Apr 2022 17:55:54 +0800 Subject: bpf, docs: Fix typo "respetively" to "respectively" "respetively" should be "respectively". Signed-off-by: Tiezhu Yang Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/1651139754-4838-4-git-send-email-yangtiezhu@loongson.cn --- Documentation/bpf/instruction-set.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst index 00b080056d0e..1de6a57c7e1e 100644 --- a/Documentation/bpf/instruction-set.rst +++ b/Documentation/bpf/instruction-set.rst @@ -157,7 +157,7 @@ Examples: dst_reg = htobe64(dst_reg) ``BPF_FROM_LE`` and ``BPF_FROM_BE`` exist as aliases for ``BPF_TO_LE`` and -``BPF_TO_BE`` respetively. +``BPF_TO_BE`` respectively. Jump instructions -- cgit From eb5e26a491d17f520921b7e236b3bf0520553542 Mon Sep 17 00:00:00 2001 From: Nuno Sá Date: Mon, 4 Apr 2022 10:49:59 +0200 Subject: dt-bindings: iio: dac: change ad3552r maintainer MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As the maintainer email no longer exists, change it to myself. Signed-off-by: Nuno Sá Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220404085000.249423-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml index 501a463e5d88..9c48c76993fe 100644 --- a/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Analog Devices AD2552R DAC device driver maintainers: - - Mihail Chindris + - Nuno Sá description: | Bindings for the Analog Devices AD3552R DAC device and similar. -- cgit From 180ab171616119a1343924db1e281c48bfbee6be Mon Sep 17 00:00:00 2001 From: Lorenzo Bianconi Date: Mon, 4 Apr 2022 21:24:44 +0200 Subject: dt-bindings: iio: imu: st_lsm6dsx: add asm330lhhx device bindings Add device bindings for asm330lhhx IMU sensor. Use lsm6dsr as fallback device for asm330lhhx since it implements all the features currently supported by asm330lhhx. Signed-off-by: Lorenzo Bianconi Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/2e5304b7e11085d4e701b4b591fd79cc54f01301.1649100168.git.lorenzo@kernel.org Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/imu/st,lsm6dsx.yaml | 38 ++++++++++++---------- 1 file changed, 21 insertions(+), 17 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml index 0750f700a143..5d4839f00898 100644 --- a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml +++ b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml @@ -14,23 +14,27 @@ description: properties: compatible: - enum: - - st,lsm6ds3 - - st,lsm6ds3h - - st,lsm6dsl - - st,lsm6dsm - - st,ism330dlc - - st,lsm6dso - - st,asm330lhh - - st,lsm6dsox - - st,lsm6dsr - - st,lsm6ds3tr-c - - st,ism330dhcx - - st,lsm9ds1-imu - - st,lsm6ds0 - - st,lsm6dsrx - - st,lsm6dst - - st,lsm6dsop + oneOf: + - enum: + - st,lsm6ds3 + - st,lsm6ds3h + - st,lsm6dsl + - st,lsm6dsm + - st,ism330dlc + - st,lsm6dso + - st,asm330lhh + - st,lsm6dsox + - st,lsm6dsr + - st,lsm6ds3tr-c + - st,ism330dhcx + - st,lsm9ds1-imu + - st,lsm6ds0 + - st,lsm6dsrx + - st,lsm6dst + - st,lsm6dsop + - items: + - const: st,asm330lhhx + - const: st,lsm6dsr reg: maxItems: 1 -- cgit From 42763b249aaa0ec8950b433c3cbed021c9779a95 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Sat, 23 Apr 2022 14:16:54 +0100 Subject: dt-bindings: iio: adc: Document Renesas RZ/V2L ADC Document renesas RZ/V2L ADC bindings. RZ/V2L ADC is identical to RZ/G2L with same number of channels. While at it remove RZ/G2LC SoC from binding documentation as it does not support ADC. Signed-off-by: Biju Das Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220423131654.131390-1-biju.das.jz@bp.renesas.com Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml b/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml index c80201d6a716..d66c24cae1e1 100644 --- a/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml @@ -19,7 +19,8 @@ properties: compatible: items: - enum: - - renesas,r9a07g044-adc # RZ/G2{L,LC} + - renesas,r9a07g044-adc # RZ/G2L + - renesas,r9a07g054-adc # RZ/V2L - const: renesas,rzg2l-adc reg: -- cgit From b71b538b477f4ab7bb8bf39d1fa40e9f296df8b6 Mon Sep 17 00:00:00 2001 From: Arnaud Ferraris Date: Wed, 20 Apr 2022 13:25:39 +0200 Subject: dt-bindings: iio: light: stk33xx: Add proximity-near-level This allows exporting the value from which userspace should assert an object is "near". Signed-off-by: Arnaud Ferraris Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220420112540.91907-2-arnaud.ferraris@collabora.com Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/light/stk33xx.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/light/stk33xx.yaml b/Documentation/devicetree/bindings/iio/light/stk33xx.yaml index f92bf7b2b7f0..f6e22dc9814a 100644 --- a/Documentation/devicetree/bindings/iio/light/stk33xx.yaml +++ b/Documentation/devicetree/bindings/iio/light/stk33xx.yaml @@ -13,6 +13,9 @@ maintainers: description: | Ambient light and proximity sensor over an i2c interface. +allOf: + - $ref: ../common.yaml# + properties: compatible: enum: @@ -26,6 +29,8 @@ properties: interrupts: maxItems: 1 + proximity-near-level: true + required: - compatible - reg @@ -44,6 +49,7 @@ examples: stk3310@48 { compatible = "sensortek,stk3310"; reg = <0x48>; + proximity-near-level = <25>; interrupt-parent = <&gpio1>; interrupts = <5 IRQ_TYPE_LEVEL_LOW>; }; -- cgit From 392eeccc3b593558694f7caaf855bc2b827c5b0b Mon Sep 17 00:00:00 2001 From: Cixi Geng Date: Tue, 19 Apr 2022 22:24:52 +0800 Subject: dt-bindings:iio:adc: add sprd,ump9620-adc dt-binding sprd,ump9620-adc is one variant of sc27xx series, add ump9620 description and sample in dt-bindings. Signed-off-by: Cixi Geng Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220419142458.884933-2-gengcixi@gmail.com Signed-off-by: Jonathan Cameron --- .../bindings/iio/adc/sprd,sc2720-adc.yaml | 60 +++++++++++++++++++--- 1 file changed, 54 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/sprd,sc2720-adc.yaml b/Documentation/devicetree/bindings/iio/adc/sprd,sc2720-adc.yaml index caa3ee0b4b8c..44aa28b59197 100644 --- a/Documentation/devicetree/bindings/iio/adc/sprd,sc2720-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/sprd,sc2720-adc.yaml @@ -20,6 +20,7 @@ properties: - sprd,sc2723-adc - sprd,sc2730-adc - sprd,sc2731-adc + - sprd,ump9620-adc reg: maxItems: 1 @@ -33,13 +34,39 @@ properties: hwlocks: maxItems: 1 - nvmem-cells: - maxItems: 2 + nvmem-cells: true - nvmem-cell-names: - items: - - const: big_scale_calib - - const: small_scale_calib + nvmem-cell-names: true + +allOf: + - if: + not: + properties: + compatible: + contains: + enum: + - sprd,ump9620-adc + then: + properties: + nvmem-cells: + maxItems: 2 + nvmem-cell-names: + items: + - const: big_scale_calib + - const: small_scale_calib + + else: + properties: + nvmem-cells: + maxItems: 6 + nvmem-cell-names: + items: + - const: big_scale_calib1 + - const: big_scale_calib2 + - const: small_scale_calib1 + - const: small_scale_calib2 + - const: vbat_det_cal1 + - const: vbat_det_cal2 required: - compatible @@ -69,4 +96,25 @@ examples: nvmem-cell-names = "big_scale_calib", "small_scale_calib"; }; }; + + - | + #include + pmic { + #address-cells = <1>; + #size-cells = <0>; + adc@504 { + compatible = "sprd,ump9620-adc"; + reg = <0x504>; + interrupt-parent = <&ump9620_pmic>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + #io-channel-cells = <1>; + hwlocks = <&hwlock 4>; + nvmem-cells = <&adc_bcal1>, <&adc_bcal2>, + <&adc_scal1>, <&adc_scal2>, + <&vbat_det_cal1>, <&vbat_det_cal2>; + nvmem-cell-names = "big_scale_calib1", "big_scale_calib2", + "small_scale_calib1", "small_scale_calib2", + "vbat_det_cal1", "vbat_det_cal2"; + }; + }; ... -- cgit From 6d5aa418b3bd42cdccc36e94ee199af423ef7c84 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Wed, 27 Apr 2022 18:28:39 +0900 Subject: docs: submitting-patches: Fix crossref to 'The canonical patch format' The reference to `explicit_in_reply_to` is pointless as when the reference was added in the form of "#15" [1], Section 15) was "The canonical patch format". The reference of "#15" had not been properly updated in a couple of reorganizations during the plain-text SubmittingPatches era. Fix it by using `the_canonical_patch_format`. [1]: 2ae19acaa50a ("Documentation: Add "how to write a good patch summary" to SubmittingPatches") Signed-off-by: Akira Yokosawa Fixes: 5903019b2a5e ("Documentation/SubmittingPatches: convert it to ReST markup") Fixes: 9b2c76777acc ("Documentation/SubmittingPatches: enrich the Sphinx output") Cc: Jonathan Corbet Cc: Mauro Carvalho Chehab Cc: stable@vger.kernel.org # v4.9+ Link: https://lore.kernel.org/r/64e105a5-50be-23f2-6cae-903a2ea98e18@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/process/submitting-patches.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 9bb4e8c0f635..bf5ead743ccf 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -77,7 +77,7 @@ as you intend it to. The maintainer will thank you if you write your patch description in a form which can be easily pulled into Linux's source code management -system, ``git``, as a "commit log". See :ref:`explicit_in_reply_to`. +system, ``git``, as a "commit log". See :ref:`the_canonical_patch_format`. Solve only one problem per patch. If your description starts to get long, that's a sign that you probably need to split up your patch. -- cgit From 10434640b6ebefb3d293775ad6dc983eddaa882c Mon Sep 17 00:00:00 2001 From: Johan Hovold Date: Wed, 27 Apr 2022 09:31:42 +0200 Subject: Documentation: devres: fix typo in interface list Fix the misspelled devm_get_clk_from_child() helper name in the devres interface list. Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20220427073142.16700-1-johan+linaro@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/driver-api/driver-model/devres.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index 5018403fe82f..2d39967bafcc 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -249,7 +249,7 @@ CLOCK devm_clk_bulk_get() devm_clk_bulk_get_all() devm_clk_bulk_get_optional() - devm_get_clk_from_childl() + devm_get_clk_from_child() devm_clk_hw_register() devm_of_clk_add_hw_provider() devm_clk_hw_register_clkdev() -- cgit From e0bd6f14c28f49219196c81d2d7d0c16bb65986e Mon Sep 17 00:00:00 2001 From: Kosuke Fujimoto Date: Mon, 25 Apr 2022 21:48:53 +0900 Subject: docs/ja_JP/index: update section title in Japanese Update section title "Japanese Translation" in Japanese. This change is to keep consistency with other translations. Signed-off-by: Kosuke Fujimoto Cc: Jonathan Corbet Cc: Tsugikazu Shibata Cc: Akira Yokosawa Cc: linux-doc@vger.kernel.org Reviewed-by: Akira Yokosawa Link: https://lore.kernel.org/r/20220425124853.8347-1-fujimotokosuke0@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/translations/ja_JP/index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/translations/ja_JP/index.rst b/Documentation/translations/ja_JP/index.rst index 20738c931d02..43b9fb7246d3 100644 --- a/Documentation/translations/ja_JP/index.rst +++ b/Documentation/translations/ja_JP/index.rst @@ -5,7 +5,7 @@ \kerneldocCJKon \kerneldocBeginJP{ -Japanese translations +日本語訳 ===================== .. toctree:: -- cgit From 59c4eba59f65d24abedb39f68d725c91e15278aa Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Sun, 24 Apr 2022 18:10:49 +0800 Subject: docs/zh_CN: add vm hmm translation Translate .../vm/hmm.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/6248f340dd43097d6517239e1f038165b9fef7cd.1650794774.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/hmm.rst | 361 ++++++++++++++++++++++++++ Documentation/translations/zh_CN/vm/index.rst | 2 +- 2 files changed, 362 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/hmm.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/hmm.rst b/Documentation/translations/zh_CN/vm/hmm.rst new file mode 100644 index 000000000000..2379df95aa58 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/hmm.rst @@ -0,0 +1,361 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/vm/hmm.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + +================== +异构内存管理 (HMM) +================== + +提供基础设施和帮助程序以将非常规内存（设备内存，如板上 GPU 内存）集成到常规内核路径中，其 +基石是此类内存的专用struct page（请参阅本文档的第 5 至 7 节）。 + +HMM 还为 SVM（共享虚拟内存）提供了可选的帮助程序，即允许设备透明地访问与 CPU 一致的程序 +地址，这意味着 CPU 上的任何有效指针也是该设备的有效指针。这对于简化高级异构计算的使用变得 +必不可少，其中 GPU、DSP 或 FPGA 用于代表进程执行各种计算。 + +本文档分为以下部分：在第一部分中，我揭示了与使用特定于设备的内存分配器相关的问题。在第二 +部分中，我揭示了许多平台固有的硬件限制。第三部分概述了 HMM 设计。第四部分解释了 CPU 页 +表镜像的工作原理以及 HMM 在这种情况下的目的。第五部分处理内核中如何表示设备内存。最后， +最后一节介绍了一个新的迁移助手，它允许利用设备 DMA 引擎。 + +.. contents:: :local: + +使用特定于设备的内存分配器的问题 +================================ + +具有大量板载内存（几 GB）的设备（如 GPU）历来通过专用驱动程序特定 API 管理其内存。这会 +造成设备驱动程序分配和管理的内存与常规应用程序内存（私有匿名、共享内存或常规文件支持内存） +之间的隔断。从这里开始，我将把这个方面称为分割的地址空间。我使用共享地址空间来指代相反的情况： +即，设备可以透明地使用任何应用程序内存区域。 + +分割的地址空间的发生是因为设备只能访问通过设备特定 API 分配的内存。这意味着从设备的角度来 +看，程序中的所有内存对象并不平等，这使得依赖于广泛的库的大型程序变得复杂。 + +具体来说，这意味着想要利用像 GPU 这样的设备的代码需要在通用分配的内存（malloc、mmap +私有、mmap 共享）和通过设备驱动程序 API 分配的内存之间复制对象（这仍然以 mmap 结束， +但是是设备文件）。 + +对于平面数据集（数组、网格、图像……），这并不难实现，但对于复杂数据集（列表、树……）， +很难做到正确。复制一个复杂的数据集需要重新映射其每个元素之间的所有指针关系。这很容易出错， +而且由于数据集和地址的重复，程序更难调试。 + +分割地址空间也意味着库不能透明地使用它们从核心程序或另一个库中获得的数据，因此每个库可能 +不得不使用设备特定的内存分配器来重复其输入数据集。大型项目会因此受到影响，并因为各种内存 +拷贝而浪费资源。 + +复制每个库的API以接受每个设备特定分配器分配的内存作为输入或输出，并不是一个可行的选择。 +这将导致库入口点的组合爆炸。 + +最后，随着高级语言结构（在 C++ 中，当然也在其他语言中）的进步，编译器现在有可能在没有程 +序员干预的情况下利用 GPU 和其他设备。某些编译器识别的模式仅适用于共享地址空间。对所有 +其他模式，使用共享地址空间也更合理。 + + +I/O 总线、设备内存特性 +====================== + +由于一些限制，I/O 总线削弱了共享地址空间。大多数 I/O 总线只允许从设备到主内存的基本 +内存访问；甚至缓存一致性通常是可选的。从 CPU 访问设备内存甚至更加有限。通常情况下，它 +不是缓存一致的。 + +如果我们只考虑 PCIE 总线，那么设备可以访问主内存（通常通过 IOMMU）并与 CPU 缓存一 +致。但是，它只允许设备对主存储器进行一组有限的原子操作。这在另一个方向上更糟：CPU +只能访问有限范围的设备内存，而不能对其执行原子操作。因此，从内核的角度来看，设备内存不 +能被视为与常规内存等同。 + +另一个严重的因素是带宽有限（约 32GBytes/s，PCIE 4.0 和 16 通道）。这比最快的 GPU +内存 (1 TBytes/s) 慢 33 倍。最后一个限制是延迟。从设备访问主内存的延迟比设备访问自 +己的内存时高一个数量级。 + +一些平台正在开发新的 I/O 总线或对 PCIE 的添加/修改以解决其中一些限制 +（OpenCAPI、CCIX）。它们主要允许 CPU 和设备之间的双向缓存一致性，并允许架构支持的所 +有原子操作。遗憾的是，并非所有平台都遵循这一趋势，并且一些主要架构没有针对这些问题的硬 +件解决方案。 + +因此，为了使共享地址空间有意义，我们不仅必须允许设备访问任何内存，而且还必须允许任何内 +存在设备使用时迁移到设备内存（在迁移时阻止 CPU 访问）。 + + +共享地址空间和迁移 +================== + +HMM 打算提供两个主要功能。第一个是通过复制cpu页表到设备页表中来共享地址空间，因此对 +于进程地址空间中的任何有效主内存地址，相同的地址指向相同的物理内存。 + +为了实现这一点，HMM 提供了一组帮助程序来填充设备页表，同时跟踪 CPU 页表更新。设备页表 +更新不像 CPU 页表更新那么容易。要更新设备页表，您必须分配一个缓冲区（或使用预先分配的 +缓冲区池）并在其中写入 GPU 特定命令以执行更新（取消映射、缓存失效和刷新等）。这不能通 +过所有设备的通用代码来完成。因此，为什么HMM提供了帮助器，在把硬件的具体细节留给设备驱 +动程序的同时，把一切可以考虑的因素都考虑进去了。 + +HMM 提供的第二种机制是一种新的 ZONE_DEVICE 内存，它允许为设备内存的每个页面分配一个 +struct page。这些页面很特殊，因为 CPU 无法映射它们。然而，它们允许使用现有的迁移机 +制将主内存迁移到设备内存，从 CPU 的角度来看，一切看起来都像是换出到磁盘的页面。使用 +struct page可以与现有的 mm 机制进行最简单、最干净的集成。再次，HMM 仅提供帮助程序， +首先为设备内存热插拔新的 ZONE_DEVICE 内存，然后执行迁移。迁移内容和时间的策略决定留 +给设备驱动程序。 + +请注意，任何 CPU 对设备页面的访问都会触发缺页异常并迁移回主内存。例如，当支持给定CPU +地址 A 的页面从主内存页面迁移到设备页面时，对地址 A 的任何 CPU 访问都会触发缺页异常 +并启动向主内存的迁移。 + +凭借这两个特性，HMM 不仅允许设备镜像进程地址空间并保持 CPU 和设备页表同步，而且还通 +过迁移设备正在使用的数据集部分来利用设备内存。 + + +地址空间镜像实现和API +===================== + +地址空间镜像的主要目标是允许将一定范围的 CPU 页表复制到一个设备页表中；HMM 有助于 +保持两者同步。想要镜像进程地址空间的设备驱动程序必须从注册 mmu_interval_notifier +开始:: + + int mmu_interval_notifier_insert(struct mmu_interval_notifier *interval_sub, + struct mm_struct *mm, unsigned long start, + unsigned long length, + const struct mmu_interval_notifier_ops *ops); + +在 ops->invalidate() 回调期间，设备驱动程序必须对范围执行更新操作（将范围标记为只 +读，或完全取消映射等）。设备必须在驱动程序回调返回之前完成更新。 + +当设备驱动程序想要填充一个虚拟地址范围时，它可以使用:: + + int hmm_range_fault(struct hmm_range *range); + +如果请求写访问，它将在丢失或只读条目上触发缺页异常（见下文）。缺页异常使用通用的 mm 缺 +页异常代码路径，就像 CPU 缺页异常一样。 + +这两个函数都将 CPU 页表条目复制到它们的 pfns 数组参数中。该数组中的每个条目对应于虚拟 +范围中的一个地址。HMM 提供了一组标志来帮助驱动程序识别特殊的 CPU 页表项。 + +在 sync_cpu_device_pagetables() 回调中锁定是驱动程序必须尊重的最重要的方面，以保 +持事物正确同步。使用模式是:: + + int driver_populate_range(...) + { + struct hmm_range range; + ... + + range.notifier = &interval_sub; + range.start = ...; + range.end = ...; + range.hmm_pfns = ...; + + if (!mmget_not_zero(interval_sub->notifier.mm)) + return -EFAULT; + + again: + range.notifier_seq = mmu_interval_read_begin(&interval_sub); + mmap_read_lock(mm); + ret = hmm_range_fault(&range); + if (ret) { + mmap_read_unlock(mm); + if (ret == -EBUSY) + goto again; + return ret; + } + mmap_read_unlock(mm); + + take_lock(driver->update); + if (mmu_interval_read_retry(&ni, range.notifier_seq) { + release_lock(driver->update); + goto again; + } + + /* Use pfns array content to update device page table, + * under the update lock */ + + release_lock(driver->update); + return 0; + } + +driver->update 锁与驱动程序在其 invalidate() 回调中使用的锁相同。该锁必须在调用 +mmu_interval_read_retry() 之前保持，以避免与并发 CPU 页表更新发生任何竞争。 + +利用 default_flags 和 pfn_flags_mask +==================================== + +hmm_range 结构有 2 个字段，default_flags 和 pfn_flags_mask，它们指定整个范围 +的故障或快照策略，而不必为 pfns 数组中的每个条目设置它们。 + +例如，如果设备驱动程序需要至少具有读取权限的范围的页面，它会设置:: + + range->default_flags = HMM_PFN_REQ_FAULT; + range->pfn_flags_mask = 0; + +并如上所述调用 hmm_range_fault()。这将填充至少具有读取权限的范围内的所有页面。 + +现在假设驱动程序想要做同样的事情，除了它想要拥有写权限的范围内的一页。现在驱动程序设 +置:: + + range->default_flags = HMM_PFN_REQ_FAULT; + range->pfn_flags_mask = HMM_PFN_REQ_WRITE; + range->pfns[index_of_write] = HMM_PFN_REQ_WRITE; + +有了这个，HMM 将在至少读取（即有效）的所有页面中异常，并且对于地址 +== range->start + (index_of_write << PAGE_SHIFT) 它将异常写入权限，即，如果 +CPU pte 没有设置写权限，那么HMM将调用handle_mm_fault()。 + +hmm_range_fault 完成后，标志位被设置为页表的当前状态，即 HMM_PFN_VALID | 如果页 +面可写，将设置 HMM_PFN_WRITE。 + + +从核心内核的角度表示和管理设备内存 +================================== + +尝试了几种不同的设计来支持设备内存。第一个使用特定于设备的数据结构来保存有关迁移内存 +的信息，HMM 将自身挂接到 mm 代码的各个位置，以处理对设备内存支持的地址的任何访问。 +事实证明，这最终复制了 struct page 的大部分字段，并且还需要更新许多内核代码路径才 +能理解这种新的内存类型。 + +大多数内核代码路径从不尝试访问页面后面的内存，而只关心struct page的内容。正因为如此， +HMM 切换到直接使用 struct page 用于设备内存，这使得大多数内核代码路径不知道差异。 +我们只需要确保没有人试图从 CPU 端映射这些页面。 + +移入和移出设备内存 +================== + +由于 CPU 无法直接访问设备内存，因此设备驱动程序必须使用硬件 DMA 或设备特定的加载/存 +储指令来迁移数据。migrate_vma_setup()、migrate_vma_pages() 和 +migrate_vma_finalize() 函数旨在使驱动程序更易于编写并集中跨驱动程序的通用代码。 + +在将页面迁移到设备私有内存之前，需要创建特殊的设备私有 ``struct page`` 。这些将用 +作特殊的“交换”页表条目，以便 CPU 进程在尝试访问已迁移到设备专用内存的页面时会发生异常。 + +这些可以通过以下方式分配和释放:: + + struct resource *res; + struct dev_pagemap pagemap; + + res = request_free_mem_region(&iomem_resource, /* number of bytes */, + "name of driver resource"); + pagemap.type = MEMORY_DEVICE_PRIVATE; + pagemap.range.start = res->start; + pagemap.range.end = res->end; + pagemap.nr_range = 1; + pagemap.ops = &device_devmem_ops; + memremap_pages(&pagemap, numa_node_id()); + + memunmap_pages(&pagemap); + release_mem_region(pagemap.range.start, range_len(&pagemap.range)); + +还有devm_request_free_mem_region(), devm_memremap_pages(), +devm_memunmap_pages() 和 devm_release_mem_region() 当资源可以绑定到 ``struct device``. + +整体迁移步骤类似于在系统内存中迁移 NUMA 页面(see :ref:`Page migration `) ， +但这些步骤分为设备驱动程序特定代码和共享公共代码: + +1. ``mmap_read_lock()`` + + 设备驱动程序必须将 ``struct vm_area_struct`` 传递给migrate_vma_setup()， + 因此需要在迁移期间保留 mmap_read_lock() 或 mmap_write_lock()。 + +2. ``migrate_vma_setup(struct migrate_vma *args)`` + + 设备驱动初始化了 ``struct migrate_vma`` 的字段，并将该指针传递给 + migrate_vma_setup()。``args->flags`` 字段是用来过滤哪些源页面应该被迁移。 + 例如，设置 ``MIGRATE_VMA_SELECT_SYSTEM`` 将只迁移系统内存，设置 + ``MIGRATE_VMA_SELECT_DEVICE_PRIVATE`` 将只迁移驻留在设备私有内存中的页 + 面。如果后者被设置， ``args->pgmap_owner`` 字段被用来识别驱动所拥有的设备 + 私有页。这就避免了试图迁移驻留在其他设备中的设备私有页。目前，只有匿名的私有VMA + 范围可以被迁移到系统内存和设备私有内存。 + + migrate_vma_setup()所做的第一步是用 ``mmu_notifier_invalidate_range_start()`` + 和 ``mmu_notifier_invalidate_range_end()`` 调用来遍历设备周围的页表，使 + 其他设备的MMU无效，以便在 ``args->src`` 数组中填写要迁移的PFN。 + ``invalidate_range_start()`` 回调传递给一个``struct mmu_notifier_range`` ， + 其 ``event`` 字段设置为MMU_NOTIFY_MIGRATE， ``owner`` 字段设置为传递给 + migrate_vma_setup()的 ``args->pgmap_owner`` 字段。这允许设备驱动跳过无 + 效化回调，只无效化那些实际正在迁移的设备私有MMU映射。这一点将在下一节详细解释。 + + + 在遍历页表时，一个 ``pte_none()`` 或 ``is_zero_pfn()`` 条目导致一个有效 + 的 “zero” PFN 存储在 ``args->src`` 阵列中。这让驱动分配设备私有内存并清 + 除它，而不是复制一个零页。到系统内存或设备私有结构页的有效PTE条目将被 + ``lock_page()``锁定，与LRU隔离（如果系统内存和设备私有页不在LRU上），从进 + 程中取消映射，并插入一个特殊的迁移PTE来代替原来的PTE。 migrate_vma_setup() + 还清除了 ``args->dst`` 数组。 + +3. 设备驱动程序分配目标页面并将源页面复制到目标页面。 + + 驱动程序检查每个 ``src`` 条目以查看该 ``MIGRATE_PFN_MIGRATE`` 位是否已 + 设置并跳过未迁移的条目。设备驱动程序还可以通过不填充页面的 ``dst`` 数组来选 + 择跳过页面迁移。 + + 然后，驱动程序分配一个设备私有 struct page 或一个系统内存页，用 ``lock_page()`` + 锁定该页，并将 ``dst`` 数组条目填入:: + + dst[i] = migrate_pfn(page_to_pfn(dpage)); + + 现在驱动程序知道这个页面正在被迁移，它可以使设备私有 MMU 映射无效并将设备私有 + 内存复制到系统内存或另一个设备私有页面。由于核心 Linux 内核会处理 CPU 页表失 + 效，因此设备驱动程序只需使其自己的 MMU 映射失效。 + + 驱动程序可以使用 ``migrate_pfn_to_page(src[i])`` 来获取源设备的 + ``struct page`` 面，并将源页面复制到目标设备上，如果指针为 ``NULL`` ，意 + 味着源页面没有被填充到系统内存中，则清除目标设备的私有内存。 + +4. ``migrate_vma_pages()`` + + 这一步是实际“提交”迁移的地方。 + + 如果源页是 ``pte_none()`` 或 ``is_zero_pfn()`` 页，这时新分配的页会被插 + 入到CPU的页表中。如果一个CPU线程在同一页面上发生异常，这可能会失败。然而，页 + 表被锁定，只有一个新页会被插入。如果它失去了竞争，设备驱动将看到 + ``MIGRATE_PFN_MIGRATE`` 位被清除。 + + 如果源页被锁定、隔离等，源 ``struct page`` 信息现在被复制到目标 + ``struct page`` ，最终完成CPU端的迁移。 + +5. 设备驱动为仍在迁移的页面更新设备MMU页表，回滚未迁移的页面。 + + 如果 ``src`` 条目仍然有 ``MIGRATE_PFN_MIGRATE`` 位被设置，设备驱动可以 + 更新设备MMU，如果 ``MIGRATE_PFN_WRITE`` 位被设置，则设置写启用位。 + +6. ``migrate_vma_finalize()`` + + 这一步用新页的页表项替换特殊的迁移页表项，并释放对源和目的 ``struct page`` + 的引用。 + +7. ``mmap_read_unlock()`` + + 现在可以释放锁了。 + +独占访问存储器 +============== + +一些设备具有诸如原子PTE位的功能，可以用来实现对系统内存的原子访问。为了支持对一 +个共享的虚拟内存页的原子操作，这样的设备需要对该页的访问是排他的，而不是来自CPU +的任何用户空间访问。 ``make_device_exclusive_range()`` 函数可以用来使一 +个内存范围不能从用户空间访问。 + +这将用特殊的交换条目替换给定范围内的所有页的映射。任何试图访问交换条目的行为都会 +导致一个异常，该异常会通过用原始映射替换该条目而得到恢复。驱动程序会被通知映射已 +经被MMU通知器改变，之后它将不再有对该页的独占访问。独占访问被保证持续到驱动程序 +放弃页面锁和页面引用为止，这时页面上的任何CPU异常都可以按所述进行。 + +内存 cgroup (memcg) 和 rss 统计 +=============================== + +目前，设备内存被视为 rss 计数器中的任何常规页面（如果设备页面用于匿名，则为匿名， +如果设备页面用于文件支持页面，则为文件，如果设备页面用于共享内存，则为 shmem）。 +这是为了保持现有应用程序的故意选择，这些应用程序可能在不知情的情况下开始使用设备 +内存，运行不受影响。 + +一个缺点是 OOM 杀手可能会杀死使用大量设备内存而不是大量常规系统内存的应用程序， +因此不会释放太多系统内存。在决定以不同方式计算设备内存之前，我们希望收集更多关 +于应用程序和系统在存在设备内存的情况下在内存压力下如何反应的实际经验。 + +对内存 cgroup 做出了相同的决定。设备内存页面根据相同的内存 cgroup 计算，常规 +页面将被计算在内。这确实简化了进出设备内存的迁移。这也意味着从设备内存迁移回常规 +内存不会失败，因为它会超过内存 cgroup 限制。一旦我们对设备内存的使用方式及其对 +内存资源控制的影响有了更多的了解，我们可能会在后面重新考虑这个选择。 + +请注意，设备内存永远不能由设备驱动程序或通过 GUP 固定，因此此类内存在进程退出时 +总是被释放的。或者在共享内存或文件支持内存的情况下，当删除最后一个引用时。 diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index 61cd39cefdcf..0839b2231548 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -28,6 +28,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） highmem ksm frontswap + hmm hwpoison hugetlbfs_reserv memory-model @@ -44,7 +45,6 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） TODOLIST: * arch_pgtable_helpers * free_page_reporting -* hmm * hugetlbfs_reserv * numa * page_migration -- cgit From f5cc416384d82d5201e9a066b5686cc38ddb2f00 Mon Sep 17 00:00:00 2001 From: Yanteng Si Date: Sun, 24 Apr 2022 18:10:50 +0800 Subject: docs/zh_CN: add vm numa translation Translate .../vm/numa.rst into Chinese. Signed-off-by: Yanteng Si Reviewed-by: Alex Shi Link: https://lore.kernel.org/r/65e5a38c3112fb1f9e126f1807fda2724ebf3312.1650794774.git.siyanteng@loongson.cn Signed-off-by: Jonathan Corbet --- Documentation/translations/zh_CN/vm/index.rst | 2 +- Documentation/translations/zh_CN/vm/numa.rst | 101 ++++++++++++++++++++++++++ 2 files changed, 102 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/vm/numa.rst (limited to 'Documentation') diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst index 0839b2231548..a1c6d529b6ff 100644 --- a/Documentation/translations/zh_CN/vm/index.rst +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -33,6 +33,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处） hugetlbfs_reserv memory-model mmu_notifier + numa overcommit-accounting page_frags page_owner @@ -46,7 +47,6 @@ TODOLIST: * arch_pgtable_helpers * free_page_reporting * hugetlbfs_reserv -* numa * page_migration * slub * transhuge diff --git a/Documentation/translations/zh_CN/vm/numa.rst b/Documentation/translations/zh_CN/vm/numa.rst new file mode 100644 index 000000000000..6af412b924ad --- /dev/null +++ b/Documentation/translations/zh_CN/vm/numa.rst @@ -0,0 +1,101 @@ +:Original: Documentation/vm/numa.rst + +:翻译: + + 司延腾 Yanteng Si + +:校译: + + +始于1999年11月，作者： + +========================== +何为非统一内存访问(NUMA)？ +========================== + +这个问题可以从几个视角来回答：硬件观点和Linux软件视角。 + +从硬件角度看，NUMA系统是一个由多个组件或装配组成的计算机平台，每个组件可能包含0个或更多的CPU、 +本地内存和/或IO总线。为了简洁起见，并将这些物理组件/装配的硬件视角与软件抽象区分开来，我们在 +本文中称这些组件/装配为“单元”。 + +每个“单元”都可以看作是系统的一个SMP[对称多处理器]子集——尽管独立的SMP系统所需的一些组件可能 +不会在任何给定的单元上填充。NUMA系统的单元通过某种系统互连连接在一起——例如，交叉开关或点对点 +链接是NUMA系统互连的常见类型。这两种类型的互连都可以聚合起来，以创建NUMA平台，其中的单元与其 +他单元有多个距离。 + +对于Linux，感兴趣的NUMA平台主要是所谓的缓存相干NUMA--简称ccNUMA系统系统。在ccNUMA系统中， +所有的内存都是可见的，并且可以从连接到任何单元的任何CPU中访问，缓存一致性是由处理器缓存和/或 +系统互连在硬件中处理。 + +内存访问时间和有效的内存带宽取决于包含CPU的单元或进行内存访问的IO总线距离包含目标内存的单元 +有多远。例如，连接到同一单元的CPU对内存的访问将比访问其他远程单元的内存经历更快的访问时间和 +更高的带宽。 NUMA平台可以在任何给定单元上访问多种远程距离的（其他）单元。 + +平台供应商建立NUMA系统并不只是为了让软件开发人员的生活变得有趣。相反，这种架构是提供可扩展 +内存带宽的一种手段。然而，为了实现可扩展的内存带宽，系统和应用软件必须安排大部分的内存引用 +[cache misses]到“本地”内存——同一单元的内存，如果有的话——或者到最近的有内存的单元。 + +这就自然而然有了Linux软件对NUMA系统的视角: + +Linux将系统的硬件资源划分为多个软件抽象，称为“节点”。Linux将节点映射到硬件平台的物理单元 +上，对一些架构的细节进行了抽象。与物理单元一样，软件节点可能包含0或更多的CPU、内存和/或IO +总线。同样，对“较近”节点的内存访问——映射到较近单元的节点——通常会比对较远单元的访问经历更快 +的访问时间和更高的有效带宽。 + +对于一些架构，如x86，Linux将“隐藏”任何代表没有内存连接的物理单元的节点，并将连接到该单元 +的任何CPU重新分配到代表有内存的单元的节点上。因此，在这些架构上，我们不能假设Linux将所有 +的CPU与一个给定的节点相关联，会看到相同的本地内存访问时间和带宽。 + +此外，对于某些架构，同样以x86为例，Linux支持对额外节点的仿真。对于NUMA仿真，Linux会将现 +有的节点或者非NUMA平台的系统内存分割成多个节点。每个模拟的节点将管理底层单元物理内存的一部 +分。NUMA仿真对于在非NUMA平台上测试NUMA内核和应用功能是非常有用的，当与cpusets一起使用时， +可以作为一种内存资源管理机制。[见 Documentation/admin-guide/cgroup-v1/cpusets.rst] + +对于每个有内存的节点，Linux构建了一个独立的内存管理子系统，有自己的空闲页列表、使用中页列表、 +使用统计和锁来调解访问。此外，Linux为每个内存区[DMA、DMA32、NORMAL、HIGH_MEMORY、MOVABLE +中的一个或多个]构建了一个有序的“区列表”。zonelist指定了当一个选定的区/节点不能满足分配请求 +时要访问的区/节点。当一个区没有可用的内存来满足请求时，这种情况被称为“overflow 溢出”或 +“fallback 回退”。 + +由于一些节点包含多个包含不同类型内存的区，Linux必须决定是否对区列表进行排序，使分配回退到不同 +节点上的相同区类型，或同一节点上的不同区类型。这是一个重要的考虑因素，因为有些区，如DMA或DMA32， +代表了相对稀缺的资源。Linux选择了一个默认的Node ordered zonelist。这意味着在使用按NUMA距 +离排序的远程节点之前，它会尝试回退到同一节点的其他分区。 + +默认情况下，Linux会尝试从执行请求的CPU被分配到的节点中满足内存分配请求。具体来说，Linux将试 +图从请求来源的节点的适当分区列表中的第一个节点进行分配。这被称为“本地分配”。如果“本地”节点不能 +满足请求，内核将检查所选分区列表中其他节点的区域，寻找列表中第一个能满足请求的区域。 + +本地分配将倾向于保持对分配的内存的后续访问 “本地”的底层物理资源和系统互连——只要内核代表其分配 +一些内存的任务后来不从该内存迁移。Linux调度器知道平台的NUMA拓扑结构——体现在“调度域”数据结构 +中[见 Documentation/scheduler/sched-domains.rst]——并且调度器试图尽量减少任务迁移到遥 +远的调度域中。然而，调度器并没有直接考虑到任务的NUMA足迹。因此，在充分不平衡的情况下，任务可 +以在节点之间迁移，远离其初始节点和内核数据结构。 + +系统管理员和应用程序设计者可以使用各种CPU亲和命令行接口，如taskset(1)和numactl(1)，以及程 +序接口，如sched_setaffinity(2)，来限制任务的迁移，以改善NUMA定位。此外，人们可以使用 +Linux NUMA内存策略修改内核的默认本地分配行为。 [见 +:ref:`Documentation/admin-guide/mm/numa_memory_policy.rst `]. + +系统管理员可以使用控制组和CPUsets限制非特权用户在调度或NUMA命令和功能中可以指定的CPU和节点 +的内存。 [见 Documentation/admin-guide/cgroup-v1/cpusets.rst] + +在不隐藏无内存节点的架构上，Linux会在分区列表中只包括有内存的区域[节点]。这意味着对于一个无 +内存的节点，“本地内存节点”——CPU节点的分区列表中的第一个区域的节点——将不是节点本身。相反，它 +将是内核在建立分区列表时选择的离它最近的有内存的节点。所以，默认情况下，本地分配将由内核提供 +最近的可用内存来完成。这是同一机制的结果，该机制允许这种分配在一个包含内存的节点溢出时回退到 +其他附近的节点。 + +一些内核分配不希望或不能容忍这种分配回退行为。相反，他们想确保他们从指定的节点获得内存，或者 +得到通知说该节点没有空闲内存。例如，当一个子系统分配每个CPU的内存资源时，通常是这种情况。 + +一个典型的分配模式是使用内核的numa_node_id()或CPU_to_node()函数获得“当前CPU”所在节点的 +节点ID，然后只从返回的节点ID请求内存。当这样的分配失败时，请求的子系统可以恢复到它自己的回退 +路径。板块内核内存分配器就是这样的一个例子。或者，子系统可以选择在分配失败时禁用或不启用自己。 +内核分析子系统就是这样的一个例子。 + +如果架构支持——不隐藏无内存节点，那么连接到无内存节点的CPU将总是产生回退路径的开销，或者一些 +子系统如果试图完全从无内存的节点分配内存，将无法初始化。为了透明地支持这种架构，内核子系统可 +以使用numa_mem_id()或cpu_to_mem()函数来定位调用或指定CPU的“本地内存节点”。同样，这是同 +一个节点，默认的本地页分配将从这个节点开始尝试。 -- cgit From 62ce577b9887accea6f65422f593e83b266a8bf0 Mon Sep 17 00:00:00 2001 From: Frank Rowand Date: Wed, 16 Mar 2022 15:26:22 -0500 Subject: Documentation: dev-tools: use literal block instead of code-block KTAP Specification: Change code-block directives to straightforward literal blocks since the blocks do not contain code. Suggested-by: Jonathan Corbet Signed-off-by: Frank Rowand Reviewed-by: David Gow Link: https://lore.kernel.org/r/20220316202622.324866-3-frowand.list@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/ktap.rst | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/ktap.rst b/Documentation/dev-tools/ktap.rst index 5ee735c6687f..d0a9565b0f44 100644 --- a/Documentation/dev-tools/ktap.rst +++ b/Documentation/dev-tools/ktap.rst @@ -115,34 +115,32 @@ The diagnostic data field is optional, and results which have neither a directive nor any diagnostic data do not need to include the "#" field separator. -Example result lines include: - -.. code-block:: none +Example result lines include:: ok 1 test_case_name The test "test_case_name" passed. -.. code-block:: none +:: not ok 1 test_case_name The test "test_case_name" failed. -.. code-block:: none +:: ok 1 test # SKIP necessary dependency unavailable The test "test" was SKIPPED with the diagnostic message "necessary dependency unavailable". -.. code-block:: none +:: not ok 1 test # TIMEOUT 30 seconds The test "test" timed out, with diagnostic data "30 seconds". -.. code-block:: none +:: ok 5 check return code # rcode=0 @@ -202,7 +200,7 @@ allowed to be either indented or not indented. An example of a test with two nested subtests: -.. code-block:: none +:: KTAP version 1 1..1 @@ -215,7 +213,7 @@ An example of a test with two nested subtests: An example format with multiple levels of nested testing: -.. code-block:: none +:: KTAP version 1 1..2 @@ -250,7 +248,7 @@ nested version line, uses a line of the form Example KTAP output -------------------- -.. code-block:: none +:: KTAP version 1 1..1 -- cgit From a477b94d657875c81775b7e5147fd2671ff25ce0 Mon Sep 17 00:00:00 2001 From: Joel Savitz Date: Fri, 22 Apr 2022 12:45:26 -0400 Subject: Documentation: add missing angle bracket in cgroup-v2 doc Trivial addition of missing closing angle backet. Signed-off-by: Joel Savitz Link: https://lore.kernel.org/r/20220422164526.3464306-1-jsavitz@redhat.com Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/cgroup-v2.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 69d7a6983f78..38aa01939e1e 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1881,7 +1881,7 @@ IO Latency Interface Files io.latency This takes a similar format as the other controllers. - "MAJOR:MINOR target=" io.stat If the controller is enabled you will see extra stats in io.stat in -- cgit From dbfb5f94e084287f0a3f23d14ef6692c43c98855 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Tue, 26 Apr 2022 16:35:06 -0700 Subject: dt-bindings: power: rpmpd: Add sc8280xp RPMh power-domains The sc8280xp has 13 power-domains controlled through the RPMh, document the compatible and provide definitions for the power-domains - and their active-only variants where applicable. The SA8540p differs slightly in the power domains exposed, so add a separate compatible for this, but reuse the constants to allow sharing the DeviceTree source. Signed-off-by: Bjorn Andersson Acked-by: Krzysztof Kozlowski Reviewed-by: Johan Hovold Link: https://lore.kernel.org/r/20220426233508.1762345-2-bjorn.andersson@linaro.org --- Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index b90c4427beec..ad77a6380f38 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -27,10 +27,12 @@ properties: - qcom,msm8998-rpmpd - qcom,qcm2290-rpmpd - qcom,qcs404-rpmpd + - qcom,sa8540p-rpmhpd - qcom,sdm660-rpmpd - qcom,sc7180-rpmhpd - qcom,sc7280-rpmhpd - qcom,sc8180x-rpmhpd + - qcom,sc8280xp-rpmhpd - qcom,sdm845-rpmhpd - qcom,sdx55-rpmhpd - qcom,sdx65-rpmhpd -- cgit From 9c1082fd1b1b8fd0f990ef917ddeff977fd320ab Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Wed, 20 Apr 2022 21:19:25 +0200 Subject: dt-bindings: pinctrl: ocelot: add reset property On the LAN966x SoC the GPIO controller will be resetted together with the SGPIO and the switch core. Add a phandle to register the shared reset line. Signed-off-by: Michael Walle Acked-by: Rob Herring Link: https://lore.kernel.org/r/20220420191926.3411830-2-michael@walle.cc Signed-off-by: Linus Walleij --- .../devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml index 7149a6655623..98d547c34ef3 100644 --- a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml @@ -42,6 +42,14 @@ properties: "#interrupt-cells": const: 2 + resets: + maxItems: 1 + + reset-names: + description: Optional shared switch reset. + items: + - const: switch + patternProperties: '-pins$': type: object -- cgit From 0037c30a84c10819e43c9bac5f85fb9cc0fc0af4 Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Wed, 27 Apr 2022 09:53:37 +0200 Subject: dt-bindings: interrupt-controller: fsl,ls-extirq: convert to YAML Convert the fsl,ls-extirq binding to the new YAML format. In contrast to the original binding documentation, there are three compatibles which are used in their corresponding device trees which have a specific compatible and the (already documented) fallback compatible: - "fsl,ls1046a-extirq", "fsl,ls1043a-extirq" - "fsl,ls2080a-extirq", "fsl,ls1088a-extirq" - "fsl,lx2160a-extirq", "fsl,ls1088a-extirq" Depending on the number of the number of the external IRQs which is usually 12 except for the LS1021A where there are only 6, the interrupt-map-mask was reduced from 0xffffffff to 0xf and 0x7 respectively and the number of interrupt-map entries have to match. Signed-off-by: Michael Walle Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220427075338.1156449-4-michael@walle.cc --- .../interrupt-controller/fsl,ls-extirq.txt | 53 --------- .../interrupt-controller/fsl,ls-extirq.yaml | 118 +++++++++++++++++++++ 2 files changed, 118 insertions(+), 53 deletions(-) delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt deleted file mode 100644 index 4d47df1a5c91..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt +++ /dev/null @@ -1,53 +0,0 @@ -* Freescale Layerscape external IRQs - -Some Layerscape SOCs (LS1021A, LS1043A, LS1046A -LS1088A, LS208xA, LX216xA) support inverting -the polarity of certain external interrupt lines. - -The device node must be a child of the node representing the -Supplemental Configuration Unit (SCFG). - -Required properties: -- compatible: should be "fsl,-extirq", e.g. "fsl,ls1021a-extirq". - "fsl,ls1043a-extirq": for LS1043A, LS1046A. - "fsl,ls1088a-extirq": for LS1088A, LS208xA, LX216xA. -- #interrupt-cells: Must be 2. The first element is the index of the - external interrupt line. The second element is the trigger type. -- #address-cells: Must be 0. -- interrupt-controller: Identifies the node as an interrupt controller -- reg: Specifies the Interrupt Polarity Control Register (INTPCR) in - the SCFG or the External Interrupt Control Register (IRQCR) in - the ISC. -- interrupt-map: Specifies the mapping from external interrupts to GIC - interrupts. -- interrupt-map-mask: Must be <0xffffffff 0>. - -Example: - scfg: scfg@1570000 { - compatible = "fsl,ls1021a-scfg", "syscon"; - reg = <0x0 0x1570000 0x0 0x10000>; - big-endian; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0x0 0x0 0x1570000 0x10000>; - - extirq: interrupt-controller@1ac { - compatible = "fsl,ls1021a-extirq"; - #interrupt-cells = <2>; - #address-cells = <0>; - interrupt-controller; - reg = <0x1ac 4>; - interrupt-map = - <0 0 &gic GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>, - <1 0 &gic GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>, - <2 0 &gic GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>, - <3 0 &gic GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>, - <4 0 &gic GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>, - <5 0 &gic GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>; - interrupt-map-mask = <0xffffffff 0x0>; - }; - }; - - - interrupts-extended = <&gic GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>, - <&extirq 1 IRQ_TYPE_LEVEL_LOW>; diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml new file mode 100644 index 000000000000..887e565b9573 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml @@ -0,0 +1,118 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/fsl,ls-extirq.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Layerscape External Interrupt Controller + +maintainers: + - Shawn Guo + - Li Yang + +description: | + Some Layerscape SOCs (LS1021A, LS1043A, LS1046A LS1088A, LS208xA, + LX216xA) support inverting the polarity of certain external interrupt + lines. + +properties: + compatible: + oneOf: + - enum: + - fsl,ls1021a-extirq + - fsl,ls1043a-extirq + - fsl,ls1088a-extirq + - items: + - enum: + - fsl,ls1046a-extirq + - const: fsl,ls1043a-extirq + - items: + - enum: + - fsl,ls2080a-extirq + - fsl,lx2160a-extirq + - const: fsl,ls1088a-extirq + + '#interrupt-cells': + const: 2 + + '#address-cells': + const: 0 + + interrupt-controller: true + + reg: + maxItems: 1 + description: + Specifies the Interrupt Polarity Control Register (INTPCR) in the + SCFG or the External Interrupt Control Register (IRQCR) in the ISC. + + interrupt-map: + description: Specifies the mapping from external interrupts to GIC interrupts. + + interrupt-map-mask: true + +required: + - compatible + - '#interrupt-cells' + - '#address-cells' + - interrupt-controller + - reg + - interrupt-map + - interrupt-map-mask + +allOf: + - if: + properties: + compatible: + contains: + enum: + - fsl,ls1021a-extirq + then: + properties: + interrupt-map: + minItems: 6 + maxItems: 6 + interrupt-map-mask: + items: + - const: 0x7 + - const: 0 + - if: + properties: + compatible: + contains: + enum: + - fsl,ls1043a-extirq + - fsl,ls1046a-extirq + - fsl,ls1088a-extirq + - fsl,ls2080a-extirq + - fsl,lx2160a-extirq + then: + properties: + interrupt-map: + minItems: 12 + maxItems: 12 + interrupt-map-mask: + items: + - const: 0xf + - const: 0 + +additionalProperties: false + +examples: + - | + #include + interrupt-controller@1ac { + compatible = "fsl,ls1021a-extirq"; + #interrupt-cells = <2>; + #address-cells = <0>; + interrupt-controller; + reg = <0x1ac 4>; + interrupt-map = + <0 0 &gic GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>, + <1 0 &gic GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>, + <2 0 &gic GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>, + <3 0 &gic GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>, + <4 0 &gic GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>, + <5 0 &gic GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>; + interrupt-map-mask = <0x7 0x0>; + }; -- cgit From 8274c8eae1d3e48bb834dc26b7ebdaeef53d10ba Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Wed, 27 Apr 2022 09:53:38 +0200 Subject: dt-bindings: fsl: convert fsl,layerscape-scfg to YAML Convert the fsl,layerscape-scfg binding to the new YAML format. In the device trees, the device node always have a "syscon" compatible, which wasn't mentioned in the previous binding. Also added, compared to the original binding, is the interrupt-controller subnode as used in arch/arm/boot/dts/ls1021a.dtsi as well as the litte-endian and big-endian properties. Signed-off-by: Michael Walle Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220427075338.1156449-5-michael@walle.cc --- .../bindings/arm/freescale/fsl,layerscape-scfg.txt | 19 ------- .../bindings/soc/fsl/fsl,layerscape-scfg.yaml | 58 ++++++++++++++++++++++ 2 files changed, 58 insertions(+), 19 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt create mode 100644 Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt deleted file mode 100644 index 0ab67b0b216d..000000000000 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt +++ /dev/null @@ -1,19 +0,0 @@ -Freescale SCFG - -SCFG is the supplemental configuration unit, that provides SoC specific -configuration and status registers for the chip. Such as getting PEX port -status. - -Required properties: - - compatible: Should contain a chip-specific compatible string, - Chip-specific strings are of the form "fsl,-scfg", - The following s are known to be supported: - ls1012a, ls1021a, ls1043a, ls1046a, ls2080a. - - - reg: should contain base address and length of SCFG memory-mapped registers - -Example: - scfg: scfg@1570000 { - compatible = "fsl,ls1021a-scfg"; - reg = <0x0 0x1570000 0x0 0x10000>; - }; diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml new file mode 100644 index 000000000000..8d088b5fe823 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/fsl/fsl,layerscape-scfg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Layerscape Supplemental Configuration Unit + +maintainers: + - Shawn Guo + - Li Yang + +description: | + SCFG is the supplemental configuration unit, that provides SoC specific + configuration and status registers for the chip. Such as getting PEX port + status. + +properties: + compatible: + items: + - enum: + - fsl,ls1012a-scfg + - fsl,ls1021a-scfg + - fsl,ls1028a-scfg + - fsl,ls1043a-scfg + - fsl,ls1046a-scfg + - const: syscon + + reg: + maxItems: 1 + + little-endian: true + big-endian: true + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + ranges: true + +patternProperties: + "^interrupt-controller@[a-z0-9]+$": + $ref: /schemas/interrupt-controller/fsl,ls-extirq.yaml# + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + syscon@1570000 { + compatible = "fsl,ls1021a-scfg", "syscon"; + reg = <0x1570000 0x10000>; + }; -- cgit From 75382a2dca0e9e9e57e88b479cf537549461a934 Mon Sep 17 00:00:00 2001 From: Jiajian Ye Date: Thu, 28 Apr 2022 23:15:56 -0700 Subject: tools/vm/page_owner_sort.c: support for multi-value selection in single argument When viewing page owner information, we may want to select blocks whose PID/TGID/TASK_COMM_NAME appears in a user-specified list for data analysis and aggregation. But currently page_owner_sort only supports selecting blocks associated with only one specified PID/TGID/TASK_COMM_NAME. Therefore, following adjustments are made to fix the problem: 1. Enhance selecting function to support the selection of multiple PIDs/TGIDs/TASK_COMM_NAMEs. The enhanced usages are as follows: --pid Select by pid. This selects the blocks whose PID numbers appear in . --tgid Select by tgid. This selects the blocks whose TGID numbers appear in . --name Select by task command name. This selects the blocks whose task command name appear in . Where , , are single arguments in the form of a comma-separated list,which offers a way to specify individual selecting rules. For example, if you want to select blocks whose tgids are 1, 2 or 3, you have to use 4 commands as follows: ./page_owner_sort --tgid=1 ./page_owner_sort --tgid=2 ./page_owner_sort --tgid=3 cat > With this patch, you can use only 1 command to obtain the same result as above: ./page_owner_sort --tgid=1,2,3 2. Update explanations of --pid, --tgid and --name in the function usage() and the document(Documents/vm/page_owner.rst). This work is coauthored by Yixuan Cao Shenghong Han Yinan Zhang Chongxi Zhao Yuhong Feng Yongqiang Liu Link: https://lkml.kernel.org/r/20220401024856.767-2-yejiajian2018@email.szu.edu.cn Signed-off-by: Jiajian Ye Cc: Chongxi Zhao Cc: Shenghong Han Cc: Yinan Zhang Cc: Yixuan Cao Cc: Yongqiang Liu Cc: Yuhong Feng Cc: Haowen Bai Cc: Sean Anderson Signed-off-by: Andrew Morton --- Documentation/vm/page_owner.rst | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index 7e0c3f574e78..3102f91d635c 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -129,7 +129,6 @@ Usage Specify culling rules.Culling syntax is key[,key[,...]].Choose a multi-letter key from the **STANDARD FORMAT SPECIFIERS** section. - is a single argument in the form of a comma-separated list, which offers a way to specify individual culling rules. The recognized keywords are described in the **STANDARD FORMAT SPECIFIERS** section below. @@ -137,7 +136,6 @@ Usage the STANDARD SORT KEYS section below. Mixed use of abbreviated and complete-form of keys is allowed. - Examples: ./page_owner_sort --cull=stacktrace ./page_owner_sort --cull=st,pid,name @@ -147,9 +145,21 @@ Usage -f Filter out the information of blocks whose memory has been released. Select: - --pid Select by pid. - --tgid Select by tgid. - --name Select by task command name. + --pid Select by pid. This selects the blocks whose process ID + numbers appear in . + --tgid Select by tgid. This selects the blocks whose thread + group ID numbers appear in . + --name Select by task command name. This selects the blocks whose + task command name appear in . + + , , are single arguments in the form of a comma-separated list, + which offers a way to specify individual selecting rules. + + + Examples: + ./page_owner_sort --pid=1 + ./page_owner_sort --tgid=1,2,3 + ./page_owner_sort --name name1,name2 STANDARD FORMAT SPECIFIERS ========================== -- cgit From ebbeae36387ccf1326c896167872c3acf6c3c956 Mon Sep 17 00:00:00 2001 From: Jiajian Ye Date: Thu, 28 Apr 2022 23:15:57 -0700 Subject: tools/vm/page_owner_sort.c: support sorting blocks by multiple keys When viewing page owner information, we may want to sort blocks of information by multiple keys, since one single key does not uniquely identify a block. Therefore, following adjustments are made: 1. Add a new --sort option to support sorting blocks of information by multiple keys. ./page_owner_sort --sort= ./page_owner_sort --sort is a single argument in the form of a comma-separated list, which offers a way to specify sorting order. Sorting syntax is [+|-]key[,[+|-]key[,...]]. The ascending or descending order can be specified by adding the + (ascending, default) or - (descend -ing) prefix to the key: ./page_owner_sort [option] --sort -key1,+key2,key3... For example, to sort the blocks first by task command name in lexicographic order and then by pid in ascending numerical order, use the following: ./page_owner_sort --sort=name,+pid To sort the blocks first by pid in ascending order and then by timestamp of the page when it is allocated in descending order, use the following: ./page_owner_sort --sort=pid,-alloc_ts 2. Add explanations of a newly added --sort option in the function usage() and the document(Documentation/vm/page_owner.rst). This work is coauthored by Yixuan Cao Shenghong Han Yinan Zhang Chongxi Zhao Yuhong Feng Yongqiang Liu Link: https://lkml.kernel.org/r/20220401024856.767-3-yejiajian2018@email.szu.edu.cn Signed-off-by: Jiajian Ye Cc: Chongxi Zhao Cc: Shenghong Han Cc: Yinan Zhang Cc: Yixuan Cao Cc: Yongqiang Liu Cc: Yuhong Feng Cc: Haowen Bai Cc: Sean Anderson Signed-off-by: Andrew Morton --- Documentation/vm/page_owner.rst | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index 3102f91d635c..523bf3419512 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -121,6 +121,14 @@ Usage -r Sort by memory release time. -s Sort by stack trace. -t Sort by times (default). + --sort Specify sorting order. Sorting syntax is [+|-]key[,[+|-]key[,...]]. + Choose a key from the **STANDARD FORMAT SPECIFIERS** section. The "+" is + optional since default direction is increasing numerical or lexicographic + order. Mixed use of abbreviated and complete-form of keys is allowed. + + Examples: + ./page_owner_sort --sort=n,+pid,-tgid + ./page_owner_sort --sort=at additional function:: @@ -165,9 +173,23 @@ STANDARD FORMAT SPECIFIERS ========================== :: +For --sort option: + + KEY LONG DESCRIPTION + p pid process ID + tg tgid thread group ID + n name task command name + st stacktrace stack trace of the page allocation + T txt full text of block + ft free_ts timestamp of the page when it was released + at alloc_ts timestamp of the page when it was allocated + +For --curl option: + KEY LONG DESCRIPTION p pid process ID tg tgid thread group ID n name task command name f free whether the page has been released or not - st stacktrace stace trace of the page allocation + st stacktrace stack trace of the page allocation + -- cgit From f09654bb88127473b4baf3bc0b68d4d4695aca7b Mon Sep 17 00:00:00 2001 From: Yixuan Cao Date: Thu, 28 Apr 2022 23:15:57 -0700 Subject: tools/vm/page_owner_sort.c: provide allocator labelling and update --cull and --sort options An application is suspected of having memory leak when its memory consumption is high and keeps increasing. There are several commonly used memory allocators: slab, cma, vmalloc, etc. The memory leak identification can be sped up if the page information allocated by an allocator can be analyzed separately. This patch provides supports for memory allocator labelling for slab, vmalloc, and cma. The pages allocated by slab and cma can be confirmed from the "PFN" line according to the kernel codes, and the label of the vmalloc allocator can be obtained by analyzing the stack trace. Thanks for Vlastimil Babka's constructive suggestions. Based on Yinan Zhang's study, the call chain of vmalloc() is vmalloc() -> ... -> __vmalloc_node_range() -> __vmalloc_area_node(). __vmalloc_area_node() requests memory through the interface of buddy allocation system. In the current version, __vmalloc_area_node() uses four interfaces: alloc_pages_bulk_array_mempolicy(), alloc_pages_bulk_array_node(), alloc_pages() and alloc_pages_node(). By disassembling the code, we find that __vmalloc_area_node() is expanded in __vmalloc_node_range(). So __vmalloc_area_node is not in the stack trace. On the test machine, the stack trace of pages allocated by vmalloc has the following four forms: __alloc_pages_bulk+0x230/0x6a0 __vmalloc_node_range+0x19c/0x598 alloc_pages_bulk_array_mempolicy+0xbc/0x278 __vmalloc_node_range+0x1e8/0x598 __alloc_pages+0x160/0x2b0 __vmalloc_node_range+0x234/0x598 alloc_pages+0xac/0x150 __vmalloc_node_range+0x44c/0x598 Therefore, in two consecutive lines of stacktrace, if the first line contains the word "alloc_pages" and the second line contains the word "__vmalloc_node_range", it can be determined that the page is allocated by vmalloc. And the function offset and size are not the same on different machines, so there is no need to match them. At the same time, this patch updates the --cull and --sort options to support allocator-based merge statistics and sorting. The added functions are fully compatible with the original work. When using, you can use "allocator", or abbreviated as "ator". Relevant updates have also been made in the documentation(Documentation/vm/page_owner.rst). Example: ./page_owner_sort --cull=st,pid,name,allocator ./page_owner_sort --sort=ator,pid,name This work is coauthored by Jiajian Ye, Yinan Zhang, Shenghong Han, Chongxi Zhao, Yuhong Feng and Yongqiang Liu. Link: https://lkml.kernel.org/r/20220410132932.9402-1-caoyixuan2019@email.szu.edu.cn Signed-off-by: Yixuan Cao Cc: Chongxi Zhao Cc: Haowen Bai Cc: Jiajian Ye Cc: Sean Anderson Cc: Shenghong Han Cc: Yinan Zhang Cc: Yongqiang Liu Cc: Yuhong Feng Signed-off-by: Andrew Morton --- Documentation/vm/page_owner.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index 523bf3419512..25622c715823 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -183,6 +183,7 @@ For --sort option: T txt full text of block ft free_ts timestamp of the page when it was released at alloc_ts timestamp of the page when it was allocated + ator allocator memory allocator for pages For --curl option: @@ -192,4 +193,4 @@ For --curl option: n name task command name f free whether the page has been released or not st stacktrace stack trace of the page allocation - + ator allocator memory allocator for pages -- cgit From 8d98e42fb20c25e8efdab4cc1ac46d52ba964aca Mon Sep 17 00:00:00 2001 From: Joel Savitz Date: Thu, 28 Apr 2022 23:16:01 -0700 Subject: Documentation/sysctl: document page_lock_unfairness commit 5ef64cc8987a ("mm: allow a controlled amount of unfairness in the page lock") introduced a new systctl but no accompanying documentation. Add a simple entry to the documentation. Link: https://lkml.kernel.org/r/20220325164437.120246-1-jsavitz@redhat.com Signed-off-by: Joel Savitz Cc: Jonathan Corbet Cc: Vlastimil Babka Cc: Mel Gorman Cc: Dave Hansen Cc: Suren Baghdasaryan Cc: Mike Rapoport Cc: "zhangyi (F)" Cc: Charan Teja Reddy Cc: Linus Torvalds Signed-off-by: Andrew Morton --- Documentation/admin-guide/sysctl/vm.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index f4804ce37c58..747e325ebcd0 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -62,6 +62,7 @@ Currently, these files are in /proc/sys/vm: - overcommit_memory - overcommit_ratio - page-cluster +- page_lock_unfairness - panic_on_oom - percpu_pagelist_high_fraction - stat_interval @@ -754,6 +755,14 @@ extra faults and I/O delays for following faults if they would have been part of that consecutive pages readahead would have brought in. +page_lock_unfairness +==================== + +This value determines the number of times that the page lock can be +stolen from under a waiter. After the lock is stolen the number of times +specified in this file (default is 5), the "fair lock handoff" semantics +will apply, and the waiter will only be awakened if the lock can be taken. + panic_on_oom ============ -- cgit From 47010c040dec8af6347ec6259104fc13f7e7e30a Mon Sep 17 00:00:00 2001 From: Muchun Song Date: Thu, 28 Apr 2022 23:16:15 -0700 Subject: mm: hugetlb_vmemmap: cleanup CONFIG_HUGETLB_PAGE_FREE_VMEMMAP* The word of "free" is not expressive enough to express the feature of optimizing vmemmap pages associated with each HugeTLB, rename this keywork to "optimize". In this patch , cheanup configs to make code more expressive. Link: https://lkml.kernel.org/r/20220404074652.68024-4-songmuchun@bytedance.com Signed-off-by: Muchun Song Cc: Mike Kravetz Cc: David Hildenbrand Signed-off-by: Andrew Morton --- Documentation/admin-guide/kernel-parameters.txt | 4 ++-- Documentation/admin-guide/mm/hugetlbpage.rst | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 3f1cc5e317ed..d9b577db6e19 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1660,7 +1660,7 @@ Format: size[KMG] hugetlb_free_vmemmap= - [KNL] Reguires CONFIG_HUGETLB_PAGE_FREE_VMEMMAP + [KNL] Reguires CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP enabled. Allows heavy hugetlb users to free up some more memory (7 * PAGE_SIZE for each 2MB hugetlb page). @@ -1669,7 +1669,7 @@ on: enable the feature off: disable the feature - Built with CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON=y, + Built with CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON=y, the default is on. This is not compatible with memory_hotplug.memmap_on_memory. diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst index 0166f9de3428..a90330d0a837 100644 --- a/Documentation/admin-guide/mm/hugetlbpage.rst +++ b/Documentation/admin-guide/mm/hugetlbpage.rst @@ -164,7 +164,7 @@ default_hugepagesz will all result in 256 2M huge pages being allocated. Valid default huge page size is architecture dependent. hugetlb_free_vmemmap - When CONFIG_HUGETLB_PAGE_FREE_VMEMMAP is set, this enables freeing + When CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP is set, this enables optimizing unused vmemmap pages associated with each HugeTLB page. When multiple huge page sizes are supported, ``/proc/sys/vm/nr_hugepages`` -- cgit From 60a427db0f80f16b9bb9efe6cc79c93f336e8466 Mon Sep 17 00:00:00 2001 From: Joao Martins Date: Thu, 28 Apr 2022 23:16:15 -0700 Subject: mm/hugetlb_vmemmap: move comment block to Documentation/vm In preparation for device-dax for using hugetlbfs compound page tail deduplication technique, move the comment block explanation into a common place in Documentation/vm. Link: https://lkml.kernel.org/r/20220420155310.9712-4-joao.m.martins@oracle.com Signed-off-by: Joao Martins Reviewed-by: Muchun Song Reviewed-by: Dan Williams Suggested-by: Dan Williams Cc: Muchun Song Cc: Mike Kravetz Cc: Christoph Hellwig Cc: Jane Chu Cc: Jason Gunthorpe Cc: Jonathan Corbet Cc: Matthew Wilcox Cc: Vishal Verma Signed-off-by: Andrew Morton --- Documentation/vm/index.rst | 1 + Documentation/vm/vmemmap_dedup.rst | 173 +++++++++++++++++++++++++++++++++++++ 2 files changed, 174 insertions(+) create mode 100644 Documentation/vm/vmemmap_dedup.rst (limited to 'Documentation') diff --git a/Documentation/vm/index.rst b/Documentation/vm/index.rst index 44365c4574a3..2fb612bb72c9 100644 --- a/Documentation/vm/index.rst +++ b/Documentation/vm/index.rst @@ -37,5 +37,6 @@ algorithms. If you are looking for advice on simply allocating memory, see the transhuge unevictable-lru vmalloced-kernel-stacks + vmemmap_dedup z3fold zsmalloc diff --git a/Documentation/vm/vmemmap_dedup.rst b/Documentation/vm/vmemmap_dedup.rst new file mode 100644 index 000000000000..485ccf4f7b10 --- /dev/null +++ b/Documentation/vm/vmemmap_dedup.rst @@ -0,0 +1,173 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================== +Free some vmemmap pages of HugeTLB +================================== + +The struct page structures (page structs) are used to describe a physical +page frame. By default, there is a one-to-one mapping from a page frame to +it's corresponding page struct. + +HugeTLB pages consist of multiple base page size pages and is supported by many +architectures. See Documentation/admin-guide/mm/hugetlbpage.rst for more +details. On the x86-64 architecture, HugeTLB pages of size 2MB and 1GB are +currently supported. Since the base page size on x86 is 4KB, a 2MB HugeTLB page +consists of 512 base pages and a 1GB HugeTLB page consists of 4096 base pages. +For each base page, there is a corresponding page struct. + +Within the HugeTLB subsystem, only the first 4 page structs are used to +contain unique information about a HugeTLB page. __NR_USED_SUBPAGE provides +this upper limit. The only 'useful' information in the remaining page structs +is the compound_head field, and this field is the same for all tail pages. + +By removing redundant page structs for HugeTLB pages, memory can be returned +to the buddy allocator for other uses. + +Different architectures support different HugeTLB pages. For example, the +following table is the HugeTLB page size supported by x86 and arm64 +architectures. Because arm64 supports 4k, 16k, and 64k base pages and +supports contiguous entries, so it supports many kinds of sizes of HugeTLB +page. + ++--------------+-----------+-----------------------------------------------+ +| Architecture | Page Size | HugeTLB Page Size | ++--------------+-----------+-----------+-----------+-----------+-----------+ +| x86-64 | 4KB | 2MB | 1GB | | | ++--------------+-----------+-----------+-----------+-----------+-----------+ +| | 4KB | 64KB | 2MB | 32MB | 1GB | +| +-----------+-----------+-----------+-----------+-----------+ +| arm64 | 16KB | 2MB | 32MB | 1GB | | +| +-----------+-----------+-----------+-----------+-----------+ +| | 64KB | 2MB | 512MB | 16GB | | ++--------------+-----------+-----------+-----------+-----------+-----------+ + +When the system boot up, every HugeTLB page has more than one struct page +structs which size is (unit: pages):: + + struct_size = HugeTLB_Size / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE + +Where HugeTLB_Size is the size of the HugeTLB page. We know that the size +of the HugeTLB page is always n times PAGE_SIZE. So we can get the following +relationship:: + + HugeTLB_Size = n * PAGE_SIZE + +Then:: + + struct_size = n * PAGE_SIZE / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE + = n * sizeof(struct page) / PAGE_SIZE + +We can use huge mapping at the pud/pmd level for the HugeTLB page. + +For the HugeTLB page of the pmd level mapping, then:: + + struct_size = n * sizeof(struct page) / PAGE_SIZE + = PAGE_SIZE / sizeof(pte_t) * sizeof(struct page) / PAGE_SIZE + = sizeof(struct page) / sizeof(pte_t) + = 64 / 8 + = 8 (pages) + +Where n is how many pte entries which one page can contains. So the value of +n is (PAGE_SIZE / sizeof(pte_t)). + +This optimization only supports 64-bit system, so the value of sizeof(pte_t) +is 8. And this optimization also applicable only when the size of struct page +is a power of two. In most cases, the size of struct page is 64 bytes (e.g. +x86-64 and arm64). So if we use pmd level mapping for a HugeTLB page, the +size of struct page structs of it is 8 page frames which size depends on the +size of the base page. + +For the HugeTLB page of the pud level mapping, then:: + + struct_size = PAGE_SIZE / sizeof(pmd_t) * struct_size(pmd) + = PAGE_SIZE / 8 * 8 (pages) + = PAGE_SIZE (pages) + +Where the struct_size(pmd) is the size of the struct page structs of a +HugeTLB page of the pmd level mapping. + +E.g.: A 2MB HugeTLB page on x86_64 consists in 8 page frames while 1GB +HugeTLB page consists in 4096. + +Next, we take the pmd level mapping of the HugeTLB page as an example to +show the internal implementation of this optimization. There are 8 pages +struct page structs associated with a HugeTLB page which is pmd mapped. + +Here is how things look before optimization:: + + HugeTLB struct pages(8 pages) page frame(8 pages) + +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ + | | | 0 | -------------> | 0 | + | | +-----------+ +-----------+ + | | | 1 | -------------> | 1 | + | | +-----------+ +-----------+ + | | | 2 | -------------> | 2 | + | | +-----------+ +-----------+ + | | | 3 | -------------> | 3 | + | | +-----------+ +-----------+ + | | | 4 | -------------> | 4 | + | PMD | +-----------+ +-----------+ + | level | | 5 | -------------> | 5 | + | mapping | +-----------+ +-----------+ + | | | 6 | -------------> | 6 | + | | +-----------+ +-----------+ + | | | 7 | -------------> | 7 | + | | +-----------+ +-----------+ + | | + | | + | | + +-----------+ + +The value of page->compound_head is the same for all tail pages. The first +page of page structs (page 0) associated with the HugeTLB page contains the 4 +page structs necessary to describe the HugeTLB. The only use of the remaining +pages of page structs (page 1 to page 7) is to point to page->compound_head. +Therefore, we can remap pages 1 to 7 to page 0. Only 1 page of page structs +will be used for each HugeTLB page. This will allow us to free the remaining +7 pages to the buddy allocator. + +Here is how things look after remapping:: + + HugeTLB struct pages(8 pages) page frame(8 pages) + +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ + | | | 0 | -------------> | 0 | + | | +-----------+ +-----------+ + | | | 1 | ---------------^ ^ ^ ^ ^ ^ ^ + | | +-----------+ | | | | | | + | | | 2 | -----------------+ | | | | | + | | +-----------+ | | | | | + | | | 3 | -------------------+ | | | | + | | +-----------+ | | | | + | | | 4 | ---------------------+ | | | + | PMD | +-----------+ | | | + | level | | 5 | -----------------------+ | | + | mapping | +-----------+ | | + | | | 6 | -------------------------+ | + | | +-----------+ | + | | | 7 | ---------------------------+ + | | +-----------+ + | | + | | + | | + +-----------+ + +When a HugeTLB is freed to the buddy system, we should allocate 7 pages for +vmemmap pages and restore the previous mapping relationship. + +For the HugeTLB page of the pud level mapping. It is similar to the former. +We also can use this approach to free (PAGE_SIZE - 1) vmemmap pages. + +Apart from the HugeTLB page of the pmd/pud level mapping, some architectures +(e.g. aarch64) provides a contiguous bit in the translation table entries +that hints to the MMU to indicate that it is one of a contiguous set of +entries that can be cached in a single TLB entry. + +The contiguous bit is used to increase the mapping size at the pmd and pte +(last) level. So this type of HugeTLB page can be optimized only when its +size of the struct page structs is greater than 1 page. + +Notice: The head vmemmap page is not freed to the buddy allocator and all +tail vmemmap pages are mapped to the head vmemmap page frame. So we can see +more than one struct page struct with PG_head (e.g. 8 per 2 MB HugeTLB page) +associated with each HugeTLB page. The compound_head() can handle this +correctly (more details refer to the comment above compound_head()). -- cgit From 4917f55b4ef963e2d2288fe4eb651728be8db406 Mon Sep 17 00:00:00 2001 From: Joao Martins Date: Thu, 28 Apr 2022 23:16:16 -0700 Subject: mm/sparse-vmemmap: improve memory savings for compound devmaps A compound devmap is a dev_pagemap with @vmemmap_shift > 0 and it means that pages are mapped at a given huge page alignment and utilize uses compound pages as opposed to order-0 pages. Take advantage of the fact that most tail pages look the same (except the first two) to minimize struct page overhead. Allocate a separate page for the vmemmap area which contains the head page and separate for the next 64 pages. The rest of the subsections then reuse this tail vmemmap page to initialize the rest of the tail pages. Sections are arch-dependent (e.g. on x86 it's 64M, 128M or 512M) and when initializing compound devmap with big enough @vmemmap_shift (e.g. 1G PUD) it may cross multiple sections. The vmemmap code needs to consult @pgmap so that multiple sections that all map the same tail data can refer back to the first copy of that data for a given gigantic page. On compound devmaps with 2M align, this mechanism lets 6 pages be saved out of the 8 necessary PFNs necessary to set the subsection's 512 struct pages being mapped. On a 1G compound devmap it saves 4094 pages. Altmap isn't supported yet, given various restrictions in altmap pfn allocator, thus fallback to the already in use vmemmap_populate(). It is worth noting that altmap for devmap mappings was there to relieve the pressure of inordinate amounts of memmap space to map terabytes of pmem. With compound pages the motivation for altmaps for pmem gets reduced. Link: https://lkml.kernel.org/r/20220420155310.9712-5-joao.m.martins@oracle.com Signed-off-by: Joao Martins Reviewed-by: Muchun Song Cc: Christoph Hellwig Cc: Dan Williams Cc: Jane Chu Cc: Jason Gunthorpe Cc: Jonathan Corbet Cc: Matthew Wilcox Cc: Mike Kravetz Cc: Vishal Verma Signed-off-by: Andrew Morton --- Documentation/vm/vmemmap_dedup.rst | 56 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 53 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/vmemmap_dedup.rst b/Documentation/vm/vmemmap_dedup.rst index 485ccf4f7b10..c9c495f62d12 100644 --- a/Documentation/vm/vmemmap_dedup.rst +++ b/Documentation/vm/vmemmap_dedup.rst @@ -1,8 +1,11 @@ .. SPDX-License-Identifier: GPL-2.0 -================================== -Free some vmemmap pages of HugeTLB -================================== +========================================= +A vmemmap diet for HugeTLB and Device DAX +========================================= + +HugeTLB +======= The struct page structures (page structs) are used to describe a physical page frame. By default, there is a one-to-one mapping from a page frame to @@ -171,3 +174,50 @@ tail vmemmap pages are mapped to the head vmemmap page frame. So we can see more than one struct page struct with PG_head (e.g. 8 per 2 MB HugeTLB page) associated with each HugeTLB page. The compound_head() can handle this correctly (more details refer to the comment above compound_head()). + +Device DAX +========== + +The device-dax interface uses the same tail deduplication technique explained +in the previous chapter, except when used with the vmemmap in +the device (altmap). + +The following page sizes are supported in DAX: PAGE_SIZE (4K on x86_64), +PMD_SIZE (2M on x86_64) and PUD_SIZE (1G on x86_64). + +The differences with HugeTLB are relatively minor. + +It only use 3 page structs for storing all information as opposed +to 4 on HugeTLB pages. + +There's no remapping of vmemmap given that device-dax memory is not part of +System RAM ranges initialized at boot. Thus the tail page deduplication +happens at a later stage when we populate the sections. HugeTLB reuses the +the head vmemmap page representing, whereas device-dax reuses the tail +vmemmap page. This results in only half of the savings compared to HugeTLB. + +Deduplicated tail pages are not mapped read-only. + +Here's how things look like on device-dax after the sections are populated:: + + +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ + | | | 0 | -------------> | 0 | + | | +-----------+ +-----------+ + | | | 1 | -------------> | 1 | + | | +-----------+ +-----------+ + | | | 2 | ----------------^ ^ ^ ^ ^ ^ + | | +-----------+ | | | | | + | | | 3 | ------------------+ | | | | + | | +-----------+ | | | | + | | | 4 | --------------------+ | | | + | PMD | +-----------+ | | | + | level | | 5 | ----------------------+ | | + | mapping | +-----------+ | | + | | | 6 | ------------------------+ | + | | +-----------+ | + | | | 7 | --------------------------+ + | | +-----------+ + | | + | | + | | + +-----------+ -- cgit From 94bfe85bde18a99612bb5d0ce348643c2d352836 Mon Sep 17 00:00:00 2001 From: Yang Yang Date: Thu, 28 Apr 2022 23:16:16 -0700 Subject: mm/vmstat: add events for ksm cow Users may use ksm by calling madvise(, , MADV_MERGEABLE) when they want to save memory, it's a tradeoff by suffering delay on ksm cow. Users can get to know how much memory ksm saved by reading /sys/kernel/mm/ksm/pages_sharing, but they don't know what's the costs of ksm cow, and this is important of some delay sensitive tasks. So add ksm cow events to help users evaluate whether or how to use ksm. Also update Documentation/admin-guide/mm/ksm.rst with new added events. Link: https://lkml.kernel.org/r/20220331035616.2390805-1-yang.yang29@zte.com.cn Signed-off-by: Yang Yang Reviewed-by: David Hildenbrand Reviewed-by: xu xin Reviewed-by: Ran Xiaokai Cc: Matthew Wilcox (Oracle) Cc: Jonathan Corbet Cc: Dave Hansen Cc: Saravanan D Cc: Minchan Kim Cc: John Hubbard Signed-off-by: Andrew Morton --- Documentation/admin-guide/mm/ksm.rst | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst index 97d816791aca..b244f0202a03 100644 --- a/Documentation/admin-guide/mm/ksm.rst +++ b/Documentation/admin-guide/mm/ksm.rst @@ -184,6 +184,24 @@ The maximum possible ``pages_sharing/pages_shared`` ratio is limited by the ``max_page_sharing`` tunable. To increase the ratio ``max_page_sharing`` must be increased accordingly. +Monitoring KSM events +===================== + +There are some counters in /proc/vmstat that may be used to monitor KSM events. +KSM might help save memory, it's a tradeoff by may suffering delay on KSM COW +or on swapping in copy. Those events could help users evaluate whether or how +to use KSM. For example, if cow_ksm increases too fast, user may decrease the +range of madvise(, , MADV_MERGEABLE). + +cow_ksm + is incremented every time a KSM page triggers copy on write (COW) + when users try to write to a KSM page, we have to make a copy. + +ksm_swpin_copy + is incremented every time a KSM page is copied when swapping in + note that KSM page might be copied when swapping in because do_swap_page() + cannot do all the locking needed to reconstitute a cross-anon_vma KSM page. + -- Izik Eidus, Hugh Dickins, 17 Nov 2009 -- cgit From e2ab93e59bc3c029b61a7091825f193f1a66a1a1 Mon Sep 17 00:00:00 2001 From: Ashish Mhetre Date: Tue, 26 Apr 2022 13:08:26 +0530 Subject: dt-bindings: memory: tegra: Update validation for reg and reg-names From Tegra186 onwards, memory controller support multiple channels. "reg" items are updated with address and size of these channels. Tegra186 has overall 5 memory controller channels. Tegra194 and Tegra234 have overall 17 memory controller channels each. There is one "reg" entry for memory controller stream-ID registers. So update the "reg" property's "minItems" and "maxItems" accordingly in the Tegra186 devicetree documentation. Also update validation for "reg-names" added for these corresponding "reg" items. ABI change due to new bindings is intended but backward compatibility is preserved in driver. Reviewed-by: Rob Herring Signed-off-by: Ashish Mhetre Signed-off-by: Thierry Reding --- .../memory-controllers/nvidia,tegra186-mc.yaml | 80 ++++++++++++++++++++-- 1 file changed, 74 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml index 13c4c82fd0d3..c7cfa6c2cd81 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml @@ -34,8 +34,12 @@ properties: - nvidia,tegra234-mc reg: - minItems: 1 - maxItems: 3 + minItems: 6 + maxItems: 18 + + reg-names: + minItems: 6 + maxItems: 18 interrupts: items: @@ -142,7 +146,18 @@ allOf: then: properties: reg: - maxItems: 1 + maxItems: 6 + description: 5 memory controller channels and 1 for stream-id registers + + reg-names: + maxItems: 6 + items: + - const: sid + - const: broadcast + - const: ch0 + - const: ch1 + - const: ch2 + - const: ch3 - if: properties: @@ -151,7 +166,30 @@ allOf: then: properties: reg: - minItems: 3 + minItems: 18 + description: 17 memory controller channels and 1 for stream-id registers + + reg-names: + minItems: 18 + items: + - const: sid + - const: broadcast + - const: ch0 + - const: ch1 + - const: ch2 + - const: ch3 + - const: ch4 + - const: ch5 + - const: ch6 + - const: ch7 + - const: ch8 + - const: ch9 + - const: ch10 + - const: ch11 + - const: ch12 + - const: ch13 + - const: ch14 + - const: ch15 - if: properties: @@ -160,13 +198,37 @@ allOf: then: properties: reg: - minItems: 3 + minItems: 18 + description: 17 memory controller channels and 1 for stream-id registers + + reg-names: + minItems: 18 + items: + - const: sid + - const: broadcast + - const: ch0 + - const: ch1 + - const: ch2 + - const: ch3 + - const: ch4 + - const: ch5 + - const: ch6 + - const: ch7 + - const: ch8 + - const: ch9 + - const: ch10 + - const: ch11 + - const: ch12 + - const: ch13 + - const: ch14 + - const: ch15 additionalProperties: false required: - compatible - reg + - reg-names - interrupts - "#address-cells" - "#size-cells" @@ -182,7 +244,13 @@ examples: memory-controller@2c00000 { compatible = "nvidia,tegra186-mc"; - reg = <0x0 0x02c00000 0x0 0xb0000>; + reg = <0x0 0x02c00000 0x0 0x10000>, /* MC-SID */ + <0x0 0x02c10000 0x0 0x10000>, /* Broadcast channel */ + <0x0 0x02c20000 0x0 0x10000>, /* MC0 */ + <0x0 0x02c30000 0x0 0x10000>, /* MC1 */ + <0x0 0x02c40000 0x0 0x10000>, /* MC2 */ + <0x0 0x02c50000 0x0 0x10000>; /* MC3 */ + reg-names = "sid", "broadcast", "ch0", "ch1", "ch2", "ch3"; interrupts = ; #address-cells = <2>; -- cgit From 5dddb41692849594862473e4ddf57fb52e1249d6 Mon Sep 17 00:00:00 2001 From: Heikki Krogerus Date: Mon, 18 Apr 2022 17:59:32 +0000 Subject: thunderbolt: Link USB4 ports to their USB Type-C connectors Creating a symlink pointing to the correct USB Type-C connector for the on-board USB4 ports when they are created. The link will be created only if the firmware is able to describe the connection between the port and its connector. Signed-off-by: Heikki Krogerus Signed-off-by: Won Chung Signed-off-by: Mika Westerberg --- Documentation/ABI/testing/sysfs-bus-thunderbolt | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index b7e87f6c7d47..f7570c240ce8 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -293,6 +293,16 @@ Contact: thunderbolt-software@lists.01.org Description: This contains XDomain service specific settings as bitmask. Format: %x +What: /sys/bus/thunderbolt/devices/usb4_portX/connector +Date: April 2022 +Contact: Heikki Krogerus +Description: + Symlink to the USB Type-C connector. This link is only + created when USB Type-C Connector Class is enabled, + and only if the system firmware is capable of + describing the connection between a port and its + connector. + What: /sys/bus/thunderbolt/devices/usb4_portX/link Date: Sep 2021 KernelVersion: v5.14 -- cgit From dc6d04619e62825083926929d88c94c5b6b42670 Mon Sep 17 00:00:00 2001 From: Markuss Broks Date: Fri, 29 Apr 2022 15:09:14 +0300 Subject: regulator: sm5703: Correct reference to the common regulator schema The correct file name is regulator.yaml, not regulators.yaml. Signed-off-by: Markuss Broks Link: https://lore.kernel.org/r/20220429120914.9928-1-markuss.broks@gmail.com Signed-off-by: Mark Brown --- .../bindings/regulator/siliconmitus,sm5703-regulator.yaml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/siliconmitus,sm5703-regulator.yaml b/Documentation/devicetree/bindings/regulator/siliconmitus,sm5703-regulator.yaml index 75ff16b58000..9d84117530ca 100644 --- a/Documentation/devicetree/bindings/regulator/siliconmitus,sm5703-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/siliconmitus,sm5703-regulator.yaml @@ -19,14 +19,14 @@ description: | properties: buck: type: object - $ref: regulators.yaml# + $ref: regulator.yaml# unevaluatedProperties: false description: Properties for the BUCK regulator. vbus: type: object - $ref: regulators.yaml# + $ref: regulator.yaml# unevaluatedProperties: false description: Properties for the VBUS regulator. @@ -34,14 +34,14 @@ properties: patternProperties: "^ldo[1-3]$": type: object - $ref: regulators.yaml# + $ref: regulator.yaml# unevaluatedProperties: false description: Properties for single LDO regulator. "^usbldo[1-2]$": type: object - $ref: regulators.yaml# + $ref: regulator.yaml# unevaluatedProperties: false description: Properties for a single USBLDO regulator. -- cgit From 66727cdb250ec5d3f42558e33ace5c7d0fbd9477 Mon Sep 17 00:00:00 2001 From: YC Hung Date: Thu, 6 Jan 2022 14:48:48 +0800 Subject: ASoC: dsp: mediatek: add mt8195 dsp document This patch adds mt8195 dsp document. The dsp is used for Sound Open Firmware driver node. It includes registers, clocks, memory regions, and mailbox for dsp. Signed-off-by: yc.hung Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20220106064847.15588-1-yc.hung@mediatek.com Signed-off-by: Mark Brown --- .../bindings/dsp/mediatek,mt8195-dsp.yaml | 105 +++++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml new file mode 100644 index 000000000000..b7e68b0dfa13 --- /dev/null +++ b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dsp/mediatek,mt8195-dsp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek mt8195 DSP core + +maintainers: + - YC Hung + +description: | + Some boards from mt8195 contain a DSP core used for + advanced pre- and post- audio processing. + +properties: + compatible: + const: mediatek,mt8195-dsp + + reg: + items: + - description: Address and size of the DSP Cfg registers + - description: Address and size of the DSP SRAM + + reg-names: + items: + - const: cfg + - const: sram + + clocks: + items: + - description: mux for audio dsp clock + - description: 26M clock + - description: mux for audio dsp local bus + - description: default audio dsp local bus clock source + - description: clock gate for audio dsp clock + - description: mux for audio dsp access external bus + + clock-names: + items: + - const: adsp_sel + - const: clk26m_ck + - const: audio_local_bus + - const: mainpll_d7_d2 + - const: scp_adsp_audiodsp + - const: audio_h + + power-domains: + maxItems: 1 + + mboxes: + items: + - description: ipc reply between host and audio DSP. + - description: ipc request between host and audio DSP. + + mbox-names: + items: + - const: mbox0 + - const: mbox1 + + memory-region: + items: + - description: dma buffer between host and DSP. + - description: DSP system memory. + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - memory-region + - power-domains + - mbox-names + - mboxes + +additionalProperties: false + +examples: + - | + #include + #include + dsp@10803000 { + compatible = "mediatek,mt8195-dsp"; + reg = <0x10803000 0x1000>, + <0x10840000 0x40000>; + reg-names = "cfg", "sram"; + clocks = <&topckgen 10>, //CLK_TOP_ADSP + <&clk26m>, + <&topckgen 107>, //CLK_TOP_AUDIO_LOCAL_BUS + <&topckgen 136>, //CLK_TOP_MAINPLL_D7_D2 + <&scp_adsp 0>, //CLK_SCP_ADSP_AUDIODSP + <&topckgen 34>; //CLK_TOP_AUDIO_H + clock-names = "adsp_sel", + "clk26m_ck", + "audio_local_bus", + "mainpll_d7_d2", + "scp_adsp_audiodsp", + "audio_h"; + memory-region = <&adsp_dma_mem_reserved>, + <&adsp_mem_reserved>; + power-domains = <&spm 6>; //MT8195_POWER_DOMAIN_ADSP + mbox-names = "mbox0", "mbox1"; + mboxes = <&adsp_mailbox0>, <&adsp_mailbox1>; + }; -- cgit From d495f942f40aa412f8d4d65951152648cfa09903 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Fri, 22 Apr 2022 12:30:13 +0200 Subject: KVM: fix bad user ABI for KVM_EXIT_SYSTEM_EVENT When KVM_EXIT_SYSTEM_EVENT was introduced, it included a flags member that at the time was unused. Unfortunately this extensibility mechanism has several issues: - x86 is not writing the member, so it would not be possible to use it on x86 except for new events - the member is not aligned to 64 bits, so the definition of the uAPI struct is incorrect for 32- on 64-bit userspace. This is a problem for RISC-V, which supports CONFIG_KVM_COMPAT, but fortunately usage of flags was only introduced in 5.18. Since padding has to be introduced, place a new field in there that tells if the flags field is valid. To allow further extensibility, in fact, change flags to an array of 16 values, and store how many of the values are valid. The availability of the new ndata field is tied to a system capability; all architectures are changed to fill in the field. To avoid breaking compilation of userspace that was using the flags field, provide a userspace-only union to overlap flags with data[0]. The new field is placed at the same offset for both 32- and 64-bit userspace. Cc: Will Deacon Cc: Marc Zyngier Cc: Peter Gonda Cc: Sean Christopherson Signed-off-by: Paolo Bonzini Reported-by: kernel test robot Message-Id: <20220422103013.34832-1-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 85c7abc51af5..4a900cdbc62e 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -5986,16 +5986,16 @@ should put the acknowledged interrupt vector into the 'epr' field. #define KVM_SYSTEM_EVENT_RESET 2 #define KVM_SYSTEM_EVENT_CRASH 3 __u32 type; - __u64 flags; + __u32 ndata; + __u64 data[16]; } system_event; If exit_reason is KVM_EXIT_SYSTEM_EVENT then the vcpu has triggered a system-level event using some architecture specific mechanism (hypercall or some special instruction). In case of ARM64, this is triggered using -HVC instruction based PSCI call from the vcpu. The 'type' field describes -the system-level event type. The 'flags' field describes architecture -specific flags for the system-level event. +HVC instruction based PSCI call from the vcpu. +The 'type' field describes the system-level event type. Valid values for 'type' are: - KVM_SYSTEM_EVENT_SHUTDOWN -- the guest has requested a shutdown of the @@ -6010,10 +6010,20 @@ Valid values for 'type' are: to ignore the request, or to gather VM memory core dump and/or reset/shutdown of the VM. -Valid flags are: +If KVM_CAP_SYSTEM_EVENT_DATA is present, the 'data' field can contain +architecture specific information for the system-level event. Only +the first `ndata` items (possibly zero) of the data array are valid. - - KVM_SYSTEM_EVENT_RESET_FLAG_PSCI_RESET2 (arm64 only) -- the guest issued - a SYSTEM_RESET2 call according to v1.1 of the PSCI specification. + - for arm64, data[0] is set to KVM_SYSTEM_EVENT_RESET_FLAG_PSCI_RESET2 if + the guest issued a SYSTEM_RESET2 call according to v1.1 of the PSCI + specification. + + - for RISC-V, data[0] is set to the value of the second argument of the + ``sbi_system_reset`` call. + +Previous versions of Linux defined a `flags` member in this struct. The +field is now aliased to `data[0]`. Userspace can assume that it is only +written if ndata is greater than 0. :: -- cgit From 84e5ffd045f33e4fa32370135436d987478d0bf7 Mon Sep 17 00:00:00 2001 From: Lai Jiangshan Date: Wed, 20 Apr 2022 21:12:04 +0800 Subject: KVM: X86/MMU: Fix shadowing 5-level NPT for 4-level NPT L1 guest When shadowing 5-level NPT for 4-level NPT L1 guest, the root_sp is allocated with role.level = 5 and the guest pagetable's root gfn. And root_sp->spt[0] is also allocated with the same gfn and the same role except role.level = 4. Luckily that they are different shadow pages, but only root_sp->spt[0] is the real translation of the guest pagetable. Here comes a problem: If the guest switches from gCR4_LA57=0 to gCR4_LA57=1 (or vice verse) and uses the same gfn as the root page for nested NPT before and after switching gCR4_LA57. The host (hCR4_LA57=1) might use the same root_sp for the guest even the guest switches gCR4_LA57. The guest will see unexpected page mapped and L2 may exploit the bug and hurt L1. It is lucky that the problem can't hurt L0. And three special cases need to be handled: The root_sp should be like role.direct=1 sometimes: its contents are not backed by gptes, root_sp->gfns is meaningless. (For a normal high level sp in shadow paging, sp->gfns is often unused and kept zero, but it could be relevant and meaningful if sp->gfns is used because they are backed by concrete gptes.) For such root_sp in the case, root_sp is just a portal to contribute root_sp->spt[0], and root_sp->gfns should not be used and root_sp->spt[0] should not be dropped if gpte[0] of the guest root pagetable is changed. Such root_sp should not be accounted too. So add role.passthrough to distinguish the shadow pages in the hash when gCR4_LA57 is toggled and fix above special cases by using it in kvm_mmu_page_{get|set}_gfn() and sp_has_gptes(). Signed-off-by: Lai Jiangshan Message-Id: <20220420131204.2850-3-jiangshanlai@gmail.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/x86/mmu.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/x86/mmu.rst b/Documentation/virt/kvm/x86/mmu.rst index 5b1ebad24c77..8739120f4300 100644 --- a/Documentation/virt/kvm/x86/mmu.rst +++ b/Documentation/virt/kvm/x86/mmu.rst @@ -202,6 +202,10 @@ Shadow pages contain the following information: Is 1 if the MMU instance cannot use A/D bits. EPT did not have A/D bits before Haswell; shadow EPT page tables also cannot use A/D bits if the L1 hypervisor does not enable them. + role.passthrough: + The page is not backed by a guest page table, but its first entry + points to one. This is set if NPT uses 5-level page tables (host + CR4.LA57=1) and is shadowing L1's 4-level NPT (L1 CR4.LA57=1). gfn: Either the guest page table containing the translations shadowed by this page, or the base page frame for linear translations. See role.direct. -- cgit From 18f3976fdb5da2ba9572845e6f7dfb58652871ea Mon Sep 17 00:00:00 2001 From: Alexandru Elisei Date: Mon, 25 Apr 2022 12:44:44 +0100 Subject: KVM: arm64: uapi: Add kvm_debug_exit_arch.hsr_high When userspace is debugging a VM, the kvm_debug_exit_arch part of the kvm_run struct contains arm64 specific debug information: the ESR_EL2 value, encoded in the field "hsr", and the address of the instruction that caused the exception, encoded in the field "far". Linux has moved to treating ESR_EL2 as a 64-bit register, but unfortunately kvm_debug_exit_arch.hsr cannot be changed because that would change the memory layout of the struct on big endian machines: Current layout: | Layout with "hsr" extended to 64 bits: | offset 0: ESR_EL2[31:0] (hsr) | offset 0: ESR_EL2[61:32] (hsr[61:32]) offset 4: padding | offset 4: ESR_EL2[31:0] (hsr[31:0]) offset 8: FAR_EL2[61:0] (far) | offset 8: FAR_EL2[61:0] (far) which breaks existing code. The padding is inserted by the compiler because the "far" field must be aligned to 8 bytes (each field must be naturally aligned - aapcs64 [1], page 18), and the struct itself must be aligned to 8 bytes (the struct must be aligned to the maximum alignment of its fields - aapcs64, page 18), which means that "hsr" must be aligned to 8 bytes as it is the first field in the struct. To avoid changing the struct size and layout for the existing fields, add a new field, "hsr_high", which replaces the existing padding. "hsr_high" will be used to hold the ESR_EL2[61:32] bits of the register. The memory layout, both on big and little endian machine, becomes: offset 0: ESR_EL2[31:0] (hsr) offset 4: ESR_EL2[61:32] (hsr_high) offset 8: FAR_EL2[61:0] (far) The padding that the compiler inserts for the current struct layout is unitialized. To prevent an updated userspace running on an old kernel mistaking the padding for a valid "hsr_high" value, add a new flag, KVM_DEBUG_ARCH_HSR_HIGH_VALID, to kvm_run->flags to let userspace know that "hsr_high" holds a valid ESR_EL2[61:32] value. [1] https://github.com/ARM-software/abi-aa/releases/download/2021Q3/aapcs64.pdf Signed-off-by: Alexandru Elisei Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20220425114444.368693-6-alexandru.elisei@arm.com Signed-off-by: Catalin Marinas --- Documentation/virt/kvm/api.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 85c7abc51af5..ecd70d99f3e0 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -5713,6 +5713,8 @@ affect the device's behavior. Current defined flags:: #define KVM_RUN_X86_SMM (1 << 0) /* x86, set if bus lock detected in VM */ #define KVM_RUN_BUS_LOCK (1 << 1) + /* arm64, set for KVM_EXIT_DEBUG */ + #define KVM_DEBUG_ARCH_HSR_HIGH_VALID (1 << 0) :: -- cgit From 1e69a83a5e1aae7a1e6079cf306fc72087a059d9 Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Fri, 29 Apr 2022 14:20:55 -0300 Subject: dt-bindings: display: simple: Add Startek KD070WVFPA043-C069A panel Add Startek KD070WVFPA043-C069A 7" TFT LCD panel compatible string. Signed-off-by: Fabio Estevam Acked-by: Sam Ravnborg Reviewed-by: Marek Vasut Signed-off-by: Marek Vasut Link: https://patchwork.freedesktop.org/patch/msgid/20220429172056.3499563-1-festevam@gmail.com --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index cfe7bb9f89de..21ba90c9fe33 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -296,6 +296,8 @@ properties: - starry,kr070pe2t # Starry 12.2" (1920x1200 pixels) TFT LCD panel - starry,kr122ea0sra + # Startek KD070WVFPA043-C069A 7" TFT LCD panel + - startek,kd070wvfpa # Team Source Display Technology TST043015CMHX 4.3" WQVGA TFT LCD panel - team-source-display,tst043015cmhx # Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel -- cgit From 30226b69f8767a822f87c2c92bf6d4fbf545cee1 Mon Sep 17 00:00:00 2001 From: Brian Geffon Date: Fri, 29 Apr 2022 14:36:59 -0700 Subject: zram: add a huge_idle writeback mode Today it's only possible to write back as a page, idle, or huge. A user might want to writeback pages which are huge and idle first as these idle pages do not require decompression and make a good first pass for writeback. Idle writeback specifically has the advantage that a refault is unlikely given that the page has been swapped for some amount of time without being refaulted. Huge writeback has the advantage that you're guaranteed to get the maximum benefit from a single page writeback, that is, you're reclaiming one full page of memory. Pages which are compressed in zram being written back result in some benefit which is always less than a page size because of the fact that it was compressed. The primary use of this is for minimizing refaults in situations where the device has to be sensitive to storage endurance. On ChromeOS we have devices with slow eMMC and repeated writes and refaults can negatively affect performance and endurance. Link: https://lkml.kernel.org/r/20220322215821.1196994-1-bgeffon@google.com Signed-off-by: Brian Geffon Acked-by: Minchan Kim Cc: Nitin Gupta Cc: Sergey Senozhatsky Signed-off-by: Andrew Morton --- Documentation/admin-guide/blockdev/zram.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst index 54fe63745ed8..c73b16930449 100644 --- a/Documentation/admin-guide/blockdev/zram.rst +++ b/Documentation/admin-guide/blockdev/zram.rst @@ -343,6 +343,11 @@ Admin can request writeback of those idle pages at right timing via:: With the command, zram will writeback idle pages from memory to the storage. +Additionally, if a user choose to writeback only huge and idle pages +this can be accomplished with:: + + echo huge_idle > /sys/block/zramX/writeback + If an admin wants to write a specific page in zram device to the backing device, they could write a page index into the interface. -- cgit From 94968384dde15d48263bfc59d280cd71b1259d8c Mon Sep 17 00:00:00 2001 From: Shakeel Butt Date: Fri, 29 Apr 2022 14:36:59 -0700 Subject: memcg: introduce per-memcg reclaim interface This patch series adds a memory.reclaim proactive reclaim interface. The rationale behind the interface and how it works are in the first patch. This patch (of 4): Introduce a memcg interface to trigger memory reclaim on a memory cgroup. Use case: Proactive Reclaim --------------------------- A userspace proactive reclaimer can continuously probe the memcg to reclaim a small amount of memory. This gives more accurate and up-to-date workingset estimation as the LRUs are continuously sorted and can potentially provide more deterministic memory overcommit behavior. The memory overcommit controller can provide more proactive response to the changing behavior of the running applications instead of being reactive. A userspace reclaimer's purpose in this case is not a complete replacement for kswapd or direct reclaim, it is to proactively identify memory savings opportunities and reclaim some amount of cold pages set by the policy to free up the memory for more demanding jobs or scheduling new jobs. A user space proactive reclaimer is used in Google data centers. Additionally, Meta's TMO paper recently referenced a very similar interface used for user space proactive reclaim: https://dl.acm.org/doi/pdf/10.1145/3503222.3507731 Benefits of a user space reclaimer: ----------------------------------- 1) More flexible on who should be charged for the cpu of the memory reclaim. For proactive reclaim, it makes more sense to be centralized. 2) More flexible on dedicating the resources (like cpu). The memory overcommit controller can balance the cost between the cpu usage and the memory reclaimed. 3) Provides a way to the applications to keep their LRUs sorted, so, under memory pressure better reclaim candidates are selected. This also gives more accurate and uptodate notion of working set for an application. Why memory.high is not enough? ------------------------------ - memory.high can be used to trigger reclaim in a memcg and can potentially be used for proactive reclaim. However there is a big downside in using memory.high. It can potentially introduce high reclaim stalls in the target application as the allocations from the processes or the threads of the application can hit the temporary memory.high limit. - Userspace proactive reclaimers usually use feedback loops to decide how much memory to proactively reclaim from a workload. The metrics used for this are usually either refaults or PSI, and these metrics will become messy if the application gets throttled by hitting the high limit. - memory.high is a stateful interface, if the userspace proactive reclaimer crashes for any reason while triggering reclaim it can leave the application in a bad state. - If a workload is rapidly expanding, setting memory.high to proactively reclaim memory can result in actually reclaiming more memory than intended. The benefits of such interface and shortcomings of existing interface were further discussed in this RFC thread: https://lore.kernel.org/linux-mm/5df21376-7dd1-bf81-8414-32a73cea45dd@google.com/ Interface: ---------- Introducing a very simple memcg interface 'echo 10M > memory.reclaim' to trigger reclaim in the target memory cgroup. The interface is introduced as a nested-keyed file to allow for future optional arguments to be easily added to configure the behavior of reclaim. Possible Extensions: -------------------- - This interface can be extended with an additional parameter or flags to allow specifying one or more types of memory to reclaim from (e.g. file, anon, ..). - The interface can also be extended with a node mask to reclaim from specific nodes. This has use cases for reclaim-based demotion in memory tiering systens. - A similar per-node interface can also be added to support proactive reclaim and reclaim-based demotion in systems without memcg. - Add a timeout parameter to make it easier for user space to call the interface without worrying about being blocked for an undefined amount of time. For now, let's keep things simple by adding the basic functionality. [yosryahmed@google.com: worked on versions v2 onwards, refreshed to current master, updated commit message based on recent discussions and use cases] Link: https://lkml.kernel.org/r/20220425190040.2475377-1-yosryahmed@google.com Link: https://lkml.kernel.org/r/20220425190040.2475377-2-yosryahmed@google.com Signed-off-by: Shakeel Butt Co-developed-by: Yosry Ahmed Signed-off-by: Yosry Ahmed Acked-by: Johannes Weiner Acked-by: Michal Hocko Acked-by: Wei Xu Acked-by: Roman Gushchin Acked-by: David Rientjes Cc: Tejun Heo Cc: Zefan Li Cc: Jonathan Corbet Cc: Shuah Khan Cc: Yu Zhao Cc: Dave Hansen Cc: Greg Thelen Cc: Chen Wandun Cc: Vaibhav Jain Cc: "Michal Koutn" Cc: Tim Chen Signed-off-by: Andrew Morton --- Documentation/admin-guide/cgroup-v2.rst | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 69d7a6983f78..19bcd73cad03 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1208,6 +1208,27 @@ PAGE_SIZE multiple when read back. high limit is used and monitored properly, this limit's utility is limited to providing the final safety net. + memory.reclaim + A write-only nested-keyed file which exists for all cgroups. + + This is a simple interface to trigger memory reclaim in the + target cgroup. + + This file accepts a single key, the number of bytes to reclaim. + No nested keys are currently supported. + + Example:: + + echo "1G" > memory.reclaim + + The interface can be later extended with nested keys to + configure the reclaim behavior. For example, specify the + type of memory to reclaim from (anon, file, ..). + + Please note that the kernel can over or under reclaim from + the target cgroup. If less bytes are reclaimed than the + specified amount, -EAGAIN is returned. + memory.oom.group A read-write single value file which exists on non-root cgroups. The default value is "0". -- cgit From 749c61e5b30a18037fcae27694cd949c4d652205 Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Wed, 27 Apr 2022 23:44:04 +0200 Subject: dt-bindings: net: micrel: add coma-mode-gpios property The LAN8814 has a coma mode pin which is used to put the PHY into isolate and power-down mode. Usually strapped to be asserted by default. A GPIO is then used to take the PHY out of this mode. Signed-off-by: Michael Walle Acked-by: Rob Herring Signed-off-by: Jakub Kicinski --- Documentation/devicetree/bindings/net/micrel.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt index 8d157f0295a5..a9ed691ffb03 100644 --- a/Documentation/devicetree/bindings/net/micrel.txt +++ b/Documentation/devicetree/bindings/net/micrel.txt @@ -45,3 +45,12 @@ Optional properties: In fiber mode, auto-negotiation is disabled and the PHY can only work in 100base-fx (full and half duplex) modes. + + - coma-mode-gpios: If present the given gpio will be deasserted when the + PHY is probed. + + Some PHYs have a COMA mode input pin which puts the PHY into + isolate and power-down mode. On some boards this input is connected + to a GPIO of the SoC. + + Supported on the LAN8814. -- cgit From 6bb63ccc25d4a8cb8fe48efeda680cb13f84d1b0 Mon Sep 17 00:00:00 2001 From: Mat Martineau Date: Wed, 27 Apr 2022 15:50:01 -0700 Subject: mptcp: Add a per-namespace sysctl to set the default path manager type The new net.mptcp.pm_type sysctl determines which path manager will be used by each newly-created MPTCP socket. v2: Handle builds without CONFIG_SYSCTL v3: Clarify logic for type-specific PM init (Geliang Tang and Paolo Abeni) Acked-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski --- Documentation/networking/mptcp-sysctl.rst | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst index b0d4da71e68e..e263dfcc4b40 100644 --- a/Documentation/networking/mptcp-sysctl.rst +++ b/Documentation/networking/mptcp-sysctl.rst @@ -46,6 +46,24 @@ allow_join_initial_addr_port - BOOLEAN Default: 1 +pm_type - INTEGER + + Set the default path manager type to use for each new MPTCP + socket. In-kernel path management will control subflow + connections and address advertisements according to + per-namespace values configured over the MPTCP netlink + API. Userspace path management puts per-MPTCP-connection subflow + connection decisions and address advertisements under control of + a privileged userspace program, at the cost of more netlink + traffic to propagate all of the related events and commands. + + This is a per-namespace sysctl. + + * 0 - In-kernel path manager + * 1 - Userspace path manager + + Default: 0 + stale_loss_cnt - INTEGER The number of MPTCP-level retransmission intervals with no traffic and pending outstanding data on a given subflow required to declare it stale. -- cgit From 4fdabd509df3fb5e731031197034cb02f053731a Mon Sep 17 00:00:00 2001 From: Michael Walle Date: Thu, 28 Apr 2022 13:40:48 +0200 Subject: dt-bindings: net: lan966x: remove PHY reset The PHY reset was intended to be a phandle for a special PHY reset driver for the integrated PHYs as well as any external PHYs. It turns out, that the culprit is how the reset of the switch device is done. In particular, the switch reset also affects other subsystems like the GPIO and the SGPIO block and it happens to be the case that the reset lines of the external PHYs are connected to a common GPIO line. Thus as soon as the switch issues a reset during probe time, all the external PHYs will go into reset because all the GPIO lines will switch to input and the pull-down on that signal will take effect. So even if there was a special PHY reset driver, it (1) won't fix the root cause of the problem and (2) it won't fix all the other consumers of GPIO lines which will also be reset. It turns out, the Ocelot SoC has the same weird behavior (or the lack of a dedicated switch reset) and there the problem is already solved and all the bits and pieces are already there and this PHY reset property isn't not needed at all. There are no users of this binding. Just remove it. Signed-off-by: Michael Walle Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml index 131dc5a652de..f3ed708de0eb 100644 --- a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml +++ b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml @@ -53,12 +53,10 @@ properties: resets: items: - description: Reset controller used for switch core reset (soft reset) - - description: Reset controller used for releasing the phy from reset reset-names: items: - const: switch - - const: phy ethernet-ports: type: object -- cgit From c37415f55bdadffe5b4c0e7981e9fc7e8b96beea Mon Sep 17 00:00:00 2001 From: Peter Geis Date: Fri, 29 Apr 2022 07:52:46 -0400 Subject: dt-bindings: arm: rockchip: Add Pine64 Quartz64 Model B The Quartz64 Model B is a compact single board computer from Pine64 based on the rk3566 SoC. It outputs on uart2 for the debug console. Signed-off-by: Peter Geis Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220429115252.2360496-2-pgwipeout@gmail.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index efb0a9c4347b..6fa95ff92a98 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -502,9 +502,11 @@ properties: - const: pine64,rockpro64 - const: rockchip,rk3399 - - description: Pine64 Quartz64 Model A + - description: Pine64 Quartz64 Model A/B items: - - const: pine64,quartz64-a + - enum: + - pine64,quartz64-a + - pine64,quartz64-b - const: rockchip,rk3566 - description: Radxa Rock -- cgit From c466828fb3ba8cb7f5c3bf28766da9b70bf9745e Mon Sep 17 00:00:00 2001 From: Peter Geis Date: Fri, 29 Apr 2022 07:52:47 -0400 Subject: dt-bindings: arm: rockchip: Add Pine64 SoQuartz SoM The SoQuartz system on module is designed to be pin compatible with the RPi CM4 SoM. It is based on the rk3566 SoC and outputs on uart2 for debug and console. The first carrier board supported is the CM4IO board from RPi. Signed-off-by: Peter Geis Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220429115252.2360496-3-pgwipeout@gmail.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 6fa95ff92a98..ea8dcbc5106f 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -509,6 +509,13 @@ properties: - pine64,quartz64-b - const: rockchip,rk3566 + - description: Pine64 SoQuartz SoM + items: + - enum: + - pine64,soquartz-cm4io + - const: pine64,soquartz + - const: rockchip,rk3566 + - description: Radxa Rock items: - const: radxa,rock -- cgit From e52ded5543708e0382f236ce35372a63f4568341 Mon Sep 17 00:00:00 2001 From: Peter Geis Date: Fri, 29 Apr 2022 07:52:48 -0400 Subject: dt-bindings: arm: rockchip: Add Firefly Station M2 The Station M2 is a compact single board computer based on the rk3566 SoC. It outputs on uart2 for debug and console purposes. Signed-off-by: Peter Geis Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220429115252.2360496-4-pgwipeout@gmail.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index ea8dcbc5106f..cf9eb1e8326a 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -133,6 +133,11 @@ properties: - firefly,roc-rk3399-pc-plus - const: rockchip,rk3399 + - description: Firefly Station M2 + items: + - const: firefly,rk3566-roc-pc + - const: rockchip,rk3566 + - description: FriendlyElec NanoPi R2S items: - const: friendlyarm,nanopi-r2s -- cgit From a12d521f4a3d2088f23b75f063de68ea1dc6b5a3 Mon Sep 17 00:00:00 2001 From: Sven Peter Date: Sun, 1 May 2022 16:55:07 +0200 Subject: dt-bindings: iommu: Add Apple SART DMA address filter Apple SoCs such as the M1 come with a simple DMA address filter called SART. Unlike a real IOMMU no pagetables can be configured but instead DMA transactions can be allowed for up to 16 paddr regions. The consumer also needs special support since not all DMA allocations have to be added to this filter. Reviewed-by: Rob Herring Signed-off-by: Sven Peter --- .../devicetree/bindings/iommu/apple,sart.yaml | 52 ++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/apple,sart.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iommu/apple,sart.yaml b/Documentation/devicetree/bindings/iommu/apple,sart.yaml new file mode 100644 index 000000000000..1524fa3094ef --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/apple,sart.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iommu/apple,sart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple SART DMA address filter + +maintainers: + - Sven Peter + +description: + Apple SART is a simple address filter for DMA transactions. Regions of + physical memory must be added to the SART's allow list before any + DMA can target these. Unlike a proper IOMMU no remapping can be done and + special support in the consumer driver is required since not all DMA + transactions of a single device are subject to SART filtering. + + SART1 has first been used since at least the A11 (iPhone 8 and iPhone X) + and allows 36 bit of physical address space and filter entries with sizes + up to 24 bit. + + SART2, first seen in A14 and M1, allows 36 bit of physical address space + and filter entry size up to 36 bit. + + SART3, first seen in M1 Pro/Max, extends both the address space and filter + entry size to 42 bit. + +properties: + compatible: + enum: + - apple,t6000-sart + - apple,t8103-sart + + reg: + maxItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + iommu@7bc50000 { + compatible = "apple,t8103-sart"; + reg = <0x7bc50000 0x4000>; + }; -- cgit From 49714461b7970acb38c421a48f5d7f782e360003 Mon Sep 17 00:00:00 2001 From: Alexandru Tachici Date: Fri, 29 Apr 2022 18:34:37 +0300 Subject: dt-bindings: net: phy: Add 10-baseT1L 2.4 Vpp Add a tristate property to advertise desired transmit level. If the device supports the 2.4 Vpp operating mode for 10BASE-T1L, as defined in 802.3gc, and the 2.4 Vpp transmit voltage operation is desired, property should be set to 1. This property is used to select whether Auto-Negotiation advertises a request to operate the 10BASE-T1L PHY in increased transmit level mode. If property is set to 1, the PHY shall advertise a request to operate the 10BASE-T1L PHY in increased transmit level mode. If property is set to zero, the PHY shall not advertise a request to operate the 10BASE-T1L PHY in increased transmit level mode. Reviewed-by: Rob Herring Signed-off-by: Alexandru Tachici Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/ethernet-phy.yaml | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml index ee42328a109d..ed1415a4381f 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml @@ -77,6 +77,15 @@ properties: description: Maximum PHY supported speed in Mbits / seconds. + phy-10base-t1l-2.4vpp: + description: | + tristate, request/disable 2.4 Vpp operating mode. The values are: + 0: Disable 2.4 Vpp operating mode. + 1: Request 2.4 Vpp operating mode from link partner. + Absence of this property will leave configuration to default values. + $ref: "/schemas/types.yaml#/definitions/uint32" + enum: [0, 1] + broken-turn-around: $ref: /schemas/types.yaml#/definitions/flag description: -- cgit From e678acedf364a8843388af4e1e0ebe854f2e0e8c Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 22 Apr 2022 14:20:39 -0500 Subject: dt-bindings: iio: Fix incorrect compatible strings in examples Fix a couple of examples using incorrect compatible strings. Signed-off-by: Rob Herring Reviewed-by: Slawomir Stepien Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220422192039.2590548-1-robh@kernel.org Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/dac/lltc,ltc2632.yaml | 2 +- .../devicetree/bindings/iio/potentiometer/microchip,mcp4131.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/lltc,ltc2632.yaml b/Documentation/devicetree/bindings/iio/dac/lltc,ltc2632.yaml index edf804d0aca2..b1eb77335d05 100644 --- a/Documentation/devicetree/bindings/iio/dac/lltc,ltc2632.yaml +++ b/Documentation/devicetree/bindings/iio/dac/lltc,ltc2632.yaml @@ -68,7 +68,7 @@ examples: #size-cells = <0>; dac@0 { - compatible = "lltc,ltc2632"; + compatible = "lltc,ltc2632-l12"; reg = <0>; /* CS0 */ spi-max-frequency = <1000000>; vref-supply = <&vref>; diff --git a/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4131.yaml b/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4131.yaml index 945a2d644ddc..32e92bced81f 100644 --- a/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4131.yaml +++ b/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4131.yaml @@ -95,7 +95,7 @@ examples: #size-cells = <0>; potentiometer@0 { - compatible = "mcp4131-502"; + compatible = "microchip,mcp4131-502"; reg = <0>; spi-max-frequency = <500000>; }; -- cgit From 644664627d21648735adfa733956f94064d3417d Mon Sep 17 00:00:00 2001 From: Mimi Zohar Date: Thu, 14 Apr 2022 16:46:39 -0400 Subject: ima: fix 'd-ng' comments and documentation Initially the 'd-ng' template field did not prefix the digest with either "md5" or "sha1" hash algorithms. Prior to being upstreamed this changed, but the comments and documentation were not updated. Fix the comments and documentation. Fixes: 4d7aeee73f53 ("ima: define new template ima-ng and template fields d-ng and n-ng") Reported-by: Eric Biggers Reviewed-by: Stefan Berger Signed-off-by: Mimi Zohar --- Documentation/security/IMA-templates.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/security/IMA-templates.rst b/Documentation/security/IMA-templates.rst index 1a91d92950a7..cab97f49971d 100644 --- a/Documentation/security/IMA-templates.rst +++ b/Documentation/security/IMA-templates.rst @@ -66,8 +66,7 @@ descriptors by adding their identifier to the format string calculated with the SHA1 or MD5 hash algorithm; - 'n': the name of the event (i.e. the file name), with size up to 255 bytes; - 'd-ng': the digest of the event, calculated with an arbitrary hash - algorithm (field format: [:]digest, where the digest - prefix is shown only if the hash algorithm is not SHA1 or MD5); + algorithm (field format: :digest); - 'd-modsig': the digest of the event without the appended modsig; - 'n-ng': the name of the event, without size limitations; - 'sig': the file signature, or the EVM portable signature if the file -- cgit From 3e4659f98ef93de21ea69ac8222d02367da79de6 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Wed, 20 Apr 2022 21:15:49 -0700 Subject: dt-bindings: display: msm: Add optional resets Add an optional reference to the MDSS_CORE reset, which when specified can be used by the implementation to reset the hardware blocks. Reviewed-by: Dmitry Baryshkov Acked-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Patchwork: https://patchwork.freedesktop.org/patch/482794/ Link: https://lore.kernel.org/r/20220421041550.643964-1-bjorn.andersson@linaro.org Signed-off-by: Dmitry Baryshkov --- Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml | 4 ++++ Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml | 4 ++++ Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml | 4 ++++ Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml | 4 ++++ 4 files changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml index d31483a78eab..07c68f8ee6f9 100644 --- a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml +++ b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml @@ -66,6 +66,10 @@ properties: interconnect-names: const: mdp0-mem + resets: + items: + - description: MDSS_CORE reset + patternProperties: "^display-controller@[0-9a-f]+$": type: object diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml index 12a86b1ec1bc..b41991eaa454 100644 --- a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml @@ -65,6 +65,10 @@ properties: interconnect-names: const: mdp0-mem + resets: + items: + - description: MDSS_CORE reset + patternProperties: "^display-controller@[0-9a-f]+$": type: object diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml index fbeb931a026e..6e417d06fc79 100644 --- a/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml @@ -64,6 +64,10 @@ properties: interconnect-names: const: mdp0-mem + resets: + items: + - description: MDSS_CORE reset + patternProperties: "^display-controller@[0-9a-f]+$": type: object diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml index 0dca4b3d66e4..1a42491efdbc 100644 --- a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml +++ b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml @@ -57,6 +57,10 @@ properties: ranges: true + resets: + items: + - description: MDSS_CORE reset + patternProperties: "^display-controller@[0-9a-f]+$": type: object -- cgit From 81c653659d34ec253fba7f5d0f430813fe0f643d Mon Sep 17 00:00:00 2001 From: Joel Savitz Date: Thu, 24 Mar 2022 18:11:56 -0400 Subject: Documentation/sysctl: document max_rcu_stall_to_panic commit dfe564045c65 ("rcu: Panic after fixed number of stalls") introduced a new systctl but no accompanying documentation. Add a simple entry to the documentation. Signed-off-by: Joel Savitz Acked-by: Paul E. McKenney Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/sysctl/kernel.rst | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 1144ea3229a3..545d2d7420a1 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -783,6 +783,13 @@ is useful to define the root cause of RCU stalls using a vmcore. 1 panic() after printing RCU stall messages. = ============================================================ +max_rcu_stall_to_panic +====================== + +When ``panic_on_rcu_stall`` is set to 1, this value determines the +number of times that RCU can stall before panic() is called. + +When ``panic_on_rcu_stall`` is set to 0, this value is has no effect. perf_cpu_time_max_percent ========================= -- cgit From 55427d5b0dff5754f3579dde93955aac483e8d6a Mon Sep 17 00:00:00 2001 From: Max Filippov Date: Wed, 13 Apr 2022 20:41:12 -0700 Subject: xtensa: enable context tracking Put user exit context tracking call on the common kernel entry/exit path (function calls are impossible at earlier kernel entry stages because PS.EXCM is not cleared yet). Put user entry context tracking call on the user exit path. Syscalls go through this common code too, so nothing specific needs to be done for them. Signed-off-by: Max Filippov --- Documentation/features/time/context-tracking/arch-support.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/features/time/context-tracking/arch-support.txt b/Documentation/features/time/context-tracking/arch-support.txt index bb1c1801553e..72e7aadeda7e 100644 --- a/Documentation/features/time/context-tracking/arch-support.txt +++ b/Documentation/features/time/context-tracking/arch-support.txt @@ -27,5 +27,5 @@ | sparc: | ok | | um: | TODO | | x86: | ok | - | xtensa: | TODO | + | xtensa: | ok | ----------------------- -- cgit From 507185695e93c70aced2f419892bc2ab9387b324 Mon Sep 17 00:00:00 2001 From: Max Filippov Date: Wed, 13 Apr 2022 20:40:10 -0700 Subject: xtensa: enable HAVE_VIRT_CPU_ACCOUNTING_GEN There's no direct cputime_t manipulation in the xtensa arch code, so generic virt CPU accounting may be enabled. Signed-off-by: Max Filippov --- Documentation/features/time/virt-cpuacct/arch-support.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/features/time/virt-cpuacct/arch-support.txt b/Documentation/features/time/virt-cpuacct/arch-support.txt index 5163a60a1c1e..c905aa3c1d81 100644 --- a/Documentation/features/time/virt-cpuacct/arch-support.txt +++ b/Documentation/features/time/virt-cpuacct/arch-support.txt @@ -27,5 +27,5 @@ | sparc: | ok | | um: | TODO | | x86: | ok | - | xtensa: | TODO | + | xtensa: | ok | ----------------------- -- cgit From af7a16e567aec884276c2523eadf22dda547f949 Mon Sep 17 00:00:00 2001 From: Max Filippov Date: Mon, 25 Apr 2022 10:59:04 -0700 Subject: xtensa: enable ARCH_HAS_DEBUG_VM_PGTABLE xtensa kernels successfully build and run with CONFIG_DEBUG_VM_PGTABLE=y, enable arch support for it. Reviewed-by: Anshuman Khandual Signed-off-by: Max Filippov --- Documentation/features/debug/debug-vm-pgtable/arch-support.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt index 83eafe1a7f68..ff21a83abe62 100644 --- a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt +++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt @@ -27,5 +27,5 @@ | sparc: | TODO | | um: | TODO | | x86: | ok | - | xtensa: | TODO | + | xtensa: | ok | ----------------------- -- cgit From 35a78bf20033d5d7b1c53cb5616732dbf6ec9890 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Sat, 23 Apr 2022 14:07:43 +0100 Subject: dt-bindings: can: renesas,rcar-canfd: Document RZ/G2UL support Add CANFD binding documentation for Renesas R9A07G043 (RZ/G2UL) SoC. Link: https://lore.kernel.org/all/20220423130743.123198-1-biju.das.jz@bp.renesas.com Signed-off-by: Biju Das Acked-by: Krzysztof Kozlowski Reviewed-by: Geert Uytterhoeven Signed-off-by: Marc Kleine-Budde --- Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml index 648740270731..9fc137fafed9 100644 --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml @@ -33,6 +33,7 @@ properties: - items: - enum: + - renesas,r9a07g043-canfd # RZ/G2UL - renesas,r9a07g044-canfd # RZ/G2{L,LC} - renesas,r9a07g054-canfd # RZ/V2L - const: renesas,rzg2l-canfd # RZ/G2L family -- cgit From 5f02ecbe08d6a3434a14b92bee98adec76e8808e Mon Sep 17 00:00:00 2001 From: Pavel Pisa Date: Sun, 24 Apr 2022 18:28:11 +0200 Subject: docs: networking: device drivers: can: add ctucanfd to index This patch adds the ctucanfd-driver document to the index. Link: https://lore.kernel.org/all/e4396244da6b008c671def9f50bb983a10389863.1650816929.git.pisa@cmp.felk.cvut.cz Signed-off-by: Pavel Pisa [mkl: split into separate patches] Signed-off-by: Marc Kleine-Budde --- Documentation/networking/device_drivers/can/index.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/can/index.rst b/Documentation/networking/device_drivers/can/index.rst index 58b6e0ad3030..0c3cc6633559 100644 --- a/Documentation/networking/device_drivers/can/index.rst +++ b/Documentation/networking/device_drivers/can/index.rst @@ -10,6 +10,7 @@ Contents: .. toctree:: :maxdepth: 2 + ctu/ctucanfd-driver freescale/flexcan .. only:: subproject and html -- cgit From 75790ef3b796abefe9a0f6a90288b7ae9971fd3c Mon Sep 17 00:00:00 2001 From: Pavel Pisa Date: Sun, 24 Apr 2022 18:28:11 +0200 Subject: docs: networking: device drivers: can: ctucanfd: update author e-mail This patch updates the author's email address. Link: https://lore.kernel.org/all/e4396244da6b008c671def9f50bb983a10389863.1650816929.git.pisa@cmp.felk.cvut.cz Cc: Odrej Ille Signed-off-by: Pavel Pisa [mkl: split into separate patches] Signed-off-by: Marc Kleine-Budde --- Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst b/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst index 797fb45be187..2fde5551e756 100644 --- a/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst +++ b/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst @@ -536,7 +536,7 @@ CTU CAN FD Driver Sources Reference CTU CAN FD IP Core and Driver Development Acknowledgment --------------------------------------------------------- -* Odrej Ille +* Odrej Ille * started the project as student at Department of Measurement, FEE, CTU * invested great amount of personal time and enthusiasm to the project over years -- cgit From bb419dc67bb51d15740df5a775da1de057e4b2fb Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 25 Apr 2022 16:04:35 +0200 Subject: dt-bindings: arm: stm32: narrow DH STM32MP1 SoM boards The bindings for DH STM32MP1 SoM boards allows invalid combinations, e.g. st,stm32mp153 SoC on a dh,stm32mp157c-dhcom-som SoM. Split the enums to properly match valid setups. Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Alexandre Torgue --- .../devicetree/bindings/arm/stm32/stm32.yaml | 37 +++++++++++++--------- 1 file changed, 22 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index fa0a1b84122e..2f83f2760e6a 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -14,21 +14,6 @@ properties: const: "/" compatible: oneOf: - - description: DH STM32MP1 SoM based Boards - items: - - enum: - - arrow,stm32mp157a-avenger96 # Avenger96 - - dh,stm32mp153c-dhcom-drc02 - - dh,stm32mp157c-dhcom-pdk2 - - dh,stm32mp157c-dhcom-picoitx - - enum: - - dh,stm32mp153c-dhcom-som - - dh,stm32mp157a-dhcor-som - - dh,stm32mp157c-dhcom-som - - enum: - - st,stm32mp153 - - st,stm32mp157 - - description: emtrion STM32MP1 Argon based Boards items: - const: emtrion,stm32mp157c-emsbc-argon @@ -65,6 +50,13 @@ properties: - enum: - st,stm32mp135f-dk - const: st,stm32mp135 + + - description: DH STM32MP153 SoM based Boards + items: + - const: dh,stm32mp153c-dhcom-drc02 + - const: dh,stm32mp153c-dhcom-som + - const: st,stm32mp153 + - items: - enum: - shiratech,stm32mp157a-iot-box # IoT Box @@ -79,6 +71,21 @@ properties: - const: st,stm32mp157c-ed1 - const: st,stm32mp157 + - description: DH STM32MP1 SoM based Boards + items: + - enum: + - arrow,stm32mp157a-avenger96 # Avenger96 + - const: dh,stm32mp157a-dhcor-som + - const: st,stm32mp157 + + - description: DH STM32MP1 SoM based Boards + items: + - enum: + - dh,stm32mp157c-dhcom-pdk2 + - dh,stm32mp157c-dhcom-picoitx + - const: dh,stm32mp157c-dhcom-som + - const: st,stm32mp157 + - description: Engicam i.Core STM32MP1 SoM based Boards items: - enum: -- cgit From 5d68f9798d7da8a1004d3d09e56dc7b379700016 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 25 Apr 2022 16:04:36 +0200 Subject: dt-bindings: arm: stm32: correct blank lines Correct blank lines to precesily separate entries. Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Alexandre Torgue --- Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 2f83f2760e6a..80b29f6903f0 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -64,8 +64,8 @@ properties: - st,stm32mp157c-ed1 - st,stm32mp157a-dk1 - st,stm32mp157c-dk2 - - const: st,stm32mp157 + - items: - const: st,stm32mp157c-ev1 - const: st,stm32mp157c-ed1 @@ -110,6 +110,7 @@ properties: - const: oct,stm32mp15xx-osd32 - enum: - st,stm32mp157 + - description: Odyssey STM32MP1 SoM based Boards items: - enum: -- cgit From c70bb467fb211fadd2c1360892a498330d8a94a6 Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Tue, 26 Apr 2022 09:35:08 +0200 Subject: dt-bindings: arm: stm32: Add compatible strings for Protonic T1L boards This boards are based on STM32MP151AAD3 and use 10BaseT1L for communication. - PRTT1C - 10BaseT1L switch - PRTT1S - 10BaseT1L CO2 sensor board - PRTT1A - 10BaseT1L multi functional controller Signed-off-by: Oleksij Rempel Acked-by: Krzysztof Kozlowski Signed-off-by: Alexandre Torgue --- Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 80b29f6903f0..a93c60241f28 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -51,6 +51,14 @@ properties: - st,stm32mp135f-dk - const: st,stm32mp135 + - description: ST STM32MP151 based Boards + items: + - enum: + - prt,prtt1a # Protonic PRTT1A + - prt,prtt1c # Protonic PRTT1C + - prt,prtt1s # Protonic PRTT1S + - const: st,stm32mp151 + - description: DH STM32MP153 SoM based Boards items: - const: dh,stm32mp153c-dhcom-drc02 -- cgit From 94de07e5565be51d91dd91dcae6ede54c0f9be27 Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Tue, 26 Apr 2022 09:35:09 +0200 Subject: dt-bindings: net: silabs,wfx: add prt,prtt1c-wfm200 antenna variant Add compatible for wfm200 antenna configuration variant for Protonic PRTT1C board. Signed-off-by: Oleksij Rempel Acked-by: Krzysztof Kozlowski Signed-off-by: Alexandre Torgue --- Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml b/Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml index 105725a127ab..ce107fe45d7c 100644 --- a/Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml +++ b/Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml @@ -39,6 +39,7 @@ properties: compatible: items: - enum: + - prt,prtt1c-wfm200 # Protonic PRTT1C Board - silabs,brd4001a # WGM160P Evaluation Board - silabs,brd8022a # WF200 Evaluation Board - silabs,brd8023a # WFM200 Evaluation Board -- cgit From c4f2a32a7fc212a843f0540822a6f1880d176267 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 22 Apr 2022 14:20:54 -0500 Subject: dt-bindings: phy: marvell,armada-3700-utmi-host-phy: Fix incorrect compatible in example Fix the example using the incorrect compatible string. Signed-off-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220422192054.2591093-1-robh@kernel.org Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml index 2437c3683326..632d61c07f40 100644 --- a/Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml @@ -45,7 +45,7 @@ additionalProperties: false examples: - | usb2_utmi_host_phy: phy@5f000 { - compatible = "marvell,armada-3700-utmi-host-phy"; + compatible = "marvell,a3700-utmi-host-phy"; reg = <0x5f000 0x800>; marvell,usb-misc-reg = <&usb2_syscon>; #phy-cells = <0>; -- cgit From bc055a50a8594a634e09a7286601d0d2bd51c734 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Sat, 23 Apr 2022 14:47:52 +0100 Subject: dt-bindings: phy: renesas,usb2-phy: Document RZ/G2UL phy bindings Document USB phy bindings for RZ/G2UL SoC. RZ/G2UL USB phy is identical to one found on the RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,rzg2l-usb2-phy" will be used as a fallback. Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220423134752.143090-1-biju.das.jz@bp.renesas.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml index 16807bbbdcb1..f82649a55e91 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml @@ -32,6 +32,7 @@ properties: - items: - enum: + - renesas,usb2-phy-r9a07g043 # RZ/G2UL - renesas,usb2-phy-r9a07g044 # RZ/G2{L,LC} - renesas,usb2-phy-r9a07g054 # RZ/V2L - const: renesas,rzg2l-usb2-phy -- cgit From 00fd24089b8154ddf5b3e724e2c4c9974b9ba91e Mon Sep 17 00:00:00 2001 From: Manikanta Pubbisetty Date: Fri, 29 Apr 2022 22:34:54 +0530 Subject: dt: bindings: net: add bindings of WCN6750 for ath11k WCN6750 is the WLAN chip on Qualcomm Snapdragon SoC SC7280; Though being a PCIe based solution, it is not attached to the APSS processor (Application Processor SubSystem), it is instead attached to another tiny processor called WPSS Q6 processor (Wireless Processor SubSystem) on the SC7280 MSM, where the WLAN firmware runs, and it is the WLAN firmware running on the Q6 processor which enumerates WCN6750, as a result APPS processor would never know such a device being present in the system and would not detect the WCN6750 hardware unless and otherwise WCN6750 is registered as a platform device. This is the reason behind adding WCN6750 WLAN node in the device tree. Add WCN6750 wireless driver support, its based on ath11k driver. Reviewed-by: Rob Herring Signed-off-by: Manikanta Pubbisetty Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220429170502.20080-2-quic_mpubbise@quicinc.com --- .../bindings/net/wireless/qcom,ath11k.yaml | 361 ++++++++++++++------- 1 file changed, 252 insertions(+), 109 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml index cdf7b873b419..6b32caa8311c 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml @@ -20,120 +20,17 @@ properties: enum: - qcom,ipq8074-wifi - qcom,ipq6018-wifi + - qcom,wcn6750-wifi reg: maxItems: 1 interrupts: - items: - - description: misc-pulse1 interrupt events - - description: misc-latch interrupt events - - description: sw exception interrupt events - - description: watchdog interrupt events - - description: interrupt event for ring CE0 - - description: interrupt event for ring CE1 - - description: interrupt event for ring CE2 - - description: interrupt event for ring CE3 - - description: interrupt event for ring CE4 - - description: interrupt event for ring CE5 - - description: interrupt event for ring CE6 - - description: interrupt event for ring CE7 - - description: interrupt event for ring CE8 - - description: interrupt event for ring CE9 - - description: interrupt event for ring CE10 - - description: interrupt event for ring CE11 - - description: interrupt event for ring host2wbm-desc-feed - - description: interrupt event for ring host2reo-re-injection - - description: interrupt event for ring host2reo-command - - description: interrupt event for ring host2rxdma-monitor-ring3 - - description: interrupt event for ring host2rxdma-monitor-ring2 - - description: interrupt event for ring host2rxdma-monitor-ring1 - - description: interrupt event for ring reo2ost-exception - - description: interrupt event for ring wbm2host-rx-release - - description: interrupt event for ring reo2host-status - - description: interrupt event for ring reo2host-destination-ring4 - - description: interrupt event for ring reo2host-destination-ring3 - - description: interrupt event for ring reo2host-destination-ring2 - - description: interrupt event for ring reo2host-destination-ring1 - - description: interrupt event for ring rxdma2host-monitor-destination-mac3 - - description: interrupt event for ring rxdma2host-monitor-destination-mac2 - - description: interrupt event for ring rxdma2host-monitor-destination-mac1 - - description: interrupt event for ring ppdu-end-interrupts-mac3 - - description: interrupt event for ring ppdu-end-interrupts-mac2 - - description: interrupt event for ring ppdu-end-interrupts-mac1 - - description: interrupt event for ring rxdma2host-monitor-status-ring-mac3 - - description: interrupt event for ring rxdma2host-monitor-status-ring-mac2 - - description: interrupt event for ring rxdma2host-monitor-status-ring-mac1 - - description: interrupt event for ring host2rxdma-host-buf-ring-mac3 - - description: interrupt event for ring host2rxdma-host-buf-ring-mac2 - - description: interrupt event for ring host2rxdma-host-buf-ring-mac1 - - description: interrupt event for ring rxdma2host-destination-ring-mac3 - - description: interrupt event for ring rxdma2host-destination-ring-mac2 - - description: interrupt event for ring rxdma2host-destination-ring-mac1 - - description: interrupt event for ring host2tcl-input-ring4 - - description: interrupt event for ring host2tcl-input-ring3 - - description: interrupt event for ring host2tcl-input-ring2 - - description: interrupt event for ring host2tcl-input-ring1 - - description: interrupt event for ring wbm2host-tx-completions-ring3 - - description: interrupt event for ring wbm2host-tx-completions-ring2 - - description: interrupt event for ring wbm2host-tx-completions-ring1 - - description: interrupt event for ring tcl2host-status-ring - + minItems: 32 + maxItems: 52 interrupt-names: - items: - - const: misc-pulse1 - - const: misc-latch - - const: sw-exception - - const: watchdog - - const: ce0 - - const: ce1 - - const: ce2 - - const: ce3 - - const: ce4 - - const: ce5 - - const: ce6 - - const: ce7 - - const: ce8 - - const: ce9 - - const: ce10 - - const: ce11 - - const: host2wbm-desc-feed - - const: host2reo-re-injection - - const: host2reo-command - - const: host2rxdma-monitor-ring3 - - const: host2rxdma-monitor-ring2 - - const: host2rxdma-monitor-ring1 - - const: reo2ost-exception - - const: wbm2host-rx-release - - const: reo2host-status - - const: reo2host-destination-ring4 - - const: reo2host-destination-ring3 - - const: reo2host-destination-ring2 - - const: reo2host-destination-ring1 - - const: rxdma2host-monitor-destination-mac3 - - const: rxdma2host-monitor-destination-mac2 - - const: rxdma2host-monitor-destination-mac1 - - const: ppdu-end-interrupts-mac3 - - const: ppdu-end-interrupts-mac2 - - const: ppdu-end-interrupts-mac1 - - const: rxdma2host-monitor-status-ring-mac3 - - const: rxdma2host-monitor-status-ring-mac2 - - const: rxdma2host-monitor-status-ring-mac1 - - const: host2rxdma-host-buf-ring-mac3 - - const: host2rxdma-host-buf-ring-mac2 - - const: host2rxdma-host-buf-ring-mac1 - - const: rxdma2host-destination-ring-mac3 - - const: rxdma2host-destination-ring-mac2 - - const: rxdma2host-destination-ring-mac1 - - const: host2tcl-input-ring4 - - const: host2tcl-input-ring3 - - const: host2tcl-input-ring2 - - const: host2tcl-input-ring1 - - const: wbm2host-tx-completions-ring3 - - const: wbm2host-tx-completions-ring2 - - const: wbm2host-tx-completions-ring1 - - const: tcl2host-status-ring + maxItems: 52 qcom,rproc: $ref: /schemas/types.yaml#/definitions/phandle @@ -151,20 +48,205 @@ properties: board-2.bin for designs with colliding bus and device specific ids memory-region: - maxItems: 1 + minItems: 1 + maxItems: 2 description: phandle to a node describing reserved memory (System RAM memory) used by ath11k firmware (see bindings/reserved-memory/reserved-memory.txt) + iommus: + minItems: 1 + maxItems: 2 + + wifi-firmware: + type: object + description: | + WCN6750 wifi node can contain one optional firmware subnode. + Firmware subnode is needed when the platform does not have Trustzone. + required: + - iommus + required: - compatible - reg - interrupts - - interrupt-names - qcom,rproc additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,ipq8074-wifi + - qcom,ipq6018-wifi + then: + properties: + interrupts: + items: + - description: misc-pulse1 interrupt events + - description: misc-latch interrupt events + - description: sw exception interrupt events + - description: watchdog interrupt events + - description: interrupt event for ring CE0 + - description: interrupt event for ring CE1 + - description: interrupt event for ring CE2 + - description: interrupt event for ring CE3 + - description: interrupt event for ring CE4 + - description: interrupt event for ring CE5 + - description: interrupt event for ring CE6 + - description: interrupt event for ring CE7 + - description: interrupt event for ring CE8 + - description: interrupt event for ring CE9 + - description: interrupt event for ring CE10 + - description: interrupt event for ring CE11 + - description: interrupt event for ring host2wbm-desc-feed + - description: interrupt event for ring host2reo-re-injection + - description: interrupt event for ring host2reo-command + - description: interrupt event for ring host2rxdma-monitor-ring3 + - description: interrupt event for ring host2rxdma-monitor-ring2 + - description: interrupt event for ring host2rxdma-monitor-ring1 + - description: interrupt event for ring reo2ost-exception + - description: interrupt event for ring wbm2host-rx-release + - description: interrupt event for ring reo2host-status + - description: interrupt event for ring reo2host-destination-ring4 + - description: interrupt event for ring reo2host-destination-ring3 + - description: interrupt event for ring reo2host-destination-ring2 + - description: interrupt event for ring reo2host-destination-ring1 + - description: interrupt event for ring rxdma2host-monitor-destination-mac3 + - description: interrupt event for ring rxdma2host-monitor-destination-mac2 + - description: interrupt event for ring rxdma2host-monitor-destination-mac1 + - description: interrupt event for ring ppdu-end-interrupts-mac3 + - description: interrupt event for ring ppdu-end-interrupts-mac2 + - description: interrupt event for ring ppdu-end-interrupts-mac1 + - description: interrupt event for ring rxdma2host-monitor-status-ring-mac3 + - description: interrupt event for ring rxdma2host-monitor-status-ring-mac2 + - description: interrupt event for ring rxdma2host-monitor-status-ring-mac1 + - description: interrupt event for ring host2rxdma-host-buf-ring-mac3 + - description: interrupt event for ring host2rxdma-host-buf-ring-mac2 + - description: interrupt event for ring host2rxdma-host-buf-ring-mac1 + - description: interrupt event for ring rxdma2host-destination-ring-mac3 + - description: interrupt event for ring rxdma2host-destination-ring-mac2 + - description: interrupt event for ring rxdma2host-destination-ring-mac1 + - description: interrupt event for ring host2tcl-input-ring4 + - description: interrupt event for ring host2tcl-input-ring3 + - description: interrupt event for ring host2tcl-input-ring2 + - description: interrupt event for ring host2tcl-input-ring1 + - description: interrupt event for ring wbm2host-tx-completions-ring3 + - description: interrupt event for ring wbm2host-tx-completions-ring2 + - description: interrupt event for ring wbm2host-tx-completions-ring1 + - description: interrupt event for ring tcl2host-status-ring + interrupt-names: + items: + - const: misc-pulse1 + - const: misc-latch + - const: sw-exception + - const: watchdog + - const: ce0 + - const: ce1 + - const: ce2 + - const: ce3 + - const: ce4 + - const: ce5 + - const: ce6 + - const: ce7 + - const: ce8 + - const: ce9 + - const: ce10 + - const: ce11 + - const: host2wbm-desc-feed + - const: host2reo-re-injection + - const: host2reo-command + - const: host2rxdma-monitor-ring3 + - const: host2rxdma-monitor-ring2 + - const: host2rxdma-monitor-ring1 + - const: reo2ost-exception + - const: wbm2host-rx-release + - const: reo2host-status + - const: reo2host-destination-ring4 + - const: reo2host-destination-ring3 + - const: reo2host-destination-ring2 + - const: reo2host-destination-ring1 + - const: rxdma2host-monitor-destination-mac3 + - const: rxdma2host-monitor-destination-mac2 + - const: rxdma2host-monitor-destination-mac1 + - const: ppdu-end-interrupts-mac3 + - const: ppdu-end-interrupts-mac2 + - const: ppdu-end-interrupts-mac1 + - const: rxdma2host-monitor-status-ring-mac3 + - const: rxdma2host-monitor-status-ring-mac2 + - const: rxdma2host-monitor-status-ring-mac1 + - const: host2rxdma-host-buf-ring-mac3 + - const: host2rxdma-host-buf-ring-mac2 + - const: host2rxdma-host-buf-ring-mac1 + - const: rxdma2host-destination-ring-mac3 + - const: rxdma2host-destination-ring-mac2 + - const: rxdma2host-destination-ring-mac1 + - const: host2tcl-input-ring4 + - const: host2tcl-input-ring3 + - const: host2tcl-input-ring2 + - const: host2tcl-input-ring1 + - const: wbm2host-tx-completions-ring3 + - const: wbm2host-tx-completions-ring2 + - const: wbm2host-tx-completions-ring1 + - const: tcl2host-status-ring + + - if: + properties: + compatible: + contains: + enum: + - qcom,ipq8074-wifi + - qcom,ipq6018-wifi + then: + required: + - interrupt-names + + - if: + properties: + compatible: + contains: + enum: + - qcom,wcn6750-wifi + then: + properties: + interrupts: + items: + - description: interrupt event for ring CE1 + - description: interrupt event for ring CE2 + - description: interrupt event for ring CE3 + - description: interrupt event for ring CE4 + - description: interrupt event for ring CE5 + - description: interrupt event for ring CE6 + - description: interrupt event for ring CE7 + - description: interrupt event for ring CE8 + - description: interrupt event for ring CE9 + - description: interrupt event for ring CE10 + - description: interrupt event for ring DP1 + - description: interrupt event for ring DP2 + - description: interrupt event for ring DP3 + - description: interrupt event for ring DP4 + - description: interrupt event for ring DP5 + - description: interrupt event for ring DP6 + - description: interrupt event for ring DP7 + - description: interrupt event for ring DP8 + - description: interrupt event for ring DP9 + - description: interrupt event for ring DP10 + - description: interrupt event for ring DP11 + - description: interrupt event for ring DP12 + - description: interrupt event for ring DP13 + - description: interrupt event for ring DP14 + - description: interrupt event for ring DP15 + - description: interrupt event for ring DP16 + - description: interrupt event for ring DP17 + - description: interrupt event for ring DP18 + - description: interrupt event for ring DP19 + - description: interrupt event for ring DP20 + - description: interrupt event for ring DP21 + - description: interrupt event for ring DP22 + examples: - | @@ -309,3 +391,64 @@ examples: }; }; }; + + - | + #include + + reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + + wlan_ce_mem: memory@4cd000 { + no-map; + reg = <0x0 0x004cd000 0x0 0x1000>; + }; + + wlan_fw_mem: memory@80c00000 { + no-map; + reg = <0x0 0x80c00000 0x0 0xc00000>; + }; + }; + + wifi: wifi@17a10040 { + compatible = "qcom,wcn6750-wifi"; + reg = <0x17a10040 0x0>; + iommus = <&apps_smmu 0x1c00 0x1>; + interrupts = , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + ; + qcom,rproc = <&remoteproc_wpss>; + memory-region = <&wlan_fw_mem>, <&wlan_ce_mem>; + wifi-firmware { + iommus = <&apps_smmu 0x1c02 0x1>; + }; + }; -- cgit From 666518676d4fea1517043d6008df4f67ea19b5dd Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Tue, 26 Apr 2022 21:36:44 +0200 Subject: dt-bindings: display: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge The i.MX8MP contains two syscon registers which are responsible for configuring the on-SoC DPI-to-LVDS serializer. Add DT binding which represents this serializer as a bridge. Acked-by: Sam Ravnborg Signed-off-by: Marek Vasut Cc: Laurent Pinchart Cc: Lucas Stach Cc: Maxime Ripard Cc: Peng Fan Cc: Rob Herring Cc: Robby Cai Cc: Robert Foss Cc: Sam Ravnborg Cc: Thomas Zimmermann Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220426193645.244792-1-marex@denx.de --- .../bindings/display/bridge/fsl,ldb.yaml | 92 ++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml new file mode 100644 index 000000000000..77f174eee424 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/fsl,ldb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8MP DPI to LVDS bridge chip + +maintainers: + - Marek Vasut + +description: | + The i.MX8MP mediamix contains two registers which are responsible + for configuring the on-SoC DPI-to-LVDS serializer. This describes + those registers as bridge within the DT. + +properties: + compatible: + const: fsl,imx8mp-ldb + + clocks: + maxItems: 1 + + clock-names: + const: ldb + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for DPI input. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for LVDS Channel-A output (panel or bridge). + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for LVDS Channel-B output (panel or bridge). + + required: + - port@0 + - port@1 + +required: + - compatible + - clocks + - ports + +additionalProperties: false + +examples: + - | + #include + + blk-ctrl { + bridge { + compatible = "fsl,imx8mp-ldb"; + clocks = <&clk IMX8MP_CLK_MEDIA_LDB>; + clock-names = "ldb"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + ldb_from_lcdif2: endpoint { + remote-endpoint = <&lcdif2_to_ldb>; + }; + }; + + port@1 { + reg = <1>; + + ldb_lvds_ch0: endpoint { + remote-endpoint = <&ldb_to_lvdsx4panel>; + }; + }; + + port@2 { + reg = <2>; + + ldb_lvds_ch1: endpoint { + }; + }; + }; + }; + }; -- cgit From 82b96552f15a05ee9f31813178e024720aa5b9bc Mon Sep 17 00:00:00 2001 From: Sven Peter Date: Sun, 1 May 2022 16:55:09 +0200 Subject: dt-bindings: nvme: Add Apple ANS NVMe Apple SoCs such as the M1 come with an embedded NVMe coprocessor called ANS2. Reviewed-by: Rob Herring Signed-off-by: Sven Peter --- .../devicetree/bindings/nvme/apple,nvme-ans.yaml | 111 +++++++++++++++++++++ 1 file changed, 111 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml b/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml new file mode 100644 index 000000000000..ddff9233b159 --- /dev/null +++ b/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml @@ -0,0 +1,111 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvme/apple,nvme-ans.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple ANS NVM Express host controller + +maintainers: + - Sven Peter + +properties: + compatible: + items: + - enum: + - apple,t8103-nvme-ans2 + - apple,t6000-nvme-ans2 + - const: apple,nvme-ans2 + + reg: + items: + - description: NVMe and NVMMU registers + - description: ANS2 co-processor control registers + + reg-names: + items: + - const: nvme + - const: ans + + resets: + maxItems: 1 + + power-domains: + # two domains for t8103, three for t6000 + minItems: 2 + items: + - description: power domain for the NVMe controller. + - description: power domain for the first PCIe bus connecting the NVMe + controller to the storage modules. + - description: optional power domain for the second PCIe bus + connecting the NVMe controller to the storage modules. + + power-domain-names: + minItems: 2 + items: + - const: ans + - const: apcie0 + - const: apcie1 + + mboxes: + maxItems: 1 + description: Mailbox of the ANS2 co-processor + + interrupts: + maxItems: 1 + + apple,sart: + maxItems: 1 + $ref: /schemas/types.yaml#/definitions/phandle + description: | + Reference to the SART address filter. + + The SART address filter is documented in iommu/apple,sart.yaml. + +if: + properties: + compatible: + contains: + const: apple,t8103-nvme-ans2 +then: + properties: + power-domains: + maxItems: 2 + power-domain-names: + maxItems: 2 +else: + properties: + power-domains: + minItems: 3 + power-domain-names: + minItems: 3 + +required: + - compatible + - reg + - reg-names + - resets + - power-domains + - power-domain-names + - mboxes + - interrupts + - apple,sart + +additionalProperties: false + +examples: + - | + #include + #include + + nvme@7bcc0000 { + compatible = "apple,t8103-nvme-ans2", "apple,nvme-ans2"; + reg = <0x7bcc0000 0x40000>, <0x77400000 0x4000>; + reg-names = "nvme", "ans"; + interrupts = ; + mboxes = <&ans>; + apple,sart = <&sart>; + power-domains = <&ps_ans2>, <&ps_apcie_st>; + power-domain-names = "ans", "apcie0"; + resets = <&ps_ans2>; + }; -- cgit From 1d7aff7788362fb85ef694874c065dc2e1f58a63 Mon Sep 17 00:00:00 2001 From: Dave Gerlach Date: Tue, 26 Apr 2022 13:07:42 -0700 Subject: dt-bindings: wkup-m3-ipc: Add firmware-name property Document that the firmware-name property can be used to indicate a file contains I2C sequences for PMIC voltage scaling during deep sleep. Based on previous work by Russ Dill. Signed-off-by: Dave Gerlach Signed-off-by: Keerthy [dfustini: split from driver patch and convert to json-schema] Signed-off-by: Drew Fustini Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220426200741.712842-2-dfustini@baylibre.com --- Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml b/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml index 88d690de050c..0df41c4f60c1 100644 --- a/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml +++ b/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml @@ -40,6 +40,12 @@ description: |+ override the pin's existing bias (pull-up/pull-down) and value (high/low) when IO isolation is active. + Support for I2C PMIC Voltage Scaling + ==================================== + It is possible to pass the name of a binary file to load into the CM3 memory. + The binary data is the I2C sequences for the CM3 to send out to the PMIC + during low power mode entry. + properties: compatible: enum: @@ -67,6 +73,10 @@ properties: mbox_wkupm3 child node. maxItems: 1 + firmware-name: + description: + Name of binary file with I2C sequences for PMIC voltage scaling + ti,vtt-gpio-pin: $ref: /schemas/types.yaml#/definitions/uint32 description: GPIO pin connected to enable pin on VTT regulator @@ -117,6 +127,7 @@ examples: ti,rproc = <&wkup_m3>; mboxes = <&am335x_mailbox &mbox_wkupm3>; ti,vtt-gpio-pin = <7>; + firmware-name = "am335x-evm-scale-data.bin"; }; }; @@ -157,6 +168,7 @@ examples: ti,rproc = <&wkup_m3>; mboxes = <&am437x_mailbox &mbox_wkupm3>; ti,set-io-isolation; + firmware-name = "am43x-evm-scale-data.bin"; }; }; -- cgit From 52077d82331a13e3e09295ac288343b9f80d7d68 Mon Sep 17 00:00:00 2001 From: David Heidelberg Date: Mon, 27 Dec 2021 18:01:50 +0100 Subject: dt-bindings: spmi: convert QCOM PMIC SPMI bindings to yaml Convert Qualcomm PMIC SPMI binding to yaml format. Signed-off-by: David Heidelberg Reviewed-by: Vinod Koul Reviewed-by: Rob Herring Acked-by: Lee Jones Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20211227170151.73116-1-david@ixit.cz --- .../devicetree/bindings/mfd/qcom,spmi-pmic.txt | 2 +- .../bindings/spmi/qcom,spmi-pmic-arb.txt | 65 ----------- .../bindings/spmi/qcom,spmi-pmic-arb.yaml | 120 +++++++++++++++++++++ 3 files changed, 121 insertions(+), 66 deletions(-) delete mode 100644 Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt create mode 100644 Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt index a461ec2f758f..eb78e3ae7703 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt @@ -59,7 +59,7 @@ Required properties for peripheral child nodes: Optional properties for peripheral child nodes: - interrupts: Interrupts are specified as a 4-tuple. For more information see: - Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt + Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml - interrupt-names: Corresponding interrupt name to the interrupts property Each child node of SPMI slave id represents a function of the PMIC. In the diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt deleted file mode 100644 index ca645e21fe47..000000000000 --- a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt +++ /dev/null @@ -1,65 +0,0 @@ -Qualcomm SPMI Controller (PMIC Arbiter) - -The SPMI PMIC Arbiter is found on Snapdragon chipsets. It is an SPMI -controller with wrapping arbitration logic to allow for multiple on-chip -devices to control a single SPMI master. - -The PMIC Arbiter can also act as an interrupt controller, providing interrupts -to slave devices. - -See Documentation/devicetree/bindings/spmi/spmi.yaml for the generic SPMI -controller binding requirements for child nodes. - -See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for -generic interrupt controller binding documentation. - -Required properties: -- compatible : should be "qcom,spmi-pmic-arb". -- reg-names : must contain: - "core" - core registers - "intr" - interrupt controller registers - "cnfg" - configuration registers - Registers used only for V2 PMIC Arbiter: - "chnls" - tx-channel per virtual slave registers. - "obsrvr" - rx-channel (called observer) per virtual slave registers. - -- reg : address + size pairs describing the PMIC arb register sets; order must - correspond with the order of entries in reg-names -- #address-cells : must be set to 2 -- #size-cells : must be set to 0 -- qcom,ee : indicates the active Execution Environment identifier (0-5) -- qcom,channel : which of the PMIC Arb provided channels to use for accesses (0-5) -- interrupts : interrupt list for the PMIC Arb controller, must contain a - single interrupt entry for the peripheral interrupt -- interrupt-names : corresponding interrupt names for the interrupts - listed in the 'interrupts' property, must contain: - "periph_irq" - summary interrupt for PMIC peripherals -- interrupt-controller : boolean indicator that the PMIC arbiter is an interrupt controller -- #interrupt-cells : must be set to 4. Interrupts are specified as a 4-tuple: - cell 1: slave ID for the requested interrupt (0-15) - cell 2: peripheral ID for requested interrupt (0-255) - cell 3: the requested peripheral interrupt (0-7) - cell 4: interrupt flags indicating level-sense information, as defined in - dt-bindings/interrupt-controller/irq.h - -Example: - - spmi { - compatible = "qcom,spmi-pmic-arb"; - reg-names = "core", "intr", "cnfg"; - reg = <0xfc4cf000 0x1000>, - <0xfc4cb000 0x1000>, - <0xfc4ca000 0x1000>; - - interrupt-names = "periph_irq"; - interrupts = <0 190 0>; - - qcom,ee = <0>; - qcom,channel = <0>; - - #address-cells = <2>; - #size-cells = <0>; - - interrupt-controller; - #interrupt-cells = <4>; - }; diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml new file mode 100644 index 000000000000..55d379c85fd9 --- /dev/null +++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spmi/qcom,spmi-pmic-arb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SPMI Controller (PMIC Arbiter) + +maintainers: + - Stephen Boyd + +description: | + The SPMI PMIC Arbiter is found on Snapdragon chipsets. It is an SPMI + controller with wrapping arbitration logic to allow for multiple on-chip + devices to control a single SPMI master. + + The PMIC Arbiter can also act as an interrupt controller, providing interrupts + to slave devices. + +allOf: + - $ref: spmi.yaml + +properties: + compatible: + const: qcom,spmi-pmic-arb + + reg: + oneOf: + - items: # V1 + - description: core registers + - description: interrupt controller registers + - description: configuration registers + - items: # V2 + - description: core registers + - description: tx-channel per virtual slave regosters + - description: rx-channel (called observer) per virtual slave registers + - description: interrupt controller registers + - description: configuration registers + + reg-names: + oneOf: + - items: + - const: core + - const: intr + - const: cnfg + - items: + - const: core + - const: chnls + - const: obsrvr + - const: intr + - const: cnfg + + interrupts: + maxItems: 1 + + interrupt-names: + const: periph_irq + + interrupt-controller: true + + '#address-cells': true + + '#interrupt-cells': + const: 4 + description: | + cell 1: slave ID for the requested interrupt (0-15) + cell 2: peripheral ID for requested interrupt (0-255) + cell 3: the requested peripheral interrupt (0-7) + cell 4: interrupt flags indicating level-sense information, + as defined in dt-bindings/interrupt-controller/irq.h + + '#size-cells': true + + qcom,ee: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 5 + description: > + indicates the active Execution Environment identifier + + qcom,channel: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 5 + description: > + which of the PMIC Arb provided channels to use for accesses + +required: + - compatible + - reg-names + - interrupts + - interrupt-names + - '#interrupt-cells' + - qcom,ee + - qcom,channel + +unevaluatedProperties: false + +examples: + - | + spmi@fc4cf000 { + compatible = "qcom,spmi-pmic-arb"; + reg-names = "core", "intr", "cnfg"; + reg = <0xfc4cf000 0x1000>, + <0xfc4cb000 0x1000>, + <0xfc4ca000 0x1000>; + + interrupt-names = "periph_irq"; + interrupts = <0 190 0>; + + qcom,ee = <0>; + qcom,channel = <0>; + + #address-cells = <2>; + #size-cells = <0>; + + interrupt-controller; + #interrupt-cells = <4>; + }; + -- cgit From ef6a0a3b2b1084059f6bb1f07d919d40f7dfbfd6 Mon Sep 17 00:00:00 2001 From: David Collins Date: Thu, 28 Apr 2022 09:12:47 +0800 Subject: dt-bindings: spmi: spmi-pmic-arb: make interrupt properties as optional Make all interrupt related properties as optional instead of required. Some boards do not required PMIC IRQ support and it isn't needed to handle SPMI bus transactions, so specify it as optional. Signed-off-by: David Collins Signed-off-by: Fenglin Wu Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/1651108369-11059-9-git-send-email-quic_fenglinw@quicinc.com --- Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml index 55d379c85fd9..fee4f0eb4665 100644 --- a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml +++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml @@ -88,9 +88,6 @@ properties: required: - compatible - reg-names - - interrupts - - interrupt-names - - '#interrupt-cells' - qcom,ee - qcom,channel -- cgit From 1cdba21db2ca31514c60b9732fc3963ae24c59e0 Mon Sep 17 00:00:00 2001 From: Daniel Latypov Date: Fri, 29 Apr 2022 11:12:57 -0700 Subject: kunit: add ability to specify suite-level init and exit functions KUnit has support for setup/cleanup logic for each test case in a suite. But it lacks the ability to specify setup/cleanup for the entire suite itself. This can be used to do setup that is too expensive or cumbersome to do for each test. Or it can be used to do simpler things like log debug information after the suite completes. It's a fairly common feature, so the lack of it is noticeable. Some examples in other frameworks and languages: * https://docs.python.org/3/library/unittest.html#setupclass-and-teardownclass * https://google.github.io/googletest/reference/testing.html#Test::SetUpTestSuite Meta: This is very similar to this patch here: https://lore.kernel.org/linux-kselftest/20210805043503.20252-3-bvanassche@acm.org/ The changes from that patch: * pass in `struct kunit *` so users can do stuff like `kunit_info(suite, "debug message")` * makes sure the init failure is bubbled up as a failure * updates kunit-example-test.c to use a suite init * Updates kunit/usage.rst to mention the new support * some minor cosmetic things * use `suite_{init,exit}` instead of `{init/exit}_suite` * make suite init error message more consistent w/ test init * etc. Signed-off-by: Daniel Latypov Reviewed-by: David Gow Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/usage.rst | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index 1c83e7d60a8a..d62a04255c2e 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -125,8 +125,8 @@ We need many test cases covering all the unit's behaviors. It is common to have many similar tests. In order to reduce duplication in these closely related tests, most unit testing frameworks (including KUnit) provide the concept of a *test suite*. A test suite is a collection of test cases for a unit of code -with a setup function that gets invoked before every test case and then a tear -down function that gets invoked after every test case completes. For example: +with optional setup and teardown functions that run before/after the whole +suite and/or every test case. For example: .. code-block:: c @@ -141,16 +141,19 @@ down function that gets invoked after every test case completes. For example: .name = "example", .init = example_test_init, .exit = example_test_exit, + .suite_init = example_suite_init, + .suite_exit = example_suite_exit, .test_cases = example_test_cases, }; kunit_test_suite(example_test_suite); -In the above example, the test suite ``example_test_suite`` would run the test -cases ``example_test_foo``, ``example_test_bar``, and ``example_test_baz``. Each -would have ``example_test_init`` called immediately before it and -``example_test_exit`` called immediately after it. -``kunit_test_suite(example_test_suite)`` registers the test suite with the -KUnit test framework. +In the above example, the test suite ``example_test_suite`` would first run +``example_suite_init``, then run the test cases ``example_test_foo``, +``example_test_bar``, and ``example_test_baz``. Each would have +``example_test_init`` called immediately before it and ``example_test_exit`` +called immediately after it. Finally, ``example_suite_exit`` would be called +after everything else. ``kunit_test_suite(example_test_suite)`` registers the +test suite with the KUnit test framework. .. note:: A test case will only run if it is associated with a test suite. -- cgit From a5fc012e6ee75a899173398573e77207542f588a Mon Sep 17 00:00:00 2001 From: Sascha Hauer Date: Fri, 22 Apr 2022 09:28:22 +0200 Subject: dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name "vpll" is a misnomer. A clock input to a device should be named after the usage in the device, not after the clock that drives it. On the rk3568 the same clock is driven by the HPLL. This patch adds "ref" as a new alternative clock name for "vpll" Signed-off-by: Sascha Hauer Acked-by: Rob Herring Tested-by: Michael Riesch Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-6-s.hauer@pengutronix.de --- .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml index da3b889ad8fc..0400f67e5f2c 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml @@ -36,7 +36,8 @@ properties: # order when present. - description: The HDMI CEC controller main clock - description: Power for GRF IO - - description: External clock for some HDMI PHY + - description: External clock for some HDMI PHY (old clock name, deprecated) + - description: External clock for some HDMI PHY (new name) clock-names: minItems: 2 @@ -47,10 +48,14 @@ properties: - cec - grf - vpll + - ref - enum: - grf - vpll - - const: vpll + - ref + - enum: + - vpll + - ref ddc-i2c-bus: $ref: /schemas/types.yaml#/definitions/phandle -- cgit From 77b0693f875d4d916d0518ac0de68d4d0de3934f Mon Sep 17 00:00:00 2001 From: Benjamin Gaignard Date: Fri, 22 Apr 2022 09:28:25 +0200 Subject: dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568 HDMI Define a new compatible for rk3568 HDMI. This version of HDMI hardware block needs two new clocks hclk_vio and hclk to provide phy reference clocks. Signed-off-by: Benjamin Gaignard Reviewed-by: Rob Herring Signed-off-by: Sascha Hauer Tested-by: Michael Riesch Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-9-s.hauer@pengutronix.de --- Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml index 0400f67e5f2c..e6b8437a1e2d 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml @@ -23,6 +23,7 @@ properties: - rockchip,rk3288-dw-hdmi - rockchip,rk3328-dw-hdmi - rockchip,rk3399-dw-hdmi + - rockchip,rk3568-dw-hdmi reg-io-width: const: 4 -- cgit From 80266ccb864b6443fd0bf54bb17444d2632fad21 Mon Sep 17 00:00:00 2001 From: Sascha Hauer Date: Fri, 22 Apr 2022 09:28:27 +0200 Subject: dt-bindings: display: rockchip: dw-hdmi: Add regulator support The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed for the HDMI port. Add the binding for these supplies. Signed-off-by: Sascha Hauer Acked-by: Rob Herring Tested-by: Michael Riesch Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-11-s.hauer@pengutronix.de --- .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml index e6b8437a1e2d..38ebb6983028 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml @@ -28,6 +28,17 @@ properties: reg-io-width: const: 4 + avdd-0v9-supply: + description: + A 0.9V supply that powers up the SoC internal circuitry. The actual pin name + varies between the different SoCs and is usually HDMI_TX_AVDD_0V9 or sometimes + HDMI_AVDD_1V0. + + avdd-1v8-supply: + description: + A 1.8V supply that powers up the SoC internal circuitry. The pin name on the + SoC usually is HDMI_TX_AVDD_1V8. + clocks: minItems: 2 items: -- cgit From 6e944f52a225484b87bb343d0ba28165edf04b19 Mon Sep 17 00:00:00 2001 From: Sascha Hauer Date: Fri, 22 Apr 2022 09:28:32 +0200 Subject: dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional None of the upstream device tree files has a "unwedge" pinctrl specified. Make it optional. Signed-off-by: Sascha Hauer Acked-by: Rob Herring Tested-by: Michael Riesch Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-16-s.hauer@pengutronix.de --- Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml index 38ebb6983028..d7cb2b2be60e 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml @@ -89,6 +89,7 @@ properties: The unwedge pinctrl entry shall drive the DDC SDA line low. This is intended to work around a hardware errata that can cause the DDC I2C bus to be wedged. + minItems: 1 items: - const: default - const: unwedge -- cgit From 6406ac633d8096d5a05e4a82499a4efac2dd18d5 Mon Sep 17 00:00:00 2001 From: Dipen Patel Date: Fri, 22 Apr 2022 13:52:12 -0700 Subject: Documentation: Add HTE subsystem guide Adding hte document which can help understand various APIs implemented in HTE framework for the HTE producers and the consumers. Signed-off-by: Dipen Patel Signed-off-by: Thierry Reding --- Documentation/hte/hte.rst | 79 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 Documentation/hte/hte.rst (limited to 'Documentation') diff --git a/Documentation/hte/hte.rst b/Documentation/hte/hte.rst new file mode 100644 index 000000000000..153f3233c100 --- /dev/null +++ b/Documentation/hte/hte.rst @@ -0,0 +1,79 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +============================================ +The Linux Hardware Timestamping Engine (HTE) +============================================ + +:Author: Dipen Patel + +Introduction +------------ + +Certain devices have built in hardware timestamping engines which can +monitor sets of system signals, lines, buses etc... in realtime for state +change; upon detecting the change they can automatically store the timestamp at +the moment of occurrence. Such functionality may help achieve better accuracy +in obtaining timestamps than using software counterparts i.e. ktime and +friends. + +This document describes the API that can be used by hardware timestamping +engine provider and consumer drivers that want to use the hardware timestamping +engine (HTE) framework. Both consumers and providers must include +``#include ``. + +The HTE framework APIs for the providers +---------------------------------------- + +.. kernel-doc:: drivers/hte/hte.c + :functions: devm_hte_register_chip hte_push_ts_ns + +The HTE framework APIs for the consumers +---------------------------------------- + +.. kernel-doc:: drivers/hte/hte.c + :functions: hte_init_line_attr hte_ts_get hte_ts_put devm_hte_request_ts_ns hte_request_ts_ns hte_enable_ts hte_disable_ts of_hte_req_count hte_get_clk_src_info + +The HTE framework public structures +----------------------------------- +.. kernel-doc:: include/linux/hte.h + +More on the HTE timestamp data +------------------------------ +The ``struct hte_ts_data`` is used to pass timestamp details between the +consumers and the providers. It expresses timestamp data in nanoseconds in +u64. An example of the typical timestamp data life cycle, for the GPIO line is +as follows:: + + - Monitors GPIO line change. + - Detects the state change on GPIO line. + - Converts timestamps in nanoseconds. + - Stores GPIO raw level in raw_level variable if the provider has that + hardware capability. + - Pushes this hte_ts_data object to HTE subsystem. + - HTE subsystem increments seq counter and invokes consumer provided callback. + Based on callback return value, the HTE core invokes secondary callback in + the thread context. + +HTE subsystem debugfs attributes +-------------------------------- +HTE subsystem creates debugfs attributes at ``/sys/kernel/debug/hte/``. +It also creates line/signal-related debugfs attributes at +``/sys/kernel/debug/hte//