From 33a499668eb6781a4518e4facf2d85cc8cd1a650 Mon Sep 17 00:00:00 2001 From: Frank Li Date: Thu, 21 Mar 2024 11:04:00 -0400 Subject: ASoC: dt-bindings: fsl-audmix: Convert fsl,audmix.txt to yaml Convert fsl,audmix.txt to yaml to let dtb check tools check audmix part. Signed-off-by: Frank Li Reviewed-by: Rob Herring Link: https://msgid.link/r/20240321150401.2464783-1-Frank.Li@nxp.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/fsl,audmix.txt | 50 ------------- .../devicetree/bindings/sound/fsl,audmix.yaml | 83 ++++++++++++++++++++++ 2 files changed, 83 insertions(+), 50 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/fsl,audmix.txt create mode 100644 Documentation/devicetree/bindings/sound/fsl,audmix.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,audmix.txt b/Documentation/devicetree/bindings/sound/fsl,audmix.txt deleted file mode 100644 index 840b7e0d6a63..000000000000 --- a/Documentation/devicetree/bindings/sound/fsl,audmix.txt +++ /dev/null @@ -1,50 +0,0 @@ -NXP Audio Mixer (AUDMIX). - -The Audio Mixer is a on-chip functional module that allows mixing of two -audio streams into a single audio stream. Audio Mixer has two input serial -audio interfaces. These are driven by two Synchronous Audio interface -modules (SAI). Each input serial interface carries 8 audio channels in its -frame in TDM manner. Mixer mixes audio samples of corresponding channels -from two interfaces into a single sample. Before mixing, audio samples of -two inputs can be attenuated based on configuration. The output of the -Audio Mixer is also a serial audio interface. Like input interfaces it has -the same TDM frame format. This output is used to drive the serial DAC TDM -interface of audio codec and also sent to the external pins along with the -receive path of normal audio SAI module for readback by the CPU. - -The output of Audio Mixer can be selected from any of the three streams - - serial audio input 1 - - serial audio input 2 - - mixed audio - -Mixing operation is independent of audio sample rate but the two audio -input streams must have same audio sample rate with same number of channels -in TDM frame to be eligible for mixing. - -Device driver required properties: -================================= - - compatible : Compatible list, contains "fsl,imx8qm-audmix" - - - reg : Offset and length of the register set for the device. - - - clocks : Must contain an entry for each entry in clock-names. - - - clock-names : Must include the "ipg" for register access. - - - power-domains : Must contain the phandle to AUDMIX power domain node - - - dais : Must contain a list of phandles to AUDMIX connected - DAIs. The current implementation requires two phandles - to SAI interfaces to be provided, the first SAI in the - list being used to route the AUDMIX output. - -Device driver configuration example: -====================================== - audmix: audmix@59840000 { - compatible = "fsl,imx8qm-audmix"; - reg = <0x0 0x59840000 0x0 0x10000>; - clocks = <&clk IMX8QXP_AUD_AUDMIX_IPG>; - clock-names = "ipg"; - power-domains = <&pd_audmix>; - dais = <&sai4>, <&sai5>; - }; diff --git a/Documentation/devicetree/bindings/sound/fsl,audmix.yaml b/Documentation/devicetree/bindings/sound/fsl,audmix.yaml new file mode 100644 index 000000000000..9413b901cf77 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,audmix.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,audmix.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Audio Mixer (AUDMIX). + +maintainers: + - Shengjiu Wang + - Frank Li + +description: | + The Audio Mixer is a on-chip functional module that allows mixing of two + audio streams into a single audio stream. Audio Mixer has two input serial + audio interfaces. These are driven by two Synchronous Audio interface + modules (SAI). Each input serial interface carries 8 audio channels in its + frame in TDM manner. Mixer mixes audio samples of corresponding channels + from two interfaces into a single sample. Before mixing, audio samples of + two inputs can be attenuated based on configuration. The output of the + Audio Mixer is also a serial audio interface. Like input interfaces it has + the same TDM frame format. This output is used to drive the serial DAC TDM + interface of audio codec and also sent to the external pins along with the + receive path of normal audio SAI module for readback by the CPU. + + The output of Audio Mixer can be selected from any of the three streams + - serial audio input 1 + - serial audio input 2 + - mixed audio + + Mixing operation is independent of audio sample rate but the two audio + input streams must have same audio sample rate with same number of channels + in TDM frame to be eligible for mixing. + +properties: + compatible: + const: fsl,imx8qm-audmix + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ipg + + power-domains: + maxItems: 1 + + dais: + description: contain a list of phandles to AUDMIX connected DAIs. + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 2 + items: + - description: the AUDMIX output + maxItems: 1 + - description: serial audio input 1 + maxItems: 1 + - description: serial audio input 2 + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - power-domains + - dais + +unevaluatedProperties: false + +examples: + - | + audmix@59840000 { + compatible = "fsl,imx8qm-audmix"; + reg = <0x59840000 0x10000>; + clocks = <&amix_lpcg 0>; + clock-names = "ipg"; + power-domains = <&pd_audmix>; + dais = <&sai4>, <&sai5>; + }; -- cgit v1.2.3 From 1fdc23aa57913d7a0a521f71dcdefdde9364d4f9 Mon Sep 17 00:00:00 2001 From: Kartik Agarwala Date: Mon, 18 Mar 2024 01:32:02 +0530 Subject: ASoC: dt-bindings: wm8776: Convert to dtschema Convert WM8776 audio CODEC bindings from text to dtschema. Signed-off-by: Kartik Agarwala Reviewed-by: Charles Keepax Reviewed-by: Krzysztof Kozlowski Link: https://msgid.link/r/20240317200201.119233-1-agarwala.kartik@gmail.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/wlf,wm8776.yaml | 41 ++++++++++++++++++++++ Documentation/devicetree/bindings/sound/wm8776.txt | 18 ---------- 2 files changed, 41 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8776.yaml delete mode 100644 Documentation/devicetree/bindings/sound/wm8776.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8776.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8776.yaml new file mode 100644 index 000000000000..7bbc96ee81be --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8776.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8776.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8776 audio CODEC + +maintainers: + - patches@opensource.cirrus.com + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: wlf,wm8776 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@1a { + compatible = "wlf,wm8776"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wm8776.txt b/Documentation/devicetree/bindings/sound/wm8776.txt deleted file mode 100644 index 01173369c3ed..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8776.txt +++ /dev/null @@ -1,18 +0,0 @@ -WM8776 audio CODEC - -This device supports both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - - compatible : "wlf,wm8776" - - - reg : the I2C address of the device for I2C, the chip select - number for SPI. - -Example: - -wm8776: codec@1a { - compatible = "wlf,wm8776"; - reg = <0x1a>; -}; -- cgit v1.2.3 From 885dd75f41f9fff5b277bc6ab28ad798f98a37b4 Mon Sep 17 00:00:00 2001 From: Frank Li Date: Fri, 22 Mar 2024 10:54:05 -0400 Subject: ASoC: dt-bindings: fsl-esai: Convert fsl,esai.txt to yaml Convert fsl,esai.txt to yaml. So DTB_CHECK tools can verify dts file about esai part. clock-names 'spba' is optional according to description. So minItems of clocks and clock-names is 3. Signed-off-by: Frank Li Reviewed-by: Rob Herring Link: https://msgid.link/r/20240322145406.2613256-1-Frank.Li@nxp.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/fsl,esai.txt | 68 ------------ .../devicetree/bindings/sound/fsl,esai.yaml | 116 +++++++++++++++++++++ 2 files changed, 116 insertions(+), 68 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/fsl,esai.txt create mode 100644 Documentation/devicetree/bindings/sound/fsl,esai.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt b/Documentation/devicetree/bindings/sound/fsl,esai.txt deleted file mode 100644 index 90112ca1ff42..000000000000 --- a/Documentation/devicetree/bindings/sound/fsl,esai.txt +++ /dev/null @@ -1,68 +0,0 @@ -Freescale Enhanced Serial Audio Interface (ESAI) Controller - -The Enhanced Serial Audio Interface (ESAI) provides a full-duplex serial port -for serial communication with a variety of serial devices, including industry -standard codecs, Sony/Phillips Digital Interface (S/PDIF) transceivers, and -other DSPs. It has up to six transmitters and four receivers. - -Required properties: - - - compatible : Compatible list, should contain one of the following - compatibles: - "fsl,imx35-esai", - "fsl,vf610-esai", - "fsl,imx6ull-esai", - "fsl,imx8qm-esai", - - - reg : Offset and length of the register set for the device. - - - interrupts : Contains the spdif interrupt. - - - dmas : Generic dma devicetree binding as described in - Documentation/devicetree/bindings/dma/dma.txt. - - - dma-names : Two dmas have to be defined, "tx" and "rx". - - - clocks : Contains an entry for each entry in clock-names. - - - clock-names : Includes the following entries: - "core" The core clock used to access registers - "extal" The esai baud clock for esai controller used to - derive HCK, SCK and FS. - "fsys" The system clock derived from ahb clock used to - derive HCK, SCK and FS. - "spba" The spba clock is required when ESAI is placed as a - bus slave of the Shared Peripheral Bus and when two - or more bus masters (CPU, DMA or DSP) try to access - it. This property is optional depending on the SoC - design. - - - fsl,fifo-depth : The number of elements in the transmit and receive - FIFOs. This number is the maximum allowed value for - TFCR[TFWM] or RFCR[RFWM]. - - - fsl,esai-synchronous: This is a boolean property. If present, indicating - that ESAI would work in the synchronous mode, which - means all the settings for Receiving would be - duplicated from Transmission related registers. - -Optional properties: - - - big-endian : If this property is absent, the native endian mode - will be in use as default, or the big endian mode - will be in use for all the device registers. - -Example: - -esai: esai@2024000 { - compatible = "fsl,imx35-esai"; - reg = <0x02024000 0x4000>; - interrupts = <0 51 0x04>; - clocks = <&clks 208>, <&clks 118>, <&clks 208>; - clock-names = "core", "extal", "fsys"; - dmas = <&sdma 23 21 0>, <&sdma 24 21 0>; - dma-names = "rx", "tx"; - fsl,fifo-depth = <128>; - fsl,esai-synchronous; - big-endian; -}; diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.yaml b/Documentation/devicetree/bindings/sound/fsl,esai.yaml new file mode 100644 index 000000000000..f167f1634d7e --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,esai.yaml @@ -0,0 +1,116 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,esai.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Enhanced Serial Audio Interface (ESAI) Controller + +maintainers: + - Shengjiu Wang + - Frank Li + +description: + The Enhanced Serial Audio Interface (ESAI) provides a full-duplex serial port + for serial communication with a variety of serial devices, including industry + standard codecs, Sony/Phillips Digital Interface (S/PDIF) transceivers, and + other DSPs. It has up to six transmitters and four receivers. + +properties: + compatible: + enum: + - fsl,imx35-esai + - fsl,imx6ull-esai + - fsl,imx8qm-esai + - fsl,vf610-esai + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 3 + items: + - description: + The core clock used to access registers. + - description: + The esai baud clock for esai controller used to + derive HCK, SCK and FS. + - description: + The system clock derived from ahb clock used to + derive HCK, SCK and FS. + - description: + The spba clock is required when ESAI is placed as a + bus slave of the Shared Peripheral Bus and when two + or more bus masters (CPU, DMA or DSP) try to access + it. This property is optional depending on the SoC + design. + + clock-names: + minItems: 3 + items: + - const: core + - const: extal + - const: fsys + - const: spba + + dmas: + minItems: 2 + maxItems: 2 + + dma-names: + items: + - const: rx + - const: tx + + fsl,fifo-depth: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The number of elements in the transmit and receive + FIFOs. This number is the maximum allowed value for + TFCR[TFWM] or RFCR[RFWM]. + + fsl,esai-synchronous: + $ref: /schemas/types.yaml#/definitions/flag + description: + This is a boolean property. If present, indicating + that ESAI would work in the synchronous mode, which + means all the settings for Receiving would be + duplicated from Transmission related registers. + + big-endian: + $ref: /schemas/types.yaml#/definitions/flag + description: + If this property is absent, the native endian mode + will be in use as default, or the big endian mode + will be in use for all the device registers. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + - fsl,fifo-depth + - fsl,esai-synchronous + +unevaluatedProperties: false + +examples: + - | + esai@2024000 { + compatible = "fsl,imx35-esai"; + reg = <0x02024000 0x4000>; + interrupts = <0 51 0x04>; + clocks = <&clks 208>, <&clks 118>, <&clks 208>; + clock-names = "core", "extal", "fsys"; + dmas = <&sdma 23 21 0>, <&sdma 24 21 0>; + dma-names = "rx", "tx"; + fsl,fifo-depth = <128>; + fsl,esai-synchronous; + big-endian; + }; -- cgit v1.2.3 From b340f56a74b62d8ce8617650c8ab4a26c87ba5c5 Mon Sep 17 00:00:00 2001 From: Kartik Agarwala Date: Mon, 25 Mar 2024 23:49:42 +0530 Subject: ASoC: dt-bindings: wm8974: Convert to dtschema Convert WM8974 audio CODEC bindings from text to dtschema. Signed-off-by: Kartik Agarwala Reviewed-by: Krzysztof Kozlowski Link: https://msgid.link/r/20240325181943.116733-1-agarwala.kartik@gmail.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/wlf,wm8974.txt | 15 -------- .../devicetree/bindings/sound/wlf,wm8974.yaml | 41 ++++++++++++++++++++++ 2 files changed, 41 insertions(+), 15 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8974.txt create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8974.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8974.txt b/Documentation/devicetree/bindings/sound/wlf,wm8974.txt deleted file mode 100644 index 01d3a7c83419..000000000000 --- a/Documentation/devicetree/bindings/sound/wlf,wm8974.txt +++ /dev/null @@ -1,15 +0,0 @@ -WM8974 audio CODEC - -This device supports both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - compatible: "wlf,wm8974" - - reg: the I2C address or SPI chip select number of the device - -Examples: - -codec: wm8974@1a { - compatible = "wlf,wm8974"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8974.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8974.yaml new file mode 100644 index 000000000000..d27300207c67 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8974.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8974.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8974 audio CODEC + +maintainers: + - patches@opensource.cirrus.com + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: wlf,wm8974 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@1a { + compatible = "wlf,wm8974"; + reg = <0x1a>; + }; + }; -- cgit v1.2.3 From cce4cbb157493483f03c21213753b66425a31430 Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Tue, 5 Mar 2024 15:36:29 +0100 Subject: ASoC: dt-bindings: Add Rockchip RK3308 internal audio codec Add device tree bindings document for the internal audio codec of the Rockchip RK3308 SoC. Reviewed-by: Rob Herring Signed-off-by: Luca Ceresoli Link: https://msgid.link/r/20240305-rk3308-audio-codec-v4-2-312acdbe628f@bootlin.com Signed-off-by: Mark Brown --- .../bindings/sound/rockchip,rk3308-codec.yaml | 98 ++++++++++++++++++++++ MAINTAINERS | 5 ++ 2 files changed, 103 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml new file mode 100644 index 000000000000..ecf3d7d968c8 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/rockchip,rk3308-codec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3308 Internal Codec + +description: | + This is the audio codec embedded in the Rockchip RK3308 + SoC. It has 8 24-bit ADCs and 2 24-bit DACs. The maximum supported + sampling rate is 192 kHz. + + It is connected internally to one out of a selection of the internal I2S + controllers. + + The RK3308 audio codec has 8 independent capture channels, but some + features work on stereo pairs called groups: + * grp 0 -- MIC1 / MIC2 + * grp 1 -- MIC3 / MIC4 + * grp 2 -- MIC5 / MIC6 + * grp 3 -- MIC7 / MIC8 + +maintainers: + - Luca Ceresoli + +properties: + compatible: + const: rockchip,rk3308-codec + + reg: + maxItems: 1 + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the General Register Files (GRF) + + clocks: + items: + - description: clock for TX + - description: clock for RX + - description: AHB clock driving the interface + + clock-names: + items: + - const: mclk_tx + - const: mclk_rx + - const: hclk + + resets: + maxItems: 1 + + reset-names: + items: + - const: codec + + "#sound-dai-cells": + const: 0 + + rockchip,micbias-avdd-percent: + description: | + Voltage setting for the MICBIAS pins expressed as a percentage of + AVDD. + + E.g. if rockchip,micbias-avdd-percent = 85 and AVDD = 3v3, then the + MIC BIAS voltage will be 3.3 V * 85% = 2.805 V. + + enum: [ 50, 55, 60, 65, 70, 75, 80, 85 ] + +required: + - compatible + - reg + - rockchip,grf + - clocks + - resets + - "#sound-dai-cells" + +additionalProperties: false + +examples: + - | + #include + + audio_codec: audio-codec@ff560000 { + compatible = "rockchip,rk3308-codec"; + reg = <0xff560000 0x10000>; + rockchip,grf = <&grf>; + clock-names = "mclk_tx", "mclk_rx", "hclk"; + clocks = <&cru SCLK_I2S2_8CH_TX_OUT>, + <&cru SCLK_I2S2_8CH_RX_OUT>, + <&cru PCLK_ACODEC>; + reset-names = "codec"; + resets = <&cru SRST_ACODEC_P>; + #sound-dai-cells = <0>; + }; + +... diff --git a/MAINTAINERS b/MAINTAINERS index aa3b947fb080..89a59660bf0f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -19046,6 +19046,11 @@ S: Maintained F: Documentation/devicetree/bindings/media/rockchip-rga.yaml F: drivers/media/platform/rockchip/rga/ +ROCKCHIP RK3308 INTERNAL AUDIO CODEC +M: Luca Ceresoli +S: Maintained +F: Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml + ROCKCHIP VIDEO DECODER DRIVER M: Ezequiel Garcia L: linux-media@vger.kernel.org -- cgit v1.2.3 From 2e4c003b3672085267a358ebf82129b4e08dd64f Mon Sep 17 00:00:00 2001 From: Seven Lee Date: Wed, 27 Mar 2024 15:57:54 +0800 Subject: ASoC: dt-bindings: Added schema for "nuvoton,nau8325" Add a DT schema for describing nau8325 audio amplifiers. The key features are as follows: - Low SPK_VDD Quiescent Current - Gain Setting with 2-wire interface - Powerful Stereo Class-D Amplifier - Low Output Noise - Low Current Shutdown Mode - Click-and Pop Suppression More resources : https://www.nuvoton.com/products/smart-home-audio/audio-amplifiers/class-d-series/nau8325yg/ Signed-off-by: Seven Lee Reviewed-by: Rob Herring Link: https://msgid.link/r/20240327075755.3410381-2-wtli@nuvoton.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/nuvoton,nau8325.yaml | 80 ++++++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/nuvoton,nau8325.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8325.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8325.yaml new file mode 100644 index 000000000000..979be0d336da --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8325.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/nuvoton,nau8325.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NAU8325 audio Amplifier + +maintainers: + - Seven Lee + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: nuvoton,nau8325 + + reg: + maxItems: 1 + + nuvoton,vref-impedance-ohms: + description: + The vref impedance to be used in ohms. Middle of voltage enables + Tie-Off selection options. Due to the high impedance of the VREF + pin, it is important to use a low-leakage capacitor. + + enum: [0, 25000, 125000, 2500] + + nuvoton,dac-vref-microvolt: + description: + The DAC vref to be used in voltage. DAC reference voltage setting. Can + be used for minor tuning of the output level. Since the VDDA is range + between 1.62 to 1.98 voltage, the typical value for design is 1.8V. After + the minor tuning, the final microvolt are as the below. + + enum: [1800000, 2700000, 2880000, 3060000] + + nuvoton,alc-enable: + description: + Enable digital automatic level control (ALC) function. + type: boolean + + nuvoton,clock-detection-disable: + description: + When clock detection is enabled, it will detect whether MCLK + and FS are within the range. MCLK range is from 2.048MHz to 24.576MHz. + FS range is from 8kHz to 96kHz. And also needs to detect the ratio + MCLK_SRC/LRCK of 256, 400 or 500, and needs to detect the BCLK + to make sure data is present. There needs to be at least 8 BCLK + cycles per Frame Sync. + type: boolean + + nuvoton,clock-det-data: + description: + Request clock detection to require 2048 non-zero samples before enabling + the audio paths. If set then non-zero samples is required, otherwise it + doesn't matter. + type: boolean + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@21 { + compatible = "nuvoton,nau8325"; + reg = <0x21>; + nuvoton,vref-impedance-ohms = <125000>; + nuvoton,dac-vref-microvolt = <2880000>; + nuvoton,alc-enable; + nuvoton,clock-det-data; + }; + }; -- cgit v1.2.3 From 9b21531866fced634bcc7fca33667c7ef258433f Mon Sep 17 00:00:00 2001 From: Frank Li Date: Thu, 28 Mar 2024 10:51:33 -0400 Subject: ASoC: dt-bindings: fsl,imx-asrc/spdif: Add power-domains property Add power-domains property for asrc and spdif since fsl,imx8qm-asrc/spdif and fsl,imx8qxp-asrc/spdif require 'power-domains'. Set 'power-domains' as required property for compatible string fsl,imx8qm-asrc/spdif and fsl,imx8qxp-asrc/spdif. Acked-by: Conor Dooley Signed-off-by: Frank Li Link: https://msgid.link/r/20240328-asrc_8qxp-v8-1-801cd6bb5be2@nxp.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml | 14 ++++++++++++++ Documentation/devicetree/bindings/sound/fsl,spdif.yaml | 15 +++++++++++++++ 2 files changed, 29 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml b/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml index bfef2fcb75b1..76aa1f248488 100644 --- a/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml @@ -74,6 +74,9 @@ properties: - const: asrck_f - const: spba + power-domains: + maxItems: 1 + fsl,asrc-rate: $ref: /schemas/types.yaml#/definitions/uint32 description: The mutual sample rate used by DPCM Back Ends @@ -131,6 +134,17 @@ allOf: properties: fsl,asrc-clk-map: false + - if: + properties: + compatible: + contains: + enum: + - fsl,imx8qm-asrc + - fsl,imx8qxp-asrc + then: + required: + - power-domains + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml index 1d64e8337aa4..56f8c0c8afde 100644 --- a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml @@ -86,6 +86,9 @@ properties: registers. Set this flag for HCDs with big endian descriptors and big endian registers. + power-domains: + maxItems: 1 + required: - compatible - reg @@ -97,6 +100,18 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + enum: + - fsl,imx8qm-spdif + - fsl,imx8qxp-spdif + then: + required: + - power-domains + examples: - | spdif@2004000 { -- cgit v1.2.3 From 82330327ce03889f20072cef5167499d51cdf260 Mon Sep 17 00:00:00 2001 From: Frank Li Date: Thu, 28 Mar 2024 10:51:34 -0400 Subject: ASoC: dt-bindings: fsl,imx-asrc: update max interrupt numbers fsl,imx8qxp-spdif and fsl,imx8qm-spdif have 2 interrupts. Other platforms have 1 interrupt. Increase max interrupt number to 2 and add restriction for platforms except i.MX8QXP and i.MX8QM. Reviewed-by: Rob Herring Signed-off-by: Frank Li Link: https://msgid.link/r/20240328-asrc_8qxp-v8-2-801cd6bb5be2@nxp.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/fsl,spdif.yaml | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml index 56f8c0c8afde..204f361cea27 100644 --- a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml @@ -31,7 +31,10 @@ properties: maxItems: 1 interrupts: - maxItems: 1 + minItems: 1 + items: + - description: Combined or receive interrupt + - description: Transmit interrupt dmas: items: @@ -101,6 +104,21 @@ required: additionalProperties: false allOf: + - if: + properties: + compatible: + enum: + - fsl,imx8qm-spdif + - fsl,imx8qxp-spdif + then: + properties: + interrupts: + minItems: 2 + else: + properties: + interrupts: + maxItems: 1 + - if: properties: compatible: -- cgit v1.2.3 From 7b5f2072657a9041cbaf4ba139f672be11694ca3 Mon Sep 17 00:00:00 2001 From: Frank Li Date: Thu, 28 Mar 2024 10:51:35 -0400 Subject: ASoC: dt-bindings: fsl-sai: allow only one dma-names Some sai only connect one direction dma (rx/tx) in SOC. For example: imx8qxp sai5 only connect tx dma channel. So allow only one "rx" or "tx" for dma-names. Remove description under dmas because no user use index to get dma channel. All user use 'dma-names' to get correct dma channel. dma-names already in 'required' list. Reviewed-by: Rob Herring Signed-off-by: Frank Li Link: https://msgid.link/r/20240328-asrc_8qxp-v8-3-801cd6bb5be2@nxp.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl,sai.yaml | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml b/Documentation/devicetree/bindings/sound/fsl,sai.yaml index 2456d958adee..a5d9c246cc47 100644 --- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml @@ -81,14 +81,12 @@ properties: dmas: minItems: 1 - items: - - description: DMA controller phandle and request line for RX - - description: DMA controller phandle and request line for TX + maxItems: 2 dma-names: minItems: 1 items: - - const: rx + - enum: [ rx, tx ] - const: tx interrupts: -- cgit v1.2.3 From be1b7acb929137e3943fe380671242beb485190c Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Tue, 2 Apr 2024 05:57:15 +0300 Subject: dt-bindings: display/msm: sm8150-mdss: add DP node As Qualcomm SM8150 got support for the DisplayPort, add displayport@ node as a valid child to the MDSS node. Fixes: 88806318e2c2 ("dt-bindings: display: msm: dp: declare compatible string for sm8150") Reviewed-by: Krzysztof Kozlowski Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/586156/ Link: https://lore.kernel.org/r/20240402-fd-fix-schema-v3-1-817ea6ddf775@linaro.org Signed-off-by: Abhinav Kumar --- .../devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml index c0d6a4fdff97..e6dc5494baee 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml @@ -53,6 +53,15 @@ patternProperties: compatible: const: qcom,sm8150-dpu + "^displayport-controller@[0-9a-f]+$": + type: object + additionalProperties: true + + properties: + compatible: + contains: + const: qcom,sm8150-dp + "^dsi@[0-9a-f]+$": type: object additionalProperties: true -- cgit v1.2.3 From 4189b54220e5af15e948a48524b45d5ea2e5660d Mon Sep 17 00:00:00 2001 From: Shengjiu Wang Date: Mon, 1 Apr 2024 20:54:16 +0800 Subject: ASoC: dt-bindings: fsl-asoc-card: convert to YAML Convert the fsl-asoc-card binding to YAML. When testing dtbs_check, found below compatible strings are not listed in document: fsl,imx-sgtl5000 fsl,imx53-cpuvo-sgtl5000 fsl,imx51-babbage-sgtl5000 fsl,imx53-m53evk-sgtl5000 fsl,imx53-qsb-sgtl5000 fsl,imx53-voipac-sgtl5000 fsl,imx6-armadeus-sgtl5000 fsl,imx6-rex-sgtl5000 fsl,imx6-sabreauto-cs42888 fsl,imx6-wandboard-sgtl5000 fsl,imx6dl-nit6xlite-sgtl5000 fsl,imx6q-ba16-sgtl5000 fsl,imx6q-nitrogen6_max-sgtl5000 fsl,imx6q-nitrogen6_som2-sgtl5000 fsl,imx6q-nitrogen6x-sgtl5000 fsl,imx6q-sabrelite-sgtl5000 fsl,imx6q-sabresd-wm8962 fsl,imx6q-udoo-ac97 fsl,imx6q-ventana-sgtl5000 fsl,imx6sl-evk-wm8962 fsl,imx6sx-sdb-mqs fsl,imx6sx-sdb-wm8962 fsl,imx7d-evk-wm8960 karo,tx53-audio-sgtl5000 tq,imx53-mba53-sgtl5000 So add them in yaml file to pass the test. Also correct the 'dai-format' to 'format' in document. For 'audio-routing', the items are not listed. Because this fsl-asoc-card is generic driver, which supports several codecs, if list all the items, there will be a long list. Signed-off-by: Shengjiu Wang Reviewed-by: Rob Herring Link: https://msgid.link/r/1711976056-19884-3-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/fsl-asoc-card.txt | 117 ------------- .../devicetree/bindings/sound/fsl-asoc-card.yaml | 195 +++++++++++++++++++++ 2 files changed, 195 insertions(+), 117 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/fsl-asoc-card.txt create mode 100644 Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt deleted file mode 100644 index 4e8dbc5abfd1..000000000000 --- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt +++ /dev/null @@ -1,117 +0,0 @@ -Freescale Generic ASoC Sound Card with ASRC support - -The Freescale Generic ASoC Sound Card can be used, ideally, for all Freescale -SoCs connecting with external CODECs. - -The idea of this generic sound card is a bit like ASoC Simple Card. However, -for Freescale SoCs (especially those released in recent years), most of them -have ASRC (Documentation/devicetree/bindings/sound/fsl,asrc.txt) inside. And -this is a specific feature that might be painstakingly controlled and merged -into the Simple Card. - -So having this generic sound card allows all Freescale SoC users to benefit -from the simplification of a new card support and the capability of the wide -sample rates support through ASRC. - -Note: The card is initially designed for those sound cards who use AC'97, I2S - and PCM DAI formats. However, it'll be also possible to support those non - AC'97/I2S/PCM type sound cards, such as S/PDIF audio and HDMI audio, as - long as the driver has been properly upgraded. - - -The compatible list for this generic sound card currently: - "fsl,imx-audio-ac97" - - "fsl,imx-audio-cs42888" - - "fsl,imx-audio-cs427x" - (compatible with CS4271 and CS4272) - - "fsl,imx-audio-wm8962" - - "fsl,imx-audio-sgtl5000" - (compatible with Documentation/devicetree/bindings/sound/imx-audio-sgtl5000.txt) - - "fsl,imx-audio-wm8960" - - "fsl,imx-audio-mqs" - - "fsl,imx-audio-wm8524" - - "fsl,imx-audio-tlv320aic32x4" - - "fsl,imx-audio-tlv320aic31xx" - - "fsl,imx-audio-si476x" - - "fsl,imx-audio-wm8958" - - "fsl,imx-audio-nau8822" - -Required properties: - - - compatible : Contains one of entries in the compatible list. - - - model : The user-visible name of this sound complex - - - audio-cpu : The phandle of an CPU DAI controller - - - audio-codec : The phandle of an audio codec - -Optional properties: - - - audio-asrc : The phandle of ASRC. It can be absent if there's no - need to add ASRC support via DPCM. - - - 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. There're a few pre-designed board connectors: - * Line Out Jack - * Line In Jack - * Headphone Jack - * Mic Jack - * Ext Spk - * AMIC (stands for Analog Microphone Jack) - * DMIC (stands for Digital Microphone Jack) - - Note: The "Mic Jack" and "AMIC" are redundant while - coexisting in order to support the old bindings - of wm8962 and sgtl5000. - - - hp-det-gpio : The GPIO that detect headphones are plugged in - - mic-det-gpio : The GPIO that detect microphones are plugged in - - bitclock-master : Indicates dai-link bit clock master; for details see simple-card.yaml. - - frame-master : Indicates dai-link frame master; for details see simple-card.yaml. - - 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: - - - mux-int-port : The internal port of the i.MX audio muxer (AUDMUX) - - - mux-ext-port : The external port of the i.MX audio muxer - -Example: -sound-cs42888 { - compatible = "fsl,imx-audio-cs42888"; - model = "cs42888-audio"; - audio-cpu = <&esai>; - audio-asrc = <&asrc>; - audio-codec = <&cs42888>; - audio-routing = - "Line Out Jack", "AOUT1L", - "Line Out Jack", "AOUT1R", - "Line Out Jack", "AOUT2L", - "Line Out Jack", "AOUT2R", - "Line Out Jack", "AOUT3L", - "Line Out Jack", "AOUT3R", - "Line Out Jack", "AOUT4L", - "Line Out Jack", "AOUT4R", - "AIN1L", "Line In Jack", - "AIN1R", "Line In Jack", - "AIN2L", "Line In Jack", - "AIN2R", "Line In Jack"; -}; diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml b/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml new file mode 100644 index 000000000000..42ca39eebd49 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml @@ -0,0 +1,195 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl-asoc-card.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Generic ASoC Sound Card with ASRC support + +description: + The Freescale Generic ASoC Sound Card can be used, ideally, + for all Freescale SoCs connecting with external CODECs. + + The idea of this generic sound card is a bit like ASoC Simple Card. + However, for Freescale SoCs (especially those released in recent years), + most of them have ASRC inside. And this is a specific feature that might + be painstakingly controlled and merged into the Simple Card. + + So having this generic sound card allows all Freescale SoC users to + benefit from the simplification of a new card support and the capability + of the wide sample rates support through ASRC. + + Note, The card is initially designed for those sound cards who use AC'97, I2S + and PCM DAI formats. However, it'll be also possible to support those non + AC'97/I2S/PCM type sound cards, such as S/PDIF audio and HDMI audio, as + long as the driver has been properly upgraded. + +maintainers: + - Shengjiu Wang + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,imx-sgtl5000 + - fsl,imx53-cpuvo-sgtl5000 + - fsl,imx51-babbage-sgtl5000 + - fsl,imx53-m53evk-sgtl5000 + - fsl,imx53-qsb-sgtl5000 + - fsl,imx53-voipac-sgtl5000 + - fsl,imx6-armadeus-sgtl5000 + - fsl,imx6-rex-sgtl5000 + - fsl,imx6-sabreauto-cs42888 + - fsl,imx6-wandboard-sgtl5000 + - fsl,imx6dl-nit6xlite-sgtl5000 + - fsl,imx6q-ba16-sgtl5000 + - fsl,imx6q-nitrogen6_max-sgtl5000 + - fsl,imx6q-nitrogen6_som2-sgtl5000 + - fsl,imx6q-nitrogen6x-sgtl5000 + - fsl,imx6q-sabrelite-sgtl5000 + - fsl,imx6q-sabresd-wm8962 + - fsl,imx6q-udoo-ac97 + - fsl,imx6q-ventana-sgtl5000 + - fsl,imx6sl-evk-wm8962 + - fsl,imx6sx-sdb-mqs + - fsl,imx6sx-sdb-wm8962 + - fsl,imx7d-evk-wm8960 + - karo,tx53-audio-sgtl5000 + - tq,imx53-mba53-sgtl5000 + - enum: + - fsl,imx-audio-ac97 + - fsl,imx-audio-cs42888 + - fsl,imx-audio-mqs + - fsl,imx-audio-sgtl5000 + - fsl,imx-audio-wm8960 + - fsl,imx-audio-wm8962 + - items: + - enum: + - fsl,imx-audio-ac97 + - fsl,imx-audio-cs42888 + - fsl,imx-audio-cs427x + - fsl,imx-audio-mqs + - fsl,imx-audio-nau8822 + - fsl,imx-audio-sgtl5000 + - fsl,imx-audio-si476x + - fsl,imx-audio-tlv320aic31xx + - fsl,imx-audio-tlv320aic32x4 + - fsl,imx-audio-wm8524 + - fsl,imx-audio-wm8960 + - fsl,imx-audio-wm8962 + - fsl,imx-audio-wm8958 + + model: + $ref: /schemas/types.yaml#/definitions/string + description: The user-visible name of this sound complex + + audio-asrc: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of ASRC. It can be absent if there's no + need to add ASRC support via DPCM. + + audio-codec: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of an audio codec + + audio-cpu: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of an CPU DAI controller + + 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. There're a few pre-designed board + connectors. "AMIC" stands for Analog Microphone Jack. + "DMIC" stands for Digital Microphone Jack. The "Mic Jack" and "AMIC" + are redundant while coexisting in order to support the old bindings + of wm8962 and sgtl5000. + + hp-det-gpio: + deprecated: true + maxItems: 1 + description: The GPIO that detect headphones are plugged in + + hp-det-gpios: + maxItems: 1 + description: The GPIO that detect headphones are plugged in + + mic-det-gpio: + deprecated: true + maxItems: 1 + description: The GPIO that detect microphones are plugged in + + mic-det-gpios: + maxItems: 1 + description: The GPIO that detect microphones are plugged in + + bitclock-master: + $ref: simple-card.yaml#/definitions/bitclock-master + description: Indicates dai-link bit clock master. + + frame-master: + $ref: simple-card.yaml#/definitions/frame-master + description: Indicates dai-link frame master. + + format: + $ref: simple-card.yaml#/definitions/format + description: audio format. + + frame-inversion: + $ref: simple-card.yaml#/definitions/frame-inversion + description: dai-link uses frame clock inversion. + + bitclock-inversion: + $ref: simple-card.yaml#/definitions/bitclock-inversion + description: dai-link uses bit clock inversion. + + mclk-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: main clock id, specific for each card configuration. + + mux-int-port: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 7] + description: The internal port of the i.MX audio muxer (AUDMUX) + + mux-ext-port: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [3, 4, 5, 6] + description: The external port of the i.MX audio muxer + + ssi-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of an CPU DAI controller + +required: + - compatible + - model + +unevaluatedProperties: false + +examples: + - | + sound-cs42888 { + compatible = "fsl,imx-audio-cs42888"; + model = "cs42888-audio"; + audio-cpu = <&esai>; + audio-asrc = <&asrc>; + audio-codec = <&cs42888>; + audio-routing = + "Line Out Jack", "AOUT1L", + "Line Out Jack", "AOUT1R", + "Line Out Jack", "AOUT2L", + "Line Out Jack", "AOUT2R", + "Line Out Jack", "AOUT3L", + "Line Out Jack", "AOUT3R", + "Line Out Jack", "AOUT4L", + "Line Out Jack", "AOUT4R", + "AIN1L", "Line In Jack", + "AIN1R", "Line In Jack", + "AIN2L", "Line In Jack", + "AIN2R", "Line In Jack"; + }; -- cgit v1.2.3 From aa98e70fc6c97f39a7bd68cb1e641ca50d4f9423 Mon Sep 17 00:00:00 2001 From: Bagas Sanjaya Date: Fri, 5 Apr 2024 14:23:18 +0700 Subject: Documentation: filesystems: Add bcachefs toctree Commit eb386617be4bdf ("bcachefs: Errcode tracepoint, documentation") adds initial bcachefs documentation (private error codes) but without any table of contents tree for the filesystem docs, hence Sphinx warns: Documentation/filesystems/bcachefs/errorcodes.rst: WARNING: document isn't included in any toctree Add bcachefs toctree to fix above warning. Fixes: eb386617be4b ("bcachefs: Errcode tracepoint, documentation") Signed-off-by: Bagas Sanjaya Signed-off-by: Kent Overstreet --- Documentation/filesystems/bcachefs/index.rst | 11 +++++++++++ Documentation/filesystems/index.rst | 1 + 2 files changed, 12 insertions(+) create mode 100644 Documentation/filesystems/bcachefs/index.rst (limited to 'Documentation') diff --git a/Documentation/filesystems/bcachefs/index.rst b/Documentation/filesystems/bcachefs/index.rst new file mode 100644 index 000000000000..e2bd61ccd96f --- /dev/null +++ b/Documentation/filesystems/bcachefs/index.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================== +bcachefs Documentation +====================== + +.. toctree:: + :maxdepth: 2 + :numbered: + + errorcodes diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index 0ea1e44fa028..1f9b4c905a6a 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -69,6 +69,7 @@ Documentation for filesystem implementations. afs autofs autofs-mount-control + bcachefs/index befs bfs btrfs -- cgit v1.2.3 From ffe6176b7f53ca0c99355f13e14a33a40cf49406 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sun, 31 Mar 2024 10:43:48 +0200 Subject: virtio: store owner from modules with register_virtio_driver() Modules registering driver with register_virtio_driver() might forget to set .owner field. i2c-virtio.c for example has it missing. The field is used by some other kernel parts for reference counting (try_module_get()), so it is expected that drivers will set it. Solve the problem by moving this task away from the drivers to the core virtio code, just like we did for platform_driver in commit 9447057eaff8 ("platform_device: use a macro instead of platform_driver_register"). Fixes: 3cfc88380413 ("i2c: virtio: add a virtio i2c frontend driver") Cc: "Jie Deng" Signed-off-by: Krzysztof Kozlowski Message-Id: <20240331-module-owner-virtio-v2-1-98f04bfaf46a@linaro.org> Signed-off-by: Michael S. Tsirkin --- Documentation/driver-api/virtio/writing_virtio_drivers.rst | 1 - drivers/virtio/virtio.c | 6 ++++-- include/linux/virtio.h | 7 +++++-- 3 files changed, 9 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/virtio/writing_virtio_drivers.rst b/Documentation/driver-api/virtio/writing_virtio_drivers.rst index e14c58796d25..e5de6f5d061a 100644 --- a/Documentation/driver-api/virtio/writing_virtio_drivers.rst +++ b/Documentation/driver-api/virtio/writing_virtio_drivers.rst @@ -97,7 +97,6 @@ like this:: static struct virtio_driver virtio_dummy_driver = { .driver.name = KBUILD_MODNAME, - .driver.owner = THIS_MODULE, .id_table = id_table, .probe = virtio_dummy_probe, .remove = virtio_dummy_remove, diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c index f173587893cb..9510c551dce8 100644 --- a/drivers/virtio/virtio.c +++ b/drivers/virtio/virtio.c @@ -362,14 +362,16 @@ static const struct bus_type virtio_bus = { .remove = virtio_dev_remove, }; -int register_virtio_driver(struct virtio_driver *driver) +int __register_virtio_driver(struct virtio_driver *driver, struct module *owner) { /* Catch this early. */ BUG_ON(driver->feature_table_size && !driver->feature_table); driver->driver.bus = &virtio_bus; + driver->driver.owner = owner; + return driver_register(&driver->driver); } -EXPORT_SYMBOL_GPL(register_virtio_driver); +EXPORT_SYMBOL_GPL(__register_virtio_driver); void unregister_virtio_driver(struct virtio_driver *driver) { diff --git a/include/linux/virtio.h b/include/linux/virtio.h index b0201747a263..26c4325aa373 100644 --- a/include/linux/virtio.h +++ b/include/linux/virtio.h @@ -170,7 +170,7 @@ size_t virtio_max_dma_size(const struct virtio_device *vdev); /** * struct virtio_driver - operations for a virtio I/O driver - * @driver: underlying device driver (populate name and owner). + * @driver: underlying device driver (populate name). * @id_table: the ids serviced by this driver. * @feature_table: an array of feature numbers supported by this driver. * @feature_table_size: number of entries in the feature table array. @@ -208,7 +208,10 @@ static inline struct virtio_driver *drv_to_virtio(struct device_driver *drv) return container_of(drv, struct virtio_driver, driver); } -int register_virtio_driver(struct virtio_driver *drv); +/* use a macro to avoid include chaining to get THIS_MODULE */ +#define register_virtio_driver(drv) \ + __register_virtio_driver(drv, THIS_MODULE) +int __register_virtio_driver(struct virtio_driver *drv, struct module *owner); void unregister_virtio_driver(struct virtio_driver *drv); /* module_virtio_driver() - Helper macro for drivers that don't do -- cgit v1.2.3 From c64c4e3f789123e82ffae3404d108cf826c9599a Mon Sep 17 00:00:00 2001 From: Mohammad Rafi Shaik Date: Mon, 8 Apr 2024 09:53:30 +0530 Subject: ASoC: dt-bindings: qcom,sm8250: Add QCM6490 snd QCS6490 sound card Document the bindings for the Qualcomm QCM6490 IDP and QCS6490 RB3Gen2 board specific sound card. The bindings are the same as for other newer Qualcomm ADSP sound cards, thus keep them in existing qcom,sm8250.yaml file, even though Linux driver is separate. Signed-off-by: Mohammad Rafi Shaik Acked-by: Krzysztof Kozlowski Reviewed-by: Srinivas Kandagatla Link: https://msgid.link/r/20240408042331.403103-2-quic_mohs@quicinc.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml index 2ab6871e89e5..b2e15ebbd1bc 100644 --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml @@ -29,6 +29,8 @@ properties: - enum: - qcom,apq8016-sbc-sndcard - qcom,msm8916-qdsp6-sndcard + - qcom,qcm6490-idp-sndcard + - qcom,qcs6490-rb3gen2-sndcard - qcom,qrb5165-rb5-sndcard - qcom,sc7180-qdsp6-sndcard - qcom,sc8280xp-sndcard -- cgit v1.2.3 From 8167bd1c8a45c289316417cf938bcd8ceec24fd5 Mon Sep 17 00:00:00 2001 From: Animesh Agarwal Date: Sat, 6 Apr 2024 19:44:49 +0530 Subject: ASoC: dt-bindings: ti,pcm1681: Convert to dtschema Convert the Texas Instruments PCM1681 bindings to DT schema. Make bindings complete by adding #sound-dai-cells. Signed-off-by: Animesh Agarwal Reviewed-by: Krzysztof Kozlowski Link: https://msgid.link/r/20240406141454.45529-1-animeshagarwal28@gmail.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/ti,pcm1681.txt | 15 -------- .../devicetree/bindings/sound/ti,pcm1681.yaml | 43 ++++++++++++++++++++++ 2 files changed, 43 insertions(+), 15 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/ti,pcm1681.txt create mode 100644 Documentation/devicetree/bindings/sound/ti,pcm1681.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/ti,pcm1681.txt b/Documentation/devicetree/bindings/sound/ti,pcm1681.txt deleted file mode 100644 index 4df17185ab80..000000000000 --- a/Documentation/devicetree/bindings/sound/ti,pcm1681.txt +++ /dev/null @@ -1,15 +0,0 @@ -Texas Instruments PCM1681 8-channel PWM Processor - -Required properties: - - - compatible: Should contain "ti,pcm1681". - - reg: The i2c address. Should contain <0x4c>. - -Examples: - - i2c_bus { - pcm1681@4c { - compatible = "ti,pcm1681"; - reg = <0x4c>; - }; - }; diff --git a/Documentation/devicetree/bindings/sound/ti,pcm1681.yaml b/Documentation/devicetree/bindings/sound/ti,pcm1681.yaml new file mode 100644 index 000000000000..5aa00617291c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ti,pcm1681.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/ti,pcm1681.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments PCM1681 8-channel PWM Processor + +maintainers: + - Shenghao Ding + - Kevin Lu + - Baojun Xu + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: ti,pcm1681 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pcm1681: audio-codec@4c { + compatible = "ti,pcm1681"; + reg = <0x4c>; + }; + }; -- cgit v1.2.3 From ec9404e40e8f36421a2b66ecb76dc2209fe7f3ef Mon Sep 17 00:00:00 2001 From: Pawan Gupta Date: Mon, 11 Mar 2024 08:57:05 -0700 Subject: x86/bhi: Add BHI mitigation knob Branch history clearing software sequences and hardware control BHI_DIS_S were defined to mitigate Branch History Injection (BHI). Add cmdline spectre_bhi={on|off|auto} to control BHI mitigation: auto - Deploy the hardware mitigation BHI_DIS_S, if available. on - Deploy the hardware mitigation BHI_DIS_S, if available, otherwise deploy the software sequence at syscall entry and VMexit. off - Turn off BHI mitigation. The default is auto mode which does not deploy the software sequence mitigation. This is because of the hardening done in the syscall dispatch path, which is the likely target of BHI. Signed-off-by: Pawan Gupta Signed-off-by: Daniel Sneddon Signed-off-by: Thomas Gleixner Reviewed-by: Alexandre Chartre Reviewed-by: Josh Poimboeuf --- Documentation/admin-guide/hw-vuln/spectre.rst | 45 +++++++++++-- Documentation/admin-guide/kernel-parameters.txt | 11 +++ arch/x86/Kconfig | 25 +++++++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kernel/cpu/bugs.c | 90 ++++++++++++++++++++++++- 5 files changed, 165 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst index cce768afec6b..7cb99b09827c 100644 --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -138,11 +138,10 @@ associated with the source address of the indirect branch. Specifically, the BHB might be shared across privilege levels even in the presence of Enhanced IBRS. -Currently the only known real-world BHB attack vector is via -unprivileged eBPF. Therefore, it's highly recommended to not enable -unprivileged eBPF, especially when eIBRS is used (without retpolines). -For a full mitigation against BHB attacks, it's recommended to use -retpolines (or eIBRS combined with retpolines). +Previously the only known real-world BHB attack vector was via unprivileged +eBPF. Further research has found attacks that don't require unprivileged eBPF. +For a full mitigation against BHB attacks it is recommended to set BHI_DIS_S or +use the BHB clearing sequence. Attack scenarios ---------------- @@ -430,6 +429,21 @@ The possible values in this file are: 'PBRSB-eIBRS: Not affected' CPU is not affected by PBRSB =========================== ======================================================= + - Branch History Injection (BHI) protection status: + +.. list-table:: + + * - BHI: Not affected + - System is not affected + * - BHI: Retpoline + - System is protected by retpoline + * - BHI: BHI_DIS_S + - System is protected by BHI_DIS_S + * - BHI: SW loop + - System is protected by software clearing sequence + * - BHI: Syscall hardening + - Syscalls are hardened against BHI + Full mitigation might require a microcode update from the CPU vendor. When the necessary microcode is not available, the kernel will report vulnerability. @@ -484,7 +498,11 @@ Spectre variant 2 Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at boot, by setting the IBRS bit, and they're automatically protected against - Spectre v2 variant attacks. + some Spectre v2 variant attacks. The BHB can still influence the choice of + indirect branch predictor entry, and although branch predictor entries are + isolated between modes when eIBRS is enabled, the BHB itself is not isolated + between modes. Systems which support BHI_DIS_S will set it to protect against + BHI attacks. On Intel's enhanced IBRS systems, this includes cross-thread branch target injections on SMT systems (STIBP). In other words, Intel eIBRS enables @@ -638,6 +656,21 @@ kernel command line. spectre_v2=off. Spectre variant 1 mitigations cannot be disabled. + spectre_bhi= + + [X86] Control mitigation of Branch History Injection + (BHI) vulnerability. Syscalls are hardened against BHI + regardless of this setting. This setting affects the deployment + of the HW BHI control and the SW BHB clearing sequence. + + on + unconditionally enable. + off + unconditionally disable. + auto + enable if hardware mitigation + control(BHI_DIS_S) is available. + For spectre_v2_user see Documentation/admin-guide/kernel-parameters.txt Mitigation selection guide diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index bb884c14b2f6..2dbe60c1db22 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -6063,6 +6063,17 @@ sonypi.*= [HW] Sony Programmable I/O Control Device driver See Documentation/admin-guide/laptops/sonypi.rst + spectre_bhi= [X86] Control mitigation of Branch History Injection + (BHI) vulnerability. Syscalls are hardened against BHI + reglardless of this setting. This setting affects the + deployment of the HW BHI control and the SW BHB + clearing sequence. + + on - unconditionally enable. + off - unconditionally disable. + auto - (default) enable only if hardware mitigation + control(BHI_DIS_S) is available. + spectre_v2= [X86,EARLY] Control mitigation of Spectre variant 2 (indirect branch speculation) vulnerability. The default operation protects the kernel from diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 4fff6ed46e90..29a7b69a1316 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2633,6 +2633,31 @@ config MITIGATION_RFDS stored in floating point, vector and integer registers. See also +choice + prompt "Clear branch history" + depends on CPU_SUP_INTEL + default SPECTRE_BHI_AUTO + help + Enable BHI mitigations. BHI attacks are a form of Spectre V2 attacks + where the branch history buffer is poisoned to speculatively steer + indirect branches. + See + +config SPECTRE_BHI_ON + bool "on" + help + Equivalent to setting spectre_bhi=on command line parameter. +config SPECTRE_BHI_OFF + bool "off" + help + Equivalent to setting spectre_bhi=off command line parameter. +config SPECTRE_BHI_AUTO + bool "auto" + help + Equivalent to setting spectre_bhi=auto command line parameter. + +endchoice + endif config ARCH_HAS_ADD_PAGES diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index 8edd7a28869a..a2ee9a00e4a7 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -468,6 +468,7 @@ #define X86_FEATURE_AMD_LBR_PMC_FREEZE (21*32+ 0) /* AMD LBR and PMC Freeze */ #define X86_FEATURE_CLEAR_BHB_LOOP (21*32+ 1) /* "" Clear branch history at syscall entry using SW loop */ #define X86_FEATURE_BHI_CTRL (21*32+ 2) /* "" BHI_DIS_S HW control available */ +#define X86_FEATURE_CLEAR_BHB_HW (21*32+ 3) /* "" BHI_DIS_S HW control enabled */ /* * BUG word(s) diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index e8c7146f9ed7..1ab275029888 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1607,6 +1607,74 @@ static void __init spectre_v2_determine_rsb_fill_type_at_vmexit(enum spectre_v2_ dump_stack(); } +/* + * Set BHI_DIS_S to prevent indirect branches in kernel to be influenced by + * branch history in userspace. Not needed if BHI_NO is set. + */ +static bool __init spec_ctrl_bhi_dis(void) +{ + if (!boot_cpu_has(X86_FEATURE_BHI_CTRL)) + return false; + + x86_spec_ctrl_base |= SPEC_CTRL_BHI_DIS_S; + update_spec_ctrl(x86_spec_ctrl_base); + setup_force_cpu_cap(X86_FEATURE_CLEAR_BHB_HW); + + return true; +} + +enum bhi_mitigations { + BHI_MITIGATION_OFF, + BHI_MITIGATION_ON, + BHI_MITIGATION_AUTO, +}; + +static enum bhi_mitigations bhi_mitigation __ro_after_init = + IS_ENABLED(CONFIG_SPECTRE_BHI_ON) ? BHI_MITIGATION_ON : + IS_ENABLED(CONFIG_SPECTRE_BHI_OFF) ? BHI_MITIGATION_OFF : + BHI_MITIGATION_AUTO; + +static int __init spectre_bhi_parse_cmdline(char *str) +{ + if (!str) + return -EINVAL; + + if (!strcmp(str, "off")) + bhi_mitigation = BHI_MITIGATION_OFF; + else if (!strcmp(str, "on")) + bhi_mitigation = BHI_MITIGATION_ON; + else if (!strcmp(str, "auto")) + bhi_mitigation = BHI_MITIGATION_AUTO; + else + pr_err("Ignoring unknown spectre_bhi option (%s)", str); + + return 0; +} +early_param("spectre_bhi", spectre_bhi_parse_cmdline); + +static void __init bhi_select_mitigation(void) +{ + if (bhi_mitigation == BHI_MITIGATION_OFF) + return; + + /* Retpoline mitigates against BHI unless the CPU has RRSBA behavior */ + if (cpu_feature_enabled(X86_FEATURE_RETPOLINE) && + !(x86_read_arch_cap_msr() & ARCH_CAP_RRSBA)) + return; + + if (spec_ctrl_bhi_dis()) + return; + + if (!IS_ENABLED(CONFIG_X86_64)) + return; + + if (bhi_mitigation == BHI_MITIGATION_AUTO) + return; + + setup_force_cpu_cap(X86_FEATURE_CLEAR_BHB_LOOP); + pr_info("Spectre BHI mitigation: SW BHB clearing on syscall\n"); +} + static void __init spectre_v2_select_mitigation(void) { enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline(); @@ -1718,6 +1786,9 @@ static void __init spectre_v2_select_mitigation(void) mode == SPECTRE_V2_RETPOLINE) spec_ctrl_disable_kernel_rrsba(); + if (boot_cpu_has(X86_BUG_BHI)) + bhi_select_mitigation(); + spectre_v2_enabled = mode; pr_info("%s\n", spectre_v2_strings[mode]); @@ -2733,6 +2804,21 @@ static char *pbrsb_eibrs_state(void) } } +static const char * const spectre_bhi_state(void) +{ + if (!boot_cpu_has_bug(X86_BUG_BHI)) + return "; BHI: Not affected"; + else if (boot_cpu_has(X86_FEATURE_CLEAR_BHB_HW)) + return "; BHI: BHI_DIS_S"; + else if (boot_cpu_has(X86_FEATURE_CLEAR_BHB_LOOP)) + return "; BHI: SW loop"; + else if (boot_cpu_has(X86_FEATURE_RETPOLINE) && + !(x86_read_arch_cap_msr() & ARCH_CAP_RRSBA)) + return "; BHI: Retpoline"; + + return "; BHI: Vulnerable (Syscall hardening enabled)"; +} + static ssize_t spectre_v2_show_state(char *buf) { if (spectre_v2_enabled == SPECTRE_V2_LFENCE) @@ -2745,13 +2831,15 @@ static ssize_t spectre_v2_show_state(char *buf) spectre_v2_enabled == SPECTRE_V2_EIBRS_LFENCE) return sysfs_emit(buf, "Vulnerable: eIBRS+LFENCE with unprivileged eBPF and SMT\n"); - return sysfs_emit(buf, "%s%s%s%s%s%s%s\n", + return sysfs_emit(buf, "%s%s%s%s%s%s%s%s\n", spectre_v2_strings[spectre_v2_enabled], ibpb_state(), boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? "; IBRS_FW" : "", stibp_state(), boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? "; RSB filling" : "", pbrsb_eibrs_state(), + spectre_bhi_state(), + /* this should always be at the end */ spectre_v2_module_string()); } -- cgit v1.2.3 From 95a6ccbdc7199a14b71ad8901cb788ba7fb5167b Mon Sep 17 00:00:00 2001 From: Pawan Gupta Date: Mon, 11 Mar 2024 08:57:09 -0700 Subject: x86/bhi: Mitigate KVM by default BHI mitigation mode spectre_bhi=auto does not deploy the software mitigation by default. In a cloud environment, it is a likely scenario where userspace is trusted but the guests are not trusted. Deploying system wide mitigation in such cases is not desirable. Update the auto mode to unconditionally mitigate against malicious guests. Deploy the software sequence at VMexit in auto mode also, when hardware mitigation is not available. Unlike the force =on mode, software sequence is not deployed at syscalls in auto mode. Suggested-by: Alexandre Chartre Signed-off-by: Pawan Gupta Signed-off-by: Daniel Sneddon Signed-off-by: Thomas Gleixner Reviewed-by: Alexandre Chartre Reviewed-by: Josh Poimboeuf --- Documentation/admin-guide/hw-vuln/spectre.rst | 7 +++++-- Documentation/admin-guide/kernel-parameters.txt | 5 +++-- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/nospec-branch.h | 5 +++++ arch/x86/kernel/cpu/bugs.c | 9 ++++++++- arch/x86/kvm/vmx/vmenter.S | 2 +- 6 files changed, 23 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst index 7cb99b09827c..b70b1d8bd8e6 100644 --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -439,10 +439,12 @@ The possible values in this file are: - System is protected by retpoline * - BHI: BHI_DIS_S - System is protected by BHI_DIS_S - * - BHI: SW loop + * - BHI: SW loop; KVM SW loop - System is protected by software clearing sequence * - BHI: Syscall hardening - Syscalls are hardened against BHI + * - BHI: Syscall hardening; KVM: SW loop + - System is protected from userspace attacks by syscall hardening; KVM is protected by software clearing sequence Full mitigation might require a microcode update from the CPU vendor. When the necessary microcode is not available, the kernel will @@ -669,7 +671,8 @@ kernel command line. unconditionally disable. auto enable if hardware mitigation - control(BHI_DIS_S) is available. + control(BHI_DIS_S) is available, otherwise + enable alternate mitigation in KVM. For spectre_v2_user see Documentation/admin-guide/kernel-parameters.txt diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 2dbe60c1db22..4fa46302f436 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -6071,8 +6071,9 @@ on - unconditionally enable. off - unconditionally disable. - auto - (default) enable only if hardware mitigation - control(BHI_DIS_S) is available. + auto - (default) enable hardware mitigation + (BHI_DIS_S) if available, otherwise enable + alternate mitigation in KVM. spectre_v2= [X86,EARLY] Control mitigation of Spectre variant 2 (indirect branch speculation) vulnerability. diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index a2ee9a00e4a7..3c7434329661 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -469,6 +469,7 @@ #define X86_FEATURE_CLEAR_BHB_LOOP (21*32+ 1) /* "" Clear branch history at syscall entry using SW loop */ #define X86_FEATURE_BHI_CTRL (21*32+ 2) /* "" BHI_DIS_S HW control available */ #define X86_FEATURE_CLEAR_BHB_HW (21*32+ 3) /* "" BHI_DIS_S HW control enabled */ +#define X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT (21*32+ 4) /* "" Clear branch history at vmexit using SW loop */ /* * BUG word(s) diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h index aea40204278b..ff5f1ecc7d1e 100644 --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -330,8 +330,13 @@ .macro CLEAR_BRANCH_HISTORY ALTERNATIVE "", "call clear_bhb_loop", X86_FEATURE_CLEAR_BHB_LOOP .endm + +.macro CLEAR_BRANCH_HISTORY_VMEXIT + ALTERNATIVE "", "call clear_bhb_loop", X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT +.endm #else #define CLEAR_BRANCH_HISTORY +#define CLEAR_BRANCH_HISTORY_VMEXIT #endif #else /* __ASSEMBLY__ */ diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 1ab275029888..295463707e68 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1668,9 +1668,14 @@ static void __init bhi_select_mitigation(void) if (!IS_ENABLED(CONFIG_X86_64)) return; + /* Mitigate KVM by default */ + setup_force_cpu_cap(X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT); + pr_info("Spectre BHI mitigation: SW BHB clearing on vm exit\n"); + if (bhi_mitigation == BHI_MITIGATION_AUTO) return; + /* Mitigate syscalls when the mitigation is forced =on */ setup_force_cpu_cap(X86_FEATURE_CLEAR_BHB_LOOP); pr_info("Spectre BHI mitigation: SW BHB clearing on syscall\n"); } @@ -2811,10 +2816,12 @@ static const char * const spectre_bhi_state(void) else if (boot_cpu_has(X86_FEATURE_CLEAR_BHB_HW)) return "; BHI: BHI_DIS_S"; else if (boot_cpu_has(X86_FEATURE_CLEAR_BHB_LOOP)) - return "; BHI: SW loop"; + return "; BHI: SW loop, KVM: SW loop"; else if (boot_cpu_has(X86_FEATURE_RETPOLINE) && !(x86_read_arch_cap_msr() & ARCH_CAP_RRSBA)) return "; BHI: Retpoline"; + else if (boot_cpu_has(X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT)) + return "; BHI: Syscall hardening, KVM: SW loop"; return "; BHI: Vulnerable (Syscall hardening enabled)"; } diff --git a/arch/x86/kvm/vmx/vmenter.S b/arch/x86/kvm/vmx/vmenter.S index 0f3593e10c57..f6986dee6f8c 100644 --- a/arch/x86/kvm/vmx/vmenter.S +++ b/arch/x86/kvm/vmx/vmenter.S @@ -275,7 +275,7 @@ SYM_INNER_LABEL_ALIGN(vmx_vmexit, SYM_L_GLOBAL) call vmx_spec_ctrl_restore_host - CLEAR_BRANCH_HISTORY + CLEAR_BRANCH_HISTORY_VMEXIT /* Put return value in AX */ mov %_ASM_BX, %_ASM_AX -- cgit v1.2.3 From d325a858a53b5816a60447887f7148eace999e00 Mon Sep 17 00:00:00 2001 From: Richard Genoud Date: Mon, 8 Apr 2024 12:13:29 +0200 Subject: MAINTAINERS: mailmap: update Richard Genoud's email address I'm working now at bootlin, so I'll use my bootlin address for kernel development from now on. Update also the yaml file for atmel-serial accordingly. Signed-off-by: Richard Genoud Reviewed-by: Nicolas Ferre Link: https://lore.kernel.org/r/20240408101329.9448-1-richard.genoud@bootlin.com Signed-off-by: Greg Kroah-Hartman --- .mailmap | 1 + Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml | 2 +- MAINTAINERS | 2 +- 3 files changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/.mailmap b/.mailmap index 8284692f9610..71e28f4e0d4a 100644 --- a/.mailmap +++ b/.mailmap @@ -524,6 +524,7 @@ Rémi Denis-Courmont Ricardo Ribalda Ricardo Ribalda Ricardo Ribalda Delgado Ricardo Ribalda +Richard Genoud Richard Leitner Richard Leitner Richard Leitner diff --git a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml index 65cb2e5c5eee..eb2992a447d7 100644 --- a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml +++ b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Atmel Universal Synchronous Asynchronous Receiver/Transmitter (USART) maintainers: - - Richard Genoud + - Richard Genoud properties: compatible: diff --git a/MAINTAINERS b/MAINTAINERS index aea47e04c3a5..0dbdc81e46c6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14363,7 +14363,7 @@ F: drivers/dma/at_xdmac.c F: include/dt-bindings/dma/at91.h MICROCHIP AT91 SERIAL DRIVER -M: Richard Genoud +M: Richard Genoud S: Maintained F: Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml F: drivers/tty/serial/atmel_serial.c -- cgit v1.2.3 From 22a1dd652de329394ca81dd2fe046444920c96dc Mon Sep 17 00:00:00 2001 From: Bastien Curutchet Date: Tue, 2 Apr 2024 09:12:01 +0200 Subject: ASoC: dt-bindings: davinci-mcbsp: convert McBSP bindings to yaml schema Convert the binding for McBSP controllers for TI SoCs from txt to YAML schema. Add properties 'clocks', 'clock-names', 'power-domains' and '#sound-dai-cells' which were missing from the txt file. Add '#sound-dai-cells' and 'clocks' in the example which were missing from the txt file. Signed-off-by: Bastien Curutchet Reviewed-by: Rob Herring Acked-by: Peter Ujfalusi Link: https://msgid.link/r/20240402071213.11671-2-bastien.curutchet@bootlin.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/davinci-mcbsp.txt | 50 ------------ .../devicetree/bindings/sound/davinci-mcbsp.yaml | 95 ++++++++++++++++++++++ 2 files changed, 95 insertions(+), 50 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/davinci-mcbsp.txt create mode 100644 Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt b/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt deleted file mode 100644 index 3ffc2562fb31..000000000000 --- a/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt +++ /dev/null @@ -1,50 +0,0 @@ -Texas Instruments DaVinci McBSP module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -This binding describes the "Multi-channel Buffered Serial Port" (McBSP) -audio interface found in some TI DaVinci processors like the OMAP-L138 or AM180x. - - -Required properties: -~~~~~~~~~~~~~~~~~~~~ -- compatible : - "ti,da850-mcbsp" : for DA850, AM180x and OPAM-L138 platforms - -- reg : physical base address and length of the controller memory mapped - region(s). -- reg-names : Should contain: - * "mpu" for the main registers (required). - * "dat" for the data FIFO (optional). - -- dmas: three element list of DMA controller phandles, DMA request line and - TC channel ordered triplets. -- 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: -~~~~~~~~~~~~~~~~~~~~ -- interrupts : Interrupt numbers for McBSP -- interrupt-names : Known interrupt names are "rx" and "tx" - -- 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 - -Example (AM1808): -~~~~~~~~~~~~~~~~~ - -mcbsp0: mcbsp@1d10000 { - compatible = "ti,da850-mcbsp"; - pinctrl-names = "default"; - pinctrl-0 = <&mcbsp0_pins>; - - reg = <0x00110000 0x1000>, - <0x00310000 0x1000>; - reg-names = "mpu", "dat"; - interrupts = <97 98>; - interrupt-names = "rx", "tx"; - dmas = <&edma0 3 1 - &edma0 2 1>; - dma-names = "tx", "rx"; -}; diff --git a/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml b/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml new file mode 100644 index 000000000000..139b594dd192 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/davinci-mcbsp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: McBSP Controller for TI SoCs + +maintainers: + - Bastien Curutchet + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - ti,da850-mcbsp + + reg: + minItems: 1 + items: + - description: CFG registers + - description: data registers + + reg-names: + minItems: 1 + items: + - const: mpu + - const: dat + + dmas: + items: + - description: transmission DMA channel + - description: reception DMA channel + + dma-names: + items: + - const: tx + - const: rx + + interrupts: + items: + - description: RX interrupt + - description: TX interrupt + + interrupt-names: + items: + - const: rx + - const: tx + + clocks: + items: + - description: functional clock + + clock-names: + items: + - const: fck + + power-domains: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - "#sound-dai-cells" + - compatible + - reg + - reg-names + - dmas + - dma-names + - clocks + +unevaluatedProperties: false + +examples: + - | + mcbsp0@1d10000 { + #sound-dai-cells = <0>; + compatible = "ti,da850-mcbsp"; + pinctrl-names = "default"; + pinctrl-0 = <&mcbsp0_pins>; + + reg = <0x111000 0x1000>, + <0x311000 0x1000>; + reg-names = "mpu", "dat"; + interrupts = <97>, <98>; + interrupt-names = "rx", "tx"; + dmas = <&edma0 3 1>, + <&edma0 2 1>; + dma-names = "tx", "rx"; + + clocks = <&psc1 14>; + }; -- cgit v1.2.3 From 6a4b6b062a5917d611c1bde7189c5147cf0ca832 Mon Sep 17 00:00:00 2001 From: Bastien Curutchet Date: Tue, 2 Apr 2024 09:12:02 +0200 Subject: ASoC: dt-bindings: davinci-mcbsp: Add optional clock The McBSP uses an internal sample rate generator to provide bit clock or frame clock. This sample rate generator can be programmed to be driven by McBSP's internal clock source or by an external clock source (located on CLKS pin). The external clock source is not described in the bindings. Add an optional clock item that allows to select an external clock as sample rate generator's input. Signed-off-by: Bastien Curutchet Reviewed-by: Rob Herring Acked-by: Peter Ujfalusi Link: https://msgid.link/r/20240402071213.11671-3-bastien.curutchet@bootlin.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml b/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml index 139b594dd192..0c2b1936c6a1 100644 --- a/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml +++ b/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml @@ -50,12 +50,16 @@ properties: - const: tx clocks: + minItems: 1 items: - description: functional clock + - description: external input clock for sample rate generator. clock-names: + minItems: 1 items: - const: fck + - const: clks power-domains: maxItems: 1 -- cgit v1.2.3 From 609302ca04a3177463b0fbf4d5fc55a3ab4f900d Mon Sep 17 00:00:00 2001 From: Bastien Curutchet Date: Tue, 2 Apr 2024 09:12:12 +0200 Subject: ASoC: dt-bindings: davinci-mcbsp: Add the 'ti,T1-framing-{rx/tx}' flags McBSP's data delay can be configured from 0 to 2 bit clock periods. 0 is used for DSP_B format, 1 for DSP_A format. A data delay of 2 bit clock periods can be used to interface to 'T1 framing' devices where data stream is preceded by a 'framing bit'. This 2 bit clock data delay is not described in the bindings. Add two flags 'ti,T1-framing-[rx/tx]' to enable a data delay of 2 bit clock periods in reception or transmission. Signed-off-by: Bastien Curutchet Reviewed-by: Rob Herring Acked-by: Peter Ujfalusi Link: https://msgid.link/r/20240402071213.11671-13-bastien.curutchet@bootlin.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml b/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml index 0c2b1936c6a1..4fa677023827 100644 --- a/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml +++ b/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml @@ -67,6 +67,20 @@ properties: "#sound-dai-cells": const: 0 + ti,T1-framing-tx: + $ref: /schemas/types.yaml#/definitions/flag + description: + If the property is present, tx data delay is set to 2 bit clock periods. + McBSP will insert a blank period (high-impedance period) before the first + data bit. This can be used to interface to T1-framing devices. + + ti,T1-framing-rx: + $ref: /schemas/types.yaml#/definitions/flag + description: + If the property is present, rx data delay is set to 2 bit clock periods. + McBSP will discard the bit preceding the data stream (called framing bit). + This can be used to interface to T1-framing devices. + required: - "#sound-dai-cells" - compatible -- cgit v1.2.3 From dfe648903f42296866d79f10d03f8c85c9dfba30 Mon Sep 17 00:00:00 2001 From: Josh Poimboeuf Date: Wed, 10 Apr 2024 22:40:45 -0700 Subject: x86/bugs: Fix BHI documentation Fix up some inaccuracies in the BHI documentation. Fixes: ec9404e40e8f ("x86/bhi: Add BHI mitigation knob") Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Reviewed-by: Nikolay Borisov Cc: Linus Torvalds Cc: Sean Christopherson Link: https://lore.kernel.org/r/8c84f7451bfe0dd08543c6082a383f390d4aa7e2.1712813475.git.jpoimboe@kernel.org --- Documentation/admin-guide/hw-vuln/spectre.rst | 15 ++++++++------- Documentation/admin-guide/kernel-parameters.txt | 12 +++++++----- 2 files changed, 15 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst index b70b1d8bd8e6..3cf18e4a1d9a 100644 --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -439,11 +439,11 @@ The possible values in this file are: - System is protected by retpoline * - BHI: BHI_DIS_S - System is protected by BHI_DIS_S - * - BHI: SW loop; KVM SW loop + * - BHI: SW loop, KVM SW loop - System is protected by software clearing sequence * - BHI: Syscall hardening - Syscalls are hardened against BHI - * - BHI: Syscall hardening; KVM: SW loop + * - BHI: Syscall hardening, KVM: SW loop - System is protected from userspace attacks by syscall hardening; KVM is protected by software clearing sequence Full mitigation might require a microcode update from the CPU @@ -666,13 +666,14 @@ kernel command line. of the HW BHI control and the SW BHB clearing sequence. on - unconditionally enable. + (default) Enable the HW or SW mitigation as + needed. off - unconditionally disable. + Disable the mitigation. auto - enable if hardware mitigation - control(BHI_DIS_S) is available, otherwise - enable alternate mitigation in KVM. + Enable the HW mitigation if needed, but + *don't* enable the SW mitigation except for KVM. + The system may be vulnerable. For spectre_v2_user see Documentation/admin-guide/kernel-parameters.txt diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 70046a019d42..a029ad6c4963 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3444,6 +3444,7 @@ retbleed=off [X86] spec_rstack_overflow=off [X86] spec_store_bypass_disable=off [X86,PPC] + spectre_bhi=off [X86] spectre_v2_user=off [X86] srbds=off [X86,INTEL] ssbd=force-off [ARM64] @@ -6069,11 +6070,12 @@ deployment of the HW BHI control and the SW BHB clearing sequence. - on - unconditionally enable. - off - unconditionally disable. - auto - (default) enable hardware mitigation - (BHI_DIS_S) if available, otherwise enable - alternate mitigation in KVM. + on - (default) Enable the HW or SW mitigation + as needed. + off - Disable the mitigation. + auto - Enable the HW mitigation if needed, but + *don't* enable the SW mitigation except + for KVM. The system may be vulnerable. spectre_v2= [X86,EARLY] Control mitigation of Spectre variant 2 (indirect branch speculation) vulnerability. -- cgit v1.2.3 From 5f882f3b0a8bf0788d5a0ee44b1191de5319bb8a Mon Sep 17 00:00:00 2001 From: Josh Poimboeuf Date: Wed, 10 Apr 2024 22:40:48 -0700 Subject: x86/bugs: Clarify that syscall hardening isn't a BHI mitigation While syscall hardening helps prevent some BHI attacks, there's still other low-hanging fruit remaining. Don't classify it as a mitigation and make it clear that the system may still be vulnerable if it doesn't have a HW or SW mitigation enabled. Fixes: ec9404e40e8f ("x86/bhi: Add BHI mitigation knob") Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Cc: Sean Christopherson Link: https://lore.kernel.org/r/b5951dae3fdee7f1520d5136a27be3bdfe95f88b.1712813475.git.jpoimboe@kernel.org --- Documentation/admin-guide/hw-vuln/spectre.rst | 11 +++++------ Documentation/admin-guide/kernel-parameters.txt | 3 +-- arch/x86/kernel/cpu/bugs.c | 6 +++--- 3 files changed, 9 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst index 3cf18e4a1d9a..5a39acf82483 100644 --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -441,10 +441,10 @@ The possible values in this file are: - System is protected by BHI_DIS_S * - BHI: SW loop, KVM SW loop - System is protected by software clearing sequence - * - BHI: Syscall hardening - - Syscalls are hardened against BHI - * - BHI: Syscall hardening, KVM: SW loop - - System is protected from userspace attacks by syscall hardening; KVM is protected by software clearing sequence + * - BHI: Vulnerable + - System is vulnerable to BHI + * - BHI: Vulnerable, KVM: SW loop + - System is vulnerable; KVM is protected by software clearing sequence Full mitigation might require a microcode update from the CPU vendor. When the necessary microcode is not available, the kernel will @@ -661,8 +661,7 @@ kernel command line. spectre_bhi= [X86] Control mitigation of Branch History Injection - (BHI) vulnerability. Syscalls are hardened against BHI - regardless of this setting. This setting affects the deployment + (BHI) vulnerability. This setting affects the deployment of the HW BHI control and the SW BHB clearing sequence. on diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a029ad6c4963..a3874cc97892 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -6065,8 +6065,7 @@ See Documentation/admin-guide/laptops/sonypi.rst spectre_bhi= [X86] Control mitigation of Branch History Injection - (BHI) vulnerability. Syscalls are hardened against BHI - reglardless of this setting. This setting affects the + (BHI) vulnerability. This setting affects the deployment of the HW BHI control and the SW BHB clearing sequence. diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 08dfb94fcb3a..9eeb60f5fbb3 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -2818,10 +2818,10 @@ static const char *spectre_bhi_state(void) return "; BHI: SW loop, KVM: SW loop"; else if (boot_cpu_has(X86_FEATURE_RETPOLINE) && rrsba_disabled) return "; BHI: Retpoline"; - else if (boot_cpu_has(X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT)) - return "; BHI: Syscall hardening, KVM: SW loop"; + else if (boot_cpu_has(X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT)) + return "; BHI: Vulnerable, KVM: SW loop"; - return "; BHI: Vulnerable (Syscall hardening enabled)"; + return "; BHI: Vulnerable"; } static ssize_t spectre_v2_show_state(char *buf) -- cgit v1.2.3 From 156539fd65019e8ed6b9fbac0583cf519cdbb227 Mon Sep 17 00:00:00 2001 From: Michael Ellerman Date: Fri, 22 Mar 2024 21:38:40 +1100 Subject: Documentation: embargoed-hardware-issues.rst: Add myself for Power Unfortunately Anton has left IBM. Add myself as the contact for Power, until someone else volunteers. Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20240322103840.668746-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman --- 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 bb2100228cc7..6e9a4597bf2c 100644 --- a/Documentation/process/embargoed-hardware-issues.rst +++ b/Documentation/process/embargoed-hardware-issues.rst @@ -252,7 +252,7 @@ an involved disclosed party. The current ambassadors list: AMD Tom Lendacky Ampere Darren Hart ARM Catalin Marinas - IBM Power Anton Blanchard + IBM Power Michael Ellerman IBM Z Christian Borntraeger Intel Tony Luck Qualcomm Trilok Soni -- cgit v1.2.3 From 62bef5df35a87d0f8464b1a8837540988cfaf5db Mon Sep 17 00:00:00 2001 From: Shengjiu Wang Date: Thu, 11 Apr 2024 18:11:44 +0800 Subject: ASoC: dt-bindings: imx-audio-spdif: convert to YAML Convert the imx-audio-spdif binding to YAML. When testing dtbs_check, found below compatible strings are not listed in document: fsl,imx-sabreauto-spdif fsl,imx6sx-sdb-spdif So add them in yaml file to pass the test. Signed-off-by: Shengjiu Wang Reviewed-by: Krzysztof Kozlowski Link: https://msgid.link/r/1712830305-31350-2-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown --- .../bindings/sound/fsl,imx-audio-spdif.yaml | 66 ++++++++++++++++++++++ .../devicetree/bindings/sound/imx-audio-spdif.txt | 36 ------------ 2 files changed, 66 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml delete mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml new file mode 100644 index 000000000000..5fc543d02ecb --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,imx-audio-spdif.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX audio complex with S/PDIF transceiver + +maintainers: + - Shengjiu Wang + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,imx-sabreauto-spdif + - fsl,imx6sx-sdb-spdif + - const: fsl,imx-audio-spdif + - enum: + - fsl,imx-audio-spdif + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + + spdif-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of the i.MX S/PDIF controller + + spdif-out: + type: boolean + description: + If present, the transmitting function of S/PDIF will be enabled, + indicating there's a physical S/PDIF out connector or jack on the + board or it's connecting to some other IP block, such as an HDMI + encoder or display-controller. + + spdif-in: + type: boolean + description: + If present, the receiving function of S/PDIF will be enabled, + indicating there is a physical S/PDIF in connector/jack on the board. + +required: + - compatible + - model + - spdif-controller + +anyOf: + - required: + - spdif-in + - required: + - spdif-out + +additionalProperties: false + +examples: + - | + sound-spdif { + compatible = "fsl,imx-audio-spdif"; + model = "imx-spdif"; + spdif-controller = <&spdif>; + spdif-out; + spdif-in; + }; diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt deleted file mode 100644 index da84a442ccea..000000000000 --- a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt +++ /dev/null @@ -1,36 +0,0 @@ -Freescale i.MX audio complex with S/PDIF transceiver - -Required properties: - - - compatible : "fsl,imx-audio-spdif" - - - model : The user-visible name of this sound complex - - - spdif-controller : The phandle of the i.MX S/PDIF controller - - -Optional properties: - - - spdif-out : This is a boolean property. If present, the - transmitting function of S/PDIF will be enabled, - indicating there's a physical S/PDIF out connector - or jack on the board or it's connecting to some - other IP block, such as an HDMI encoder or - display-controller. - - - spdif-in : This is a boolean property. If present, the receiving - function of S/PDIF will be enabled, indicating there - is a physical S/PDIF in connector/jack on the board. - -* Note: At least one of these two properties should be set in the DT binding. - - -Example: - -sound-spdif { - compatible = "fsl,imx-audio-spdif"; - model = "imx-spdif"; - spdif-controller = <&spdif>; - spdif-out; - spdif-in; -}; -- cgit v1.2.3 From 36d4fe147c870f6d3f6602befd7ef44393a1c87a Mon Sep 17 00:00:00 2001 From: Josh Poimboeuf Date: Wed, 10 Apr 2024 22:40:50 -0700 Subject: x86/bugs: Remove CONFIG_BHI_MITIGATION_AUTO and spectre_bhi=auto Unlike most other mitigations' "auto" options, spectre_bhi=auto only mitigates newer systems, which is confusing and not particularly useful. Remove it. Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Reviewed-by: Nikolay Borisov Cc: Sean Christopherson Cc: Linus Torvalds Link: https://lore.kernel.org/r/412e9dc87971b622bbbaf64740ebc1f140bff343.1712813475.git.jpoimboe@kernel.org --- Documentation/admin-guide/hw-vuln/spectre.rst | 4 ---- Documentation/admin-guide/kernel-parameters.txt | 3 --- arch/x86/Kconfig | 5 ----- arch/x86/kernel/cpu/bugs.c | 10 +--------- 4 files changed, 1 insertion(+), 21 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst index 5a39acf82483..25a04cda4c2c 100644 --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -669,10 +669,6 @@ kernel command line. needed. off Disable the mitigation. - auto - Enable the HW mitigation if needed, but - *don't* enable the SW mitigation except for KVM. - The system may be vulnerable. For spectre_v2_user see Documentation/admin-guide/kernel-parameters.txt diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a3874cc97892..902ecd92a29f 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -6072,9 +6072,6 @@ on - (default) Enable the HW or SW mitigation as needed. off - Disable the mitigation. - auto - Enable the HW mitigation if needed, but - *don't* enable the SW mitigation except - for KVM. The system may be vulnerable. spectre_v2= [X86,EARLY] Control mitigation of Spectre variant 2 (indirect branch speculation) vulnerability. diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 10a6251f58f3..b63b6767a63d 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2651,11 +2651,6 @@ config SPECTRE_BHI_OFF bool "off" help Equivalent to setting spectre_bhi=off command line parameter. -config SPECTRE_BHI_AUTO - bool "auto" - depends on BROKEN - help - Equivalent to setting spectre_bhi=auto command line parameter. endchoice diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 9eeb60f5fbb3..6af4780a18ed 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1625,13 +1625,10 @@ static bool __init spec_ctrl_bhi_dis(void) enum bhi_mitigations { BHI_MITIGATION_OFF, BHI_MITIGATION_ON, - BHI_MITIGATION_AUTO, }; static enum bhi_mitigations bhi_mitigation __ro_after_init = - IS_ENABLED(CONFIG_SPECTRE_BHI_ON) ? BHI_MITIGATION_ON : - IS_ENABLED(CONFIG_SPECTRE_BHI_OFF) ? BHI_MITIGATION_OFF : - BHI_MITIGATION_AUTO; + IS_ENABLED(CONFIG_SPECTRE_BHI_ON) ? BHI_MITIGATION_ON : BHI_MITIGATION_OFF; static int __init spectre_bhi_parse_cmdline(char *str) { @@ -1642,8 +1639,6 @@ static int __init spectre_bhi_parse_cmdline(char *str) bhi_mitigation = BHI_MITIGATION_OFF; else if (!strcmp(str, "on")) bhi_mitigation = BHI_MITIGATION_ON; - else if (!strcmp(str, "auto")) - bhi_mitigation = BHI_MITIGATION_AUTO; else pr_err("Ignoring unknown spectre_bhi option (%s)", str); @@ -1673,9 +1668,6 @@ static void __init bhi_select_mitigation(void) setup_force_cpu_cap(X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT); pr_info("Spectre BHI mitigation: SW BHB clearing on vm exit\n"); - if (bhi_mitigation == BHI_MITIGATION_AUTO) - return; - /* Mitigate syscalls when the mitigation is forced =on */ setup_force_cpu_cap(X86_FEATURE_CLEAR_BHB_LOOP); pr_info("Spectre BHI mitigation: SW BHB clearing on syscall\n"); -- cgit v1.2.3 From 4be7bc275253c0f35c8f6362af1ee5d91d5d83e9 Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Fri, 12 Apr 2024 09:14:10 -0300 Subject: ASoC: dt-bindings: fsl-asoc-card: Document fsl,imx25-pdk-sgtl5000 Document fsl,imx25-pdk-sgtl5000 to fix the following dt-schema warning: imx25-pdk.dtb: sound: compatible: 'oneOf' conditional failed, one must be fixed: ['fsl,imx25-pdk-sgtl5000', 'fsl,imx-audio-sgtl5000'] is too long Fixes: 4189b54220e5 ("ASoC: dt-bindings: fsl-asoc-card: convert to YAML") Signed-off-by: Fabio Estevam Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240412121410.2948048-1-festevam@gmail.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml b/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml index 42ca39eebd49..bbf6fa1a2012 100644 --- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml +++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml @@ -33,6 +33,7 @@ properties: - items: - enum: - fsl,imx-sgtl5000 + - fsl,imx25-pdk-sgtl5000 - fsl,imx53-cpuvo-sgtl5000 - fsl,imx51-babbage-sgtl5000 - fsl,imx53-m53evk-sgtl5000 -- cgit v1.2.3 From d6e792ed7dd022a16a637ade224da070b60f4f3b Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Fri, 12 Apr 2024 05:46:03 +0000 Subject: ASoC: dt-bindings: renesas: add R8A779H0 V4M Add document for R-Car V4M (R8A779H0). Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/871q7bcew5.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/renesas,rsnd.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index 0d7a6b576d88..8ce78ca838ba 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -49,6 +49,7 @@ properties: # for Gen4 SoC - items: - const: renesas,rcar_sound-r8a779g0 # R-Car V4H + - const: renesas,rcar_sound-r8a779h0 # R-Car V4M - const: renesas,rcar_sound-gen4 # for Generic - enum: -- cgit v1.2.3 From f284b23809bf54f8189f82f822f099e43d6a0a35 Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Fri, 12 Apr 2024 05:45:43 +0000 Subject: ASoC: dt-bindings: renesas,rsnd: add missing renesas,rcar_sound-gen4 It is missing generic compatible for R-Car Gen4 Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/8734rrcewo.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/renesas,rsnd.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index 8ce78ca838ba..b3da278cf141 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -56,6 +56,7 @@ properties: - renesas,rcar_sound-gen1 - renesas,rcar_sound-gen2 - renesas,rcar_sound-gen3 + - renesas,rcar_sound-gen4 reg: minItems: 1 -- cgit v1.2.3 From fb7c3d8ba039df877886fd457538d8b24ca9c84b Mon Sep 17 00:00:00 2001 From: AngeloGioacchino Del Regno Date: Thu, 4 Apr 2024 10:18:08 +0200 Subject: dt-bindings: pwm: mediatek,pwm-disp: Document power-domains property MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Allow the power-domains property to the PWM_DISP block as on some SoCs this does need at most one power domain. Fixes: b09b179bac0a ("dt-bindings: pwm: Convert pwm-mtk-disp.txt to mediatek,pwm-disp.yaml format") Signed-off-by: AngeloGioacchino Del Regno Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240404081808.92199-1-angelogioacchino.delregno@collabora.com Signed-off-by: Uwe Kleine-König --- 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 afcdeed4e88a..bc813fe74fab 100644 --- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml @@ -52,6 +52,9 @@ properties: - const: main - const: mm + power-domains: + maxItems: 1 + required: - compatible - reg -- cgit v1.2.3 From abbb99301e9d2c91567e1893dbe34f2f8b52ea9a Mon Sep 17 00:00:00 2001 From: Thorsten Leemhuis Date: Tue, 9 Apr 2024 09:30:44 +0200 Subject: docs: verify/bisect: use git switch, tag kernel, and various fixes Various small improvements and fixes: * Use the more modern 'git switch' instead of 'git checkout', which makes it more obvious what's happening (among others due to the --discard-changes parameter that is more clear than --force). * Provide a hint how a mainline version number and one from a stable series look like. * When trying to validate the bisection result with a revert, add a special tag to facilitate the identification. * Sync version numbers used in various examples for consistency: stick to 6.0.13, 6.0.15, and 6.1.5. * Fix a few typos and oddities. Signed-off-by: Thorsten Leemhuis Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/85029aa004447b0eeb5043fb014630f2acafacec.1712647788.git.linux@leemhuis.info --- .../verify-bugs-and-bisect-regressions.rst | 117 ++++++++++++--------- 1 file changed, 67 insertions(+), 50 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst index d3504826f401..c999e40c79ab 100644 --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst @@ -38,8 +38,8 @@ aspects, all of which might be essential in your present case.]* **In case you want to check if a bug is present in code currently supported by developers**, execute just the *preparations* and *segment 1*; while doing so, consider the newest Linux kernel you regularly use to be the 'working' kernel. -In the following example that's assumed to be 6.0.13, which is why the sources -of 6.0 will be used to prepare the .config file. +In the following example that's assumed to be 6.0, which is why its sources +will be used to prepare the .config file. **In case you face a regression**, follow the steps at least till the end of *segment 2*. Then you can submit a preliminary report -- or continue with @@ -61,7 +61,7 @@ will be considered the 'good' release and used to prepare the .config file. cd ~/linux/ git remote add -t master stable \ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git - git checkout --detach v6.0 + git switch --detach v6.0 # * Hint: if you used an existing clone, ensure no stale .config is around. make olddefconfig # * Ensure the former command picked the .config of the 'working' kernel. @@ -87,7 +87,7 @@ will be considered the 'good' release and used to prepare the .config file. a) Checking out latest mainline code:: cd ~/linux/ - git checkout --force --detach mainline/master + git switch --discard-changes --detach mainline/master b) Build, install, and boot a kernel:: @@ -125,7 +125,7 @@ will be considered the 'good' release and used to prepare the .config file. a) Start by checking out the sources of the 'good' version:: cd ~/linux/ - git checkout --force --detach v6.0 + git switch --discard-changes --detach v6.0 b) Build, install, and boot a kernel as described earlier in *segment 1, section b* -- just feel free to skip the 'du' commands, as you have a rough @@ -157,11 +157,12 @@ will be considered the 'good' release and used to prepare the .config file. works with the newly built kernel. If it does, tell Git by executing ``git bisect good``; if it does not, run ``git bisect bad`` instead. - All three commands will make Git checkout another commit; then re-execute + All three commands will make Git check out another commit; then re-execute this step (e.g. build, install, boot, and test a kernel to then tell Git the outcome). Do so again and again until Git shows which commit broke things. If you run short of disk space during this process, check the - "Supplementary tasks" section below. + section 'Supplementary tasks: cleanup during and after the process' + below. d) Once your finished the bisection, put a few things away:: @@ -172,12 +173,15 @@ will be considered the 'good' release and used to prepare the .config file. e) Try to verify the bisection result:: - git checkout --force --detach mainline/master + git switch --discard-changes --detach mainline/master git revert --no-edit cafec0cacaca0 + cp ~/kernel-config-working .config + ./scripts/config --set-str CONFIG_LOCALVERSION '-local-cafec0cacaca0-reverted' This is optional, as some commits are impossible to revert. But if the second command worked flawlessly, build, install, and boot one more kernel - kernel, which should not show the regression. + kernel; just this time skip the first command copying the base .config file + over, as that already has been taken care off. * **Supplementary tasks**: cleanup during and after the process. @@ -208,7 +212,7 @@ Step-by-step guide on how to verify bugs and bisect regressions =============================================================== This guide describes how to set up your own Linux kernels for investigating bugs -or regressions you intent to report. How far you want to follow the instructions +or regressions you intend to report. How far you want to follow the instructions depends on your issue: Execute all steps till the end of *segment 1* to **verify if your kernel problem @@ -240,12 +244,17 @@ to get things rolling again. For further details on how to report Linux kernel issues or regressions check out Documentation/admin-guide/reporting-issues.rst, which works in conjunction with this document. It among others explains why you need to verify bugs with -the latest 'mainline' kernel, even if you face a problem with a kernel from a -'stable/longterm' series; for users facing a regression it also explains that -sending a preliminary report after finishing segment 2 might be wise, as the -regression and its culprit might be known already. For further details on -what actually qualifies as a regression check out -Documentation/admin-guide/reporting-regressions.rst. +the latest 'mainline' kernel (e.g. versions like 6.0, 6.1-rc1, or 6.1-rc6), +even if you face a problem with a kernel from a 'stable/longterm' series +(say 6.0.13). + +For users facing a regression that document also explains why sending a +preliminary report after segment 2 might be wise, as the regression and its +culprit might be known already. For further details on what actually qualifies +as a regression check out Documentation/admin-guide/reporting-regressions.rst. + +If you run into any problems while following this guide or have ideas how to +improve it, :ref:`please let the kernel developers know `. .. _introprep_bissbs: @@ -286,7 +295,7 @@ Preparations: set up everything to build your own kernels Do you follow this guide to verify if a bug is present in the code developers care for? Then consider the mainline release your 'working' kernel (the newest one you regularly use) is based on to be the 'good' version; if your 'working' - kernel for example is 6.0.11, then your 'good' kernel is 6.0. + kernel for example is 6.0.13, then your 'good' kernel is 6.0. In case you face a regression, it depends on the version range where the regression was introduced: @@ -295,14 +304,14 @@ Preparations: set up everything to build your own kernels 6.1-rc1? Then henceforth regard 6.0 as the last known 'good' version and 6.1-rc1 as the first 'bad' one. - * Some function stopped working when updating from 6.0.11 to 6.1.4? Then for - the time being consider 6.0 as the last 'good' version and 6.1.4 as + * Some function stopped working when updating from 6.0.13 to 6.1.5? Then for + the time being consider 6.0 as the last 'good' version and 6.1.5 as the 'bad' one. Note, at this point it is merely assumed that 6.0 is fine; this assumption will be checked in segment 2. - * A feature you used in 6.0.11 does not work at all or worse in 6.1.13? In + * A feature you used in 6.0.13 does not work at all or worse in 6.1.15? In that case you want to bisect within a stable/longterm series: consider - 6.0.11 as the last known 'good' version and 6.0.13 as the first 'bad' + 6.0.13 as the last known 'good' version and 6.0.15 as the first 'bad' one. Note, in this case you still want to compile and test a mainline kernel as explained in segment 1: the outcome will determine if you need to report your issue to the regular developers or the stable team. @@ -367,7 +376,7 @@ Preparations: set up everything to build your own kernels * Start preparing a kernel build configuration (the '.config' file). Before doing so, ensure you are still running the 'working' kernel an earlier - step told you to boot; if you are unsure, check the current kernel release + step told you to boot; if you are unsure, check the current kernelrelease identifier using ``uname -r``. Afterwards check out the source code for the version earlier established as @@ -375,7 +384,7 @@ Preparations: set up everything to build your own kernels the version number in this and all later Git commands needs to be prefixed with a 'v':: - git checkout --detach v6.0 + git switch --discard-changes --detach v6.0 Now create a build configuration file:: @@ -505,7 +514,7 @@ be a waste of time. [:ref:`details`] * Check out the latest Linux codebase:: cd ~/linux/ - git checkout --force --detach mainline/master + git switch --discard-changes --detach mainline/master [:ref:`details`] @@ -617,7 +626,7 @@ be a waste of time. [:ref:`details`] cd ~/linux/ git remote set-branches --add stable linux-6.0.y git fetch stable - git checkout --force --detach linux-6.0.y + git switch --discard-changes --detach linux-6.0.y Now use the checked out code to build and install another kernel using the commands the earlier steps already described in more detail:: @@ -669,7 +678,7 @@ otherwise would be a waste of time. [:ref:`details`] 'good' (once again assumed to be 6.0 here):: cd ~/linux/ - git checkout --detach v6.0 + git switch --discard-changes --detach v6.0 Now use the checked out code to configure, build, and install another kernel using the commands the previous subsection explained in more detail:: @@ -703,7 +712,7 @@ Segment 3: perform the bisection and validate the result With all the preparations and precaution builds taken care of, you are now ready to begin the bisection. This will make you build quite a few kernels -- usually about 15 in case you encountered a regression when updating to a newer series -(say from 6.0.11 to 6.1.3). But do not worry, due to the trimmed build +(say from 6.0.13 to 6.1.5). But do not worry, due to the trimmed build configuration created earlier this works a lot faster than many people assume: overall on average it will often just take about 10 to 15 minutes to compile each kernel on commodity x86 machines. @@ -745,7 +754,7 @@ each kernel on commodity x86 machines. If compilation fails for some reason, run ``git bisect skip`` and restart executing the stack of commands from the beginning. - In case you skipped the "test latest codebase" step in the guide, check its + In case you skipped the 'test latest codebase' step in the guide, check its description as for why the 'df [...]' and 'make -s kernelrelease [...]' commands are here. @@ -823,16 +832,16 @@ each kernel on commodity x86 machines. Begin by checking out the latest codebase depending on the range you bisected: * Did you face a regression within a stable/longterm series (say between - 6.0.11 and 6.0.13) that does not happen in mainline? Then check out the + 6.0.13 and 6.0.15) that does not happen in mainline? Then check out the latest codebase for the affected series like this:: git fetch stable - git checkout --force --detach linux-6.0.y + git switch --discard-changes --detach linux-6.0.y * In all other cases check out latest mainline:: git fetch mainline - git checkout --force --detach mainline/master + git switch --discard-changes --detach mainline/master If you bisected a regression within a stable/longterm series that also happens in mainline, there is one more thing to do: look up the mainline @@ -846,21 +855,27 @@ each kernel on commodity x86 machines. git revert --no-edit cafec0cacaca0 - If that fails, give up trying and move on to the next step. But if it works, - build a kernel again using the familiar command sequence:: + If that fails, give up trying and move on to the next step; if it works, + adjust the tag to facilitate the identification and prevent accidentally + overwriting another kernel:: cp ~/kernel-config-working .config + ./scripts/config --set-str CONFIG_LOCALVERSION '-local-cafec0cacaca0-reverted' + + Build a kernel using the familiar command sequence, just without copying the + the base .config over:: + make olddefconfig && - make -j $(nproc --all) && + make -j $(nproc --all) # * Check if the free space suffices holding another kernel: df -h /boot/ /lib/modules/ sudo make modules_install command -v installkernel && sudo make install - Make -s kernelrelease | tee -a ~/kernels-built + make -s kernelrelease | tee -a ~/kernels-built reboot - Now check one last time if the feature that made you perform a bisection work - with that kernel. + Now check one last time if the feature that made you perform a bisection works + with that kernel: if everything went well, it should not show the regression. [:ref:`details`] @@ -934,10 +949,12 @@ This concludes the step-by-step guide. Did you run into trouble following any of the above steps not cleared up by the reference section below? Did you spot errors? Or do you have ideas how to -improve the guide? Then please take a moment and let the maintainer of this +improve the guide? + +If any of that applies, please take a moment and let the maintainer of this document know by email (Thorsten Leemhuis ), ideally while CCing the Linux docs mailing list (linux-doc@vger.kernel.org). Such feedback is -vital to improve this document further, which is in everybody's interest, as it +vital to improve this text further, which is in everybody's interest, as it will enable more people to master the task described here -- and hopefully also improve similar guides inspired by this one. @@ -1059,18 +1076,18 @@ Bisection range Establishing the range of commits to be checked is mostly straightforward, except when a regression occurred when switching from a release of one stable -series to a release of a later series (e.g. from 6.0.11 to 6.1.4). In that case +series to a release of a later series (e.g. from 6.0.13 to 6.1.5). In that case Git will need some hand holding, as there is no straight line of descent. That's because with the release of 6.0 mainline carried on to 6.1 while the stable series 6.0.y branched to the side. It's therefore theoretically possible -that the issue you face with 6.1.4 only worked in 6.0.11, as it was fixed by a +that the issue you face with 6.1.5 only worked in 6.0.13, as it was fixed by a commit that went into one of the 6.0.y releases, but never hit mainline or the 6.1.y series. Thankfully that normally should not happen due to the way the stable/longterm maintainers maintain the code. It's thus pretty safe to assume 6.0 as a 'good' kernel. That assumption will be tested anyway, as that kernel will be built and tested in the segment '2' of this guide; Git would force you -to do this as well, if you tried bisecting between 6.0.11 and 6.1.13. +to do this as well, if you tried bisecting between 6.0.13 and 6.1.15. [:ref:`back to step-by-step guide `] @@ -1117,7 +1134,7 @@ These commands install a few packages that are often, but not always needed. You for example might want to skip installing the development headers for ncurses, which you will only need in case you later might want to adjust the kernel build configuration using make the targets 'menuconfig' or 'nconfig'; likewise omit -the headers of Qt6 is you do not plan to adjust the .config using 'xconfig'. +the headers of Qt6 if you do not plan to adjust the .config using 'xconfig'. You furthermore might need additional libraries and their development headers for tasks not covered in this guide -- for example when building utilities from @@ -1184,7 +1201,7 @@ First, execute the following command to retrieve the latest mainline codebase:: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Now deepen your clone's history to the second predecessor of the mainline -release of your 'good' version. In case the latter are 6.0 or 6.0.11, 5.19 would +release of your 'good' version. In case the latter are 6.0 or 6.0.13, 5.19 would be the first predecessor and 5.18 the second -- hence deepen the history up to that version:: @@ -1490,7 +1507,7 @@ highly recommended for these reasons: Your report might be ignored if you send it to the wrong party -- and even when you get a reply there is a decent chance that developers tell you to - evaluate which of the two cases it is before they take a closer look. + evaluate which of the two cases it is before they take a closer look. [:ref:`back to step-by-step guide `] @@ -1552,8 +1569,8 @@ by modifying your search terms or using another line from the error messages. In the end, most issues you run into have likely been encountered and reported by others already. That includes issues where the cause is not your -system, but lies in the code. If you run into one of those, you might thus find a -solution (e.g. a patch) or workaround for your issue, too. +system, but lies in the code. If you run into one of those, you might thus find +a solution (e.g. a patch) or workaround for your issue, too. Package your kernel up ~~~~~~~~~~~~~~~~~~~~~~ @@ -1767,8 +1784,8 @@ multitude of reasons why this might happen. Some ideas where to look: Note, if you found and fixed problems with the .config file, you want to use it to build another kernel from the latest codebase, as your earlier tests with -mainline and the latest version from an affected stable/longterm series were most -likely flawed. +mainline and the latest version from an affected stable/longterm series were +most likely flawed. [:ref:`back to step-by-step guide `] @@ -1911,7 +1928,7 @@ Now remove the boot entry for the kernel from your bootloader's configuration; the steps to do that vary quite a bit between Linux distributions. Note, be careful with wildcards like '*' when deleting files or directories -for kernels manually: you might accidentally remove files of a 6.0.11 kernel +for kernels manually: you might accidentally remove files of a 6.0.13 kernel when all you want is to remove 6.0 or 6.0.1. [:ref:`back to step-by-step guide `] -- cgit v1.2.3 From 932c9a5398a7b41cb8e7a0264e5470133b373e11 Mon Sep 17 00:00:00 2001 From: Thorsten Leemhuis Date: Tue, 9 Apr 2024 09:30:45 +0200 Subject: docs: verify/bisect: add and fetch stable branches ahead of time Add and fetch all required stable branches ahead of time. This fixes a bug, as readers that wanted to bisect a regression within a stable or longterm series otherwise did not have them available at the right time. This way also matches the flow somewhat better and avoids some "if you haven't already added it" phrases that otherwise become necessary in future changes. Signed-off-by: Thorsten Leemhuis Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/57dcf312959476abe6151bf3d35eb79e3e9a83d1.1712647788.git.linux@leemhuis.info --- .../verify-bugs-and-bisect-regressions.rst | 31 +++++++++++++--------- 1 file changed, 18 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst index c999e40c79ab..06278501a4bd 100644 --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst @@ -136,8 +136,7 @@ will be considered the 'good' release and used to prepare the .config file. * **Segment 3**: perform and validate the bisection. - a) In case your 'broken' version is a stable/longterm release, add the Git - branch holding it:: + a) Retrieve the sources for your 'bad' version:: git remote set-branches --add stable linux-6.1.y git fetch stable @@ -371,6 +370,21 @@ Preparations: set up everything to build your own kernels [:ref:`details`] +.. _stablesources_bissbs: + +* Retrieve the sources for any stable or longterm series you might need. + + Is the version you earlier established as 'bad' a stable or longterm release? + Then download the code for the series it belongs to ('linux-6.1.y' in this + example):: + + git remote set-branches --add stable linux-6.1.y + git fetch stable + + If the version earlier established as 'good' is from a different stable or + longterm series (say 6.0.13), repeat the previous step, but this time for the + branch holding the series the 'good' version belongs to (e.g. linux-6.0.y). + .. _oldconfig_bissbs: * Start preparing a kernel build configuration (the '.config' file). @@ -620,12 +634,10 @@ be a waste of time. [:ref:`details`] reproduce it with the mainline kernel you just built? One that according to the `front page of kernel.org `_ is still supported? Then check if the latest codebase for the particular series might already fix the - problem. To do so, add the stable series Git branch for your 'good' kernel - (again, this here is assumed to be 6.0) and check out the latest version:: + problem. To do so, check out that series latest version (again, this here is + assumed to be 6.0):: cd ~/linux/ - git remote set-branches --add stable linux-6.0.y - git fetch stable git switch --discard-changes --detach linux-6.0.y Now use the checked out code to build and install another kernel using the @@ -717,13 +729,6 @@ configuration created earlier this works a lot faster than many people assume: overall on average it will often just take about 10 to 15 minutes to compile each kernel on commodity x86 machines. -* In case your 'bad' version is a stable/longterm release (say 6.1.5), add its - stable branch, unless you already did so earlier:: - - cd ~/linux/ - git remote set-branches --add stable linux-6.1.y - git fetch stable - .. _bisectstart_bissbs: * Start the bisection and tell Git about the versions earlier established as -- cgit v1.2.3 From 453de3207ff3534dd7165a32a73dd28cc9e8f14f Mon Sep 17 00:00:00 2001 From: Thorsten Leemhuis Date: Tue, 9 Apr 2024 09:30:46 +0200 Subject: docs: verify/bisect: proper headlines and more spacing Various small improvements and fixes: * Separate ref links from their target with a space for better readability. * Add a proper heading for the note at the end of the step-by-step guide. * Use proper 3rd and 4th level headlines in the reference section and add short intros for the 2nd level headlines that lacked one. Signed-off-by: Thorsten Leemhuis Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/f59f0f235a2192ed93899a7338153e4cb71075f0.1712647788.git.linux@leemhuis.info --- .../verify-bugs-and-bisect-regressions.rst | 194 ++++++++++++--------- 1 file changed, 113 insertions(+), 81 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst index 06278501a4bd..355c2cea5230 100644 --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst @@ -29,7 +29,7 @@ The essence of the process (aka 'TL;DR') ======================================== *[If you are new to building or bisecting Linux, ignore this section and head -over to the* ":ref:`step-by-step guide`" *below. It utilizes +over to the* ':ref:`step-by-step guide `' *below. It utilizes the same commands as this section while describing them in brief fashion. The steps are nevertheless easy to follow and together with accompanying entries in a reference section mention many alternatives, pitfalls, and additional @@ -224,15 +224,15 @@ report; instead of the latter your could also head straight on and follow *segment 3* to **perform a bisection** for a full-fledged regression report developers are obliged to act upon. - :ref:`Preparations: set up everything to build your own kernels.` + :ref:`Preparations: set up everything to build your own kernels `. - :ref:`Segment 1: try to reproduce the problem with the latest codebase.` + :ref:`Segment 1: try to reproduce the problem with the latest codebase `. - :ref:`Segment 2: check if the kernels you build work fine.` + :ref:`Segment 2: check if the kernels you build work fine `. - :ref:`Segment 3: perform a bisection and validate the result.` + :ref:`Segment 3: perform a bisection and validate the result `. - :ref:`Supplementary tasks: cleanup during and after following this guide.` + :ref:`Supplementary tasks: cleanup during and after following this guide `. The steps in each segment illustrate the important aspects of the process, while a comprehensive reference section holds additional details for almost all of the @@ -260,12 +260,14 @@ improve it, :ref:`please let the kernel developers know `. Preparations: set up everything to build your own kernels --------------------------------------------------------- +The following steps lay the groundwork for all further tasks. + .. _backup_bissbs: * Create a fresh backup and put system repair and restore tools at hand, just to be prepared for the unlikely case of something going sideways. - [:ref:`details`] + [:ref:`details `] .. _vanilla_bissbs: @@ -273,7 +275,7 @@ Preparations: set up everything to build your own kernels builds them automatically. That includes but is not limited to DKMS, openZFS, VirtualBox, and Nvidia's graphics drivers (including the GPLed kernel module). - [:ref:`details`] + [:ref:`details `] .. _secureboot_bissbs: @@ -284,7 +286,7 @@ Preparations: set up everything to build your own kernels their restrictions through a process initiated by ``mokutil --disable-validation``. - [:ref:`details`] + [:ref:`details `] .. _rangecheck_bissbs: @@ -319,13 +321,13 @@ Preparations: set up everything to build your own kernels throughout this guide will refer to the last kernel that has been working fine.* - [:ref:`details`] + [:ref:`details `] .. _bootworking_bissbs: * Boot into the 'working' kernel and briefly use the apparently broken feature. - [:ref:`details`] + [:ref:`details `] .. _diskspace_bissbs: @@ -335,7 +337,7 @@ Preparations: set up everything to build your own kernels debug symbols: both explain approaches reducing the amount of space, which should allow you to master these tasks with about 4 Gigabytes free space. - [:ref:`details`] + [:ref:`details `] .. _buildrequires_bissbs: @@ -345,7 +347,7 @@ Preparations: set up everything to build your own kernels reference section shows how to quickly install those on various popular Linux distributions. - [:ref:`details`] + [:ref:`details `] .. _sources_bissbs: @@ -368,7 +370,7 @@ Preparations: set up everything to build your own kernels git remote add -t master stable \ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git - [:ref:`details`] + [:ref:`details `] .. _stablesources_bissbs: @@ -421,7 +423,7 @@ Preparations: set up everything to build your own kernels 'make olddefconfig' again and check if it now picked up the right config file as base. - [:ref:`details`] + [:ref:`details `] .. _localmodconfig_bissbs: @@ -455,7 +457,7 @@ Preparations: set up everything to build your own kernels spending much effort on, as long as it boots and allows to properly test the feature that causes trouble. - [:ref:`details`] + [:ref:`details `] .. _tagging_bissbs: @@ -465,7 +467,7 @@ Preparations: set up everything to build your own kernels ./scripts/config --set-str CONFIG_LOCALVERSION '-local' ./scripts/config -e CONFIG_LOCALVERSION_AUTO - [:ref:`details`] + [:ref:`details `] .. _debugsymbols_bissbs: @@ -484,7 +486,7 @@ Preparations: set up everything to build your own kernels ./scripts/config -d DEBUG_INFO -d DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT \ -d DEBUG_INFO_DWARF4 -d DEBUG_INFO_DWARF5 -e CONFIG_DEBUG_INFO_NONE - [:ref:`details`] + [:ref:`details `] .. _configmods_bissbs: @@ -494,14 +496,14 @@ Preparations: set up everything to build your own kernels * Are you running Debian? Then you want to avoid known problems by performing additional adjustments explained in the reference section. - [:ref:`details`]. + [:ref:`details `]. * If you want to influence other aspects of the configuration, do so now using your preferred tool. Note, to use make targets like 'menuconfig' or 'nconfig', you will need to install the development files of ncurses; for 'xconfig' you likewise need the Qt5 or Qt6 headers. - [:ref:`details`]. + [:ref:`details `]. .. _saveconfig_bissbs: @@ -511,7 +513,7 @@ Preparations: set up everything to build your own kernels make olddefconfig cp .config ~/kernel-config-working - [:ref:`details`] + [:ref:`details `] .. _introlatestcheck_bissbs: @@ -521,7 +523,7 @@ Segment 1: try to reproduce the problem with the latest codebase The following steps verify if the problem occurs with the code currently supported by developers. In case you face a regression, it also checks that the problem is not caused by some .config change, as reporting the issue then would -be a waste of time. [:ref:`details`] +be a waste of time. [:ref:`details `] .. _checkoutmaster_bissbs: @@ -530,7 +532,7 @@ be a waste of time. [:ref:`details`] cd ~/linux/ git switch --discard-changes --detach mainline/master - [:ref:`details`] + [:ref:`details `] .. _build_bissbs: @@ -545,7 +547,7 @@ be a waste of time. [:ref:`details`] reference section for alternatives, which obviously will require other steps to install as well. - [:ref:`details`] + [:ref:`details `] .. _install_bissbs: @@ -578,7 +580,7 @@ be a waste of time. [:ref:`details`] down: if you will build more kernels as described in segment 2 and 3, you will have to perform those again after executing ``command -v installkernel [...]``. - [:ref:`details`] + [:ref:`details `] .. _storagespace_bissbs: @@ -591,7 +593,7 @@ be a waste of time. [:ref:`details`] Write down or remember those two values for later: they enable you to prevent running out of disk space accidentally during a bisection. - [:ref:`details`] + [:ref:`details `] .. _kernelrelease_bissbs: @@ -618,7 +620,7 @@ be a waste of time. [:ref:`details`] If that command does not return '0', check the reference section, as the cause for this might interfere with your testing. - [:ref:`details`] + [:ref:`details `] .. _recheckbroken_bissbs: @@ -626,7 +628,7 @@ be a waste of time. [:ref:`details`] out the instructions in the reference section to ensure nothing went sideways during your tests. - [:ref:`details`] + [:ref:`details `] .. _recheckstablebroken_bissbs: @@ -662,12 +664,12 @@ be a waste of time. [:ref:`details`] Now verify if this kernel is showing the problem. - [:ref:`details`] + [:ref:`details `] Do you follow this guide to verify if a problem is present in the code currently supported by Linux kernel developers? Then you are done at this point. If you later want to remove the kernel you just built, check out -:ref:`Supplementary tasks: cleanup during and after following this guide`. +:ref:`Supplementary tasks: cleanup during and after following this guide `. In case you face a regression, move on and execute at least the next segment as well. @@ -679,7 +681,7 @@ Segment 2: check if the kernels you build work fine In case of a regression, you now want to ensure the trimmed configuration file you created earlier works as expected; a bisection with the .config file -otherwise would be a waste of time. [:ref:`details`] +otherwise would be a waste of time. [:ref:`details `] .. _recheckworking_bissbs: @@ -714,7 +716,7 @@ otherwise would be a waste of time. [:ref:`details`] Now check if this kernel works as expected; if not, consult the reference section for further instructions. - [:ref:`details`] + [:ref:`details `] .. _introbisect_bissbs: @@ -739,7 +741,7 @@ each kernel on commodity x86 machines. git bisect good v6.0 git bisect bad v6.1.5 - [:ref:`details`] + [:ref:`details `] .. _bisectbuild_bissbs: @@ -768,7 +770,7 @@ each kernel on commodity x86 machines. totally normal to see release identifiers like '6.0-rc1-local-gcafec0cacaca0' if you bisect between versions 6.1 and 6.2 for example. - [:ref:`details`] + [:ref:`details `] .. _bisecttest_bissbs: @@ -808,7 +810,7 @@ each kernel on commodity x86 machines. might need to scroll up to see the message mentioning the culprit; alternatively, run ``git bisect log > ~/bisection-log``. - [:ref:`details`] + [:ref:`details `] .. _bisectlog_bissbs: @@ -820,7 +822,7 @@ each kernel on commodity x86 machines. cp .config ~/bisection-config-culprit git bisect reset - [:ref:`details`] + [:ref:`details `] .. _revert_bissbs: @@ -882,7 +884,7 @@ each kernel on commodity x86 machines. Now check one last time if the feature that made you perform a bisection works with that kernel: if everything went well, it should not show the regression. - [:ref:`details`] + [:ref:`details `] .. _introclosure_bissbs: @@ -923,7 +925,7 @@ space might run out. kernel image and related files behind; in that case remove them as described in the reference section. - [:ref:`details`] + [:ref:`details `] .. _finishingtouch_bissbs: @@ -946,11 +948,15 @@ space might run out. the version considered 'good', and the last three or four you compiled during the actual bisection process. - [:ref:`details`] + [:ref:`details `] + .. _submit_improvements: -This concludes the step-by-step guide. +Conclusion +---------- + +You have reached the end of the step-by-step guide. Did you run into trouble following any of the above steps not cleared up by the reference section below? Did you spot errors? Or do you have ideas how to @@ -970,10 +976,20 @@ Reference section for the step-by-step guide This section holds additional information for almost all the items in the above step-by-step guide. +Preparations for building your own kernels +------------------------------------------ + + *The steps in this section lay the groundwork for all further tests.* + [:ref:`... `] + +The steps in all later sections of this guide depend on those described here. + +[:ref:`back to step-by-step guide `]. + .. _backup_bisref: Prepare for emergencies ------------------------ +~~~~~~~~~~~~~~~~~~~~~~~ *Create a fresh backup and put system repair and restore tools at hand.* [:ref:`... `] @@ -988,7 +1004,7 @@ for something going sideways, even if that should not happen. .. _vanilla_bisref: Remove anything related to externally maintained kernel modules ---------------------------------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Remove all software that depends on externally developed kernel drivers or builds them automatically.* [:ref:`...`] @@ -1006,7 +1022,7 @@ explains in more detail. .. _secureboot_bisref: Deal with techniques like Secure Boot -------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *On platforms with 'Secure Boot' or similar techniques, prepare everything to ensure the system will permit your self-compiled kernel to boot later.* @@ -1043,7 +1059,7 @@ Afterwards, permit MokManager to reboot the machine. .. _bootworking_bisref: Boot the last kernel that was working -------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Boot into the last working kernel and briefly recheck if the feature that regressed really works.* [:ref:`...`] @@ -1056,7 +1072,7 @@ the right thing. .. _diskspace_bisref: Space requirements ------------------- +~~~~~~~~~~~~~~~~~~ *Ensure to have enough free space for building Linux.* [:ref:`... `] @@ -1074,7 +1090,7 @@ space by quite a few gigabytes. .. _rangecheck_bisref: Bisection range ---------------- +~~~~~~~~~~~~~~~ *Determine the kernel versions considered 'good' and 'bad' throughout this guide.* [:ref:`...`] @@ -1099,7 +1115,7 @@ to do this as well, if you tried bisecting between 6.0.13 and 6.1.15. .. _buildrequires_bisref: Install build requirements --------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~ *Install all software required to build a Linux kernel.* [:ref:`...`] @@ -1150,7 +1166,7 @@ the kernel's tools/ directory. .. _sources_bisref: Download the sources using Git ------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Retrieve the Linux mainline sources.* [:ref:`...`] @@ -1170,7 +1186,7 @@ work better for you: .. _sources_bundle_bisref: Downloading Linux mainline sources using a bundle -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +""""""""""""""""""""""""""""""""""""""""""""""""" Use the following commands to retrieve the Linux mainline sources using a bundle:: @@ -1241,7 +1257,7 @@ Note, shallow clones have a few peculiar characteristics: .. _oldconfig_bisref: Start defining the build configuration for your kernel ------------------------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Start preparing a kernel build configuration (the '.config' file).* [:ref:`... `] @@ -1301,7 +1317,7 @@ that file to the build machine and store it as ~/linux/.config; afterwards run .. _localmodconfig_bisref: Trim the build configuration for your kernel --------------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Disable any kernel modules apparently superfluous for your setup.* [:ref:`... `] @@ -1350,7 +1366,7 @@ step-by-step guide mentions:: .. _tagging_bisref: Tag the kernels about to be build ---------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Ensure all the kernels you will build are clearly identifiable using a special tag and a unique version identifier.* [:ref:`... `] @@ -1366,7 +1382,7 @@ confusing during the bisection. .. _debugsymbols_bisref: Decide to enable or disable debug symbols ------------------------------------------ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Decide how to handle debug symbols.* [:ref:`... `] @@ -1395,7 +1411,7 @@ explains this process in more detail. .. _configmods_bisref: Adjust build configuration --------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~ *Check if you may want or need to adjust some other kernel configuration options:* @@ -1406,7 +1422,7 @@ kernel configuration options. .. _configmods_distros_bisref: Distro specific adjustments -~~~~~~~~~~~~~~~~~~~~~~~~~~~ +""""""""""""""""""""""""""" *Are you running* [:ref:`... `] @@ -1431,7 +1447,7 @@ when following this guide on a few commodity distributions. .. _configmods_individual_bisref: Individual adjustments -~~~~~~~~~~~~~~~~~~~~~~ +"""""""""""""""""""""" *If you want to influence the other aspects of the configuration, do so now.* [:ref:`... `] @@ -1448,13 +1464,13 @@ is missing. .. _saveconfig_bisref: Put the .config file aside --------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~ *Reprocess the .config after the latest changes and store it in a safe place.* [:ref:`... `] Put the .config you prepared aside, as you want to copy it back to the build -directory every time during this guide before you start building another +directory every time during this guide before you start building another kernel. That's because going back and forth between different versions can alter .config files in odd ways; those occasionally cause side effects that could confuse testing or in some cases render the result of your bisection @@ -1464,8 +1480,8 @@ meaningless. .. _introlatestcheck_bisref: -Try to reproduce the regression ------------------------------------------ +Try to reproduce the problem with the latest codebase +----------------------------------------------------- *Verify the regression is not caused by some .config change and check if it still occurs with the latest codebase.* [:ref:`... `] @@ -1519,21 +1535,21 @@ highly recommended for these reasons: .. _checkoutmaster_bisref: Check out the latest Linux codebase ------------------------------------ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Check out the latest Linux codebase.* - [:ref:`... `] + [:ref:`... `] In case you later want to recheck if an ever newer codebase might fix the problem, remember to run that ``git fetch --shallow-exclude [...]`` command again mentioned earlier to update your local Git repository. -[:ref:`back to step-by-step guide `] +[:ref:`back to step-by-step guide `] .. _build_bisref: Build your kernel ------------------ +~~~~~~~~~~~~~~~~~ *Build the image and the modules of your first kernel using the config file you prepared.* [:ref:`... `] @@ -1543,7 +1559,7 @@ yourself. Another subsection explains how to directly package your kernel up as deb, rpm or tar file. Dealing with build errors -~~~~~~~~~~~~~~~~~~~~~~~~~ +""""""""""""""""""""""""" When a build error occurs, it might be caused by some aspect of your machine's setup that often can be fixed quickly; other times though the problem lies in @@ -1578,7 +1594,7 @@ system, but lies in the code. If you run into one of those, you might thus find a solution (e.g. a patch) or workaround for your issue, too. Package your kernel up -~~~~~~~~~~~~~~~~~~~~~~ +"""""""""""""""""""""" The step-by-step guide uses the default make targets (e.g. 'bzImage' and 'modules' on x86) to build the image and the modules of your kernel, which later @@ -1609,7 +1625,7 @@ distribution's kernel packages. .. _install_bisref: Put the kernel in place ------------------------ +~~~~~~~~~~~~~~~~~~~~~~~ *Install the kernel you just built.* [:ref:`... `] @@ -1652,7 +1668,7 @@ process. Afterwards add your kernel to your bootloader configuration and reboot. .. _storagespace_bisref: Storage requirements per kernel -------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Check how much storage space the kernel, its modules, and other related files like the initramfs consume.* [:ref:`... `] @@ -1673,7 +1689,7 @@ need to look in different places. .. _tainted_bisref: Check if your newly built kernel considers itself 'tainted' ------------------------------------------------------------ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Check if the kernel marked itself as 'tainted'.* [:ref:`... `] @@ -1692,7 +1708,7 @@ interest, as your testing might be flawed otherwise. .. _recheckbroken_bisref: Check the kernel built from a recent mainline codebase ------------------------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Verify if your bug occurs with the newly built kernel.* [:ref:`... `] @@ -1718,7 +1734,7 @@ the kernel you built from the latest codebase. These are the most frequent: .. _recheckstablebroken_bisref: Check the kernel built from the latest stable/longterm codebase ---------------------------------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Are you facing a regression within a stable/longterm release, but failed to reproduce it with the kernel you just built using the latest mainline sources? @@ -1763,7 +1779,7 @@ ensure the kernel version you assumed to be 'good' earlier in the process (e.g. .. _recheckworking_bisref: Build your own version of the 'good' kernel -------------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Build your own variant of the working kernel and check if the feature that regressed works as expected with it.* [:ref:`... `] @@ -1794,10 +1810,20 @@ most likely flawed. [:ref:`back to step-by-step guide `] +Perform a bisection and validate the result +------------------------------------------- + + *With all the preparations and precaution builds taken care of, you are now + ready to begin the bisection.* [:ref:`... `] + +The steps in this segment perform and validate the bisection. + +[:ref:`back to step-by-step guide `]. + .. _bisectstart_bisref: Start the bisection -------------------- +~~~~~~~~~~~~~~~~~~~ *Start the bisection and tell Git about the versions earlier established as 'good' and 'bad'.* [:ref:`... `] @@ -1811,7 +1837,7 @@ for you to test. .. _bisectbuild_bisref: Build a kernel from the bisection point ---------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Build, install, and boot a kernel from the code Git checked out using the same commands you used earlier.* [:ref:`... `] @@ -1839,7 +1865,7 @@ There are two things worth of note here: .. _bisecttest_bisref: Bisection checkpoint --------------------- +~~~~~~~~~~~~~~~~~~~~ *Check if the feature that regressed works in the kernel you just built.* [:ref:`... `] @@ -1853,7 +1879,7 @@ will be for nothing. .. _bisectlog_bisref: Put the bisection log away --------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~ *Store Git's bisection log and the current .config file in a safe place.* [:ref:`... `] @@ -1873,7 +1899,7 @@ ask for it after you report the regression. .. _revert_bisref: Try reverting the culprit -------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~ *Try reverting the culprit on top of the latest codebase to see if this fixes your regression.* [:ref:`... `] @@ -1891,14 +1917,20 @@ succeeds, test that kernel version instead. [:ref:`back to step-by-step guide `] +Cleanup steps during and after following this guide +--------------------------------------------------- -Supplementary tasks: cleanup during and after the bisection ------------------------------------------------------------ + *During and after following this guide you might want or need to remove some + of the kernels you installed.* [:ref:`... `] + +The steps in this section describe clean-up procedures. + +[:ref:`back to step-by-step guide `]. .. _makeroom_bisref: Cleaning up during the bisection --------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *To remove one of the kernels you installed, look up its 'kernelrelease' identifier.* [:ref:`... `] @@ -1939,7 +1971,7 @@ when all you want is to remove 6.0 or 6.0.1. [:ref:`back to step-by-step guide `] Cleaning up after the bisection -------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. _finishingtouch_bisref: -- cgit v1.2.3 From a421835a2a327f2b3472dcb755adb57d0f82e478 Mon Sep 17 00:00:00 2001 From: Thorsten Leemhuis Date: Tue, 9 Apr 2024 09:30:47 +0200 Subject: docs: verify/bisect: explain testing reverts, patches and newer code Rename 'Supplementary tasks' to 'Complementary tasks' while introducing a section 'Optional tasks: test reverts, patches, or later versions': the latter is something readers occasionally will have to do after reporting a bug and thus is best covered here. Signed-off-by: Thorsten Leemhuis Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/dacf26a4c48e9e8f04ecbc77e0a74c9b2a6a1103.1712647788.git.linux@leemhuis.info --- .../verify-bugs-and-bisect-regressions.rst | 128 ++++++++++++++++++--- 1 file changed, 115 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst index 355c2cea5230..1987c827211f 100644 --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst @@ -160,7 +160,7 @@ will be considered the 'good' release and used to prepare the .config file. this step (e.g. build, install, boot, and test a kernel to then tell Git the outcome). Do so again and again until Git shows which commit broke things. If you run short of disk space during this process, check the - section 'Supplementary tasks: cleanup during and after the process' + section 'Complementary tasks: cleanup during and after the process' below. d) Once your finished the bisection, put a few things away:: @@ -182,7 +182,7 @@ will be considered the 'good' release and used to prepare the .config file. kernel; just this time skip the first command copying the base .config file over, as that already has been taken care off. -* **Supplementary tasks**: cleanup during and after the process. +* **Complementary tasks**: cleanup during and after the process. a) To avoid running out of disk space during a bisection, you might need to remove some kernels you built earlier. You most likely want to keep those @@ -205,6 +205,18 @@ will be considered the 'good' release and used to prepare the .config file. the kernels you built earlier and later you might want to keep around for a week or two. +* **Optional task**: test a debug patch or a proposed fix later:: + + git fetch mainline + git switch --discard-changes --detach mainline/master + git apply /tmp/foobars-proposed-fix-v1.patch + cp ~/kernel-config-working .config + ./scripts/config --set-str CONFIG_LOCALVERSION '-local-foobars-fix-v1' + + Build, install, and boot a kernel as described in *segment 1, section b* -- + but this time omit the first command copying the build configuration over, + as that has been taken care of already. + .. _introguide_bissbs: Step-by-step guide on how to verify bugs and bisect regressions @@ -232,7 +244,9 @@ developers are obliged to act upon. :ref:`Segment 3: perform a bisection and validate the result `. - :ref:`Supplementary tasks: cleanup during and after following this guide `. + :ref:`Complementary tasks: cleanup during and after following this guide `. + + :ref:`Optional tasks: test reverts, patches, or later versions `. The steps in each segment illustrate the important aspects of the process, while a comprehensive reference section holds additional details for almost all of the @@ -669,7 +683,7 @@ be a waste of time. [:ref:`details `] Do you follow this guide to verify if a problem is present in the code currently supported by Linux kernel developers? Then you are done at this point. If you later want to remove the kernel you just built, check out -:ref:`Supplementary tasks: cleanup during and after following this guide `. +:ref:`Complementary tasks: cleanup during and after following this guide `. In case you face a regression, move on and execute at least the next segment as well. @@ -888,7 +902,7 @@ each kernel on commodity x86 machines. .. _introclosure_bissbs: -Supplementary tasks: cleanup during and after the bisection +Complementary tasks: cleanup during and after the bisection ----------------------------------------------------------- During and after following this guide you might want or need to remove some of @@ -950,6 +964,81 @@ space might run out. [:ref:`details `] +.. _introoptional_bissbs: + +Optional: test reverts, patches, or later versions +-------------------------------------------------- + +While or after reporting a bug, you might want or potentially will be asked to +test reverts, debug patches, proposed fixes, or other versions. In that case +follow these instructions. + +* Update your Git clone and check out the latest code. + + * In case you want to test mainline, fetch its latest changes before checking + its code out:: + + git fetch mainline + git switch --discard-changes --detach mainline/master + + * In case you want to test a stable or longterm kernel, first add the branch + holding the series you are interested in (6.2 in the example), unless you + already did so earlier:: + + git remote set-branches --add stable linux-6.2.y + + Then fetch the latest changes and check out the latest version from the + series:: + + git fetch stable + git switch --discard-changes --detach stable/linux-6.2.y + +* Copy your kernel build configuration over:: + + cp ~/kernel-config-working .config + +* Your next step depends on what you want to do: + + * In case you just want to test the latest codebase, head to the next step, + you are already all set. + + * In case you want to test if a revert fixes an issue, revert one or multiple + changes by specifying their commit ids:: + + git revert --no-edit cafec0cacaca0 + + Now give that kernel a special tag to facilitates its identification and + prevent accidentally overwriting another kernel:: + + ./scripts/config --set-str CONFIG_LOCALVERSION '-local-cafec0cacaca0-reverted' + + * In case you want to test a patch, store the patch in a file like + '/tmp/foobars-proposed-fix-v1.patch' and apply it like this:: + + git apply /tmp/foobars-proposed-fix-v1.patch + + In case of multiple patches, repeat this step with the others. + + Now give that kernel a special tag to facilitates its identification and + prevent accidentally overwriting another kernel:: + + ./scripts/config --set-str CONFIG_LOCALVERSION '-local-foobars-fix-v1' + +* Build a kernel using the familiar commands, just without copying the kernel + build configuration over, as that has been taken care of already:: + + make olddefconfig && + make -j $(nproc --all) + # * Check if the free space suffices holding another kernel: + df -h /boot/ /lib/modules/ + sudo make modules_install + command -v installkernel && sudo make install + make -s kernelrelease | tee -a ~/kernels-built + reboot + +* Now verify you booted the newly built kernel and check it. + +[:ref:`details `] .. _submit_improvements: @@ -1986,20 +2075,33 @@ build artifacts and the Linux sources, but will leave the Git repository (~/linux/.git/) behind -- a simple ``git reset --hard`` thus will bring the sources back. -Removing the repository as well would likely be unwise at this point: there is a -decent chance developers will ask you to build another kernel to perform -additional tests. This is often required to debug an issue or check proposed -fixes. Before doing so you want to run the ``git fetch mainline`` command again -followed by ``git checkout mainline/master`` to bring your clone up to date and -checkout the latest codebase. Then apply the patch using ``git apply -`` or ``git am `` and build yet another kernel using the -familiar commands. +Removing the repository as well would likely be unwise at this point: there +is a decent chance developers will ask you to build another kernel to +perform additional tests -- like testing a debug patch or a proposed fix. +Details on how to perform those can be found in the section :ref:`Optional +tasks: test reverts, patches, or later versions `. Additional tests are also the reason why you want to keep the ~/kernel-config-working file around for a few weeks. [:ref:`back to step-by-step guide `] +.. _introoptional_bisref: + +Test reverts, patches, or later versions +---------------------------------------- + + *While or after reporting a bug, you might want or potentially will be asked + to test reverts, patches, proposed fixes, or other versions.* + [:ref:`... `] + +All the commands used in this section should be pretty straight forward, so +there is not much to add except one thing: when setting a kernel tag as +instructed, ensure it is not much longer than the one used in the example, as +problems will arise if the kernelrelease identifier exceeds 63 characters. + +[:ref:`back to step-by-step guide `]. + Additional reading material =========================== -- cgit v1.2.3 From 2bcfd71e8dfca5047f9fbcc2e2ba62c5bb39aa3a Mon Sep 17 00:00:00 2001 From: Thorsten Leemhuis Date: Tue, 9 Apr 2024 09:30:48 +0200 Subject: docs: verify/bisect: describe how to use a build host Describe how to build kernels on another system (with and without cross-compiling), as building locally can be quite painfully on some slow systems. This is done in an add-on section, as it would make the step-by-step guide to complicated if this special case would be described there. Signed-off-by: Thorsten Leemhuis Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/288160cb4769e46a3280250ca71da0abc4aa002d.1712647788.git.linux@leemhuis.info --- .../verify-bugs-and-bisect-regressions.rst | 78 ++++++++++++++++++++-- 1 file changed, 74 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst index 1987c827211f..6193c7976427 100644 --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst @@ -276,6 +276,10 @@ Preparations: set up everything to build your own kernels The following steps lay the groundwork for all further tasks. +Note: the instructions assume you are building and testing on the same +machine; if you want to compile the kernel on another system, check +:ref:`Build kernels on a different machine ` below. + .. _backup_bissbs: * Create a fresh backup and put system repair and restore tools at hand, just @@ -2103,11 +2107,77 @@ problems will arise if the kernelrelease identifier exceeds 63 characters. [:ref:`back to step-by-step guide `]. -Additional reading material -=========================== +Additional information +====================== + +.. _buildhost_bis: + +Build kernels on a different machine +------------------------------------ + +To compile kernels on another system, slightly alter the step-by-step guide's +instructions: + +* Start following the guide on the machine where you want to install and test + the kernels later. + +* After executing ':ref:`Boot into the working kernel and briefly use the + apparently broken feature `', save the list of loaded + modules to a file using ``lsmod > ~/test-machine-lsmod``. Then locate the + build configuration for the running kernel (see ':ref:`Start defining the + build configuration for your kernel `' for hints on where + to find it) and store it as '~/test-machine-config-working'. Transfer both + files to the home directory of your build host. + +* Continue the guide on the build host (e.g. with ':ref:`Ensure to have enough + free space for building [...] `'). + +* When you reach ':ref:`Start preparing a kernel build configuration[...] + `': before running ``make olddefconfig`` for the first time, + execute the following command to base your configuration on the one from the + test machine's 'working' kernel:: + + cp ~/test-machine-config-working ~/linux/.config + +* During the next step to ':ref:`disable any apparently superfluous kernel + modules `' use the following command instead:: + + yes '' | make localmodconfig LSMOD=~/lsmod_foo-machine localmodconfig + +* Continue the guide, but ignore the instructions outlining how to compile, + install, and reboot into a kernel every time they come up. Instead build + like this:: -Further sources ---------------- + cp ~/kernel-config-working .config + make olddefconfig && + make -j $(nproc --all) targz-pkg + + This will generate a gzipped tar file whose name is printed in the last + line shown; for example, a kernel with the kernelrelease identifier + '6.0.0-rc1-local-g928a87efa423' built for x86 machines usually will + be stored as '~/linux/linux-6.0.0-rc1-local-g928a87efa423-x86.tar.gz'. + + Copy that file to your test machine's home directory. + +* Switch to the test machine to check if you have enough space to hold another + kernel. Then extract the file you transferred:: + + sudo tar -xvzf ~/linux-6.0.0-rc1-local-g928a87efa423-x86.tar.gz -C / + + Afterwards :ref:`generate the initramfs and add the kernel to your boot + loader's configuration `; on some distributions the following + command will take care of both these tasks:: + + sudo /sbin/installkernel 6.0.0-rc1-local-g928a87efa423 /boot/vmlinuz-6.0.0-rc1-local-g928a87efa423 + + Now reboot and ensure you started the intended kernel. + +This approach even works when building for another architecture: just install +cross-compilers and add the appropriate parameters to every invocation of make +(e.g. ``make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- [...]``). + +Additional reading material +--------------------------- * The `man page for 'git bisect' `_ and `fighting regressions with 'git bisect' `_ -- cgit v1.2.3 From 8d939ae349343b55984ea821164e2be526d48cd1 Mon Sep 17 00:00:00 2001 From: Thorsten Leemhuis Date: Tue, 9 Apr 2024 09:30:49 +0200 Subject: docs: verify/bisect: stable regressions: first stable, then mainline Rearrange the instructions so that readers facing a regression within a stable or longterm series first test its latest release before testing mainline. This is less scary for some people. It also reduces the chance that something goes sideways for readers that compile their first kernel, as mainline can cause slightly more trouble. Signed-off-by: Thorsten Leemhuis Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/efd3cb9c68db450091021326bf9c334553df0ec2.1712647788.git.linux@leemhuis.info --- .../verify-bugs-and-bisect-regressions.rst | 91 ++++++++++++---------- 1 file changed, 51 insertions(+), 40 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst index 6193c7976427..c389d4fd7599 100644 --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst @@ -309,31 +309,32 @@ machine; if you want to compile the kernel on another system, check .. _rangecheck_bissbs: * Determine the kernel versions considered 'good' and 'bad' throughout this - guide. + guide: - Do you follow this guide to verify if a bug is present in the code developers - care for? Then consider the mainline release your 'working' kernel (the newest - one you regularly use) is based on to be the 'good' version; if your 'working' - kernel for example is 6.0.13, then your 'good' kernel is 6.0. + * Do you follow this guide to verify if a bug is present in the code the + primary developers care for? Then consider the version of the newest kernel + you regularly use currently as 'good' (e.g. 6.0, 6.0.13, or 6.1-rc2). - In case you face a regression, it depends on the version range where the - regression was introduced: + * Do you face a regression, e.g. something broke or works worse after + switching to a newer kernel version? In that case it depends on the version + range during which the problem appeared: - * Something which used to work in Linux 6.0 broke when switching to Linux - 6.1-rc1? Then henceforth regard 6.0 as the last known 'good' version - and 6.1-rc1 as the first 'bad' one. + * Something regressed when updating from a stable/longterm release + (say 6.0.13) to a newer mainline series (like 6.1-rc7 or 6.1) or a + stable/longterm version based on one (say 6.1.5)? Then consider the + mainline release your working kernel is based on to be the 'good' + version (e.g. 6.0) and the first version to be broken as the 'bad' one + (e.g. 6.1-rc7, 6.1, or 6.1.5). Note, at this point it is merely assumed + that 6.0 is fine; this hypothesis will be checked in segment 2. - * Some function stopped working when updating from 6.0.13 to 6.1.5? Then for - the time being consider 6.0 as the last 'good' version and 6.1.5 as - the 'bad' one. Note, at this point it is merely assumed that 6.0 is fine; - this assumption will be checked in segment 2. + * Something regressed when switching from one mainline version (say 6.0) to + a later one (like 6.1-rc1) or a stable/longterm release based on it + (say 6.1.5)? Then regard the last working version (e.g. 6.0) as 'good' and + the first broken (e.g. 6.1-rc1 or 6.1.5) as 'bad'. - * A feature you used in 6.0.13 does not work at all or worse in 6.1.15? In - that case you want to bisect within a stable/longterm series: consider - 6.0.13 as the last known 'good' version and 6.0.15 as the first 'bad' - one. Note, in this case you still want to compile and test a mainline kernel - as explained in segment 1: the outcome will determine if you need to report - your issue to the regular developers or the stable team. + * Something regressed when updating within a stable/longterm series (say + from 6.0.13 to 6.0.15)? Then consider those versions as 'good' and 'bad' + (e.g. 6.0.13 and 6.0.15), as you need to bisect within that series. *Note, do not confuse 'good' version with 'working' kernel; the latter term throughout this guide will refer to the last kernel that has been working @@ -392,19 +393,13 @@ machine; if you want to compile the kernel on another system, check .. _stablesources_bissbs: -* Retrieve the sources for any stable or longterm series you might need. - - Is the version you earlier established as 'bad' a stable or longterm release? - Then download the code for the series it belongs to ('linux-6.1.y' in this - example):: +* Is one of the versions you earlier established as 'good' or 'bad' a stable or + longterm release (say 6.1.5)? Then download the code for the series it belongs + to ('linux-6.1.y' in this example):: git remote set-branches --add stable linux-6.1.y git fetch stable - If the version earlier established as 'good' is from a different stable or - longterm series (say 6.0.13), repeat the previous step, but this time for the - branch holding the series the 'good' version belongs to (e.g. linux-6.0.y). - .. _oldconfig_bissbs: * Start preparing a kernel build configuration (the '.config' file). @@ -545,10 +540,24 @@ be a waste of time. [:ref:`details `] .. _checkoutmaster_bissbs: -* Check out the latest Linux codebase:: +* Check out the latest Linux codebase. - cd ~/linux/ - git switch --discard-changes --detach mainline/master + * Are your 'good' and 'bad' versions from the same stable or longterm series? + Then check the `front page of kernel.org `_: if it + lists a release from that series without an '[EOL]' tag, checkout the series + latest version ('linux-6.1.y' in the following example):: + + cd ~/linux/ + git switch --discard-changes --detach stable/linux-6.1.y + + Your series is unsupported, if is not listed or carrying a 'end of life' + tag. In that case you might want to check if a successor series (say + linux-6.2.y) or mainline (see next point) fix the bug. + + * In all other cases, run:: + + cd ~/linux/ + git switch --discard-changes --detach mainline/master [:ref:`details `] @@ -650,15 +659,15 @@ be a waste of time. [:ref:`details `] .. _recheckstablebroken_bissbs: -* Are you facing a problem within a stable/longterm series, but failed to - reproduce it with the mainline kernel you just built? One that according to - the `front page of kernel.org `_ is still supported? Then - check if the latest codebase for the particular series might already fix the - problem. To do so, check out that series latest version (again, this here is - assumed to be 6.0):: +* Did you just built a stable or longterm kernel? And were you able to reproduce + the regression with it? Then you should test the latest mainline codebase as + well, because the result determines which developers the bug must be submitted + to. + + To prepare that test, check out current mainline:: cd ~/linux/ - git switch --discard-changes --detach linux-6.0.y + git switch --discard-changes --detach mainline/master Now use the checked out code to build and install another kernel using the commands the earlier steps already described in more detail:: @@ -680,7 +689,9 @@ be a waste of time. [:ref:`details `] uname -r cat /proc/sys/kernel/tainted - Now verify if this kernel is showing the problem. + Now verify if this kernel is showing the problem. If it does, then you need + to report the bug to the primary developers; if it does not, report it to the + stable team. See Documentation/admin-guide/reporting-issues.rst for details. [:ref:`details `] -- cgit v1.2.3 From 62c48dd33b4f2e037554d1322ae4f9f60e9461ef Mon Sep 17 00:00:00 2001 From: Shengjiu Wang Date: Mon, 15 Apr 2024 15:17:36 +0800 Subject: ASoC: dt-bindings: fsl-asoc-card: Add compatbile string for wm8904 codec The wm8904 codec is used on an i.MX95 Toradex board. Signed-off-by: Shengjiu Wang Link: https://lore.kernel.org/r/1713165456-3494-3-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml b/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml index bbf6fa1a2012..9922664d5ccc 100644 --- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml +++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml @@ -77,6 +77,7 @@ properties: - fsl,imx-audio-tlv320aic31xx - fsl,imx-audio-tlv320aic32x4 - fsl,imx-audio-wm8524 + - fsl,imx-audio-wm8904 - fsl,imx-audio-wm8960 - fsl,imx-audio-wm8962 - fsl,imx-audio-wm8958 -- cgit v1.2.3 From dc7a31300a8f28af282974512c2d403ada0658b5 Mon Sep 17 00:00:00 2001 From: AngeloGioacchino Del Regno Date: Tue, 16 Apr 2024 09:14:06 +0200 Subject: ASoC: dt-bindings: mt8195: Document audio-routing and dai-link subnode Document the dai-link subnodes and the audio-routing property, allowing to describe machine specific audio hardware and links in device tree. While at it, also deprecate the old properties which were previously used with driver hardcoded configuration. Also, since describing machine specific audio hardware and links replaces the now deprecated old logic doing the same in a driver hardcoded fashion, it is not allowed to have both the old and new properties together. Reviewed-by: Rob Herring Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240416071410.75620-15-angelogioacchino.delregno@collabora.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/mt8195-mt6359.yaml | 134 +++++++++++++++++++++ 1 file changed, 134 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml b/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml index c1ddbf672ca3..2af1d8ffbd8b 100644 --- a/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml +++ b/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml @@ -12,6 +12,9 @@ maintainers: description: This binding describes the MT8195 sound card. +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: enum: @@ -23,6 +26,33 @@ properties: $ref: /schemas/types.yaml#/definitions/string description: User specified audio sound card name + audio-routing: + 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. + Valid names could be the input or output widgets of audio components, + power supplies, MicBias of codec and the software switch. + minItems: 2 + items: + enum: + # Sinks + - Ext Spk + - Headphone + - IN1P + - Left Spk + - Right Spk + + # Sources + - Headset Mic + - HPOL + - HPOR + - Left BE_OUT + - Left SPO + - Right BE_OUT + - Right SPO + - Speaker + mediatek,platform: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8195 ASoC platform. @@ -30,10 +60,12 @@ properties: mediatek,dptx-codec: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8195 Display Port Tx codec node. + deprecated: true mediatek,hdmi-codec: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8195 HDMI codec node. + deprecated: true mediatek,adsp: $ref: /schemas/types.yaml#/definitions/phandle @@ -45,20 +77,122 @@ properties: A list of the desired dai-links in the sound card. Each entry is a name defined in the machine driver. +patternProperties: + ".*-dai-link$": + type: object + additionalProperties: false + description: + Container for dai-link level properties and CODEC sub-nodes. + + properties: + link-name: + description: Indicates dai-link name and PCM stream name + enum: + - DPTX_BE + - ETDM1_IN_BE + - ETDM2_IN_BE + - ETDM1_OUT_BE + - ETDM2_OUT_BE + - ETDM3_OUT_BE + - PCM1_BE + + codec: + description: Holds subnode which indicates codec dai. + type: object + additionalProperties: false + properties: + sound-dai: + minItems: 1 + maxItems: 2 + required: + - sound-dai + + dai-format: + description: audio format + enum: [ i2s, right_j, left_j, dsp_a, dsp_b ] + + mediatek,clk-provider: + $ref: /schemas/types.yaml#/definitions/string + description: Indicates dai-link clock master. + enum: [ cpu, codec ] + + required: + - link-name + additionalProperties: false required: - compatible - mediatek,platform +# Disallow legacy properties if xxx-dai-link nodes are specified +if: + not: + patternProperties: + ".*-dai-link$": false +then: + properties: + mediatek,dptx-codec: false + mediatek,hdmi-codec: false + examples: - | sound: mt8195-sound { compatible = "mediatek,mt8195_mt6359_rt1019_rt5682"; + model = "mt8195_r1019_5682"; mediatek,platform = <&afe>; pinctrl-names = "default"; pinctrl-0 = <&aud_pins_default>; + + audio-routing = + "Headphone", "HPOL", + "Headphone", "HPOR", + "IN1P", "Headset Mic", + "Ext Spk", "Speaker"; + + mm-dai-link { + link-name = "ETDM1_IN_BE"; + mediatek,clk-provider = "cpu"; + }; + + hs-playback-dai-link { + link-name = "ETDM1_OUT_BE"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&headset_codec>; + }; + }; + + hs-capture-dai-link { + link-name = "ETDM2_IN_BE"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&headset_codec>; + }; + }; + + spk-playback-dai-link { + link-name = "ETDM2_OUT_BE"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&spk_amplifier>; + }; + }; + + hdmi-dai-link { + link-name = "ETDM3_OUT_BE"; + codec { + sound-dai = <&hdmi_tx>; + }; + }; + + displayport-dai-link { + link-name = "DPTX_BE"; + codec { + sound-dai = <&dp_tx>; + }; + }; }; ... -- cgit v1.2.3 From 5a50483c47b8cf3066eb151fa21e195f3dfab5a8 Mon Sep 17 00:00:00 2001 From: AngeloGioacchino Del Regno Date: Tue, 16 Apr 2024 09:14:07 +0200 Subject: ASoC: dt-bindings: mt8192: Document audio-routing and dai-link subnode Document the dai-link subnodes and the audio-routing property, allowing to describe machine specific audio hardware and links in device tree. While at it, also deprecate the old properties which were previously used with the driver's partially hardcoded configuration. Also, since describing machine specific audio hardware and links replaces the now deprecated old logic doing the same in a driver hardcoded fashion, it is not allowed to have both the old and new properties together. Reviewed-by: Rob Herring Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240416071410.75620-16-angelogioacchino.delregno@collabora.com Signed-off-by: Mark Brown --- .../sound/mt8192-mt6359-rt1015-rt5682.yaml | 139 +++++++++++++++++++-- 1 file changed, 129 insertions(+), 10 deletions(-) (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 7e50f5d65c8f..c4e68f31aaab 100644 --- a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml +++ b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml @@ -13,6 +13,9 @@ maintainers: description: This binding describes the MT8192 sound card. +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: enum: @@ -20,6 +23,31 @@ properties: - mediatek,mt8192_mt6359_rt1015p_rt5682 - mediatek,mt8192_mt6359_rt1015p_rt5682s + audio-routing: + 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. + Valid names could be the input or output widgets of audio components, + power supplies, MicBias of codec and the software switch. + minItems: 2 + items: + enum: + # Sinks + - Speakers + - Headphone Jack + - IN1P + - Left Spk + - Right Spk + + # Sources + - Headset Mic + - HPOL + - HPOR + - Left SPO + - Right SPO + - Speaker + mediatek,platform: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8192 ASoC platform. @@ -27,10 +55,12 @@ properties: mediatek,hdmi-codec: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of HDMI codec. + deprecated: true headset-codec: type: object additionalProperties: false + deprecated: true properties: sound-dai: @@ -41,6 +71,7 @@ properties: speaker-codecs: type: object additionalProperties: false + deprecated: true properties: sound-dai: @@ -51,33 +82,121 @@ properties: required: - sound-dai -additionalProperties: false +patternProperties: + ".*-dai-link$": + type: object + additionalProperties: false + + description: + Container for dai-link level properties and CODEC sub-nodes. + + properties: + link-name: + description: Indicates dai-link name and PCM stream name + enum: + - I2S0 + - I2S1 + - I2S2 + - I2S3 + - I2S4 + - I2S5 + - I2S6 + - I2S7 + - I2S8 + - I2S9 + - TDM + + codec: + description: Holds subnode which indicates codec dai. + type: object + additionalProperties: false + properties: + sound-dai: + minItems: 1 + maxItems: 2 + required: + - sound-dai + + dai-format: + description: audio format + enum: [ i2s, right_j, left_j, dsp_a, dsp_b ] + + mediatek,clk-provider: + $ref: /schemas/types.yaml#/definitions/string + description: Indicates dai-link clock master. + enum: [ cpu, codec ] + + required: + - link-name + +unevaluatedProperties: false required: - compatible - mediatek,platform - - headset-codec - - speaker-codecs + +# Disallow legacy properties if xxx-dai-link nodes are specified +if: + not: + patternProperties: + ".*-dai-link$": false +then: + properties: + headset-codec: false + speaker-codecs: false + mediatek,hdmi-codec: false examples: - | sound: mt8192-sound { compatible = "mediatek,mt8192_mt6359_rt1015_rt5682"; - mediatek,platform = <&afe>; - mediatek,hdmi-codec = <&anx_bridge_dp>; + model = "mt8192_mt6359_rt1015_rt5682"; pinctrl-names = "aud_clk_mosi_off", "aud_clk_mosi_on"; pinctrl-0 = <&aud_clk_mosi_off>; pinctrl-1 = <&aud_clk_mosi_on>; + mediatek,platform = <&afe>; + + audio-routing = + "Headphone Jack", "HPOL", + "Headphone Jack", "HPOR", + "IN1P", "Headset Mic", + "Speakers", "Speaker"; + + spk-playback-dai-link { + link-name = "I2S3"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&rt1015p>; + }; + }; + + hs-playback-dai-link { + link-name = "I2S8"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&rt5682 0>; + }; + }; - headset-codec { - sound-dai = <&rt5682>; + hs-capture-dai-link { + link-name = "I2S9"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&rt5682 0>; + }; }; - speaker-codecs { - sound-dai = <&rt1015_l>, - <&rt1015_r>; + displayport-dai-link { + link-name = "TDM"; + dai-format = "dsp_a"; + codec { + sound-dai = <&anx_bridge_dp>; + }; }; }; -- cgit v1.2.3 From 787f190cd1cd3123555e33a3400f3e919ec94a81 Mon Sep 17 00:00:00 2001 From: AngeloGioacchino Del Regno Date: Tue, 16 Apr 2024 09:14:08 +0200 Subject: ASoC: dt-bindings: mt8186: Document audio-routing and dai-link subnode Document the dai-link subnodes and the audio-routing property, allowing to describe machine specific audio hardware and links in device tree. While at it, also deprecate the old properties which were previously used with the driver's partially hardcoded configuration. Also, since describing machine specific audio hardware and links replaces the now deprecated old logic doing the same in a driver hardcoded fashion, it is not allowed to have both the old and new properties together. Reviewed-by: Rob Herring Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240416071410.75620-17-angelogioacchino.delregno@collabora.com Signed-off-by: Mark Brown --- .../sound/mt8186-mt6366-da7219-max98357.yaml | 131 +++++++++++++++++++-- .../sound/mt8186-mt6366-rt1019-rt5682s.yaml | 120 +++++++++++++++++-- 2 files changed, 233 insertions(+), 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml b/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml index 9853c11a1330..cbc641ecbe94 100644 --- a/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml +++ b/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml @@ -12,17 +12,46 @@ maintainers: description: This binding describes the MT8186 sound card. +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: enum: - mediatek,mt8186-mt6366-da7219-max98357-sound + 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. + Valid names could be the input or output widgets of audio components, + power supplies, MicBias of codec and the software switch. + minItems: 2 + items: + enum: + # Sinks + - HDMI1 + - Headphones + - Line Out + - MIC + - Speakers + + # Sources + - Headset Mic + - HPL + - HPR + - Speaker + - TX + mediatek,platform: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8186 ASoC platform. headset-codec: type: object + deprecated: true additionalProperties: false properties: sound-dai: @@ -32,6 +61,7 @@ properties: playback-codecs: type: object + deprecated: true additionalProperties: false properties: sound-dai: @@ -53,32 +83,115 @@ properties: A list of the desired dai-links in the sound card. Each entry is a name defined in the machine driver. -additionalProperties: false +patternProperties: + ".*-dai-link$": + type: object + additionalProperties: false + description: + Container for dai-link level properties and CODEC sub-nodes. + + properties: + link-name: + description: Indicates dai-link name and PCM stream name + items: + enum: + - I2S0 + - I2S1 + - I2S2 + - I2S3 + + codec: + description: Holds subnode which indicates codec dai. + type: object + additionalProperties: false + properties: + sound-dai: + minItems: 1 + maxItems: 2 + required: + - sound-dai + + dai-format: + description: audio format + items: + enum: + - i2s + - right_j + - left_j + - dsp_a + - dsp_b + + mediatek,clk-provider: + $ref: /schemas/types.yaml#/definitions/string + description: Indicates dai-link clock master. + items: + enum: + - cpu + - codec + + required: + - link-name + +unevaluatedProperties: false required: - compatible - mediatek,platform - - headset-codec - - playback-codecs + +# Disallow legacy properties if xxx-dai-link nodes are specified +if: + not: + patternProperties: + ".*-dai-link$": false +then: + properties: + headset-codec: false + speaker-codecs: false examples: - | sound: mt8186-sound { compatible = "mediatek,mt8186-mt6366-da7219-max98357-sound"; - mediatek,platform = <&afe>; + model = "mt8186_da7219_m98357"; pinctrl-names = "aud_clk_mosi_off", "aud_clk_mosi_on"; pinctrl-0 = <&aud_clk_mosi_off>; pinctrl-1 = <&aud_clk_mosi_on>; + mediatek,platform = <&afe>; + + audio-routing = + "Headphones", "HPL", + "Headphones", "HPR", + "MIC", "Headset Mic", + "Speakers", "Speaker", + "HDMI1", "TX"; + + hs-playback-dai-link { + link-name = "I2S0"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&da7219>; + }; + }; - headset-codec { - sound-dai = <&da7219>; + hs-capture-dai-link { + link-name = "I2S1"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&da7219>; + }; }; - playback-codecs { - sound-dai = <&anx_bridge_dp>, - <&max98357a>; + spk-dp-playback-dai-link { + link-name = "I2S3"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&anx_bridge_dp>, <&max98357a>; + }; }; }; diff --git a/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml b/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml index bdf7b0960533..ed93f18ef985 100644 --- a/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml +++ b/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml @@ -12,6 +12,9 @@ maintainers: description: This binding describes the MT8186 sound card. +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: enum: @@ -19,6 +22,34 @@ properties: - mediatek,mt8186-mt6366-rt5682s-max98360-sound - mediatek,mt8186-mt6366-rt5650-sound + 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. + Valid names could be the input or output widgets of audio components, + power supplies, MicBias of codec and the software switch. + minItems: 2 + items: + enum: + # Sinks + - HDMI1 + - Headphone + - IN1P + - IN1N + - Line Out + - Speakers + + # Sources + - Headset Mic + - HPOL + - HPOR + - Speaker + - SPOL + - SPOR + - TX + mediatek,platform: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8186 ASoC platform. @@ -32,6 +63,7 @@ properties: headset-codec: type: object + deprecated: true additionalProperties: false properties: sound-dai: @@ -41,6 +73,7 @@ properties: playback-codecs: type: object + deprecated: true additionalProperties: false properties: sound-dai: @@ -62,13 +95,56 @@ properties: A list of the desired dai-links in the sound card. Each entry is a name defined in the machine driver. -additionalProperties: false +patternProperties: + ".*-dai-link$": + type: object + additionalProperties: false + description: + Container for dai-link level properties and CODEC sub-nodes. + + properties: + link-name: + description: Indicates dai-link name and PCM stream name + enum: [ I2S0, I2S1, I2S2, I2S3 ] + + codec: + description: Holds subnode which indicates codec dai. + type: object + additionalProperties: false + properties: + sound-dai: + minItems: 1 + maxItems: 2 + required: + - sound-dai + + dai-format: + description: audio format + enum: [ i2s, right_j, left_j, dsp_a, dsp_b ] + + mediatek,clk-provider: + $ref: /schemas/types.yaml#/definitions/string + description: Indicates dai-link clock master. + enum: [ cpu, codec ] + + required: + - link-name + +unevaluatedProperties: false required: - compatible - mediatek,platform - - headset-codec - - playback-codecs + +# Disallow legacy properties if xxx-dai-link nodes are specified +if: + not: + patternProperties: + ".*-dai-link$": false +then: + properties: + headset-codec: false + speaker-codecs: false examples: - | @@ -76,23 +152,49 @@ examples: sound: mt8186-sound { compatible = "mediatek,mt8186-mt6366-rt1019-rt5682s-sound"; - mediatek,platform = <&afe>; + model = "mt8186_rt1019_rt5682s"; pinctrl-names = "aud_clk_mosi_off", "aud_clk_mosi_on", "aud_gpio_dmic_sec"; pinctrl-0 = <&aud_clk_mosi_off>; pinctrl-1 = <&aud_clk_mosi_on>; pinctrl-2 = <&aud_gpio_dmic_sec>; + mediatek,platform = <&afe>; dmic-gpios = <&pio 23 GPIO_ACTIVE_HIGH>; - headset-codec { - sound-dai = <&rt5682s>; + audio-routing = + "Headphone", "HPOL", + "Headphone", "HPOR", + "IN1P", "Headset Mic", + "Speakers", "Speaker", + "HDMI1", "TX"; + + hs-playback-dai-link { + link-name = "I2S0"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&rt5682s 0>; + }; + }; + + hs-capture-dai-link { + link-name = "I2S1"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&rt5682s 0>; + }; }; - playback-codecs { - sound-dai = <&it6505dptx>, - <&rt1019p>; + spk-hdmi-playback-dai-link { + link-name = "I2S3"; + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; + codec { + sound-dai = <&it6505dptx>, <&rt1019p>; + }; }; }; -- cgit v1.2.3 From f5c12105c15f0ddf0ff37646290568dd986fa2f3 Mon Sep 17 00:00:00 2001 From: Oscar Salvador Date: Thu, 4 Apr 2024 09:07:00 +0200 Subject: mm,page_owner: fix refcount imbalance Current code does not contemplate scenarios were an allocation and free operation on the same pages do not handle it in the same amount at once. To give an example, page_alloc_exact(), where we will allocate a page of enough order to stafisfy the size request, but we will free the remainings right away. In the above example, we will increment the stack_record refcount only once, but we will decrease it the same number of times as number of unused pages we have to free. This will lead to a warning because of refcount imbalance. Fix this by recording the number of base pages in the refcount field. Link: https://lkml.kernel.org/r/20240404070702.2744-3-osalvador@suse.de Reported-by: syzbot+41bbfdb8d41003d12c0f@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-mm/00000000000090e8ff0613eda0e5@google.com Fixes: 217b2119b9e2 ("mm,page_owner: implement the tracking of the stacks count") Signed-off-by: Oscar Salvador Reviewed-by: Vlastimil Babka Tested-by: Alexandre Ghiti Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Marco Elver Cc: Michal Hocko Cc: Palmer Dabbelt Signed-off-by: Andrew Morton --- Documentation/mm/page_owner.rst | 73 +++++++++++++++++++++-------------------- mm/page_owner.c | 34 +++++++++++-------- 2 files changed, 58 insertions(+), 49 deletions(-) (limited to 'Documentation') diff --git a/Documentation/mm/page_owner.rst b/Documentation/mm/page_owner.rst index 0d0334cd5179..3a45a20fc05a 100644 --- a/Documentation/mm/page_owner.rst +++ b/Documentation/mm/page_owner.rst @@ -24,10 +24,10 @@ 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. -It can also be used to show all the stacks and their outstanding -allocations, which gives us a quick overview of where the memory is going -without the need to screen through all the pages and match the allocation -and free operation. +It can also be used to show all the stacks and their current number of +allocated base pages, which gives us a quick overview of where the memory +is going without the need to screen through all the pages and match the +allocation and free operation. 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 @@ -75,42 +75,45 @@ Usage cat /sys/kernel/debug/page_owner_stacks/show_stacks > stacks.txt cat stacks.txt - prep_new_page+0xa9/0x120 - get_page_from_freelist+0x7e6/0x2140 - __alloc_pages+0x18a/0x370 - new_slab+0xc8/0x580 - ___slab_alloc+0x1f2/0xaf0 - __slab_alloc.isra.86+0x22/0x40 - kmem_cache_alloc+0x31b/0x350 - __khugepaged_enter+0x39/0x100 - dup_mmap+0x1c7/0x5ce - copy_process+0x1afe/0x1c90 - kernel_clone+0x9a/0x3c0 - __do_sys_clone+0x66/0x90 - do_syscall_64+0x7f/0x160 - entry_SYSCALL_64_after_hwframe+0x6c/0x74 - stack_count: 234 + post_alloc_hook+0x177/0x1a0 + get_page_from_freelist+0xd01/0xd80 + __alloc_pages+0x39e/0x7e0 + allocate_slab+0xbc/0x3f0 + ___slab_alloc+0x528/0x8a0 + kmem_cache_alloc+0x224/0x3b0 + sk_prot_alloc+0x58/0x1a0 + sk_alloc+0x32/0x4f0 + inet_create+0x427/0xb50 + __sock_create+0x2e4/0x650 + inet_ctl_sock_create+0x30/0x180 + igmp_net_init+0xc1/0x130 + ops_init+0x167/0x410 + setup_net+0x304/0xa60 + copy_net_ns+0x29b/0x4a0 + create_new_namespaces+0x4a1/0x820 + nr_base_pages: 16 ... ... echo 7000 > /sys/kernel/debug/page_owner_stacks/count_threshold cat /sys/kernel/debug/page_owner_stacks/show_stacks> stacks_7000.txt cat stacks_7000.txt - prep_new_page+0xa9/0x120 - get_page_from_freelist+0x7e6/0x2140 - __alloc_pages+0x18a/0x370 - alloc_pages_mpol+0xdf/0x1e0 - folio_alloc+0x14/0x50 - filemap_alloc_folio+0xb0/0x100 - page_cache_ra_unbounded+0x97/0x180 - filemap_fault+0x4b4/0x1200 - __do_fault+0x2d/0x110 - do_pte_missing+0x4b0/0xa30 - __handle_mm_fault+0x7fa/0xb70 - handle_mm_fault+0x125/0x300 - do_user_addr_fault+0x3c9/0x840 - exc_page_fault+0x68/0x150 - asm_exc_page_fault+0x22/0x30 - stack_count: 8248 + post_alloc_hook+0x177/0x1a0 + get_page_from_freelist+0xd01/0xd80 + __alloc_pages+0x39e/0x7e0 + alloc_pages_mpol+0x22e/0x490 + folio_alloc+0xd5/0x110 + filemap_alloc_folio+0x78/0x230 + page_cache_ra_order+0x287/0x6f0 + filemap_get_pages+0x517/0x1160 + filemap_read+0x304/0x9f0 + xfs_file_buffered_read+0xe6/0x1d0 [xfs] + xfs_file_read_iter+0x1f0/0x380 [xfs] + __kernel_read+0x3b9/0x730 + kernel_read_file+0x309/0x4d0 + __do_sys_finit_module+0x381/0x730 + do_syscall_64+0x8d/0x150 + entry_SYSCALL_64_after_hwframe+0x62/0x6a + nr_base_pages: 20824 ... cat /sys/kernel/debug/page_owner > page_owner_full.txt diff --git a/mm/page_owner.c b/mm/page_owner.c index 52d1ced0b57f..5df0d6892bdc 100644 --- a/mm/page_owner.c +++ b/mm/page_owner.c @@ -196,7 +196,8 @@ static void add_stack_record_to_list(struct stack_record *stack_record, spin_unlock_irqrestore(&stack_list_lock, flags); } -static void inc_stack_record_count(depot_stack_handle_t handle, gfp_t gfp_mask) +static void inc_stack_record_count(depot_stack_handle_t handle, gfp_t gfp_mask, + int nr_base_pages) { struct stack_record *stack_record = __stack_depot_get_stack_record(handle); @@ -217,15 +218,20 @@ static void inc_stack_record_count(depot_stack_handle_t handle, gfp_t gfp_mask) /* Add the new stack_record to our list */ add_stack_record_to_list(stack_record, gfp_mask); } - refcount_inc(&stack_record->count); + refcount_add(nr_base_pages, &stack_record->count); } -static void dec_stack_record_count(depot_stack_handle_t handle) +static void dec_stack_record_count(depot_stack_handle_t handle, + int nr_base_pages) { struct stack_record *stack_record = __stack_depot_get_stack_record(handle); - if (stack_record) - refcount_dec(&stack_record->count); + if (!stack_record) + return; + + if (refcount_sub_and_test(nr_base_pages, &stack_record->count)) + pr_warn("%s: refcount went to 0 for %u handle\n", __func__, + handle); } static inline void __update_page_owner_handle(struct page_ext *page_ext, @@ -306,7 +312,7 @@ void __reset_page_owner(struct page *page, unsigned short order) * the machinery is not ready yet, we cannot decrement * their refcount either. */ - dec_stack_record_count(alloc_handle); + dec_stack_record_count(alloc_handle, 1 << order); } noinline void __set_page_owner(struct page *page, unsigned short order, @@ -325,7 +331,7 @@ noinline void __set_page_owner(struct page *page, unsigned short order, current->pid, current->tgid, ts_nsec, current->comm); page_ext_put(page_ext); - inc_stack_record_count(handle, gfp_mask); + inc_stack_record_count(handle, gfp_mask, 1 << order); } void __set_page_owner_migrate_reason(struct page *page, int reason) @@ -872,11 +878,11 @@ static void *stack_next(struct seq_file *m, void *v, loff_t *ppos) return stack; } -static unsigned long page_owner_stack_threshold; +static unsigned long page_owner_pages_threshold; static int stack_print(struct seq_file *m, void *v) { - int i, stack_count; + int i, nr_base_pages; struct stack *stack = v; unsigned long *entries; unsigned long nr_entries; @@ -887,14 +893,14 @@ static int stack_print(struct seq_file *m, void *v) nr_entries = stack_record->size; entries = stack_record->entries; - stack_count = refcount_read(&stack_record->count) - 1; + nr_base_pages = refcount_read(&stack_record->count) - 1; - if (stack_count < 1 || stack_count < page_owner_stack_threshold) + if (nr_base_pages < 1 || nr_base_pages < page_owner_pages_threshold) return 0; for (i = 0; i < nr_entries; i++) seq_printf(m, " %pS\n", (void *)entries[i]); - seq_printf(m, "stack_count: %d\n\n", stack_count); + seq_printf(m, "nr_base_pages: %d\n\n", nr_base_pages); return 0; } @@ -924,13 +930,13 @@ static const struct file_operations page_owner_stack_operations = { static int page_owner_threshold_get(void *data, u64 *val) { - *val = READ_ONCE(page_owner_stack_threshold); + *val = READ_ONCE(page_owner_pages_threshold); return 0; } static int page_owner_threshold_set(void *data, u64 val) { - WRITE_ONCE(page_owner_stack_threshold, val); + WRITE_ONCE(page_owner_pages_threshold, val); return 0; } -- cgit v1.2.3 From 5894ff6c4707af645f2faa36cf07cc2745e1658f Mon Sep 17 00:00:00 2001 From: Frank Li Date: Tue, 16 Apr 2024 10:47:47 -0400 Subject: ASoC: dt-bindings: fsl-esai: Remove 'fsl,*' from required list fsl,fifo-depth have default value 64 in driver(sound/soc/fsl/fsl_esai.c). fsl,esai-synchronous is flag(bool) type. It doesn't make sense to put flag type into 'required'. Fix warning: arch/arm/boot/dts/nxp/imx/imx6q-sabreauto.dtb: esai@2024000: 'fsl,fifo-depth' is a required property arch/arm/boot/dts/nxp/imx/imx6q-sabreauto.dtb: esai@2024000: 'fsl,esai-synchronous' is a required property Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20240416-esai_arm_dts_warning-v2-1-879e59c0c3b8@nxp.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl,esai.yaml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.yaml b/Documentation/devicetree/bindings/sound/fsl,esai.yaml index f167f1634d7e..2a64e682b517 100644 --- a/Documentation/devicetree/bindings/sound/fsl,esai.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,esai.yaml @@ -67,6 +67,7 @@ properties: fsl,fifo-depth: $ref: /schemas/types.yaml#/definitions/uint32 + default: 64 description: The number of elements in the transmit and receive FIFOs. This number is the maximum allowed value for @@ -95,8 +96,6 @@ required: - clock-names - dmas - dma-names - - fsl,fifo-depth - - fsl,esai-synchronous unevaluatedProperties: false -- cgit v1.2.3 From 9aea6d64bb3acbff6b2f33cb5bbff65e824ab9a7 Mon Sep 17 00:00:00 2001 From: Frank Li Date: Tue, 16 Apr 2024 10:47:48 -0400 Subject: ASoC: dt-bindings: fsl-esai: Add ref: dai-common.yaml Add ref: dai-common.yaml to fix below warning. arch/arm/boot/dts/nxp/imx/imx6q-sabreauto.dtb: esai@2024000: Unevaluated properties are not allowed ('#sound-dai-cells' was unexpected) Reviewed-by: Rob Herring Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20240416-esai_arm_dts_warning-v2-2-879e59c0c3b8@nxp.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl,esai.yaml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.yaml b/Documentation/devicetree/bindings/sound/fsl,esai.yaml index 2a64e682b517..f99ed20fa684 100644 --- a/Documentation/devicetree/bindings/sound/fsl,esai.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,esai.yaml @@ -99,6 +99,9 @@ required: unevaluatedProperties: false +allOf: + - $ref: dai-common.yaml# + examples: - | esai@2024000 { -- cgit v1.2.3 From ed37d240d03e84d09d4d2a771fda419da4308d17 Mon Sep 17 00:00:00 2001 From: Mohammad Shehar Yaar Tausif Date: Thu, 18 Apr 2024 22:03:24 +0530 Subject: ASoC: dt-bindings: tegra20-das: Convert to schema Convert NVIDIA Tegra20 DAS (Digital Audio Switch) binding to schema. Signed-off-by: Mohammad Shehar Yaar Tausif Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240418163326.58365-1-sheharyaar48@gmail.com Signed-off-by: Mark Brown --- .../bindings/sound/nvidia,tegra20-das.txt | 12 -------- .../bindings/sound/nvidia,tegra20-das.yaml | 36 ++++++++++++++++++++++ 2 files changed, 36 insertions(+), 12 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra20-das.txt create mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra20-das.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.txt deleted file mode 100644 index 6de3a7ee4efb..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.txt +++ /dev/null @@ -1,12 +0,0 @@ -NVIDIA Tegra 20 DAS (Digital Audio Switch) controller - -Required properties: -- compatible : "nvidia,tegra20-das" -- reg : Should contain DAS registers location and length - -Example: - -das@70000c00 { - compatible = "nvidia,tegra20-das"; - reg = <0x70000c00 0x80>; -}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.yaml new file mode 100644 index 000000000000..44c5ce8ee6be --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra20-das.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra 20 DAS (Digital Audio Switch) controller + +maintainers: + - Thierry Reding + - Jon Hunter + +properties: + compatible: + const: nvidia,tegra20-das + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <1>; + #size-cells = <1>; + das@70000c00 { + compatible = "nvidia,tegra20-das"; + reg = <0x70000c00 0x80>; + }; + }; +... -- cgit v1.2.3 From 467d2528d64e8fcf784850ac94f665efae2af149 Mon Sep 17 00:00:00 2001 From: Seven Lee Date: Mon, 15 Apr 2024 15:06:47 +0800 Subject: ASoC: dt-bindings: nau8821: Add delay control for ADC Change the original fixed delay to the assignment from the property. It will make it more flexible to different platforms to avoid pop noise at the beginning of recording. Signed-off-by: Seven Lee Reviewed-by: Rob Herring (Arm) Link: https://lore.kernel.org/r/20240415070649.3496487-2-wtli@nuvoton.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml index 054b53954ac3..9f44168efb3e 100644 --- a/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml +++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml @@ -103,6 +103,12 @@ properties: just limited to the left adc for design demand. type: boolean + nuvoton,adc-delay-ms: + description: Delay (in ms) to make input path stable and avoid pop noise. + minimum: 125 + maximum: 500 + default: 125 + '#sound-dai-cells': const: 0 @@ -136,6 +142,7 @@ examples: nuvoton,jack-eject-debounce = <0>; nuvoton,dmic-clk-threshold = <3072000>; nuvoton,dmic-slew-rate = <0>; + nuvoton,adc-delay-ms = <125>; #sound-dai-cells = <0>; }; }; -- cgit v1.2.3 From cee56a8e9cf89fd690e18eb2e6f09d3f8a6442fb Mon Sep 17 00:00:00 2001 From: Shenghao Ding Date: Sun, 7 Apr 2024 17:18:45 +0800 Subject: ASoc: dt-bindings: PCM6240: Add initial DT binding PCM6240 family chips are popular among audio customers, in spite of only a portion of the functionality of codec, such as ADC or DAC, and so on, for different Specifications, range from Personal Electric to Automotive Electric, even some professional fields. Yet their audio performance is far superior to the codec's, and cost is lower than codec, and much easier to program than codec. Reviewed-by: Rob Herring Signed-off-by: Shenghao Ding Link: https://lore.kernel.org/r/20240407091846.1299-5-shenghao-ding@ti.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/ti,pcm6240.yaml | 177 +++++++++++++++++++++ 1 file changed, 177 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/ti,pcm6240.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/ti,pcm6240.yaml b/Documentation/devicetree/bindings/sound/ti,pcm6240.yaml new file mode 100644 index 000000000000..dd5b08e3d7a1 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ti,pcm6240.yaml @@ -0,0 +1,177 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 - 2024 Texas Instruments Incorporated +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/ti,pcm6240.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments PCM6240 Family Audio ADC/DAC + +maintainers: + - Shenghao Ding + +description: | + The PCM6240 Family is a big family of Audio ADC/DAC for + different Specifications, range from Personal Electric + to Automotive Electric, even some professional fields. + + Specifications about the audio chip can be found at: + https://www.ti.com/lit/gpn/tlv320adc3120 + https://www.ti.com/lit/gpn/tlv320adc5120 + https://www.ti.com/lit/gpn/tlv320adc6120 + https://www.ti.com/lit/gpn/dix4192 + https://www.ti.com/lit/gpn/pcm1690 + https://www.ti.com/lit/gpn/pcm3120-q1 + https://www.ti.com/lit/gpn/pcm3140-q1 + https://www.ti.com/lit/gpn/pcm5120-q1 + https://www.ti.com/lit/gpn/pcm6120-q1 + https://www.ti.com/lit/gpn/pcm6260-q1 + https://www.ti.com/lit/gpn/pcm9211 + https://www.ti.com/lit/gpn/pcmd3140 + https://www.ti.com/lit/gpn/pcmd3180 + https://www.ti.com/lit/gpn/taa5212 + https://www.ti.com/lit/gpn/tad5212 + +properties: + compatible: + description: | + ti,adc3120: Stereo-channel, 768-kHz, Burr-Brown™ audio analog-to- + digital converter (ADC) with 106-dB SNR. + + ti,adc5120: 2-Channel, 768-kHz, Burr-Brown™ Audio ADC with 120-dB SNR. + + ti,adc6120: Stereo-channel, 768-kHz, Burr-Brown™ audio analog-to- + digital converter (ADC) with 123-dB SNR. + + ti,dix4192: 216-kHz digital audio converter with Quad-Channel In + and One-Channel Out. + + ti,pcm1690: Automotive Catalog 113dB SNR 8-Channel Audio DAC with + Differential Outputs. + + ti,pcm3120: Automotive, stereo, 106-dB SNR, 768-kHz, low-power + software-controlled audio ADC. + + ti,pcm3140: Automotive, Quad-Channel, 768-kHz, Burr-Brown™ Audio ADC + with 106-dB SNR. + + ti,pcm5120: Automotive, stereo, 120-dB SNR, 768-kHz, low-power + software-controlled audio ADC. + + ti,pcm5140: Automotive, Quad-Channel, 768-kHz, Burr-Brown™ Audio ADC + with 120-dB SNR. + + ti,pcm6120: Automotive, stereo, 123-dB SNR, 768-kHz, low-power + software-controlled audio ADC. + + ti,pcm6140: Automotive, Quad-Channel, 768-kHz, Burr-Brown™ Audio ADC + with 123-dB SNR. + + ti,pcm6240: Automotive 4-ch audio ADC with integrated programmable mic + bias, boost and input diagnostics. + + ti,pcm6260: Automotive 6-ch audio ADC with integrated programmable mic + bias, boost and input diagnostics. + + ti,pcm9211: 216-kHz digital audio converter With Stereo ADC and + Routing. + + ti,pcmd3140: Four-channel PDM-input to TDM or I2S output converter. + + ti,pcmd3180: Eight-channel pulse-density-modulation input to TDM or + I2S output converter. + + ti,taa5212: Low-power high-performance stereo audio ADC with 118-dB + dynamic range. + + ti,tad5212: Low-power stereo audio DAC with 120-dB dynamic range. + oneOf: + - items: + - enum: + - ti,adc3120 + - ti,adc5120 + - ti,pcm3120 + - ti,pcm5120 + - ti,pcm6120 + - const: ti,adc6120 + - items: + - enum: + - ti,pcmd512x + - ti,pcm9211 + - ti,taa5212 + - ti,tad5212 + - const: ti,adc6120 + - items: + - enum: + - ti,pcm3140 + - ti,pcm5140 + - ti,dix4192 + - ti,pcm6140 + - ti,pcm6260 + - const: ti,pcm6240 + - items: + - enum: + - ti,pcmd3140 + - ti,pcmd3180 + - ti,pcm1690 + - ti,taa5412 + - ti,tad5412 + - const: ti,pcm6240 + - enum: + - ti,adc6120 + - ti,pcm6240 + + reg: + description: + I2C address, in multiple pcmdevices case, all the i2c address + aggregate as one Audio Device to support multiple audio slots. + minItems: 1 + maxItems: 4 + + reset-gpios: + maxItems: 1 + + interrupts: + maxItems: 1 + description: + Invalid only for ti,pcm1690 because of no INT pin. + + '#sound-dai-cells': + const: 0 + +required: + - compatible + - reg + +allOf: + - $ref: dai-common.yaml# + - if: + properties: + compatible: + contains: + enum: + - ti,pcm1690 + then: + properties: + interrupts: false + +additionalProperties: false + +examples: + - | + #include + i2c { + /* example for two devices with interrupt support */ + #address-cells = <1>; + #size-cells = <0>; + pcm6240: audio-codec@48 { + compatible = "ti,pcm6240"; + reg = <0x48>, /* primary-device */ + <0x4b>; /* secondary-device */ + #sound-dai-cells = <0>; + reset-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>; + interrupt-parent = <&gpio1>; + interrupts = <15>; + }; + }; +... -- cgit v1.2.3 From ab371a026a1a4ad81817d82ba433c19934082894 Mon Sep 17 00:00:00 2001 From: Kartik Agarwala Date: Sun, 21 Apr 2024 09:01:31 +0530 Subject: ASoC: dt-bindings: mt2701-wm8960: Convert to dtschema Convert mt2701-wm890 bindings from text to dtschema. This is used by MediaTek mt7623a/n SoC. Signed-off-by: Kartik Agarwala Reviewed-by: Rob Herring (Arm) Link: https://lore.kernel.org/r/20240421033129.13076-1-agarwala.kartik@gmail.com Signed-off-by: Mark Brown --- .../bindings/sound/mediatek,mt2701-wm8960.yaml | 54 ++++++++++++++++++++++ .../devicetree/bindings/sound/mt2701-wm8960.txt | 24 ---------- 2 files changed, 54 insertions(+), 24 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml delete mode 100644 Documentation/devicetree/bindings/sound/mt2701-wm8960.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml new file mode 100644 index 000000000000..cf985461a995 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.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/mediatek,mt2701-wm8960.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek MT2701 with WM8960 CODEC + +maintainers: + - Kartik Agarwala + +properties: + compatible: + const: mediatek,mt2701-wm8960-machine + + mediatek,platform: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of MT2701 ASoC platform. + + 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. + + mediatek,audio-codec: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of the WM8960 audio codec. + +unevaluatedProperties: false + +required: + - compatible + - mediatek,platform + - audio-routing + - mediatek,audio-codec + - pinctrl-names + - pinctrl-0 + +examples: + - | + sound { + compatible = "mediatek,mt2701-wm8960-machine"; + mediatek,platform = <&afe>; + audio-routing = + "Headphone", "HP_L", + "Headphone", "HP_R", + "LINPUT1", "AMIC", + "RINPUT1", "AMIC"; + mediatek,audio-codec = <&wm8960>; + pinctrl-names = "default"; + pinctrl-0 = <&aud_pins_default>; + }; diff --git a/Documentation/devicetree/bindings/sound/mt2701-wm8960.txt b/Documentation/devicetree/bindings/sound/mt2701-wm8960.txt deleted file mode 100644 index 809b609ea9d0..000000000000 --- a/Documentation/devicetree/bindings/sound/mt2701-wm8960.txt +++ /dev/null @@ -1,24 +0,0 @@ -MT2701 with WM8960 CODEC - -Required properties: -- compatible: "mediatek,mt2701-wm8960-machine" -- mediatek,platform: the phandle of MT2701 ASoC platform -- audio-routing: a list of the connections between audio -- mediatek,audio-codec: the phandles of wm8960 codec -- pinctrl-names: Should contain only one value - "default" -- pinctrl-0: Should specify pin control groups used for this controller. - -Example: - - sound:sound { - compatible = "mediatek,mt2701-wm8960-machine"; - mediatek,platform = <&afe>; - audio-routing = - "Headphone", "HP_L", - "Headphone", "HP_R", - "LINPUT1", "AMIC", - "RINPUT1", "AMIC"; - mediatek,audio-codec = <&wm8960>; - pinctrl-names = "default"; - pinctrl-0 = <&aud_pins_default>; - }; -- cgit v1.2.3 From 701a22fd9ffaa409bbd45c2936870341b3ad9fdb Mon Sep 17 00:00:00 2001 From: Mohammad Shehar Yaar Tausif Date: Tue, 23 Apr 2024 17:27:47 +0530 Subject: ASoC: dt-bindings: tegra20-ac97: convert to dt schema Convert NVIDIA Tegra20 AC97 binding to DT schema. Change -gpio to -gpios in schema as "gpio" suffix is deprecated. Signed-off-by: Mohammad Shehar Yaar Tausif Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240423115749.15786-1-sheharyaar48@gmail.com Signed-off-by: Mark Brown --- .../bindings/sound/nvidia,tegra20-ac97.txt | 36 ---------- .../bindings/sound/nvidia,tegra20-ac97.yaml | 82 ++++++++++++++++++++++ 2 files changed, 82 insertions(+), 36 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt create mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt deleted file mode 100644 index eaf00102d92c..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt +++ /dev/null @@ -1,36 +0,0 @@ -NVIDIA Tegra 20 AC97 controller - -Required properties: -- compatible : "nvidia,tegra20-ac97" -- reg : Should contain AC97 controller registers location and length -- interrupts : Should contain AC97 interrupt -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the following entries: - - ac97 -- dmas : Must contain an entry for each entry in clock-names. - See ../dma/dma.txt for details. -- dma-names : Must include the following entries: - - rx - - tx -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. -- nvidia,codec-reset-gpio : The Tegra GPIO controller's phandle and the number - of the GPIO used to reset the external AC97 codec -- nvidia,codec-sync-gpio : The Tegra GPIO controller's phandle and the number - of the GPIO corresponding with the AC97 DAP _FS line - -Example: - -ac97@70002000 { - compatible = "nvidia,tegra20-ac97"; - reg = <0x70002000 0x200>; - interrupts = <0 81 0x04>; - nvidia,codec-reset-gpio = <&gpio 170 0>; - nvidia,codec-sync-gpio = <&gpio 120 0>; - clocks = <&tegra_car 3>; - resets = <&tegra_car 3>; - reset-names = "ac97"; - dmas = <&apbdma 12>, <&apbdma 12>; - dma-names = "rx", "tx"; -}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.yaml new file mode 100644 index 000000000000..4ea0a303d995 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra20-ac97.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra20 AC97 controller + +maintainers: + - Thierry Reding + - Jon Hunter + +properties: + compatible: + const: nvidia,tegra20-ac97 + + reg: + maxItems: 1 + + resets: + maxItems: 1 + + reset-names: + const: ac97 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + dmas: + maxItems: 2 + + dma-names: + items: + - const: rx + - const: tx + + nvidia,codec-reset-gpios: + description: Reset pin of external AC97 codec + maxItems: 1 + + nvidia,codec-sync-gpios: + description: AC97 DAP _FS line + maxItems: 1 + +required: + - compatible + - reg + - resets + - reset-names + - interrupts + - clocks + - dmas + - dma-names + - nvidia,codec-reset-gpios + - nvidia,codec-sync-gpios + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + #include + + ac97@70002000 { + compatible = "nvidia,tegra20-ac97"; + reg = <0x70002000 0x200>; + resets = <&tegra_car 3>; + reset-names = "ac97"; + interrupts = ; + clocks = <&tegra_car 3>; + dmas = <&apbdma 12>, <&apbdma 12>; + dma-names = "rx", "tx"; + nvidia,codec-reset-gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH>; + nvidia,codec-sync-gpios = <&gpio TEGRA_GPIO(P, 0) GPIO_ACTIVE_HIGH>; + }; +... -- cgit v1.2.3 From 466c8c46b4ba763435b2a787b7824d9f0fd3e76e Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 23 Apr 2024 14:19:26 +0200 Subject: ASoC: dt-bindings: renesas: Fix R-Car Gen4 SoC-specific compatibles make dtbs_check: arch/arm64/boot/dts/renesas/r8a779g0-white-hawk.dtb: sound@ec5a0000: compatible: 'oneOf' conditional failed, one must be fixed: ['renesas,rcar_sound-r8a779g0', 'renesas,rcar_sound-gen4'] is too short ... 'renesas,rcar_sound-r8a779h0' was expected The list of SoC-specific compatible values for R-Car Gen4 SoCs is mutually-exclusive, just like for other R-Car SoC generations, so it should use an enum. Fixes: d6e792ed7dd022a1 ("ASoC: dt-bindings: renesas: add R8A779H0 V4M") Signed-off-by: Geert Uytterhoeven Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/b3a6cf12c46b23a501b0d54c6892b969e2a55145.1713874657.git.geert+renesas@glider.be Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/renesas,rsnd.yaml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index b3da278cf141..07ec6247d9de 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -48,8 +48,9 @@ properties: - const: renesas,rcar_sound-gen3 # for Gen4 SoC - items: - - const: renesas,rcar_sound-r8a779g0 # R-Car V4H - - const: renesas,rcar_sound-r8a779h0 # R-Car V4M + - enum: + - renesas,rcar_sound-r8a779g0 # R-Car V4H + - renesas,rcar_sound-r8a779h0 # R-Car V4M - const: renesas,rcar_sound-gen4 # for Generic - enum: -- cgit v1.2.3 From 2da01ca3674c6e90dbeeda02168849e2ec877edc Mon Sep 17 00:00:00 2001 From: Shengjiu Wang Date: Thu, 25 Apr 2024 14:35:06 +0800 Subject: ASoC: dt-bindings: fsl,ssi: Convert to YAML Convert the fsl,ssi binding to YAML. Add below compatible strings which were not listed in document: fsl,imx50-ssi fsl,imx53-ssi fsl,imx25-ssi fsl,imx27-ssi fsl,imx6q-ssi fsl,imx6sl-ssi fsl,imx6sx-ssi Add below fsl,mode strings which were not listed. i2s-slave i2s-master lj-slave lj-master rj-slave rj-master Add 'ac97-gpios' property which were not listed. Then dtbs_check can pass. And remove the 'codec' description which should be in the 'codec' binding doc. Signed-off-by: Shengjiu Wang Reviewed-by: Rob Herring (Arm) Link: https://lore.kernel.org/r/1714026906-16723-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/fsl,ssi.txt | 87 --------- .../devicetree/bindings/sound/fsl,ssi.yaml | 194 +++++++++++++++++++++ 2 files changed, 194 insertions(+), 87 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/fsl,ssi.txt create mode 100644 Documentation/devicetree/bindings/sound/fsl,ssi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt deleted file mode 100644 index 7e15a85cecd2..000000000000 --- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt +++ /dev/null @@ -1,87 +0,0 @@ -Freescale Synchronous Serial Interface - -The SSI is a serial device that communicates with audio codecs. It can -be programmed in AC97, I2S, left-justified, or right-justified modes. - -Required properties: -- compatible: Compatible list, should contain one of the following - compatibles: - fsl,mpc8610-ssi - fsl,imx51-ssi - fsl,imx35-ssi - fsl,imx21-ssi -- cell-index: The SSI, <0> = SSI1, <1> = SSI2, and so on. -- reg: Offset and length of the register set for the device. -- interrupts: where a is the interrupt number and b is a - field that represents an encoding of the sense and - level information for the interrupt. This should be - encoded based on the information in section 2) - depending on the type of interrupt controller you - have. -- fsl,fifo-depth: The number of elements in the transmit and receive FIFOs. - This number is the maximum allowed value for SFCSR[TFWM0]. - - clocks: "ipg" - Required clock for the SSI unit - "baud" - Required clock for SSI master mode. Otherwise this - clock is not used - -Required are also ac97 link bindings if ac97 is used. See -Documentation/devicetree/bindings/sound/soc-ac97link.txt for the necessary -bindings. - -Optional properties: -- codec-handle: Phandle to a 'codec' node that defines an audio - codec connected to this SSI. This node is typically - a child of an I2C or other control node. -- fsl,fiq-stream-filter: Bool property. Disabled DMA and use FIQ instead to - filter the codec stream. This is necessary for some boards - where an incompatible codec is connected to this SSI, e.g. - on pca100 and pcm043. -- dmas: Generic dma devicetree binding as described in - Documentation/devicetree/bindings/dma/dma.txt. -- dma-names: Two dmas have to be defined, "tx" and "rx", if fsl,imx-fiq - is not defined. -- fsl,mode: The operating mode for the AC97 interface only. - "ac97-slave" - AC97 mode, SSI is clock slave - "ac97-master" - AC97 mode, SSI is clock master -- fsl,ssi-asynchronous: - If specified, the SSI is to be programmed in asynchronous - mode. In this mode, pins SRCK, STCK, SRFS, and STFS must - all be connected to valid signals. In synchronous mode, - SRCK and SRFS are ignored. Asynchronous mode allows - playback and capture to use different sample sizes and - sample rates. Some drivers may require that SRCK and STCK - be connected together, and SRFS and STFS be connected - together. This would still allow different sample sizes, - but not different sample rates. -- fsl,playback-dma: Phandle to a node for the DMA channel to use for - playback of audio. This is typically dictated by SOC - design. See the notes below. - Only used on Power Architecture. -- fsl,capture-dma: Phandle to a node for the DMA channel to use for - capture (recording) of audio. This is typically dictated - by SOC design. See the notes below. - Only used on Power Architecture. - -Child 'codec' node required properties: -- compatible: Compatible list, contains the name of the codec - -Child 'codec' node optional properties: -- clock-frequency: The frequency of the input clock, which typically comes - from an on-board dedicated oscillator. - -Notes on fsl,playback-dma and fsl,capture-dma: - -On SOCs that have an SSI, specific DMA channels are hard-wired for playback -and capture. On the MPC8610, for example, SSI1 must use DMA channel 0 for -playback and DMA channel 1 for capture. SSI2 must use DMA channel 2 for -playback and DMA channel 3 for capture. The developer can choose which -DMA controller to use, but the channels themselves are hard-wired. The -purpose of these two properties is to represent this hardware design. - -The device tree nodes for the DMA channels that are referenced by -"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with -"fsl,ssi-dma-channel". The SOC-specific compatible string (e.g. -"fsl,mpc8610-dma-channel") can remain. If these nodes are left as -"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA -drivers (fsldma) will attempt to use them, and it will conflict with the -sound drivers. diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.yaml b/Documentation/devicetree/bindings/sound/fsl,ssi.yaml new file mode 100644 index 000000000000..4ab10cd3b520 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,ssi.yaml @@ -0,0 +1,194 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,ssi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Synchronous Serial Interface + +maintainers: + - Shengjiu Wang + +description: + Notes on fsl,playback-dma and fsl,capture-dma + On SOCs that have an SSI, specific DMA channels are hard-wired for playback + and capture. On the MPC8610, for example, SSI1 must use DMA channel 0 for + playback and DMA channel 1 for capture. SSI2 must use DMA channel 2 for + playback and DMA channel 3 for capture. The developer can choose which + DMA controller to use, but the channels themselves are hard-wired. The + purpose of these two properties is to represent this hardware design. + + The device tree nodes for the DMA channels that are referenced by + "fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with + "fsl,ssi-dma-channel". The SOC-specific compatible string (e.g. + "fsl,mpc8610-dma-channel") can remain. If these nodes are left as + "fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA + drivers (fsldma) will attempt to use them, and it will conflict with the + sound drivers. + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,imx50-ssi + - fsl,imx53-ssi + - const: fsl,imx51-ssi + - const: fsl,imx21-ssi + - items: + - enum: + - fsl,imx25-ssi + - fsl,imx27-ssi + - fsl,imx35-ssi + - fsl,imx51-ssi + - const: fsl,imx21-ssi + - items: + - enum: + - fsl,imx6q-ssi + - fsl,imx6sl-ssi + - fsl,imx6sx-ssi + - const: fsl,imx51-ssi + - items: + - const: fsl,imx21-ssi + - items: + - const: fsl,mpc8610-ssi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: The ipg clock for register access + - description: clock for SSI master mode + minItems: 1 + + clock-names: + items: + - const: ipg + - const: baud + minItems: 1 + + dmas: + oneOf: + - items: + - description: DMA controller phandle and request line for RX + - description: DMA controller phandle and request line for TX + - items: + - description: DMA controller phandle and request line for RX0 + - description: DMA controller phandle and request line for TX0 + - description: DMA controller phandle and request line for RX1 + - description: DMA controller phandle and request line for TX1 + + dma-names: + oneOf: + - items: + - const: rx + - const: tx + - items: + - const: rx0 + - const: tx0 + - const: rx1 + - const: tx1 + + "#sound-dai-cells": + const: 0 + description: optional, some dts node didn't add it. + + cell-index: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + description: The SSI index + + ac97-gpios: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: Please refer to soc-ac97link.txt + + codec-handle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to a 'codec' node that defines an audio + codec connected to this SSI. This node is typically + a child of an I2C or other control node. + + fsl,fifo-depth: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The number of elements in the transmit and receive FIFOs. + This number is the maximum allowed value for SFCSR[TFWM0]. + enum: [8, 15] + + fsl,fiq-stream-filter: + type: boolean + description: + Disabled DMA and use FIQ instead to filter the codec stream. + This is necessary for some boards where an incompatible codec + is connected to this SSI, e.g. on pca100 and pcm043. + + fsl,mode: + $ref: /schemas/types.yaml#/definitions/string + enum: [ ac97-slave, ac97-master, i2s-slave, i2s-master, + lj-slave, lj-master, rj-slave, rj-master ] + description: | + "ac97-slave" - AC97 mode, SSI is clock slave + "ac97-master" - AC97 mode, SSI is clock master + "i2s-slave" - I2S mode, SSI is clock slave + "i2s-master" - I2S mode, SSI is clock master + "lj-slave" - Left justified mode, SSI is clock slave + "lj-master" - Left justified mode, SSI is clock master + "rj-slave" - Right justified mode, SSI is clock slave + "rj-master" - Right justified mode, SSI is clock master + + fsl,ssi-asynchronous: + type: boolean + description: If specified, the SSI is to be programmed in asynchronous + mode. In this mode, pins SRCK, STCK, SRFS, and STFS must + all be connected to valid signals. In synchronous mode, + SRCK and SRFS are ignored. Asynchronous mode allows + playback and capture to use different sample sizes and + sample rates. Some drivers may require that SRCK and STCK + be connected together, and SRFS and STFS be connected + together. This would still allow different sample sizes, + but not different sample rates. + + fsl,playback-dma: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to a node for the DMA channel to use for + playback of audio. This is typically dictated by SOC + design. Only used on Power Architecture. + + fsl,capture-dma: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to a node for the DMA channel to use for + capture (recording) of audio. This is typically dictated + by SOC design. Only used on Power Architecture. + +required: + - compatible + - reg + - interrupts + - fsl,fifo-depth + +allOf: + - $ref: dai-common.yaml# + +unevaluatedProperties: false + +examples: + - | + #include + #include + ssi@2028000 { + compatible = "fsl,imx6q-ssi", "fsl,imx51-ssi"; + reg = <0x02028000 0x4000>; + interrupts = ; + clocks = <&clks IMX6QDL_CLK_SSI1_IPG>, + <&clks IMX6QDL_CLK_SSI1>; + clock-names = "ipg", "baud"; + dmas = <&sdma 37 1 0>, <&sdma 38 1 0>; + dma-names = "rx", "tx"; + #sound-dai-cells = <0>; + fsl,fifo-depth = <15>; + }; -- cgit v1.2.3 From 534e0cd89baf74c22ca55b442fb4add8d844e272 Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Fri, 26 Apr 2024 18:56:34 +0200 Subject: ASoC: doc: dapm: fix typos Fix various typos. Reviewed-by: Alexandre Belloni Reviewed-by: Bagas Sanjaya Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20240426-dapm-docs-v2-1-87b07547eb5b@bootlin.com Signed-off-by: Mark Brown --- Documentation/sound/soc/dapm.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst index c3154ce6e1b2..59f65b181828 100644 --- a/Documentation/sound/soc/dapm.rst +++ b/Documentation/sound/soc/dapm.rst @@ -50,7 +50,7 @@ Stream domain All DAPM power switching decisions are made automatically by consulting an audio routing map of the whole machine. This map is specific to each machine and consists of the interconnections between every audio component (including -internal codec components). All audio components that effect power are called +internal codec components). All audio components that affect power are called widgets hereafter. @@ -221,7 +221,7 @@ when the Mic is inserted:-:: Codec (BIAS) Domain ------------------- -The codec bias power domain has no widgets and is handled by the codecs DAPM +The codec bias power domain has no widgets and is handled by the codec DAPM event handler. This handler is called when the codec powerstate is changed wrt to any stream event or by kernel PM events. @@ -236,7 +236,7 @@ a virtual widget - a widget with no control bits e.g. SND_SOC_DAPM_MIXER("AC97 Mixer", SND_SOC_NOPM, 0, 0, NULL, 0), -This can be used to merge to signal paths together in software. +This can be used to merge two signal paths together in software. After all the widgets have been defined, they can then be added to the DAPM subsystem individually with a call to snd_soc_dapm_new_control(). -- cgit v1.2.3 From eaf84bda623e0a034fe03b871addf7dc4f70dfff Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Fri, 26 Apr 2024 18:56:35 +0200 Subject: ASoC: doc: dapm: fix struct name struct snd_soc_codec_dai does not exist. Reviewed-by: Alexandre Belloni Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20240426-dapm-docs-v2-2-87b07547eb5b@bootlin.com Signed-off-by: Mark Brown --- Documentation/sound/soc/dapm.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst index 59f65b181828..68ef79f539f2 100644 --- a/Documentation/sound/soc/dapm.rst +++ b/Documentation/sound/soc/dapm.rst @@ -148,7 +148,7 @@ Stream widgets have the following format:- SND_SOC_DAPM_AIF_IN(name, stream, slot, reg, shift, invert) NOTE: the stream name must match the corresponding stream name in your codec -snd_soc_codec_dai. +snd_soc_dai_driver. e.g. stream widgets for HiFi playback and capture :: -- cgit v1.2.3 From 610277caa77f07997857ab2e31a073d8ad7ed090 Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Fri, 26 Apr 2024 18:56:36 +0200 Subject: ASoC: doc: dapm: minor rewording Slightly reword for better readability: replace "PM" -> "power management frameworks", add missing comma. Reviewed-by: Alexandre Belloni Reviewed-by: Bagas Sanjaya Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20240426-dapm-docs-v2-3-87b07547eb5b@bootlin.com Signed-off-by: Mark Brown --- Documentation/sound/soc/dapm.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst index 68ef79f539f2..479c010d2dac 100644 --- a/Documentation/sound/soc/dapm.rst +++ b/Documentation/sound/soc/dapm.rst @@ -7,8 +7,8 @@ Description Dynamic Audio Power Management (DAPM) is designed to allow portable Linux devices to use the minimum amount of power within the audio -subsystem at all times. It is independent of other kernel PM and as -such, can easily co-exist with the other PM systems. +subsystem at all times. It is independent of other kernel power +management frameworks and, as such, can easily co-exist with them. DAPM is also completely transparent to all user space applications as all power switching is done within the ASoC core. No code changes or -- cgit v1.2.3 From 3233a68fcb216a2d8615862841c1fca7a940fc5c Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Fri, 26 Apr 2024 18:56:37 +0200 Subject: ASoC: doc: dapm: remove dash after colon There is no need for a dash after colons. Also fix an incorrect ":-::" sequence. Reviewed-by: Alexandre Belloni Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20240426-dapm-docs-v2-4-87b07547eb5b@bootlin.com Signed-off-by: Mark Brown --- Documentation/sound/soc/dapm.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst index 479c010d2dac..be849879274d 100644 --- a/Documentation/sound/soc/dapm.rst +++ b/Documentation/sound/soc/dapm.rst @@ -20,7 +20,7 @@ DAPM spans the whole machine. It covers power control within the entire audio subsystem, this includes internal codec power blocks and machine level power systems. -There are 4 power domains within DAPM +There are 4 power domains within DAPM: Codec bias domain VREF, VMID (core codec and audio power) @@ -57,7 +57,7 @@ widgets hereafter. DAPM Widgets ============ -Audio DAPM widgets fall into a number of types:- +Audio DAPM widgets fall into a number of types: Mixer Mixes several analog signals into a single analog signal. @@ -141,7 +141,7 @@ Stream Widgets relate to the stream power domain and only consist of ADCs (analog to digital converters), DACs (digital to analog converters), AIF IN and AIF OUT. -Stream widgets have the following format:- +Stream widgets have the following format: :: SND_SOC_DAPM_DAC(name, stream name, reg, shift, invert), @@ -167,7 +167,7 @@ Path Domain Widgets ------------------- Path domain widgets have a ability to control or affect the audio signal or -audio paths within the audio subsystem. They have the following form:- +audio paths within the audio subsystem. They have the following form: :: SND_SOC_DAPM_PGA(name, reg, shift, invert, controls, num_controls) @@ -207,7 +207,7 @@ powered. e.g. A machine widget can have an optional call back. e.g. Jack connector widget for an external Mic that enables Mic Bias -when the Mic is inserted:-:: +when the Mic is inserted:: static int spitz_mic_bias(struct snd_soc_dapm_widget* w, int event) { @@ -271,7 +271,7 @@ connect the destination widget (wrt audio signal) with its source widgets. {"Output Mixer", "HiFi Playback Switch", "DAC"}, {"Output Mixer", "Mic Sidetone Switch", "Mic Bias"}, -So we have :- +So we have : * Destination Widget <=== Path Name <=== Source Widget, or * Sink, Path, Source, or @@ -280,7 +280,7 @@ So we have :- When there is no path name connecting widgets (e.g. a direct connection) we pass NULL for the path name. -Interconnections are created with a call to:- +Interconnections are created with a call to: :: snd_soc_dapm_connect_input(codec, sink, path, source); -- cgit v1.2.3 From 7d0e76107894377a14f211c85a821a53416d5ab2 Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Fri, 26 Apr 2024 18:56:39 +0200 Subject: ASoC: doc: dapm: replace "map" with "graph" DAPM is actually based on a graph, so use this specific term instead of the more generic "map". Reviewed-by: Alexandre Belloni Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20240426-dapm-docs-v2-6-87b07547eb5b@bootlin.com Signed-off-by: Mark Brown --- Documentation/sound/soc/dapm.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst index be849879274d..eb50400fa321 100644 --- a/Documentation/sound/soc/dapm.rst +++ b/Documentation/sound/soc/dapm.rst @@ -48,7 +48,7 @@ Stream domain stopped respectively. e.g. aplay, arecord. All DAPM power switching decisions are made automatically by consulting an audio -routing map of the whole machine. This map is specific to each machine and +routing graph of the whole machine. This graph is specific to each machine and consists of the interconnections between every audio component (including internal codec components). All audio components that affect power are called widgets hereafter. @@ -229,7 +229,7 @@ to any stream event or by kernel PM events. Virtual Widgets --------------- -Sometimes widgets exist in the codec or machine audio map that don't have any +Sometimes widgets exist in the codec or machine audio graph that don't have any corresponding soft power control. In this case it is necessary to create a virtual widget - a widget with no control bits e.g. :: @@ -247,7 +247,7 @@ Codec/DSP Widget Interconnections Widgets are connected to each other within the codec, platform and machine by audio paths (called interconnections). Each interconnection must be defined in -order to create a map of all audio paths between widgets. +order to create a graph of all audio paths between widgets. This is easiest with a diagram of the codec or DSP (and schematic of the machine audio system), as it requires joining widgets together via their audio signal -- cgit v1.2.3 From dd5f36e59134654f9fd7b39d4d66327a1a2db82d Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Fri, 26 Apr 2024 18:56:40 +0200 Subject: ASoC: doc: dapm: extend initial descrption Extend the initial description providing clearer definitions of "widget" and "route", and to stop using the word "component" to mean "widget". Give more details and clarify wording and add a picture representing a real DAPM graph. Group all the introductory paragraphs before the "DAPM power domains", and split the latter to a specific section. Reviewed-by: Alexandre Belloni Reviewed-by: Bagas Sanjaya Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20240426-dapm-docs-v2-7-87b07547eb5b@bootlin.com Signed-off-by: Mark Brown --- Documentation/sound/soc/dapm-graph.svg | 375 +++++++++++++++++++++++++++++++++ Documentation/sound/soc/dapm.rst | 30 ++- 2 files changed, 396 insertions(+), 9 deletions(-) create mode 100644 Documentation/sound/soc/dapm-graph.svg (limited to 'Documentation') diff --git a/Documentation/sound/soc/dapm-graph.svg b/Documentation/sound/soc/dapm-graph.svg new file mode 100644 index 000000000000..d783672db815 --- /dev/null +++ b/Documentation/sound/soc/dapm-graph.svg @@ -0,0 +1,375 @@ + + + + + + +G + + +ROOT + +ROOT + + +4000b000.audio-controller + +4000b000.audio-controller + + +cs42l51.0-004a + +cs42l51.0-004a + + +hdmi-audio-codec.1.auto + +hdmi-audio-codec.1.auto + + + +ROOT_Amplifier + +Amplifier +[out_drv] + + + +4000b000.audio-controller_capture + +capture +[dai_out] + + + +4000b000.audio-controller_playback + +playback +[dai_in] + + + +hdmi-audio-codec.1.auto_I2S Playback + +I2S Playback +[dai_in] + + + +4000b000.audio-controller_playback->hdmi-audio-codec.1.auto_I2S Playback + + + + + +hdmi-audio-codec.1.auto_Capture + +Capture +[dai_out] + + + +hdmi-audio-codec.1.auto_Capture->4000b000.audio-controller_capture + + + + + +cs42l51.0-004a_AIN1L + +AIN1L +[input] + + + +cs42l51.0-004a_PGA-ADC Mux Left + +PGA-ADC Mux Left +[mux] + + + +cs42l51.0-004a_AIN1L->cs42l51.0-004a_PGA-ADC Mux Left + + + + + +cs42l51.0-004a_AIN1R + +AIN1R +[input] + + + +cs42l51.0-004a_PGA-ADC Mux Right + +PGA-ADC Mux Right +[mux] + + + +cs42l51.0-004a_AIN1R->cs42l51.0-004a_PGA-ADC Mux Right + + + + + +cs42l51.0-004a_AIN2L + +AIN2L +[input] + + + +cs42l51.0-004a_AIN2R + +AIN2R +[input] + + + +cs42l51.0-004a_Capture + +Capture +[dai_out] + + + +cs42l51.0-004a_DAC Mux + +DAC Mux +[mux] + + + +cs42l51.0-004a_Left DAC + +Left DAC +[dac] + + + +cs42l51.0-004a_DAC Mux->cs42l51.0-004a_Left DAC + + + + + +cs42l51.0-004a_Right DAC + +Right DAC +[dac] + + + +cs42l51.0-004a_DAC Mux->cs42l51.0-004a_Right DAC + + + + + +cs42l51.0-004a_HPL + +HPL +[output] + + + +cs42l51.0-004a_HPR + +HPR +[output] + + + +cs42l51.0-004a_Left ADC + +Left ADC +[adc] + + + +cs42l51.0-004a_Left ADC->cs42l51.0-004a_Capture + + + + + +cs42l51.0-004a_Left DAC->cs42l51.0-004a_HPL + + + + + +cs42l51.0-004a_Left PGA + +Left PGA +[pga] + + + +cs42l51.0-004a_Left PGA->cs42l51.0-004a_Left ADC + + + + + +cs42l51.0-004a_MCLK + +MCLK +[supply] + + + +cs42l51.0-004a_MCLK->cs42l51.0-004a_Capture + + + + + +cs42l51.0-004a_Playback + +Playback +[dai_in] + + + +cs42l51.0-004a_MCLK->cs42l51.0-004a_Playback + + + + + +cs42l51.0-004a_MICL + +MICL +[input] + + + +cs42l51.0-004a_Mic Preamp Left + +Mic Preamp Left +[mixer] + + + +cs42l51.0-004a_MICL->cs42l51.0-004a_Mic Preamp Left + + + + + +cs42l51.0-004a_MICR + +MICR +[input] + + + +cs42l51.0-004a_Mic Preamp Right + +Mic Preamp Right +[mixer] + + + +cs42l51.0-004a_MICR->cs42l51.0-004a_Mic Preamp Right + + + + + +cs42l51.0-004a_Mic Bias + +Mic Bias +[supply] + + + +cs42l51.0-004a_Mic Bias->cs42l51.0-004a_MICL + + + + + +cs42l51.0-004a_PGA-ADC Mux Left->cs42l51.0-004a_Left PGA + + + + + +cs42l51.0-004a_Right PGA + +Right PGA +[pga] + + + +cs42l51.0-004a_PGA-ADC Mux Right->cs42l51.0-004a_Right PGA + + + + + +cs42l51.0-004a_Playback->cs42l51.0-004a_DAC Mux + + + + + +cs42l51.0-004a_Right ADC + +Right ADC +[adc] + + + +cs42l51.0-004a_Right ADC->cs42l51.0-004a_Capture + + + + + +cs42l51.0-004a_Right DAC->cs42l51.0-004a_HPR + + + + + +cs42l51.0-004a_Right PGA->cs42l51.0-004a_Right ADC + + + + + +hdmi-audio-codec.1.auto_TX + +TX +[output] + + + +hdmi-audio-codec.1.auto_I2S Playback->hdmi-audio-codec.1.auto_TX + + + + + +hdmi-audio-codec.1.auto_RX + +RX +[output] + + + +hdmi-audio-codec.1.auto_RX->hdmi-audio-codec.1.auto_Capture + + + + + diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst index eb50400fa321..8d741295fc40 100644 --- a/Documentation/sound/soc/dapm.rst +++ b/Documentation/sound/soc/dapm.rst @@ -16,9 +16,27 @@ recompiling are required for user space applications. DAPM makes power switching decisions based upon any audio stream (capture/playback) activity and audio mixer settings within the device. -DAPM spans the whole machine. It covers power control within the entire -audio subsystem, this includes internal codec power blocks and machine -level power systems. +DAPM is based on two basic elements, called widgets and routes: + + * a **widget** is every part of the audio hardware that can be enabled by + software when in use and disabled to save power when not in use + * a **route** is an interconnection between widgets that exists when sound + can flow from one widget to the other + +All DAPM power switching decisions are made automatically by consulting an +audio routing graph. This graph is specific to each sound card and spans +the whole sound card, so some DAPM routes connect two widgets belonging to +different components (e.g. the LINE OUT pin of a CODEC and the input pin of +an amplifier). + +The graph for the STM32MP1-DK1 sound card is shown in picture: + +.. kernel-figure:: dapm-graph.svg + :alt: Example DAPM graph + :align: center + +DAPM power domains +================== There are 4 power domains within DAPM: @@ -47,12 +65,6 @@ Stream domain Enabled and disabled when stream playback/capture is started and stopped respectively. e.g. aplay, arecord. -All DAPM power switching decisions are made automatically by consulting an audio -routing graph of the whole machine. This graph is specific to each machine and -consists of the interconnections between every audio component (including -internal codec components). All audio components that affect power are called -widgets hereafter. - DAPM Widgets ============ -- cgit v1.2.3 From 36de8c0e26793beeda1d6a7592f44b4551271469 Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Fri, 26 Apr 2024 18:56:41 +0200 Subject: ASoC: doc: dapm: describe how widgets and routes are registered The small paragraph describing how to register widgets is incomplete (does not mention routes) and mentions snd_soc_dapm_new_control() which is not really used. Moreover it appears as a part of the "Virtual Widgets" subsection. Replace it with a detailed and current description of how widgets and routes are registered, mentioning both static declaration and runtime registration. Also make this a section on its own. Reviewed-by: Alexandre Belloni Reviewed-by: Bagas Sanjaya Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20240426-dapm-docs-v2-8-87b07547eb5b@bootlin.com Signed-off-by: Mark Brown --- Documentation/sound/soc/dapm.rst | 38 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 36 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst index 8d741295fc40..57d96a39f124 100644 --- a/Documentation/sound/soc/dapm.rst +++ b/Documentation/sound/soc/dapm.rst @@ -250,8 +250,42 @@ a virtual widget - a widget with no control bits e.g. This can be used to merge two signal paths together in software. -After all the widgets have been defined, they can then be added to the DAPM -subsystem individually with a call to snd_soc_dapm_new_control(). +Registering DAPM controls +========================= + +In many cases the DAPM widgets implemented statically in a ``static const +struct snd_soc_dapm_widget`` array and the routes connecting them in a +``static const struct snd_soc_dapm_route`` array in a codec driver, and +simply declared via the ``dapm_widgets`` and ``num_dapm_widgets`` fields of +the ``struct snd_soc_component_driver`` so the driver registration will +take care of populating them:: + + static const struct snd_soc_dapm_widget wm2000_dapm_widgets[] = { + SND_SOC_DAPM_OUTPUT("SPKN"), + SND_SOC_DAPM_OUTPUT("SPKP"), + ... + }; + + /* Target, Path, Source */ + static const struct snd_soc_dapm_route wm2000_audio_map[] = { + { "SPKN", NULL, "ANC Engine" }, + { "SPKP", NULL, "ANC Engine" }, + ... + }; + + static const struct snd_soc_component_driver soc_component_dev_wm2000 = { + ... + .dapm_widgets = wm2000_dapm_widgets, + .num_dapm_widgets = ARRAY_SIZE(wm2000_dapm_widgets), + ... + }; + +In more complex cases the list of DAPM widgets and/or routes can be only +known at build time. This happens for example when a driver supports +different models having a different set of features. In those cases +separate widgets and routes arrays implementing the case-specific features +can be registered programmatically by calling snd_soc_dapm_new_controls() +and snd_soc_dapm_add_routes(). Codec/DSP Widget Interconnections -- cgit v1.2.3 From d40e82194423c9d058bdeff863373b7da9f7045b Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Fri, 26 Apr 2024 18:56:42 +0200 Subject: ASoC: doc: dapm: fix and improve section "Registering DAPM controls" Extend the first paragraph to mention the {,num_}dapm_routes fields just like the widget conterparts. Mention the route fields also in the code example. Fix "at build time", this really means "at probe time". Reviewed-by: Alexandre Belloni Reviewed-by: Bagas Sanjaya Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20240426-dapm-docs-v2-9-87b07547eb5b@bootlin.com Signed-off-by: Mark Brown --- Documentation/sound/soc/dapm.rst | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst index 57d96a39f124..50f908f4e8ed 100644 --- a/Documentation/sound/soc/dapm.rst +++ b/Documentation/sound/soc/dapm.rst @@ -253,12 +253,17 @@ This can be used to merge two signal paths together in software. Registering DAPM controls ========================= -In many cases the DAPM widgets implemented statically in a ``static const -struct snd_soc_dapm_widget`` array and the routes connecting them in a -``static const struct snd_soc_dapm_route`` array in a codec driver, and -simply declared via the ``dapm_widgets`` and ``num_dapm_widgets`` fields of -the ``struct snd_soc_component_driver`` so the driver registration will -take care of populating them:: +In many cases the DAPM widgets are implemented statically in a ``static +const struct snd_soc_dapm_widget`` array in a codec driver, and simply +declared via the ``dapm_widgets`` and ``num_dapm_widgets`` fields of the +``struct snd_soc_component_driver``. + +Similarly, routes connecting them are implemented statically in a ``static +const struct snd_soc_dapm_route`` array and declared via the +``dapm_routes`` and ``num_dapm_routes`` fields of the same struct. + +With the above declared, the driver registration will take care of +populating them:: static const struct snd_soc_dapm_widget wm2000_dapm_widgets[] = { SND_SOC_DAPM_OUTPUT("SPKN"), @@ -277,11 +282,13 @@ take care of populating them:: ... .dapm_widgets = wm2000_dapm_widgets, .num_dapm_widgets = ARRAY_SIZE(wm2000_dapm_widgets), + .dapm_routes = wm2000_audio_map, + .num_dapm_routes = ARRAY_SIZE(wm2000_audio_map), ... }; In more complex cases the list of DAPM widgets and/or routes can be only -known at build time. This happens for example when a driver supports +known at probe time. This happens for example when a driver supports different models having a different set of features. In those cases separate widgets and routes arrays implementing the case-specific features can be registered programmatically by calling snd_soc_dapm_new_controls() -- cgit v1.2.3 From 057acfb460d6792c7d3ec088f57c411fb0e4d395 Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Fri, 26 Apr 2024 18:56:43 +0200 Subject: ASoC: doc: dapm: improve section "Codec/DSP Widget Interconnections" Improve wording in a few places, cleanup ReST colon syntax, remove space before colon, and remove the "codec" parameter in the parentheses of snd_soc_dapm_new_widgets() (there should be no parameters in the docs, and that function takes a card, not a codec). Reviewed-by: Alexandre Belloni Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20240426-dapm-docs-v2-10-87b07547eb5b@bootlin.com Signed-off-by: Mark Brown --- Documentation/sound/soc/dapm.rst | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst index 50f908f4e8ed..8fccdb0d6454 100644 --- a/Documentation/sound/soc/dapm.rst +++ b/Documentation/sound/soc/dapm.rst @@ -306,25 +306,23 @@ This is easiest with a diagram of the codec or DSP (and schematic of the machine audio system), as it requires joining widgets together via their audio signal paths. -e.g., from the WM8731 output mixer (wm8731.c) - -The WM8731 output mixer has 3 inputs (sources) +For example the WM8731 output mixer (wm8731.c) has 3 inputs (sources): 1. Line Bypass Input 2. DAC (HiFi playback) 3. Mic Sidetone Input -Each input in this example has a kcontrol associated with it (defined in example -above) and is connected to the output mixer via its kcontrol name. We can now -connect the destination widget (wrt audio signal) with its source widgets. -:: +Each input in this example has a kcontrol associated with it (defined in +the example above) and is connected to the output mixer via its kcontrol +name. We can now connect the destination widget (wrt audio signal) with its +source widgets. :: /* output mixer */ {"Output Mixer", "Line Bypass Switch", "Line Input"}, {"Output Mixer", "HiFi Playback Switch", "DAC"}, {"Output Mixer", "Mic Sidetone Switch", "Mic Bias"}, -So we have : +So we have: * Destination Widget <=== Path Name <=== Source Widget, or * Sink, Path, Source, or @@ -333,12 +331,11 @@ So we have : When there is no path name connecting widgets (e.g. a direct connection) we pass NULL for the path name. -Interconnections are created with a call to: -:: +Interconnections are created with a call to:: snd_soc_dapm_connect_input(codec, sink, path, source); -Finally, snd_soc_dapm_new_widgets(codec) must be called after all widgets and +Finally, snd_soc_dapm_new_widgets() must be called after all widgets and interconnections have been registered with the core. This causes the core to scan the codec and machine so that the internal DAPM state matches the physical state of the machine. -- cgit v1.2.3 From ce5a4f101cd0dfbda391d4f1815222d82a9d8a5a Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Fri, 26 Apr 2024 18:56:44 +0200 Subject: ASoC: doc: dapm: update section "DAPM Widget Events" The example in this section is not in the kernel sources anymore. Replace it with an up to date code fragment. Reword the initial paragraph. Remove "Please" which is not standard practice in documentation. Reviewed-by: Alexandre Belloni Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20240426-dapm-docs-v2-11-87b07547eb5b@bootlin.com Signed-off-by: Mark Brown --- Documentation/sound/soc/dapm.rst | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst index 8fccdb0d6454..2a1cfa2eca83 100644 --- a/Documentation/sound/soc/dapm.rst +++ b/Documentation/sound/soc/dapm.rst @@ -376,23 +376,29 @@ jacks can also be switched OFF. DAPM Widget Events ================== -Some widgets can register their interest with the DAPM core in PM events. -e.g. A Speaker with an amplifier registers a widget so the amplifier can be -powered only when the spk is in use. -:: +Widgets needing to implement a more complex behaviour than what DAPM can do +can set a custom "event handler" by setting a function pointer. An example +is a power supply needing to enable a GPIO:: - /* turn speaker amplifier on/off depending on use */ - static int corgi_amp_event(struct snd_soc_dapm_widget *w, int event) + static int sof_es8316_speaker_power_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) { - gpio_set_value(CORGI_GPIO_APM_ON, SND_SOC_DAPM_EVENT_ON(event)); - return 0; + if (SND_SOC_DAPM_EVENT_ON(event)) + gpiod_set_value_cansleep(gpio_pa, true); + else + gpiod_set_value_cansleep(gpio_pa, false); + + return 0; } - /* corgi machine dapm widgets */ - static const struct snd_soc_dapm_widget wm8731_dapm_widgets = - SND_SOC_DAPM_SPK("Ext Spk", corgi_amp_event); + static const struct snd_soc_dapm_widget st_widgets[] = { + ... + SND_SOC_DAPM_SUPPLY("Speaker Power", SND_SOC_NOPM, 0, 0, + sof_es8316_speaker_power_event, + SND_SOC_DAPM_PRE_PMD | SND_SOC_DAPM_POST_PMU), + }; -Please see soc-dapm.h for all other widgets that support events. +See soc-dapm.h for all other widgets that support events. Event types -- cgit v1.2.3 From 4155a82f6af8068473cd66b55da56fd379835fb0 Mon Sep 17 00:00:00 2001 From: Luca Ceresoli Date: Fri, 26 Apr 2024 18:56:45 +0200 Subject: ASoC: doc: dapm: update event types Some new event types now exist, so update the code fragment. Reviewed-by: Alexandre Belloni Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20240426-dapm-docs-v2-12-87b07547eb5b@bootlin.com Signed-off-by: Mark Brown --- Documentation/sound/soc/dapm.rst | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst index 2a1cfa2eca83..14c4dc026e6b 100644 --- a/Documentation/sound/soc/dapm.rst +++ b/Documentation/sound/soc/dapm.rst @@ -404,13 +404,16 @@ See soc-dapm.h for all other widgets that support events. Event types ----------- -The following event types are supported by event widgets. -:: +The following event types are supported by event widgets:: /* dapm event types */ - #define SND_SOC_DAPM_PRE_PMU 0x1 /* before widget power up */ - #define SND_SOC_DAPM_POST_PMU 0x2 /* after widget power up */ - #define SND_SOC_DAPM_PRE_PMD 0x4 /* before widget power down */ - #define SND_SOC_DAPM_POST_PMD 0x8 /* after widget power down */ - #define SND_SOC_DAPM_PRE_REG 0x10 /* before audio path setup */ - #define SND_SOC_DAPM_POST_REG 0x20 /* after audio path setup */ + #define SND_SOC_DAPM_PRE_PMU 0x1 /* before widget power up */ + #define SND_SOC_DAPM_POST_PMU 0x2 /* after widget power up */ + #define SND_SOC_DAPM_PRE_PMD 0x4 /* before widget power down */ + #define SND_SOC_DAPM_POST_PMD 0x8 /* after widget power down */ + #define SND_SOC_DAPM_PRE_REG 0x10 /* before audio path setup */ + #define SND_SOC_DAPM_POST_REG 0x20 /* after audio path setup */ + #define SND_SOC_DAPM_WILL_PMU 0x40 /* called at start of sequence */ + #define SND_SOC_DAPM_WILL_PMD 0x80 /* called at start of sequence */ + #define SND_SOC_DAPM_PRE_POST_PMD (SND_SOC_DAPM_PRE_PMD | SND_SOC_DAPM_POST_PMD) + #define SND_SOC_DAPM_PRE_POST_PMU (SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMU) -- cgit v1.2.3 From 4a1baeefd1d5a955b5a55a75539244e03e623b0b Mon Sep 17 00:00:00 2001 From: Mohammad Shehar Yaar Tausif Date: Fri, 26 Apr 2024 22:33:18 +0530 Subject: ASoC: dt-bindings: tegra30-i2s: convert to dt schema Convert NVIDIA Tegra30 I2S binding to DT schema and add "clock-names" property used by multiple tegra i2s blocks in arch/arm64/boot/dts/nvidia/tegra132.dtsi. This is not a required property by the binding. Signed-off-by: Mohammad Shehar Yaar Tausif Reviewed-by: Rob Herring (Arm) Link: https://lore.kernel.org/r/20240426170322.36273-1-sheharyaar48@gmail.com Signed-off-by: Mark Brown --- .../bindings/sound/nvidia,tegra30-i2s.txt | 27 --------- .../bindings/sound/nvidia,tegra30-i2s.yaml | 67 ++++++++++++++++++++++ 2 files changed, 67 insertions(+), 27 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt create mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt deleted file mode 100644 index 38caa936f6f8..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt +++ /dev/null @@ -1,27 +0,0 @@ -NVIDIA Tegra30 I2S controller - -Required properties: -- compatible : For Tegra30, must contain "nvidia,tegra30-i2s". For Tegra124, - must contain "nvidia,tegra124-i2s". Otherwise, must contain - "nvidia,-i2s" plus at least one of the above, where is - tegra114 or tegra132. -- reg : Should contain I2S registers location and length -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the following entries: - - i2s -- nvidia,ahub-cif-ids : The list of AHUB CIF IDs for this port, rx (playback) - first, tx (capture) second. See nvidia,tegra30-ahub.txt for values. - -Example: - -i2s@70080300 { - compatible = "nvidia,tegra30-i2s"; - reg = <0x70080300 0x100>; - nvidia,ahub-cif-ids = <4 4>; - clocks = <&tegra_car 11>; - resets = <&tegra_car 11>; - reset-names = "i2s"; -}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.yaml new file mode 100644 index 000000000000..89c3c6414ab1 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra30-i2s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra30 I2S controller + +maintainers: + - Thierry Reding + - Jon Hunter + +properties: + compatible: + oneOf: + - enum: + - nvidia,tegra124-i2s + - nvidia,tegra30-i2s + - items: + - const: nvidia,tegra114-i2s + - const: nvidia,tegra30-i2s + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: i2s + + resets: + maxItems: 1 + + reset-names: + const: i2s + + nvidia,ahub-cif-ids: + description: list of AHUB CIF IDs + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: rx (playback) + - description: tx (capture) + +required: + - compatible + - reg + - clocks + - resets + - reset-names + - nvidia,ahub-cif-ids + +additionalProperties: false + +examples: + - | + #include + + i2s@70080300 { + compatible = "nvidia,tegra30-i2s"; + reg = <0x70080300 0x100>; + nvidia,ahub-cif-ids = <4 4>; + clocks = <&tegra_car TEGRA30_CLK_I2S0>; + resets = <&tegra_car 30>; + reset-names = "i2s"; + }; +... -- cgit v1.2.3