Re: [PATCH v5 6/6] PCI: spacemit-k1: Add Spacemit K3 PCIe host controller support

On Wed, Sep 09, 2026 at 03:51:02PM +0800, Inochi Amaoto wrote:

[...]

quoted

quoted

+static int k3_pcie_parse_port(struct k1_pcie *k1)
+{
+	u32 status0, status1, status2;
+
+	/* This register require a RAW for cleanup */
+	status0 = readl_relaxed(k1->link + K3_PHY_AHB_IRQSTATUS_INTX);
+	status1 = readl_relaxed(k1->link + INTR_STATUS);
+	status2 = readl_relaxed(k1->link + K3_ADDR_INTR_STATUS1);
+
+	writel_relaxed(status0, k1->link + K3_PHY_AHB_IRQSTATUS_INTX);
+	writel_relaxed(status1, k1->link + INTR_STATUS);
+	writel_relaxed(status2, k1->link + K3_ADDR_INTR_STATUS1);
+
+	return k1_pcie_parse_port(k1);
+}
+

Are these status registers accessible before the controller clocks are enabled
and resets released? k3_pcie_parse_port() runs before dw_pcie_host_init(), which
calls k3_pcie_init() to enable those resources.

Yes they can. It is something interesting.

quoted

The SDK uses the same ordering, but I am not sure whether it relies on firmware
leaving the registers accessible. If so, would it be safer to move this clearing
into k3_pcie_init(), after enabling the resources?

In fact, I have no idea about which clock control this MMIO area, if it is dbi
clock (but I guest it is not), it is kind of weird for this clear and should
move to the init. Do you have some knowledge on this?

I checked with our hardware team. PMU AP and PCIECFG share a system clock
derived from PLL1 /8 or /6.

This clock is already available during early boot, before PCIe controller
initialization. The register accesses in k3_pcie_parse_port() therefore
do not need to wait for k3_pcie_init(). That resolves my concern about
the ordering.

                                            - Troy