* Re: [PATCH v1 2/2] riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
From: Yixun Lan @ 2026-03-31 8:59 UTC (permalink / raw)
To: Sandie Cao
Cc: Conor Dooley, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Heinrich Schuchardt, Troy Mitchell, Michael Opdenacker,
Guodong Xu, Hendrik Hamerlinck, Yangyu Chen, spacemit,
linux-riscv, devicetree, linux-kernel
In-Reply-To: <20260331034616.67183-1-sandie.cao@deepcomputing.io>
Hi Sandie,
On 11:46 Tue 31 Mar , Sandie Cao wrote:
> From: sandiecao <sandie.cao@deepcomputing.io>
>
> The FML13V05 board from DeepComputing incorporates a SpacemiT K3 RISC-V
> SoC.It is a mainboard designed for the Framework Laptop 13 Chassis,
> which has (Framework) SKU FRANHQ0001.
>
> The FML13V05 board features:
> - SpacemiT K3 RISC-V SoC
> - LPDDR5 16GB or 32GB
> - eMMC 32GB ~128GB (Optional)
> - UFS 3.1 256G (Optional)
> - QSPI Flash
> - MicroSD Slot
> - PCIe-based Wi-Fi
> - 4 USB-C Ports
> - Port 1: PD 3.0 (65W Max), USB 3.2 Gen 1
> - Port 2: PD 3.0 (65W Max), USB 3.2 Gen 1, DP 1.4 (4K@60Hz)
> - Port 3 & 4: USB 3.2 Gen 1
>
> This minimal device tree enables booting into a serial console with UART
> output.
>
> Signed-off-by: sandiecao <sandie.cao@deepcomputing.io>
> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
should put your own signed-off at the end.
> ---
> arch/riscv/boot/dts/spacemit/Makefile | 1 +
> .../spacemit/k3-deepcomputing-fml13v05.dts | 28 +++++++++++++++++++
> 2 files changed, 29 insertions(+)
> create mode 100644 arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
>
> diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
> index 7e2b87702571..acb993c452ba 100644
> --- a/arch/riscv/boot/dts/spacemit/Makefile
> +++ b/arch/riscv/boot/dts/spacemit/Makefile
> @@ -4,4 +4,5 @@ dtb-$(CONFIG_ARCH_SPACEMIT) += k1-milkv-jupiter.dtb
> dtb-$(CONFIG_ARCH_SPACEMIT) += k1-musepi-pro.dtb
> dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-r2s.dtb
> dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-rv2.dtb
> +dtb-$(CONFIG_ARCH_SPACEMIT) += k3-deepcomputing-fml13v05.dtb
> dtb-$(CONFIG_ARCH_SPACEMIT) += k3-pico-itx.dtb
> diff --git a/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts b/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
> new file mode 100644
> index 000000000000..2343ae3acc2d
> --- /dev/null
> +++ b/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
> @@ -0,0 +1,28 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (C) 2024 DeepComputing (HK) Limited
should cover current year, which is 2026 now..
> + */
> +
> +#include "k3.dtsi"
> +
> +/ {
> + model = "DeepComputing FML13V05";
> + compatible = "deepcomputing,fml13v05", "spacemit,k3";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0";
> + };
> +
> + memory@100000000 {
> + device_type = "memory";
> + reg = <0x1 0x00000000 0x4 0x00000000>;
> + };
> +};
> +
> +&uart0 {
Can you also add pinctrl data explicitly?
> + status = "okay";
> +};
> --
> 2.43.0
--
Yixun Lan (dlan)
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Ulf Hansson @ 2026-03-31 9:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <c4d6b758-474b-409d-b553-fa4ec1df494e@kernel.org>
On Mon, 30 Mar 2026 at 15:38, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 30/03/2026 15:30, Ulf Hansson wrote:
> >
> > Usually we want bindings to go along with their respective drivers on
> > a subsystem basis.
> >
> > Both patch2 and patch4 updates DT bindings for the power-domain providers.
>
> Patch 2 yes. Patch 4 not. That's why I did not take patch 2.
>
> >
> > Why shouldn't the bindings go along with the driver changes here?
>
> Patch #2 is pmdomain, so with pmdomain drivers thus your tree. Patch #4
> is not pmdomain, so not with pmdomain drivers, so not your tree... At
> least I do not see any pmdomain parts in that patch #4. It's a Samsung
> SoC PMU driver and none of further driver patches touch that PMU driver.
Yes, you are right that the PMU driver isn't touched.
Although, the PMU DT description added in patch3 and extended in
patch4, allows power-domain providers to be described in its child
nodes. Those child nodes use the same compatible string as the
power-domain providers described in patch2.
Kind regards
Uffe
^ permalink raw reply
* [PATCH] arm64: dts: qcom: lemans: Move PCIe devices into soc node
From: Shawn Guo @ 2026-03-31 9:01 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Konrad Dybcio, Krzysztof Kozlowski, Manivannan Sadhasivam,
Mrinmay Sarkar, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel, Shawn Guo
These PCIe devices with MMIO address should be inside soc node rather
than outside.
Fixes: 489f14be0e0a ("arm64: dts: qcom: sa8775p: Add pcie0 and pcie1 nodes")
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
This is compile tested only!
arch/arm64/boot/dts/qcom/lemans.dtsi | 692 +++++++++++++--------------
1 file changed, 346 insertions(+), 346 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index f565067bda31..03a712d82d78 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -2694,6 +2694,352 @@ mmss_noc: interconnect@17a0000 {
qcom,bcm-voters = <&apps_bcm_voter>;
};
+ pcie0: pcie@1c00000 {
+ compatible = "qcom,pcie-sa8775p";
+ reg = <0x0 0x01c00000 0x0 0x3000>,
+ <0x0 0x40000000 0x0 0xf20>,
+ <0x0 0x40000f20 0x0 0xa8>,
+ <0x0 0x40001000 0x0 0x4000>,
+ <0x0 0x40100000 0x0 0x100000>,
+ <0x0 0x01c03000 0x0 0x1000>;
+ reg-names = "parf", "dbi", "elbi", "atu", "config", "mhi";
+ device_type = "pci";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x01000000 0x0 0x00000000 0x0 0x40200000 0x0 0x100000>,
+ <0x02000000 0x0 0x40300000 0x0 0x40300000 0x0 0x1fd00000>;
+ bus-range = <0x00 0xff>;
+
+ dma-coherent;
+
+ linux,pci-domain = <0>;
+ num-lanes = <2>;
+
+ interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0",
+ "msi1",
+ "msi2",
+ "msi3",
+ "msi4",
+ "msi5",
+ "msi6",
+ "msi7",
+ "global";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc GIC_SPI 434 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc GIC_SPI 435 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc GIC_SPI 438 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc GIC_SPI 439 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
+ <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>;
+
+ clock-names = "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a";
+
+ assigned-clocks = <&gcc GCC_PCIE_0_AUX_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ interconnects = <&pcie_anoc MASTER_PCIE_0 0 &mc_virt SLAVE_EBI1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_PCIE_0 0>;
+ interconnect-names = "pcie-mem", "cpu-pcie";
+
+ iommu-map = <0x0 &pcie_smmu 0x0000 0x1>,
+ <0x100 &pcie_smmu 0x0001 0x1>;
+
+ resets = <&gcc GCC_PCIE_0_BCR>,
+ <&gcc GCC_PCIE_0_LINK_DOWN_BCR>;
+ reset-names = "pci",
+ "link_down";
+
+ power-domains = <&gcc PCIE_0_GDSC>;
+
+ phys = <&pcie0_phy>;
+ phy-names = "pciephy";
+
+ eq-presets-8gts = /bits/ 16 <0x5555 0x5555>;
+ eq-presets-16gts = /bits/ 8 <0x55 0x55>;
+
+ status = "disabled";
+
+ pcieport0: pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
+ };
+
+ pcie0_ep: pcie-ep@1c00000 {
+ compatible = "qcom,sa8775p-pcie-ep";
+ reg = <0x0 0x01c00000 0x0 0x3000>,
+ <0x0 0x40000000 0x0 0xf20>,
+ <0x0 0x40000f20 0x0 0xa8>,
+ <0x0 0x40001000 0x0 0x4000>,
+ <0x0 0x40200000 0x0 0x1fe00000>,
+ <0x0 0x01c03000 0x0 0x1000>,
+ <0x0 0x40005000 0x0 0x2000>;
+ reg-names = "parf", "dbi", "elbi", "atu", "addr_space",
+ "mmio", "dma";
+
+ clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
+ <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>;
+
+ clock-names = "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a";
+
+ interrupts = <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 630 IRQ_TYPE_LEVEL_HIGH>;
+
+ interrupt-names = "global", "doorbell", "dma";
+
+ interconnects = <&pcie_anoc MASTER_PCIE_0 0 &mc_virt SLAVE_EBI1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_PCIE_0 0>;
+ interconnect-names = "pcie-mem", "cpu-pcie";
+
+ dma-coherent;
+ iommus = <&pcie_smmu 0x0000 0x7f>;
+ resets = <&gcc GCC_PCIE_0_BCR>;
+ reset-names = "core";
+ power-domains = <&gcc PCIE_0_GDSC>;
+ phys = <&pcie0_phy>;
+ phy-names = "pciephy";
+ num-lanes = <2>;
+ linux,pci-domain = <0>;
+
+ status = "disabled";
+ };
+
+ pcie0_phy: phy@1c04000 {
+ compatible = "qcom,sa8775p-qmp-gen4x2-pcie-phy";
+ reg = <0x0 0x1c04000 0x0 0x2000>;
+
+ clocks = <&gcc GCC_PCIE_0_PHY_AUX_CLK>,
+ <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_CLKREF_EN>,
+ <&gcc GCC_PCIE_0_PHY_RCHNG_CLK>,
+ <&gcc GCC_PCIE_0_PIPE_CLK>,
+ <&gcc GCC_PCIE_0_PIPEDIV2_CLK>;
+ clock-names = "aux",
+ "cfg_ahb",
+ "ref",
+ "rchng",
+ "pipe",
+ "pipediv2";
+
+ assigned-clocks = <&gcc GCC_PCIE_0_PHY_RCHNG_CLK>;
+ assigned-clock-rates = <100000000>;
+
+ resets = <&gcc GCC_PCIE_0_PHY_BCR>;
+ reset-names = "phy";
+
+ #clock-cells = <0>;
+ clock-output-names = "pcie_0_pipe_clk";
+
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
+ pcie1: pcie@1c10000 {
+ compatible = "qcom,pcie-sa8775p";
+ reg = <0x0 0x01c10000 0x0 0x3000>,
+ <0x0 0x60000000 0x0 0xf20>,
+ <0x0 0x60000f20 0x0 0xa8>,
+ <0x0 0x60001000 0x0 0x4000>,
+ <0x0 0x60100000 0x0 0x100000>,
+ <0x0 0x01c13000 0x0 0x1000>;
+ reg-names = "parf", "dbi", "elbi", "atu", "config", "mhi";
+ device_type = "pci";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x01000000 0x0 0x00000000 0x0 0x60200000 0x0 0x100000>,
+ <0x02000000 0x0 0x60300000 0x0 0x60300000 0x0 0x1fd00000>;
+ bus-range = <0x00 0xff>;
+
+ dma-coherent;
+
+ linux,pci-domain = <1>;
+ num-lanes = <4>;
+
+ interrupts = <GIC_SPI 519 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 518 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0",
+ "msi1",
+ "msi2",
+ "msi3",
+ "msi4",
+ "msi5",
+ "msi6",
+ "msi7",
+ "global";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&gcc GCC_PCIE_1_AUX_CLK>,
+ <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_1_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_1_SLV_Q2A_AXI_CLK>;
+
+ clock-names = "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a";
+
+ assigned-clocks = <&gcc GCC_PCIE_1_AUX_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ interconnects = <&pcie_anoc MASTER_PCIE_1 0 &mc_virt SLAVE_EBI1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_PCIE_1 0>;
+ interconnect-names = "pcie-mem", "cpu-pcie";
+
+ iommu-map = <0x0 &pcie_smmu 0x0080 0x1>,
+ <0x100 &pcie_smmu 0x0081 0x1>;
+
+ resets = <&gcc GCC_PCIE_1_BCR>,
+ <&gcc GCC_PCIE_1_LINK_DOWN_BCR>;
+ reset-names = "pci",
+ "link_down";
+
+ power-domains = <&gcc PCIE_1_GDSC>;
+
+ phys = <&pcie1_phy>;
+ phy-names = "pciephy";
+
+ eq-presets-8gts = /bits/ 16 <0x5555 0x5555 0x5555 0x5555>;
+ eq-presets-16gts = /bits/ 8 <0x55 0x55 0x55 0x55>;
+
+ status = "disabled";
+
+ pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
+ };
+
+ pcie1_ep: pcie-ep@1c10000 {
+ compatible = "qcom,sa8775p-pcie-ep";
+ reg = <0x0 0x01c10000 0x0 0x3000>,
+ <0x0 0x60000000 0x0 0xf20>,
+ <0x0 0x60000f20 0x0 0xa8>,
+ <0x0 0x60001000 0x0 0x4000>,
+ <0x0 0x60200000 0x0 0x1fe00000>,
+ <0x0 0x01c13000 0x0 0x1000>,
+ <0x0 0x60005000 0x0 0x2000>;
+ reg-names = "parf", "dbi", "elbi", "atu", "addr_space",
+ "mmio", "dma";
+
+ clocks = <&gcc GCC_PCIE_1_AUX_CLK>,
+ <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_1_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_1_SLV_Q2A_AXI_CLK>;
+
+ clock-names = "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a";
+
+ interrupts = <GIC_SPI 518 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 474 IRQ_TYPE_LEVEL_HIGH>;
+
+ interrupt-names = "global", "doorbell", "dma";
+
+ interconnects = <&pcie_anoc MASTER_PCIE_1 0 &mc_virt SLAVE_EBI1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_PCIE_1 0>;
+ interconnect-names = "pcie-mem", "cpu-pcie";
+
+ dma-coherent;
+ iommus = <&pcie_smmu 0x80 0x7f>;
+ resets = <&gcc GCC_PCIE_1_BCR>;
+ reset-names = "core";
+ power-domains = <&gcc PCIE_1_GDSC>;
+ phys = <&pcie1_phy>;
+ phy-names = "pciephy";
+ num-lanes = <4>;
+ linux,pci-domain = <1>;
+
+ status = "disabled";
+ };
+
+ pcie1_phy: phy@1c14000 {
+ compatible = "qcom,sa8775p-qmp-gen4x4-pcie-phy";
+ reg = <0x0 0x1c14000 0x0 0x4000>;
+
+ clocks = <&gcc GCC_PCIE_1_PHY_AUX_CLK>,
+ <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_CLKREF_EN>,
+ <&gcc GCC_PCIE_1_PHY_RCHNG_CLK>,
+ <&gcc GCC_PCIE_1_PIPE_CLK>,
+ <&gcc GCC_PCIE_1_PIPEDIV2_CLK>;
+ clock-names = "aux",
+ "cfg_ahb",
+ "ref",
+ "rchng",
+ "pipe",
+ "pipediv2";
+
+ assigned-clocks = <&gcc GCC_PCIE_1_PHY_RCHNG_CLK>;
+ assigned-clock-rates = <100000000>;
+
+ resets = <&gcc GCC_PCIE_1_PHY_BCR>;
+ reset-names = "phy";
+
+ #clock-cells = <0>;
+ clock-output-names = "pcie_1_pipe_clk";
+
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
ufs_mem_hc: ufshc@1d84000 {
compatible = "qcom,sa8775p-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
reg = <0x0 0x01d84000 0x0 0x3000>;
@@ -8601,350 +8947,4 @@ turing_llm_tpdm_out: endpoint {
};
};
};
-
- pcie0: pcie@1c00000 {
- compatible = "qcom,pcie-sa8775p";
- reg = <0x0 0x01c00000 0x0 0x3000>,
- <0x0 0x40000000 0x0 0xf20>,
- <0x0 0x40000f20 0x0 0xa8>,
- <0x0 0x40001000 0x0 0x4000>,
- <0x0 0x40100000 0x0 0x100000>,
- <0x0 0x01c03000 0x0 0x1000>;
- reg-names = "parf", "dbi", "elbi", "atu", "config", "mhi";
- device_type = "pci";
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges = <0x01000000 0x0 0x00000000 0x0 0x40200000 0x0 0x100000>,
- <0x02000000 0x0 0x40300000 0x0 0x40300000 0x0 0x1fd00000>;
- bus-range = <0x00 0xff>;
-
- dma-coherent;
-
- linux,pci-domain = <0>;
- num-lanes = <2>;
-
- interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "msi0",
- "msi1",
- "msi2",
- "msi3",
- "msi4",
- "msi5",
- "msi6",
- "msi7",
- "global";
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0x7>;
- interrupt-map = <0 0 0 1 &intc GIC_SPI 434 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &intc GIC_SPI 435 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &intc GIC_SPI 438 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &intc GIC_SPI 439 IRQ_TYPE_LEVEL_HIGH>;
-
- clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
- <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
- <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
- <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
- <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>;
-
- clock-names = "aux",
- "cfg",
- "bus_master",
- "bus_slave",
- "slave_q2a";
-
- assigned-clocks = <&gcc GCC_PCIE_0_AUX_CLK>;
- assigned-clock-rates = <19200000>;
-
- interconnects = <&pcie_anoc MASTER_PCIE_0 0 &mc_virt SLAVE_EBI1 0>,
- <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_PCIE_0 0>;
- interconnect-names = "pcie-mem", "cpu-pcie";
-
- iommu-map = <0x0 &pcie_smmu 0x0000 0x1>,
- <0x100 &pcie_smmu 0x0001 0x1>;
-
- resets = <&gcc GCC_PCIE_0_BCR>,
- <&gcc GCC_PCIE_0_LINK_DOWN_BCR>;
- reset-names = "pci",
- "link_down";
-
- power-domains = <&gcc PCIE_0_GDSC>;
-
- phys = <&pcie0_phy>;
- phy-names = "pciephy";
-
- eq-presets-8gts = /bits/ 16 <0x5555 0x5555>;
- eq-presets-16gts = /bits/ 8 <0x55 0x55>;
-
- status = "disabled";
-
- pcieport0: pcie@0 {
- device_type = "pci";
- reg = <0x0 0x0 0x0 0x0 0x0>;
- bus-range = <0x01 0xff>;
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
- };
- };
-
- pcie0_ep: pcie-ep@1c00000 {
- compatible = "qcom,sa8775p-pcie-ep";
- reg = <0x0 0x01c00000 0x0 0x3000>,
- <0x0 0x40000000 0x0 0xf20>,
- <0x0 0x40000f20 0x0 0xa8>,
- <0x0 0x40001000 0x0 0x4000>,
- <0x0 0x40200000 0x0 0x1fe00000>,
- <0x0 0x01c03000 0x0 0x1000>,
- <0x0 0x40005000 0x0 0x2000>;
- reg-names = "parf", "dbi", "elbi", "atu", "addr_space",
- "mmio", "dma";
-
- clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
- <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
- <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
- <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
- <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>;
-
- clock-names = "aux",
- "cfg",
- "bus_master",
- "bus_slave",
- "slave_q2a";
-
- interrupts = <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 630 IRQ_TYPE_LEVEL_HIGH>;
-
- interrupt-names = "global", "doorbell", "dma";
-
- interconnects = <&pcie_anoc MASTER_PCIE_0 0 &mc_virt SLAVE_EBI1 0>,
- <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_PCIE_0 0>;
- interconnect-names = "pcie-mem", "cpu-pcie";
-
- dma-coherent;
- iommus = <&pcie_smmu 0x0000 0x7f>;
- resets = <&gcc GCC_PCIE_0_BCR>;
- reset-names = "core";
- power-domains = <&gcc PCIE_0_GDSC>;
- phys = <&pcie0_phy>;
- phy-names = "pciephy";
- num-lanes = <2>;
- linux,pci-domain = <0>;
-
- status = "disabled";
- };
-
- pcie0_phy: phy@1c04000 {
- compatible = "qcom,sa8775p-qmp-gen4x2-pcie-phy";
- reg = <0x0 0x1c04000 0x0 0x2000>;
-
- clocks = <&gcc GCC_PCIE_0_PHY_AUX_CLK>,
- <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
- <&gcc GCC_PCIE_CLKREF_EN>,
- <&gcc GCC_PCIE_0_PHY_RCHNG_CLK>,
- <&gcc GCC_PCIE_0_PIPE_CLK>,
- <&gcc GCC_PCIE_0_PIPEDIV2_CLK>;
- clock-names = "aux",
- "cfg_ahb",
- "ref",
- "rchng",
- "pipe",
- "pipediv2";
-
- assigned-clocks = <&gcc GCC_PCIE_0_PHY_RCHNG_CLK>;
- assigned-clock-rates = <100000000>;
-
- resets = <&gcc GCC_PCIE_0_PHY_BCR>;
- reset-names = "phy";
-
- #clock-cells = <0>;
- clock-output-names = "pcie_0_pipe_clk";
-
- #phy-cells = <0>;
-
- status = "disabled";
- };
-
- pcie1: pcie@1c10000 {
- compatible = "qcom,pcie-sa8775p";
- reg = <0x0 0x01c10000 0x0 0x3000>,
- <0x0 0x60000000 0x0 0xf20>,
- <0x0 0x60000f20 0x0 0xa8>,
- <0x0 0x60001000 0x0 0x4000>,
- <0x0 0x60100000 0x0 0x100000>,
- <0x0 0x01c13000 0x0 0x1000>;
- reg-names = "parf", "dbi", "elbi", "atu", "config", "mhi";
- device_type = "pci";
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges = <0x01000000 0x0 0x00000000 0x0 0x60200000 0x0 0x100000>,
- <0x02000000 0x0 0x60300000 0x0 0x60300000 0x0 0x1fd00000>;
- bus-range = <0x00 0xff>;
-
- dma-coherent;
-
- linux,pci-domain = <1>;
- num-lanes = <4>;
-
- interrupts = <GIC_SPI 519 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 518 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "msi0",
- "msi1",
- "msi2",
- "msi3",
- "msi4",
- "msi5",
- "msi6",
- "msi7",
- "global";
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0x7>;
- interrupt-map = <0 0 0 1 &intc GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &intc GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &intc GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &intc GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
-
- clocks = <&gcc GCC_PCIE_1_AUX_CLK>,
- <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
- <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
- <&gcc GCC_PCIE_1_SLV_AXI_CLK>,
- <&gcc GCC_PCIE_1_SLV_Q2A_AXI_CLK>;
-
- clock-names = "aux",
- "cfg",
- "bus_master",
- "bus_slave",
- "slave_q2a";
-
- assigned-clocks = <&gcc GCC_PCIE_1_AUX_CLK>;
- assigned-clock-rates = <19200000>;
-
- interconnects = <&pcie_anoc MASTER_PCIE_1 0 &mc_virt SLAVE_EBI1 0>,
- <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_PCIE_1 0>;
- interconnect-names = "pcie-mem", "cpu-pcie";
-
- iommu-map = <0x0 &pcie_smmu 0x0080 0x1>,
- <0x100 &pcie_smmu 0x0081 0x1>;
-
- resets = <&gcc GCC_PCIE_1_BCR>,
- <&gcc GCC_PCIE_1_LINK_DOWN_BCR>;
- reset-names = "pci",
- "link_down";
-
- power-domains = <&gcc PCIE_1_GDSC>;
-
- phys = <&pcie1_phy>;
- phy-names = "pciephy";
-
- eq-presets-8gts = /bits/ 16 <0x5555 0x5555 0x5555 0x5555>;
- eq-presets-16gts = /bits/ 8 <0x55 0x55 0x55 0x55>;
-
- status = "disabled";
-
- pcie@0 {
- device_type = "pci";
- reg = <0x0 0x0 0x0 0x0 0x0>;
- bus-range = <0x01 0xff>;
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
- };
- };
-
- pcie1_ep: pcie-ep@1c10000 {
- compatible = "qcom,sa8775p-pcie-ep";
- reg = <0x0 0x01c10000 0x0 0x3000>,
- <0x0 0x60000000 0x0 0xf20>,
- <0x0 0x60000f20 0x0 0xa8>,
- <0x0 0x60001000 0x0 0x4000>,
- <0x0 0x60200000 0x0 0x1fe00000>,
- <0x0 0x01c13000 0x0 0x1000>,
- <0x0 0x60005000 0x0 0x2000>;
- reg-names = "parf", "dbi", "elbi", "atu", "addr_space",
- "mmio", "dma";
-
- clocks = <&gcc GCC_PCIE_1_AUX_CLK>,
- <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
- <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
- <&gcc GCC_PCIE_1_SLV_AXI_CLK>,
- <&gcc GCC_PCIE_1_SLV_Q2A_AXI_CLK>;
-
- clock-names = "aux",
- "cfg",
- "bus_master",
- "bus_slave",
- "slave_q2a";
-
- interrupts = <GIC_SPI 518 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 474 IRQ_TYPE_LEVEL_HIGH>;
-
- interrupt-names = "global", "doorbell", "dma";
-
- interconnects = <&pcie_anoc MASTER_PCIE_1 0 &mc_virt SLAVE_EBI1 0>,
- <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_PCIE_1 0>;
- interconnect-names = "pcie-mem", "cpu-pcie";
-
- dma-coherent;
- iommus = <&pcie_smmu 0x80 0x7f>;
- resets = <&gcc GCC_PCIE_1_BCR>;
- reset-names = "core";
- power-domains = <&gcc PCIE_1_GDSC>;
- phys = <&pcie1_phy>;
- phy-names = "pciephy";
- num-lanes = <4>;
- linux,pci-domain = <1>;
-
- status = "disabled";
- };
-
- pcie1_phy: phy@1c14000 {
- compatible = "qcom,sa8775p-qmp-gen4x4-pcie-phy";
- reg = <0x0 0x1c14000 0x0 0x4000>;
-
- clocks = <&gcc GCC_PCIE_1_PHY_AUX_CLK>,
- <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
- <&gcc GCC_PCIE_CLKREF_EN>,
- <&gcc GCC_PCIE_1_PHY_RCHNG_CLK>,
- <&gcc GCC_PCIE_1_PIPE_CLK>,
- <&gcc GCC_PCIE_1_PIPEDIV2_CLK>;
- clock-names = "aux",
- "cfg_ahb",
- "ref",
- "rchng",
- "pipe",
- "pipediv2";
-
- assigned-clocks = <&gcc GCC_PCIE_1_PHY_RCHNG_CLK>;
- assigned-clock-rates = <100000000>;
-
- resets = <&gcc GCC_PCIE_1_PHY_BCR>;
- reset-names = "phy";
-
- #clock-cells = <0>;
- clock-output-names = "pcie_1_pipe_clk";
-
- #phy-cells = <0>;
-
- status = "disabled";
- };
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v1 1/1] arm64: dts: imx91-var-dart-sonata: add RGB select supply for PCA6408
From: Stefano Radaelli @ 2026-03-31 9:02 UTC (permalink / raw)
To: Frank Li
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <acqLWgY1_G7e0qOI@lizhi-Precision-Tower-5810>
On Mon, Mar 30, 2026 at 10:40:26AM -0400, Frank Li wrote:
> > Yes, it is exactly the second case!
> > It's just an EN pin, that enables a buffer to route RGB signals used on
> > the DART-MX91 som only.
> > That's why I think regulator is the right way for this case.
>
> Okay, it'd better to emphrase it in commit message because _SEL is miss
> leasing.
>
Thank you Frank,
I'm sending new version with correct commit message.
Best Regards,
Stefano
^ permalink raw reply
* Re: [PATCH 4/7] clk: qcom: rpmh: Add support for Hawi RPMH clocks
From: Taniya Das @ 2026-03-31 9:08 UTC (permalink / raw)
To: Vivek Aknurwar, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260330-clk-hawi-v1-4-c2a663e1d35b@oss.qualcomm.com>
On 3/31/2026 6:04 AM, Vivek Aknurwar wrote:
> diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c
> index 6a54481cc6ae..f9084c15467c 100644
> --- a/drivers/clk/qcom/clk-rpmh.c
> +++ b/drivers/clk/qcom/clk-rpmh.c
> @@ -405,7 +405,9 @@ DEFINE_CLK_RPMH_VRM(clk5, _a2_e0, "C5A_E0", 2);
> DEFINE_CLK_RPMH_VRM(clk6, _a2_e0, "C6A_E0", 2);
> DEFINE_CLK_RPMH_VRM(clk7, _a2_e0, "C7A_E0", 2);
> DEFINE_CLK_RPMH_VRM(clk8, _a2_e0, "C8A_E0", 2);
> +DEFINE_CLK_RPMH_VRM(clk9, _a2_e0, "C9A_E0", 2);
>
> +DEFINE_CLK_RPMH_VRM(clk7, _a4_e0, "C7A_E0", 4);
> DEFINE_CLK_RPMH_VRM(clk11, _a4_e0, "C11A_E0", 4);
>
> DEFINE_CLK_RPMH_BCM(ce, "CE0");
> @@ -965,6 +967,36 @@ static const struct clk_rpmh_desc clk_rpmh_eliza = {
> .num_clks = ARRAY_SIZE(eliza_rpmh_clocks),
> };
>
> +static struct clk_hw *hawi_rpmh_clocks[] = {
> + [RPMH_CXO_CLK] = &clk_rpmh_bi_tcxo_div2.hw,
> + [RPMH_CXO_CLK_A] = &clk_rpmh_bi_tcxo_div2_ao.hw,
> + [RPMH_DIV_CLK1] = &clk_rpmh_clk11_a4_e0.hw,
> + [RPMH_LN_BB_CLK1] = &clk_rpmh_clk6_a2_e0.hw,
> + [RPMH_LN_BB_CLK1_A] = &clk_rpmh_clk6_a2_e0_ao.hw,
> + [RPMH_LN_BB_CLK2] = &clk_rpmh_clk7_a4_e0.hw,
> + [RPMH_LN_BB_CLK2_A] = &clk_rpmh_clk7_a4_e0_ao.hw,
> + [RPMH_LN_BB_CLK3] = &clk_rpmh_clk8_a2_e0.hw,
> + [RPMH_LN_BB_CLK3_A] = &clk_rpmh_clk8_a2_e0_ao.hw,
> + [RPMH_LN_BB_CLK4] = &clk_rpmh_clk9_a2_e0.hw,
> + [RPMH_LN_BB_CLK4_A] = &clk_rpmh_clk9_a2_e0_ao.hw,
> + [RPMH_RF_CLK1] = &clk_rpmh_clk1_a1_e0.hw,
> + [RPMH_RF_CLK1_A] = &clk_rpmh_clk1_a1_e0_ao.hw,
> + [RPMH_RF_CLK2] = &clk_rpmh_clk2_a1_e0.hw,
> + [RPMH_RF_CLK2_A] = &clk_rpmh_clk2_a1_e0_ao.hw,
> + [RPMH_RF_CLK3] = &clk_rpmh_clk3_a2_e0.hw,
> + [RPMH_RF_CLK3_A] = &clk_rpmh_clk3_a2_e0_ao.hw,
> + [RPMH_RF_CLK4] = &clk_rpmh_clk4_a2_e0.hw,
> + [RPMH_RF_CLK4_A] = &clk_rpmh_clk4_a2_e0_ao.hw,
> + [RPMH_RF_CLK5] = &clk_rpmh_clk5_a2_e0.hw,
> + [RPMH_RF_CLK5_A] = &clk_rpmh_clk5_a2_e0_ao.hw,
> + [RPMH_IPA_CLK] = &clk_rpmh_ipa.hw,
> +};
> +
> +static const struct clk_rpmh_desc clk_rpmh_hawi = {
> + .clks = hawi_rpmh_clocks,
> + .num_clks = ARRAY_SIZE(hawi_rpmh_clocks),
> +};
> +
> static struct clk_hw *of_clk_rpmh_hw_get(struct of_phandle_args *clkspec,
> void *data)
> {
> @@ -1056,6 +1088,7 @@ static int clk_rpmh_probe(struct platform_device *pdev)
> static const struct of_device_id clk_rpmh_match_table[] = {
> { .compatible = "qcom,eliza-rpmh-clk", .data = &clk_rpmh_eliza},
> { .compatible = "qcom,glymur-rpmh-clk", .data = &clk_rpmh_glymur},
> + { .compatible = "qcom,hawi-rpmh-clk", .data = &clk_rpmh_hawi},
> { .compatible = "qcom,kaanapali-rpmh-clk", .data = &clk_rpmh_kaanapali},
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH 6/7] clk: qcom: clk-alpha-pll: Add support for Taycan EHA_T PLL
From: Taniya Das @ 2026-03-31 9:10 UTC (permalink / raw)
To: Vivek Aknurwar, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260330-clk-hawi-v1-6-c2a663e1d35b@oss.qualcomm.com>
On 3/31/2026 6:05 AM, Vivek Aknurwar wrote:
> Add clock operations and register offsets to enable control of the Taycan
> EHA_T PLL, allowing for proper configuration and management of the PLL.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> drivers/clk/qcom/clk-alpha-pll.h | 6 ++++++
> 1 file changed, 6 insertions(+)
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: lemans: Move PCIe devices into soc node
From: Konrad Dybcio @ 2026-03-31 9:11 UTC (permalink / raw)
To: Shawn Guo, Bjorn Andersson
Cc: Konrad Dybcio, Krzysztof Kozlowski, Manivannan Sadhasivam,
Mrinmay Sarkar, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260331090147.18522-1-shengchao.guo@oss.qualcomm.com>
On 3/31/26 11:01 AM, Shawn Guo wrote:
> These PCIe devices with MMIO address should be inside soc node rather
> than outside.
>
> Fixes: 489f14be0e0a ("arm64: dts: qcom: sa8775p: Add pcie0 and pcie1 nodes")
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> This is compile tested only!
I have no idea how this fell through the cracks in the first place
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 7/7] clk: qcom: Add support for global clock controller on Hawi
From: Taniya Das @ 2026-03-31 9:13 UTC (permalink / raw)
To: Vivek Aknurwar, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260330-clk-hawi-v1-7-c2a663e1d35b@oss.qualcomm.com>
On 3/31/2026 6:05 AM, Vivek Aknurwar wrote:
> Add support for the global clock controller (GCC) on the Hawi SoC.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 9 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/gcc-hawi.c | 3656 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 3666 insertions(+)
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH 5/7] clk: qcom: Add Hawi TCSR clock controller driver
From: Taniya Das @ 2026-03-31 9:13 UTC (permalink / raw)
To: Vivek Aknurwar, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260330-clk-hawi-v1-5-c2a663e1d35b@oss.qualcomm.com>
On 3/31/2026 6:05 AM, Vivek Aknurwar wrote:
> Add support for the TCSR clock controller found on Hawi SoCs.
> This controller provides reference clocks for various peripherals
> including PCIe, UFS, and USB.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 7 ++
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/tcsrcc-hawi.c | 158 +++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 166 insertions(+)
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH v3 6/7] arm64: dts: qcom: x1e80100: Add CAMCC block definition
From: Konrad Dybcio @ 2026-03-31 9:15 UTC (permalink / raw)
To: Jagadeesh Kona, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jagadeesh Kona,
Bryan O'Donoghue, Konrad Dybcio
Cc: Ajit Pandey, Imran Shaik, Taniya Das, linux-arm-msm, linux-clk,
devicetree, linux-kernel, Vladimir Zapolskiy, Abel Vesa
In-Reply-To: <20260331-purwa-videocc-camcc-v3-6-6daca180a4b1@oss.qualcomm.com>
On 3/31/26 7:24 AM, Jagadeesh Kona wrote:
> From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>
> Add the CAMCC block for x1e80100. The x1e80100 CAMCC block is an iteration
> of previous CAMCC blocks with the exception of having two required
> power-domains not just one. And update the compatible for camcc and
> videocc nodes on Purwa to match with their respective Purwa (X1P42100)
> specific drivers.
>
> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
> ---
Can I please get a definitive yes/no on this?
https://lore.kernel.org/linux-arm-msm/382725b5-1e72-44b2-b9ae-38aea1f7a976@oss.qualcomm.com/
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: usb: dwc3-xilinx: Add MMI USB support on Versal Gen2 platform
From: Pandey, Radhey Shyam @ 2026-03-31 9:18 UTC (permalink / raw)
To: Krzysztof Kozlowski, Radhey Shyam Pandey
Cc: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel, linux-usb, devicetree, linux-arm-kernel, linux-kernel,
git
In-Reply-To: <20260331-jellyfish-of-pragmatic-prowess-a230fc@quoll>
> On Tue, Mar 31, 2026 at 12:33:01AM +0530, Radhey Shyam Pandey wrote:
>> Versal Gen2 platform multimedia integrated (MMI) module has a USB3.2 Gen
>> 2x1 Dual Role Device IP. Introduce a new compatibility string to support
>> it. The USB wrapper registers reside in the MMI UDH system-level control
>> registers (SLCR) block, so instead of a dedicated reg property, add
>> xlnx,usb-syscon phandle with four cells specifying register offsets for
>> USB2 PHY, USB3 PHY, USB DRD, and USB power configuration within the SLCR.
>>
>> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
>> ---
>> Changes for v2:
>> - Add blank line after compatible as suggested by Krzysztof.
>> - Retain the mmi suffix in the compatible string, as this USB 3.2 Gen2
>> IP from Synopsys is part of the dedicated Multimedia Interface. The
>> Versal Gen2 platform also includes a separate USB 2.0 controller,
>> and the mmi suffix uniquely distinguishes between the two USB
>> controllers. MMI is an independent subsystem particularly targeted for
>> deployment in Multi-Media related applications. The MMI block include
>> following submodules: UDH: USB3.2 Gen 2x1 Dual Role Device, DisplayPort
>> Transmit Controller, Security Module (ESM) for DisplayPort and HDMI
>> Controllers, DP AUX-I2C PHY.
>> - For MMI USB define parent address space i.e UDH block.
>> - Fix inconsistent MHz spacing to use SI convention with spaces.
>> - Move description before $ref and items in xlnx,usb-syscon property.
>> - Restore original zynqmp-dwc3 example, add new versal2-mmi-dwc3 example.
>> - Use 'usb' node name (without unit address) for versal2 example since
>> it has no reg property.
>> - Use 1/1 address/size configuration in versal2 example, use lowercase
>> hex in syscon offsets.
>> ---
>> .../devicetree/bindings/usb/dwc3-xilinx.yaml | 70 ++++++++++++++++++-
>> 1 file changed, 67 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
>> index d6823ef5f9a7..5e31b961aff7 100644
>> --- a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
>> +++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
>> @@ -15,6 +15,8 @@ properties:
>> - enum:
>> - xlnx,zynqmp-dwc3
>> - xlnx,versal-dwc3
>> + - xlnx,versal2-mmi-dwc3
> I am not going to ask the same questions.
I have provided the explanation in v2 changelog.
Retain the mmi suffix in the compatible string, as this USB 3.2 Gen2
IP from Synopsys is part of the dedicated Multimedia Interface. The
Versal Gen2 platform also includes a separate USB 2.0 controller,
and the mmi suffix uniquely distinguishes between the two USB
controllers.
Let me know if you still have reservation in this approach (using
<vendor>,<soc>-<subsystem>-<ip>). Or any other alternative
based on IP version etc please suggest.
Thanks,
Radhey
^ permalink raw reply
* [PATCH v3 0/3] misc: ti_fpc202: Add LED support
From: Romain Gantois @ 2026-03-31 9:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Greg Kroah-Hartman
Cc: Felix Gu, Thomas Petazzoni, linux-kernel, devicetree,
Romain Gantois, Conor Dooley
Hi everyone,
This series depends on "misc: ti_fpc202: two small fixes" by Felix Gu:
https://lore.kernel.org/all/20260221-fp202-v1-0-4d28cb8b28fb@gmail.com/
The FPC202 dual port controller features eight special-purpose ports which
are meant to drive LEDs. These support PWM and blink offloading.
This is version three of my series which adds support for these
special-purpose LED ports.
Best Regards,
Romain
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
Changes in v3:
- Described LED line unit adresses in hexadecimal instead of decimal
- Made LED "label" property optional
- Link to v2: https://lore.kernel.org/r/20260226-fpc202-leds-v2-0-bc74857869e0@bootlin.com
Changes in v2:
- Avoided selecting foreign subsystems in Kconfig
- Rebased on conflicting bugfix series
- Link to v1: https://lore.kernel.org/r/20260127-fpc202-leds-v1-0-ebd0cfb9f9a1@bootlin.com
---
Romain Gantois (3):
misc: ti_fpc202: Depend on GPIOLIB instead of selecting it
dt-bindings: misc: Describe FPC202 LED features
misc: ti_fpc202: Support special-purpose GPIO lines with LED features
.../devicetree/bindings/misc/ti,fpc202.yaml | 21 ++
drivers/misc/Kconfig | 3 +-
drivers/misc/ti_fpc202.c | 339 ++++++++++++++++++++-
3 files changed, 349 insertions(+), 14 deletions(-)
---
base-commit: f552b769213459b62c976d3b380e7e0030af1920
change-id: 20260126-fpc202-leds-53def6ce751e
Best regards,
--
Romain Gantois <romain.gantois@bootlin.com>
^ permalink raw reply
* [PATCH v3 3/3] misc: ti_fpc202: Support special-purpose GPIO lines with LED features
From: Romain Gantois @ 2026-03-31 9:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Greg Kroah-Hartman
Cc: Felix Gu, Thomas Petazzoni, linux-kernel, devicetree,
Romain Gantois
In-Reply-To: <20260331-fpc202-leds-v3-0-74b173537d42@bootlin.com>
The FPC202 dual port controller has 20 regular GPIO lines and 8 special
GPIO lines with LED features. Each one of these "LED GPIOs" can output PWM
and blink signals.
Add support for the eight special-purpose GPIO lines to the existing FPC202
driver's GPIO support. Add support for registering led-class devices on
these GPIO lines.
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
drivers/misc/Kconfig | 1 +
drivers/misc/ti_fpc202.c | 339 +++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 327 insertions(+), 13 deletions(-)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index dcb36e39d7079..00683bf06258f 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -117,6 +117,7 @@ config TI_FPC202
tristate "TI FPC202 Dual Port Controller"
depends on I2C
depends on GPIOLIB
+ depends on LEDS_CLASS
select I2C_ATR
help
If you say yes here you get support for the Texas Instruments FPC202
diff --git a/drivers/misc/ti_fpc202.c b/drivers/misc/ti_fpc202.c
index 79a029d79f7a6..2aac83ec4a395 100644
--- a/drivers/misc/ti_fpc202.c
+++ b/drivers/misc/ti_fpc202.c
@@ -7,12 +7,17 @@
*/
#include <linux/cleanup.h>
+#include <linux/device/devres.h>
#include <linux/err.h>
#include <linux/i2c.h>
#include <linux/i2c-atr.h>
#include <linux/gpio/consumer.h>
#include <linux/gpio/driver.h>
+#include <linux/gpio/machine.h>
+#include <linux/leds.h>
#include <linux/module.h>
+#include <linux/math.h>
+#include <linux/types.h>
#define FPC202_NUM_PORTS 2
#define FPC202_ALIASES_PER_PORT 2
@@ -34,18 +39,55 @@
* ...
* 19: P1_S1_OUT_B
*
+ * Ports with optional LED control:
+ *
+ * 20: P0_S0_OUT_C (P0_S0_LED1)
+ * ...
+ * 23: P1_S1_OUT_C (P1_S1_LED1)
+ * 24: P0_S0_OUT_D (P0_S0_LED2
+ * ...
+ * 27: P1_S1_OUT_D (P1_S1_LED2)
+ *
*/
-#define FPC202_GPIO_COUNT 20
+#define FPC202_GPIO_COUNT 28
#define FPC202_GPIO_P0_S0_IN_B 4
#define FPC202_GPIO_P0_S0_OUT_A 12
+#define FPC202_GPIO_P0_S0_OUT_C 20
+#define FPC202_GPIO_P0_S0_OUT_D 24
#define FPC202_REG_IN_A_INT 0x6
#define FPC202_REG_IN_C_IN_B 0x7
#define FPC202_REG_OUT_A_OUT_B 0x8
+#define FPC202_REG_OUT_C_OUT_D 0x9
#define FPC202_REG_OUT_A_OUT_B_VAL 0xa
+#define FPC202_LED_COUNT 8
+
+/* There are four LED GPIO mode registers which manage two GPIOs each. */
+#define FPC202_REG_LED_MODE(offset) (0x1a + 0x20 * ((offset) % 4))
+
+/* LED1 GPIOs (*_OUT_C) are configured in bits 1:0, LED2 GPIOs (*_OUT_D) in bits 3:2. */
+#define FPC202_LED_MODE_SHIFT(offset) ((offset) < FPC202_GPIO_P0_S0_OUT_D ? 0 : 2)
+#define FPC202_LED_MODE_MASK(offset) (GENMASK(1, 0) << FPC202_LED_MODE_SHIFT(offset))
+
+/* There is one PWM control register for each GPIO LED */
+#define FPC202_REG_LED_PWM(offset) \
+ (((offset) < FPC202_GPIO_P0_S0_OUT_D ? 0x14 : 0x15) + 0x20 * ((offset) % 4))
+
+/* There are two blink delay registers (on/off time) for each GPIO LED */
+#define FPC202_REG_LED_BLINK_ON(offset) \
+ (((offset) < FPC202_GPIO_P0_S0_OUT_D ? 0x16 : 0x18) + 0x20 * ((offset) % 4))
+#define FPC202_REG_LED_BLINK_OFF(offset) (FPC202_REG_LED_BLINK_ON(offset) + 1)
+
+/* The actual hardware precision is 2.5ms but since the LED API doesn't handle sub-millisecond
+ * timesteps this is rounded up to 5ms
+ */
+#define FPC202_LED_BLINK_PRECISION 5UL
+
+#define FPC202_LED_MAX_BRIGHTNESS 255
+
#define FPC202_REG_MOD_DEV(port, dev) (0xb4 + ((port) * 4) + (dev))
#define FPC202_REG_AUX_DEV(port, dev) (0xb6 + ((port) * 4) + (dev))
@@ -59,15 +101,34 @@
/* Even aliases are assigned to device 0 and odd aliases to device 1 */
#define fpc202_dev_num_from_alias(alias) ((alias) % 2)
+enum fpc202_led_mode {
+ FPC202_LED_MODE_OFF = 0,
+ FPC202_LED_MODE_ON = 1,
+ FPC202_LED_MODE_PWM = 2,
+ FPC202_LED_MODE_BLINK = 3,
+};
+
+struct fpc202_led {
+ int offset;
+ struct led_classdev led_cdev;
+ struct fpc202_priv *priv;
+ struct gpio_desc *gpio;
+ enum fpc202_led_mode mode;
+};
+
struct fpc202_priv {
struct i2c_client *client;
struct i2c_atr *atr;
struct gpio_desc *en_gpio;
struct gpio_chip gpio;
+ struct fpc202_led leds[FPC202_LED_COUNT];
/* Lock REG_MOD/AUX_DEV and addr_caches during attach/detach */
struct mutex reg_dev_lock;
+ /* Lock LED mode select register during accesses */
+ struct mutex led_mode_lock;
+
/* Cached device addresses for both ports and their devices */
u8 addr_caches[2][2];
@@ -97,6 +158,11 @@ static int fpc202_gpio_get_dir(int offset)
return offset < FPC202_GPIO_P0_S0_OUT_A ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT;
}
+static int fpc202_gpio_has_led_caps(int offset)
+{
+ return offset >= FPC202_GPIO_P0_S0_OUT_C;
+}
+
static int fpc202_read(struct fpc202_priv *priv, u8 reg)
{
int val;
@@ -118,6 +184,37 @@ static void fpc202_set_enable(struct fpc202_priv *priv, int enable)
gpiod_set_value(priv->en_gpio, enable);
}
+static int fpc202_led_mode_write(struct fpc202_priv *priv,
+ int offset,
+ enum fpc202_led_mode mode)
+{
+ u8 val, reg = FPC202_REG_LED_MODE(offset);
+ int ret;
+
+ guard(mutex)(&priv->led_mode_lock);
+
+ ret = fpc202_read(priv, reg);
+ if (ret < 0) {
+ dev_err(&priv->client->dev, "failed to read LED mode %d! err %d\n",
+ offset, ret);
+ return ret;
+ }
+
+ val = (u8)ret & ~FPC202_LED_MODE_MASK(offset);
+ val |= mode << FPC202_LED_MODE_SHIFT(offset);
+
+ return fpc202_write(priv, reg, val);
+}
+
+static int fpc202_led_mode_set(struct fpc202_led *led, enum fpc202_led_mode mode)
+{
+ struct fpc202_priv *priv = led->priv;
+
+ led->mode = mode;
+
+ return fpc202_led_mode_write(priv, led->offset, mode);
+}
+
static int fpc202_gpio_set(struct gpio_chip *chip, unsigned int offset,
int value)
{
@@ -125,6 +222,16 @@ static int fpc202_gpio_set(struct gpio_chip *chip, unsigned int offset,
int ret;
u8 val;
+ if (fpc202_gpio_has_led_caps(offset)) {
+ ret = fpc202_led_mode_write(priv, offset,
+ value ? FPC202_LED_MODE_ON : FPC202_LED_MODE_OFF);
+ if (ret < 0)
+ dev_err(&priv->client->dev, "Failed to set GPIO %d LED mode! err %d\n",
+ offset, ret);
+
+ return ret;
+ }
+
ret = fpc202_read(priv, FPC202_REG_OUT_A_OUT_B_VAL);
if (ret < 0) {
dev_err(&priv->client->dev, "Failed to set GPIO %d value! err %d\n", offset, ret);
@@ -153,9 +260,11 @@ static int fpc202_gpio_get(struct gpio_chip *chip, unsigned int offset)
} else if (offset < FPC202_GPIO_P0_S0_OUT_A) {
reg = FPC202_REG_IN_C_IN_B;
bit = BIT(offset - FPC202_GPIO_P0_S0_IN_B);
- } else {
+ } else if (!fpc202_gpio_has_led_caps(offset)) {
reg = FPC202_REG_OUT_A_OUT_B_VAL;
bit = BIT(offset - FPC202_GPIO_P0_S0_OUT_A);
+ } else {
+ return -EOPNOTSUPP;
}
ret = fpc202_read(priv, reg);
@@ -177,21 +286,29 @@ static int fpc202_gpio_direction_output(struct gpio_chip *chip, unsigned int off
int value)
{
struct fpc202_priv *priv = gpiochip_get_data(chip);
+ u8 reg, val, bit;
int ret;
- u8 val;
if (fpc202_gpio_get_dir(offset) == GPIO_LINE_DIRECTION_IN)
return -EINVAL;
fpc202_gpio_set(chip, offset, value);
- ret = fpc202_read(priv, FPC202_REG_OUT_A_OUT_B);
+ if (fpc202_gpio_has_led_caps(offset)) {
+ reg = FPC202_REG_OUT_C_OUT_D;
+ bit = BIT(offset - FPC202_GPIO_P0_S0_OUT_C);
+ } else {
+ reg = FPC202_REG_OUT_A_OUT_B;
+ bit = BIT(offset - FPC202_GPIO_P0_S0_OUT_A);
+ }
+
+ ret = fpc202_read(priv, reg);
if (ret < 0)
return ret;
- val = (u8)ret | BIT(offset - FPC202_GPIO_P0_S0_OUT_A);
+ val = (u8)ret | bit;
- return fpc202_write(priv, FPC202_REG_OUT_A_OUT_B, val);
+ return fpc202_write(priv, reg, val);
}
/*
@@ -264,6 +381,183 @@ static const struct i2c_atr_ops fpc202_atr_ops = {
.detach_addr = fpc202_detach_addr,
};
+static struct fpc202_led *fpc202_cdev_to_led(struct led_classdev *cdev)
+{
+ return container_of(cdev, struct fpc202_led, led_cdev);
+}
+
+static struct fpc202_led *fpc202_led_get(struct fpc202_priv *priv, int offset)
+{
+ return &priv->leds[offset - FPC202_GPIO_P0_S0_OUT_C];
+}
+
+static int fpc202_led_blink_set(struct led_classdev *cdev,
+ unsigned long *delay_on,
+ unsigned long *delay_off)
+{
+ struct fpc202_led *led = fpc202_cdev_to_led(cdev);
+ struct fpc202_priv *priv = led->priv;
+ unsigned long val;
+ int ret;
+
+ if (*delay_on == 0 && *delay_off == 0) {
+ *delay_on = 250;
+ *delay_off = 250;
+ } else {
+ if (*delay_on % FPC202_LED_BLINK_PRECISION)
+ *delay_on = roundup(*delay_on, FPC202_LED_BLINK_PRECISION);
+
+ if (*delay_off % FPC202_LED_BLINK_PRECISION)
+ *delay_off = roundup(*delay_off, FPC202_LED_BLINK_PRECISION);
+ }
+
+ /* Multiply the duration by two, since the actual precision is 2.5ms not 5ms*/
+ val = 2 * (*delay_on / FPC202_LED_BLINK_PRECISION);
+ if (val > 255) {
+ val = 255;
+ *delay_on = (val / 2) * FPC202_LED_BLINK_PRECISION;
+ }
+
+ ret = fpc202_write(priv, FPC202_REG_LED_BLINK_ON(led->offset), val);
+ if (ret) {
+ dev_err(&priv->client->dev,
+ "Failed to set blink on duration for LED %d, err %d\n",
+ led->offset, ret);
+ return ret;
+ }
+
+ val = 2 * (*delay_off / FPC202_LED_BLINK_PRECISION);
+ if (val > 255) {
+ val = 255;
+ *delay_off = (val / 2) * FPC202_LED_BLINK_PRECISION;
+ }
+
+ ret = fpc202_write(priv, FPC202_REG_LED_BLINK_OFF(led->offset), val);
+ if (ret) {
+ dev_err(&priv->client->dev,
+ "Failed to set blink off duration for LED %d, err %d\n",
+ led->offset, ret);
+ return ret;
+ }
+
+ return fpc202_led_mode_set(led, FPC202_LED_MODE_BLINK);
+}
+
+static enum led_brightness fpc202_led_brightness_get(struct led_classdev *cdev)
+{
+ struct fpc202_led *led = fpc202_cdev_to_led(cdev);
+
+ if (led->mode == FPC202_LED_MODE_OFF)
+ return LED_OFF;
+
+ return LED_ON;
+}
+
+static int fpc202_led_brightness_set(struct led_classdev *cdev,
+ enum led_brightness brightness)
+{
+ struct fpc202_led *led = fpc202_cdev_to_led(cdev);
+ struct fpc202_priv *priv = led->priv;
+ int ret;
+
+ if (!brightness)
+ return fpc202_led_mode_set(led, FPC202_LED_MODE_OFF);
+
+ if (led->mode != FPC202_LED_MODE_BLINK) {
+ if (brightness == FPC202_LED_MAX_BRIGHTNESS)
+ return fpc202_led_mode_set(led, FPC202_LED_MODE_ON);
+
+ ret = fpc202_led_mode_set(led, FPC202_LED_MODE_PWM);
+ if (ret) {
+ dev_err(&priv->client->dev, "Failed to set LED %d mode, err %d\n",
+ led->offset, ret);
+ return ret;
+ }
+ }
+
+ return fpc202_write(priv, FPC202_REG_LED_PWM(led->offset), brightness);
+}
+
+static int fpc202_register_led(struct fpc202_priv *priv, int offset,
+ struct device_node *led_handle)
+{
+ struct fpc202_led *led = fpc202_led_get(priv, offset);
+ struct device *dev = &priv->client->dev;
+ struct led_init_data init_data = { };
+ int ret = 0;
+
+ led->priv = priv;
+ led->offset = offset;
+ led->led_cdev.max_brightness = FPC202_LED_MAX_BRIGHTNESS;
+ led->led_cdev.brightness_set_blocking = fpc202_led_brightness_set;
+ led->led_cdev.brightness_get = fpc202_led_brightness_get;
+ led->led_cdev.blink_set = fpc202_led_blink_set;
+
+ init_data.fwnode = of_fwnode_handle(led_handle);
+ init_data.default_label = NULL;
+ init_data.devicename = NULL;
+ init_data.devname_mandatory = false;
+
+ ret = fpc202_led_mode_set(led, FPC202_LED_MODE_OFF);
+ if (ret) {
+ dev_err(dev, "Failed to set LED %d mode, err %d\n", offset, ret);
+ return ret;
+ }
+
+ ret = devm_led_classdev_register_ext(dev, &led->led_cdev, &init_data);
+ if (ret) {
+ dev_err(dev, "Failed to register LED %d cdev, err %d\n", offset, ret);
+ return ret;
+ }
+
+ /* Claim corresponding GPIO line so that it cannot be interfered with */
+ led->gpio = gpiochip_request_own_desc(&priv->gpio, offset, led->led_cdev.name,
+ GPIO_ACTIVE_HIGH, GPIOD_ASIS);
+ if (IS_ERR(led->gpio)) {
+ ret = PTR_ERR(led->gpio);
+ dev_err(dev, "Failed to register LED %d cdev, err %d\n", offset, ret);
+ }
+
+ return ret;
+}
+
+static int fpc202_register_leds(struct fpc202_priv *priv)
+{
+ struct device *dev = &priv->client->dev;
+ int offset, ret = 0;
+
+ if (!devres_open_group(dev, fpc202_register_leds, GFP_KERNEL))
+ return -ENOMEM;
+
+ for_each_child_of_node_scoped(dev->of_node, led_handle) {
+ ret = of_property_read_u32(led_handle, "reg", &offset);
+ if (ret) {
+ dev_err(dev, "Failed to read 'reg' property of child node, err %d\n", ret);
+ return ret;
+ }
+
+ if (offset < FPC202_GPIO_P0_S0_OUT_C || offset > FPC202_GPIO_COUNT)
+ continue;
+
+ ret = fpc202_register_led(priv, offset, led_handle);
+ if (ret) {
+ dev_err(dev, "Failed to register LED %d, err %d\n", offset,
+ ret);
+ goto free_own_gpios;
+ }
+ }
+
+ devres_close_group(dev, fpc202_register_leds);
+
+ return 0;
+
+free_own_gpios:
+ for (offset = 0; offset < FPC202_LED_COUNT; offset++)
+ if (priv->leds[offset].gpio)
+ gpiochip_free_own_desc(priv->leds[offset].gpio);
+ return ret;
+}
+
static int fpc202_probe_port(struct fpc202_priv *priv, struct device_node *i2c_handle, int port_id)
{
u16 aliases[FPC202_ALIASES_PER_PORT] = { };
@@ -302,13 +596,14 @@ static int fpc202_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
struct fpc202_priv *priv;
- int ret, port_id;
+ int ret, port_id, led_id;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
mutex_init(&priv->reg_dev_lock);
+ mutex_init(&priv->led_mode_lock);
priv->client = client;
i2c_set_clientdata(client, priv);
@@ -346,6 +641,12 @@ static int fpc202_probe(struct i2c_client *client)
i2c_atr_set_driver_data(priv->atr, priv);
+ ret = fpc202_register_leds(priv);
+ if (ret) {
+ dev_err(dev, "Failed to register LEDs, err %d\n", ret);
+ goto delete_atr;
+ }
+
bitmap_zero(priv->probed_ports, FPC202_NUM_PORTS);
for_each_child_of_node_scoped(dev->of_node, i2c_handle) {
@@ -358,11 +659,8 @@ static int fpc202_probe(struct i2c_client *client)
goto unregister_chans;
}
- if (port_id >= FPC202_NUM_PORTS) {
- dev_err(dev, "port ID %d is out of range!\n", port_id);
- ret = -EINVAL;
- goto unregister_chans;
- }
+ if (port_id >= FPC202_NUM_PORTS)
+ continue;
ret = fpc202_probe_port(priv, i2c_handle, port_id);
if (ret) {
@@ -377,11 +675,18 @@ static int fpc202_probe(struct i2c_client *client)
for_each_set_bit(port_id, priv->probed_ports, FPC202_NUM_PORTS)
fpc202_remove_port(priv, port_id);
+ for (led_id = 0; led_id < FPC202_LED_COUNT; led_id++)
+ if (priv->leds[led_id].gpio)
+ gpiochip_free_own_desc(priv->leds[led_id].gpio);
+
+ devres_release_group(&client->dev, fpc202_register_leds);
+delete_atr:
i2c_atr_delete(priv->atr);
disable_gpio:
fpc202_set_enable(priv, 0);
gpiochip_remove(&priv->gpio);
destroy_mutex:
+ mutex_destroy(&priv->led_mode_lock);
mutex_destroy(&priv->reg_dev_lock);
out:
return ret;
@@ -390,11 +695,19 @@ static int fpc202_probe(struct i2c_client *client)
static void fpc202_remove(struct i2c_client *client)
{
struct fpc202_priv *priv = i2c_get_clientdata(client);
- int port_id;
+ int port_id, led_id;
for_each_set_bit(port_id, priv->probed_ports, FPC202_NUM_PORTS)
fpc202_remove_port(priv, port_id);
+ for (led_id = 0; led_id < FPC202_LED_COUNT; led_id++)
+ if (priv->leds[led_id].gpio)
+ gpiochip_free_own_desc(priv->leds[led_id].gpio);
+
+ /* Release led devices early so that blink handlers don't trigger. */
+ devres_release_group(&client->dev, fpc202_register_leds);
+
+ mutex_destroy(&priv->led_mode_lock);
mutex_destroy(&priv->reg_dev_lock);
i2c_atr_delete(priv->atr);
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/3] misc: ti_fpc202: Depend on GPIOLIB instead of selecting it
From: Romain Gantois @ 2026-03-31 9:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Greg Kroah-Hartman
Cc: Felix Gu, Thomas Petazzoni, linux-kernel, devicetree,
Romain Gantois
In-Reply-To: <20260331-fpc202-leds-v3-0-74b173537d42@bootlin.com>
Selecting a foreign subsystem such as GPIOLIB may lead to dependency loops.
Use a "depends on" instead.
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
drivers/misc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 5cc79d1517af5..dcb36e39d7079 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -116,7 +116,7 @@ config RPMB
config TI_FPC202
tristate "TI FPC202 Dual Port Controller"
depends on I2C
- select GPIOLIB
+ depends on GPIOLIB
select I2C_ATR
help
If you say yes here you get support for the Texas Instruments FPC202
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/3] dt-bindings: misc: Describe FPC202 LED features
From: Romain Gantois @ 2026-03-31 9:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Greg Kroah-Hartman
Cc: Felix Gu, Thomas Petazzoni, linux-kernel, devicetree,
Romain Gantois, Conor Dooley
In-Reply-To: <20260331-fpc202-leds-v3-0-74b173537d42@bootlin.com>
The FPC202 dual port controller has 20 regular GPIO lines and 8 special
GPIO lines with LED features. Each one of these "LED GPIOs" can output PWM
and blink signals.
Describe these special-purpose GPIO lines.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
.../devicetree/bindings/misc/ti,fpc202.yaml | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/ti,fpc202.yaml b/Documentation/devicetree/bindings/misc/ti,fpc202.yaml
index a8cb10f2d0df3..71c5859d2e135 100644
--- a/Documentation/devicetree/bindings/misc/ti,fpc202.yaml
+++ b/Documentation/devicetree/bindings/misc/ti,fpc202.yaml
@@ -53,6 +53,22 @@ patternProperties:
unevaluatedProperties: false
+ "^led@1[4-b]$":
+ $ref: /schemas/leds/common.yaml#
+ description: Output GPIO line with advanced LED features enabled.
+
+ properties:
+ reg:
+ minimum: 0x14
+ maximum: 0x1b
+ description:
+ GPIO line ID
+
+ required:
+ - reg
+
+ unevaluatedProperties: false
+
required:
- compatible
- reg
@@ -89,6 +105,11 @@ examples:
#size-cells = <0>;
reg = <1>;
};
+
+ led@14 {
+ reg = <0x14>;
+ label = "phy0:green:indicator";
+ };
};
};
...
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/1] arm64: dts: imx91-var-dart-sonata: add RGB enable supply for PCA6408
From: Stefano Radaelli @ 2026-03-31 9:21 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
From: Stefano Radaelli <stefano.r@variscite.com>
RGB enable pin, labeled as RGBSEL, is a board-level enable signal on
the Sonata carrier board.
The two PCA6408 GPIO expanders depend on this signal being asserted, so
model it as a fixed regulator and use it as their vcc-supply.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
- Fixed commit message and RGB pin references.
arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
index afa39dab240a..3f0fd321d95f 100644
--- a/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
@@ -90,6 +90,13 @@ reg_vref_1v8: regulator-adc-vref {
regulator-max-microvolt = <1800000>;
};
+ reg_rgb_sel: regulator-rgb-enable {
+ compatible = "regulator-fixed";
+ regulator-name = "RGBSEL";
+ gpio = <&pca9534 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -195,6 +202,7 @@ pca6408_1: gpio@20 {
#gpio-cells = <2>;
interrupt-parent = <&gpio1>;
interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ vcc-supply = <®_rgb_sel>;
};
pca6408_2: gpio@21 {
@@ -204,6 +212,7 @@ pca6408_2: gpio@21 {
#gpio-cells = <2>;
interrupt-parent = <&gpio1>;
interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ vcc-supply = <®_rgb_sel>;
};
pca9534: gpio@22 {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 2/3] clk: qcom: Add support for GXCLK for Milos
From: Taniya Das @ 2026-03-31 9:23 UTC (permalink / raw)
To: Luca Weiss, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, linux-clk,
devicetree, linux-kernel
In-Reply-To: <20260306-milos-gxclkctl-v1-2-00b09ee159a7@fairphone.com>
On 3/6/2026 7:18 PM, Luca Weiss wrote:
> GXCLKCTL (Graphics GX Clock Controller) is a block dedicated to managing
> clocks for the GPU subsystem on GX power domain. The GX clock controller
> driver manages only the GX GDSC and the rest of the resources of the
> controller are managed by the firmware.
>
> We can use the existing kaanapali driver for Milos as well since the
> GX_CLKCTL_GX_GDSC supported by the Linux driver requires the same
> configuration.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH 4/7] clk: qcom: rpmh: Add support for Hawi RPMH clocks
From: Konrad Dybcio @ 2026-03-31 9:30 UTC (permalink / raw)
To: Vivek Aknurwar, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Taniya Das
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260330-clk-hawi-v1-4-c2a663e1d35b@oss.qualcomm.com>
On 3/31/26 2:34 AM, Vivek Aknurwar wrote:
> Add RPMH clocks present in Hawi the SoC.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v4 01/11] dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
From: Harshal Dev @ 2026-03-31 9:40 UTC (permalink / raw)
To: Kuldeep Singh, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Abel Vesa, Manivannan Sadhasivam, cros-qcom-dts-watchers,
Eric Biggers, Dmitry Baryshkov, Jingyi Wang, Tengfei Fan,
Bartosz Golaszewski, David Wronek, Luca Weiss, Neil Armstrong,
Melody Olvera, Alexander Koskovich
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Krzysztof Kozlowski
In-Reply-To: <873e8ad2-50cd-4c09-9a51-20ad745fe8dc@oss.qualcomm.com>
Hi Kuldeep,
On 3/24/2026 4:16 PM, Kuldeep Singh wrote:
>
> On 3/23/2026 2:47 PM, Harshal Dev wrote:
>> The DT bindings for inline-crypto engine do not specify the UFS_PHY_GDSC
>> power-domain and iface clock. Without enabling the iface clock and the
>> associated power-domain the ICE hardware cannot function correctly and
>> leads to unclocked hardware accesses being observed during probe.
>>
>> Fix the DT bindings for inline-crypto engine to require the UFS_PHY_GDSC
>> power-domain and iface clock for new devices (Eliza and Milos) introduced
>> in the current release (7.0) with yet-to-stabilize ABI, while preserving
>> backward compatibility for older devices.
>>
>> Fixes: 618195a7ac3df ("dt-bindings: crypto: qcom,inline-crypto-engine: Document the Eliza ICE")
>> Fixes: 85faec1e85555 ("dt-bindings: crypto: qcom,inline-crypto-engine: document the Milos ICE")
>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>> ---
>> .../bindings/crypto/qcom,inline-crypto-engine.yaml | 35 +++++++++++++++++++++-
>> 1 file changed, 34 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> index 876bf90ed96e..ccb6b8dd8e11 100644
>> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> @@ -30,6 +30,16 @@ properties:
>> maxItems: 1
>>
>> clocks:
>> + minItems: 1
>> + maxItems: 2
>> +
>> + clock-names:
>> + minItems: 1
>> + items:
>> + - const: core
>> + - const: iface
>> +
>> + power-domains:
>> maxItems: 1
>>
>> operating-points-v2: true
>> @@ -44,6 +54,25 @@ required:
>>
>> additionalProperties: false
>>
>> +allOf:
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - qcom,eliza-inline-crypto-engine
>> + - qcom,milos-inline-crypto-engine
>> +
>> + then:
>> + required:
>> + - power-domains
>> + - clock-names
>> + properties:
>> + clocks:
>> + minItems: 2
>> + clock-names:
>> + minItems: 2
>> +
>
> Hi Krzysztof,
>
> As motive here is to enforce 2 clocks for upcoming targets and keep
> minItems as 1 for already merged ones for ensuring backward
> compatibility. Can we do like below?
>
> allOf:
> - if:
> not:
> properties:
> compatible:
> contains:
> enum:
> - qcom,kaanapali-inline-crypto-engine
> - qcom,qcs8300-inline-crypto-engine
> - qcom,sa8775p-inline-crypto-engine
> - qcom,sc7180-inline-crypto-engine
> - qcom,sc7280-inline-crypto-engine
> - qcom,sm8450-inline-crypto-engine
> - qcom,sm8550-inline-crypto-engine
> - qcom,sm8650-inline-crypto-engine
> - qcom,sm8750-inline-crypto-engine
>
> then:
> required:
> - power-domains
> - clock-names
> properties:
> clocks:
> minItems: 2
> clock-names:
> minItems: 2
>
> This will ensure for every new target addition, default clock count is
> enforced as 2 default.
> Please share your thoughts as well.
>
I don't really have any particular objections to this proposal, but I can
see that other bindings where the need for an additional clock was realized
later on use a similar pattern as this patchset does:
https://elixir.bootlin.com/linux/v7.0-rc2/source/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
I'll wait for Krzysztof to take a final call on this.
Regards,
Harshal
^ permalink raw reply
* Re: [PATCH v8 2/3] hwmon: ltc4283: Add support for the LTC4283 Swap Controller
From: Nuno Sá @ 2026-03-31 9:48 UTC (permalink / raw)
To: Guenter Roeck
Cc: Nuno Sá, linux-gpio, linux-hwmon, devicetree, linux-doc,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Linus Walleij, Bartosz Golaszewski
In-Reply-To: <e0c96f38-6742-4b86-8938-64e4e6063119@roeck-us.net>
On Mon, Mar 30, 2026 at 08:47:32AM -0700, Guenter Roeck wrote:
> On 3/30/26 02:28, Nuno Sá wrote:
> > Hi Guenter, Regarding AI review, I think most of the points were
> > discussed in previous revisions, but there are two valid.
> >
> > On Fri, Mar 27, 2026 at 05:26:15PM +0000, Nuno Sá wrote:
> > > Support the LTC4283 Hot Swap Controller. The device features programmable
> > > current limit with foldback and independently adjustable inrush current to
> > > optimize the MOSFET safe operating area (SOA). The SOA timer limits MOSFET
> > > temperature rise for reliable protection against overstresses.
> > >
> > > An I2C interface and onboard ADC allow monitoring of board current,
> > > voltage, power, energy, and fault status.
> > >
> > > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > > ---
> > > Documentation/hwmon/index.rst | 1 +
> > > Documentation/hwmon/ltc4283.rst | 266 ++++++
> > > MAINTAINERS | 1 +
> > > drivers/hwmon/Kconfig | 12 +
> > > drivers/hwmon/Makefile | 1 +
> > > drivers/hwmon/ltc4283.c | 1796 +++++++++++++++++++++++++++++++++++++++
> > > 6 files changed, 2077 insertions(+)
> > >
> >
> > ...
> >
> > > +static int ltc4283_read_in_alarm(struct ltc4283_hwmon *st, u32 channel,
> > > + bool max_alm, long *val)
> > > +{
> > > + if (channel == LTC4283_VPWR)
> > > + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_1,
> > > + BIT(2 + max_alm), val);
> > > +
> > > + if (channel >= LTC4283_CHAN_ADI_1 && channel <= LTC4283_CHAN_ADI_4) {
> > > + u32 bit = (channel - LTC4283_CHAN_ADI_1) * 2;
> > > + /*
> > > + * Lower channels go to higher bits. We also want to go +1 down
> > > + * in the min_alarm case.
> > > + */
> > > + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_2,
> > > + BIT(7 - bit - !max_alm), val);
> > > + }
> > > +
> > > + if (channel >= LTC4283_CHAN_ADIO_1 && channel <= LTC4283_CHAN_ADIO_4) {
> > > + u32 bit = (channel - LTC4283_CHAN_ADIO_1) * 2;
> > > +
> > > + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_3,
> > > + BIT(7 - bit - !max_alm), val);
> > > + }
> > > +
> > > + if (channel >= LTC4283_CHAN_ADIN12 && channel <= LTC4283_CHAN_ADIN34) {
> > > + u32 bit = (channel - LTC4283_CHAN_ADIN12) * 2;
> > > +
> > > + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_5,
> > > + BIT(7 - bit - !max_alm), val);
> > > + }
> >
> > "Will this condition handle the ADIO12 and ADIO34 differential channels?
> > It looks like channels 14 and 15 fall through to the default return intended
> > for the DRAIN channel. Since reading the alarm implicitly clears the register
> > bits, could reading these ADIO alarms unintentionally clear actual DRAIN
> > alarms? Should the upper bound be LTC4283_CHAN_ADIO34?"
> >
> > Good catch and should be:
> >
> > - if (channel >= LTC4283_CHAN_ADIN12 && channel <= LTC4283_CHAN_ADIN34) {
> > + if (channel >= LTC4283_CHAN_ADIN12 && channel <= LTC4283_CHAN_ADIO34) {
> >
> > > +
> > > + if (channel == LTC4283_CHAN_DRNS)
> > > + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_4,
> > > + BIT(6 + max_alm), val);
> > > +
> > > + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_4, BIT(4 + max_alm),
> > > + val);
> > > +}
> >
> > ...
> >
> > > +
> > > +static int ltc4283_probe(struct i2c_client *client)
> > > +{
> > > + struct device *dev = &client->dev, *hwmon;
> > > + struct auxiliary_device *adev;
> > > + struct ltc4283_hwmon *st;
> > > + int ret;
> > > +
> > > + st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
> > > + if (!st)
> > > + return -ENOMEM;
> > > +
> > > + if (!i2c_check_functionality(client->adapter,
> > > + I2C_FUNC_SMBUS_BYTE_DATA |
> > > + I2C_FUNC_SMBUS_WORD_DATA |
> > > + I2C_FUNC_SMBUS_READ_I2C_BLOCK))
> > > + return -EOPNOTSUPP;
> > > +
> > > + st->client = client;
> > > + st->map = devm_regmap_init(dev, <c4283_regmap_bus, client,
> > > + <c4283_regmap_config);
> > > + if (IS_ERR(st->map))
> > > + return dev_err_probe(dev, PTR_ERR(st->map),
> > > + "Failed to create regmap\n");
> > > +
> > > + ret = ltc4283_setup(st, dev);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + hwmon = devm_hwmon_device_register_with_info(dev, "ltc4283", st,
> > > + <c4283_chip_info, NULL);
> > > +
> > > + if (IS_ERR(hwmon))
> > > + return PTR_ERR(hwmon);
> > > +
> > > + ltc4283_debugfs_init(st, client);
> > > +
> > > + if (!st->gpio_mask)
> > > + return 0;
> > > +
> > > + adev = devm_auxiliary_device_create(dev, "gpio", &st->gpio_mask);
> > > + if (!adev)
> > > + return dev_err_probe(dev, -ENODEV, "Failed to add GPIO device\n");
> >
> > "Does this allow multiple LTC4283 chips to probe successfully?
> > Without allocating a unique ID per I2C instance, it seems the first probed
> > chip takes the generic name. If a second chip is present, it might attempt
> > to register with the exact same name, resulting in a failure in device_add()
> > and aborting the probe."
> >
> > Also looks valid and I suspect is one of those that a quick look will
> > find more "offenders". I would purpose:
> >
> > - adev = devm_auxiliary_device_create(dev, "gpio", &st->gpio_mask);
> > + adev = __devm_auxiliary_device_create(dev, KBUILD_MODNAME, "gpio",
> > + &st->gpio_mask, client->addr);
> >
>
> That would still fail if there are multiple chips at the same I2C address
> on multiple I2C busses. Check drivers/gpu/drm/bridge/ti-sn65dsi86.c which has
> the same problem.
I did looked at that one but totally forgot the multiple busses
scenario.
>
> > If there's nothing else and you agree with the above, is this something
> > you can tweak while applying or should I spin a new version?
> >
>
> Please respin. Also, regarding the other concerns:
>
> Can BIT(8) * st->rsense wrap to zero on 32-bit architectures?
> BIT(8) is a 32-bit unsigned long and st->rsense is a u32. If a user sets a
> very large sense resistor value via the device tree, the multiplication could
> wrap to 0, causing a division-by-zero kernel panic. Should the divisor use
> BIT_ULL(8)?
>
> Unless I am missing something, this _can_ overflow. Try to provide a sense
> resistor value of 1677721600. Yes, it is unreasonable to specify such large
> rsense values, but why not just limit it such that it does not overflow ?
Yes, that's pretty much my reasoning (regarding the unreasonable
rsense). I could just make BIT_ULL() and be done with it. I can also
also cap rsense to a max value but i'm not 100% what that value would
be. Maybe 1 ohm is already more than reasonable. I can also ask internally. Any
preference on this one?
>
> Also, for the overflow concerns, if you are sure they can not happen, I'll
> really need to write the unit test code to make sure that this is indeed
> the case.
>
Hmm, for the val * MILLI case, well it should not happen but given it
depends on user input, better if I clamp it before passing the
value to ltc4283_write_in_byte(). Yes, we clamp again inside the
write_bytes() API but not a big deal.
For the st->power_max is again one of those cases where the values would
not make sense (I think - the combination of vsense_max and rsense). Just looking
at the code, it can overflow but this one I'm not really sure how we could handle it.
Maybe clamp power_max to U8_MAX and have a warning message in ltc4283_read_power_byte() if
we overflow long in which case we need a power64 attr?
But even clamping does not make much sense here. The power limit register
is 8 bits, so if our design (rsense + vsense_max) overflows that,
there's nothing we can do other that erroring out.
- Nuno Sá
> Thanks,
> Guenter
>
^ permalink raw reply
* Re: [PATCH v2 4/5] phy: qcom: qmp-pcie: Add Gen5 8-lanes mode for Glymur
From: Qiang Yu @ 2026-03-31 9:59 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <x3ts7to7c4qnorloahe7cgup3uekn4wolmmorqa3b3bjfslqfn@eijnzdp2ops3>
On Tue, Mar 24, 2026 at 11:23:19PM +0200, Dmitry Baryshkov wrote:
> On Mon, Mar 23, 2026 at 12:15:31AM -0700, Qiang Yu wrote:
> > The third PCIe controller on Glymur SoC supports 8-lane operation via
> > bifurcation of two PHYs (each requires separate power domian, resets and
> > aux clk).
> >
> > Add dedicated reset/no_csr reset list ("phy_b", "phy_b_nocsr") and
> > clock ("phy_b_aux") required for 8-lane operation. Introduce new
> > glymur_qmp_gen5x8_pciephy_cfg configuration to enable PCIe Gen5 x8 mode.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> > drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 30 +++++++++++++++++++++++++++++-
> > 1 file changed, 29 insertions(+), 1 deletion(-)
> >
> > @@ -4705,6 +4713,23 @@ static const struct qmp_phy_cfg glymur_qmp_gen4x2_pciephy_cfg = {
> > .phy_status = PHYSTATUS_4_20,
> > };
> >
> > +static const struct qmp_phy_cfg glymur_qmp_gen5x8_pciephy_cfg = {
> > + .lanes = 8,
> > +
> > + .offsets = &qmp_pcie_offsets_v8_50,
> > +
> > + .reset_list = glymur_pciephy_reset_l,
> > + .num_resets = ARRAY_SIZE(glymur_pciephy_reset_l),
> > + .nocsr_reset_list = glymur_pciephy_nocsr_reset_l,
> > + .num_nocsr_resets = ARRAY_SIZE(glymur_pciephy_nocsr_reset_l),
>
> Just for my understanding. If it was not the NOCSR case and had to
> program the registers, would we have needed to program anything in the
> PCIe3B space?
The PCIe3B PHY registers need to be programmed.
But we don't need to do it explicitly because there are also broadcast
registers: writing to these registers will automatically write the same
offset and value to both PHY ports simultaneously.
- Qiang Yu
>
> > + .vreg_list = qmp_phy_vreg_l,
> > + .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
> > +
> > + .regs = pciephy_v8_50_regs_layout,
> > +
> > + .phy_status = PHYSTATUS_4_20,
> > +};
> > +
> > static void qmp_pcie_init_port_b(struct qmp_pcie *qmp, const struct qmp_phy_cfg_tbls *tbls)
> > {
> > const struct qmp_phy_cfg *cfg = qmp->cfg;
> > @@ -5483,6 +5508,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
> > }, {
> > .compatible = "qcom,glymur-qmp-gen5x4-pcie-phy",
> > .data = &glymur_qmp_gen5x4_pciephy_cfg,
> > + }, {
> > + .compatible = "qcom,glymur-qmp-gen5x8-pcie-phy",
> > + .data = &glymur_qmp_gen5x8_pciephy_cfg,
> > }, {
> > .compatible = "qcom,ipq6018-qmp-pcie-phy",
> > .data = &ipq6018_pciephy_cfg,
> >
> > --
> > 2.34.1
> >
>
> --
> With best wishes
> Dmitry
^ permalink raw reply
* Re: [PATCH v2 5/5] arch: arm64: dts: qcom: Add support for PCIe3a
From: Qiang Yu @ 2026-03-31 10:00 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <odmf4zxf4p3luqimkbhggg6cyvjnlfhjsqsvpwpu5ctkviogrj@bmazfab5hb5y>
On Tue, Mar 24, 2026 at 11:21:19PM +0200, Dmitry Baryshkov wrote:
> On Mon, Mar 23, 2026 at 12:15:32AM -0700, Qiang Yu wrote:
> > Describe PCIe3a controller and PHY. Also add required system resources
> > like regulators, clocks, interrupts and registers configuration for PCIe3a.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> > arch/arm64/boot/dts/qcom/glymur.dtsi | 314 ++++++++++++++++++++++++++++++++++-
> > 1 file changed, 313 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> > index bde287f645ee94116a489c55be3b7b80db3815e9..52104607a1713323fdfe2e7de710e38c1e22d06e 100644
> > --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> > @@ -736,7 +736,7 @@ gcc: clock-controller@100000 {
> > <0>, /* USB 2 Phy PCIE PIPEGMUX */
> > <0>, /* USB 2 Phy PIPEGMUX */
> > <0>, /* USB 2 Phy SYS PCIE PIPEGMUX */
> > - <0>, /* PCIe 3a */
> > + <&pcie3a_phy>, /* PCIe 3a */
> > <&pcie3b_phy>, /* PCIe 3b */
> > <&pcie4_phy>, /* PCIe 4 */
> > <&pcie5_phy>, /* PCIe 5 */
> > @@ -2360,6 +2360,318 @@ pcie_west_slv_noc: interconnect@1920000 {
> > #interconnect-cells = <2>;
> > };
> >
> > + pcie3a: pci@1c10000 {
>
> Incorrect placement. 1c10000 > 1bf0000.
>
> > + device_type = "pci";
> > + compatible = "qcom,glymur-pcie", "qcom,pcie-x1e80100";
> > + reg = <0x0 0x01c10000 0x0 0x3000>,
> > + <0x0 0x70000000 0x0 0xf20>,
> > + <0x0 0x70000f40 0x0 0xa8>,
> > + <0x0 0x70001000 0x0 0x4000>,
> > + <0x0 0x70100000 0x0 0x100000>,
> > + <0x0 0x01c13000 0x0 0x1000>;
>
> [...]
>
> > + };
> > +
> > + pcie3a_phy: phy@f00000 {
>
> This one too, it should be before PCIe3b PHY.
Okay, will change them.
- Qiang Yu
>
> > + compatible = "qcom,glymur-qmp-gen5x8-pcie-phy";
> > + reg = <0 0x00f00000 0 0x10000>;
> > +
>
> [...]
>
> > + };
> > +
> > pcie4: pci@1bf0000 {
> > device_type = "pci";
> > compatible = "qcom,glymur-pcie", "qcom,pcie-x1e80100";
> >
> > --
> > 2.34.1
> >
>
> --
> With best wishes
> Dmitry
^ permalink raw reply
* [PATCH 0/2] Enable Mali G310 GPU support on i.MX952 board
From: Guangliu Ding @ 2026-03-31 10:12 UTC (permalink / raw)
To: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Guangliu Ding, Jiyu Yang
This series enable Mali G310 GPU support on i.MX952 boards, the same GPU
IP as the instance on i.MX95 boards.
Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
---
Guangliu Ding (2):
dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
arm64: dts: imx952: Describe Mali G310 GPU
.../bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
arch/arm64/boot/dts/freescale/imx952.dtsi | 36 ++++++++++++++++++++++
2 files changed, 37 insertions(+)
---
base-commit: 0138af2472dfdef0d56fc4697416eaa0ff2589bd
change-id: 20260331-master-7ec7ff0fe1b2
Best regards,
--
Guangliu Ding <guangliu.ding@nxp.com>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-03-31 10:12 UTC (permalink / raw)
To: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Guangliu Ding, Jiyu Yang
In-Reply-To: <20260331-master-v1-0-65c8e318d462@nxp.com>
Add compatible string of Mali G310 GPU on i.MX952 board.
Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
---
Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
index 8eccd4338a2b..6a10843a26e2 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
@@ -20,6 +20,7 @@ properties:
- enum:
- mediatek,mt8196-mali
- nxp,imx95-mali # G310
+ - nxp,imx952-mali # G310
- rockchip,rk3588-mali
- const: arm,mali-valhall-csf # Mali Valhall GPU model/revision is fully discoverable
--
2.34.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: imx952: Describe Mali G310 GPU
From: Guangliu Ding @ 2026-03-31 10:12 UTC (permalink / raw)
To: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Guangliu Ding, Jiyu Yang
In-Reply-To: <20260331-master-v1-0-65c8e318d462@nxp.com>
Support Mali G310 GPU on i.MX952 board. Describe this GPU in the DT.
Include dummy GPU voltage regulator and OPP tables.
Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx952.dtsi | 36 +++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx952.dtsi b/arch/arm64/boot/dts/freescale/imx952.dtsi
index 91fe4916ac04..0bd3e7fc0674 100644
--- a/arch/arm64/boot/dts/freescale/imx952.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx952.dtsi
@@ -318,6 +318,28 @@ usbphynop2: usbphynop2 {
clock-names = "main_clk";
};
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-hz-real = /bits/ 64 <500000000>;
+ opp-microvolt = <920000>;
+ };
+
+ opp-800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-hz-real = /bits/ 64 <800000000>;
+ opp-microvolt = <920000>;
+ };
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-hz-real = /bits/ 64 <1000000000>;
+ opp-microvolt = <920000>;
+ };
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
@@ -1262,5 +1284,19 @@ usbmisc2: usbmisc@4c200200 {
reg = <0x0 0x4c200200 0x0 0x200>,
<0x0 0x4c010014 0x0 0x4>;
};
+
+ gpu: gpu@4d900000 {
+ compatible = "nxp,imx952-mali", "arm,mali-valhall-csf";
+ reg = <0 0x4d900000 0 0x480000>;
+ interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 289 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "gpu", "job", "mmu";
+ clocks = <&scmi_clk IMX952_CLK_GPU>;
+ clock-names = "core";
+ power-domains = <&scmi_devpd IMX952_PD_GPU>;
+ operating-points-v2 = <&gpu_opp_table>;
+ dynamic-power-coefficient = <1013>;
+ };
};
};
--
2.34.1
^ permalink raw reply related
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