* Re: [PATCH v2 6/7] arm64: dts: qcom: shikra-cqm-cqs-evk-imx577-camera: Add DT overlay
From: Vladimir Zapolskiy @ 2026-06-12 8:10 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-6-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Shikra CQM and CQS are retail variants sharing the same PM4125 PMIC
> and identical camera supply rails. The only difference between them
> is the integrated modem on CQM, which does not affect camera hardware.
>
> Add a shared overlay for optional IMX577 integration via CSIPHY1,
> used by both CQM and CQS EVK boards.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 6 ++
> .../dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso | 70 ++++++++++++++++++++++
> arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 9 +++
> arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 9 +++
> 4 files changed, 94 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index a9e9d829fb962386b3975f345ec006504607130a..76b8f144983827f4905a72935e8d5291a227dc97 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -337,6 +337,12 @@ dtb-$(CONFIG_ARCH_QCOM) += sdx75-idp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += shikra-cqm-evk.dtb
> dtb-$(CONFIG_ARCH_QCOM) += shikra-cqs-evk.dtb
> dtb-$(CONFIG_ARCH_QCOM) += shikra-iqs-evk.dtb
> +
> +shikra-cqm-evk-imx577-camera-dtbs := shikra-cqm-evk.dtb shikra-cqm-cqs-evk-imx577-camera.dtbo
> +shikra-cqs-evk-imx577-camera-dtbs := shikra-cqs-evk.dtb shikra-cqm-cqs-evk-imx577-camera.dtbo
> +
> +dtb-$(CONFIG_ARCH_QCOM) += shikra-cqm-evk-imx577-camera.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += shikra-cqs-evk-imx577-camera.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm4250-oneplus-billie2.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm4450-qrd.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm6115-fxtec-pro1x.dtb
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso b/arch/arm64/boot/dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso
> new file mode 100644
> index 0000000000000000000000000000000000000000..e3dad7c81e5e8aeb1061c784b5b893965f914a6f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso
> @@ -0,0 +1,70 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/clock/qcom,shikra-gcc.h>
> +#include <dt-bindings/gpio/gpio.h>
> +
> +&camss {
> + vdd-csiphy-1p2-supply = <&pm4125_l5>;
> + vdd-csiphy-1p8-supply = <&pm4125_l13>;
> +
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + csiphy1_ep: endpoint {
> + data-lanes = <0 1 2 3>;
> + remote-endpoint = <&imx577_ep1>;
> + };
> + };
> + };
> +};
> +
> +&cci {
> + status = "okay";
> +};
> +
> +&cci_i2c1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + camera@1a {
> + compatible = "sony,imx577";
> + reg = <0x1a>;
> +
> + reset-gpios = <&tlmm 33 GPIO_ACTIVE_LOW>;
> + pinctrl-0 = <&cam_mclk1_default &cam1_reset_default>;
> + pinctrl-names = "default";
> +
> + clocks = <&gcc GCC_CAMSS_MCLK1_CLK>;
> + assigned-clocks = <&gcc GCC_CAMSS_MCLK1_CLK>;
> + assigned-clock-rates = <24000000>;
> +
> + /*
> + * avdd and dvdd are supplied by on-board regulators on the
> + * IMX577 module from the connector's 3.3 V rail; they are
> + * not SoC-controlled. dovdd (1.8 V) powers the carrier board
> + * level-shifter that translates CCI I2C and reset lines
> + * between the SoC and the connector.
> + */
> + dovdd-supply = <&pm4125_l15>;
> +
> + port {
> + imx577_ep1: endpoint {
> + link-frequencies = /bits/ 64 <600000000>;
> + data-lanes = <0 1 2 3>;
The numeration of data-lanes shall be started from 1, this has to be fixed.
> + remote-endpoint = <&csiphy1_ep>;
> + };
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> index 0a52ab9b7a4c34d371f5ac23efe59d1c9d2723f4..0d5c3e31b1f613157d4d2ec6947c630f1031b73b 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> @@ -38,3 +38,12 @@ &sdhc_1 {
>
> status = "okay";
> };
> +
> +&tlmm {
> + cam1_reset_default: cam1-reset-default-state {
> + pins = "gpio33";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
Since it's a mezzanine specific pinctl assignment, it shall go to the
correspondent .dtso file.
It's a concidence that one .dtso file is good enough for describing the
mezzanine for two diffferent boards, but let's exploit it by keeping one
dt overlay file as it is now.
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> index b3f19a64d7aed3121ef092df684b19a4de39b497..515af370ca014a668dc035ff944fb82b6e09ceeb 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> @@ -38,3 +38,12 @@ &sdhc_1 {
>
> status = "okay";
> };
> +
> +&tlmm {
> + cam1_reset_default: cam1-reset-default-state {
> + pins = "gpio33";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 0/2] Add support for the QMP PCIe PHYs in Qualcomm IPQ9650
From: Kathiravan Thirumoorthy @ 2026-06-12 8:08 UTC (permalink / raw)
To: Vinod Koul
Cc: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <8a0e9314-0c97-48c8-be95-986c7e6fe641@oss.qualcomm.com>
On 6/11/2026 9:52 PM, Kathiravan Thirumoorthy wrote:
>
> On 6/11/2026 4:45 PM, Vinod Koul wrote:
>> On 02-06-26, 14:40, Kathiravan Thirumoorthy wrote:
>>> Qualcomm's IPQ9650 SoC has 3 Gen3 dual lane and 2 Gen3 single lane
>>> controllers with the QMP PHYs. Unlike the PHYs in the other IPQ SoC,
>>> refgen supply is needed to bringup the PHYs. Both single and dual lane
>>> shares the same HW init sequence. So reuse the tables.
>>>
>>> Document the compatible along with refgen supply and add the phy driver
>>> support for it.
>> Please rebase this on phy-next tomorrow. It does not apply for me due to
>> changes applied ealier today
>
> There is a discussion open about the supplies[1]. Once that is
> clarified, let me re spin. So we can take up this series for v7.3 once
> that discussion is closed.
>
> [1]
> https://lore.kernel.org/linux-arm-msm/aiqYtowP2DQt7Jw0@vaman/T/#m37a571fac0c77fd00f6379ad9a2414b60431820b
>
Discussion is concluded and I have sent the V2[1] on top of phy-next
(2ace2e949979 ("phy: rockchip: inno-usb2: Add missing clkout_ctl_phy
kerneldoc")). Please take a look at it.
[1]
https://lore.kernel.org/linux-arm-msm/20260612-ipq9650_pcie_phy-v2-0-b938cc2fc267@qti.qualcomm.com/#t
^ permalink raw reply
* [PATCH 2/2] ARM: dts: renesas: r9a06g032-rzn1d400-eb: Enable SPI-FRAM
From: Wolfram Sang @ 2026-06-12 8:03 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Wolfram Sang, Geert Uytterhoeven, Magnus Damm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260612080354.57459-4-wsa+renesas@sang-engineering.com>
Activate the FRAM and the SPI bus which it is attached to.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
.../dts/renesas/r9a06g032-rzn1d400-eb.dts | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts b/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts
index 97a339b30d76..ead379988fb1 100644
--- a/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts
+++ b/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts
@@ -53,6 +53,10 @@ led@1 {
};
};
+&gpio2 {
+ status = "okay";
+};
+
&i2c2 {
/* Sensors are different across revisions. All are LM75B compatible */
sensor@49 {
@@ -152,6 +156,13 @@ pins_sdio1_clk: pins-sdio1-clk {
drive-strength = <12>;
};
+ pins_spi1: pins-spi1 {
+ pinmux = <RZN1_PINMUX(156, RZN1_FUNC_SPI0_M)>,
+ <RZN1_PINMUX(157, RZN1_FUNC_SPI0_M)>,
+ <RZN1_PINMUX(158, RZN1_FUNC_SPI0_M)>,
+ <RZN1_PINMUX(159, RZN1_FUNC_GPIO)>;
+ };
+
pins_uart2: pins-uart2 {
pinmux = <RZN1_PINMUX(105, RZN1_FUNC_UART2)>,
<RZN1_PINMUX(106, RZN1_FUNC_UART2)>,
@@ -168,6 +179,20 @@ &sdio1 {
status = "okay";
};
+&spi1 {
+ pinctrl-0 = <&pins_spi1>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ cs-gpios = <&gpio2a 31 GPIO_ACTIVE_LOW>;
+
+ fram: fram@0 {
+ compatible = "cypress,fm25", "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <12500000>;
+ };
+};
+
&switch {
pinctrl-0 = <&pins_eth1>, <&pins_eth2>, <&pins_eth3>, <&pins_eth4>,
<&pins_mdio1>;
--
2.47.3
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: renesas: r9a06g032: Describe SPI controllers
From: Wolfram Sang @ 2026-06-12 8:03 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Wolfram Sang, Geert Uytterhoeven, Magnus Damm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260612080354.57459-4-wsa+renesas@sang-engineering.com>
Add nodes for the 6 SPI controllers of the Renesas RZ/N1D SoC. The first
4 can only be controllers, the latter 2 can only be targets. DMA nodes
are not added yet because DMA needs some extra code in the drivers and
cannot be tested yet. Basic FIFO mode works reliably, though.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
arch/arm/boot/dts/renesas/r9a06g032.dtsi | 90 ++++++++++++++++++++++++
1 file changed, 90 insertions(+)
diff --git a/arch/arm/boot/dts/renesas/r9a06g032.dtsi b/arch/arm/boot/dts/renesas/r9a06g032.dtsi
index 442ea26b40f5..e5c76b38a58e 100644
--- a/arch/arm/boot/dts/renesas/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/renesas/r9a06g032.dtsi
@@ -563,6 +563,96 @@ gic: interrupt-controller@44101000 {
<GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
};
+ /* Controller only */
+ spi1: spi@50005000 {
+ compatible = "renesas,r9a06g032-spi", "renesas,rzn1-spi";
+ reg = <0x50005000 0x200>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl R9A06G032_CLK_SPI0>, <&sysctrl R9A06G032_HCLK_SPI0>;
+ clock-names = "ssi_clk", "pclk";
+ power-domains = <&sysctrl>;
+ spi-max-frequency = <12500000>;
+ num-cs = <4>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ /* Controller only */
+ spi2: spi@50006000 {
+ compatible = "renesas,r9a06g032-spi", "renesas,rzn1-spi";
+ reg = <0x50006000 0x200>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl R9A06G032_CLK_SPI1>, <&sysctrl R9A06G032_HCLK_SPI1>;
+ clock-names = "ssi_clk", "pclk";
+ power-domains = <&sysctrl>;
+ spi-max-frequency = <12500000>;
+ num-cs = <4>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ /* Controller only */
+ spi3: spi@50007000 {
+ compatible = "renesas,r9a06g032-spi", "renesas,rzn1-spi";
+ reg = <0x50007000 0x200>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl R9A06G032_CLK_SPI2>, <&sysctrl R9A06G032_HCLK_SPI2>;
+ clock-names = "ssi_clk", "pclk";
+ power-domains = <&sysctrl>;
+ spi-max-frequency = <12500000>;
+ num-cs = <4>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ /* Controller only */
+ spi4: spi@50008000 {
+ compatible = "renesas,r9a06g032-spi", "renesas,rzn1-spi";
+ reg = <0x50008000 0x200>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl R9A06G032_CLK_SPI3>, <&sysctrl R9A06G032_HCLK_SPI3>;
+ clock-names = "ssi_clk", "pclk";
+ power-domains = <&sysctrl>;
+ spi-max-frequency = <12500000>;
+ num-cs = <4>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ /* Target only */
+ spi5: spi@50009000 {
+ compatible = "renesas,r9a06g032-spi", "renesas,rzn1-spi";
+ reg = <0x50009000 0x200>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl R9A06G032_CLK_SPI4>, <&sysctrl R9A06G032_HCLK_SPI4>;
+ clock-names = "ssi_clk", "pclk";
+ power-domains = <&sysctrl>;
+ spi-max-frequency = <12500000>;
+ num-cs = <1>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ /* Target only */
+ spi6: spi@5000a000 {
+ compatible = "renesas,r9a06g032-spi", "renesas,rzn1-spi";
+ reg = <0x5000a000 0x200>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl R9A06G032_CLK_SPI5>, <&sysctrl R9A06G032_HCLK_SPI5>;
+ clock-names = "ssi_clk", "pclk";
+ power-domains = <&sysctrl>;
+ spi-max-frequency = <12500000>;
+ num-cs = <1>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
/*
* The GPIO mapping to the corresponding pins is not obvious.
* See the hardware documentation for details.
--
2.47.3
^ permalink raw reply related
* [PATCH 0/2] ARM: dts: renesas: r9a06g032-rzn1d400-eb: Enable SPI and FRAM
From: Wolfram Sang @ 2026-06-12 8:03 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Wolfram Sang, Conor Dooley, devicetree, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring
Here are the patches to enable the SPI-FRAM with FIFO (no DMA yet, needs
more work) on the RZ/N1D Extension board.
Wolfram Sang (2):
ARM: dts: renesas: r9a06g032: Describe SPI controllers
ARM: dts: renesas: r9a06g032-rzn1d400-eb: Enable SPI-FRAM
.../dts/renesas/r9a06g032-rzn1d400-eb.dts | 25 ++++++
arch/arm/boot/dts/renesas/r9a06g032.dtsi | 90 +++++++++++++++++++
2 files changed, 115 insertions(+)
--
2.47.3
^ permalink raw reply
* Re: [PATCH v4 01/16] dt-bindings: riscv: sort multi-letter Z extensions alphanumerically
From: Conor Dooley @ 2026-06-12 8:02 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto, linux-doc, linux-riscv,
linux-kernel, kvm, kvm-riscv, Paul Walmsley, Conor Dooley,
devicetree, spacemit, sophgo, linux-kselftest, Palmer Dabbelt
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-1-3f01a2449488@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 494 bytes --]
On Thu, Jun 11, 2026 at 04:12:38PM -0400, Guodong Xu wrote:
> The multi-letter extension enum is documented as being sorted
> alphanumerically (see the "multi-letter extensions, sorted
> alphanumerically" comment), but several Z entries have drifted out of
> order.
>
> Reorder the affected entries so the multi-letter Z list is sorted
> alphanumerically again.
>
> Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: na
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/7] arm64: dts: qcom: shikra: Add pin configuration for mclks
From: Vladimir Zapolskiy @ 2026-06-12 8:02 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-5-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Add pinctrl configuration for the four available camera master clocks.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index fed71131491ebf6e261bfcd14b5d4a2624837878..2f0f7710c2897e140495afd8d4e8bde50f356096 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -380,6 +380,34 @@ cci_i2c1_sleep: cci-i2c1-sleep-state {
> bias-pull-down;
> };
>
> + cam_mclk0_default: cam-mclk0-default-state {
> + pins = "gpio34";
> + function = "cam_mclk";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + cam_mclk1_default: cam-mclk1-default-state {
> + pins = "gpio35";
> + function = "cam_mclk";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + cam_mclk2_default: cam-mclk2-default-state {
> + pins = "gpio96";
> + function = "cam_mclk";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + cam_mclk3_default: cam-mclk3-default-state {
> + pins = "gpio98";
> + function = "cam_mclk";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> qup_uart0_default: qup-uart0-default-state {
> pins = "gpio0", "gpio1";
> function = "qup0_se0";
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 4/7] arm64: dts: qcom: shikra: Add CCI definitions
From: Vladimir Zapolskiy @ 2026-06-12 8:01 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-4-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Qualcomm Shikra SoC has one Camera Control Interface (CCI)
> containing two I2C hosts.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 70 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index b93ce4a92a998ea5d9d4268d2fd46030fafc4084..fed71131491ebf6e261bfcd14b5d4a2624837878 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -348,6 +348,38 @@ tlmm: pinctrl@500000 {
> gpio-ranges = <&tlmm 0 0 165>;
> wakeup-parent = <&mpm>;
>
> + cci_i2c0_default: cci-i2c0-default-state {
> + /* SDA, SCL */
> + pins = "gpio36", "gpio37";
> + function = "cci_i2c0";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
> +
> + cci_i2c0_sleep: cci-i2c0-sleep-state {
> + /* SDA, SCL */
> + pins = "gpio36", "gpio37";
> + function = "cci_i2c0";
> + drive-strength = <2>;
> + bias-pull-down;
> + };
> +
> + cci_i2c1_default: cci-i2c1-default-state {
> + /* SDA, SCL */
> + pins = "gpio41", "gpio42";
> + function = "cci_i2c1";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
> +
> + cci_i2c1_sleep: cci-i2c1-sleep-state {
> + /* SDA, SCL */
> + pins = "gpio41", "gpio42";
> + function = "cci_i2c1";
> + drive-strength = <2>;
> + bias-pull-down;
> + };
> +
> qup_uart0_default: qup-uart0-default-state {
> pins = "gpio0", "gpio1";
> function = "qup0_se0";
> @@ -701,6 +733,44 @@ port@1 {
> reg = <1>;
> };
> };
> +
> + };
> +
> + cci: cci@5c1b000 {
> + compatible = "qcom,shikra-cci", "qcom,msm8996-cci";
> + reg = <0x0 0x05c1b000 0x0 0x1000>;
> +
> + interrupts = <GIC_SPI 206 IRQ_TYPE_EDGE_RISING 0>;
> +
> + clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
> + <&gcc GCC_CAMSS_CCI_0_CLK>;
> + clock-names = "ahb",
> + "cci";
> +
> + power-domains = <&gcc GCC_CAMSS_TOP_GDSC>;
> +
> + pinctrl-0 = <&cci_i2c0_default &cci_i2c1_default>;
> + pinctrl-1 = <&cci_i2c0_sleep &cci_i2c1_sleep>;
> + pinctrl-names = "default", "sleep";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + status = "disabled";
> +
> + cci_i2c0: i2c-bus@0 {
> + reg = <0>;
> + clock-frequency = <400000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + cci_i2c1: i2c-bus@1 {
> + reg = <1>;
> + clock-frequency = <400000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> };
>
> qupv3_0: geniqup@4ac0000 {
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: Add support for Shikra
From: Dmitry Baryshkov @ 2026-06-12 8:00 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Krishna Kurapati, Krzysztof Kozlowski, Neil Armstrong, Vinod Koul,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Xiangxu Yin, Johan Hovold, Loic Poulain, Kathiravan Thirumoorthy,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <0947e485-4619-43a3-a127-5b887780190b@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 03:36:20PM +0200, Konrad Dybcio wrote:
> On 5/17/26 9:16 PM, Dmitry Baryshkov wrote:
> > On Fri, May 15, 2026 at 09:06:21PM +0530, Krishna Kurapati wrote:
> >>
> >>
> >> On 5/14/2026 8:07 PM, Krzysztof Kozlowski wrote:
> >>> On 14/05/2026 08:22, Krishna Kurapati wrote:
> >>>>
> >>>>
> >>>> On 5/14/2026 12:26 AM, Krzysztof Kozlowski wrote:
> >>>>> On 07/05/2026 13:37, Krishna Kurapati wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 5/5/2026 7:30 PM, Krzysztof Kozlowski wrote:
> >>>>>>> On 05/05/2026 15:57, Krishna Kurapati wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 5/5/2026 6:59 PM, Krzysztof Kozlowski wrote:
> >>>>>>>>> On 05/05/2026 15:27, Krishna Kurapati wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 5/5/2026 4:22 PM, Krzysztof Kozlowski wrote:
> >>>>>>>>>>> On 05/05/2026 12:49, Krzysztof Kozlowski wrote:
> >>>>>>>>>>>> On Mon, May 04, 2026 at 10:36:57PM +0530, Krishna Kurapati wrote:
> >>>>>>>>>>>>> Declare the USB-C QMP PHY present on the Qualcomm Shikra platform.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>> .../devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml | 2 ++
> >>>>>>>>>>>>> 1 file changed, 2 insertions(+)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> >>>>>>>>>>>
> >>>>>>>>>>> ... and then I looked at the driver. So un-reviewed. Devices are clearly
> >>>>>>>>>>> compatible. If not, explain what is not compatible.
> >>>>>>>>>>>
> >>>>>>>>>> Talos uses GCC_USB3_PRIM_PHY_AUX_CLK.
> >>>>>>>>>>
> >>>>>>>>>> In Shikra, we are using GCC_USB3_PRIM_PHY_COM_AUX_CLK. We don't have
> >>>>>>>>>> GCC_USB3_PRIM_PHY_AUX_CLK.
> >>>>>>>>>>
> >>>>>>>>>> Hence, I didn't use a fallback compatible.
> >>>>>>>>>
> >>>>>>>>> This still explains nothing. How different clock makes interface for SW
> >>>>>>>>> incompatible exactly?
> >>>>>>>>>
> >>>>>>>> So I went by the naming. AUX vs COM_AUX.
> >>>>>>>
> >>>>>>> The naming does not matter. If the clock is called
> >>>>>>> "no_one_expects_spanish_inquisition", does that make software
> >>>>>>> incompatible? Why would the name itself matter?
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Can I use a fallback compatible and in DT vote for "COM_AUX" clock with
> >>>>>>>> clock-names mentioning "aux" ?
> >>>>>>>
> >>>>>>> I don't know, I asked what is different in software interface.
> >>>>>>>
> >>>>>>
> >>>>>> Hi Krzysztof,
> >>>>>>
> >>>>>> I checked with the hw team here and found out two things.
> >>>>>>
> >>>>>> 1. Shikra is a spinoff of Agatti and its sw interface (clocks used and
> >>>>>> regulators used) is the same as agatti.
> >>>>>>
> >>>>>> 2. I thought we could use qcm2290 as a fallback since the phy register
> >>>>>> init sequence is the same for Talos/Shikra/Agatti. The difference
> >>>>>> between Talos and agatti when checked in the driver was the init load
> >>>>>> settings. I checked with the hw team and they suggested using the init
> >>>>>> load settings which talos was using.
> >>>>>>
> >>>>>> Hence both these compatibles (qcm2290 and qcs615) cannot be used as
> >>>>>> fallback for Shikra.
> >>>>>
> >>>>> Then I do not understand why you are using qcs615_usb3phy_cfg for
> >>>>> Shikra. You say that the initialization is different, but you use
> >>>>> exactly the same initialization. So in a meaning of compatibility
> >>>>> between hardware for Devicetree they are compatible.
> >>>>>
> >>>> Hi Krzysztof,
> >>>>
> >>>> There are 3 things:
> >>>>
> >>>> 1. Clocks used:
> >>>> -> Talos supports AUX Clock since it supports DP over USB.
> >>>> -> Agatti and Shikra use COM_AUX clock since they dont support DP over USB.
> >>>>
> >>>> 2. Phy register Init sequence - same for all 3 targets
> >>>>
> >>>> 3. Regulator init load:
> >>>> -> Different for both Talos and Agatti
> >>>> -> Recommendation is to use Talos regulator load values.
> >>>>
> >>>> SW interface wise, shikra is comaptible with agatti. If we use agatti as
> >>>> fallback, we would end up using the platform data of Agatti where the
> >>>> regulator init load is not suitable for Shikra. Hence not using Agatti
> >>>> as fallback.
> >>>>
> >>>> Coming to driver changes, I used qcs615_cfg because it has required phy
> >>>> register sequence and regulator init load as needed by shikra.
> >>>
> >>> So is it compatible with QCS615? If not, then something is incomplete or
> >>> confusing. The driver uses the same software interface.
> >>>
> >> Sorry for the confusion. The Talos compatible represents the USB/DP PHY with
> >> aux clock input, while Shikra is a USB-only PHY with com_aux input clock, so
> >> the two PHYs are not compatible with each other.
> >
> > According to the memory map, there is an (unused) DP registers part
> > right after the QMP USB3 PHY. So, sofware-wise it is compatible to
> > Talos. Having the different clock input means different integration of
> > the block rather than the differences in the hardware block.
> >
> > So, the block should be compatible to qcom,qcs615-qmp-usb3-dp-phy
>
> It should still carry its own compatible though, to let the driver
> disallow powering up the DP part
Why? The DP part is there, in the PHY, pretty much like it's present on
most of USBC platforms. I assume it can be powered on. There is no
point in it though as there is no DP controller (nor DP pins).
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: sm8650-ayaneo-pocket-s2: switch sound card to ayaneo,pocket-s2-sndcard
From: Neil Armstrong @ 2026-06-12 7:59 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, kancy2333, linux-sound,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <tkgqorjdnvwcx4ddgi5m7j3g6wlawxnm5ugty6y33ftwxzbvv5@uxcai2sgglfs>
On 6/12/26 09:57, Dmitry Baryshkov wrote:
> On Wed, Jun 10, 2026 at 09:41:47AM +0200, Neil Armstrong wrote:
>> Switch to the ayaneo,pocket-s2-sndcard since the hardware layout
>> is incompatible with the default SM8650 generic sound card.
>
> Incompatible, how?
As explained on the cover letter, the WAS speakers are not connected
on the same lines as the other devices handled by this card.
Neil
>
>>
>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>> ---
>> arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
>> index 0dc994f4e48d..508d1445bf21 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
>> +++ b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
>> @@ -221,7 +221,7 @@ upd720201_vdd33_reg: upd720201-vdd33-regulator {
>> };
>>
>> sound {
>> - compatible = "qcom,sm8650-sndcard", "qcom,sm8450-sndcard";
>> + compatible = "ayaneo,pocket-s2-sndcard";
>> model = "SM8650-APS2";
>> audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT",
>> "SpkrRight IN", "WSA_SPK2 OUT",
>>
>> --
>> 2.34.1
>>
>
^ permalink raw reply
* Re: [PATCH v4 2/8] dt-bindings: net: wireless: qcom,ath10k: Document NVMEM cells
From: Loic Poulain @ 2026-06-12 7:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan, linux-mmc, devicetree,
linux-kernel, linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel, Bartosz Golaszewski
In-Reply-To: <20260610-funny-paper-warthog-25fa0a@quoll>
On Wed, Jun 10, 2026 at 9:16 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Tue, Jun 09, 2026 at 09:52:27AM +0200, Loic Poulain wrote:
> > Document the NVMEM cells supported by the ath10k driver, the
> > mac-address, pre-calibration data, and calibration data.
> >
> > Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> > ---
> > .../devicetree/bindings/net/wireless/qcom,ath10k.yaml | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> > index c21d66c7cd558ab792524be9afec8b79272d1c87..7391df5e7071e626af4c64b9919d48c41ac09f1e 100644
> > --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> > @@ -92,6 +92,22 @@ properties:
> >
> > ieee80211-freq-limit: true
> >
> > + nvmem-cells:
> > + minItems: 1
> > + maxItems: 3
> > + description: |
>
> If there is going to be resend:
> Do not need '|' unless you need to preserve formatting.
Sure, thanks.
>
> > + References to nvmem cells for MAC address and/or calibration data.
> > + Supported cell names are mac-address, calibration, and pre-calibration.
> > +
> > + nvmem-cell-names:
> > + minItems: 1
> > + maxItems: 3
> > + items:
> > + enum:
> > + - mac-address
> > + - calibration
> > + - pre-calibration
>
> This means you expect random order with variable number of items. Is
> that intentional? If yes, please provide short explanation in the commit
> msg.
Yes we may or may have any of those cells. Will document.
Thanks,
Loic
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: sm8650-ayaneo-pocket-s2: switch sound card to ayaneo,pocket-s2-sndcard
From: Dmitry Baryshkov @ 2026-06-12 7:57 UTC (permalink / raw)
To: Neil Armstrong
Cc: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, kancy2333, linux-sound,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260610-topic-sm8650-ayaneo-pocket-s2-wsa2-fix-v1-3-18bb19c5ca22@linaro.org>
On Wed, Jun 10, 2026 at 09:41:47AM +0200, Neil Armstrong wrote:
> Switch to the ayaneo,pocket-s2-sndcard since the hardware layout
> is incompatible with the default SM8650 generic sound card.
Incompatible, how?
>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
> index 0dc994f4e48d..508d1445bf21 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
> @@ -221,7 +221,7 @@ upd720201_vdd33_reg: upd720201-vdd33-regulator {
> };
>
> sound {
> - compatible = "qcom,sm8650-sndcard", "qcom,sm8450-sndcard";
> + compatible = "ayaneo,pocket-s2-sndcard";
> model = "SM8650-APS2";
> audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT",
> "SpkrRight IN", "WSA_SPK2 OUT",
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 3/7] arm64: dts: qcom: shikra: Add CAMSS node
From: Vladimir Zapolskiy @ 2026-06-12 7:56 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-3-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Add the Camera Subsystem node. Shikra shares the same IP as QCM2290
> with two CSIPHYs, two CSIDs and two VFEs, but does not include CDM
> and OPE blocks, so only a single IOMMU context bank is needed.
>
> Co-developed-by: Vikram Sharma <vikram.sharma@oss.qualcomm.com>
> Signed-off-by: Vikram Sharma <vikram.sharma@oss.qualcomm.com>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 99 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 99 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index a4334d99c1f35ee851ca8266ec37d4a200a07ee5..b93ce4a92a998ea5d9d4268d2fd46030fafc4084 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -604,6 +604,105 @@ opp-384000000 {
> };
> };
>
> + camss: camss@5c11000 {
> + compatible = "qcom,shikra-camss", "qcom,qcm2290-camss";
> +
> + reg = <0x0 0x05c11000 0x0 0x1000>,
> + <0x0 0x05c6e000 0x0 0x1000>,
> + <0x0 0x05c75000 0x0 0x1000>,
> + <0x0 0x05c52000 0x0 0x1000>,
> + <0x0 0x05c53000 0x0 0x1000>,
> + <0x0 0x05c66000 0x0 0x400>,
> + <0x0 0x05c68000 0x0 0x400>,
> + <0x0 0x05c6f000 0x0 0x4000>,
> + <0x0 0x05c76000 0x0 0x4000>;
> + reg-names = "top",
> + "csid0",
> + "csid1",
> + "csiphy0",
> + "csiphy1",
> + "csitpg0",
> + "csitpg1",
> + "vfe0",
> + "vfe1";
> +
> + clocks = <&gcc GCC_CAMERA_AHB_CLK>,
> + <&gcc GCC_CAMSS_AXI_CLK>,
> + <&gcc GCC_CAMSS_NRT_AXI_CLK>,
> + <&gcc GCC_CAMSS_RT_AXI_CLK>,
> + <&gcc GCC_CAMSS_TFE_0_CSID_CLK>,
> + <&gcc GCC_CAMSS_TFE_1_CSID_CLK>,
> + <&gcc GCC_CAMSS_CPHY_0_CLK>,
> + <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
> + <&gcc GCC_CAMSS_CPHY_1_CLK>,
> + <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
> + <&gcc GCC_CAMSS_TOP_AHB_CLK>,
> + <&gcc GCC_CAMSS_TFE_0_CLK>,
> + <&gcc GCC_CAMSS_TFE_0_CPHY_RX_CLK>,
> + <&gcc GCC_CAMSS_TFE_1_CLK>,
> + <&gcc GCC_CAMSS_TFE_1_CPHY_RX_CLK>;
> + clock-names = "ahb",
> + "axi",
> + "camnoc_nrt_axi",
> + "camnoc_rt_axi",
> + "csi0",
> + "csi1",
> + "csiphy0",
> + "csiphy0_timer",
> + "csiphy1",
> + "csiphy1_timer",
> + "top_ahb",
> + "vfe0",
> + "vfe0_cphy_rx",
> + "vfe1",
> + "vfe1_cphy_rx";
> +
> + interrupts = <GIC_SPI 210 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 212 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 72 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 73 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 309 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 310 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 211 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 213 IRQ_TYPE_EDGE_RISING 0>;
> + interrupt-names = "csid0",
> + "csid1",
> + "csiphy0",
> + "csiphy1",
> + "csitpg0",
> + "csitpg1",
> + "vfe0",
> + "vfe1";
> +
> + interconnects = <&mem_noc MASTER_AMPSS_M0 RPM_ACTIVE_TAG
> + &config_noc SLAVE_CAMERA_CFG RPM_ACTIVE_TAG>,
> + <&mmrt_virt MASTER_CAMNOC_HF RPM_ALWAYS_TAG
> + &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>,
> + <&mmnrt_virt MASTER_CAMNOC_SF RPM_ALWAYS_TAG
> + &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>;
> + interconnect-names = "ahb",
> + "hf_mnoc",
> + "sf_mnoc";
> +
> + iommus = <&apps_smmu 0x400 0x0>;
> + power-domains = <&gcc GCC_CAMSS_TOP_GDSC>;
Please add an empty line between the properties above.
> +
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + };
> +
> + port@1 {
> + reg = <1>;
> + };
> + };
> + };
> +
> qupv3_0: geniqup@4ac0000 {
> compatible = "qcom,geni-se-qup";
> reg = <0x0 0x04ac0000 0x0 0x2000>;
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 2/2] phy: qcom: qmp-pcie: Add IPQ9650 PCIe PHY support
From: Dmitry Baryshkov @ 2026-06-12 7:56 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260612-ipq9650_pcie_phy-v2-2-b938cc2fc267@qti.qualcomm.com>
On Fri, Jun 12, 2026 at 01:21:02PM +0530, Kathiravan Thirumoorthy wrote:
> From: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
>
> Add support for the IPQ9650 platform, which includes three Gen3 x2 PCIe
> controllers and two Gen3 x1 PCIe controllers. The PHY instances require
> the on-chip refgen supply.
>
> Add the IPQ9650 Gen3 x1 and x2 QMP PCIe PHY configurations along with
> the refgen regulator supply. Note that an on-chip LDO, driven by the SoC
> CX, supplies the PHY voltages without requiring software control. Note
> that IPQ9650 does not support CX power collapse or rail scaling.
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 220 +++++++++++++++++++++++++++++++
> 1 file changed, 220 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: dts: qcom: sm8250: sort out Iris power domains
From: Dmitry Baryshkov @ 2026-06-12 7:55 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Jonathan Marek,
Rafael J. Wysocki, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Mauro Carvalho Chehab, Stanimir Varbanov,
Abhinav Kumar, Hans Verkuil, Stefan Schmidt, Konrad Dybcio,
Bryan O'Donoghue, Dikshita Agarwal, Ulf Hansson,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm,
linux-media, Mauro Carvalho Chehab
In-Reply-To: <73a30753-527b-4662-ba99-2ebc3878861b@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 03:52:09PM +0200, Konrad Dybcio wrote:
> On 6/10/26 3:34 PM, Dmitry Baryshkov wrote:
> > On Wed, Jun 10, 2026 at 02:24:24PM +0200, Konrad Dybcio wrote:
> >> On 6/4/26 6:22 PM, Dmitry Baryshkov wrote:
> >>> On SM8250 Iris core requires two power rails to function, MX (for PLLs)
> >>> and MMCX (for everything else). The commit fa245b3f06cd ("arm64: dts:
> >>> qcom: sm8250: Add venus DT node") added only MX power rail, but omitted
> >>> MMCX voltage levels.
> >>>
> >>> Add MMCX domain to the Iris device node.
> >>>
> >>> Fixes: fa245b3f06cd ("arm64: dts: qcom: sm8250: Add venus DT node")
> >>> Reported-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> >>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> >>> ---
> >>
> >> [...]
> >>
> >>> opp-720000000 {
> >>> opp-hz = /bits/ 64 <720000000>;
> >>> - required-opps = <&rpmhpd_opp_low_svs>;
> >>> + required-opps = <&rpmhpd_opp_svs>,
> >>> + <&rpmhpd_opp_low_svs>;
> >>
> >> So the computer tells me low_svs would be enough for PLL0 to generate 720MHz
> >>
> >> Is there some transient dependency that bumps this to svs?
> >>
> >> Your changelog mentions you altered this in v6, but I don't see any related
> >> discussion
> >
> > There are two sources of information. The "clocks plan" and the "pll
> > info". For some reason, the clock plan doesn't reflect actual PLL
> > requirements. See the info on the corresponding PLL type.
>
> OK thanks, now I think I asked this already in the past..
>
> still, both point to LOWSVS @ 720 for sm8250
Not really, PLL type points to 615. I've posted you the screenshots
privately (sorry).
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 12/13] arm64: dts: qcom: agatti: Add DSI1 PHY and sleep clocks to DISPCC node
From: Dmitry Baryshkov @ 2026-06-12 7:54 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Imran Shaik, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Loic Poulain, Brian Masney, Ajit Pandey, Taniya Das,
Jagadeesh Kona, linux-arm-msm, linux-clk, devicetree,
linux-kernel
In-Reply-To: <88bdbde3-ac7b-4c40-a8c9-7ffc58a180b2@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 04:02:02PM +0200, Konrad Dybcio wrote:
> On 6/4/26 7:26 AM, Imran Shaik wrote:
> > Update the DISPCC node on QCM2290 (Agatti) to align with the latest DT
> > bindings changes, which adds support for the DSI1 PHY and sleep clocks.
> >
> > Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> > ---
>
> The Agatti MDSS doc suggests there's only a single DSI controller
> and PHY. There are registers to support a secondary PHY, but
> are those just leftovers?
Yes.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: i2c: qcom-cci: Document Shikra compatible
From: Vladimir Zapolskiy @ 2026-06-12 7:53 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma,
Wolfram Sang
In-Reply-To: <20260608-shikra-camss-review-v2-2-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Add Shikra compatible consistent with CAMSS CCI interfaces.
> It requires only two clocks.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: media: qcom: Add Shikra CAMSS compatible
From: Vladimir Zapolskiy @ 2026-06-12 7:53 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-1-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Shikra contains the same Camera Subsystem IP as QCM2290. Document the
> platform-specific compatible string, using qcom,qcm2290-camss as
> fallback.
>
> Unlike QCM2290, Shikra omits the CDM and OPE blocks, requiring only a
> single IOMMU context bank instead of four.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> .../devicetree/bindings/media/qcom,qcm2290-camss.yaml | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> index 391d0f6f67ef5fdfea31dd3683477561516b1556..4f39eefb4898ebc22117407f26cfb4f41deb111b 100644
> --- a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> @@ -14,8 +14,11 @@ description:
>
> properties:
> compatible:
> - const: qcom,qcm2290-camss
> -
> + oneOf:
> + - items:
> + - const: qcom,shikra-camss
> + - const: qcom,qcm2290-camss
> + - const: qcom,qcm2290-camss
> reg:
> maxItems: 9
>
> @@ -76,7 +79,14 @@ properties:
> - const: sf_mnoc
>
> iommus:
> - maxItems: 4
> + oneOf:
> + - items:
> + - description: S1 HLOS VFE non-protected (VFE only)
> + - items:
> + - description: S1 HLOS VFE non-protected
> + - description: S1 HLOS CDM non-protected
> + - description: S1 HLOS OPE read non-protected
> + - description: S1 HLOS OPE write non-protected
>
> power-domains:
> items:
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 2/2] phy: qcom: qmp-pcie: Add IPQ9650 PCIe PHY support
From: Kathiravan Thirumoorthy @ 2026-06-12 7:52 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <epxrpj52vst4zjigsn6ghaiajyzkwdtji2dvgrf7euag4indvf@wzhhy7wtuhhi>
On 6/12/2026 12:54 PM, Dmitry Baryshkov wrote:
> On Fri, Jun 12, 2026 at 12:13:04PM +0530, Kathiravan Thirumoorthy wrote:
>> On 6/12/2026 11:44 AM, Dmitry Baryshkov wrote:
>>> On Fri, Jun 12, 2026 at 08:22:02AM +0530, Kathiravan Thirumoorthy wrote:
>>>> On 6/12/2026 1:52 AM, Dmitry Baryshkov wrote:
>>>>> On Tue, Jun 09, 2026 at 03:46:56PM +0530, Kathiravan Thirumoorthy wrote:
>>>>>> On 6/8/2026 12:26 PM, Dmitry Baryshkov wrote:
>>>>>>> On Tue, Jun 02, 2026 at 02:40:18PM +0530, Kathiravan Thirumoorthy wrote:
>>>>>>>> The IPQ9650 platform has three Gen3 2-lane PCIe controllers and two Gen3
>>>>>>>> 1-lane PCIe controllers. The PHY instances also require the on-chip refgen
>>>>>>>> supply.
>>>>>>>>
>>>>>>>> Add the IPQ9650 Gen3 x1 and x2 QMP PCIe PHY configurations, including the
>>>>>>>> refgen regulator supply.
>>>>>>>>
>>>>>>>> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
>>>>>>>> ---
>>>>>>>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 220 +++++++++++++++++++++++++++++++
>>>>>>>> 1 file changed, 220 insertions(+)
>>>>>>>>
>>>>>>>> @@ -3378,6 +3524,10 @@ static const char * const qmp_phy_vreg_l[] = {
>>>>>>>> "vdda-phy", "vdda-pll",
>>>>>>>> };
>>>>>>>> +static const char * const ipq9650_qmp_phy_vreg_l[] = {
>>>>>>>> + "refgen",
>>>>>>>> +};
>>>>>>> Now vdda-phy / vdda-pll supplies?
>>>>>> Cross checked with HW team again. Along with refgen, there is a on-chip LDO
>>>>>> which supplies fixed voltage to the PHYs. It is enabled upon system power on
>>>>>> and no SW intervention is required.
>>>>> What is it being powered by? MX? CX?
>>>> It is driven by CX.
>>> I assume that there is no CX collapse on IPQ9650? Is CX not scaling on
>>> this chip. Please provide some details on the commit message.
>> That's right. No CX collapse on IPQ9650. Let me rewrite the commit message
>> as below. Hope its okay.
>>
>> --
>>
>> Add support for the IPQ9650 platform, which includes three Gen3 x2 PCIe
>> controllers and two Gen3 x1 PCIe controllers. The PHY instances require the
>> on-chip refgen supply.
>>
>> Add the IPQ9650 Gen3 x1 and x2 QMP PCIe PHY configurations along with the
>> refgen regulator supply. Note that an on-chip LDO, driven by the SoC CX,
>> supplies the PHY voltages without requiring software control. Note that CX
>> power collapse is not supported on IPQ9650.
> ...neither CX power collapse nor rail scaling...
>
> LGTM.
Thanks much. Have sent V2. Please have a look.
>
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-frdm: Add missing HDMI DDC pinctrl
From: Philipp Zabel @ 2026-06-12 7:51 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <airL0l3pgGRaPFVt@lizhi-Precision-Tower-5810>
On Thu, Jun 11, 2026 at 10:53:06AM -0400, Frank Li wrote:
> On Thu, Jun 11, 2026 at 10:18:59AM +0200, Philipp Zabel wrote:
> > Configure HDMI DDC SCL/SDA pins to support reading EDID.
> >
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > ---
>
> Fix tags here?
Fixes: 95d7d7d2ad27 ("arm64: dts: imx8mp-frdm: add sd, ethernet, wifi, usb and hdmi support")
regards
Philipp
^ permalink raw reply
* Re: [PATCH v2 04/16] usb: hub: Return actual error from hub_configure() in hub_probe()
From: Chen-Yu Tsai @ 2026-06-12 7:51 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Alan Stern,
linux-acpi, driver-core, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <ailytpKQcvYTUH7j@ashevche-desk.local>
On Wed, Jun 10, 2026 at 11:20 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Jun 10, 2026 at 04:40:38PM +0800, Chen-Yu Tsai wrote:
> > The addition of power sequencing descriptor handling in the USB hub code
> > requires dealing with deferred probing from pwrseq_get(). The power
> > sequencing provider may not yet be available when the USB hub probes.
> >
> > Return the actual error code from hub_configure() when it fails, so that
> > the driver core can notice the deferred probe request.
>
> Makes sense to me.
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> One nit-pick, though.
>
> ...
>
> > - if (hub_configure(hub, &desc->endpoint[0].desc) >= 0) {
> > + ret = hub_configure(hub, &desc->endpoint[0].desc);
> > + if (ret >= 0) {
> > onboard_dev_create_pdevs(hdev, &hub->onboard_devs);
> >
> > return 0;
> > }
> >
> > hub_disconnect(intf);
> > - return -ENODEV;
> > + return ret;
>
> Can we convert to regular pattern, id est checking for errors first?
Sure. Will do it together in the next version.
ChenYu
> ret = hub_configure(hub, &desc->endpoint[0].desc);
> if (ret < 0) {
> hub_disconnect(intf);
> return ret;
> }
>
> onboard_dev_create_pdevs(hdev, &hub->onboard_devs);
>
> return 0;
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* [PATCH v2 2/2] phy: qcom: qmp-pcie: Add IPQ9650 PCIe PHY support
From: Kathiravan Thirumoorthy @ 2026-06-12 7:51 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Kathiravan Thirumoorthy
In-Reply-To: <20260612-ipq9650_pcie_phy-v2-0-b938cc2fc267@qti.qualcomm.com>
From: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Add support for the IPQ9650 platform, which includes three Gen3 x2 PCIe
controllers and two Gen3 x1 PCIe controllers. The PHY instances require
the on-chip refgen supply.
Add the IPQ9650 Gen3 x1 and x2 QMP PCIe PHY configurations along with
the refgen regulator supply. Note that an on-chip LDO, driven by the SoC
CX, supplies the PHY voltages without requiring software control. Note
that IPQ9650 does not support CX power collapse or rail scaling.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 220 +++++++++++++++++++++++++++++++
1 file changed, 220 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index d3effad7a074..1b94c411321a 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -857,6 +857,152 @@ static const struct qmp_phy_init_tbl ipq9574_gen3x2_pcie_pcs_misc_tbl[] = {
QMP_PHY_INIT_CFG(QPHY_V5_PCS_PCIE_ENDPOINT_REFCLK_DRIVE, 0xc1),
};
+static const struct qmp_phy_init_tbl ipq9650_pcie_serdes_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIAS_EN_CLKBUFLR_EN, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIAS_EN_CTRL_BY_PSM, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_CLK_SELECT, 0x34),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_IVCO, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_CMN_MODE, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_CMN_CONFIG, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP_EN, 0x42),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_RESETSM_CNTRL, 0x20),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_MAP, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_TIMER1, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_TIMER2, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE0, 0x68),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START3_MODE0, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START2_MODE0, 0xaa),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START1_MODE0, 0xab),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE0, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE0, 0xd4),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_CP_CTRL_MODE0, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_RCTRL_MODE0, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_CCTRL_MODE0, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_INTEGLOOP_GAIN1_MODE0, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE2_MODE0, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE1_MODE0, 0x24),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_SVS_MODE_CLK_SEL, 0x05),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYS_CLK_CTRL, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_BUF_ENABLE, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_EN_SEL, 0x08),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_BG_TIMER, 0x0b),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_SEL, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_CLK_ENABLE1, 0x90),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE1, 0x53),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START3_MODE1, 0x05),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START2_MODE1, 0x55),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START1_MODE1, 0x55),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE1, 0x29),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE1, 0xaa),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_CP_CTRL_MODE1, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_RCTRL_MODE1, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_CCTRL_MODE1, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_INTEGLOOP_GAIN1_MODE1, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_INTEGLOOP_GAIN0_MODE1, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE2_MODE1, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE1_MODE1, 0xb4),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_SVS_MODE_CLK_SEL, 0x05),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_CORE_CLK_EN, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_EN_CENTER, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_PER2, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_PER1, 0x7d),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_STEP_SIZE2_MODE0, 0x05),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_STEP_SIZE1_MODE0, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_STEP_SIZE2_MODE1, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_STEP_SIZE1_MODE1, 0x08),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_CORECLK_DIV_MODE1, 0x08),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_HSCLK_SEL, 0x11),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x18),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0xa2),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE1, 0x13),
+ QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE1, 0xb5),
+};
+
+static const struct qmp_phy_init_tbl ipq9650_pcie_tx_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V4_TX_RES_CODE_LANE_OFFSET_TX, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_TX_RES_CODE_LANE_OFFSET_RX, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_TX_RCV_DETECT_LVL_2, 0x12),
+ QMP_PHY_INIT_CFG(QSERDES_V4_TX_HIGHZ_DRVR_EN, 0x10),
+ QMP_PHY_INIT_CFG(QSERDES_V4_TX_LANE_MODE_1, 0xb5),
+ QMP_PHY_INIT_CFG(QSERDES_V4_TX_PI_QEC_CTRL, 0x00),
+};
+
+static const struct qmp_phy_init_tbl ipq9650_pcie_rx_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_AUX_DATA_TCOARSE_TFINE, 0x30),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_GM_CAL, 0x11),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FO_GAIN, 0x0c),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_GAIN, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_CNTRL, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_ENABLES, 0x1c),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_DEGLITCH_CNTRL, 0x1e),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL1, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL2, 0x0e),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL3, 0x4a),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL4, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_VGA_GAIN2_LSB, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_VGA_GAIN2_MSB, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_VGA_CAL_CNTRL1, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_VGA_CAL_CNTRL2, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_DCC_CTRL1, 0x0c),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_DFE_CTLE_POST_CAL_OFFSET, 0x38),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_DFE_1, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_DFE_2, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_TX_ADAPT_PRE_THRESH1, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_TX_ADAPT_PRE_THRESH2, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_TX_ADAPT_POST_THRESH, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_TX_ADAPT_MAIN_THRESH, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_DFE_EN_TIMER, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x7f),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_PI_CONTROLS, 0x70),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQ_OFFSET_ADAPTOR_CNTRL1, 0x17),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_OFFSET_ADAPTOR_CNTRL2, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_LOW, 0xd4),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH, 0x54),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH2, 0xdb),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH3, 0x3b),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH4, 0x31),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_LOW, 0x24),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH, 0xe4),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH2, 0xec),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH3, 0x3b),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH4, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_LOW, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH2, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH3, 0x67),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH4, 0x35),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_IDAC_TSETTLE_HIGH, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_IDAC_TSETTLE_LOW, 0xc0),
+};
+
+static const struct qmp_phy_init_tbl ipq9650_pcie_pcs_tbl[] = {
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_REFGEN_REQ_CONFIG1, 0x25),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_G12S1_TXDEEMPH_M3P5DB, 0x10),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_RATE_SLEW_CNTRL1, 0x03),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_EQ_CONFIG2, 0x0f),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_P2U3_WAKEUP_DLY_TIME_AUXCLK_L, 0x01),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_RX_DCC_CAL_CONFIG, 0x00),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_RX_SIGDET_LVL, 0x77),
+};
+
+static const struct qmp_phy_init_tbl ipq9650_pcie_pcs_misc_tbl[] = {
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_POWER_STATE_CONFIG2, 0x0d),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_POWER_STATE_CONFIG4, 0x07),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_ENDPOINT_REFCLK_DRIVE, 0xc1),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_L1P1_WAKEUP_DLY_TIME_AUXCLK_L, 0x01),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_L1P2_WAKEUP_DLY_TIME_AUXCLK_L, 0x01),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_INT_AUX_CLK_CONFIG1, 0x00),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_OSC_DTCT_ACTIONS, 0x00),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_EQ_CONFIG1, 0x1c),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_EQ_CONFIG2, 0x0b),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_PRESET_P2_P3_POST, 0x34),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_PRESET_P6_P7_PRE, 0x33),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_PRESET_P6_P7_POST, 0x40),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_PRESET_P10_PRE, 0x00),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_PRESET_P10_POST, 0x58),
+};
+
static const struct qmp_phy_init_tbl qcs615_pcie_serdes_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_V2_COM_BIAS_EN_CLKBUFLR_EN, 0x18),
QMP_PHY_INIT_CFG(QSERDES_V2_COM_CLK_ENABLE1, 0x10),
@@ -3484,6 +3630,10 @@ static const char * const qmp_phy_vreg_l[] = {
"vdda-phy", "vdda-pll",
};
+static const char * const ipq9650_qmp_phy_vreg_l[] = {
+ "refgen",
+};
+
static const char * const sm8550_qmp_phy_vreg_l[] = {
"vdda-phy", "vdda-pll", "vdda-qref",
};
@@ -3527,6 +3677,14 @@ static const struct qmp_pcie_offsets qmp_pcie_offsets_v4x1 = {
.rx = 0x0400,
};
+static const struct qmp_pcie_offsets qmp_pcie_offsets_9650_v4x1 = {
+ .serdes = 0,
+ .pcs = 0x0600,
+ .pcs_misc = 0x0a00,
+ .tx = 0x0200,
+ .rx = 0x0400,
+};
+
static const struct qmp_pcie_offsets qmp_pcie_offsets_v4x2 = {
.serdes = 0,
.pcs = 0x0a00,
@@ -3802,6 +3960,62 @@ static const struct qmp_phy_cfg ipq9574_gen3x2_pciephy_cfg = {
.pipe_clock_rate = 250000000,
};
+static const struct qmp_phy_cfg ipq9650_gen3x1_pciephy_cfg = {
+ .lanes = 1,
+
+ .offsets = &qmp_pcie_offsets_9650_v4x1,
+
+ .tbls = {
+ .serdes = ipq9650_pcie_serdes_tbl,
+ .serdes_num = ARRAY_SIZE(ipq9650_pcie_serdes_tbl),
+ .tx = ipq9650_pcie_tx_tbl,
+ .tx_num = ARRAY_SIZE(ipq9650_pcie_tx_tbl),
+ .rx = ipq9650_pcie_rx_tbl,
+ .rx_num = ARRAY_SIZE(ipq9650_pcie_rx_tbl),
+ .pcs = ipq9650_pcie_pcs_tbl,
+ .pcs_num = ARRAY_SIZE(ipq9650_pcie_pcs_tbl),
+ .pcs_misc = ipq9650_pcie_pcs_misc_tbl,
+ .pcs_misc_num = ARRAY_SIZE(ipq9650_pcie_pcs_misc_tbl),
+ },
+ .reset_list = ipq8074_pciephy_reset_l,
+ .num_resets = ARRAY_SIZE(ipq8074_pciephy_reset_l),
+ .vreg_list = ipq9650_qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(ipq9650_qmp_phy_vreg_l),
+ .regs = pciephy_v4_regs_layout,
+
+ .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
+ .phy_status = PHYSTATUS,
+ .pipe_clock_rate = 250000000,
+};
+
+static const struct qmp_phy_cfg ipq9650_gen3x2_pciephy_cfg = {
+ .lanes = 2,
+
+ .offsets = &qmp_pcie_offsets_v4x2,
+
+ .tbls = {
+ .serdes = ipq9650_pcie_serdes_tbl,
+ .serdes_num = ARRAY_SIZE(ipq9650_pcie_serdes_tbl),
+ .tx = ipq9650_pcie_tx_tbl,
+ .tx_num = ARRAY_SIZE(ipq9650_pcie_tx_tbl),
+ .rx = ipq9650_pcie_rx_tbl,
+ .rx_num = ARRAY_SIZE(ipq9650_pcie_rx_tbl),
+ .pcs = ipq9650_pcie_pcs_tbl,
+ .pcs_num = ARRAY_SIZE(ipq9650_pcie_pcs_tbl),
+ .pcs_misc = ipq9650_pcie_pcs_misc_tbl,
+ .pcs_misc_num = ARRAY_SIZE(ipq9650_pcie_pcs_misc_tbl),
+ },
+ .reset_list = ipq8074_pciephy_reset_l,
+ .num_resets = ARRAY_SIZE(ipq8074_pciephy_reset_l),
+ .vreg_list = ipq9650_qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(ipq9650_qmp_phy_vreg_l),
+ .regs = pciephy_v4_regs_layout,
+
+ .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
+ .phy_status = PHYSTATUS,
+ .pipe_clock_rate = 250000000,
+};
+
static const struct qmp_phy_cfg qcs615_pciephy_cfg = {
.lanes = 1,
@@ -5558,6 +5772,12 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
}, {
.compatible = "qcom,ipq9574-qmp-gen3x2-pcie-phy",
.data = &ipq9574_gen3x2_pciephy_cfg,
+ }, {
+ .compatible = "qcom,ipq9650-qmp-gen3x1-pcie-phy",
+ .data = &ipq9650_gen3x1_pciephy_cfg,
+ }, {
+ .compatible = "qcom,ipq9650-qmp-gen3x2-pcie-phy",
+ .data = &ipq9650_gen3x2_pciephy_cfg,
}, {
.compatible = "qcom,kaanapali-qmp-gen3x2-pcie-phy",
.data = &qmp_v8_gen3x2_pciephy_cfg,
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: phy: qcom,ipq8074-qmp-pcie: document IPQ9650 QMP PCIe PHYs
From: Kathiravan Thirumoorthy @ 2026-06-12 7:51 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Kathiravan Thirumoorthy, Krzysztof Kozlowski
In-Reply-To: <20260612-ipq9650_pcie_phy-v2-0-b938cc2fc267@qti.qualcomm.com>
From: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Document the single-lane and dual-lane QMP PCIe PHYs found on the
IPQ9650 SoC.
Unlike the PHYs in the other supported IPQ SoCs, the IPQ9650 PHYs require
the on-chip refgen supply to power up. Add the refgen-supply property
and require it only for the IPQ9650 compatibles.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
.../bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
index f60804687412..048b2e3ff0ef 100644
--- a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
@@ -22,6 +22,8 @@ properties:
- qcom,ipq8074-qmp-pcie-phy
- qcom,ipq9574-qmp-gen3x1-pcie-phy
- qcom,ipq9574-qmp-gen3x2-pcie-phy
+ - qcom,ipq9650-qmp-gen3x1-pcie-phy
+ - qcom,ipq9650-qmp-gen3x2-pcie-phy
- items:
- enum:
- qcom,ipq5424-qmp-gen3x1-pcie-phy
@@ -61,6 +63,8 @@ properties:
"#phy-cells":
const: 0
+ refgen-supply: true
+
required:
- compatible
- reg
@@ -72,6 +76,21 @@ required:
- clock-output-names
- "#phy-cells"
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq9650-qmp-gen3x1-pcie-phy
+ - qcom,ipq9650-qmp-gen3x2-pcie-phy
+ then:
+ required:
+ - refgen-supply
+ else:
+ properties:
+ refgen-supply: false
+
additionalProperties: false
examples:
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] Add support for the QMP PCIe PHYs in Qualcomm IPQ9650
From: Kathiravan Thirumoorthy @ 2026-06-12 7:51 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Kathiravan Thirumoorthy, Krzysztof Kozlowski
Qualcomm's IPQ9650 SoC has 3 Gen3 dual lane and 2 Gen3 single lane
controllers with the QMP PHYs. Unlike the PHYs in the other IPQ SoC,
refgen supply is needed to bringup the PHYs. Both single and dual lane
shares the same HW init sequence. So reuse the tables.
Document the compatible along with refgen supply and add the phy driver
support for it.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
Changes in v2:
- rebase on phy-next
- pick up R-b tag
- Link to v1:
https://lore.kernel.org/linux-arm-msm/20260602-ipq9650_pcie_phy-v1-0-d8c32a36dbd9@oss.qualcomm.com/
To: Vinod Koul <vkoul@kernel.org>
To: Neil Armstrong <neil.armstrong@linaro.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-phy@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Kathiravan Thirumoorthy (2):
dt-bindings: phy: qcom,ipq8074-qmp-pcie: document IPQ9650 QMP PCIe PHYs
phy: qcom: qmp-pcie: Add IPQ9650 PCIe PHY support
.../bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml | 19 ++
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 220 +++++++++++++++++++++
2 files changed, 239 insertions(+)
---
base-commit: 2ace2e949979b82f82f12dd76d7c5a6145246ca3
change-id: 20260521-ipq9650_pcie_phy-60d7df32581c
Best regards,
--
Kathiravan Thirumoorthy <kathirav@qti.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Dmitry Baryshkov @ 2026-06-12 7:50 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Stephan Gerhold, Mark Pearson, Rob Herring, Manivannan Sadhasivam,
Greg KH, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Derek J . Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86@vger.kernel.org, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm,
linux-acpi@vger.kernel.org
In-Reply-To: <eftahohsx3bbvmgxuciofjjcrybnsm2qc752hwyt65rb2uwaon@h32nh5fcpo7p>
On Wed, Jun 10, 2026 at 06:44:59PM +0200, Manivannan Sadhasivam wrote:
> On Tue, Mar 31, 2026 at 06:29:51PM +0200, Stephan Gerhold wrote:
> > On Wed, Mar 25, 2026 at 05:36:08PM +0530, Manivannan Sadhasivam wrote:
> > > On Mon, Mar 23, 2026 at 01:23:07PM -0400, Mark Pearson wrote:
> > > > On Mon, Mar 23, 2026, at 12:52 PM, Manivannan Sadhasivam wrote:
> > > > > On Mon, Mar 23, 2026 at 06:45:15PM +0200, Dmitry Baryshkov wrote:
> > > > >> On Mon, Mar 23, 2026 at 09:26:04PM +0530, Manivannan Sadhasivam wrote:
> > > > >> > On Mon, Mar 23, 2026 at 05:14:30PM +0200, Dmitry Baryshkov wrote:
> > > > >> > > On Mon, Mar 23, 2026 at 07:14:25PM +0530, Manivannan Sadhasivam wrote:
> > > > >> > > > On Mon, Mar 23, 2026 at 08:39:55AM -0500, Rob Herring wrote:
> > > > >> > > > > On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > >> > > > > >
> > > > >> > > > > > On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> > > > >> > > > > > > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > > > >> > > > > > > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > > > >> > > > > > > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > > > >> > > > > > > > spec, it looks very similar to the M.2 Key E connector. So add the
> > > > >> > > > > > > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > > > >> > > > > > > > to reuse the Key E binding.
> > > > >> > > > > > >
> > > > >> > > > > > > What is LGA?
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > Land Grid Array
> > > > >> > > > > >
> > > > >> > > > > > > If not in the spec, is it really something generic?
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> > > > >> > > > > > vendors may also use this form factor. PCIe connectors are full of innovation as
> > > > >> > > > > > the spec gives room for hardware designers to be as innovative as possible to
> > > > >> > > > > > save the BOM cost.
> > > > >> > > > >
> > > > >> > > > > innovation == incompatible changes
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > > Yes, I was trying to sound nice :)
> > > > >> > > >
> > > > >> > > > > > This is why I do not want to make it Lenovo specific. But if you prefer that, I
> > > > >> > > > > > can name it as "lenovo,pcie-m2-1620-lga-connector".
> > > > >> > > > >
> > > > >> > > > > Depends if you think that s/w needs to know the differences. Hard to
> > > > >> > > > > say with a sample size of 1.
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > > Sure. Will add the 'lenovo' prefix then.
> > > > >> > >
> > > > >> > > Is it really Lenovo? Or is it some other module vendor, whose LGAs are
> > > > >> > > being used by Lenovo?
> > > > >> > >
> > > > >> > > I remember that DB820c also used some kind of a module for the WiFi card
> > > > >> > > (which might be M.2 compatible or might not, I can't find exact docs at
> > > > >> > > this point).
> > > > >> > >
> > > > >> >
> > > > >> > I don't know. These kind of designs might be reused by several vendors. But
> > > > >> > considering that we should not make it generic, I'd go with Lenovo as that's
> > > > >> > the only vendor we know as of now.
> > > > >>
> > > > >> ... and later we learn that other vendors use the same idea /pinout,
> > > > >> then nothing stops us from still telling that it's a
> > > > >> "lenovo,pcie-m2-something-lga".
> > > > >>
> > > > >
> > > > > How do you possibly know whether a single vendor has introduced this form factor
> > > > > or reused by multiple ones? Atleast, I don't have access to such a source to
> > > > > confirm.
> > > > >
> > > > I've not really been following this thread/patchset in detail; but want me to try and check with the T14s platform team if this device is specifically made for us (Lenovo) or not?
> > > > I doubt it is - we just don't do that usually, but I can go and ask the question if it will help resolve this (with the caveat that it could hold up the review for a bit and I may not be able to get a straight answer)
> > > >
> > >
> > > I can drop this specific patch in the meantime.
> > >
> > > > My vote (for what little it's worth) would be to make it non-Lenovo specific. Then when the same part causes issues on another vendors platform I won't get asked questions about why Lenovo is breaking <other vendor> :)
> > > >
> > >
> > > Even if Lenovo prefix is used, it won't break other vendors. Just that we will
> > > end up adding more compatibles.
> > >
> > > Anyhow, I'll wait for your reply and drop this patch for next revision.
> > >
> >
> > If you need a vendor prefix, I think "qcom," would be more appropriate
> > than Lenovo. This form factor is used by most vendors for recent
> > soldered Qualcomm-based wireless cards, not just Lenovo:
> >
> > - Dell XPS 13 9345 has exactly the same soldered M.2 card, I assume
> > there are several other vendors as well.
> >
> > - https://www.sparklan.com/product/wnsq-290be/ is a third-party
> > (Qualcomm-based) M.2 LGA 1620 card, in the block diagram the
> > pinout is called "QM.2 1620 LGA 168pin".
> >
> > - If you press F9 while booting the ThinkPad T14s, you should get to a
> > screen with "Regulatory Information". For the T14s, this screen says
> > "Contains FCC ID: J9C-QCNCM825". This is the WiFi/BT module in the
> > soldered form factor. If you look that up on the FCC website, the
> > applicant for this module is "Qualcomm Technologies, Inc.". This
> > seems to be some kind of "modular certification" that vendors can
> > reuse/adapt without going through the whole process again.
> >
> > Perhaps you should ask around inside Qualcomm? :-)
> >
>
> Sorry for getting back after this long. I did ask around, but our HW folks are
> saying that Qcom is not the first one to use LGA M.2 modules. They claim that
> other vendors also do that.
I think, the idea was that there is no single standard for LGA modules
(please correct me if I'm wrong, I haven't checked the latest PCIe
standards).
>
> But for this specific card, it should be fine to use the 'qcom' prefix as
> apparently the module was supplied by Qcom.
>
> I'll submit the bindings patch together with DTS change for T14s.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
--
With best wishes
Dmitry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox