archive mirror
 help / color / mirror / Atom feed
From: Mika Westerberg <>
To: Kai-Heng Feng <>
Cc: Rafael Wysocki <>,
	"Shih-Yuan Lee (FourDollars)" <>,
	Tiffany <>,
	Linux PCI <>,
	Linux PM <>,
	open list <>
Subject: Re: Thunderbolt, direct-complete and long suspend/resume time of Suspend-to-idle
Date: Wed, 11 Mar 2020 12:38:40 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Mar 11, 2020 at 01:39:51PM +0800, Kai-Heng Feng wrote:
> Hi,
> I am currently investigating long suspend and resume time of suspend-to-idle.
> It's because Thunderbolt bridges need to wait for 1100ms [1] for runtime-resume on system suspend, and also for system resume.
> I made a quick hack to the USB driver and xHCI driver to support direct-complete, but I failed to do so for the parent PCIe bridge as it always disables the direct-complete [2], since device_may_wakeup() returns true for the device:
> 	/* Avoid direct_complete to let wakeup_path propagate. */
> 		if (device_may_wakeup(dev) || dev->power.wakeup_path)
> 			dev->power.direct_complete = false;

You need to be careful here because otherwise you end up situation where
the link is not properly trained and we tear down the whole tree of
devices which is worse than waiting bit more for resume.

> Once the direct-complete is disabled, system suspend/resume is used hence the delay in [1] is making the resume really slow. 
> So how do we make suspend-to-idle faster? I have some ideas but I am not sure if they are feasible:
> - Make PM core know the runtime_suspend() already use the same wakeup as suspend(), so it doesn't need to use device_may_wakeup() check to determine direct-complete.
> - Remove the DPM_FLAG_NEVER_SKIP flag in pcieport driver, and use pm_request_resume() in its complete() callback to prevent blocking the resume process.
> - Reduce the 1100ms delay. Maybe someone knows the values used in macOS and Windows...

Which system this is? ICL? I think it is the TBT root ports only that do
not support active link reporting. The PCIe spec is not entirely clear
about root ports since it explictly mentions only downstream ports so
one option would be to check for root port and that it supports gen 3
speeds and based on that wait for max say 2 * 100ms or something like

  reply	other threads:[~2020-03-11 10:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11  5:39 Thunderbolt, direct-complete and long suspend/resume time of Suspend-to-idle Kai-Heng Feng
2020-03-11 10:38 ` Mika Westerberg [this message]
2020-03-12  4:41   ` Kai-Heng Feng
2020-03-12  8:15     ` Mika Westerberg
2020-03-12 10:10       ` Kai-Heng Feng
2020-03-12 10:41         ` Mika Westerberg
2020-03-13  5:07           ` Kai-Heng Feng
2020-03-13 11:31             ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* 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).