On Fri, Sep 05, 2025 at 10:47:42AM +0530, Krishna Chaitanya Chundru wrote:
> On 9/4/2025 1:42 AM, Bjorn Helgaas wrote:
> > On Thu, Aug 28, 2025 at 01:04:26PM +0530, Krishna Chaitanya Chundru wrote:
> > > The ELBI registers falls after the DBI space, PARF_SLV_DBI_ELBI register
> > > gives us the offset from which ELBI starts. So override ELBI with the
> > > offset from PARF_SLV_DBI_ELBI and cfg win to map these regions.
> > >
> > > On root bus, we have only the root port. Any access other than that
> > > should not go out of the link and should return all F's. Since the iATU
> > > is configured for the buses which starts after root bus, block the
> > > transactions starting from function 1 of the root bus to the end of
> > > the root bus (i.e from dbi_base + 4kb to dbi_base + 1MB) from going
> > > outside the link through ECAM blocker through PARF registers.
> > > @@ -1322,6 +1383,15 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
> > > if (ret)
> > > return ret;
> > > + if (pp->ecam_enabled) {
> > > + /*
> > > + * Override ELBI when ECAM is enabled, as when ECAM
> > > + * is enabled ELBI moves along with the dbi config space.
> > > + */
> > > + offset = FIELD_GET(SLV_DBI_ELBI_ADDR_BASE, readl(pcie->parf + PARF_SLV_DBI_ELBI));
> > > + pci->elbi_base = pci->dbi_base + offset;
> >
> > This looks like there might be a bisection hole between this patch and
> > the previous patch that enables ECAM in the DWC core? Obviously I
> > would want to avoid a bisection hole.
> >
> > What happens to qcom ELBI accesses between these two patches? It
> > looks like they would go to the wrong address until this elbi_base
> > update.
> > Is this connection between DBI and ELBI specific to qcom, or might
> > other users of ELBI (only exynos, I guess) need a similar update to
> > elbi_base?
> >
> This is specific to QCOM only, with the commit 10ba0854c5e61 ("PCI:
> qcom: Disable mirroring of DBI and iATU register space in BAR region")
> The DBI address can moved to upper region of the PCIe region. When DBI
> is moved ELBI also moves along with it. So if this patch is not present
> elbi will not point to correct ELBI address.
So I think you're saying this [5/5] patch should be squashed into the
[4/5] patch that changes the way pci->dbi_base is computed?
After [4/5], pcie-qcom.c still uses pci->elbi_base, but apparently the
value is wrong until this update in [5/5]?
Bjorn
