Re: [PATCH v2 4/4] PCI: Add runtime PM support for PCIe ports

[Lukas Wunner <lukas@wunner.de>]

Hi Mika,

I'm working on runtime pm for Thunderbolt on the Mac and your patches
directly impact that. A Thunderbolt controller comprises an upstream
bridge plus multiple downstream bridges below it, the latter are the
actual hotplug ports. I'm using my own runtime pm code for the PCIe
ports at the moment but will rebase on your patches once they're
finalised.

I've just pushed v2 of my patches to GitHub, this is nearly finished,
just needs some more polish before I can post it:
https://github.com/l1k/linux/commits/thunderbolt_runpm_v2

First of all, the root port on my 2012 Ivy Bridge machine suspends to
D3hot just fine, as do the upstream and downstream ports on the 2010
"Light Ridge" Thunderbolt controller. So the 2015 cut-off in patch [2/4]
seems extremely conservative to me, perhaps unnecessarily so. At least
you've made it possible to override that by setting bridge_d3 = true,
however I'd be happier if this could be extended further back, say,
to 2010. That way it would encompass all Macs with Thunderbolt.

Secondly, you're disabling runtime pm on hotplug ports, citing a
bugzilla entry as an example why this is necessary, however there's
a patch attached to that bugzilla entry which fixes the issue:
https://bugzilla.kernel.org/show_bug.cgi?id=53811

It is therefore unclear why you're disabling it. This breaks my
patches and you've not provided a way to selectively re-enable
runtime pm for specific hotplug ports.

FWIW I've had zero issues suspending the hotplug ports on the Light
Ridge Thunderbolt controller. Hotplug detection works fine even in
D3hot, all that is necessary is to resume the port on hotplug and
unplug while we access the hotplugged device's config space.

So it looks like a hotplug port should be *allowed* to suspend,
but its parent ports (by default) should *not* as we wouldn't be
able to access the hotplug port's config space anymore. On the Mac
even the parent ports may suspend because there's a separate GPE
provided which fires on hotplug during D3cold. Just disabling
runtime pm *generally* on all hotplug ports is too strict.

The changes required for pciehp to work with runtime suspended ports
are apparent from the following patch, I can spin them out into a
separate commit if you would like to include them in your series:
https://github.com/l1k/linux/commit/97d1140926670e6498f6671d91201e6d66e78680


> +static int pcie_port_runtime_idle(struct device *dev)
> +{
> +	struct pci_dev *pdev = to_pci_dev(dev);
> +
> +	/*
> +	 * Rely the PCI core has set bridge_d3 whenever it thinks the port
> +	 * should be good to go to D3. Everything else, including moving
> +	 * the port to D3, is handled by the PCI core.
> +	 */
> +	if (pdev->bridge_d3) {
> +		pm_schedule_suspend(dev, 10);
> +		return 0;
> +	}
> +	return -EBUSY;
> +}

It's unclear why the pm_schedule_suspend() is needed here and what the
10 ms delay is for. I don't have that delay in my runtime pm code and
haven't seen any issues. If the delay is needed then I'm wondering why
this isn't implemented using autosuspend?


> +static bool pcie_port_runtime_pm_possible(struct pci_dev *pdev)
> +{
> +	/*
> +	 * Only enable runtime PM if the PCI core agrees that this port can
> +	 * even go to D3.
> +	 */
> +	if (!pdev->bridge_d3)
> +		return false;
> +
> +	/*
> +	 * Prevent runtime PM if the port is hotplug capable. Otherwise the
> +	 * hotplug SMI code might not be able to enumerate devices behind
> +	 * this port properly (the port is powered down preventing all
> +	 * config space accesses to the subordinate devices).
> +	 */
> +	if (pcie_caps_reg(pdev) & PCI_EXP_FLAGS_SLOT) {
> +		u32 sltcap;
> +
> +		pcie_capability_read_dword(pdev, PCI_EXP_SLTCAP, &sltcap);
> +		if (sltcap & (PCI_EXP_SLTCAP_HPC | PCI_EXP_SLTCAP_HPS))
> +			return false;
> +	}
> +
> +	return true;
> +}

Why do you re-read the register here, seems like just checking
pdev->hotplug_bridge should be sufficient?


>  static void pcie_portdrv_remove(struct pci_dev *dev)
>  {
> +	const struct pcie_port_data *pdata = pci_get_drvdata(dev);
> +
> +	if (pdata->runtime_pm_enabled) {
> +		pm_runtime_forbid(&dev->dev);
> +		pm_runtime_get_noresume(&dev->dev);
> +	}
> +
>  	pcie_port_device_remove(dev);
>  }

I think you're missing a pci_set_drvdata(dev, NULL) here.


In my runtime pm code I've set pm_runtime_no_callbacks() for the port
service devices to prevent users from mucking around with their sysfs
files. Feel free to copy that from the above-linked patch if you want.

Best regards,

Lukas