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
--
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
