From: Ajay Agarwal <ajayagarwal@google.com>
To: Johan Hovold <johan@kernel.org>,
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Jingoo Han" <jingoohan1@gmail.com>,
"Gustavo Pimentel" <gustavo.pimentel@synopsys.com>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
"Bjorn Andersson" <quic_bjorande@quicinc.com>,
"Sajid Dalvi" <sdalvi@google.com>
Subject: Re: [PATCH] Revert "PCI: dwc: Wait for link up only if link is started"
Date: Mon, 10 Jul 2023 21:51:22 +0530 [thread overview]
Message-ID: <ZKwwAin4FcCETGq/@google.com> (raw)
In-Reply-To: <ZKgJfG5Mi-e77LQT@hovoldconsulting.com>
On Fri, Jul 07, 2023 at 02:47:56PM +0200, Johan Hovold wrote:
> On Thu, Jul 06, 2023 at 06:28:11PM +0530, Manivannan Sadhasivam wrote:
> > On Thu, Jul 06, 2023 at 10:26:10AM +0200, Johan Hovold wrote:
>
> > > Finally, note that the intel-gw driver is the only driver currently not
> > > providing a start_link callback and instead starts the link in its
> > > host_init callback, and which may avoid an additional one-second timeout
> > > during probe by making the link-up wait conditional. If anyone cares,
> > > that can be done in a follow-up patch with a proper motivation.
>
> > The offending commit is bogus since it makes the intel-gw _special_ w.r.t
> > waiting for the link up. Most of the drivers call dw_pcie_host_init() during the
> > probe time and they all have to wait for 1 sec if the slot is empty.
Mani, can you please explain how my commit made the intel-gw driver
special? The intel driver actually fails the dw_pcie_host_init if the
link does not come up. That was my motivation behind adding the fail
logic in the core driver as well.
>
> Just to clarify, the intel-gw driver starts the link and waits for link
> up in its host_init() callback, which is called during probe. That wait
> could possibly just be dropped in favour of the one in
> dw_pcie_host_init() and/or the driver could be reworked to implement
> start_link().
>
> Either way, the call in dw_pcie_host_init() will only add an additional
> 1 second delay in cases where the link did *not* come up.
>
> > As Johan noted, intel-gw should make use of the async probe to avoid the boot
> > delay instead of adding a special case.
>
> Indeed.
>
> Johan
Johan, Mani
My apologies for adding this regression in some of the SOCs.
May I suggest to keep my patch and make the following change instead?
This shall keep the existing behavior as is, and save the boot time
for drivers that do not define the start_link()?
```
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index cf61733bf78d..af6a7cd060b1 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -492,11 +492,8 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
if (ret)
goto err_remove_edma;
- if (pci->ops && pci->ops->start_link) {
- ret = dw_pcie_wait_for_link(pci);
- if (ret)
- goto err_stop_link;
- }
+ if (pci->ops && pci->ops->start_link)
+ dw_pcie_wait_for_link(pci);
}
bridge->sysdata = pp;
```
next prev parent reply other threads:[~2023-07-10 16:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-06 8:26 [PATCH] Revert "PCI: dwc: Wait for link up only if link is started" Johan Hovold
2023-07-06 12:58 ` Manivannan Sadhasivam
2023-07-07 12:47 ` Johan Hovold
2023-07-10 16:21 ` Ajay Agarwal [this message]
2023-07-10 16:42 ` Ajay Agarwal
2023-07-10 17:06 ` Krzysztof Wilczyński
2023-07-11 6:52 ` Johan Hovold
2023-07-12 17:45 ` Ajay Agarwal
2023-07-14 8:55 ` Johan Hovold
2024-01-11 15:43 ` Ajay Agarwal
2023-07-11 7:37 ` Manivannan Sadhasivam
2024-01-12 10:00 ` Ajay Agarwal
2024-01-19 7:40 ` Manivannan Sadhasivam
2023-07-25 20:05 ` Bjorn Helgaas
2023-07-26 8:30 ` Johan Hovold
2023-07-26 15:58 ` Bjorn Helgaas
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=ZKwwAin4FcCETGq/@google.com \
--to=ajayagarwal@google.com \
--cc=bhelgaas@google.com \
--cc=gustavo.pimentel@synopsys.com \
--cc=jingoohan1@gmail.com \
--cc=johan@kernel.org \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=quic_bjorande@quicinc.com \
--cc=robh@kernel.org \
--cc=sdalvi@google.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).