mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Shawn Lin <shawn.lin@rock-chips.com>
To: Hans Zhang <18255117159@163.com>,
	bhelgaas@google.com, lpieralisi@kernel.org,
	kwilczynski@kernel.org, mani@kernel.org, jingoohan1@gmail.com
Cc: shawn.lin@rock-chips.com, imx@lists.linux.dev,
	linuxppc-dev@lists.ozlabs.org, linux-amlogic@lists.infradead.org,
	linux-rockchip@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, sophgo@lists.linux.dev,
	linux-riscv@lists.infradead.org, spacemit@lists.linux.dev,
	linux-tegra@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 01/16] PCI: dwc: Add pcie_cap field and caching helper
Date: Tue, 27 Oct 2026 21:12:57 +0800	[thread overview]
Message-ID: <80f85ae9-7162-4940-8dec-690bc00098b4@rock-chips.com> (raw)
In-Reply-To: <20261027122827.2725643-2-18255117159@163.com>

Hi Hans,

在 2026/10/27 星期二 20:28, Hans Zhang 写道:
> The DWC PCIe core and its platform drivers repeatedly call
> dw_pcie_find_capability(pci, PCI_CAP_ID_EXP) to obtain the offset of the
> PCI Express Capability structure. Besides being verbose, that performs a
> DBI read every time, including in paths that run repeatedly such as link
> up polling, suspend/resume and interrupt handlers.
> 
> Add a pcie_cap field to struct dw_pcie and a helper
> dw_pcie_get_pcie_cap() that performs the lookup on first use and caches
> the result for the subsequent calls.
> 
> The lookup is deliberately done lazily, at the first place that needs the
> offset, instead of at a fixed point during controller initialization.
> This guarantees that the DBI read happens exactly when the open coded
> dw_pcie_find_capability() call it replaces used to happen, so no DBI
> access can be made before the controller clocks, resets and power are


With the controller inaccessible (clocks/power gated), what a DBI
read returns is platform dependent, most integrations just hang the
accessing CPU, like Rockchip's SoCs, others might return zero or
garbage. Zero self-heals as the commit message describes, but a garbage 
non-zero lookup would now be cached indefinitely, so every later caller
would use a bogus offset?

Perhaps the "TX Interface Progression Detection Features" of dwc IP
could help return a dedicated value? I don't know, so I need to check
it internally. I will get back to you later.


