linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Christian Bruel <christian.bruel@foss.st.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: <lpieralisi@kernel.org>, <kw@linux.com>, <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>,
	<thippeswamy.havalige@amd.com>, <shradha.t@samsung.com>,
	<quic_schintav@quicinc.com>, <cassel@kernel.org>,
	<johan+linaro@kernel.org>, <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 v8 4/9] PCI: stm32: Add PCIe Endpoint support for STM32MP25
Date: Fri, 16 May 2025 14:07:22 +0200	[thread overview]
Message-ID: <b3bff3aa-cd99-4c9e-851a-950a4877e664@foss.st.com> (raw)
In-Reply-To: <b5x4fayqm242xqm3rgwvrz3jywlixedhhxwo7lft2y3tnuszxr@3oy2kzj2of5l>

(Sorry I missed the last point before my reply with a new v9/v10 series)

On 5/15/25 13:26, Manivannan Sadhasivam wrote:
> On Mon, May 12, 2025 at 06:06:16PM +0200, Christian Bruel wrote:
>> Hello Manivannan,
>>
>> On 4/30/25 09:50, Manivannan Sadhasivam wrote:
>>> On Wed, Apr 23, 2025 at 11:01:14AM +0200, Christian Bruel wrote:
>>>> Add driver to configure the STM32MP25 SoC PCIe Gen1 2.5GT/s or Gen2 5GT/s
>>>> controller based on the DesignWare PCIe core in endpoint mode.
>>>>
>>>> Uses the common reference clock provided by the host.
>>>>
>>>> The PCIe core_clk receives the pipe0_clk from the ComboPHY as input,
>>>> and the ComboPHY PLL must be locked for pipe0_clk to be ready.
>>>> Consequently, PCIe core registers cannot be accessed until the ComboPHY is
>>>> fully initialised and refclk is enabled and ready.
>>>>
>>>> Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
>>>> ---
>>>>    drivers/pci/controller/dwc/Kconfig         |  12 +
>>>>    drivers/pci/controller/dwc/Makefile        |   1 +
>>>>    drivers/pci/controller/dwc/pcie-stm32-ep.c | 414 +++++++++++++++++++++
>>>>    drivers/pci/controller/dwc/pcie-stm32.h    |   1 +
>>>>    4 files changed, 428 insertions(+)
>>>>    create mode 100644 drivers/pci/controller/dwc/pcie-stm32-ep.c
>>>>
>>>> diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
>>>> index 2aec5d2f9a46..aceff7d1ef33 100644
>>>> --- a/drivers/pci/controller/dwc/Kconfig
>>>> +++ b/drivers/pci/controller/dwc/Kconfig
>>>> @@ -422,6 +422,18 @@ config PCIE_STM32_HOST
>>>>    	  This driver can also be built as a module. If so, the module
>>>>    	  will be called pcie-stm32.
>>>> +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
>>>> +	  found in STM32MP25 SoC.
>>>
>>> Can you please use similar description for the RC driver also?
>>>
>>> "Enables Root Complex (RC) support for the DesignWare core based PCIe host
>>> controller found in STM32MP25 SoC."
>>
>> Yes, will align the messages
>>
>>>> +
>>>> +	  This driver can also be built as a module. If so, the module
>>>> +	  will be called pcie-stm32-ep.
>>>> +
>>>>    config PCI_DRA7XX
>>>>    	tristate
>>>
>>> [...]
>>>
>>>> +static int stm32_add_pcie_ep(struct stm32_pcie *stm32_pcie,
>>>> +			     struct platform_device *pdev)
>>>> +{
>>>> +	struct dw_pcie_ep *ep = &stm32_pcie->pci.ep;
>>>> +	struct device *dev = &pdev->dev;
>>>> +	int ret;
>>>> +
>>>> +	ret = pm_runtime_resume_and_get(dev);
>>>
>>> This needs to be called before devm_pm_runtime_enable().
>>
>> OK. Also and we must use pm_runtime_get_noresume() here.
>>
> 
> Yes!
> 
>>>
>>>> +	if (ret < 0) {
>>>> +		dev_err(dev, "pm runtime resume failed: %d\n", ret);
>>>> +		return ret;
>>>> +	}
>>>> +
>>>> +	ret = regmap_update_bits(stm32_pcie->regmap, SYSCFG_PCIECR,
>>>> +				 STM32MP25_PCIECR_TYPE_MASK,
>>>> +				 STM32MP25_PCIECR_EP);
>>>> +	if (ret) {
>>>> +		goto err_pm_put_sync;
>>>> +		return ret;
>>>> +	}
>>>> +
>>>> +	reset_control_assert(stm32_pcie->rst);
>>>> +	reset_control_deassert(stm32_pcie->rst);
>>>> +
>>>> +	ep->ops = &stm32_pcie_ep_ops;
>>>> +
>>>> +	ret = dw_pcie_ep_init(ep);
>>>> +	if (ret) {
>>>> +		dev_err(dev, "failed to initialize ep: %d\n", ret);
>>>> +		goto err_pm_put_sync;
>>>> +	}
>>>> +
>>>> +	ret = stm32_pcie_enable_resources(stm32_pcie);
>>>> +	if (ret) {
>>>> +		dev_err(dev, "failed to enable resources: %d\n", ret);
>>>> +		goto err_ep_deinit;
>>>> +	}
>>>> +
>>>> +	ret = dw_pcie_ep_init_registers(ep);
>>>> +	if (ret) {
>>>> +		dev_err(dev, "Failed to initialize DWC endpoint registers\n");
>>>> +		goto err_disable_resources;
>>>> +	}
>>>> +
>>>> +	pci_epc_init_notify(ep->epc);
>>>> +
>>>
>>> Hmm, looks like you need to duplicate dw_pcie_ep_init_registers() and
>>> pci_epc_init_notify() in stm32_pcie_perst_deassert() for hw specific reasons.
>>> So can you drop these from there?
>>
>> We cannot remove dw_pcie_ep_init_registers() and dw_pcie_ep_init_registers()
>> here because the PCIe registers need to be ready at the end of
>> pcie_stm32_probe, as the host might already be running. In that case the
>> host enumerates with /sys/bus/pci/rescan rather than asserting/deasserting
>> PERST#.
>> Therefore, we do not need to reboot the host after initializing the EP."
>>
> 
> Since PERST# is level triggered, the endpoint should still receive the PERST#
> deassert interrupt if the host was already booted. In that case, these will be
> called by the stm32_pcie_perst_deassert() function.

GPIO level interrupts are simulated on STM32 (*), so I didn't consider 
using them here
However, using the same sequence as in pcie-qcom-ep.c works fine with 
the gpio hack, avoiding the call the dw_pcie_ep_init_registers() here.

I will switch to this scheme. Thank you

Christian

(*) 47beed513a85b3561e74cbb4dd7af848716fa4e0 ("pinctrl: stm32: Add level 
interrupt support to gpio irq chip")


> 
> - Mani
> 


  reply	other threads:[~2025-05-16 12:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-23  9:01 [PATCH v8 0/9] Add STM32MP25 PCIe drivers Christian Bruel
2025-04-23  9:01 ` [PATCH v8 1/9] dt-bindings: PCI: Add STM32MP25 PCIe Root Complex bindings Christian Bruel
2025-04-23  9:01 ` [PATCH v8 2/9] PCI: stm32: Add PCIe host support for STM32MP25 Christian Bruel
2025-04-30  7:30   ` Manivannan Sadhasivam
2025-05-12 15:08     ` Christian Bruel
2025-05-15 11:29       ` Manivannan Sadhasivam
2025-05-16  8:37         ` Christian Bruel
2025-05-16 14:52           ` Manivannan Sadhasivam
2025-06-04 16:35             ` Christian Bruel
2025-04-23  9:01 ` [PATCH v8 3/9] dt-bindings: PCI: Add STM32MP25 PCIe Endpoint bindings Christian Bruel
2025-04-23  9:01 ` [PATCH v8 4/9] PCI: stm32: Add PCIe Endpoint support for STM32MP25 Christian Bruel
2025-04-30  7:50   ` Manivannan Sadhasivam
2025-05-12 16:06     ` Christian Bruel
2025-05-15 11:26       ` Manivannan Sadhasivam
2025-05-16 12:07         ` Christian Bruel [this message]
2025-04-23  9:01 ` [PATCH v8 5/9] MAINTAINERS: add entry for ST STM32MP25 PCIe drivers Christian Bruel
2025-04-23  9:01 ` [PATCH v8 6/9] arm64: dts: st: add PCIe pinctrl entries in stm32mp25-pinctrl.dtsi Christian Bruel
2025-04-23  9:01 ` [PATCH v8 7/9] arm64: dts: st: Add PCIe Root Complex mode on stm32mp251 Christian Bruel
2025-04-23  9:01 ` [PATCH v8 8/9] arm64: dts: st: Add PCIe Endpoint " Christian Bruel
2025-04-23  9:01 ` [PATCH v8 9/9] arm64: dts: st: Enable PCIe on the stm32mp257f-ev1 board 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=b3bff3aa-cd99-4c9e-851a-950a4877e664@foss.st.com \
    --to=christian.bruel@foss.st.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=johan+linaro@kernel.org \
    --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 \
    --cc=shradha.t@samsung.com \
    --cc=thippeswamy.havalige@amd.com \
    /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;
as well as URLs for NNTP newsgroup(s).