[PATCH 0/4] Add support for ExynosAutov920 PCIe PHY

[PATCH 0/4] Add support for ExynosAutov920 PCIe PHY

[Sanghoon Bae]

The ExynosAutov920 SoC has two instances of DesignWare-based PCIe PHY IP.
Each PHY has a different lane specification: one is a 4-lane PHY and
the other is a 2-lane PHY.

Each PHY can be used by separate controllers through the bifurcation
option. Therefore, from 2 up to 4 PCIe controllers can be supported
and connected with this PHY driver.

Most of the PHY structure and registers are identical, but some aspects
need to be distinguished. For this, PCIe lane number added for each PHY
properties only in ExynosAutov920.

This patchset includes:
- DT bindings for ExynosAutov920 FSYS0 sysreg
- DT bindings for ExynosAutov920 PCIe PHY
- PCIe PHY properties for ExynosAutov920 in the device tree
- PHY driver for ExynosAutov920 PCIe

Note that this patchset does not enable PCIe0 and PCIe2.
Enabling them requires additional patches for the ExynosAutov920 PCIe
RC driver, which will be applied later.

Please note that these patch set depends on the Shradha Todi's patchset
https://lore.kernel.org/lkml/20250811154638.95732-1-shradha.t@samsung.com/
so need to apply on top of that series, because that adds
the patches to make Exynos PHY common for all.

Sanghoon Bae (4):
  dt-bindings: soc: samsung: exynos-sysreg: add hsi0 for ExynosAutov920
  dt-bindings: phy: Add PCIe PHY support for ExynosAutov920 SoC
  arm64: dts: ExynosAutov920: add PCIe PHY DT nodes
  phy: exynos: Add PCIe PHY support for ExynosAutov920 SoC

 .../bindings/phy/samsung,exynos-pcie-phy.yaml |  14 ++
 .../soc/samsung/samsung,exynos-sysreg.yaml    |   1 +
 .../arm64/boot/dts/exynos/exynosautov920.dtsi |  28 +++
 drivers/phy/samsung/phy-exynos-pcie.c         | 231 ++++++++++++++++++
 4 files changed, 274 insertions(+)

-- 
2.45.2

[PATCH 1/4] dt-bindings: soc: samsung: exynos-sysreg: add hsi0 for ExynosAutov920

[Sanghoon Bae]

Add hsi0 compatible for ExynosAutov920 PCIe settings for:
- PCIe PHY power control
- PLL settings for PCIe
- PCIe device direction (RC/EP)

Signed-off-by: Sanghoon Bae <sh86.bae@samsung.com>
---
 .../devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml   | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
index d27ed6c9d61e..a44fd24ed0ea 100644
--- a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
@@ -30,6 +30,7 @@ properties:
               - samsung,exynos8895-fsys1-sysreg
               - samsung,exynos8895-peric0-sysreg
               - samsung,exynos8895-peric1-sysreg
+              - samsung,exynosautov920-hsi0-sysreg
               - samsung,exynosautov920-peric0-sysreg
               - samsung,exynosautov920-peric1-sysreg
               - tesla,fsd-cam-sysreg
-- 
2.45.2

[PATCH 2/4] dt-bindings: phy: Add PCIe PHY support for ExynosAutov920 SoC

[Sanghoon Bae]

Since the Exynosautov920 SoC uses the Samsung PCIe PHY, add support
for it in the Exynosautov920 PCIe PHY bindings.

The Exynosautov920 SoC includes two PHY instances: one for a 4-lane PHY
and another for a 2-lane PHY. Each PHY can be used by separate
controllers through the bifurcation option. Therefore, from 2 up to 4
PCIe controllers can be supported and connected with this PHY driver.

PCIe lane number is used to distinguish each PHY instance.
This is required since two PHY instances on ExynosAutov920 is not
identical.
On PHY driver code, need to check each instance and different settings.

Signed-off-by: Sanghoon Bae <sh86.bae@samsung.com>
---
 .../bindings/phy/samsung,exynos-pcie-phy.yaml      | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
index 6295472696db..1e8b88d2cd56 100644
--- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
@@ -19,6 +19,7 @@ properties:
       - samsung,exynos5433-pcie-phy
       - tesla,fsd-pcie-phy0
       - tesla,fsd-pcie-phy1
+      - samsung,exynosautov920-pcie-phy
 
   reg:
     minItems: 1
@@ -34,6 +35,10 @@ properties:
     description: phandle for FSYS sysreg interface, used to control
                  sysreg registers bits for PCIe PHY
 
+  num-lanes:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    enum: [2, 4]
+
 allOf:
   - if:
       properties:
@@ -42,6 +47,7 @@ allOf:
             enum:
               - tesla,fsd-pcie-phy0
               - tesla,fsd-pcie-phy1
