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

[Troy Mitchell]

On Wed, Sep 09, 2026 at 03:51:02PM +0800, Inochi Amaoto wrote:
> [...]
>
> > > +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.
>
> > 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

Attachment: signature.asc
Description: PGP signature