| Message ID | 1646658319-59532-1-git-send-email-Sanju.Mehta@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | thunderbolt: handle runtime pm for tunnelled pci root port | expand |
Hi Sanjay, On Mon, Mar 07, 2022 at 07:05:19AM -0600, Sanjay R Mehta wrote: > From: Sanjay R Mehta <sanju.mehta@amd.com> > > Carry out runtime-resume of PCI tunnelled root port to handle > hotplug interrupts synchronously. What problem does this solve? Typically the root ports should be able to wake from D3 when the PCIe tunnel gets established. Is it not the case here?
On 3/7/2022 7:05 PM, Mika Westerberg wrote: > Hi Sanjay, > > On Mon, Mar 07, 2022 at 07:05:19AM -0600, Sanjay R Mehta wrote: >> From: Sanjay R Mehta <sanju.mehta@amd.com> >> >> Carry out runtime-resume of PCI tunnelled root port to handle >> hotplug interrupts synchronously. > > What problem does this solve? > > Typically the root ports should be able to wake from D3 when the PCIe > tunnel gets established. Is it not the case here? Yes Mika, its not waking from D3 in this case on our hardware. Hence I have kept a check to execute this code only if root port still in D3 after PCIe tunnel is setup. Do you think should this patch go as a quirk?
Hi, On Mon, Mar 07, 2022 at 08:00:46PM +0530, Sanjay R Mehta wrote: > > > On 3/7/2022 7:05 PM, Mika Westerberg wrote: > > Hi Sanjay, > > > > On Mon, Mar 07, 2022 at 07:05:19AM -0600, Sanjay R Mehta wrote: > >> From: Sanjay R Mehta <sanju.mehta@amd.com> > >> > >> Carry out runtime-resume of PCI tunnelled root port to handle > >> hotplug interrupts synchronously. > > > > What problem does this solve? > > > > Typically the root ports should be able to wake from D3 when the PCIe > > tunnel gets established. Is it not the case here? > > Yes Mika, its not waking from D3 in this case on our hardware. > > Hence I have kept a check to execute this code only if root port still > in D3 after PCIe tunnel is setup. OK, I see. > Do you think should this patch go as a quirk? I think in that case we should prevent the port from entering D3. Does it have the ACPI "HotPlugSupportInD3" property: https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-pcie-root-ports-supporting-hot-plug-in-d3 If yes, then simply removing that should work.
diff --git a/drivers/thunderbolt/acpi.c b/drivers/thunderbolt/acpi.c index 79b5abf..10dd61b 100644 --- a/drivers/thunderbolt/acpi.c +++ b/drivers/thunderbolt/acpi.c @@ -96,6 +96,9 @@ static acpi_status tb_acpi_add_link(acpi_handle handle, u32 level, void *data, dev_name(&pdev->dev)); } + pm_runtime_set_autosuspend_delay(&pdev->dev, TB_AUTOSUSPEND_DELAY); + pm_runtime_use_autosuspend(&pdev->dev); + pm_runtime_mark_last_busy(&pdev->dev); pm_runtime_put(&pdev->dev); } diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c index cbd0ad8..2a53fa6 100644 --- a/drivers/thunderbolt/tb.c +++ b/drivers/thunderbolt/tb.c @@ -1066,6 +1066,7 @@ static int tb_tunnel_pci(struct tb *tb, struct tb_switch *sw) struct tb_cm *tcm = tb_priv(tb); struct tb_switch *parent_sw; struct tb_tunnel *tunnel; + struct device_link *link; up = tb_switch_find_port(sw, TB_TYPE_PCIE_UP); if (!up) @@ -1099,6 +1100,16 @@ static int tb_tunnel_pci(struct tb *tb, struct tb_switch *sw) if (tb_switch_pcie_l1_enable(sw)) tb_sw_warn(sw, "failed to enable PCIe L1 for Titan Ridge\n"); + list_for_each_entry(link, &tb->nhi->pdev->dev.links.consumers, s_node) { + if (pci_pcie_type(to_pci_dev(link->consumer)) == PCI_EXP_TYPE_ROOT_PORT) { + if (pm_runtime_status_suspended(link->consumer)) { + pm_runtime_get_sync(link->consumer); + pm_runtime_mark_last_busy(link->consumer); + pm_runtime_put_sync_autosuspend(link->consumer); + } + } + } + list_add_tail(&tunnel->list, &tcm->tunnel_list); return 0; }