From: Lukas Wunner <lukas@wunner.de>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Peter Wu <peter@lekensteyn.nl>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-pci@vger.kernel.org, linux-pm@vger.kernel.org,
Valdis Kletnieks <valdis.kletnieks@vt.edu>,
Dave Airlie <airlied@gmail.com>,
Andreas Noever <andreas.noever@gmail.com>
Subject: Re: [PATCH] PCI: Wait for 50ms after bridge is powered up
Date: Thu, 26 May 2016 12:10:06 +0200 [thread overview]
Message-ID: <20160526101006.GA6744@wunner.de> (raw)
In-Reply-To: <1464188696-25782-1-git-send-email-mika.westerberg@linux.intel.com>
Hi,
On Wed, May 25, 2016 at 06:04:56PM +0300, Mika Westerberg wrote:
> The PCI PM 1.2 specification requires minimum of 50ms before function on a
> bus is accessed after the bus is transitioned from B2 to B0. Now that we
> actually power down bridges we should make sure the specification is
> followed accordingly.
This patch has the unfortunate side effect of increasing boot time on
Macs with Thunderbolt by 320 ms. Granted, it's not much, but still
noticeable:
[ 2.358041] pcieport 0000:06:03.0: enabling device (0000 -> 0002)
[ 2.358195] pcieport 0000:06:03.0: rpm_idle
[ 2.358222] pcieport 0000:06:03.0: rpm_suspend
[ 2.411664] pcieport 0000:06:04.0: enabling device (0000 -> 0003)
[ 2.411821] pcieport 0000:06:04.0: rpm_idle
[ 2.411848] pcieport 0000:06:04.0: rpm_suspend
[ 2.467664] pcieport 0000:06:05.0: enabling device (0000 -> 0003)
[ 2.467817] pcieport 0000:06:05.0: rpm_idle
[ 2.467843] pcieport 0000:06:05.0: rpm_suspend
[ 2.523664] pcieport 0000:06:06.0: enabling device (0000 -> 0002)
[ 2.523822] pcieport 0000:06:06.0: rpm_idle
[ 2.523848] pcieport 0000:06:06.0: rpm_suspend
[ 2.579685] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 2.579722] pcieport 0000:06:03.0: rpm_resume
[ 2.635750] pciehp 0000:06:03.0:pcie204: Slot #3 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl- LLActRep+
[ 2.635853] pciehp 0000:06:03.0:pcie204: service driver pciehp loaded
[ 2.635858] pcieport 0000:06:03.0: rpm_idle
[ 2.635886] pcieport 0000:06:04.0: rpm_resume
[ 2.647645] pcieport 0000:06:03.0: rpm_suspend
[ 2.691747] pciehp 0000:06:04.0:pcie204: Slot #4 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl- LLActRep+
[ 2.691856] pciehp 0000:06:04.0:pcie204: service driver pciehp loaded
[ 2.691859] pcieport 0000:06:04.0: rpm_idle
[ 2.691888] pcieport 0000:06:05.0: rpm_resume
[ 2.703649] pcieport 0000:06:04.0: rpm_suspend
[ 2.747748] pciehp 0000:06:05.0:pcie204: Slot #5 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl- LLActRep+
[ 2.747842] pciehp 0000:06:05.0:pcie204: service driver pciehp loaded
[ 2.747845] pcieport 0000:06:06.0: rpm_resume
[ 2.749213] pcieport 0000:06:05.0: rpm_idle
[ 2.759650] pcieport 0000:06:05.0: rpm_suspend
[ 2.805049] pciehp 0000:06:06.0:pcie204: Slot #6 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl- LLActRep+
[ 2.806464] pciehp 0000:06:06.0:pcie204: service driver pciehp loaded
[ 2.806471] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[ 2.807876] intel_idle: MWAIT substates: 0x21120
[ 2.807878] intel_idle: v0.4.1 model 0x3A
[ 2.808170] intel_idle: lapic_timer_reliable_states 0xffffffff
[ 2.808201] GHES: HEST is not enabled!
[ 2.809613] pcieport 0000:06:06.0: rpm_idle
[ 2.809644] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 2.810096] Linux agpgart interface v0.103
[ 2.810158] AMD IOMMUv2 driver by Joerg Roedel <jroedel@suse.de>
[ 2.810158] AMD IOMMUv2 functionality not available on this system
[ 2.816468] pcieport 0000:06:06.0: rpm_suspend
I've added debug messages whenever ->runtime_idle / _suspend / _resume
is called for a device.
As can be seen, the PCI core now waits 50 ms after ->runtime_suspend.
Also, the ports are resumed when the pciehp service driver is loaded,
adding another 50 ms delay. For four hotplug ports, that's a total of
400 ms (versus 80 ms without the patch).
I'm wondering if the delay after ->runtime_suspend is really needed. Is
this mandated by the spec? We could perhaps increase the autosuspend_delay
in pcie_portdrv_probe() slightly to prevent the port from going to sleep
between pci_enable_device() and loading the pciehp service driver.
Thanks,
Lukas
>
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> ---
> Hi Bjorn,
>
> Since this is only needed when bridges are powered down, I think it makes
> sense to put this to your pci/pm branch.
>
> drivers/pci/pci.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index e785dc260e72..e645a3d4f2e0 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2361,7 +2361,12 @@ void pci_pm_init(struct pci_dev *dev)
> }
>
> dev->pm_cap = pm;
> - dev->d3_delay = PCI_PM_D3_WAIT;
> + /*
> + * PCI PM 1.2 specification requires minimum of 50ms before any
> + * function on the bus is accessed after the bus is transitioned
> + * from B2 to B0.
> + */
> + dev->d3_delay = pci_is_bridge(dev) ? PCI_PM_BUS_WAIT : PCI_PM_D3_WAIT;
> dev->d3cold_delay = PCI_PM_D3COLD_WAIT;
> dev->bridge_d3 = pci_bridge_d3_possible(dev);
> dev->d3cold_allowed = true;
> --
> 2.8.1
>
next prev parent reply other threads:[~2016-05-26 10:10 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-18 17:14 Rescanning is broken with runtime PM for PCIe ports Peter Wu
2016-05-19 7:42 ` Mika Westerberg
2016-05-19 11:36 ` Mika Westerberg
2016-05-20 8:45 ` Peter Wu
2016-05-23 8:20 ` [PATCH] PCI: Power on bridges before scanning new devices Mika Westerberg
2016-05-23 20:00 ` Bjorn Helgaas
2016-05-23 21:50 ` Bjorn Helgaas
2016-05-24 12:23 ` Bjorn Helgaas
2016-05-24 12:52 ` Lukas Wunner
2016-05-24 12:53 ` Mika Westerberg
2016-05-24 14:27 ` Peter Wu
2016-05-24 15:06 ` Lukas Wunner
2016-05-24 16:38 ` Bjorn Helgaas
2016-05-24 23:46 ` Peter Wu
2016-05-24 16:28 ` Bjorn Helgaas
2016-05-25 15:04 ` [PATCH] PCI: Wait for 50ms after bridge is powered up Mika Westerberg
2016-05-25 20:44 ` Rafael J. Wysocki
2016-05-26 10:10 ` Lukas Wunner [this message]
2016-05-26 10:25 ` Mika Westerberg
2016-05-26 10:45 ` Lukas Wunner
2016-05-26 11:03 ` Mika Westerberg
2016-05-28 12:29 ` Rafael J. Wysocki
2016-05-30 9:33 ` Mika Westerberg
2016-05-30 14:44 ` Mika Westerberg
2016-05-30 15:19 ` Andreas Noever
2016-05-31 8:33 ` Mika Westerberg
2016-05-31 8:58 ` Mika Westerberg
2016-05-31 10:40 ` Lukas Wunner
2016-05-31 10:47 ` Mika Westerberg
2016-05-31 11:07 ` Lukas Wunner
2016-06-01 9:11 ` Mika Westerberg
2016-06-01 11:42 ` Lukas Wunner
2016-05-24 21:13 ` [PATCH] PCI: Power on bridges before scanning new devices Mika Westerberg
2016-05-25 0:03 ` Rafael J. Wysocki
2016-05-25 13:19 ` Mika Westerberg
2016-05-25 20:45 ` Rafael J. Wysocki
2016-05-26 8:16 ` Mika Westerberg
2016-05-28 12:21 ` Rafael J. Wysocki
2016-05-30 9:35 ` Mika Westerberg
2016-05-25 12:16 ` Lukas Wunner
2016-05-25 13:25 ` 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=20160526101006.GA6744@wunner.de \
--to=lukas@wunner.de \
--cc=airlied@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=peter@lekensteyn.nl \
--cc=rjw@rjwysocki.net \
--cc=valdis.kletnieks@vt.edu \
/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.