* [PATCH v5 3/3] arm64: dts: qcom: glymur: Wire PCIe3a/3b to shared Gen5x8 PHY
From: Qiang Yu @ 2026-07-17 9:58 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam, Philipp Zabel,
Bjorn Andersson, Konrad Dybcio
Cc: Qiang Yu, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260717-glymur_linkmode_0717-v5-0-4f9e87a61463@oss.qualcomm.com>
Glymur's PCIe3a and PCIe3b controllers share a single Gen5x8 QMP PHY block
that can be bifurcated into two independent x4 links, rather than each
controller owning its own dedicated PHY.
Add a pcie3_phy node describing the shared PHY block, add the missing
PCIe3a controller node, and point both PCIe3a's and PCIe3b's port phys
at &pcie3_phy (index 0 and 1 respectively) so each controller picks up
its half of the bifurcated PHY. Update the GCC pipe clock parent array
to reference the new PHY's clock outputs instead of the placeholders.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 8 +
arch/arm64/boot/dts/qcom/glymur.dtsi | 336 ++++++++++++++++++++++++++++++-
2 files changed, 342 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
index c12808abbfe1..e8e81bf9a6a1 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
@@ -750,6 +750,14 @@ &pcie3b {
pinctrl-names = "default";
};
+&pcie3_phy {
+ vdda-phy-supply = <&vreg_l3c_e1_0p89>;
+ vdda-pll-supply = <&vreg_l2c_e1_1p14>;
+
+ vdda-refgen0p9-supply = <&vreg_l1c_e1_0p82>;
+ vdda-refgen1p2-supply = <&vreg_l4f_e1_1p08>;
+};
+
&pcie3b_port0 {
reset-gpios = <&tlmm 155 GPIO_ACTIVE_LOW>;
wake-gpios = <&tlmm 157 GPIO_ACTIVE_LOW>;
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 6d058d591039..edd09b84b8b9 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -801,8 +801,8 @@ 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 */
- <0>, /* PCIe 3b */
+ <&pcie3_phy 0>, /* PCIe 3a pipe */
+ <&pcie3_phy 1>, /* PCIe 3b pipe */
<&pcie4_phy>, /* PCIe 4 */
<&pcie5_phy>, /* PCIe 5 */
<&pcie6_phy>, /* PCIe 6 */
@@ -2329,6 +2329,62 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
};
};
+ pcie3_phy: phy@f00000 {
+ compatible = "qcom,glymur-qmp-gen5x8-pcie-phy";
+ reg = <0x0 0x00f00000 0x0 0x10000>,
+ <0x0 0x00f10000 0x0 0x10000>;
+ reg-names = "port_a",
+ "port_b";
+
+ clocks = <&gcc GCC_PCIE_PHY_3A_AUX_CLK>,
+ <&gcc GCC_PCIE_3A_CFG_AHB_CLK>,
+ <&tcsr TCSR_PCIE_3_CLKREF_EN>,
+ <&gcc GCC_PCIE_3A_PHY_RCHNG_CLK>,
+ <&gcc GCC_PCIE_3A_PIPE_CLK>,
+ <&gcc GCC_PCIE_PHY_3B_AUX_CLK>,
+ <&gcc GCC_PCIE_3B_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_3B_PHY_RCHNG_CLK>,
+ <&gcc GCC_PCIE_3B_PIPE_CLK>,
+ <&gcc GCC_PCIE_3B_PIPE_DIV2_CLK>;
+ clock-names = "aux",
+ "cfg_ahb",
+ "ref",
+ "rchng",
+ "pipe",
+ "phy_b_aux",
+ "cfg_ahb_b",
+ "rchng_b",
+ "pipe_b",
+ "pipediv2_b";
+
+ resets = <&gcc GCC_PCIE_3A_PHY_BCR>,
+ <&gcc GCC_PCIE_3A_NOCSR_COM_PHY_BCR>,
+ <&gcc GCC_PCIE_3B_PHY_BCR>,
+ <&gcc GCC_PCIE_3B_NOCSR_COM_PHY_BCR>;
+ reset-names = "phy_a",
+ "phy_a_nocsr",
+ "phy_b",
+ "phy_b_nocsr";
+
+ assigned-clocks = <&gcc GCC_PCIE_3A_PHY_RCHNG_CLK>,
+ <&gcc GCC_PCIE_3B_PHY_RCHNG_CLK>;
+ assigned-clock-rates = <100000000>, <100000000>;
+
+ power-domains = <&gcc GCC_PCIE_3A_PHY_GDSC>,
+ <&gcc GCC_PCIE_3B_PHY_GDSC>;
+ power-domain-names = "phy_a_gdsc", "phy_b_gdsc";
+
+ qcom,link-mode = <&tcsr 0x5000>;
+
+ #clock-cells = <1>;
+ clock-output-names = "pcie3a_pipe_clk",
+ "pcie3b_pipe_clk";
+
+ #phy-cells = <1>;
+
+ status = "disabled";
+ };
+
usb_hs_phy: phy@fa0000 {
compatible = "qcom,glymur-m31-eusb2-phy",
"qcom,sm8750-m31-eusb2-phy";
@@ -3691,6 +3747,282 @@ pcie3b_port0: pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
bus-range = <0x01 0xff>;
+ phys = <&pcie3_phy 1>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
+ };
+
+ pcie3a: pci@1c10000 {
+ 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>;
+ reg-names = "parf",
+ "dbi",
+ "elbi",
+ "atu",
+ "config",
+ "mhi";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x01000000 0x0 0x00000000 0x0 0x70200000 0x0 0x100000>,
+ <0x02000000 0x0 0x70000000 0x0 0x70300000 0x0 0x3d00000>,
+ <0x03000000 0x7 0x00000000 0x7 0x00000000 0x0 0x40000000>,
+ <0x43000000 0x70 0x00000000 0x70 0x00000000 0x10 0x00000000>;
+
+ bus-range = <0 0xff>;
+
+ dma-coherent;
+
+ linux,pci-domain = <3>;
+ num-lanes = <8>;
+
+ operating-points-v2 = <&pcie3a_opp_table>;
+
+ msi-map = <0x0 &gic_its 0xb0000 0x10000>;
+ iommu-map = <0x0 &pcie_smmu 0x30000 0x10000>;
+
+ interrupts = <GIC_SPI 948 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 949 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 844 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 845 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 846 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 847 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 942 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 0 0 0 848 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 0 849 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 0 850 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 0 851 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&gcc GCC_PCIE_3A_AUX_CLK>,
+ <&gcc GCC_PCIE_3A_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_3A_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_3A_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_3A_SLV_Q2A_AXI_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_3A_WEST_SF_AXI_CLK>;
+ clock-names = "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a",
+ "noc_aggr";
+
+ assigned-clocks = <&gcc GCC_PCIE_3A_AUX_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ interconnects = <&pcie_west_anoc MASTER_PCIE_3A QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&hsc_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
+ &pcie_west_slv_noc SLAVE_PCIE_3A QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "pcie-mem",
+ "cpu-pcie";
+
+ resets = <&gcc GCC_PCIE_3A_BCR>,
+ <&gcc GCC_PCIE_3A_LINK_DOWN_BCR>;
+ reset-names = "pci",
+ "link_down";
+
+ power-domains = <&gcc GCC_PCIE_3A_GDSC>;
+
+ eq-presets-8gts = /bits/ 16 <0x5555 0x5555 0x5555 0x5555
+ 0x5555 0x5555 0x5555 0x5555>;
+ eq-presets-16gts = /bits/ 8 <0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55>;
+ eq-presets-32gts = /bits/ 8 <0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55>;
+
+ status = "disabled";
+
+ pcie3a_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ /* GEN 1 x1 */
+ opp-2500000-1 {
+ opp-hz = /bits/ 64 <2500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <250000 1>;
+ opp-level = <1>;
+ };
+
+ /* GEN 1 x2 */
+ opp-5000000-1 {
+ opp-hz = /bits/ 64 <5000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <500000 1>;
+ opp-level = <1>;
+ };
+
+ /* GEN 1 x4 */
+ opp-10000000-1 {
+ opp-hz = /bits/ 64 <10000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <1000000 1>;
+ opp-level = <1>;
+ };
+
+ /* GEN 1 x8 */
+ opp-20000000-1 {
+ opp-hz = /bits/ 64 <20000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <2000000 1>;
+ opp-level = <1>;
+ };
+
+ /* GEN 2 x1 */
+ opp-5000000-2 {
+ opp-hz = /bits/ 64 <5000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <500000 1>;
+ opp-level = <2>;
+ };
+
+ /* GEN 2 x2 */
+ opp-10000000-2 {
+ opp-hz = /bits/ 64 <10000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <1000000 1>;
+ opp-level = <2>;
+ };
+
+ /* GEN 2 x4 */
+ opp-20000000-2 {
+ opp-hz = /bits/ 64 <20000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <2000000 1>;
+ opp-level = <2>;
+ };
+
+ /* GEN 2 x8 */
+ opp-40000000-2 {
+ opp-hz = /bits/ 64 <40000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <4000000 1>;
+ opp-level = <2>;
+ };
+
+ /* GEN 3 x1 */
+ opp-8000000-3 {
+ opp-hz = /bits/ 64 <8000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <984500 1>;
+ opp-level = <3>;
+ };
+
+ /* GEN 3 x2 */
+ opp-16000000-3 {
+ opp-hz = /bits/ 64 <16000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <1969000 1>;
+ opp-level = <3>;
+ };
+
+ /* GEN 3 x4 */
+ opp-32000000-3 {
+ opp-hz = /bits/ 64 <32000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <3938000 1>;
+ opp-level = <3>;
+ };
+
+ /* GEN 3 x8 */
+ opp-64000000-3 {
+ opp-hz = /bits/ 64 <64000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <7876000 1>;
+ opp-level = <3>;
+ };
+
+ /* GEN 4 x1 */
+ opp-16000000-4 {
+ opp-hz = /bits/ 64 <16000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ opp-peak-kBps = <1969000 1>;
+ opp-level = <4>;
+ };
+
+ /* GEN 4 x2 */
+ opp-32000000-4 {
+ opp-hz = /bits/ 64 <32000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ opp-peak-kBps = <3938000 1>;
+ opp-level = <4>;
+ };
+
+ /* GEN 4 x4 */
+ opp-64000000-4 {
+ opp-hz = /bits/ 64 <64000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ opp-peak-kBps = <7876000 1>;
+ opp-level = <4>;
+ };
+
+ /* GEN 4 x8 */
+ opp-128000000-4 {
+ opp-hz = /bits/ 64 <128000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ opp-peak-kBps = <15753000 1>;
+ opp-level = <4>;
+ };
+
+ /* GEN 5 x1 */
+ opp-32000000-5 {
+ opp-hz = /bits/ 64 <32000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ opp-peak-kBps = <3938000 1>;
+ opp-level = <5>;
+ };
+
+ /* GEN 5 x2 */
+ opp-64000000-5 {
+ opp-hz = /bits/ 64 <64000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ opp-peak-kBps = <7876000 1>;
+ opp-level = <5>;
+ };
+
+ /* GEN 5 x4 */
+ opp-128000000-5 {
+ opp-hz = /bits/ 64 <128000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ opp-peak-kBps = <15753000 1>;
+ opp-level = <5>;
+ };
+
+ /* GEN 5 x8 */
+ opp-256000000-5 {
+ opp-hz = /bits/ 64 <256000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ opp-peak-kBps = <31506000 1>;
+ opp-level = <5>;
+ };
+ };
+
+ pcie3a_port0: pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ phys = <&pcie3_phy 0>;
+
#address-cells = <3>;
#size-cells = <2>;
ranges;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: remoteproc: qcom,pas-common: allow up to 3 iommus
From: Pratyush Meduri @ 2026-07-17 9:58 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Manivannan Sadhasivam
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20260717095825.3962666-1-pratyush.meduri@oss.qualcomm.com>
The ADSP PAS on several Qualcomm SoCs (e.g. SA8775P/lemans, QCS8300,
Monaco) needs more than a single SMMU stream ID for the audio ML
(machine-learning) offload use case. In addition to the primary
ADSP stream ID, the DSP/SPF issues DMA transactions through extra
stream IDs that are not covered by the existing single-entry mapping.
Relax the iommus constraint to allow between 1 and 3 entries so the
additional ML offload stream IDs can be described, fixing dtb_check
schema violations on device trees that add them.
Signed-off-by: Pratyush Meduri <pratyush.meduri@oss.qualcomm.com>
---
.../devicetree/bindings/remoteproc/qcom,pas-common.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
index 11faf655f530..fb656bda8527 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
@@ -33,7 +33,8 @@ properties:
maxItems: 6
iommus:
- maxItems: 1
+ minItems: 1
+ maxItems: 3
power-domains:
minItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH v5 2/3] phy: qcom: qmp-pcie: Add QMP PCIe Multi-PHY driver
From: Qiang Yu @ 2026-07-17 9:58 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam, Philipp Zabel,
Bjorn Andersson, Konrad Dybcio
Cc: Qiang Yu, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260717-glymur_linkmode_0717-v5-0-4f9e87a61463@oss.qualcomm.com>
Some QMP PCIe PHY hardware blocks support multiple link topologies (e.g.
x8 or x4+x4) selected via a TCSR register. The existing single-instance
QMP PCIe PHY driver has no way to model this: it assumes a single cfg per
DT node and instantiates exactly one PHY.
Add a dedicated driver for this class of PHY. Match data carries a
per-mode cfg table; qmp_pcie_multiphy_probe() reads the current link
mode from the TCSR register pointed to by "qcom,link-mode", looks up the
corresponding cfg array, and instantiates one qmp_pcie per sub-PHY
required by that link mode, registering the clock and #phy-cells = <1> phy
providers so consumers can address individual sub-PHYs by index.
The driver inherits the phy setting and link-mode programmed by firmware,
so only the no_csr reset is used and no phy setting tables are provided.
Add the first match data and compatible, qcom,glymur-qmp-gen5x8-pcie-phy,
for the Glymur Gen5 PCIe PHY that can bifurcate into two x4 links or
operate as a single x8 link.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
drivers/phy/qualcomm/Kconfig | 11 +
drivers/phy/qualcomm/Makefile | 1 +
drivers/phy/qualcomm/phy-qcom-qmp-pcie-multiphy.c | 770 ++++++++++++++++++++++
3 files changed, 782 insertions(+)
diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index 60a0ead127fa..31241d1bbef2 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -77,6 +77,17 @@ config PHY_QCOM_QMP_PCIE
Enable this to support the QMP PCIe PHY transceiver that is used
with PCIe controllers on Qualcomm chips.
+config PHY_QCOM_QMP_PCIE_MULTIPHY
+ tristate "Qualcomm QMP PCIe Multiple Link-mode PHY Driver"
+ depends on PCI || COMPILE_TEST
+ select GENERIC_PHY
+ default PHY_QCOM_QMP
+ help
+ Enable this to support the QMP PCIe PHY transceiver that is used
+ with PCIe controllers on Qualcomm chips. This PHY is a single
+ multi-lane QMP block that can be configured either as one wide
+ link or as multiple narrower independent links (bifurcation).
+
config PHY_QCOM_QMP_PCIE_8996
tristate "Qualcomm QMP PCIe 8996 PHY Driver"
depends on PCI || COMPILE_TEST
diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
index b71a6a0bed3f..8bf887d58ee4 100644
--- a/drivers/phy/qualcomm/Makefile
+++ b/drivers/phy/qualcomm/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PHY_QCOM_PCIE2) += phy-qcom-pcie2.o
obj-$(CONFIG_PHY_QCOM_QMP_COMBO) += phy-qcom-qmp-combo.o phy-qcom-qmp-usbc.o
obj-$(CONFIG_PHY_QCOM_QMP_PCIE) += phy-qcom-qmp-pcie.o
+obj-$(CONFIG_PHY_QCOM_QMP_PCIE_MULTIPHY) += phy-qcom-qmp-pcie-multiphy.o
obj-$(CONFIG_PHY_QCOM_QMP_PCIE_8996) += phy-qcom-qmp-pcie-msm8996.o
obj-$(CONFIG_PHY_QCOM_QMP_UFS) += phy-qcom-qmp-ufs.o
obj-$(CONFIG_PHY_QCOM_QMP_USB) += phy-qcom-qmp-usb.o
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie-multiphy.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie-multiphy.c
new file mode 100644
index 000000000000..b79edf2b7d5f
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie-multiphy.c
@@ -0,0 +1,770 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2026, Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+
+#include "phy-qcom-qmp.h"
+
+#define PHY_INIT_COMPLETE_TIMEOUT 10000
+
+enum qmp_pcie_glymur_link_mode {
+ QMP_PCIE_GLYMUR_MODE_X8,
+ QMP_PCIE_GLYMUR_MODE_X4X4,
+};
+
+enum qphy_reg_layout {
+ QPHY_PCS_STATUS,
+ QPHY_LAYOUT_SIZE
+};
+
+static const unsigned int pciephy_v8_50_regs_layout[QPHY_LAYOUT_SIZE] = {
+ [QPHY_PCS_STATUS] = QPHY_V8_50_PCS_STATUS1,
+};
+
+struct qmp_pcie_offsets {
+ u16 pcs;
+};
+
+struct qmp_phy_cfg {
+ const struct qmp_pcie_offsets *offsets;
+
+ const char * const *reg_names;
+ int num_regs;
+
+ const char * const *pd_names;
+ int num_pds;
+
+ const char * const *nocsr_reset_list;
+ int num_nocsr_resets;
+
+ const char * const *vreg_list;
+ int num_vregs;
+
+ const unsigned int *regs;
+
+ unsigned int phy_status;
+
+ const char * const *clk_list;
+ int num_clks;
+ const char * const *pipe_clk_list;
+
+ int num_pipe_clks;
+};
+
+struct qmp_pcie {
+ struct device *dev;
+
+ const struct qmp_phy_cfg *cfg;
+
+ void __iomem **base;
+
+ struct clk_bulk_data *clks;
+ struct clk_bulk_data *pipe_clks;
+
+ struct reset_control_bulk_data *nocsr_resets;
+
+ struct regulator_bulk_data *vregs;
+
+ struct device **pd_devs;
+
+ struct clk_fixed_rate pipe_clk_fixed;
+};
+
+struct qmp_pcie_multiphy {
+ struct phy **phys;
+ const struct qmp_pcie_link_mode_cfg *mode_cfg;
+
+ int num_pipe_outputs;
+ struct clk_fixed_rate *pipe_out_clks;
+};
+
+struct qmp_pcie_link_mode_cfg {
+ const struct qmp_phy_cfg * const *cfgs;
+ u32 num_phys;
+};
+
+struct qmp_pcie_match_data {
+ const struct qmp_pcie_link_mode_cfg *mode_cfgs;
+ u32 num_modes;
+};
+
+static const char * const glymur_pciephy_clk_l[] = {
+ "aux", "cfg_ahb", "ref", "rchng", "phy_b_aux",
+};
+
+static const char * const glymur_pciephy_a_clk_l[] = {
+ "aux", "cfg_ahb", "ref", "rchng",
+};
+
+static const char * const glymur_pciephy_b_clk_l[] = {
+ "phy_b_aux", "cfg_ahb_b", "ref", "rchng_b",
+};
+
+static const char * const glymur_pciephy_pipeclk_l[] = {
+ "pipe",
+};
+
+static const char * const glymur_pipephy_b_pipeclk_l[] = {
+ "pipe_b", "pipediv2_b",
+};
+
+static const char * const glymur_vreg_l[] = {
+ "vdda-phy", "vdda-pll", "vdda-refgen0p9", "vdda-refgen1p2",
+};
+
+static const char * const glymur_pciephy_a_reg_l[] = {
+ "port_a",
+};
+
+static const char * const glymur_pciephy_b_reg_l[] = {
+ "port_b",
+};
+
+static const char * const glymur_pciephy_reg_l[] = {
+ "port_a", "port_b",
+};
+
+static const char * const glymur_pciephy_a_pd_l[] = {
+ "phy_a_gdsc",
+};
+
+static const char * const glymur_pciephy_b_pd_l[] = {
+ "phy_b_gdsc",
+};
+
+static const char * const glymur_pciephy_pd_l[] = {
+ "phy_a_gdsc", "phy_b_gdsc",
+};
+
+static const char * const glymur_pciephy_a_nocsr_reset_l[] = {
+ "phy_a_nocsr",
+};
+
+static const char * const glymur_pciephy_nocsr_reset_l[] = {
+ "phy_a_nocsr", "phy_b_nocsr",
+};
+
+static const char * const glymur_pciephy_b_nocsr_reset_l[] = {
+ "phy_b_nocsr",
+};
+
+static const struct qmp_pcie_offsets glymur_pcie_offsets_v8_50 = {
+ .pcs = 0x9000,
+};
+
+static const struct qmp_phy_cfg glymur_qmp_gen5x4_pciephy_a_cfg = {
+ .offsets = &glymur_pcie_offsets_v8_50,
+ .reg_names = glymur_pciephy_a_reg_l,
+ .num_regs = ARRAY_SIZE(glymur_pciephy_a_reg_l),
+ .pd_names = glymur_pciephy_a_pd_l,
+ .num_pds = ARRAY_SIZE(glymur_pciephy_a_pd_l),
+ .nocsr_reset_list = glymur_pciephy_a_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(glymur_pciephy_a_nocsr_reset_l),
+ .vreg_list = glymur_vreg_l,
+ .num_vregs = ARRAY_SIZE(glymur_vreg_l),
+ .regs = pciephy_v8_50_regs_layout,
+ .phy_status = PHYSTATUS_4_20,
+ .pipe_clk_list = glymur_pciephy_pipeclk_l,
+ .num_pipe_clks = ARRAY_SIZE(glymur_pciephy_pipeclk_l),
+ .clk_list = glymur_pciephy_a_clk_l,
+ .num_clks = ARRAY_SIZE(glymur_pciephy_a_clk_l),
+};
+
+static const struct qmp_phy_cfg glymur_qmp_gen5x4_pciephy_b_cfg = {
+ .offsets = &glymur_pcie_offsets_v8_50,
+ .reg_names = glymur_pciephy_b_reg_l,
+ .num_regs = ARRAY_SIZE(glymur_pciephy_b_reg_l),
+ .pd_names = glymur_pciephy_b_pd_l,
+ .num_pds = ARRAY_SIZE(glymur_pciephy_b_pd_l),
+ .nocsr_reset_list = glymur_pciephy_b_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(glymur_pciephy_b_nocsr_reset_l),
+ .vreg_list = glymur_vreg_l,
+ .num_vregs = ARRAY_SIZE(glymur_vreg_l),
+ .regs = pciephy_v8_50_regs_layout,
+ .phy_status = PHYSTATUS_4_20,
+ .pipe_clk_list = glymur_pipephy_b_pipeclk_l,
+ .num_pipe_clks = ARRAY_SIZE(glymur_pipephy_b_pipeclk_l),
+ .clk_list = glymur_pciephy_b_clk_l,
+ .num_clks = ARRAY_SIZE(glymur_pciephy_b_clk_l),
+};
+
+static const struct qmp_phy_cfg glymur_qmp_gen5x8_pciephy_cfg = {
+ .offsets = &glymur_pcie_offsets_v8_50,
+ .reg_names = glymur_pciephy_reg_l,
+ .num_regs = ARRAY_SIZE(glymur_pciephy_reg_l),
+ .pd_names = glymur_pciephy_pd_l,
+ .num_pds = ARRAY_SIZE(glymur_pciephy_pd_l),
+ .nocsr_reset_list = glymur_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(glymur_pciephy_nocsr_reset_l),
+ .vreg_list = glymur_vreg_l,
+ .num_vregs = ARRAY_SIZE(glymur_vreg_l),
+ .regs = pciephy_v8_50_regs_layout,
+ .phy_status = PHYSTATUS_4_20,
+ .pipe_clk_list = glymur_pciephy_pipeclk_l,
+ .num_pipe_clks = ARRAY_SIZE(glymur_pciephy_pipeclk_l),
+ .clk_list = glymur_pciephy_clk_l,
+ .num_clks = ARRAY_SIZE(glymur_pciephy_clk_l),
+};
+
+static const struct qmp_phy_cfg * const glymur_qmp_gen5x8_mode_x8_cfgs[] = {
+ &glymur_qmp_gen5x8_pciephy_cfg,
+};
+
+static const struct qmp_phy_cfg * const glymur_qmp_gen5x8_mode_x4x4_cfgs[] = {
+ &glymur_qmp_gen5x4_pciephy_a_cfg,
+ &glymur_qmp_gen5x4_pciephy_b_cfg,
+};
+
+static const struct qmp_pcie_link_mode_cfg glymur_qmp_gen5x8_mode_cfgs[] = {
+ [QMP_PCIE_GLYMUR_MODE_X8] = {
+ .cfgs = glymur_qmp_gen5x8_mode_x8_cfgs,
+ .num_phys = ARRAY_SIZE(glymur_qmp_gen5x8_mode_x8_cfgs),
+ },
+ [QMP_PCIE_GLYMUR_MODE_X4X4] = {
+ .cfgs = glymur_qmp_gen5x8_mode_x4x4_cfgs,
+ .num_phys = ARRAY_SIZE(glymur_qmp_gen5x8_mode_x4x4_cfgs),
+ },
+};
+
+static const struct qmp_pcie_match_data glymur_qmp_gen5x8_match_data = {
+ .mode_cfgs = glymur_qmp_gen5x8_mode_cfgs,
+ .num_modes = ARRAY_SIZE(glymur_qmp_gen5x8_mode_cfgs),
+};
+
+static int qmp_pcie_pd_power_on(struct qmp_pcie *qmp)
+{
+ const struct qmp_phy_cfg *cfg = qmp->cfg;
+ int i, ret;
+
+ for (i = 0; i < cfg->num_pds; i++) {
+ ret = pm_runtime_get_sync(qmp->pd_devs[i]);
+ if (ret < 0) {
+ dev_err(qmp->dev, "failed to power on %s domain\n",
+ cfg->pd_names[i]);
+ goto err_power_off;
+ }
+ }
+
+ return 0;
+
+err_power_off:
+ while (--i >= 0)
+ pm_runtime_put(qmp->pd_devs[i]);
+
+ return ret;
+}
+
+static void qmp_pcie_pd_power_off(struct qmp_pcie *qmp)
+{
+ const struct qmp_phy_cfg *cfg = qmp->cfg;
+ int i;
+
+ for (i = cfg->num_pds - 1; i >= 0; i--)
+ pm_runtime_put(qmp->pd_devs[i]);
+}
+
+static int qmp_pcie_init(struct phy *phy)
+{
+ struct qmp_pcie *qmp = phy_get_drvdata(phy);
+ const struct qmp_phy_cfg *cfg = qmp->cfg;
+ int ret;
+
+ ret = qmp_pcie_pd_power_on(qmp);
+ if (ret)
+ return ret;
+
+ ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs);
+ if (ret) {
+ dev_err(qmp->dev, "failed to enable regulators, err=%d\n", ret);
+ goto err_pd_power_off;
+ }
+
+ ret = reset_control_bulk_assert(qmp->cfg->num_nocsr_resets, qmp->nocsr_resets);
+ if (ret) {
+ dev_err(qmp->dev, "no-csr reset assert failed\n");
+ goto err_disable_regulators;
+ }
+
+ usleep_range(200, 300);
+
+ ret = clk_bulk_prepare_enable(qmp->cfg->num_clks, qmp->clks);
+ if (ret)
+ goto err_disable_regulators;
+
+ return 0;
+
+err_disable_regulators:
+ regulator_bulk_disable(cfg->num_vregs, qmp->vregs);
+err_pd_power_off:
+ qmp_pcie_pd_power_off(qmp);
+
+ return ret;
+}
+
+static int qmp_pcie_exit(struct phy *phy)
+{
+ struct qmp_pcie *qmp = phy_get_drvdata(phy);
+ const struct qmp_phy_cfg *cfg = qmp->cfg;
+
+ reset_control_bulk_assert(qmp->cfg->num_nocsr_resets, qmp->nocsr_resets);
+
+ clk_bulk_disable_unprepare(qmp->cfg->num_clks, qmp->clks);
+ regulator_bulk_disable(cfg->num_vregs, qmp->vregs);
+ qmp_pcie_pd_power_off(qmp);
+
+ return 0;
+}
+
+static int qmp_pcie_power_on(struct phy *phy)
+{
+ struct qmp_pcie *qmp = phy_get_drvdata(phy);
+ const struct qmp_phy_cfg *cfg = qmp->cfg;
+ const struct qmp_pcie_offsets *offs = cfg->offsets;
+ void __iomem *status;
+ unsigned int val;
+ int i, ret;
+
+ ret = clk_bulk_prepare_enable(qmp->cfg->num_pipe_clks, qmp->pipe_clks);
+ if (ret)
+ return ret;
+
+ ret = reset_control_bulk_deassert(qmp->cfg->num_nocsr_resets, qmp->nocsr_resets);
+ if (ret) {
+ dev_err(qmp->dev, "no-csr reset deassert failed\n");
+ goto err_disable_pipe_clk;
+ }
+
+ for (i = 0; i < cfg->num_regs; i++) {
+ status = qmp->base[i] + offs->pcs + cfg->regs[QPHY_PCS_STATUS];
+ ret = readl_poll_timeout(status, val, !(val & cfg->phy_status), 200,
+ PHY_INIT_COMPLETE_TIMEOUT);
+ if (ret) {
+ dev_err(qmp->dev, "phy initialization timed-out (%s)\n",
+ cfg->reg_names[i]);
+ goto err_disable_pipe_clk;
+ }
+ }
+
+ return 0;
+
+err_disable_pipe_clk:
+ clk_bulk_disable_unprepare(qmp->cfg->num_pipe_clks, qmp->pipe_clks);
+
+ return ret;
+}
+
+
+static int qmp_pcie_power_off(struct phy *phy)
+{
+ struct qmp_pcie *qmp = phy_get_drvdata(phy);
+
+ clk_bulk_disable_unprepare(qmp->cfg->num_pipe_clks, qmp->pipe_clks);
+
+ return 0;
+}
+
+static int qmp_pcie_enable(struct phy *phy)
+{
+ int ret;
+
+ ret = qmp_pcie_init(phy);
+ if (ret)
+ return ret;
+
+ ret = qmp_pcie_power_on(phy);
+ if (ret)
+ qmp_pcie_exit(phy);
+
+ return ret;
+}
+
+static int qmp_pcie_disable(struct phy *phy)
+{
+ int ret;
+
+ ret = qmp_pcie_power_off(phy);
+ if (ret)
+ return ret;
+
+ return qmp_pcie_exit(phy);
+}
+
+static const struct phy_ops qmp_pcie_phy_ops = {
+ .power_on = qmp_pcie_enable,
+ .power_off = qmp_pcie_disable,
+ .owner = THIS_MODULE,
+};
+
+static void qmp_pcie_pd_detach(void *data)
+{
+ struct qmp_pcie *qmp = data;
+ const struct qmp_phy_cfg *cfg = qmp->cfg;
+ int i;
+
+ for (i = 0; i < cfg->num_pds; i++) {
+ if (!IS_ERR_OR_NULL(qmp->pd_devs[i]))
+ dev_pm_domain_detach(qmp->pd_devs[i], true);
+ }
+}
+
+static int qmp_pcie_pd_init(struct qmp_pcie *qmp)
+{
+ const struct qmp_phy_cfg *cfg = qmp->cfg;
+ struct device *dev = qmp->dev;
+ int i, ret;
+
+ if (!cfg->num_pds)
+ return 0;
+
+ qmp->pd_devs = devm_kcalloc(dev, cfg->num_pds, sizeof(*qmp->pd_devs),
+ GFP_KERNEL);
+ if (!qmp->pd_devs)
+ return -ENOMEM;
+
+ for (i = 0; i < cfg->num_pds; i++) {
+ qmp->pd_devs[i] = dev_pm_domain_attach_by_name(dev,
+ cfg->pd_names[i]);
+ if (IS_ERR(qmp->pd_devs[i])) {
+ ret = PTR_ERR(qmp->pd_devs[i]);
+ goto err_detach;
+ }
+ }
+
+ return devm_add_action_or_reset(dev, qmp_pcie_pd_detach, qmp);
+
+err_detach:
+ while (--i >= 0)
+ dev_pm_domain_detach(qmp->pd_devs[i], false);
+
+ return ret;
+}
+
+static int qmp_pcie_vreg_init(struct qmp_pcie *qmp)
+{
+ const struct qmp_phy_cfg *cfg = qmp->cfg;
+ struct device *dev = qmp->dev;
+ int i;
+
+ qmp->vregs = devm_kcalloc(dev, cfg->num_vregs, sizeof(*qmp->vregs),
+ GFP_KERNEL);
+ if (!qmp->vregs)
+ return -ENOMEM;
+
+ for (i = 0; i < cfg->num_vregs; i++)
+ qmp->vregs[i].supply = cfg->vreg_list[i];
+
+ return devm_regulator_bulk_get(dev, cfg->num_vregs, qmp->vregs);
+}
+
+static int qmp_pcie_reset_init(struct qmp_pcie *qmp)
+{
+ const struct qmp_phy_cfg *cfg = qmp->cfg;
+ struct device *dev = qmp->dev;
+ int i, ret;
+
+ qmp->nocsr_resets = devm_kcalloc(dev, cfg->num_nocsr_resets,
+ sizeof(*qmp->nocsr_resets),
+ GFP_KERNEL);
+ if (!qmp->nocsr_resets)
+ return -ENOMEM;
+
+ for (i = 0; i < cfg->num_nocsr_resets; i++)
+ qmp->nocsr_resets[i].id = cfg->nocsr_reset_list[i];
+
+ ret = devm_reset_control_bulk_get_exclusive(dev,
+ cfg->num_nocsr_resets,
+ qmp->nocsr_resets);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to get no-csr resets\n");
+
+ return 0;
+}
+
+static int qmp_pcie_clk_init(struct qmp_pcie *qmp)
+{
+ const struct qmp_phy_cfg *cfg = qmp->cfg;
+ struct device *dev = qmp->dev;
+ int i, ret;
+
+ qmp->clks = devm_kcalloc(dev, cfg->num_clks, sizeof(*qmp->clks),
+ GFP_KERNEL);
+ if (!qmp->clks)
+ return -ENOMEM;
+
+ for (i = 0; i < cfg->num_clks; i++)
+ qmp->clks[i].id = cfg->clk_list[i];
+
+ ret = devm_clk_bulk_get_optional(dev, cfg->num_clks, qmp->clks);
+ if (ret)
+ return ret;
+
+ qmp->pipe_clks = devm_kcalloc(dev, cfg->num_pipe_clks,
+ sizeof(*qmp->pipe_clks), GFP_KERNEL);
+ if (!qmp->pipe_clks)
+ return -ENOMEM;
+
+ for (i = 0; i < cfg->num_pipe_clks; i++)
+ qmp->pipe_clks[i].id = cfg->pipe_clk_list[i];
+
+ return devm_clk_bulk_get_optional(dev, cfg->num_pipe_clks,
+ qmp->pipe_clks);
+}
+
+static int __phy_pipe_clk_register(struct device *dev, struct device_node *np,
+ int idx, struct clk_fixed_rate *fixed)
+{
+ struct clk_init_data init = { };
+ int ret;
+
+ ret = of_property_read_string_index(np, "clock-output-names", idx,
+ &init.name);
+ if (ret) {
+ dev_err(dev, "%pOFn: No clock-output-names\n", np);
+ return ret;
+ }
+
+ init.ops = &clk_fixed_rate_ops;
+
+ if (!fixed->fixed_rate)
+ fixed->fixed_rate = 125000000;
+
+ fixed->hw.init = &init;
+
+ return devm_clk_hw_register(dev, &fixed->hw);
+}
+
+static struct clk_hw *qmp_pcie_multiphy_clk_hw_get(struct of_phandle_args *clkspec,
+ void *data)
+{
+ struct qmp_pcie_multiphy *qmp_data = data;
+ unsigned int idx = 0;
+
+ if (clkspec->args_count)
+ idx = clkspec->args[0];
+
+ if (idx < (unsigned int)qmp_data->num_pipe_outputs)
+ return &qmp_data->pipe_out_clks[idx].hw;
+
+ return ERR_PTR(-EINVAL);
+}
+
+static int qmp_pcie_multiphy_register_clocks(struct device *dev,
+ struct device_node *np,
+ struct qmp_pcie_multiphy *qmp_data)
+{
+ int num_pipe_outputs;
+ int i, ret;
+
+ num_pipe_outputs = of_property_count_strings(np, "clock-output-names");
+ if (num_pipe_outputs < 0)
+ num_pipe_outputs = 1;
+
+ qmp_data->num_pipe_outputs = num_pipe_outputs;
+ qmp_data->pipe_out_clks = devm_kcalloc(dev, num_pipe_outputs,
+ sizeof(*qmp_data->pipe_out_clks),
+ GFP_KERNEL);
+ if (!qmp_data->pipe_out_clks)
+ return -ENOMEM;
+
+ for (i = 0; i < num_pipe_outputs; i++) {
+ ret = __phy_pipe_clk_register(dev, np, i,
+ &qmp_data->pipe_out_clks[i]);
+ if (ret)
+ return ret;
+ }
+
+ return devm_of_clk_add_hw_provider(dev, qmp_pcie_multiphy_clk_hw_get, qmp_data);
+}
+
+static int qmp_pcie_get_mmio(struct qmp_pcie *qmp)
+{
+ struct platform_device *pdev = to_platform_device(qmp->dev);
+ const struct qmp_phy_cfg *cfg = qmp->cfg;
+ struct device *dev = qmp->dev;
+ void __iomem *base;
+ int i;
+
+ qmp->base = devm_kcalloc(dev, cfg->num_regs, sizeof(*qmp->base),
+ GFP_KERNEL);
+ if (!qmp->base)
+ return -ENOMEM;
+
+ for (i = 0; i < cfg->num_regs; i++) {
+ base = devm_platform_ioremap_resource_byname(pdev, cfg->reg_names[i]);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ qmp->base[i] = base;
+ }
+
+ return 0;
+}
+
+static int qmp_pcie_read_link_mode(struct device *dev, unsigned int *link_mode)
+{
+ struct regmap *map;
+ unsigned int args[1];
+ int ret;
+
+ map = syscon_regmap_lookup_by_phandle_args(dev->of_node, "qcom,link-mode",
+ ARRAY_SIZE(args), args);
+ if (IS_ERR(map))
+ return PTR_ERR(map);
+
+ ret = regmap_read(map, args[0], link_mode);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static struct phy *qmp_pcie_multiphy_xlate(struct device *dev,
+ const struct of_phandle_args *args)
+{
+ struct qmp_pcie_multiphy *qmp_data = dev_get_drvdata(dev);
+ unsigned int idx;
+
+ if (!qmp_data || args->args_count < 1)
+ return ERR_PTR(-EINVAL);
+
+ idx = args->args[0];
+
+ if (idx < (unsigned int)qmp_data->mode_cfg->num_phys)
+ return qmp_data->phys[idx] ?: ERR_PTR(-EINVAL);
+
+ return ERR_PTR(-EINVAL);
+}
+
+static int qmp_pcie_probe_phy(struct qmp_pcie *qmp, struct device_node *np,
+ struct phy **out_phy)
+{
+ int ret;
+
+ ret = qmp_pcie_get_mmio(qmp);
+ if (ret)
+ return ret;
+
+ ret = qmp_pcie_clk_init(qmp);
+ if (ret)
+ return ret;
+
+ ret = qmp_pcie_reset_init(qmp);
+ if (ret)
+ return ret;
+
+ ret = qmp_pcie_vreg_init(qmp);
+ if (ret)
+ return ret;
+
+ ret = qmp_pcie_pd_init(qmp);
+ if (ret)
+ return ret;
+
+ *out_phy = devm_phy_create(qmp->dev, np, &qmp_pcie_phy_ops);
+ if (IS_ERR(*out_phy))
+ return PTR_ERR(*out_phy);
+
+ phy_set_drvdata(*out_phy, qmp);
+
+ return 0;
+}
+
+
+static int qmp_pcie_multiphy_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct phy_provider *phy_provider;
+ struct qmp_pcie_multiphy *qmp_data;
+ const struct qmp_pcie_match_data *match_data;
+ struct qmp_pcie *qmp;
+ struct phy **phys;
+ unsigned int link_mode;
+ int phy_index;
+ int ret;
+
+ qmp_data = devm_kzalloc(dev, sizeof(*qmp_data), GFP_KERNEL);
+
+ match_data = of_device_get_match_data(dev);
+ if (!match_data)
+ return -EINVAL;
+
+ if (!qmp_data)
+ return -ENOMEM;
+
+ ret = qmp_pcie_read_link_mode(dev, &link_mode);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to read qcom,link-mode\n");
+
+ if (link_mode >= match_data->num_modes)
+ return dev_err_probe(dev, -EINVAL, "invalid qcom,link-mode: %u\n",
+ link_mode);
+
+ qmp_data->mode_cfg = &match_data->mode_cfgs[link_mode];
+
+ qmp = devm_kcalloc(dev, qmp_data->mode_cfg->num_phys, sizeof(*qmp), GFP_KERNEL);
+ if (!qmp)
+ return -ENOMEM;
+
+ phys = devm_kcalloc(dev, qmp_data->mode_cfg->num_phys, sizeof(*phys), GFP_KERNEL);
+ if (!phys)
+ return -ENOMEM;
+
+ qmp_data->phys = phys;
+ dev_set_drvdata(dev, qmp_data);
+
+ for (phy_index = 0; phy_index < qmp_data->mode_cfg->num_phys; phy_index++) {
+ qmp[phy_index].dev = dev;
+ qmp[phy_index].cfg = qmp_data->mode_cfg->cfgs[phy_index];
+ ret = qmp_pcie_probe_phy(&qmp[phy_index], dev->of_node, &phys[phy_index]);
+ if (ret)
+ return ret;
+ }
+
+ ret = qmp_pcie_multiphy_register_clocks(dev, dev->of_node, qmp_data);
+ if (ret)
+ return ret;
+
+ phy_provider = devm_of_phy_provider_register(dev, qmp_pcie_multiphy_xlate);
+
+ return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id qmp_pcie_multiphy_of_match_table[] = {
+ {
+ .compatible = "qcom,glymur-qmp-gen5x8-pcie-phy",
+ .data = &glymur_qmp_gen5x8_match_data,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, qmp_pcie_multiphy_of_match_table);
+
+static struct platform_driver qmp_pcie_multiphy_driver = {
+ .probe = qmp_pcie_multiphy_probe,
+ .driver = {
+ .name = "qcom-qmp-pcie-multiphy",
+ .of_match_table = qmp_pcie_multiphy_of_match_table,
+ },
+};
+module_platform_driver(qmp_pcie_multiphy_driver);
+
+MODULE_AUTHOR("Qiang Yu <qiang.yu@oss.qualcomm.com>");
+MODULE_DESCRIPTION("Qualcomm QMP PCIe PHY driver for Glymur");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v5 1/3] dt-bindings: phy: qcom: Add Glymur QMP PCIe multiple link-mode PHY
From: Qiang Yu @ 2026-07-17 9:58 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam, Philipp Zabel,
Bjorn Andersson, Konrad Dybcio
Cc: Qiang Yu, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260717-glymur_linkmode_0717-v5-0-4f9e87a61463@oss.qualcomm.com>
Add qcom,glymur-qmp-pcie-multiphy.yaml as a standalone binding
for the Glymur Gen5 PCIe PHY hardware block. This block supports two
link modes, selected at runtime via a TCSR syscon register:
1. x8 - a single 8-lane PHY instance is exposed
2. x4+x4 - two independent 4-lane PHY instances are exposed
Keep this as a separate schema from qcom,sc8280xp-qmp-pcie-phy.yaml
rather than folding it into the shared compatible list there, since the
two PHY instances active in x8 mode require twice as many clocks,
resets, and power-domains as any other entry in that file, and adding
Glymur-specific properties like qcom,link-mode and reg-names there
would only apply to this one compatible.
Document the required clocks, resets, and power-domains for both PHY
instances, and use #phy-cells = <1>, where the cell value is the PHY
index within the active link mode.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
.../phy/qcom,glymur-qmp-pcie-multiphy.yaml | 176 +++++++++++++++++++++
1 file changed, 176 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,glymur-qmp-pcie-multiphy.yaml b/Documentation/devicetree/bindings/phy/qcom,glymur-qmp-pcie-multiphy.yaml
new file mode 100644
index 000000000000..73550f77e9b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,glymur-qmp-pcie-multiphy.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,glymur-qmp-pcie-multiphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QMP PCIe multiple link-mode PHY controller (PCIe, Glymur)
+
+maintainers:
+ - Qiang Yu <qiang.yu@oss.qualcomm.com>
+ - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
+
+description: |
+ The Glymur SoC uses a single PCIe Gen5 PHY hardware block for the
+ PCIe3a/PCIe3b controllers. This block supports two link modes, selected
+ at runtime via a TCSR syscon register:
+
+ 1. x8 - a single 8-lane PHY instance is exposed (PCIe3a only)
+ 2. x4+x4 - two independent 4-lane PHY instances are exposed (PCIe3a and
+ PCIe3b)
+
+ The node always describes both PHY instances ("port a" and "port b"),
+ regardless of which link mode is active on the board.
+
+properties:
+ compatible:
+ enum:
+ - qcom,glymur-qmp-gen5x8-pcie-phy
+
+ reg:
+ minItems: 2
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: port_a
+ - const: port_b
+
+ clocks:
+ minItems: 10
+ maxItems: 10
+
+ clock-names:
+ items:
+ - const: aux
+ - const: cfg_ahb
+ - const: ref
+ - const: rchng
+ - const: pipe
+ - const: phy_b_aux
+ - const: cfg_ahb_b
+ - const: rchng_b
+ - const: pipe_b
+ - const: pipediv2_b
+
+ power-domains:
+ minItems: 2
+ maxItems: 2
+
+ power-domain-names:
+ items:
+ - const: phy_a_gdsc
+ - const: phy_b_gdsc
+
+ resets:
+ minItems: 4
+ maxItems: 4
+
+ reset-names:
+ items:
+ - const: phy_a
+ - const: phy_a_nocsr
+ - const: phy_b
+ - const: phy_b_nocsr
+
+ vdda-phy-supply: true
+
+ vdda-pll-supply: true
+
+ vdda-refgen0p9-supply: true
+
+ vdda-refgen1p2-supply: true
+
+ qcom,link-mode:
+ description:
+ Reference to a register in the TCSR syscon that reports the link
+ mode the PCIe PHY is currently configured for, either a single x8
+ link or two independent x4 links. The link mode is programmed by
+ firmware before Linux boots; this property is only used to read
+ the active link mode, specified as a phandle to the syscon and
+ the register offset.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle of TCSR syscon
+ - description: offset of link mode register
+
+ "#clock-cells":
+ const: 1
+
+ clock-output-names:
+ items:
+ - description: Name of the PHY A pipe clock output.
+ - description: Name of the PHY B pipe clock output.
+
+ "#phy-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - power-domains
+ - power-domain-names
+ - resets
+ - reset-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+ - vdda-refgen0p9-supply
+ - vdda-refgen1p2-supply
+ - qcom,link-mode
+ - "#clock-cells"
+ - clock-output-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,glymur-gcc.h>
+ #include <dt-bindings/clock/qcom,glymur-tcsr.h>
+
+ pcie3_phy: phy@f00000 {
+ compatible = "qcom,glymur-qmp-gen5x8-pcie-phy";
+ reg = <0x00f00000 0x10000>, <0x00f10000 0x10000>;
+ reg-names = "port_a", "port_b";
+
+ clocks = <&gcc GCC_PCIE_PHY_3A_AUX_CLK>,
+ <&gcc GCC_PCIE_3A_CFG_AHB_CLK>,
+ <&tcsr TCSR_PCIE_3_CLKREF_EN>,
+ <&gcc GCC_PCIE_3A_PHY_RCHNG_CLK>,
+ <&gcc GCC_PCIE_3A_PIPE_CLK>,
+ <&gcc GCC_PCIE_PHY_3B_AUX_CLK>,
+ <&gcc GCC_PCIE_3B_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_3B_PHY_RCHNG_CLK>,
+ <&gcc GCC_PCIE_3B_PIPE_CLK>,
+ <&gcc GCC_PCIE_3B_PIPE_DIV2_CLK>;
+ clock-names = "aux", "cfg_ahb", "ref", "rchng", "pipe",
+ "phy_b_aux", "cfg_ahb_b", "rchng_b", "pipe_b",
+ "pipediv2_b";
+
+ resets = <&gcc GCC_PCIE_3A_PHY_BCR>,
+ <&gcc GCC_PCIE_3A_NOCSR_COM_PHY_BCR>,
+ <&gcc GCC_PCIE_3B_PHY_BCR>,
+ <&gcc GCC_PCIE_3B_NOCSR_COM_PHY_BCR>;
+ reset-names = "phy_a", "phy_a_nocsr", "phy_b", "phy_b_nocsr";
+
+ power-domains = <&gcc GCC_PCIE_3A_PHY_GDSC>,
+ <&gcc GCC_PCIE_3B_PHY_GDSC>;
+ power-domain-names = "phy_a_gdsc", "phy_b_gdsc";
+
+ vdda-phy-supply = <&vreg_l3c>;
+ vdda-pll-supply = <&vreg_l2c>;
+
+ vdda-refgen0p9-supply = <&vreg_l3c>;
+ vdda-refgen1p2-supply = <&vreg_l2c>;
+
+ qcom,link-mode = <&tcsr 0x5000>;
+
+ #clock-cells = <1>;
+ clock-output-names = "pcie3a_pipe_clk", "pcie3b_pipe_clk";
+
+ #phy-cells = <1>;
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v5 0/3] Add QMP PCIe multiple link-mode PHY support
From: Qiang Yu @ 2026-07-17 9:58 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam, Philipp Zabel,
Bjorn Andersson, Konrad Dybcio
Cc: Qiang Yu, linux-arm-msm, linux-phy, devicetree, linux-kernel
Hi all,
Some QMP PCIe PHY hardware blocks can be configured through a link-mode
register into different link topologies, such as a single wide link, or
multiple independent narrower links (e.g. x8 or x4+x4 mode on the Glymur
PCIe3 PHY).
Earlier revisions tried to extend the existing single-instance
phy-qcom-qmp-pcie.c driver to cover this hardware. That added a large
amount of conditional, multi-PHY logic to a driver whose data model
assumes one PHY per node.
This series adds a dedicated PHY provider driver,
phy-qcom-qmp-pcie-multiphy.c:
A single PHY provider node describes the shared hardware block. A new
"qcom,link-mode" property points at the TCSR syscon register that reports
the active topology; the driver reads it once at probe. #phy-cells = <1>
lets consumers pass a logical PHY index to obtain their sub-PHY. Match
data is indexed by link mode, and each link mode has its own array of
per-PHY config tables, so one shared provider exposes a different set of
logical PHYs depending on the active mode. The driver inherits the PHY
settings and link mode already programmed by UEFI, so only the no-CSR
reset is used, and no PHY setting tables or related structures are
defined. Each sub-PHY owns its register regions and power domain, so in a
bifurcated mode the links are brought up, and powered independently.
The driver is implemented and validated on Glymur, and is intended to
be extensible to other multi-mode QMP PCIe PHYs.
This series depends on a prerequisite patch by Krzysztof Kozlowski:
https://lore.kernel.org/r/20260420133616.88740-2-krzysztof.kozlowski@oss.qualcomm.com
Thanks,
Qiang
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
Changes in v5:
- Split the Glymur multi PHY binding out of the shared qcom,sc8280xp-qmp-pcie-phy.yaml into its own schema.
- Reworked phy-qcom-qmp-pcie-multiphy.c into a standalone driver instead of extending phy-qcom-qmp-pcie.c with conditional multi-PHYlogic.
- Dropped the "link mode value" cell from qcom,link-mode.
- Removed the QMP_PHY_SELECTOR_0/1 dt-bindings macros.
- Link to v4: https://lore.kernel.org/all/20260518-link_mode_0519-v4-0-269cd73cc5d1@oss.qualcomm.com/
Changes in v4:
- Replaced the static bifurcation probe model with a link-mode
architecture: the active topology (x8 or x4+x4) is selected via a
new "qcom,link-mode" DT property and written to a TCSR register at
power-on. This replaces v3 patches 4 and 5 with four new patches
(driver refactor, secondary PHY clock/reset lists, link-mode probe
infrastructure, and Glymur config).
- Updated dt-bindings to describe "qcom,link-mode", #phy-cells = <1>,
per-mode validation rules, and added a new header with
QMP_PHY_SELECTOR_* and QMP_PCIE_GLYMUR_MODE_* macros.
- Patches 2 and 3 (multiple power-domains, multiple nocsr resets) are
unchanged from v3.
- Link to v3: https://lore.kernel.org/r/20260412-glymur_gen5x8_phy_0413-v3-0-affcebc16b8b@oss.qualcomm.com
Changes in v3:
- Add description of each power-domain.
- Add 64bit prefetchable memory range required by some EPs eg. AI100 ultra.
- Move PCIe3a after PCIe3b and move PCIe3a PHY before PCIe3b PHY.
- Link to v2: https://lore.kernel.org/all/20260323-glymur_gen5x8_phy_0323-v2-0-ce0fc07f0e52@oss.qualcomm.com/
Changes in v2:
- Remove pd_list from qmp_pcie struct as it is not used in phy driver.
- align clk-names on "
- Link to v1: https://lore.kernel.org/all/20260304-glymur_gen5x8_phy-v1-0-849e9a72e125@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>
To: Qiang Yu <qiang.yu@oss.qualcomm.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
To: Bjorn Andersson <andersson@kernel.org>
To: Konrad Dybcio <konradybcio@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
---
Qiang Yu (3):
dt-bindings: phy: qcom: Add Glymur QMP PCIe multiple link-mode PHY
phy: qcom: qmp-pcie: Add QMP PCIe Multi-PHY driver
arm64: dts: qcom: glymur: Wire PCIe3a/3b to shared Gen5x8 PHY
.../phy/qcom,glymur-qmp-pcie-multiphy.yaml | 176 +++++
arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 8 +
arch/arm64/boot/dts/qcom/glymur.dtsi | 336 ++++++++-
drivers/phy/qualcomm/Kconfig | 11 +
drivers/phy/qualcomm/Makefile | 1 +
drivers/phy/qualcomm/phy-qcom-qmp-pcie-multiphy.c | 770 +++++++++++++++++++++
6 files changed, 1300 insertions(+), 2 deletions(-)
---
base-commit: 59ccadbf59aedee486fce5b4a5486a07c3f4b5d3
change-id: 20260716-glymur_linkmode_0717-70eacf08a5c5
Best regards,
--
Qiang Yu <qiang.yu@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2 0/3] arm64: dts: qcom: enable audio ML offload
From: Pratyush Meduri @ 2026-07-17 9:58 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Manivannan Sadhasivam
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
The audio ML offload use case on Lemans requires a dedicated contiguous
memory region shared with the audio DSP/SPF as well as corresponding
SMMU stream ID mappings under the EL2 configuration.
This series adds a dedicated CMA pool for audio ML buffers and
associates it with the q6apm audio subsystem. It also updates the ADSP
SMMU configuration in the EL2 overlay to include the ML-related stream
IDs required for DMA transactions during model offload.
Without these changes, audio ML workloads may fail due to unavailable
contiguous memory or SMMU faults caused by unmapped stream IDs.
changes in v2:
- fixed dt binding issue for iommu.
- v1 link: https://lore.kernel.org/all/20260716151854.3041914-1-pratyush.meduri@oss.qualcomm.com/
Pratyush Meduri (3):
dt-bindings: remoteproc: qcom,pas-common: allow up to 3 iommus
arm64: dts: qcom: lemans: enable audio ML offload memory and SMMU
mappings
arm64: dts: qcom: monaco: enable audio ML offload memory and SMMU
mappings
.../devicetree/bindings/remoteproc/qcom,pas-common.yaml | 3 ++-
arch/arm64/boot/dts/qcom/lemans-el2.dtso | 4 +++-
arch/arm64/boot/dts/qcom/lemans.dtsi | 9 +++++++++
arch/arm64/boot/dts/qcom/monaco-el2.dtso | 4 +++-
arch/arm64/boot/dts/qcom/monaco.dtsi | 9 +++++++++
5 files changed, 26 insertions(+), 3 deletions(-)
base-commit: b8809969e1d7a591e0f49dd464a5d04b3cf02ab1
--
2.34.1
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: eliza: Add PCIe PHY and controller nodes
From: Konrad Dybcio @ 2026-07-17 9:58 UTC (permalink / raw)
To: Krishna Chaitanya Chundru, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, abel.vesa
In-Reply-To: <20260708-eliza_dt-v2-1-e6281da26408@oss.qualcomm.com>
On 7/8/26 7:36 AM, Krishna Chaitanya Chundru wrote:
> Eliza supports two PCIe instances: one 8GT/s x1 (PCIe0) and one 8GT/s x2
> (PCIe1). Add PCIe controller and PHY nodes for both instances, and update
> the GCC clock references to use the newly added PHY nodes instead of
> placeholder zeros.
>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
[...]
> + pcie1: pcie@1c08000 {
> + device_type = "pci";
> + compatible = "qcom,eliza-pcie", "qcom,pcie-sm8550";
> + reg = <0 0x01c08000 0 0x3000>,
> + <0 0x44000000 0 0xf1d>,
> + <0 0x44000f20 0 0xa8>,
> + <0 0x44001000 0 0x1000>,
> + <0 0x44100000 0 0x100000>,
> + <0 0x01c0b000 0 0x1000>;
> + reg-names = "parf",
> + "dbi",
> + "elbi",
> + "atu",
> + "config",
> + "mhi";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0 0x00000000 0 0x44200000 0 0x100000>,
> + <0x02000000 0 0x44300000 0 0x44300000 0 0x3d00000>;
There's a secondary BAR region at 0x4_0000_0000 that's
0x3_0000_0000-long
Konrad
^ permalink raw reply
* [PATCH v3 4/4] MAINTAINERS: Add the Renesas RZ/N1 timers driver entry
From: Herve Codina (Schneider Electric) @ 2026-07-17 9:55 UTC (permalink / raw)
To: Wolfram Sang, Herve Codina, Daniel Lezcano, Thomas Gleixner,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: linux-renesas-soc, linux-kernel, devicetree, Pascal Eberhard,
Miquel Raynal, Thomas Petazzoni
In-Reply-To: <20260717095552.767475-1-herve.codina@bootlin.com>
After contributing the driver, add myself as the maintainer for the
Renesas RZ/N1 timers driver.
Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 15011f5752a9..17fd5f749344 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23025,6 +23025,13 @@ S: Maintained
F: Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
F: drivers/rtc/rtc-rzn1.c
+RENESAS RZ/N1 TIMERS DRIVER
+M: Herve Codina <herve.codina@bootlin.com>
+L: linux-renesas-soc@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/timer/renesas,rzn1-timer.yaml
+F: drivers/clocksource/timer-rzn1.c
+
RENESAS RZ/N1 USBF CONTROLLER DRIVER
M: Herve Codina <herve.codina@bootlin.com>
L: linux-renesas-soc@vger.kernel.org
--
2.55.0
^ permalink raw reply related
* [PATCH v3 3/4] ARM: dts: r9a06g032: Add support for timers
From: Herve Codina (Schneider Electric) @ 2026-07-17 9:55 UTC (permalink / raw)
To: Wolfram Sang, Herve Codina, Daniel Lezcano, Thomas Gleixner,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: linux-renesas-soc, linux-kernel, devicetree, Pascal Eberhard,
Miquel Raynal, Thomas Petazzoni
In-Reply-To: <20260717095552.767475-1-herve.codina@bootlin.com>
In the Renesas RZ/N1 SoCs family, two timers block are available.
Each block contains 8 timers composed of 6 16-bits timers and 2 32-bits
timers.
Each timer has its own interrupt line.
Describe those timers blocks.
Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/renesas/r9a06g032.dtsi | 34 ++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/renesas/r9a06g032.dtsi b/arch/arm/boot/dts/renesas/r9a06g032.dtsi
index 442ea26b40f5..ba3f011e8c17 100644
--- a/arch/arm/boot/dts/renesas/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/renesas/r9a06g032.dtsi
@@ -722,6 +722,40 @@ gpioirqmux: interrupt-controller@51000480 {
status = "disabled";
};
+ timer0: timer@51001000 {
+ compatible = "renesas,r9a06g032-timer", "renesas,rzn1-timer";
+ reg = <0x51001000 0x400>;
+ clocks = <&sysctrl R9A06G032_HCLK_TIMER0>;
+ clock-names = "pclk";
+ power-domains = <&sysctrl>;
+ interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ timer1: timer@51002000 {
+ compatible = "renesas,r9a06g032-timer", "renesas,rzn1-timer";
+ reg = <0x51002000 0x400>;
+ clocks = <&sysctrl R9A06G032_HCLK_TIMER1>;
+ clock-names = "pclk";
+ power-domains = <&sysctrl>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
can0: can@52104000 {
compatible = "renesas,r9a06g032-sja1000", "renesas,rzn1-sja1000";
reg = <0x52104000 0x800>;
--
2.55.0
^ permalink raw reply related
* [PATCH v3 2/4] clocksource/drivers: Add support for the Renesas RZ/N1 timers
From: Herve Codina (Schneider Electric) @ 2026-07-17 9:55 UTC (permalink / raw)
To: Wolfram Sang, Herve Codina, Daniel Lezcano, Thomas Gleixner,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: linux-renesas-soc, linux-kernel, devicetree, Pascal Eberhard,
Miquel Raynal, Thomas Petazzoni
In-Reply-To: <20260717095552.767475-1-herve.codina@bootlin.com>
The Renesas RZ/N1 timer block controller is the controller in charge of
timers available in the Renesas RZ/N1 SoCs family.
This controller handles 8 timers:
- 6 16-bit timers
- 2 32-bit timers
Each timer has its own interrupt, its own prescaler that can be used to
divide the clock by 25 and all of them can work in either one-shot or
periodic mode.
Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com>
---
drivers/clocksource/Kconfig | 11 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-rzn1.c | 455 +++++++++++++++++++++++++++++++
3 files changed, 467 insertions(+)
create mode 100644 drivers/clocksource/timer-rzn1.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index d9c76dd443f8..da83483296d5 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -152,6 +152,17 @@ config REALTEK_OTTO_TIMER
RT8391, RTL8392, RTL8393 and RTL8396 and chips of the RTL930x series
such as RTL9301, RTL9302 or RTL9303.
+config RZN1_TIMER
+ bool "Renesas RZ/N1 Timer"
+ depends on HAS_IOMEM && COMMON_CLK
+ depends on ARCH_RZN1 || COMPILE_TEST
+ help
+ Enables support for RZ/N1 SoC timers.
+ A timers block in RZ/N1 SoCs is composed of 8 timers
+ - 6 16-bit timers
+ - 2 32-bit timers
+ Two timers blocks are available in RZ/N1 SoCs.
+
config SUN4I_TIMER
bool "Sun4i timer driver" if COMPILE_TEST
depends on HAS_IOMEM
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index b46376af6b49..464ec6690ab6 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -96,3 +96,4 @@ obj-$(CONFIG_EP93XX_TIMER) += timer-ep93xx.o
obj-$(CONFIG_RALINK_TIMER) += timer-ralink.o
obj-$(CONFIG_NXP_STM_TIMER) += timer-nxp-stm.o
obj-$(CONFIG_RTK_SYSTIMER) += timer-realtek.o
+obj-$(CONFIG_RZN1_TIMER) += timer-rzn1.o
diff --git a/drivers/clocksource/timer-rzn1.c b/drivers/clocksource/timer-rzn1.c
new file mode 100644
index 000000000000..024f01bb0227
--- /dev/null
+++ b/drivers/clocksource/timer-rzn1.c
@@ -0,0 +1,455 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RZ/N1 timers driver
+ *
+ * Copyright (C) 2026 Schneider-Electric
+ *
+ * Author: Herve Codina <herve.codina@bootlin.com>
+ */
+
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/clocksource.h>
+#include <linux/cpuhotplug.h>
+#include <linux/interrupt.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/sched_clock.h>
+
+/* Per-timer register offsets */
+#define RZN1_TIMER_LOAD_COUNT_REG 0x00
+#define RZN1_TIMER_CURRENT_COUNT_REG 0x04
+#define RZN1_TIMER_CONTROL_REG 0x08
+#define RZN1_TIMER_CONTROL_INT_UNMASK BIT(3)
+#define RZN1_TIMER_CONTROL_ENABLE BIT(2)
+#define RZN1_TIMER_CONTROL_AUTORELOAD BIT(1)
+#define RZN1_TIMER_CONTROL_PRESCALER_DIV25 BIT(0)
+#define RZN1_TIMER_CLEAR_INT_REG 0x0c
+#define RZN1_TIMER_STATUS_INT0_REG 0x10
+#define RZN1_TIMER_STATUS_INT1_REG 0x14
+
+/*
+ * 8 timers are available. Among those 8 timers, the first 6 timers are 16-bit
+ * timers and the last two ones are 32-bit timers.
+ */
+#define RZN1_TIMER_BASE_INDEX_16BIT_TIMERS 0
+#define RZN1_TIMER_NB_16BIT_TIMERS 6
+#define RZN1_TIMER_LAST_INDEX_16BIT_TIMERS (RZN1_TIMER_BASE_INDEX_16BIT_TIMERS + \
+ RZN1_TIMER_NB_16BIT_TIMERS - 1)
+
+#define RZN1_TIMER_BASE_INDEX_32BIT_TIMERS 6
+#define RZN1_TIMER_NB_32BIT_TIMERS 2
+#define RZN1_TIMER_LAST_INDEX_32BIT_TIMERS (RZN1_TIMER_BASE_INDEX_32BIT_TIMERS + \
+ RZN1_TIMER_NB_32BIT_TIMERS - 1)
+
+#define RZN1_TIMER_IS_16BIT_TIMER(_i) ((_i) < RZN1_TIMER_BASE_INDEX_32BIT_TIMERS)
+
+/* Total numbers of timers */
+#define RZN1_TIMER_NB_TIMERS (RZN1_TIMER_NB_16BIT_TIMERS + \
+ RZN1_TIMER_NB_32BIT_TIMERS)
+
+/* Offset of registers related to the timer number _i in the timers regs area */
+#define RZN1_TIMER_REGS_OFFSET(_i) (0x20 * (_i))
+
+struct rzn1_timer {
+ void __iomem *base;
+ unsigned int width;
+ unsigned long rate;
+ unsigned long hz_period;
+ struct clock_event_device ced;
+};
+
+static int rzn1_timer_config(struct rzn1_timer *timer, u32 period, bool is_periodic)
+{
+ u32 ctrl;
+
+ ctrl = readl(timer->base + RZN1_TIMER_CONTROL_REG);
+
+ /* Disable the timer */
+ writel(ctrl & ~RZN1_TIMER_CONTROL_ENABLE,
+ timer->base + RZN1_TIMER_CONTROL_REG);
+
+ /* Set the new period */
+ writel(period, timer->base + RZN1_TIMER_LOAD_COUNT_REG);
+
+ /* Prepare the timer mode */
+ if (is_periodic)
+ ctrl |= RZN1_TIMER_CONTROL_AUTORELOAD;
+ else
+ ctrl &= ~RZN1_TIMER_CONTROL_AUTORELOAD;
+
+ /*
+ * Enable the timer.
+ *
+ * This automatically resets the CURRENT_COUNT register.
+ */
+ ctrl |= RZN1_TIMER_CONTROL_ENABLE;
+ writel(ctrl, timer->base + RZN1_TIMER_CONTROL_REG);
+
+ return 0;
+}
+
+static void rzn1_timer_disable(struct rzn1_timer *timer)
+{
+ u32 ctrl;
+
+ ctrl = readl(timer->base + RZN1_TIMER_CONTROL_REG);
+ ctrl &= ~RZN1_TIMER_CONTROL_ENABLE;
+ writel(ctrl, timer->base + RZN1_TIMER_CONTROL_REG);
+}
+
+static void rzn1_timer_int_enable(struct rzn1_timer *timer)
+{
+ u32 ctrl;
+
+ ctrl = readl(timer->base + RZN1_TIMER_CONTROL_REG);
+ ctrl |= RZN1_TIMER_CONTROL_INT_UNMASK;
+ writel(ctrl, timer->base + RZN1_TIMER_CONTROL_REG);
+}
+
+static irqreturn_t rzn1_timer_interrupt(int irq, void *dev_id)
+{
+ struct rzn1_timer *timer = dev_id;
+
+ /* Ack the interrupt */
+ readl(timer->base + RZN1_TIMER_CLEAR_INT_REG);
+
+ timer->ced.event_handler(&timer->ced);
+ return IRQ_HANDLED;
+}
+
+static int rzn1_clkevt_set_next_event(unsigned long cycles,
+ struct clock_event_device *evt)
+{
+ struct rzn1_timer *timer = container_of(evt, struct rzn1_timer, ced);
+
+ return rzn1_timer_config(timer, cycles, false);
+}
+
+static int rzn1_clkevt_shutdown(struct clock_event_device *evt)
+{
+ struct rzn1_timer *timer = container_of(evt, struct rzn1_timer, ced);
+
+ rzn1_timer_disable(timer);
+ return 0;
+}
+
+static int rzn1_clkevt_set_periodic(struct clock_event_device *evt)
+{
+ struct rzn1_timer *timer = container_of(evt, struct rzn1_timer, ced);
+
+ rzn1_timer_config(timer, timer->hz_period, true);
+ return 0;
+}
+
+/*
+ * This global lock is used to prevent race conditions during global timers
+ * test and set operation in case the driver is using the async probe option.
+ */
+static DEFINE_MUTEX(rzn1_global_timers_lock);
+
+static int rzn1_timer_instance;
+
+/* scheduler and clocksource */
+static struct rzn1_timer *rzn1_sched_clock;
+
+static u64 notrace rzn1_sched_read(void)
+{
+ return readl_relaxed(rzn1_sched_clock->base + RZN1_TIMER_CURRENT_COUNT_REG);
+}
+
+static u64 rzn1_clksrc_read(struct clocksource *cs)
+{
+ return readl_relaxed(rzn1_sched_clock->base + RZN1_TIMER_CURRENT_COUNT_REG);
+}
+
+static struct clocksource rzn1_clocksource = {
+ .name = "rzn1_timer_clocksource",
+ .rating = 200,
+ .flags = CLOCK_SOURCE_IS_CONTINUOUS | CLOCK_SOURCE_SUSPEND_NONSTOP,
+ .read = rzn1_clksrc_read,
+};
+
+/* Timers table where 32-bit timers will be assigned per-cpu */
+static struct rzn1_timer *rzn1_tab_timers;
+
+static int rzn1_local_timer_starting_cpu(unsigned int cpu)
+{
+ struct rzn1_timer *timer;
+
+ if (cpu > RZN1_TIMER_NB_32BIT_TIMERS)
+ return -EINVAL;
+
+ timer = &rzn1_tab_timers[cpu + RZN1_TIMER_BASE_INDEX_32BIT_TIMERS];
+
+ timer->ced.cpumask = cpumask_of(cpu);
+ irq_force_affinity(timer->ced.irq, cpumask_of(cpu));
+ clockevents_config_and_register(&timer->ced, timer->rate, 1,
+ GENMASK(timer->width - 1, 0));
+
+ return 0;
+}
+
+static void rzn1_timer_init(struct rzn1_timer *timer, unsigned int index,
+ void __iomem *timers_base, unsigned long clock_rate)
+{
+ timer->base = timers_base + RZN1_TIMER_REGS_OFFSET(index);
+
+ /* Disable the timer */
+ writel(0, timer->base + RZN1_TIMER_CONTROL_REG);
+
+ /* Clear potential interrupts */
+ readl(timer->base + RZN1_TIMER_CLEAR_INT_REG);
+
+ if (RZN1_TIMER_IS_16BIT_TIMER(index)) {
+ timer->width = 16;
+ /*
+ * Enable pre-scaler for 16-bit timers.
+ *
+ * Timers are fed by a 25MHz clock. With this pre-scaler (1/25)
+ * enabled, the 16-bit timers resolution is 1 microsecond.
+ */
+ writel(RZN1_TIMER_CONTROL_PRESCALER_DIV25,
+ timer->base + RZN1_TIMER_CONTROL_REG);
+ timer->rate = clock_rate / 25;
+ } else {
+ timer->width = 32;
+ timer->rate = clock_rate;
+ }
+ timer->hz_period = DIV_ROUND_UP(timer->rate, HZ);
+}
+
+static void rzn1_timer_clkevt_init_ced(struct rzn1_timer *timer, const char *name,
+ int irq)
+{
+ timer->ced.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
+ timer->ced.set_next_event = rzn1_clkevt_set_next_event;
+ timer->ced.set_state_shutdown = rzn1_clkevt_shutdown;
+ timer->ced.set_state_periodic = rzn1_clkevt_set_periodic;
+ timer->ced.cpumask = cpu_possible_mask;
+
+ /*
+ * 32-bit timers are fed with a 25 MHz clock directly derived from the
+ * main PLL (1 GHz). The arch timer, ARMv7 CP15 in RZ/N1 SoCs, is fed
+ * with to a 6.25 MHz clock.
+ *
+ * The clock of the RZ/N1 timers block is a stable one and the RZ/N1
+ * timers have a higher resolution than the ARM CP15 one.
+ *
+ * Also those 32-bit RZ/N1 timers are assigned per-cpu.
+ *
+ * Use a high rating for the 32-bit RZ/N1 timers in order to have them
+ * chosen by the system.
+ */
+ timer->ced.rating = timer->width == 16 ? 200 : 460;
+ timer->ced.owner = THIS_MODULE;
+ timer->ced.name = name;
+ timer->ced.irq = irq;
+}
+
+static int rzn1_timer_setup_timers(struct platform_device *pdev,
+ struct rzn1_timer *tab_timers,
+ unsigned int first_timer_index,
+ unsigned int last_timer_index,
+ void __iomem *base, unsigned long clock_rate)
+{
+ struct device *dev = &pdev->dev;
+ struct rzn1_timer *timer;
+ unsigned int i;
+ char *name;
+ int irq;
+ int ret;
+
+ for (i = first_timer_index; i <= last_timer_index; i++) {
+ timer = &tab_timers[i];
+
+ rzn1_timer_init(timer, i, base, clock_rate);
+
+ irq = platform_get_irq(pdev, i);
+ if (irq < 0)
+ return irq;
+
+ name = devm_kasprintf(dev, GFP_KERNEL, "%s-%u", dev_name(dev), i);
+ if (!name)
+ return -ENOMEM;
+
+ rzn1_timer_clkevt_init_ced(timer, name, irq);
+
+ ret = devm_request_irq(dev, timer->ced.irq, rzn1_timer_interrupt,
+ IRQF_TIMER, timer->ced.name, timer);
+ if (ret < 0)
+ return dev_err_probe(dev, irq, "timer%u: Failed to request IRQ\n", i);
+
+ rzn1_timer_int_enable(timer);
+ }
+ return 0;
+}
+
+static void rzn1_timer_register_clkevt(struct rzn1_timer *tab_timers,
+ unsigned int first_timer_index,
+ unsigned int last_timer_index)
+{
+ struct rzn1_timer *timer;
+ unsigned int i;
+
+ for (i = first_timer_index; i <= last_timer_index; i++) {
+ timer = &tab_timers[i];
+ clockevents_config_and_register(&timer->ced, timer->rate,
+ 1, GENMASK(timer->width - 1, 0));
+ }
+}
+
+static int rzn1_timer_probe_first(struct platform_device *pdev,
+ struct rzn1_timer *tab_timers,
+ void __iomem *base, unsigned long clock_rate)
+{
+ struct device *dev = &pdev->dev;
+ struct rzn1_timer *timer;
+ int ret;
+
+ /*
+ * Probe the first instance. In that case, timers are assigned as
+ * follow:
+ * - First 16-bit timer: clocksource and sched_clock
+ * - Other 16-bit timers: clock events for all possible CPUs
+ * - 32-bit timers: clock events per CPU
+ *
+ * First step, perform all operation that could fail without calling
+ * clockevents_config_and_register(), sched_clock_register() nor
+ * cpuhp_setup_state(). Those operation don't have unregister nor
+ * teardown counterparts and so, once called, we cannot remove the
+ * related resource.
+ */
+
+ /*
+ * First step for 16-bit timers except the first one and all 32-bit
+ * timers.
+ */
+ ret = rzn1_timer_setup_timers(pdev, tab_timers,
+ RZN1_TIMER_BASE_INDEX_16BIT_TIMERS + 1,
+ RZN1_TIMER_LAST_INDEX_32BIT_TIMERS,
+ base, clock_rate);
+ if (ret)
+ return ret;
+
+ /*
+ * Second step, almost all operations that can fail have been called.
+ * Timers are ready to work. Start with the last operation that can fail,
+ * installing and invoking hotplug callbacks
+ */
+ rzn1_tab_timers = tab_timers;
+ ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
+ "clockevents/rzn1/global_timer:starting",
+ rzn1_local_timer_starting_cpu, NULL);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Setup CPU hotplug state failed\n");
+
+ /*
+ * At this point, no more operations can fail. Perform remaining
+ * operations. Starting by handling the first 16-bit timer
+ */
+ timer = &tab_timers[RZN1_TIMER_BASE_INDEX_16BIT_TIMERS];
+
+ rzn1_timer_init(timer, RZN1_TIMER_BASE_INDEX_16BIT_TIMERS, base, clock_rate);
+ rzn1_timer_config(timer, GENMASK(timer->width - 1, 0), true);
+
+ rzn1_sched_clock = timer;
+
+ sched_clock_register(rzn1_sched_read, rzn1_sched_clock->width, rzn1_sched_clock->rate);
+
+ rzn1_clocksource.mask = CLOCKSOURCE_MASK(rzn1_sched_clock->width);
+ clocksource_register_hz(&rzn1_clocksource, rzn1_sched_clock->rate);
+
+ /*
+ * Register clockevents only for 16-bit timers. 32-bit timers clockevents
+ * are registered by CPU hotplug startup function set previously by the
+ * cpuhp_setup_state() call.
+ */
+ rzn1_timer_register_clkevt(tab_timers,
+ RZN1_TIMER_BASE_INDEX_16BIT_TIMERS + 1,
+ RZN1_TIMER_LAST_INDEX_16BIT_TIMERS);
+
+ return 0;
+}
+
+static int rzn1_timer_probe_other(struct platform_device *pdev,
+ struct rzn1_timer *tab_timers,
+ void __iomem *base, unsigned long clock_rate)
+{
+ int ret;
+
+ /*
+ * Probe other instance(s), i.e. not the first one. In that case,
+ * all timers are used as clock events and available for all possible
+ * CPUs
+ *
+ * First step, perform all operation that could fail without calling
+ * clockevents_config_and_register(). Unregister counterpart does not
+ * exist and so, once called, we cannot remove the related resource.
+ */
+ ret = rzn1_timer_setup_timers(pdev, tab_timers,
+ RZN1_TIMER_BASE_INDEX_16BIT_TIMERS,
+ RZN1_TIMER_LAST_INDEX_32BIT_TIMERS,
+ base, clock_rate);
+ if (ret)
+ return ret;
+
+ /*
+ * Second step, all operation that can fail have been called. We can
+ * register our timers.
+ */
+ rzn1_timer_register_clkevt(tab_timers,
+ RZN1_TIMER_BASE_INDEX_16BIT_TIMERS,
+ RZN1_TIMER_LAST_INDEX_32BIT_TIMERS);
+ return 0;
+}
+
+static int rzn1_timer_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct rzn1_timer *tab_timers;
+ unsigned long clock_rate;
+ void __iomem *base;
+ struct clk *clk;
+ int ret;
+
+ tab_timers = devm_kcalloc(dev, RZN1_TIMER_NB_TIMERS, sizeof(*tab_timers),
+ GFP_KERNEL);
+ if (!tab_timers)
+ return -ENOMEM;
+
+ base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ clk = devm_clk_get_enabled(dev, "pclk");
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk), "Failed to get pclk\n");
+
+ clock_rate = clk_get_rate(clk);
+
+ scoped_guard(mutex, &rzn1_global_timers_lock) {
+ ret = !rzn1_timer_instance ?
+ rzn1_timer_probe_first(pdev, tab_timers, base, clock_rate) :
+ rzn1_timer_probe_other(pdev, tab_timers, base, clock_rate);
+ if (!ret)
+ rzn1_timer_instance++;
+ }
+
+ return ret;
+}
+
+static const struct of_device_id rzn1_timer_of_match[] = {
+ { .compatible = "renesas,rzn1-timer", },
+ { /* sentinel */ }
+};
+
+static struct platform_driver rzn1_timer_driver = {
+ .driver = {
+ .name = "rzn1_timer",
+ .of_match_table = rzn1_timer_of_match,
+ .suppress_bind_attrs = true,
+ },
+};
+builtin_platform_driver_probe(rzn1_timer_driver, rzn1_timer_probe);
--
2.55.0
^ permalink raw reply related
* [PATCH v3 1/4] dt-bindings: timer: Add the Renesas RZ/N1 timer
From: Herve Codina (Schneider Electric) @ 2026-07-17 9:55 UTC (permalink / raw)
To: Wolfram Sang, Herve Codina, Daniel Lezcano, Thomas Gleixner,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: linux-renesas-soc, linux-kernel, devicetree, Pascal Eberhard,
Miquel Raynal, Thomas Petazzoni, Krzysztof Kozlowski
In-Reply-To: <20260717095552.767475-1-herve.codina@bootlin.com>
The Renesas RZ/N1 timer block controller is the controller in charge of
timers available in the Renesas RZ/N1 SoCs family.
This controller handles 8 timers:
- 6 16-bit timers
- 2 32-bit timers
Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
.../bindings/timer/renesas,rzn1-timer.yaml | 74 +++++++++++++++++++
1 file changed, 74 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/renesas,rzn1-timer.yaml
diff --git a/Documentation/devicetree/bindings/timer/renesas,rzn1-timer.yaml b/Documentation/devicetree/bindings/timer/renesas,rzn1-timer.yaml
new file mode 100644
index 000000000000..f00ad941f8cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/renesas,rzn1-timer.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/renesas,rzn1-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/N1 timers
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description: |
+ The Renesas RZ/N1 SoCs timers block controller is composed of 8 independent
+ timers.
+ - 6 are 16-bit timers
+ - 2 are 32-bit timers
+
+ Each timer has its own interrupt line and can work in either one-shot or
+ periodic mode.
+
+properties:
+ compatible:
+ items:
+ - const: renesas,r9a06g032-timer # RZ/N1D
+ - const: renesas,rzn1-timer
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: APB internal bus clock
+
+ clock-names:
+ items:
+ - const: pclk
+
+ power-domains:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 8
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/r9a06g032-sysctrl.h>
+
+ timer@51001000 {
+ compatible = "renesas,r9a06g032-timer", "renesas,rzn1-timer";
+ reg = <0x51001000 0x400>;
+ clocks = <&sysctrl R9A06G032_HCLK_TIMER0>;
+ clock-names = "pclk";
+ power-domains = <&sysctrl>;
+ interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ };
+...
--
2.55.0
^ permalink raw reply related
* [PATCH v3 0/4] timers: Add support for RZ/N1 SoCs timers
From: Herve Codina (Schneider Electric) @ 2026-07-17 9:55 UTC (permalink / raw)
To: Wolfram Sang, Herve Codina, Daniel Lezcano, Thomas Gleixner,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: linux-renesas-soc, linux-kernel, devicetree, Pascal Eberhard,
Miquel Raynal, Thomas Petazzoni
The Renesas RZ/N1 SoCs family has two timers block controller
available.
Each controller is charge of 8 timers (six 16-bit timers + two 32-bit
timers).
Each timer has its own interrupt, its own prescaler that can be used to
device the clock by 25 (timers block are fed with a 25 MHz clock) and
all timers can work in either one-shot or periodic mode.
This series adds support for those timers blocks.
Best regards,
Hervé
Changes v2 -> v3
v2: https://lore.kernel.org/all/20260429115054.158160-1-herve.codina@bootlin.com/
Rebase on top of v7.2-rc1.
Patch 1, 3 and 4:
- Add 'Reviewed-by: Geert Uytterhoeven'
Patch 2:
- Fix typos in commit log.
- Split Kconfig 'depends on' in 2 lines.
- Fix indentation, space and alignment in code.
- Fix dev_err_probe() conversion format.
- Introduce rzn1_timer_setup_timers() and rzn1_timer_register_clkevt()
to avoid code duplication in rzn1_timer_probe_{first,other}()
- Add '.suppress_bind_attrs = true'.
Changes v1 -> v2
v1: https://lore.kernel.org/all/20260331152616.197031-1-herve.codina@bootlin.com/
Rebase on top of v7.1-rc1.
Patch 1:
- Drop minItems related to interrupts property
- Add 'Reviewed-by: Krzysztof Kozlowski'
Patches 2, 3 and 4:
No changes
Herve Codina (Schneider Electric) (4):
dt-bindings: timer: Add the Renesas RZ/N1 timer
clocksource/drivers: Add support for the Renesas RZ/N1 timers
ARM: dts: r9a06g032: Add support for timers
MAINTAINERS: Add the Renesas RZ/N1 timers driver entry
.../bindings/timer/renesas,rzn1-timer.yaml | 74 +++
MAINTAINERS | 7 +
arch/arm/boot/dts/renesas/r9a06g032.dtsi | 34 ++
drivers/clocksource/Kconfig | 11 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-rzn1.c | 455 ++++++++++++++++++
6 files changed, 582 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/renesas,rzn1-timer.yaml
create mode 100644 drivers/clocksource/timer-rzn1.c
--
2.55.0
^ permalink raw reply
* Re: [PATCH v3 2/4] mfd: axp20x: Add support for AXP318W PMIC
From: Jerome Brunet @ 2026-07-17 9:51 UTC (permalink / raw)
To: sashiko-bot; +Cc: sashiko-reviews, conor+dt, devicetree, robh
In-Reply-To: <20260717090209.2A09B1F000E9@smtp.kernel.org>
On ven. 17 juil. 2026 at 09:02, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [Medium] The newly added I2C device ID `axp318w` fails to use named initializers and omits the `.driver_data` field, resulting in it defaulting to `0` (`AXP152_ID`).
> - [Medium] The MFD cell and resources for the power key (`axp20x-pek`) are completely omitted from `axp318_cells`, despite the commit message claiming to support it and IRQs being defined.
> - [Low] The `axp318_cells` array uses a hard-coded ID of `1` for the regulator cell, which violates MFD subsystem guidelines and risks sysfs naming collisions.
> --
>
> --- Patch [2]: [PATCH v3 2/4] mfd: axp20x: Add support for AXP318W PMIC ---
> commit c0a61d967fff87b52d26e4cb329e69e10684fb89
> Author: Andre Przywara <andre.przywara@arm.com>
>
> mfd: axp20x: Add support for AXP318W PMIC
>
> This patch adds support for the AXP318W PMIC connected via I2C. It sets up
> the regmap configurations, volatile ranges, interrupts, and registers the
> MFD cells for the regulator devices.
>
>> Describe the regmap and the MFD bits, along with the registers exposed
>> via I2C only. This covers the regulator, interrupts and power key
>> devices for now.
>
> [Severity: Medium]
> Is the power key device missing from the MFD cells array in this patch? The
> commit message mentions it is covered, but there are no power key resources
> or cells defined for the AXP318W.
Had fixed that but rebasing multiple time a lost it somehow ... will fix.
>
>> diff --git a/drivers/mfd/axp20x-i2c.c b/drivers/mfd/axp20x-i2c.c
>> index 5c93136f977e7..4e4ebfc78525c 100644
>> --- a/drivers/mfd/axp20x-i2c.c
>> +++ b/drivers/mfd/axp20x-i2c.c
>> @@ -83,6 +84,7 @@ static const struct i2c_device_id axp20x_i2c_id[] = {
>> { "axp221" },
>> { "axp223" },
>> { "axp313a" },
>> + { "axp318w" },
>
> [Severity: Medium]
> Does this need named initializers to provide the .driver_data payload?
>
> Without setting .driver_data like the of_device_id table does, won't this
> default to 0, which is AXP152_ID? If this device is instantiated via legacy
> I2C methods, device_get_match_data() might return AXP152_ID instead,
> causing the driver to mistakenly configure it as an AXP152 variant.
I don't think this driver as ever been intanciated through the legacy
i2c interface or was meant to be. While this may need to looked at for
correctness, this is not something new introduced by this change
>
>> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
>> index 679364189ea58..c8aeebd01bbcd 100644
>> --- a/drivers/mfd/axp20x.c
>> +++ b/drivers/mfd/axp20x.c
> [ ... ]
>> @@ -1061,6 +1129,10 @@ static struct mfd_cell axp313a_cells[] = {
>> MFD_CELL_RES("axp313a-pek", axp313a_pek_resources),
>> };
>>
>> +static const struct mfd_cell axp318_cells[] = {
>> + MFD_CELL_BASIC("axp20x-regulator", NULL, NULL, 0, 1),
>
> [Severity: Low]
> Should this use PLATFORM_DEVID_AUTO instead of a hard-coded ID of 1?
>
> Assigning a hardcoded ID can lead to device naming collisions in sysfs if
> multiple instances of the device are present.
PLATFORM_DEVID_AUTO does not go in here as far as can tell.
The driver uses PLATFORM_DEVID_NONE while registering the device.
I honestly do not know the reason, if there is one. If it is problem, it
is not related to this specific change. I don't mind submitting a change
for this but
1) it should not be mixed with this series
2) I can't test the other devices
>
>> +};
>> +
--
Jerome
^ permalink raw reply
* RE: [PATCH v9 2/4] clk: cix: add sky1 audss clock controller
From: Joakim Zhang @ 2026-07-17 9:47 UTC (permalink / raw)
To: Brian Masney
Cc: mturquette@baylibre.com, sboyd@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, p.zabel@pengutronix.de,
cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <allvw2ZiiyX5SGIk@redhat.com>
Hello Brian,
Thanks for your kindly review.
> -----Original Message-----
> From: Brian Masney <bmasney@redhat.com>
> Sent: Friday, July 17, 2026 7:57 AM
> To: Joakim Zhang <joakim.zhang@cixtech.com>
> Cc: mturquette@baylibre.com; sboyd@kernel.org; robh@kernel.org;
> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de; cix-kernel-
> upstream <cix-kernel-upstream@cixtech.com>; linux-clk@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v9 2/4] clk: cix: add sky1 audss clock controller
[...]
> > diff --git a/drivers/clk/cix/clk-sky1-audss.c
> > b/drivers/clk/cix/clk-sky1-audss.c
> > new file mode 100644
> > index 000000000000..5f9133232eb1
> > --- /dev/null
> > +++ b/drivers/clk/cix/clk-sky1-audss.c
> > @@ -0,0 +1,1205 @@
> > +// SPDX-License-Identifier: GPL-2.0-only // Copyright 2026 Cix
> > +Technology Group Co., Ltd.
> > +
> > +#include <linux/auxiliary_bus.h>
> > +#include <linux/clk.h>
> > +#include <linux/clk-provider.h>
> > +#include <linux/device.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
>
> You can drop this include since you are only using of_device_id. You will get it
> via two different chains:
>
> <linux/platform_device.h>
> -> <linux/device.h>
> -> <linux/device/driver.h>
> -> <linux/device-id/of.h>
>
> linux/clk-provider.h -> linux/of.h -> linux/device-id/of.h
> (Pasted from a review on a different series a little bit ago.)
Fine, will drop of_device.h.
[...]
> > +/* register sky1 audio subsystem clocks */ static int
> > +sky1_audss_clk_probe(struct platform_device *pdev) {
> > + const struct sky1_audss_clks_devtype_data *devtype_data;
> > + struct sky1_audss_clks_priv *priv;
> > + struct device *dev = &pdev->dev;
> > + struct clk_hw **clk_table;
> > + void __iomem *base;
> > + int i, ret;
> > +
> > + devtype_data = device_get_match_data(dev);
> > + if (!devtype_data)
> > + return -ENODEV;
> > +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + spin_lock_init(&priv->lock);
> > +
> > + priv->clk_data = devm_kzalloc(dev,
> > + struct_size(priv->clk_data, hws,
> SKY1_AUDSS_NUM_CLKS),
> > + GFP_KERNEL);
> > + if (!priv->clk_data)
> > + return -ENOMEM;
> > +
> > + priv->clk_data->num = SKY1_AUDSS_NUM_CLKS;
> > + clk_table = priv->clk_data->hws;
> > +
> > + base = devm_platform_ioremap_resource(pdev, 0);
> > + if (IS_ERR(base))
> > + return PTR_ERR(base);
> > +
> > + priv->regmap_cru = devm_regmap_init_mmio(dev, base,
> &sky1_audss_regmap_config);
> > + if (IS_ERR(priv->regmap_cru))
> > + return dev_err_probe(dev, PTR_ERR(priv->regmap_cru),
> > + "failed to initialize regmap\n");
> > +
> > + priv->dev = dev;
> > + priv->devtype_data = devtype_data;
> > +
> > + priv->rst_noc = devm_reset_control_get_exclusive(dev, NULL);
> > + if (IS_ERR(priv->rst_noc))
> > + return dev_err_probe(dev, PTR_ERR(priv->rst_noc),
> > + "failed to get audss noc reset");
> > +
> > + reset_control_assert(priv->rst_noc);
> > +
> > + reset_control_deassert(priv->rst_noc);
> > +
> > + pm_runtime_get_noresume(dev);
> > + pm_runtime_set_active(dev);
> > + pm_runtime_enable(dev);
> > +
> > + platform_set_drvdata(pdev, priv);
> > +
> > + ret = sky1_audss_clks_get(priv);
> > + if (ret)
> > + goto err_pm;
> > +
> > + ret = sky1_audss_clks_enable(priv);
> > + if (ret) {
> > + dev_err(dev, "failed to enable clocks\n");
> > + goto err_pm;
> > + }
> > +
> > + ret = sky1_audss_clks_set_rate(priv);
> > + if (ret) {
> > + dev_err(dev, "failed to set clocks rate\n");
> > + goto fail_clks_set;
>
> So starting here... Is there a double put below? I'll flag it below.
>
> > + }
> > +
> > + /* audio_clk4 clock fixed divider */
> > + clk_table[CLK_AUD_CLK4_DIV2] =
> > + devm_clk_hw_register_fixed_factor(dev,
> > + "audio_clk4_div2",
> > + "audio_clk4",
> > + 0,
> > + 1, 2);
> > + if (IS_ERR(clk_table[CLK_AUD_CLK4_DIV2])) {
> > + ret = PTR_ERR(clk_table[CLK_AUD_CLK4_DIV2]);
> > + dev_err(dev, "failed to register clock %d, ret:%d\n",
> CLK_AUD_CLK4_DIV2, ret);
> > + goto fail_fixed_clk;
> > + }
> > +
> > + clk_table[CLK_AUD_CLK4_DIV4] =
> > + devm_clk_hw_register_fixed_factor(dev,
> > + "audio_clk4_div4",
> > + "audio_clk4",
> > + 0,
> > + 1, 4);
> > + if (IS_ERR(clk_table[CLK_AUD_CLK4_DIV4])) {
> > + ret = PTR_ERR(clk_table[CLK_AUD_CLK4_DIV4]);
> > + dev_err(dev, "failed to register clock %d, ret:%d\n",
> CLK_AUD_CLK4_DIV4, ret);
> > + goto fail_fixed_clk;
> > + }
> > +
> > + /* audio_clk5 clock fixed divider */
> > + clk_table[CLK_AUD_CLK5_DIV2] =
> > + devm_clk_hw_register_fixed_factor(dev,
> > + "audio_clk5_div2",
> > + "audio_clk5",
> > + 0,
> > + 1, 2);
> > + if (IS_ERR(clk_table[CLK_AUD_CLK5_DIV2])) {
> > + ret = PTR_ERR(clk_table[CLK_AUD_CLK5_DIV2]);
> > + dev_err(dev, "failed to register clock %d, ret:%d\n",
> CLK_AUD_CLK5_DIV2, ret);
> > + goto fail_fixed_clk;
> > + }
> > +
> > + for (i = 0; i < devtype_data->clk_cfg_size; i++) {
> > + clk_table[devtype_data->clk_cfg[i].id] =
> > + sky1_audss_clk_register(dev,
> > + devtype_data->clk_cfg[i].name,
> > + devtype_data->clk_cfg[i].parent_names,
> > + devtype_data->clk_cfg[i].num_parents,
> > + priv->regmap_cru,
> > + devtype_data->clk_cfg[i].mux_table,
> > + devtype_data->clk_cfg[i].mux_cfg,
> > + devtype_data->clk_cfg[i].div_cfg,
> > + devtype_data->clk_cfg[i].gate_cfg,
> > + devtype_data->clk_cfg[i].flags,
> > + &priv->lock);
> > + if (IS_ERR(clk_table[devtype_data->clk_cfg[i].id])) {
> > + ret = PTR_ERR(clk_table[devtype_data->clk_cfg[i].id]);
> > + dev_err(dev, "failed to register clock %d, ret:%d\n",
> > + devtype_data->clk_cfg[i].id, ret);
> > + goto fail_fixed_clk;
> > + }
> > + }
> > +
> > + ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, priv-
> >clk_data);
> > + if (ret) {
> > + dev_err(dev, "failed to add clock provider: %d\n", ret);
> > + goto fail_register;
> > + }
> > +
> > + ret = sky1_audss_reset_controller_register(dev);
> > + if (ret)
> > + goto fail_register;
> > +
> > + pm_runtime_put_sync(dev);
> > +
> > + return 0;
> > +
> > +fail_register:
> > +fail_fixed_clk:
> > +fail_clks_set:
>
> Collapse these 3 labels into 1.
>
> > + pm_runtime_put_sync(dev);
> > +err_pm:
> > + pm_runtime_put_noidle(dev);
>
> So above where I flagged the 'goto fail_clks_set', is this a double put?
On the double-put concern: fail_* paths run put_sync() (usage 1->0) then fall through to put_noidle(). put_noidle() usesatomic_add_unless(..., -1, 0), so it is a no-op when the counter is already 0. But it still seems rather strange, I will refine the sequence to avoid it.
> > + pm_runtime_disable(dev);
> > + return ret;
> > +}
> > +
> > +static void sky1_audss_clk_remove(struct platform_device *pdev) {
> > + struct device *dev = &pdev->dev;
> > +
> > + if (!pm_runtime_status_suspended(dev))
> > + pm_runtime_force_suspend(dev);
> > +
> > + pm_runtime_disable(dev);
>
> I am fairly certain that remove() is called before the devm handlers are
> invoked. The clocks will be shutdown, but there's a window where they are still
> visible to consumers. I think you should use
> devm_add_action_or_reset() so that the cleanup is called in the expected order.
Agreed. remove() runs before devres_release_all(), so force_suspend() tears down the hardware while the OF clock provider is still visible. I'll move the runtime PM cleanup into a devm_add_action_or_reset() registered before the clocks/provider, and drop it from remove().
> > +}
> > +
> > +static int __maybe_unused sky1_audss_clk_runtime_suspend(struct
> > +device *dev) {
> > + struct sky1_audss_clks_priv *priv = dev_get_drvdata(dev);
> > + const struct sky1_audss_clks_devtype_data *devtype_data = priv-
> >devtype_data;
> > + unsigned long flags;
> > + int i;
> > +
> > + spin_lock_irqsave(&priv->lock, flags);
> > + for (i = 0; i < devtype_data->reg_save_size; i++)
> > + regmap_read(priv->regmap_cru,
> > + devtype_data->reg_save[i][0], &devtype_data-
> >reg_save[i][1]);
> > + spin_unlock_irqrestore(&priv->lock, flags);
> > +
> > + sky1_audss_clks_disable(priv);
> > +
> > + return reset_control_assert(priv->rst_noc);
> > +}
> > +
> > +static int __maybe_unused sky1_audss_clk_runtime_resume(struct device
> > +*dev) {
> > + struct sky1_audss_clks_priv *priv = dev_get_drvdata(dev);
> > + const struct sky1_audss_clks_devtype_data *devtype_data = priv-
> >devtype_data;
> > + unsigned long flags;
> > + int i, ret;
> > +
> > + ret = reset_control_deassert(priv->rst_noc);
> > + if (ret)
> > + return ret;
> > +
> > + ret = sky1_audss_clks_enable(priv);
> > + if (ret) {
> > + dev_err(dev, "failed to enable clocks\n");
> > + reset_control_assert(priv->rst_noc);
> > + return ret;
> > + }
> > +
> > + spin_lock_irqsave(&priv->lock, flags);
> > + for (i = 0; i < devtype_data->reg_save_size; i++)
> > + regmap_write(priv->regmap_cru,
> > + devtype_data->reg_save[i][0],
> > + devtype_data->reg_save[i][1]);
>
> Does it matter what order the registers are written on resume?
No, it doesn't matter.
I will send the v10 soon.
Thanks,
Joakim
^ permalink raw reply
* Re: [PATCH net-next v8 4/4] net: pse-pd: realtek-pse-mcu: add UART transport
From: Kory Maincent @ 2026-07-17 9:46 UTC (permalink / raw)
To: Jonas Jelonek
Cc: Oleksij Rempel, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, devicetree, linux-kernel, Daniel Golle,
Bjørn Mork
In-Reply-To: <20260715075530.2491534-5-jelonek.jonas@gmail.com>
On Wed, 15 Jul 2026 07:55:28 +0000
Jonas Jelonek <jelonek.jonas@gmail.com> wrote:
> Add the serdev (UART) transport for the Realtek PSE MCU core. It registers
> the MCU as a serdev device and provides the send/recv callbacks the core
> uses to exchange the 12-byte frames, receiving asynchronously via the
> serdev receive_buf callback.
>
> The baud rate defaults to 19200 and can be overridden per board with the
> "current-speed" property.
>
> Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Thank you!
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next v8 3/4] net: pse-pd: realtek-pse-mcu: add I2C transport
From: Kory Maincent @ 2026-07-17 9:45 UTC (permalink / raw)
To: Jonas Jelonek
Cc: Oleksij Rempel, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, devicetree, linux-kernel, Daniel Golle,
Bjørn Mork
In-Reply-To: <20260715075530.2491534-4-jelonek.jonas@gmail.com>
On Wed, 15 Jul 2026 07:55:27 +0000
Jonas Jelonek <jelonek.jonas@gmail.com> wrote:
> Add the I2C/SMBus transport for the Realtek PSE MCU core. It registers
> the MCU on an I2C bus and provides the send/recv callbacks the core
> uses to exchange the 12-byte frames.
>
> The MCU firmware expects one of two framings on the I2C bus, and which one
> is part of the compatible: '-smbus' (reads carry a leading command byte
> and a repeated start) or raw '-i2c' (bare block writes and reads). The
> match data flags the raw-I2C case; SMBus is the default because that's
> what the majority of devices uses.
>
> Because i2c_master_send()/i2c_master_recv() may DMA, the raw-I2C path
> bounces each frame through a heap buffer rather than the core's stack
> buffers; the SMBus path is unaffected.
>
> Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Thank you!
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next v8 2/4] net: pse-pd: add Realtek PSE MCU core
From: Kory Maincent @ 2026-07-17 9:41 UTC (permalink / raw)
To: Jonas Jelonek
Cc: Oleksij Rempel, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, devicetree, linux-kernel, Daniel Golle,
Bjørn Mork
In-Reply-To: <20260715075530.2491534-3-jelonek.jonas@gmail.com>
On Wed, 15 Jul 2026 07:55:26 +0000
Jonas Jelonek <jelonek.jonas@gmail.com> wrote:
> A range of managed Realtek-based PoE switches use a small microcontroller
> on the PCB to front the actual PSE silicon. The host CPU talks to that
> MCU over I2C/SMBus or UART using a fixed 12-byte request/response
> protocol with a trailing checksum; the PSE chips are managed by the MCU
> and are not accessed directly. Two generations of the protocol exist -
> both Realtek's - diverging in opcode numbering and a few response
> layouts; the driver handles this with a per-dialect opcode table and
> parser hooks for the responses that differ, selected by the compatible.
> The specific PSE chip behind the MCU is detected at runtime and only
> influences per-chip constants (power scaling and the per-port cap).
>
> This core module implements the protocol, message framing, the dialect
> machinery and the pse_controller_ops glue, and exports a registration
> helper for transport modules. The I2C and UART transports that drive it
> follow in the next patches; the core (PSE_REALTEK_MCU) is selected
> automatically by those transports and is not user-selectable on its own.
>
> The realtek-pse-mcu-* files and PSE_REALTEK_MCU* symbols match the
> realtek,pse-mcu-* compatibles (see the binding for the naming rationale).
> The two protocol generations - gen1 on older Broadcom-PSE boards, gen2 on
> Realtek's own PSE silicon - are both Realtek's, handled by the same shared
> core, each selecting its dialect via the compatible.
>
> Power budgeting is left to the MCU firmware; the driver advertises
> PSE_BUDGET_EVAL_STRAT_DYNAMIC (controller-managed budget) accordingly.
>
> Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Thank you!
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 00/11] rust: driver: use pointers instead of indices for ID info
From: Greg Kroah-Hartman @ 2026-07-17 9:40 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Gary Guo, Rafael J. Wysocki, Viresh Kumar, Uwe Kleine-König,
Michal Wilczynski, Igor Korotin, Rob Herring, Miguel Ojeda,
Boqun Feng, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, FUJITA Tomonori, David Airlie,
Simona Vetter, Bjorn Helgaas, Krzysztof Wilczyński,
Abdiel Janulgue, Robin Murphy, Dave Ertman, Ira Weiny,
Leon Romanovsky, Len Brown, Saravana Kannan, Drew Fustini,
Guo Ren, Fu Wei, driver-core, rust-for-linux, linux-kernel,
netdev, nova-gpu, dri-devel, linux-pci, linux-acpi, devicetree,
linux-pm, linux-pwm, linux-usb
In-Reply-To: <DK08KE2A3M7K.3OQDFZB94SMFC@kernel.org>
On Thu, Jul 16, 2026 at 09:18:05PM +0200, Danilo Krummrich wrote:
> On Mon Jun 29, 2026 at 2:39 PM CEST, Gary Guo wrote:
> > MAINTAINERS | 1 -
> > drivers/acpi/bus.c | 6 +-
> > drivers/cpufreq/rcpufreq_dt.rs | 1 -
> > drivers/gpu/drm/nova/driver.rs | 1 -
> > drivers/gpu/drm/tyr/driver.rs | 1 -
> > drivers/gpu/nova-core/driver.rs | 3 +-
> > drivers/pwm/pwm_th1520.rs | 1 -
> > include/acpi/acpi_bus.h | 11 --
> > rust/helpers/acpi.c | 16 ---
> > rust/helpers/helpers.c | 1 -
> > rust/kernel/acpi.rs | 14 +--
> > rust/kernel/auxiliary.rs | 18 +--
> > rust/kernel/device_id.rs | 207 +++++++++++++++++++---------------
> > rust/kernel/driver.rs | 137 ++--------------------
> > rust/kernel/i2c.rs | 26 ++---
> > rust/kernel/net/phy.rs | 66 +----------
> > rust/kernel/of.rs | 14 +--
> > rust/kernel/pci.rs | 25 ++--
> > rust/kernel/platform.rs | 5 +-
> > rust/kernel/usb.rs | 24 ++--
> > samples/rust/rust_debugfs.rs | 1 -
> > samples/rust/rust_dma.rs | 3 +-
> > samples/rust/rust_driver_auxiliary.rs | 4 +-
> > samples/rust/rust_driver_i2c.rs | 3 -
> > samples/rust/rust_driver_pci.rs | 11 +-
> > samples/rust/rust_driver_platform.rs | 2 -
> > samples/rust/rust_driver_usb.rs | 3 +-
> > samples/rust/rust_i2c_client.rs | 2 -
> > samples/rust/rust_soc.rs | 2 -
> > 29 files changed, 178 insertions(+), 431 deletions(-)
>
> I plan to pick this up soon. Please let me know in case there are any concerns
> from the acpi, i2c, of, net or usb side of things.
No objection from me fo rthe USB stuff:
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v2 3/5] arm64: dts: qcom: agatti: add LPASS devices
From: Konrad Dybcio @ 2026-07-17 9:39 UTC (permalink / raw)
To: Srinivas Kandagatla, lee, robh, krzk+dt, conor+dt, andersson,
konradybcio, sboyd
Cc: linux-arm-msm, devicetree, linux-kernel, alexey.klimov, r.mereu,
srini
In-Reply-To: <db2942d7-720e-46de-a614-d9469a72d69a@oss.qualcomm.com>
On 5/15/26 10:29 AM, Srinivas Kandagatla wrote:
> On 2/24/26 12:28 PM, Konrad Dybcio wrote:
>> On 2/23/26 2:39 PM, Srinivas Kandagatla wrote:
>>> From: Alexey Klimov <alexey.klimov@linaro.org>
>>>
>>> The rxmacro, txmacro, vamacro, soundwire nodes, lpass clock
>>> controllers are required to support audio playback and
>>> audio capture on sm6115 and its derivatives.
>>>
>>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
>>> ---
> I would suggest that we use the existing mechanism which is more future
> proof.
>
>
> Please suggest otherwise, I would like to move on with enabling audio on
> UNO Q platform.
If you pinky-promise we are never ever going to need the other registers
(or if we do, you'll be able to represent them reasonably), we can go
forward with the established practice
Konrad
^ permalink raw reply
* Re: [PATCH net-next v8 1/4] dt-bindings: net: pse-pd: add bindings for Realtek PSE MCU
From: Kory Maincent @ 2026-07-17 9:39 UTC (permalink / raw)
To: Jonas Jelonek
Cc: Oleksij Rempel, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, devicetree, linux-kernel, Daniel Golle,
Bjørn Mork, Conor Dooley
In-Reply-To: <20260715075530.2491534-2-jelonek.jonas@gmail.com>
On Wed, 15 Jul 2026 07:55:25 +0000
Jonas Jelonek <jelonek.jonas@gmail.com> wrote:
> Add a binding for the microcontroller (MCU) that fronts the PSE silicon
> on a range of managed Realtek-based switches. The host talks only to the
> MCU, over I2C/SMBus or UART, using a fixed message-based protocol; the
> PSE chips behind it never appear on the bus.
>
> The device is the MCU together with its Realtek firmware: the firmware
> and its host protocol are what the binding describes, not the
> general-purpose microcontroller they run on. The PSE silicon behind the
> MCU (Realtek or Broadcom) is reported by the MCU and detected at runtime,
> so it is not described here - hence the 'realtek' vendor prefix.
>
> Two protocol generations exist, both Realtek's, selected by the
> compatible: gen1 on older boards (fronting Broadcom PSE silicon) and gen2,
> the altered protocol used with Realtek's own PSE silicon. On an I2C
> attachment the framing the MCU firmware expects is part of the compatible
> as well - '-smbus' or raw '-i2c'; a UART attachment carries no framing
> suffix, as the transport is given by the parent serial node.
>
> Each board additionally carries a device-specific compatible that falls
> back to one of the protocol compatibles above. Drivers bind on the
> protocol compatible; the device-specific string identifies the board and
> reserves a place for a future per-board quirk without having to retrofit
> device trees already in the field.
>
> Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Thank you!
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH RESEND v10 2/2] arm64: dts: qcom: kodiak: Add EL2 overlay
From: Konrad Dybcio @ 2026-07-17 9:37 UTC (permalink / raw)
To: Mukesh Ojha, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Sumit Garg
In-Reply-To: <20260714071943.2036353-3-mukesh.ojha@oss.qualcomm.com>
On 7/14/26 9:19 AM, Mukesh Ojha wrote:
> All existing Kodiak board variants run the Gunyah hypervisor, which
> means Linux can only boot at EL1 on those devices. It is possible to
> boot Linux at EL2 on these devices [1].
>
> When running under Gunyah, remote processor firmware IOMMU streams are
> controlled by Gunyah. Without Gunyah, the IOMMU is managed by the
> consumer of the DeviceTree. Describe the firmware streams for each
> remote processor in an EL2 overlay.
>
> Add an EL2-specific DT overlay and apply it to Kodiak IoT variant
> devices to produce a -el2.dtb alongside the standard dtb. Modem and
> media subsystems are not yet supported due to missing dependencies.
> The GPU zap shader is disabled. In EL2 mode the kernel owns the
> hardware watchdog, so it is enabled here. The wifi-firmware child
> node describes the IOMMU stream for the WCN6750 firmware; the &wifi
> node itself is left untouched so that platforms without WiFi are
> unaffected by the overlay.
>
> [1] https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi
>
> Co-developed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
If gunyah reserves gpu_zap_mem, we could probably shave it off too
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v4 11/11] arm64: dts: qcom: monaco-arduino-monza: Add QCA2066 M.2 WiFi/BT support
From: Bartosz Golaszewski @ 2026-07-17 9:35 UTC (permalink / raw)
To: Loic Poulain
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree, Manivannan Sadhasivam, Konrad Dybcio,
Dmitry Baryshkov, Manivannan Sadhasivam, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260716-monza-wireless-v4-11-9b02e6f549d7@oss.qualcomm.com>
On Thu, 16 Jul 2026 18:18:28 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> Add support for the QCA2066 (QCNFA765) WiFi/Bluetooth module on the
> Arduino VENTUNO Q board. The module is interfaced via LGA and is
> compatible with the M.2 Key E.
>
> Add wireless-lga-connector node using pcie-m2-e-connector binding,
> connecting PCIe port 0 to the WiFi interface and UART10 port 3 to
> the Bluetooth interface.
>
> Add pcie@1,0 downstream port node with pciclass,0604 compatible so
> the pci-pwrctrl driver can acquire the power sequencer and enable
> the M.2 slot before PCIe enumeration.
>
> Add nfa725b_default_state pinctrl for the W_DISABLE1/2 GPIOs
> (gpio56/gpio55) used by the power sequencer.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v4 08/11] Bluetooth: hci_qca: Support QCA2066 on M.2 connector via pwrseq
From: Bartosz Golaszewski @ 2026-07-17 9:35 UTC (permalink / raw)
To: Loic Poulain
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree, Manivannan Sadhasivam, Manivannan Sadhasivam,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <20260716-monza-wireless-v4-8-9b02e6f549d7@oss.qualcomm.com>
On Thu, 16 Jul 2026 18:18:25 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> For QCA2066 (and other QCA chips) on M.2 connectors, the UART enable is
> controlled by the W_DISABLE2# signal managed by the pcie-m2 power sequencer
> rather than a dedicated BT enable GPIO.
>
> When the serdev controller has an OF graph (indicating it is connected to
> an M.2 connector), acquire the 'uart' pwrseq target from the connector's
> power sequencer and use it to control BT power instead of the bt-enable
> GPIO. This is factored out into qca_serdev_get_m2_pwrseq().
>
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> drivers/bluetooth/hci_qca.c | 41 +++++++++++++++++++++++++++++++----------
> 1 file changed, 31 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 25c4387136245fca25e375951f960d7240116781..22f6185a946ef04c45e41b2b34126e3f58d603ca 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -1872,6 +1872,9 @@ static int qca_power_on(struct hci_dev *hdev)
> /* Controller needs time to bootup. */
> msleep(150);
> }
> +
> + if (qcadev->bt_power.pwrseq)
> + pwrseq_power_on(qcadev->bt_power.pwrseq);
> }
>
> clear_bit(QCA_BT_OFF, &qca->flags);
> @@ -2387,6 +2390,28 @@ static int qca_init_regulators(struct qca_power *qca,
> return 0;
> }
>
> +static void qca_serdev_put_pwrseq(void *data)
> +{
> + pwrseq_put(data);
> +}
> +
> +static int qca_serdev_get_m2_pwrseq(struct qca_serdev *qcadev)
> +{
> + struct serdev_device *serdev = qcadev->serdev_hu.serdev;
> + struct pwrseq_desc *pwrseq;
> +
> + if (!of_graph_is_present(dev_of_node(&serdev->ctrl->dev)))
> + return 0;
> +
> + pwrseq = pwrseq_get(&serdev->ctrl->dev, "uart");
There's devm_pwrseq_get() you can use instead of scheduling your own action.
> + if (IS_ERR(pwrseq))
> + return PTR_ERR(pwrseq);
> +
> + qcadev->bt_power.pwrseq = pwrseq;
> +
> + return devm_add_action_or_reset(&serdev->dev, qca_serdev_put_pwrseq, pwrseq);
> +}
> +
> static int qca_serdev_probe(struct serdev_device *serdev)
> {
> struct qca_serdev *qcadev;
> @@ -2417,6 +2442,10 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> else
> qcadev->btsoc_type = QCA_ROME;
>
> + err = qca_serdev_get_m2_pwrseq(qcadev);
> + if (err)
> + return err;
> +
> switch (qcadev->btsoc_type) {
> case QCA_WCN3950:
> case QCA_WCN3988:
> @@ -2426,17 +2455,9 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> case QCA_WCN6750:
> case QCA_WCN6855:
> case QCA_WCN7850:
> - /*
> - * OF graph link is only present for BT devices attached through
> - * the M.2 Key E connector.
> - */
> - if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
> - qcadev->bt_power.pwrseq = devm_pwrseq_get(&serdev->ctrl->dev,
> - "uart");
> - if (IS_ERR(qcadev->bt_power.pwrseq))
> - return PTR_ERR(qcadev->bt_power.pwrseq);
> + /* M.2 connector modules are powered by the pwrseq acquired above. */
> + if (qcadev->bt_power.pwrseq)
> break;
> - }
>
> if (!device_property_present(&serdev->dev, "enable-gpios")) {
> /*
>
> --
> 2.34.1
>
>
Bart
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: clock: qcom: glymur-gcc: Add missing CX power domain
From: Konrad Dybcio @ 2026-07-17 9:34 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson
Cc: Abel Vesa, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Maulik Shah,
Dmitry Baryshkov, Jyothi Kumar Seerapu, Brian Masney,
Krzysztof Kozlowski, Sibi Sankar, Pankaj Patil, Akhil P Oommen,
linux-arm-msm, linux-clk, devicetree, linux-kernel,
Jishnu Prakash, Raviteja Laggyshetty, Kamal Wadhwa, Qiang Yu,
Manaf Meethalavalappu Pallikunhi, Abel Vesa
In-Reply-To: <2e9a211d-a877-419a-ba8d-40bfc42e65ef@oss.qualcomm.com>
On 7/17/26 11:30 AM, Taniya Das wrote:
>
>
> On 7/17/2026 6:45 AM, Bjorn Andersson wrote:
>> On Thu, Jul 16, 2026 at 04:42:11PM +0530, Taniya Das wrote:
>>>
>>>
>>> On 7/16/2026 12:52 PM, Abel Vesa wrote:
>>>> On 26-07-16 10:13:48, Taniya Das wrote:
[...]
>> You're expressing this in generic terms, can you please provide the
>> concrete example of what this would look for in the Glymur GCC case?
>>
>
> Yes, Bjorn, this is indeed a general requirement for a clock controller.
>
> In Glymur I do see that CX could drop to retention corner in case there
> is no vote from any subsystem and so it is better to vote from clock
> controller a level above retention using the required-opps.
>
Is this still a valid concern in light of
Commit 7178817f1904 ("pmdomain: qcom: rpmhpd: Skip retention by default")
?
Konrad
^ permalink raw reply
* Re: [RFC PATCH 9/9] arm64: dts: rockchip: rk3576-rock-4d: enable NPU
From: sashiko-bot @ 2026-07-17 9:32 UTC (permalink / raw)
To: Jiaxing Hu; +Cc: devicetree, robh, conor+dt, dri-devel
In-Reply-To: <20260717085220.3212274-10-gahing@gahingwoo.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unconditional call to `devm_pm_domain_attach_list()` breaks probe on single power-domain platforms (e.g., RK3588).
- [Medium] Devicetree binding schema violation: `power-domains` has multiple items.
--
--- Patch [9]: [RFC PATCH 9/9] arm64: dts: rockchip: rk3576-rock-4d: enable NPU ---
commit b202e27a2b4bfe1725b5bf2c08f62041f816c518
Author: Jiaxing Hu <gahing@gahingwoo.com>
arm64: dts: rockchip: rk3576-rock-4d: enable NPU
This commit enables rknn_core_0 and rknn_mmu_0 on the Radxa ROCK 4D. It
supplies the NPU rail and configures the power domains.
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
> index 272af1012ab03..09d2fc98bb4c1 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
[ ... ]
> +&rknn_core_0 {
> + npu-supply = <&vdd_npu_s0>;
> + /*
> + * Power BOTH NPU domains (NPU0 + NPU1) like the vendor's single NPU node,
> + * even though rocket computes only on core 0: the CBUF->CMAC read path is
> + * only fully powered with NPU1 up. rocket attaches the multi-PD list.
> + */
> + power-domains = <&power RK3576_PD_NPU0>, <&power RK3576_PD_NPU1>;
[Severity: High]
Does the driver's handling of the multi-PD list break probe on single-PD
platforms like RK3588?
The comment here notes that rocket attaches the multi-PD list. When a device
has exactly one power-domains entry, the driver core automatically populates
dev->pm_domain before rocket_core_init() runs.
If the driver unconditionally calls devm_pm_domain_attach_list():
drivers/accel/rocket/rocket_core.c:rocket_core_init() {
...
err = devm_pm_domain_attach_list(dev, NULL, &pd_list);
if (err < 0)
return dev_err_probe(dev, err,
"failed to attach NPU power domains\n");
...
}
In this scenario, devm_pm_domain_attach_list() returns -EEXIST because
dev->pm_domain is already set. Since -EEXIST is less than 0, won't this abort
the probe via dev_err_probe(), fatally failing initialization for platforms
with only one power domain?
[Severity: Medium]
Will this multiple power domain configuration cause dtbs_check validation
errors?
The schema currently restricts the power-domains property to a single item:
Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml:
power-domains:
maxItems: 1
Since this adds both RK3576_PD_NPU0 and RK3576_PD_NPU1, could the schema
be updated to support maxItems: 2 before adding this configuration to avoid
build-time tooling errors?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717085220.3212274-1-gahing@gahingwoo.com?part=9
^ 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