Hi Alex,
On 07:15 Thu 14 Aug , Alex Elder wrote:
> On 8/13/25 6:42 PM, Inochi Amaoto wrote:
> > On Wed, Aug 13, 2025 at 01:46:58PM -0500, Alex Elder wrote:
> >> 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 <panjunzhong@xxxxxxxxxxxxxxxxxx>
> >> Signed-off-by: Alex Elder <elder@xxxxxxxxxxxx>
> >> ---
> >> 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
>
> . . .
>
> >> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> >> index c670a8dac4680..20f0078e543c7 100644
> >> --- a/drivers/phy/Makefile
> >> +++ b/drivers/phy/Makefile
>
> . . .
>
> >> +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@xxxxxxxxxxxxxxxxxx/
>
> -Alex
>
> > Regards,
> > Inochi
>
--
Yixun Lan (dlan)
