Re: [PATCH 4/6] phy: spacemit: introduce PCIe/combo PHY

Hi Alex,

On 07:15 Thu 14 Aug     , Alex Elder wrote:

On 8/13/25 6:42 PM, Inochi Amaoto wrote:

quoted

On Wed, Aug 13, 2025 at 01:46:58PM -0500, Alex Elder wrote:

quoted

Introduce a driver that supports three PHYs found on the SpacemiT
K1 SoC.  The first PHY is a combo PHY that can be configured for
use for either USB 3 or PCIe.  The other two PHYs support PCIe
only.

All three PHYs must be programmed with an 8 bit receiver termination
value, which must be determined dynamically; only the combo PHY is
able to determine this value.  The combo PHY performs a special
calibration step at probe time to discover this, and that value is
used to program each PHY that operates in PCIe mode.  The combo
PHY must therefore be probed--first--if either of the PCIe-only
PHYs will be used.

During normal operation, the USB or PCIe driver using the PHY must
ensure clocks and resets are set up properly.  However clocks are
enabled and resets are de-asserted temporarily by this driver to
perform the calibration step on the combo PHY.

Tested-by: Junzhong Pan <redacted>
Signed-off-by: Alex Elder <redacted>
---
  drivers/phy/Kconfig                |  11 +
  drivers/phy/Makefile               |   1 +
  drivers/phy/phy-spacemit-k1-pcie.c | 639 +++++++++++++++++++++++++++++
  3 files changed, 651 insertions(+)
  create mode 100644 drivers/phy/phy-spacemit-k1-pcie.c

. . .

quoted

quoted

diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index c670a8dac4680..20f0078e543c7 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile

. . .

quoted

quoted

+static int k1_pcie_pll_lock(struct k1_pcie_phy *k1_phy, bool pcie)
+{
+	u32 val = pcie ? CFG_FORCE_RCV_RETRY : 0;
+	void __iomem *virt;
+
+	writel(val, k1_phy->regs + PCIE_RC_DONE_STATUS);
+
+	/*
+	 * Wait for indication the PHY PLL is locked.  Lanes for ports
+	 * B and C share a PLL, so it's enough to sample just lane 0.
+	 */
+	virt = k1_phy->regs + PCIE_PU_ADDR_CLK_CFG;	/* Lane 0 */
+
+	return readl_poll_timeout(virt, val, val & PLL_READY,
+				  POLL_DELAY, PLL_TIMEOUT);
+}
+

Can we use standard clk_ops and clk_mux to normalize this process?

I understand you're suggesting that we represent this as a clock.

Can you be more specific about how you suggest I do that?

For example, are you suggesting I create a separate clock driver
for this one PLL (in each PCIe register space)?

Or do you mean use clock structures and callbacks within this
driver to represent this?

I'm just not sure what you have in mind, and the two options I
mention seem a lot more complicated than this one function.

Thanks.

you can take a look at k1's i2c patch that Troy just sent which has similar case

https://lore.kernel.org/all/20250814-k1-i2c-ilcr-v3-1-317723e74bcd@linux.spacemit.com/ (local)

					-Alex

quoted

Regards,
Inochi

-- 
Yixun Lan (dlan)