> enabled. This matters for endpoint controllers such as qcom-ep and
> tegra194, where DBI is only accessible after PERST# is deasserted, and it
> also means platform drivers do not have to call the helper from a
> specific callback at the right time.
> 
> The cached value is accessed with READ_ONCE()/WRITE_ONCE(), because the
> first lookup may be triggered from different contexts, for example the
> qcom-ep global IRQ and PERST# IRQ handlers. A concurrent lookup stores
> the same value, so this race is benign.
> 
> A return value of 0 means that the capability is not present. This
> cannot happen on real DWC hardware, where the PCI Express Capability is
> mandatory, so a negative result is not cached separately: it only causes
> the search to be repeated, which does not affect correctness.
> 
> Signed-off-by: Hans Zhang <18255117159@163.com>
> ---
>   drivers/pci/controller/dwc/pcie-designware.h | 34 ++++++++++++++++++++
>   1 file changed, 34 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> index 0735ae940924..fa31e8b763bc 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -592,6 +592,8 @@ struct dw_pcie {
>   	 * use_parent_dt_ranges to true to avoid this warning.
>   	 */
>   	bool			use_parent_dt_ranges;
> +
> +	u8			pcie_cap;	/* Offset of PCI_CAP_ID_EXP */
>   };
>   
>   #define to_dw_pcie_from_pp(port) container_of((port), struct dw_pcie, pp)
> @@ -830,6 +832,38 @@ static inline void dw_pcie_dbi_ro_wr_dis(struct dw_pcie *pci)
>   	dw_pcie_writel_dbi(pci, reg, val);
>   }
>   
> +/**
> + * dw_pcie_get_pcie_cap() - Return the PCIe Capability offset
> + * @pci: DWC instance
> + *
> + * The offset of the PCI Express Capability structure is read once from
> + * the DBI configuration space on the first call and cached in
> + * @pci->pcie_cap for the subsequent ones.
> + *
> + * The lookup is done lazily at the first place that actually needs the
> + * offset, so the DBI read happens exactly when it used to happen before
> + * caching was introduced, i.e. never before the controller's clocks,
> + * resets and power are enabled.
> + *
> + * DWC PCIe controllers always implement the PCI Express Capability, so a
> + * return value of 0 means that the hardware is not usable. Callers that
> + * check the returned offset keep working, and the (never expected)
> + * lookup is simply repeated on the next call.
> + *
> + * Return: the cached offset, or 0 if the capability is not present.
> + */
> +static inline u8 dw_pcie_get_pcie_cap(struct dw_pcie *pci)
> +{
> +	u8 cap = READ_ONCE(pci->pcie_cap);
> +
> +	if (!cap) {
> +		cap = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> +		WRITE_ONCE(pci->pcie_cap, cap);
> +	}
> +
> +	return cap;
> +}
> +
>   static inline int dw_pcie_start_link(struct dw_pcie *pci)
>   {
>   	if (pci->ops && pci->ops->start_link)


  reply	other threads:[~2026-10-27 13:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 12:28 [PATCH v4 00/16] PCI: dwc: Cache PCIe capability offset Hans Zhang
2026-10-27 12:28 ` [PATCH v4 01/16] PCI: dwc: Add pcie_cap field and caching helper Hans Zhang
2026-10-27 13:12   ` Shawn Lin [this message]
2026-10-28  3:04     ` Hans Zhang
2026-10-27 12:28 ` [PATCH v4 02/16] PCI: dwc: Use cached PCIe capability offset in core Hans Zhang
2026-10-27 12:28 ` [PATCH v4 03/16] PCI: dwc: imx6: Use cached PCIe capability offset Hans Zhang
2026-10-27 12:28 ` [PATCH v4 04/16] PCI: dwc: layerscape-ep: " Hans Zhang
2026-10-27 12:28 ` [PATCH v4 05/16] PCI: dwc: meson: " Hans Zhang
2026-10-27 12:28 ` [PATCH v4 06/16] PCI: dwc: rockchip: " Hans Zhang
2026-10-27 12:36   ` Shawn Lin
2026-10-27 12:28 ` [PATCH v4 07/16] PCI: dwc: eswin: " Hans Zhang
2026-10-27 12:28 ` [PATCH v4 08/16] PCI: dwc: fu740: " Hans Zhang
2026-10-27 12:28 ` [PATCH v4 09/16] PCI: dwc: intel-gw: " Hans Zhang
2026-10-27 12:28 ` [PATCH v4 10/16] PCI: dwc: qcom-ep: " Hans Zhang
2026-10-27 12:28 ` [PATCH v4 11/16] PCI: dwc: qcom: " Hans Zhang
2026-10-27 12:28 ` [PATCH v4 12/16] PCI: dwc: sophgo: " Hans Zhang
2026-10-27 12:28 ` [PATCH v4 13/16] PCI: dwc: spacemit-k1: " Hans Zhang
2026-10-27 12:28 ` [PATCH v4 14/16] PCI: dwc: spear13xx: " Hans Zhang
2026-10-27 12:28 ` [PATCH v4 15/16] PCI: dwc: tegra194: " Hans Zhang
2026-10-27 12:28 ` [PATCH v4 16/16] PCI: dwc: ultrarisc: " Hans Zhang
2026-10-27 23:15 ` [PATCH v4 00/16] PCI: dwc: Cache " Bjorn Helgaas
2026-10-28  2:10   ` Hans Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=80f85ae9-7162-4940-8dec-690bc00098b4@rock-chips.com \
    --to=shawn.lin@rock-chips.com \
    --cc=18255117159@163.com \
    --cc=bhelgaas@google.com \
    --cc=imx@lists.linux.dev \
    --cc=jingoohan1@gmail.com \
    --cc=kwilczynski@kernel.org \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=sophgo@lists.linux.dev \
    --cc=spacemit@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®