在 2016/11/23 10:45, Brian Norris 写道:
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.
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.
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
--
Best Regards
Shawn Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
