On Fri, Sep 26, 2025 at 03:24:31PM -0500, Bjorn Helgaas wrote:

On Fri, Sep 26, 2025 at 03:23:43AM +0000, Hongxing Zhu wrote:

quoted

quoted

-----Original Message-----
From: Bjorn Helgaas <helgaas@kernel.org>

quoted

quoted

On Fri, Sep 26, 2025 at 02:19:37AM +0000, Hongxing Zhu wrote:

quoted

quoted

-----Original Message-----
From: Bjorn Helgaas <helgaas@kernel.org> On Tue, Sep 23, 2025 at
03:39:13PM +0800, Richard Zhu wrote:

quoted

The CLKREQ# is an open drain, active low signal that is driven low
by the card to request reference clock. It's an optional signal
added in PCIe CEM r4.0, sec 2. Thus, this signal wouldn't be
driven low if it's reserved.

Since the reference clock controlled by CLKREQ# may be required by
i.MX PCIe host too. To make sure this clock is ready even when the
CLKREQ# isn't driven low by the card(e.x the scenario described
above), force CLKREQ# override active low for i.MX PCIe host
during initialization.

The CLKREQ# override can be cleared safely when supports-clkreq is
present and PCIe link is up later. Because the CLKREQ# would be
driven low by the card at this time.

What happens if we clear the CLKREQ# override (so the host doesn't
assert it), and the link is up but the card never asserts CLKREQ#
(since it's an optional signal)?

Does the i.MX host still work?

The CLKREQ# override active low only be cleared when link is up
and supports-clkreq is present. In the other words, there is a
remote endpoint  device, and the CLKREQ# would be driven active
low by this endpoint device.

Assume an endpoint designed to CEM r2.0.  CLKREQ# doesn't exist in
CEM r2.0, so even if the endpoint is present and the link is up,
the endpoint will not assert CLKREQ#.

Will the i.MX host still work?

IIUC, CLKREQ# is required for ASPM L1 PM Substates.  Maybe the
CLKREQ# override should only be cleared if the endpoint advertises
L1 PM Substates support?

CLKREQ# override active low only be cleared when the endpoint
advertises that it has L1 PM Substates support or it always drives
CLKREQ# low.

What?  That's not what the patch does.  It calls .clr_clkreq_override()
whenever the link is up and devicetree contains 'support-clkreq'.

A device advertises L1 PM Substates support by putting the L1 PM
Substates Capability in its config space.

Regardless L1SS state, EP will pull down CLKREQ# by spec requirement.
'support-clkreq' indicate board design connect this signal, so host needn't
force it to low.

Additional support-clkreq require use open drain to connect both EP and RC's
CLKREQ#, some old board design use OR gate, which should not claim
support-clkreq.

The key point if CLKREQ# is connected. If clkreq# connected between EP
and RC, we can release override.

Frank

quoted

quoted

quoted

quoted

quoted

static void imx_pcie_host_post_init(struct dw_pcie_rp *pp)
 		dw_pcie_writel_dbi(pci, GEN3_RELATED_OFF, val);
 		dw_pcie_dbi_ro_wr_dis(pci);
 	}
+
+	/* Clear CLKREQ# override if supports_clkreq is true and link is up */
+	if (dw_pcie_link_up(pci) && imx_pcie->supports_clkreq) {
+		if (imx_pcie->drvdata->clr_clkreq_override)
+			imx_pcie->drvdata->clr_clkreq_override(imx_pcie);
+	}