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 18:45:34 -0800 [thread overview]
Message-ID: <20161123024527.GA18020@google.com> (raw)
In-Reply-To: <1c4bd848-67f7-0d31-6392-d9550e4767a9@rock-chips.com>
On Wed, Nov 23, 2016 at 10:39:30AM +0800, Shawn Lin wrote:
> 在 2016/11/23 10:08, Brian Norris 写道:
> >On Wed, Nov 23, 2016 at 09:19:13AM +0800, Shawn Lin wrote:
> >>diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> >>index 71d056d..720535b 100644
> >>--- a/drivers/pci/host/pcie-rockchip.c
> >>+++ b/drivers/pci/host/pcie-rockchip.c
...
> >>+static int rockchip_pcie_wait_l2(struct rockchip_pcie *rockchip)
> >>+{
> >>+ u32 value;
> >>+ int err;
> >>+
> >>+ /* send PME_TURN_OFF message */
> >>+ writel(0x0, rockchip->msg_region + PCIE_RC_SEND_PME_OFF);
> >>+
> >>+ /* read LTSSM and wait for falling into L2 link state */
> >>+ err = readl_poll_timeout(rockchip->apb_base + PCIE_CLIENT_DEBUG_OUT_0,
> >>+ value, PCIE_LINK_IS_L2(value), 20,
> >>+ jiffies_to_usecs(5 * HZ));
> >
> >You really want to wait a whole 5 seconds for this? Last I saw, you were
> >doing testing with about 500ms or less. As I read the spec, there's cap
> >on per-device time to ACK the request, and I recall that was on the
> >order of 10s of milliseconds. But technically that can add up if you
> >have a large hierarchy of devices attached...
> >
>
> I have no very clear thought about how long we should set up the
> timeout for PME_ACK. As you point out that a large hierarchy of devices
> need quite a long time I guess.
>
> A possible work for PCIe core is walk through the hierarchy of devices
> and calculate the max ACK timeout(including the latency of HUB).. But
> I guess ACPI-base platforms don't need linux-pci to handle L2 stuff at
> S3 at all, instead it will be handled by firmware, so still I don't
> know how they will calculate it.
I'm not sure if that's necessary. I was just curious on how this got
determined, when it seemed that 500ms was plenty.
We shouldn't be hitting this (and if we do, then that means we'd
probably need to reassess anyway), so maybe "too large" is fine.
Brian
next prev parent reply other threads:[~2016-11-23 2:45 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 [this message]
2016-11-23 2:51 ` Shawn Lin
2016-11-23 4:56 ` Brian Norris
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=20161123024527.GA18020@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).