From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>, Lukas Wunner <lukas@wunner.de>,
Keith Busch <keith.busch@intel.com>,
Alex Williamson <alex.williamson@redhat.com>,
Alexandru Gagniuc <mr.nuke.me@gmail.com>,
Kai-Heng Feng <kai.heng.feng@canonical.com>,
Paul Menzel <pmenzel@molgen.mpg.de>,
Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] PCI: Add missing link delays required by the PCIe spec
Date: Tue, 5 Nov 2019 11:54:28 +0200 [thread overview]
Message-ID: <20191105095428.GR2552@lahna.fi.intel.com> (raw)
In-Reply-To: <20191105000000.GA126282@google.com>
On Mon, Nov 04, 2019 at 06:00:00PM -0600, Bjorn Helgaas wrote:
> > > > > The outline of the pci_pm_resume_noirq() part of this patch is:
> > > > >
> > > > > pci_pm_resume_noirq
> > > > > if (!dev->skip_bus_pm ...) # <-- condition 1
> > > > > pci_pm_default_resume_early
> > > > > pci_power_up
> > > > > if (platform_pci_power_manageable()) # _PS0 or _PR0 exist?
> > > > > platform_pci_set_power_state
> > > > > pci_platform_pm->set_state
> > > > > acpi_pci_set_power_state(PCI_D0) # acpi_pci_platform_pm.set_state
> > > > > acpi_device_set_power(ACPI_STATE_D0) # <-- eval _PS0
> > > > > + if (d3cold) # <-- condition 2
> > > > > + pci_bridge_wait_for_secondary_bus
>
> > The reason why pci_bridge_wait_for_secondary_bus() is called almost the
> > last is that I figured we want to resume the root/downstream port
> > completely first before we start delaying for the device downstream.
>
> For understandability, I think the wait needs to go in some function
> that contains "PCI_D0", e.g., platform_pci_set_power_state() or
> pci_power_up(), so it's connected with the transition from D3cold to
> D0.
>
> Since pci_pm_default_resume_early() is the only caller of
> pci_power_up(), maybe we should just inline pci_power_up(), e.g.,
> something like this:
>
> static void pci_pm_default_resume_early(struct pci_dev *pci_dev)
> {
> pci_power_state_t prev_state = pci_dev->current_state;
>
> if (platform_pci_power_manageable(pci_dev))
> platform_pci_set_power_state(pci_dev, PCI_D0);
>
> pci_raw_set_power_state(pci_dev, PCI_D0);
> pci_update_current_state(pci_dev, PCI_D0);
>
> pci_restore_state(pci_dev);
> pci_pme_restore(pci_dev);
>
> if (prev_state == PCI_D3cold)
> pci_bridge_wait_for_secondary_bus(dev);
> }
OK, I'll see if this works.
> I don't understand why we call both platform_pci_set_power_state() and
> pci_raw_set_power_state().
platform_pci_set_power_state() deals with the ACPI methods such as
calling _PS0 after D3hot. To transition the device from D3hot to D0 you
need the PMCSR write which is done in pci_raw_set_power_state().
> I thought platform_pci_set_power_state()
> should put the device in D0, so we shouldn't need the PCI_PM_CTRL
> update in pci_raw_set_power_state(), although we probably do need
> things like pci_restore_bars() and pcie_aspm_pm_state_change().
>
> And in fact, it seems wrong that if platform_pci_set_power_state()
> puts the device in D0 and the device lacks a PM capability, we bail
> out of pci_raw_set_power_state() before calling pci_restore_bars().
>
> Tangent: I think "pci_pm_default_resume_early" is the wrong name for
> this because "default" suggests that this is what we fall back to if a
> driver or arch doesn't supply a more specific method. But here we're
> doing mandatory things that cannot be overridden, so I think something
> like "pci_pm_core_resume_early()" would be more accurate.
>
> > Need to call it before port services (pciehp) is resumed, though.
>
> I guess this is because pciehp_resume() looks at PCI_EXP_LNKSTA and
> will be confused if the link isn't up yet?
Yes.
> > If you think it is fine to do the delay before we have restored
> > everything I can move it inside pci_power_up() or call it after
> > pci_pm_default_resume_early() as above. I think at least we should make
> > sure all the saved registers are restored before so that the link
> > activation check actually works.
>
> What needs to be restored to make pcie_wait_for_link_delay() work?
I'm not entirely sure. I think that pci_restore_state() at least should
be called so that the PCIe capability gets restored. Maybe not event
that because Data Link Layer Layer Active always reflects the DL_Active
or not and it does not need to be enabled separately.
> And what event does the restore need to be ordered with?
Not sure I follow you here.
next prev parent reply other threads:[~2019-11-05 9:54 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-04 12:39 [PATCH v2 0/2] PCI: Add missing link delays Mika Westerberg
2019-10-04 12:39 ` [PATCH v2 1/2] PCI: Introduce pcie_wait_for_link_delay() Mika Westerberg
2020-08-08 20:22 ` Marc MERLIN
2020-08-08 20:23 ` Marc MERLIN
2020-08-09 16:31 ` Marc MERLIN
2020-09-06 18:18 ` pcieport 0000:00:01.0: PME: Spurious native interrupt (nvidia with nouveau and thunderbolt on thinkpad P73) Marc MERLIN
2020-09-06 18:26 ` Matthias Andree
2020-09-07 19:14 ` [Nouveau] " Karol Herbst
2020-09-07 20:58 ` Marc MERLIN
2020-09-07 23:51 ` Karol Herbst
2020-09-08 0:29 ` Marc MERLIN
2020-09-13 20:15 ` Marc MERLIN
[not found] ` <20200529180315.GA18804@merlins.org>
2020-12-26 11:12 ` 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile) Marc MERLIN
2020-12-27 18:28 ` [Nouveau] " Ilia Mirkin
2021-01-27 21:33 ` Bjorn Helgaas
2021-01-28 20:59 ` Bjorn Helgaas
2021-01-29 0:56 ` Marc MERLIN
2021-01-29 21:20 ` Bjorn Helgaas
2021-01-30 2:04 ` Marc MERLIN
2020-12-29 15:51 ` Marc MERLIN
2020-12-29 16:33 ` Ilia Mirkin
2019-10-04 12:39 ` [PATCH v2 2/2] PCI: Add missing link delays required by the PCIe spec Mika Westerberg
2019-10-26 14:19 ` Bjorn Helgaas
2019-10-28 11:28 ` Mika Westerberg
2019-10-28 13:42 ` Bjorn Helgaas
2019-10-28 18:06 ` Mika Westerberg
2019-10-28 20:16 ` Bjorn Helgaas
2019-10-29 11:15 ` Mika Westerberg
2019-10-29 20:27 ` Bjorn Helgaas
2019-10-30 11:15 ` Mika Westerberg
2019-10-31 22:31 ` Bjorn Helgaas
2019-11-01 11:19 ` Mika Westerberg
2019-11-05 0:00 ` Bjorn Helgaas
2019-11-05 9:54 ` Mika Westerberg [this message]
2019-11-05 12:58 ` Mika Westerberg
2019-11-05 20:01 ` Bjorn Helgaas
2019-11-06 13:31 ` Mika Westerberg
2019-11-05 15:00 ` Bjorn Helgaas
2019-11-05 15:28 ` Mika Westerberg
2019-11-05 16:10 ` Bjorn Helgaas
2019-11-06 13:29 ` Mika Westerberg
2019-10-29 20:54 ` Bjorn Helgaas
2019-10-30 11:33 ` Mika Westerberg
2019-10-04 12:57 ` [PATCH v2 0/2] PCI: Add missing link delays Matthias Andree
2019-10-04 13:06 ` Mika Westerberg
2019-10-05 7:34 ` Matthias Andree
2019-10-07 9:32 ` Mika Westerberg
2019-10-07 15:15 ` Matthias Andree
2019-10-08 9:05 ` Mika Westerberg
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=20191105095428.GR2552@lahna.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=alex.williamson@redhat.com \
--cc=helgaas@kernel.org \
--cc=kai.heng.feng@canonical.com \
--cc=keith.busch@intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mr.nuke.me@gmail.com \
--cc=nicholas.johnson-opensource@outlook.com.au \
--cc=pmenzel@molgen.mpg.de \
--cc=rjw@rjwysocki.net \
/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
Powered by JetHome