linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, linux-rockchip@lists.infradead.org,
	Wenrui Li <wenrui.li@rock-chips.com>,
	Jeffy Chen <jeffy.chen@rock-chips.com>
Subject: Re: [PATCH 3/3] PCI: rockchip: Add system PM support
Date: Tue, 22 Nov 2016 20:56:58 -0800	[thread overview]
Message-ID: <20161123045658.GB28948@google.com> (raw)
In-Reply-To: <bf970e48-80a0-7a18-4d87-93a5748f01c2@rock-chips.com>

On Wed, Nov 23, 2016 at 10:51:50AM +0800, Shawn Lin wrote:
> 在 2016/11/23 10:45, Brian Norris 写道:
> >I'm not sure if that's necessary. I was just curious on how this got
> >determined, when it seemed that 500ms was plenty.
> >
> 
> Refer to https://lists.launchpad.net/kernel-packages/msg123315.html
> 
> "When the host (Linux/Driver) sends the PME_TURN_OFF message it should
> wait for PME_TO_ACK from the device. Microsoft Windows versions
> typically wait for 5 seconds."
> 
> This is the reason for why I added 5s for timeout.

Huh, good find. Seems like something that could go in either the commit
message or the comments.

FWIW, that bug report seems to also be related to the question at hand
-- how to handle L2 link state entry. That bug notes that Linux "doesn't
wait for PME_TO_ACK from the device", but AFAICT, Linux PCI drivers
don't typically send PME_TURN_OFF at all.

So right now, we're just relying on our platform suspend code like this.
It'd be interesting to know if other root complexes had programmable
Message Request support like this available to the host CPU, or if they
all have something hardcoded into their BIOS/ACPI support or something
(or just don't use PME_TURN_OFF at all).

Anyway, I guess that's just a future-work question, in case we want to
consolidate support like this into the PCI core framework.

Brian

  reply	other threads:[~2016-11-23  4:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-23  1:19 [PATCH 1/3] PCI: rockchip: split out rockchip_cfg_atu Shawn Lin
2016-11-23  1:19 ` [PATCH 2/3] PCI: rockchip: move the deassert of pm/aclk/pclk after phy_init Shawn Lin
2016-11-23  1:19 ` [PATCH 3/3] PCI: rockchip: Add system PM support Shawn Lin
2016-11-23  2:08   ` Brian Norris
2016-11-23  2:39     ` Shawn Lin
2016-11-23  2:45       ` Brian Norris
2016-11-23  2:51         ` Shawn Lin
2016-11-23  4:56           ` Brian Norris [this message]
2016-11-23  1:59 ` [PATCH 1/3] PCI: rockchip: split out rockchip_cfg_atu Brian Norris
2016-11-23  2:15   ` Shawn Lin
2016-11-23  2:29     ` Brian Norris
2016-11-23  2:33       ` Shawn Lin

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=20161123045658.GB28948@google.com \
    --to=briannorris@chromium.org \
    --cc=bhelgaas@google.com \
    --cc=jeffy.chen@rock-chips.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=shawn.lin@rock-chips.com \
    --cc=wenrui.li@rock-chips.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).