public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Christian Bruel <christian.bruel@foss.st.com>
Cc: lpieralisi@kernel.org, kw@linux.com,
	manivannan.sadhasivam@linaro.org, robh@kernel.org,
	bhelgaas@google.com, krzk+dt@kernel.org, conor+dt@kernel.org,
	mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
	p.zabel@pengutronix.de, cassel@kernel.org,
	quic_schintav@quicinc.com, fabrice.gasnier@foss.st.com,
	linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/5] PCI: stm32: Add PCIe endpoint support for STM32MP25
Date: Thu, 5 Dec 2024 11:27:38 -0600	[thread overview]
Message-ID: <20241205172738.GA3054352@bhelgaas> (raw)
In-Reply-To: <20241126155119.1574564-5-christian.bruel@foss.st.com>

On Tue, Nov 26, 2024 at 04:51:18PM +0100, Christian Bruel wrote:
> Add driver to configure the STM32MP25 SoC PCIe Gen2 controller based on the
> DesignWare PCIe core in endpoint mode.

> +config PCIE_STM32_EP
> +	tristate "STMicroelectronics STM32MP25 PCIe Controller (endpoint mode)"
> +	depends on ARCH_STM32 || COMPILE_TEST
> +	depends on PCI_ENDPOINT
> +	select PCIE_DW_EP
> +	help
> +	  Enables endpoint support for DesignWare core based PCIe controller in found
> +	  in STM32MP25 SoC.

s/in found in/in/ (or "found in" if you prefer)

Wrap so help text fits in 80 columns when for "make menuconfig".

> +static void stm32_pcie_ep_init(struct dw_pcie_ep *ep)
> +{
> +	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> +	struct stm32_pcie *stm32_pcie = to_stm32_pcie(pci);
> +	enum pci_barno bar;
> +
> +	for (bar = 0; bar < PCI_STD_NUM_BARS; bar++)
> +		dw_pcie_ep_reset_bar(pci, bar);
> +
> +	/* Defer Completion Requests until link started */

I asked about this before [1] but didn't finish the conversation.  My
main point is that I think "Completion Request" is a misnomer.
There's a "Configuration Request" and a "Completion," but no such
thing as a "Completion Request."

Based on your previous response, I think this should say something
like "respond to config requests with Request Retry Status (RRS) until
we're prepared to handle them."

> +	regmap_update_bits(stm32_pcie->regmap, SYSCFG_PCIECR,
> +			   STM32MP25_PCIECR_REQ_RETRY_EN,
> +			   STM32MP25_PCIECR_REQ_RETRY_EN);
> +}
> +
> +static int stm32_pcie_enable_link(struct dw_pcie *pci)
> +{
> +	struct stm32_pcie *stm32_pcie = to_stm32_pcie(pci);
> +	int ret;
> +
> +	regmap_update_bits(stm32_pcie->regmap, SYSCFG_PCIECR,
> +			   STM32MP25_PCIECR_LTSSM_EN,
> +			   STM32MP25_PCIECR_LTSSM_EN);
> +
> +	ret = dw_pcie_wait_for_link(pci);
> +	if (ret)
> +		return ret;
> +
> +	regmap_update_bits(stm32_pcie->regmap, SYSCFG_PCIECR,
> +			   STM32MP25_PCIECR_REQ_RETRY_EN,
> +			   0);

And I assume this means the endpoint will accept config requests and
handle them normally instead of responding with RRS.

Strictly speaking this is a different condition than "the link is up"
because the link must be up in order to even receive a config request.
The purpose of RRS is for devices that need more initialization time
after the link is up before they can respond to config requests.

The fact that the hardware provides this bit makes me think the
designer anticipated that the link might come up before the rest of
the device is fully initialized.

Bjorn

[1] https://lore.kernel.org/r/20241112203846.GA1856246@bhelgaas


  parent reply	other threads:[~2024-12-05 17:27 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-26 15:51 [PATCH v2 0/5] Add STM32MP25 PCIe drivers Christian Bruel
2024-11-26 15:51 ` [PATCH v2 1/5] dt-bindings: PCI: Add STM32MP25 PCIe root complex bindings Christian Bruel
2024-11-27 14:50   ` Rob Herring
2024-12-03 13:34   ` Manivannan Sadhasivam
2024-12-03 16:55     ` Christian Bruel
2024-12-03 22:25   ` Bjorn Helgaas
2024-12-05 13:41     ` Christian Bruel
2024-12-05 17:20       ` Bjorn Helgaas
2024-12-17 15:53         ` Christian Bruel
2024-12-17 17:25           ` Manivannan Sadhasivam
2024-12-18  8:42             ` Christian Bruel
2024-12-18  9:06               ` Manivannan Sadhasivam
2024-12-17 17:20     ` Manivannan Sadhasivam
2024-12-05 17:23   ` Bjorn Helgaas
2024-11-26 15:51 ` [PATCH v2 2/5] PCI: stm32: Add PCIe host support for STM32MP25 Christian Bruel
2024-11-29 20:58   ` Bjorn Helgaas
2024-11-29 21:18     ` Lucas Stach
2024-12-05 11:46       ` Christian Bruel
2024-12-03 14:52   ` Manivannan Sadhasivam
2024-12-16  9:00     ` Christian Bruel
2024-12-18  9:46       ` Manivannan Sadhasivam
2024-12-18 11:24         ` Christian Bruel
2024-12-18 11:46           ` Manivannan Sadhasivam
2024-12-09  4:34   ` kernel test robot
2024-11-26 15:51 ` [PATCH v2 3/5] dt-bindings: PCI: Add STM32MP25 PCIe endpoint bindings Christian Bruel
2024-11-27 14:51   ` Rob Herring
2024-11-27 14:59   ` Rob Herring (Arm)
2024-12-03 14:54   ` Manivannan Sadhasivam
2024-11-26 15:51 ` [PATCH v2 4/5] PCI: stm32: Add PCIe endpoint support for STM32MP25 Christian Bruel
2024-12-03 15:22   ` Manivannan Sadhasivam
2024-12-16 10:02     ` Christian Bruel
2024-12-16 16:17       ` Manivannan Sadhasivam
2024-12-17  9:48         ` Christian Bruel
2024-12-18  9:08           ` Manivannan Sadhasivam
2024-12-18  9:21             ` Christian Bruel
2025-01-10 15:33         ` Christian Bruel
2025-01-10 14:49     ` Christian Bruel
2024-12-05 17:27   ` Bjorn Helgaas [this message]
2024-12-16 14:00     ` Christian Bruel
2025-01-14 17:05       ` Bjorn Helgaas
2025-01-14 12:10     ` Christian Bruel
2024-11-26 15:51 ` [PATCH v2 5/5] MAINTAINERS: add entry for ST STM32MP25 PCIe drivers Christian Bruel

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=20241205172738.GA3054352@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=alexandre.torgue@foss.st.com \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=christian.bruel@foss.st.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=fabrice.gasnier@foss.st.com \
    --cc=krzk+dt@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=p.zabel@pengutronix.de \
    --cc=quic_schintav@quicinc.com \
    --cc=robh@kernel.org \
    /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