+              - samsung,exynosautov920-pcie-phy
     then:
       properties:
         reg:
@@ -52,6 +58,14 @@ allOf:
       properties:
         reg:
           maxItems: 1
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: samsung,exynosautov920-pcie-phy
+    then:
+      required:
+        - num-lanes
 
 required:
   - "#phy-cells"
-- 
2.45.2

[PATCH 3/4] arm64: dts: ExynosAutov920: add PCIe PHY DT nodes

[Sanghoon Bae]

Add pcie_4l_phy, pcie_2l_phy dt node for all PCIe PHY instances
in ExynosAutov920 SoC.

Add HSI sysreg to control PCIe sysreg registers.

Signed-off-by: Sanghoon Bae <sh86.bae@samsung.com>
---
 .../arm64/boot/dts/exynos/exynosautov920.dtsi | 28 +++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynosautov920.dtsi b/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
index 2cb8041c8a9f..9e45bfcd7980 100644
--- a/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
@@ -1021,12 +1021,40 @@ cmu_hsi0: clock-controller@16000000 {
 				      "noc";
 		};
 
+		syscon_hsi0: syscon@16030000 {
+			compatible = "samsung,exynosautov920-hsi0-sysreg",
+				     "syscon";
+			reg = <0x16030000 0x1000>;
+		};
+
 		pinctrl_hsi0: pinctrl@16040000 {
 			compatible = "samsung,exynosautov920-pinctrl";
 			reg = <0x16040000 0x10000>;
 			interrupts = <GIC_SPI 442 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
+		pcie_2l_phy: pcie-phy2l@161c6000{
+			compatible = "samsung,exynosautov920-pcie-phy";
+			reg = <0x161c6000 0x2000>,
+			      <0x161d0000 0xb000>;
+			#phy-cells = <0>;
+			samsung,pmu-syscon = <&pmu_system_controller>;
+			samsung,fsys-sysreg = <&syscon_hsi0>;
+			num-lanes = <2>;
+			status = "disabled";
+		};
+
+		pcie_4l_phy: pcie-phy4l@163c6000{
+			compatible = "samsung,exynosautov920-pcie-phy";
+			reg = <0x163c6000 0x2000>,
+			      <0x163d0000 0xb000>;
+			#phy-cells = <0>;
+			samsung,pmu-syscon = <&pmu_system_controller>;
+			samsung,fsys-sysreg = <&syscon_hsi0>;
+			num-lanes = <4>;
+			status = "disabled";
+		};
+
 		cmu_hsi1: clock-controller@16400000 {
 			compatible = "samsung,exynosautov920-cmu-hsi1";
 			reg = <0x16400000 0x8000>;
-- 
2.45.2

[PATCH 4/4] phy: exynos: Add PCIe PHY support for ExynosAutov920 SoC

[Sanghoon Bae]

Add PCIe PHY support for ExynosAutov920 SoC

Signed-off-by: Sanghoon Bae <sh86.bae@samsung.com>
---
 drivers/phy/samsung/phy-exynos-pcie.c | 231 ++++++++++++++++++++++++++
 1 file changed, 231 insertions(+)

diff --git a/drivers/phy/samsung/phy-exynos-pcie.c b/drivers/phy/samsung/phy-exynos-pcie.c
index 5a55a22f9661..5b9d65f8f6c7 100644
--- a/drivers/phy/samsung/phy-exynos-pcie.c
+++ b/drivers/phy/samsung/phy-exynos-pcie.c
@@ -129,14 +129,87 @@
 #define FSD_PCIE_SYSREG_PHY_1_CMN_RSTN			BIT(1)
 #define FSD_PCIE_SYSREG_PHY_1_INIT_RSTN			BIT(3)
 
+/* Exynosautov920 register offsets and bits */
+/* EA920: PHY registers */
+#define EA920_PCIE_PHY0_COMMON_CTRL			0x1000
+#define EA920_PCIE_PHY_RTUNE_REQ			0x10000001
+#define EA920_PCIE_PHY0_GEN_CTRL_1			0x1010
+#define EA920_PCIE_PHY0_REFA_CLK_SEL_MASK		GENMASK(17, 16)
+#define EA920_PCIE_PHY0_REFB_CLK_SEL_MASK		GENMASK(19, 18)
+#define EA920_PCIE_PHY0_PHY0_SRAM_BYPASS		BIT(10)
+#define EA920_PCIE_PHY0_PHY0_SRAM_EXT_LD_DONE		BIT(11)
+#define EA920_PCIE_PHY0_REFA_B_ALT1			0x061a0060
+#define EA920_PCIE_PHY0_REFA_B_ALT0			0x06100060
+#define EA920_PCIE_PHY0_REFA_B_PAD			0x06150060
+#define EA920_PCIE_PHY0_SRAM_INIT_DONE			31
+#define EA920_PCIE_PHY_EXT_TX_ROPLL_POSTDIV_CTRL	0x11a8
+#define EA920_PCIE_PHY_ROPLL_POSTDIV_VAL		0x1249
+#define EA920_PCIE_PHY_EXT_TX_OVRD_EN_CTRL		0x11c4
+#define EA920_PCIE_PHY_ROPLL_POSTDIV_OVRD_EN_VAL	(0xf << 0)
+#define EA920_PCIE_PIPE_LANEX_LANEPLL_BYPASS		0x1384
+#define EA920_PCIE_PIPE_BYPASS_MODE_CTRL_VAL1		0x0
+#define EA920_PCIE_PIPE_BYPASS_MODE_CTRL_VAL2		0x0
+/* EA920: SOC CTRL registers */
+#define EA920_PCIE_REFCLK_CTRL_SOC_OPTION_0		0xa200
+#define EA920_PCIE_REFCLK_OPTION0_RC			0x103f5
+#define EA920_PCIE_REFCLK_CTRL_SOC_OPTION_1		0xa204
+#define EA920_PCIE_REFCLK_OPTION1_RC			0x30c00
+/* EA920: PMU registers */
+#define EA920_PCIE_PHY_4L_CONFIGURATION			0x700
+#define EA920_PCIE_PHY_2L_CONFIGURATION			0x704
+#define EA920_PCIE_PHY_CFG_EN_PHY			(0x1 << 0)
+/* EA920: GEN SYS registers */
+#define EA920_GENERAL_SS_RST_CTRL_1			0x48
+#define EA920_GENERAL_RST_PE0_SOFT_WARM_PHY_RESET	GENMASK(2, 1)
+#define EA920_GENERAL_RST_PE1_SOFT_COLD_RESET		(0x1 << 8)
+#define EA920_GENERAL_RST_PE1_SOFT_WARM_PHY_RESET	(0x3 << 9)
+#define EA920_GENERAL_RST_PE0_SOFT_WARM_RESET		(0x1 << 1)
+#define EA920_GENERAL_RST_PE1_SOFT_WARM_RESET		(0x1 << 9)
+#define EA920_GENERAL_RST_PE0_1_PHY_EN			0x808
+#define EA920_PHY_TIMEOUT				2000
+/* EA920: SYSREG registers */
+#define EA920_HSI0_PCIE_GEN5_PHY_PWRDWN_4L		0x670
+#define EA920_HSI0_PCIE_GEN5_PHY_PWRDWN_2L		0x4
+#define EA920_HSI0_PCIE_PHY_TEST_PWRDWN_MSK		BIT(0)
+#define EA920_HSI0_PCIE_PHY_TEST_PWRDUP			0x0
+#define EA920_HSI0_PCIE_PHY_TEST_PWRDWN			0x1
+#define EA920_HSI0_PCIE_GEN5_4LA_PHY_CTRL		0x828
+#define EA920_HSI0_PCIE_GEN5_2LA_PHY_CTRL		0x868
+#define EA920_HSI0_PCIE_IP_CTRL_DEV_TYPE_MSK		GENMASK(27, 24)
+#define EA920_HSI0_PCIE_IP_CTRL_DEV_TYPE_RC_A		0x4
+#define EA920_HSI0_PLL_REG0				0x600
+#define EA920_HSI0_PLL_FOUTEN_MSK			BIT(8)
+#define EA920_HSI0_PLL_FOUTEN				0x1
+#define EA920_HSI0_PLL_REG1				0x604
+#define EA920_HSI0_PLL_FOUTPOSTDIVEN_MSK		BIT(0)
+#define EA920_HSI0_PLL_FOUTPOSTDIVEN			0x1
+#define EA920_HSI0_PLL_REG2				0x608
+#define EA920_HSI0_PLL_PLLEN_MSK			BIT(24)
+#define EA920_HSI0_PLL_PLLEN				0x1
+#define EA920_HSI0_CLKBUF0_REG0				0x620
+#define EA920_HSI0_CLKBUF1_REG0				0x630
+#define EA920_HSI0_CLKBUF2_REG0				0x640
+#define EA920_HSI0_CLKBUF3_REG0				0x650
+#define EA920_HSI0_CLKBUF_IMP_CTRL_MSK			BIT(0)
+#define EA920_HSI0_CLKBUF_IMP_CTRL			0x1
+
 /* For Exynos pcie phy */
 struct exynos_pcie_phy {
 	void __iomem *base;
 	void __iomem *pcs_base;
 	struct regmap *pmureg;
 	struct regmap *fsysreg;
+	int num_lanes;
 };
 
+static u32 exynos_pcie_phy_readl(void __iomem *base, u32 offset)
+{
+	u32 data = 0;
+
+	data = readl(base + offset);
+	return data;
+}
+
 static void exynos_pcie_phy_writel(void __iomem *base, u32 val, u32 offset)
 {
 	writel(val, base + offset);
@@ -398,6 +471,152 @@ static int fsd_pcie_phy1_init(struct phy *phy)
 	return 0;
 }
 
+static int exynosautov920_pcie_phy_init(struct phy *phy)
+{
+	struct exynos_pcie_phy *ep = phy_get_drvdata(phy);
+	u32 val;
+	int timeout;
+
+	/* PHY on */
+	if (ep->num_lanes == 4) {
+		regmap_update_bits(ep->pmureg,
+				   EA920_PCIE_PHY_4L_CONFIGURATION,
+				   BIT(0), EA920_PCIE_PHY_CFG_EN_PHY);
+		regmap_update_bits(ep->fsysreg,
+				   EA920_HSI0_PCIE_GEN5_PHY_PWRDWN_4L,
+				   EA920_HSI0_PCIE_PHY_TEST_PWRDWN_MSK,
+				   EA920_HSI0_PCIE_PHY_TEST_PWRDUP);
+
+		/* SYSREG set to RC */
+		regmap_update_bits(ep->fsysreg,
+				   EA920_HSI0_PCIE_GEN5_4LA_PHY_CTRL,
+				   EA920_HSI0_PCIE_IP_CTRL_DEV_TYPE_MSK,
+				   EA920_HSI0_PCIE_IP_CTRL_DEV_TYPE_RC_A);
+	} else if (ep->num_lanes == 2) {
+		/* In 2L phy, 4L phy pmu should isolation off first */
+		regmap_update_bits(ep->pmureg,
+				   EA920_PCIE_PHY_4L_CONFIGURATION,
+				   BIT(0), EA920_PCIE_PHY_CFG_EN_PHY);
+		regmap_update_bits(ep->pmureg,
+				   EA920_PCIE_PHY_2L_CONFIGURATION,
+				   BIT(0), EA920_PCIE_PHY_CFG_EN_PHY);
+		regmap_update_bits(ep->fsysreg,
+				   EA920_HSI0_PCIE_GEN5_PHY_PWRDWN_2L,
+				   EA920_HSI0_PCIE_PHY_TEST_PWRDWN_MSK,
+				   EA920_HSI0_PCIE_PHY_TEST_PWRDUP);
+		/* SYSREG set to RC */
+		regmap_update_bits(ep->fsysreg,
+				   EA920_HSI0_PCIE_GEN5_2LA_PHY_CTRL,
+				   EA920_HSI0_PCIE_IP_CTRL_DEV_TYPE_MSK,
+				   EA920_HSI0_PCIE_IP_CTRL_DEV_TYPE_RC_A);
+	}
+
+	/* SOC control */
+	exynos_pcie_phy_writel(ep->pcs_base, EA920_PCIE_REFCLK_OPTION0_RC,
+			       EA920_PCIE_REFCLK_CTRL_SOC_OPTION_0);
+	exynos_pcie_phy_writel(ep->pcs_base, EA920_PCIE_REFCLK_OPTION1_RC,
+			       EA920_PCIE_REFCLK_CTRL_SOC_OPTION_1);
+
+	/* PLL setting */
+	regmap_update_bits(ep->fsysreg, EA920_HSI0_PLL_REG0,
+			   EA920_HSI0_PLL_FOUTEN_MSK, EA920_HSI0_PLL_FOUTEN);
+	regmap_update_bits(ep->fsysreg, EA920_HSI0_PLL_REG1,
+			   EA920_HSI0_PLL_FOUTPOSTDIVEN_MSK,
+			   EA920_HSI0_PLL_FOUTPOSTDIVEN);
+	regmap_update_bits(ep->fsysreg, EA920_HSI0_PLL_REG2,
+			   EA920_HSI0_PLL_PLLEN_MSK, EA920_HSI0_PLL_PLLEN);
+	regmap_update_bits(ep->fsysreg, EA920_HSI0_CLKBUF0_REG0,
+			   EA920_HSI0_CLKBUF_IMP_CTRL_MSK,
+			   EA920_HSI0_CLKBUF_IMP_CTRL);
+	regmap_update_bits(ep->fsysreg, EA920_HSI0_CLKBUF1_REG0,
+			   EA920_HSI0_CLKBUF_IMP_CTRL_MSK,
+			   EA920_HSI0_CLKBUF_IMP_CTRL);
+	regmap_update_bits(ep->fsysreg, EA920_HSI0_CLKBUF2_REG0,
+			   EA920_HSI0_CLKBUF_IMP_CTRL_MSK,
+			   EA920_HSI0_CLKBUF_IMP_CTRL);
+	regmap_update_bits(ep->fsysreg,	EA920_HSI0_CLKBUF3_REG0,
+			   EA920_HSI0_CLKBUF_IMP_CTRL_MSK,
+			   EA920_HSI0_CLKBUF_IMP_CTRL);
+
+	/* REFCLK setting */
+	val = exynos_pcie_phy_readl(ep->base, EA920_PCIE_PHY0_GEN_CTRL_1);
+	exynos_pcie_phy_writel(ep->base, val &
+			       ~EA920_PCIE_PHY0_REFA_CLK_SEL_MASK,
+			       EA920_PCIE_PHY0_GEN_CTRL_1);
+	exynos_pcie_phy_writel(ep->base,
+			       val & ~EA920_PCIE_PHY0_REFB_CLK_SEL_MASK,
+			       EA920_PCIE_PHY0_GEN_CTRL_1);
+	/* wait for REF CLK source change */
+	usleep_range(100, 110);
+	exynos_pcie_phy_writel(ep->base, EA920_PCIE_PHY_RTUNE_REQ,
+			       EA920_PCIE_PHY0_COMMON_CTRL);
+	exynos_pcie_phy_writel(ep->base, EA920_PCIE_PHY_ROPLL_POSTDIV_VAL,
+			       EA920_PCIE_PHY_EXT_TX_ROPLL_POSTDIV_CTRL);
+	exynos_pcie_phy_writel(ep->base,
+			       EA920_PCIE_PHY_ROPLL_POSTDIV_OVRD_EN_VAL,
+			       EA920_PCIE_PHY_EXT_TX_OVRD_EN_CTRL);
+	exynos_pcie_phy_writel(ep->base, EA920_PCIE_PIPE_BYPASS_MODE_CTRL_VAL1,
+			       EA920_PCIE_PIPE_LANEX_LANEPLL_BYPASS);
+	exynos_pcie_phy_writel(ep->base, EA920_PCIE_PIPE_BYPASS_MODE_CTRL_VAL2,
+			       EA920_PCIE_PIPE_LANEX_LANEPLL_BYPASS);
+	exynos_pcie_phy_writel(ep->base, EA920_PCIE_PHY0_REFA_B_ALT0,
+			       EA920_PCIE_PHY0_GEN_CTRL_1);
+
+	/* PHY warm reset */
+	val = exynos_pcie_phy_readl(ep->base, EA920_GENERAL_SS_RST_CTRL_1);
+	exynos_pcie_phy_writel(ep->base, val |
+			       EA920_GENERAL_RST_PE0_SOFT_WARM_PHY_RESET,
+			       EA920_GENERAL_SS_RST_CTRL_1);
+	usleep_range(10, 12);
+	exynos_pcie_phy_writel(ep->base, val &
+			       ~EA920_GENERAL_RST_PE0_SOFT_WARM_PHY_RESET,
+			       EA920_GENERAL_SS_RST_CTRL_1);
+
+	/* Set SRAM bypass */
+	val = exynos_pcie_phy_readl(ep->base, EA920_PCIE_PHY0_GEN_CTRL_1);
+	exynos_pcie_phy_writel(ep->base, val | EA920_PCIE_PHY0_PHY0_SRAM_BYPASS,
+			       EA920_PCIE_PHY0_GEN_CTRL_1);
+
+	/* Wait SRAM init */
+	timeout = 0;
+	do {
+		udelay(1);
+		timeout++;
+		if (timeout >= EA920_PHY_TIMEOUT)
+			return -ETIME;
+	} while (!(exynos_pcie_phy_readl(ep->base,
+					 EA920_PCIE_PHY0_GEN_CTRL_1) >>
+					 EA920_PCIE_PHY0_SRAM_INIT_DONE));
+
+	timeout = 0;
+	val = exynos_pcie_phy_readl(ep->base, EA920_PCIE_PHY0_GEN_CTRL_1);
+	exynos_pcie_phy_writel(ep->base, val |
+			       EA920_PCIE_PHY0_PHY0_SRAM_EXT_LD_DONE,
+			       EA920_PCIE_PHY0_GEN_CTRL_1);
+	/* wait for PHY init done */
+	mdelay(100);
+
+	return 0;
+}
+
+static int exynosautov920_pcie_phy_exit(struct phy *phy)
+{
+	struct exynos_pcie_phy *ep = phy_get_drvdata(phy);
+
+	if (ep->num_lanes == 4)
+		regmap_update_bits(ep->fsysreg,
+				   EA920_HSI0_PCIE_GEN5_PHY_PWRDWN_4L,
+				   EA920_HSI0_PCIE_PHY_TEST_PWRDWN_MSK,
+				   EA920_HSI0_PCIE_PHY_TEST_PWRDWN);
+	else if (ep->num_lanes == 2)
+		regmap_update_bits(ep->fsysreg,
+				   EA920_HSI0_PCIE_GEN5_PHY_PWRDWN_2L,
+				   EA920_HSI0_PCIE_PHY_TEST_PWRDWN_MSK,
+				   EA920_HSI0_PCIE_PHY_TEST_PWRDWN);
+
+	return 0;
+}
+
 static const struct phy_ops fsd_phy0_ops = {
 	.init		= fsd_pcie_phy0_init,
 	.reset		= fsd_pcie_phy0_reset,
@@ -410,6 +629,12 @@ static const struct phy_ops fsd_phy1_ops = {
 	.owner		= THIS_MODULE,
 };
 
+static const struct phy_ops exynosautov920_phy_ops = {
+	.init		= exynosautov920_pcie_phy_init,
+	.exit		= exynosautov920_pcie_phy_exit,
+	.owner		= THIS_MODULE,
+};
+
 static const struct of_device_id exynos_pcie_phy_match[] = {
 	{
 		.compatible = "samsung,exynos5433-pcie-phy",
@@ -423,6 +648,10 @@ static const struct of_device_id exynos_pcie_phy_match[] = {
 		.compatible = "tesla,fsd-pcie-phy1",
 		.data = &fsd_phy1_ops,
 	},
+	{
+		.compatible = "samsung,exynosautov920-pcie-phy",
+		.data = &exynosautov920_phy_ops,
+	},
 	{},
 };
 
@@ -468,6 +697,8 @@ static int exynos_pcie_phy_probe(struct platform_device *pdev)
 
 	exynos_phy->pcs_base = devm_platform_ioremap_resource(pdev, 1);
 
+	of_property_read_u32(dev->of_node, "num-lanes", &exynos_phy->num_lanes);
+
 	phy_set_drvdata(generic_phy, exynos_phy);
 	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
 
-- 
2.45.2

[PATCH 0/4] Add support for ExynosAutov920 PCIe PHY

[Sanghoon Bae]

The ExynosAutov920 SoC has two instances of DesignWare-based PCIe PHY IP.
Each PHY has a different lane specification: one is a 4-lane PHY and
the other is a 2-lane PHY.

Each PHY can be used by separate controllers through the bifurcation
option. Therefore, from 2 up to 4 PCIe controllers can be supported
and connected with this PHY driver.

Most of the PHY structure and registers are identical, but some aspects
need to be distinguished. For this, PCIe lane number added for each PHY
properties only in ExynosAutov920.

This patchset includes:
- DT bindings for ExynosAutov920 FSYS0 sysreg
- DT bindings for ExynosAutov920 PCIe PHY
- PCIe PHY properties for ExynosAutov920 in the device tree
- PHY driver for ExynosAutov920 PCIe

Note that this patchset does not enable PCIe0 and PCIe2.
Enabling them requires additional patches for the ExynosAutov920 PCIe
RC driver, which will be applied later.

Please note that these patch set depends on the Shradha Todi's patchset
https://lore.kernel.org/lkml/20250811154638.95732-1-shradha.t@samsung.com/
so need to apply on top of that series, because that adds
the patches to make Exynos PHY common for all.

Sanghoon Bae (4):
  dt-bindings: soc: samsung: exynos-sysreg: add hsi0 for ExynosAutov920
  dt-bindings: phy: Add PCIe PHY support for ExynosAutov920 SoC
  arm64: dts: ExynosAutov920: add PCIe PHY DT nodes
  phy: exynos: Add PCIe PHY support for ExynosAutov920 SoC

 .../bindings/phy/samsung,exynos-pcie-phy.yaml |  14 ++
 .../soc/samsung/samsung,exynos-sysreg.yaml    |   1 +
 .../arm64/boot/dts/exynos/exynosautov920.dtsi |  28 +++
 drivers/phy/samsung/phy-exynos-pcie.c         | 231 ++++++++++++++++++
 4 files changed, 274 insertions(+)

-- 
2.45.2

Re: [PATCH 1/4] dt-bindings: soc: samsung: exynos-sysreg: add hsi0 for ExynosAutov920

[Krzysztof Kozlowski]

On 26/09/2025 16:39, Sanghoon Bae wrote:
> Add hsi0 compatible for ExynosAutov920 PCIe settings for:
> - PCIe PHY power control
> - PLL settings for PCIe
> - PCIe device direction (RC/EP)
> 
> Signed-off-by: Sanghoon Bae <sh86.bae@samsung.com>
> ---
>  .../devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml   | 1 +
>  1 file changed, 1 insertion(+)
> 
This is not really related to PCIe or phy patchset, so putting it here
just makes life of maintainers more difficult. There is really no reason
for that.

Don't mix subsystems when not needed. DTS patchset targeting me, should
be separate from other subsystems in such case and it only needs to
mention in changelog or cover letter where are the bindings.

Best regards,
Krzysztof

Re: [PATCH 2/4] dt-bindings: phy: Add PCIe PHY support for ExynosAutov920 SoC

[Krzysztof Kozlowski]

On 26/09/2025 16:39, Sanghoon Bae wrote:
> Since the Exynosautov920 SoC uses the Samsung PCIe PHY, add support
> for it in the Exynosautov920 PCIe PHY bindings.
> 
> The Exynosautov920 SoC includes two PHY instances: one for a 4-lane PHY
> and another for a 2-lane PHY. Each PHY can be used by separate
> controllers through the bifurcation option. Therefore, from 2 up to 4
> PCIe controllers can be supported and connected with this PHY driver.


Describe hardware, not driver.

> 
> PCIe lane number is used to distinguish each PHY instance.
> This is required since two PHY instances on ExynosAutov920 is not
> identical.
> On PHY driver code, need to check each instance and different settings.


Describe hardware, not driver.

> 
> Signed-off-by: Sanghoon Bae <sh86.bae@samsung.com>
> ---
>  .../bindings/phy/samsung,exynos-pcie-phy.yaml      | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> index 6295472696db..1e8b88d2cd56 100644
> --- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> @@ -19,6 +19,7 @@ properties:
>        - samsung,exynos5433-pcie-phy
>        - tesla,fsd-pcie-phy0
>        - tesla,fsd-pcie-phy1
> +      - samsung,exynosautov920-pcie-phy

Messed order.

>  
>    reg:
>      minItems: 1
> @@ -34,6 +35,10 @@ properties:
>      description: phandle for FSYS sysreg interface, used to control
>                   sysreg registers bits for PCIe PHY
>  
> +  num-lanes:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    enum: [2, 4]
> +
>  allOf:
>    - if:
>        properties:
> @@ -42,6 +47,7 @@ allOf:
>              enum:
>                - tesla,fsd-pcie-phy0
>                - tesla,fsd-pcie-phy1
> +              - samsung,exynosautov920-pcie-phy

Messed order.

Best regards,
Krzysztof

Re: [PATCH 3/4] arm64: dts: ExynosAutov920: add PCIe PHY DT nodes

[Krzysztof Kozlowski]

On 26/09/2025 16:39, Sanghoon Bae wrote:
> Add pcie_4l_phy, pcie_2l_phy dt node for all PCIe PHY instances
> in ExynosAutov920 SoC.
> 
> Add HSI sysreg to control PCIe sysreg registers.
> 
> Signed-off-by: Sanghoon Bae <sh86.bae@samsung.com>
> ---
>  .../arm64/boot/dts/exynos/exynosautov920.dtsi | 28 +++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynosautov920.dtsi b/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
> index 2cb8041c8a9f..9e45bfcd7980 100644
> --- a/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
> @@ -1021,12 +1021,40 @@ cmu_hsi0: clock-controller@16000000 {
>  				      "noc";
>  		};
>  
> +		syscon_hsi0: syscon@16030000 {
> +			compatible = "samsung,exynosautov920-hsi0-sysreg",
> +				     "syscon";
> +			reg = <0x16030000 0x1000>;
> +		};
> +
>  		pinctrl_hsi0: pinctrl@16040000 {
>  			compatible = "samsung,exynosautov920-pinctrl";
>  			reg = <0x16040000 0x10000>;
>  			interrupts = <GIC_SPI 442 IRQ_TYPE_LEVEL_HIGH>;
>  		};
>  
> +		pcie_2l_phy: pcie-phy2l@161c6000{



Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
If you cannot find a name matching your device, please check in kernel
sources for similar cases or you can grow the spec (via pull request to
DT spec repo).

Plus style issues... missing space.

I would like to see also PCIe nodes somewhere, because I wonder if
num-lanes should not be moved to PCI node (phy consumer) instead.
Current approach feels better, but maybe it just duplicates num-lanes
from the PCI?

Best regards,
Krzysztof

RE: [PATCH 1/4] dt-bindings: soc: samsung: exynos-sysreg: add hsi0 for ExynosAutov920

[배상훈/Sanghoon Bae]

> > Add hsi0 compatible for ExynosAutov920 PCIe settings for:
> > - PCIe PHY power control
> > - PLL settings for PCIe
> > - PCIe device direction (RC/EP)
> >
> > Signed-off-by: Sanghoon Bae <sh86.bae@samsung.com>
> > ---
> >  .../devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml   | 1 +
> >  1 file changed, 1 insertion(+)
> >
> This is not really related to PCIe or phy patchset, so putting it here
> just makes life of maintainers more difficult. There is really no reason
> for that.
> 
> Don't mix subsystems when not needed. DTS patchset targeting me, should be
> separate from other subsystems in such case and it only needs to mention
> in changelog or cover letter where are the bindings.
Will separate this patch from the patchset

RE: [PATCH 2/4] dt-bindings: phy: Add PCIe PHY support for ExynosAutov920 SoC

[Sanghoon Bae]

> > Since the Exynosautov920 SoC uses the Samsung PCIe PHY, add support
> > for it in the Exynosautov920 PCIe PHY bindings.
> >
> > The Exynosautov920 SoC includes two PHY instances: one for a 4-lane
> > PHY and another for a 2-lane PHY. Each PHY can be used by separate
> > controllers through the bifurcation option. Therefore, from 2 up to 4
> > PCIe controllers can be supported and connected with this PHY driver.
> 
> 
> Describe hardware, not driver.
I will describe about the Exynosautov920 SoC PCIe hardware.

> > PCIe lane number is used to distinguish each PHY instance.
> > This is required since two PHY instances on ExynosAutov920 is not
> > identical.
> > On PHY driver code, need to check each instance and different settings.
> 
> 
> Describe hardware, not driver.
I will describe about the Exynosautov920 SoC PCIe hardware.

> > @@ -19,6 +19,7 @@ properties:
> >        - samsung,exynos5433-pcie-phy
> >        - tesla,fsd-pcie-phy0
> >        - tesla,fsd-pcie-phy1
> > +      - samsung,exynosautov920-pcie-phy
> 
> Messed order.
Will fix the order

> > @@ -42,6 +47,7 @@ allOf:
> >              enum:
> >                - tesla,fsd-pcie-phy0
> >                - tesla,fsd-pcie-phy1
> > +              - samsung,exynosautov920-pcie-phy
> 
> Messed order.
Will fix the order

RE: [PATCH 3/4] arm64: dts: ExynosAutov920: add PCIe PHY DT nodes

[SanghoonBae]

> > +		pcie_2l_phy: pcie-phy2l@161c6000{
> 
> 
> 
> Node names should be generic. See also an explanation and list of examples
> (not exhaustive) in DT specification:
> https://protect2.fireeye.com/v1/url?k=d2bcf1f2-8d273f96-d2bd7abd-
> 000babda0201-1fe7eb4ecd262f65&q=1&e=8522e96d-f1a1-4b6b-baa9-
> 44344340469a&u=https%3A%2F%2Fdevicetree-
> specification.readthedocs.io%2Fen%2Flatest%2Fchapter2-devicetree-
> basics.html%23generic-names-recommendation
> If you cannot find a name matching your device, please check in kernel
> sources for similar cases or you can grow the spec (via pull request to DT
> spec repo).
I will rename the node referring the guideline you linked.

> Plus style issues... missing space.
Will add space before left brace.

> I would like to see also PCIe nodes somewhere, because I wonder if num-
> lanes should not be moved to PCI node (phy consumer) instead.
> Current approach feels better, but maybe it just duplicates num-lanes from
> the PCI?
As mentioned earlier, I plan to enable the PCIe nodes later.
However, I can share my prototype PCIe node that I am currently using for
PCIe driver testing:

pcie_0: pcie@163c0000 {
	compatible = "samsung,exynosautov920-pcie";
	gpios = <&gph0 1 0>;	/* PERST */
	reg = <0x163C0000 0x1000>, <0x12000000 0x20000>,
		<0x2fffd000 0x2000>, <0x12600000 0x2000>;
	reg-names = "elbi", "dbi", "config", "atu";
	#address-cells = <3>;
	#size-cells = <2>;
	#interrupt-cells = <1>;
	device_type = "pci";
	interrupts = <GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>;
	interrupt-map-mask = <0 0 0 0>;
	interrupt-map = <0 0 0 0 &gic GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>;
	clocks = <&xtcxo>;
	clock-names = "ref_clk";
	num-lanes = <1>;
	num-viewport = <3>;
	bus-range = <0x00 0xff>;
	phys = <&pcie_0_phy>;
	samsung,pcie-ch = <0>;
	ranges = <0x82000000 0 0x20000000 0x20000000 0 0x1FFFD000>;
	status = "disabled";
};

As you expected, num-lanes will be defined only in the PCIe node.
Please let me know if this composition of the DT nodes looks appropriate
to you.