From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Christian Bruel <christian.bruel@foss.st.com>
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, 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 2/5] PCI: stm32: Add PCIe host support for STM32MP25
Date: Wed, 18 Dec 2024 15:16:06 +0530 [thread overview]
Message-ID: <20241218094606.sljdx2w27thc5ahj@thinkpad> (raw)
In-Reply-To: <ced7a55a-d968-497f-abc2-663855882a3f@foss.st.com>
On Mon, Dec 16, 2024 at 10:00:27AM +0100, Christian Bruel wrote:
[...]
> >
> > > + msleep(PCIE_T_RRS_READY_MS);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static void stm32_pcie_stop_link(struct dw_pcie *pci)
> > > +{
> > > + struct stm32_pcie *stm32_pcie = to_stm32_pcie(pci);
> > > +
> > > + regmap_update_bits(stm32_pcie->regmap, SYSCFG_PCIECR,
> > > + STM32MP25_PCIECR_LTSSM_EN, 0);
> > > +
> > > + /* Assert PERST# */
> > > + if (stm32_pcie->perst_gpio)
> > > + gpiod_set_value(stm32_pcie->perst_gpio, 1);
> >
> > I don't like tying PERST# handling with start/stop link. PERST# should be
> > handled based on the power/clock state.
>
> I don't understand your point: We turn off the PHY in suspend_noirq(), so
> that seems a logical place to de-assert in resume_noirq after the refclk is
> ready. PERST# should be kept active until the PHY stablilizes the clock in
> resume. From the PCIe electromechanical specs, PERST# goes active while the
> refclk is not stable/
>
While your understanding about PERST# is correct, your implementation is not.
You are toggling PERST# from start/stop link callbacks which are supposed to
control the LTSSM state only. I don't have issues with toggling PERST# in
stm32_pcie_{suspend/resume}_noirq().
>
> >
> > > +}
> > > +
> > > +static int stm32_pcie_suspend(struct device *dev)
> > > +{
> > > + struct stm32_pcie *stm32_pcie = dev_get_drvdata(dev);
> > > +
> > > + if (device_may_wakeup(dev) || device_wakeup_path(dev))
> > > + enable_irq_wake(stm32_pcie->wake_irq);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int stm32_pcie_resume(struct device *dev)
> > > +{
> > > + struct stm32_pcie *stm32_pcie = dev_get_drvdata(dev);
> > > +
> > > + if (device_may_wakeup(dev) || device_wakeup_path(dev))
> > > + disable_irq_wake(stm32_pcie->wake_irq);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int stm32_pcie_suspend_noirq(struct device *dev)
> > > +{
> > > + struct stm32_pcie *stm32_pcie = dev_get_drvdata(dev);
> > > +
> > > + stm32_pcie->link_is_up = dw_pcie_link_up(stm32_pcie->pci);
> > > +
> > > + stm32_pcie_stop_link(stm32_pcie->pci);
> >
> > I don't understand how endpoint can wakeup the host if PERST# gets asserted.
>
> The stm32 PCIe doesn't support L2, we don't expect an in-band beacon for the
> wakeup. We support wakeup only from sideband WAKE#, that will restart the
> link from IRQ
>
I don't understand how WAKE# is supported without L2. Only in L2 state, endpoint
will make use of Vaux and it will wakeup the host using either beacon or WAKE#.
If you don't support L2, then the endpoint will reach L3 (link off) state.
> >
> > > + clk_disable_unprepare(stm32_pcie->clk);
> > > +
> > > + if (!device_may_wakeup(dev) && !device_wakeup_path(dev))
> > > + phy_exit(stm32_pcie->phy);
> > > +
> > > + return pinctrl_pm_select_sleep_state(dev);
> > > +}
> > > +
> > > +static int stm32_pcie_resume_noirq(struct device *dev)
> > > +{
> > > + struct stm32_pcie *stm32_pcie = dev_get_drvdata(dev);
> > > + struct dw_pcie *pci = stm32_pcie->pci;
> > > + struct dw_pcie_rp *pp = &pci->pp;
> > > + int ret;
> > > +
> > > + /* init_state must be called first to force clk_req# gpio when no
> >
> > CLKREQ#
> >
> > Why RC should control CLKREQ#?
>
> REFCLK is gated with CLKREQ#, So we cannot access the core
> without CLKREQ# if no device is present. So force it with a init pinmux
> the time to init the PHY and the core DBI registers
>
Ok. You should add a comment to clarify it in the code as this is not a standard
behavior.
> >
> > Also please use preferred style for multi-line comments:
> >
> > /*
> > * ...
> > */
> >
> > > + * device is plugged.
> > > + */
> > > + if (!IS_ERR(dev->pins->init_state))
> > > + ret = pinctrl_select_state(dev->pins->p, dev->pins->init_state);
> > > + else
> > > + ret = pinctrl_pm_select_default_state(dev);
> > > +
> > > + if (ret) {
> > > + dev_err(dev, "Failed to activate pinctrl pm state: %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + if (!device_may_wakeup(dev) && !device_wakeup_path(dev)) {
> > > + ret = phy_init(stm32_pcie->phy);
> > > + if (ret) {
> > > + pinctrl_pm_select_default_state(dev);
> > > + return ret;
> > > + }
> > > + }
> > > +
> > > + ret = clk_prepare_enable(stm32_pcie->clk);
> > > + if (ret)
> > > + goto clk_err;
> >
> > Please name the goto labels of their purpose. Like err_phy_exit.
>
> OK
>
> >
> > > +
> > > + ret = dw_pcie_setup_rc(pp);
> > > + if (ret)
> > > + goto pcie_err;
> >
> > This should be, 'err_disable_clk'.
> >
> > > +
> > > + if (stm32_pcie->link_is_up) {
> >
> > Why do you need this check? You cannot start the link in the absence of an
> > endpoint?
> >
>
> It is an optimization to avoid unnecessary "dw_pcie_wait_for_link" if no
> device is present during suspend
>
In that case you'll not trigger LTSSM if there was no endpoint connected before
suspend. What if users connect an endpoint after resume?
- Mani
--
மணிவண்ணன் சதாசிவம்
next prev parent reply other threads:[~2024-12-18 9:52 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 [this message]
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
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=20241218094606.sljdx2w27thc5ahj@thinkpad \
--to=manivannan.sadhasivam@linaro.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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.