From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>,
Matthias Andree <matthias.andree@gmx.de>
Subject: Re: [Regression] pcie_wait_for_link_delay (1132.853 ms @ 5039.414431)
Date: Tue, 6 Aug 2019 17:15:36 +0300 [thread overview]
Message-ID: <20190806141536.GB2548@lahna.fi.intel.com> (raw)
In-Reply-To: <f83a541d-65de-ed05-c4c1-2bda345b30ef@molgen.mpg.de>
On Tue, Aug 06, 2019 at 04:02:42PM +0200, Paul Menzel wrote:
> >> How can I read out the delay from the system as done in?
> >
> > The delay is not system wide so it depends on the device. Typically it
> > is 100ms but there is a way to shorten it using ACPI _DSM.
>
> Yeah, I know. I was wondering if it can easily be read out for a device
> under `/sys`, other debug level or, for example, with `lspci` or
> `acpidump`.
AFAIK there is no easy way at least without patching the kernel. You can
log pdev->d3cold_delay for each device in pci_pm_init() for example.
> >> ```
> >> static int get_downstream_delay(struct pci_bus *bus)
> >> {
> >> struct pci_dev *pdev;
> >> int min_delay = 100;
> >> int max_delay = 0;
> >>
> >> list_for_each_entry(pdev, &bus->devices, bus_list) {
> >> if (!pdev->imm_ready)
> >> min_delay = 0;
> >> else if (pdev->d3cold_delay < min_delay)
> >> min_delay = pdev->d3cold_delay;
> >> if (pdev->d3cold_delay > max_delay)
> >> max_delay = pdev->d3cold_delay;
> >> }
> >>
> >> return max(min_delay, max_delay);
> >> }
> >> ```
> >>
> >>>> Anyway, there is such firmware out there, so I’d like to avoid the time
> >>>> increases.
> >>>>
> >>>> As a first step, the commit should be extended to print a warning (maybe if
> >>>> `initcall_debug` is specified), when the delay is higher than let’s say 50(?)
> >>>> ms. Also better documentation how to debug these delays would be appreciated.
> >>
> >> As your commit message says the standard demands a delay of at least 100 ms, 50 ms
> >> is of course too short, and maybe 150 ms or so should be used as the threshold.
> >>
> >>>> If there is no easy solution, it’d be great if the commit could be reverted for
> >>>> now, and a better solution be discussed for the next release.
> >>>
> >>> There is also kernel bugzilla entry about another regression this causes
> >>> here:
> >>>
> >>> https://bugzilla.kernel.org/show_bug.cgi?id=204413
> >>>
> >>> I agree we should revert c2bf1fc2 now. I'll try to come up alternative
> >>> solution to these missing delays that hopefully does not break existing
> >>> setups.
> >>>
> >>> Rafael, Bjorn,
> >>>
> >>> Can you revert the commit or do you want me to send a revert patch?
> >>>
> >>> Thanks and sorry about the breakage.
> >>
> >> No worries.
> >
> > Thanks for the lspci output. This explains the 1 second delay:
> >
> >> LnkCap: Port #2, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <256ns, L1 <8us
> >> ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+
> >
> > The port does not support active link reporting. Can you try the below
> > patch?
> >
> > Nicholas, can you also try it? I think it should solve your issue as
> > well.
> >
> > Thanks!
> >
> > diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
> > index 308c3e0c4a34..bb8c753013d0 100644
> > --- a/drivers/pci/pcie/portdrv_core.c
> > +++ b/drivers/pci/pcie/portdrv_core.c
> > @@ -434,7 +434,8 @@ static void wait_for_downstream_link(struct pci_dev *pdev)
> > * need to wait 100ms. For higher speeds (gen3) we need to wait
> > * first for the data link layer to become active.
> > */
> > - if (pcie_get_speed_cap(pdev) <= PCIE_SPEED_5_0GT)
> > + if (pcie_get_speed_cap(pdev) <= PCIE_SPEED_5_0GT ||
> > + !pdev->link_active_reporting)
> > msleep(delay);
> > else
> > pcie_wait_for_link_delay(pdev, true, delay);
>
> I can confirm, that the delay is reduced now.
>
> pcieport @ 0000:00:01.0 {pcieport} async_device (Total Suspend: 12.118 ms Total Resume: 105.604 ms)
Awesome, thanks.
> How can I enable the verbose log messages you got in your commit
> message like below?
>
> pcieport 0000:00:1b.0: wait for 100ms after DLLLA is set before access to 0000:01:00.0
It did not come from any log message, I just wrote it like that for the
commit log.
next prev parent reply other threads:[~2019-08-06 14:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-06 9:20 [Regression] pcie_wait_for_link_delay (1132.853 ms @ 5039.414431) Paul Menzel
2019-08-06 9:36 ` Mika Westerberg
2019-08-06 9:57 ` Paul Menzel
2019-08-06 11:31 ` Mika Westerberg
2019-08-06 14:02 ` Paul Menzel
2019-08-06 14:15 ` Mika Westerberg [this message]
2019-08-06 19:56 ` Matthias Andree
2019-08-07 10:06 ` Mika Westerberg
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=20190806141536.GB2548@lahna.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=matthias.andree@gmx.de \
--cc=nicholas.johnson-opensource@outlook.com.au \
--cc=pmenzel@molgen.mpg.de \
--cc=rafael.j.wysocki@intel.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).