From: Francesco Dolcini <francesco.dolcini@toradex.com>
To: Hongxing Zhu <hongxing.zhu@nxp.com>
Cc: Lucas Stach <l.stach@pengutronix.de>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"broonie@kernel.org" <broonie@kernel.org>,
"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
"jingoohan1@gmail.com" <jingoohan1@gmail.com>,
"festevam@gmail.com" <festevam@gmail.com>,
"francesco.dolcini@toradex.com" <francesco.dolcini@toradex.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH v9 6/8] PCI: imx6: Disable clocks and regulators after link is down
Date: Thu, 9 Jun 2022 09:53:05 +0200 [thread overview]
Message-ID: <20220609075305.GA20630@francesco-nb.int.toradex.com> (raw)
In-Reply-To: <AS8PR04MB86763AE6FF5BABE3EBED833B8CA79@AS8PR04MB8676.eurprd04.prod.outlook.com>
On Thu, Jun 09, 2022 at 06:17:46AM +0000, Hongxing Zhu wrote:
> > -----Original Message-----
> > From: Lucas Stach <l.stach@pengutronix.de>
> > Sent: 2022年6月8日 15:35
> > To: Hongxing Zhu <hongxing.zhu@nxp.com>; bhelgaas@google.com;
> > robh+dt@kernel.org; broonie@kernel.org; lorenzo.pieralisi@arm.com;
> > jingoohan1@gmail.com; festevam@gmail.com;
> > francesco.dolcini@toradex.com
> > Cc: linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > linux-kernel@vger.kernel.org; kernel@pengutronix.de; dl-linux-imx
> > <linux-imx@nxp.com>
> > Subject: Re: [PATCH v9 6/8] PCI: imx6: Disable clocks and regulators after link is
> > down
> >
> > Am Freitag, dem 06.05.2022 um 09:47 +0800 schrieb Richard Zhu:
> > > Since i.MX PCIe doesn't support hot-plug, reduce power consumption as
> > > much as possible by disabling clocks and regulators and returning
> > > error when the link is down.
> > >
> > > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > > ---
> > > drivers/pci/controller/dwc/pci-imx6.c | 19 +++++++++++++++----
> > > 1 file changed, 15 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index 3ce3993d5797..d122c12193a6 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -845,7 +845,9 @@ static int imx6_pcie_start_link(struct dw_pcie *pci)
> > > /* Start LTSSM. */
> > > imx6_pcie_ltssm_enable(dev);
> > >
> > > - dw_pcie_wait_for_link(pci);
> > > + ret = dw_pcie_wait_for_link(pci);
> > > + if (ret)
> > > + goto err_out;
> >
> > This adds back error handling that has been intentionally removed in
> > f81f095e8771 ("PCI: imx6: Allow to probe when dw_pcie_wait_for_link() fails").
> > While I agree that disabling the clocks and regulators is the right thing to do
> > when we don't manage to get a link, we should still allow the driver to probe,
> > so please add a "ret = 0" to this newly added non-fatal error paths.
> >
> Thanks for your review comments.
> There would be a long latency if the link is down and probe is finished
> successfully.
> Since the dw_pcie_wait_for_link() would be invoked twice in every driver probe
> and resume operation later. Each dw_pcie_wait_for_link() would consume about
> 90,000*10 ~ 100,000*10 u-seconds. I'm afraid that such a long latency would
> bring bad user experience.
>
> Here are the logs when probe is allowed when PCIe link is down:
> [ 55.045954][ T1835] imx6q-pcie 5f000000.pcie: PM: calling imx6_pcie_resume_noirq.742dfa074b40dca7ca925f0c49c905ec.cfi_jt+0x0/0x8 @ 1835, parent: bus@5f000000
> ...
> [ 56.074566][ T1835] imx6q-pcie 5f000000.pcie: Phy link never came up
> [ 57.074816][ T1835] imx6q-pcie 5f000000.pcie: Phy link never came up
> ...
> [ 57.182300][ T1835] imx6q-pcie 5f000000.pcie: PM: imx6_pcie_resume_noirq.742dfa074b40dca7ca925f0c49c905ec.cfi_jt+0x0/0x8 returned 0 after 2136334 usecs
>
> [ 57.182347][ T1835] imx6q-pcie 5f010000.pcie: PM: calling imx6_pcie_resume_noirq.742dfa074b40dca7ca925f0c49c905ec.cfi_jt+0x0/0x8 @ 1835, parent: bus@5f000000
> ...
> [ 58.210584][ T1835] imx6q-pcie 5f010000.pcie: Phy link never came up
> [ 59.210831][ T1835] imx6q-pcie 5f010000.pcie: Phy link never came up
> ...
> [ 59.318313][ T1835] imx6q-pcie 5f010000.pcie: PM: imx6_pcie_resume_noirq.742dfa074b40dca7ca925f0c49c905ec.cfi_jt+0x0/0x8 returned 0 after 2135949 usecs
>
> So, I'm prefer that it's better to let the probe failed when link is down.
> How do you think about that?
I think that recently Bjorn mentioned some concern with this approach,
and I agree with him.
I think that the probe of the PCIe root port should not fail if the link
is down.
What is the reason for such a long wait in dw_pcie_wait_for_link()? Is
this slowing down the resume process as a whole? Why called twice? (I'm
not familiar with that part of the code)
Francesco
WARNING: multiple messages have this Message-ID (diff)
From: Francesco Dolcini <francesco.dolcini@toradex.com>
To: Hongxing Zhu <hongxing.zhu@nxp.com>
Cc: Lucas Stach <l.stach@pengutronix.de>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"broonie@kernel.org" <broonie@kernel.org>,
"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
"jingoohan1@gmail.com" <jingoohan1@gmail.com>,
"festevam@gmail.com" <festevam@gmail.com>,
"francesco.dolcini@toradex.com" <francesco.dolcini@toradex.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH v9 6/8] PCI: imx6: Disable clocks and regulators after link is down
Date: Thu, 9 Jun 2022 09:53:05 +0200 [thread overview]
Message-ID: <20220609075305.GA20630@francesco-nb.int.toradex.com> (raw)
In-Reply-To: <AS8PR04MB86763AE6FF5BABE3EBED833B8CA79@AS8PR04MB8676.eurprd04.prod.outlook.com>
On Thu, Jun 09, 2022 at 06:17:46AM +0000, Hongxing Zhu wrote:
> > -----Original Message-----
> > From: Lucas Stach <l.stach@pengutronix.de>
> > Sent: 2022年6月8日 15:35
> > To: Hongxing Zhu <hongxing.zhu@nxp.com>; bhelgaas@google.com;
> > robh+dt@kernel.org; broonie@kernel.org; lorenzo.pieralisi@arm.com;
> > jingoohan1@gmail.com; festevam@gmail.com;
> > francesco.dolcini@toradex.com
> > Cc: linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > linux-kernel@vger.kernel.org; kernel@pengutronix.de; dl-linux-imx
> > <linux-imx@nxp.com>
> > Subject: Re: [PATCH v9 6/8] PCI: imx6: Disable clocks and regulators after link is
> > down
> >
> > Am Freitag, dem 06.05.2022 um 09:47 +0800 schrieb Richard Zhu:
> > > Since i.MX PCIe doesn't support hot-plug, reduce power consumption as
> > > much as possible by disabling clocks and regulators and returning
> > > error when the link is down.
> > >
> > > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > > ---
> > > drivers/pci/controller/dwc/pci-imx6.c | 19 +++++++++++++++----
> > > 1 file changed, 15 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index 3ce3993d5797..d122c12193a6 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -845,7 +845,9 @@ static int imx6_pcie_start_link(struct dw_pcie *pci)
> > > /* Start LTSSM. */
> > > imx6_pcie_ltssm_enable(dev);
> > >
> > > - dw_pcie_wait_for_link(pci);
> > > + ret = dw_pcie_wait_for_link(pci);
> > > + if (ret)
> > > + goto err_out;
> >
> > This adds back error handling that has been intentionally removed in
> > f81f095e8771 ("PCI: imx6: Allow to probe when dw_pcie_wait_for_link() fails").
> > While I agree that disabling the clocks and regulators is the right thing to do
> > when we don't manage to get a link, we should still allow the driver to probe,
> > so please add a "ret = 0" to this newly added non-fatal error paths.
> >
> Thanks for your review comments.
> There would be a long latency if the link is down and probe is finished
> successfully.
> Since the dw_pcie_wait_for_link() would be invoked twice in every driver probe
> and resume operation later. Each dw_pcie_wait_for_link() would consume about
> 90,000*10 ~ 100,000*10 u-seconds. I'm afraid that such a long latency would
> bring bad user experience.
>
> Here are the logs when probe is allowed when PCIe link is down:
> [ 55.045954][ T1835] imx6q-pcie 5f000000.pcie: PM: calling imx6_pcie_resume_noirq.742dfa074b40dca7ca925f0c49c905ec.cfi_jt+0x0/0x8 @ 1835, parent: bus@5f000000
> ...
> [ 56.074566][ T1835] imx6q-pcie 5f000000.pcie: Phy link never came up
> [ 57.074816][ T1835] imx6q-pcie 5f000000.pcie: Phy link never came up
> ...
> [ 57.182300][ T1835] imx6q-pcie 5f000000.pcie: PM: imx6_pcie_resume_noirq.742dfa074b40dca7ca925f0c49c905ec.cfi_jt+0x0/0x8 returned 0 after 2136334 usecs
>
> [ 57.182347][ T1835] imx6q-pcie 5f010000.pcie: PM: calling imx6_pcie_resume_noirq.742dfa074b40dca7ca925f0c49c905ec.cfi_jt+0x0/0x8 @ 1835, parent: bus@5f000000
> ...
> [ 58.210584][ T1835] imx6q-pcie 5f010000.pcie: Phy link never came up
> [ 59.210831][ T1835] imx6q-pcie 5f010000.pcie: Phy link never came up
> ...
> [ 59.318313][ T1835] imx6q-pcie 5f010000.pcie: PM: imx6_pcie_resume_noirq.742dfa074b40dca7ca925f0c49c905ec.cfi_jt+0x0/0x8 returned 0 after 2135949 usecs
>
> So, I'm prefer that it's better to let the probe failed when link is down.
> How do you think about that?
I think that recently Bjorn mentioned some concern with this approach,
and I agree with him.
I think that the probe of the PCIe root port should not fail if the link
is down.
What is the reason for such a long wait in dw_pcie_wait_for_link()? Is
this slowing down the resume process as a whole? Why called twice? (I'm
not familiar with that part of the code)
Francesco
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-06-09 7:55 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-06 1:47 [PATCH v9 0/8] PCI: imx6: refine codes and add compliance tests mode support Richard Zhu
2022-05-06 1:47 ` Richard Zhu
2022-05-06 1:47 ` [PATCH v9 1/8] PCI: imx6: Encapsulate the clock enable into one standalone function Richard Zhu
2022-05-06 1:47 ` Richard Zhu
2022-06-08 18:51 ` Bjorn Helgaas
2022-06-08 18:51 ` Bjorn Helgaas
2022-06-09 6:18 ` Hongxing Zhu
2022-06-09 6:18 ` Hongxing Zhu
2022-05-06 1:47 ` [PATCH v9 2/8] PCI: imx6: Add the error propagation from host_init Richard Zhu
2022-05-06 1:47 ` Richard Zhu
2022-06-08 18:53 ` Bjorn Helgaas
2022-06-08 18:53 ` Bjorn Helgaas
2022-06-09 6:19 ` Hongxing Zhu
2022-06-09 6:19 ` Hongxing Zhu
2022-05-06 1:47 ` [PATCH v9 3/8] PCI: imx6: Move imx6_pcie_clk_disable() earlier Richard Zhu
2022-05-06 1:47 ` Richard Zhu
2022-06-08 7:14 ` Lucas Stach
2022-06-08 7:14 ` Lucas Stach
2022-05-06 1:47 ` [PATCH v9 4/8] PCI: imx6: Disable iMX6QDL PCIe REF clock when disable PCIe clocks Richard Zhu
2022-05-06 1:47 ` Richard Zhu
2022-06-08 7:18 ` Lucas Stach
2022-06-08 7:18 ` Lucas Stach
2022-05-06 1:47 ` [PATCH v9 5/8] PCI: imx6: Refine the regulator usage Richard Zhu
2022-05-06 1:47 ` Richard Zhu
2022-06-08 7:26 ` Lucas Stach
2022-06-08 7:26 ` Lucas Stach
2022-06-09 6:17 ` Hongxing Zhu
2022-06-09 6:17 ` Hongxing Zhu
2022-06-09 7:47 ` Lucas Stach
2022-06-09 7:47 ` Lucas Stach
2022-06-09 7:54 ` Hongxing Zhu
2022-06-09 7:54 ` Hongxing Zhu
2022-06-08 18:54 ` Bjorn Helgaas
2022-06-08 18:54 ` Bjorn Helgaas
2022-06-09 6:19 ` Hongxing Zhu
2022-06-09 6:19 ` Hongxing Zhu
2022-06-09 17:20 ` Bjorn Helgaas
2022-06-09 17:20 ` Bjorn Helgaas
2022-06-10 7:09 ` Hongxing Zhu
2022-06-10 7:09 ` Hongxing Zhu
2022-05-06 1:47 ` [PATCH v9 6/8] PCI: imx6: Disable clocks and regulators after link is down Richard Zhu
2022-05-06 1:47 ` Richard Zhu
2022-06-08 7:35 ` Lucas Stach
2022-06-08 7:35 ` Lucas Stach
2022-06-09 6:17 ` Hongxing Zhu
2022-06-09 6:17 ` Hongxing Zhu
2022-06-09 7:53 ` Francesco Dolcini [this message]
2022-06-09 7:53 ` Francesco Dolcini
2022-06-09 8:36 ` Hongxing Zhu
2022-06-09 8:36 ` Hongxing Zhu
2022-06-09 7:55 ` Lucas Stach
2022-06-09 7:55 ` Lucas Stach
2022-06-09 8:30 ` Hongxing Zhu
2022-06-09 8:30 ` Hongxing Zhu
2022-05-06 1:47 ` [PATCH v9 7/8] PCI: imx6: Move the phy driver callbacks to the proper places Richard Zhu
2022-05-06 1:47 ` Richard Zhu
2022-06-08 7:44 ` Lucas Stach
2022-06-08 7:44 ` Lucas Stach
2022-06-09 6:18 ` Hongxing Zhu
2022-06-09 6:18 ` Hongxing Zhu
2022-06-08 18:57 ` Bjorn Helgaas
2022-06-08 18:57 ` Bjorn Helgaas
2022-06-09 6:20 ` Hongxing Zhu
2022-06-09 6:20 ` Hongxing Zhu
2022-06-09 16:25 ` Bjorn Helgaas
2022-06-09 16:25 ` Bjorn Helgaas
2022-06-10 6:51 ` Hongxing Zhu
2022-06-10 6:51 ` Hongxing Zhu
2022-05-06 1:47 ` [PATCH v9 8/8] PCI: imx6: Add compliance tests mode support Richard Zhu
2022-05-06 1:47 ` Richard Zhu
2022-06-08 7:48 ` Lucas Stach
2022-06-08 7:48 ` Lucas Stach
2022-06-09 6:18 ` Hongxing Zhu
2022-06-09 6:18 ` Hongxing Zhu
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=20220609075305.GA20630@francesco-nb.int.toradex.com \
--to=francesco.dolcini@toradex.com \
--cc=bhelgaas@google.com \
--cc=broonie@kernel.org \
--cc=festevam@gmail.com \
--cc=hongxing.zhu@nxp.com \
--cc=jingoohan1@gmail.com \
--cc=kernel@pengutronix.de \
--cc=l.stach@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=robh+dt@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.