All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Linux PCI <linux-pci@vger.kernel.org>
Subject: Re: [PATCH 1/7] PCI: Restore BARs on runtime resume despite being unbound
Date: Sat, 24 Feb 2018 17:26:04 +0100	[thread overview]
Message-ID: <20180224162604.GA25961@wunner.de> (raw)
In-Reply-To: <CAJZ5v0h+qipaKKDxxFFpkwUKgMjnoaUB8_p+FRDb+fSM_v+wBw@mail.gmail.com>

[trimming cc a bit to avoid spamming folks likely uninterested in PCI PM
intricacies]

On Wed, Feb 21, 2018 at 10:57:14AM +0100, Rafael J. Wysocki wrote:
> On Tue, Feb 20, 2018 at 10:29 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote:
> > > --- a/drivers/pci/pci-driver.c
> > > +++ b/drivers/pci/pci-driver.c
> > > @@ -1277,10 +1277,14 @@ static int pci_pm_runtime_resume(struct device *dev)
> > >
> > >       /*
> > >        * If pci_dev->driver is not set (unbound), the device should
> > > -      * always remain in D0 regardless of the runtime PM status
> > > +      * always remain in D0 regardless of the runtime PM status.
> > > +      * But if its parent can go to D3cold, this device may have
> > > +      * been in D3cold as well and require restoration of its BARs.
> > >        */
> > > -     if (!pci_dev->driver)
> > > +     if (!pci_dev->driver) {
> > > +             pci_restore_bars(pci_dev);
> >
> > If we do decide not to do a full-blown restore, how do we decide
> > whether to use pci_restore_bars() or pci_restore_config_space()?
> >
> > I'm not sure why we have both.
> 
> Me neither.

pci_restore_config_space() configures the BARs from saved_config_space[]
in struct pci_dev.  This array needs to have been populated beforehand.
If it's never been populated, the function can't be used.  The sole
caller of that function, pci_restore_state(), therefore checks whether
the state_saved bit in stuct pci_dev is true.

According to the code comment in the sole caller of pci_restore_bars(),
pci_raw_set_power_state(), there are systems where device are in D3hot
on boot.  Moreover devices where the No_Soft_Reset bit is 0 are in
D0uninitialized when coming out of D3hot.

For those devices, pci_restore_bars() is called to configure the BARs
from resource[] in struct pci_dev, which was populated on bus scan.
pci_restore_config_space() can't be used here because the first time
the devices are brought into D0, saved_config_space[] hasn't been
populated yet.  It's normally only populated when the device is suspended.

It might be possible to replace the invocation of pci_restore_bars()
with pci_restore_state() if pci_save_state() is called on bus scan for
devices in D3hot whose No_Soft_Reset bit is 0.

An alternative approach would be to avoid storing BARs in
saved_config_space[], and modify pci_restore_config_space() to restore
those from resource[].  That would save 24 bytes in struct pci_dev.
But it would only work if the BARs are always in sync with resource[],
I'm not sure if there are situations when this isn't the case.

Thanks,

Lukas

  parent reply	other threads:[~2018-02-24 16:26 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-18  8:38 [PATCH 0/7] Modernize vga_switcheroo by using device link for HDA Lukas Wunner
2018-02-18  8:38 ` Lukas Wunner
2018-02-18  8:38 ` [PATCH 6/7] vga_switcheroo: Let HDA autosuspend on mux change Lukas Wunner
     [not found] ` <cover.1518941072.git.lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2018-02-18  8:38   ` [PATCH 1/7] PCI: Restore BARs on runtime resume despite being unbound Lukas Wunner
2018-02-18  8:38     ` Lukas Wunner
     [not found]     ` <f7593132608eb9a83d7268cc5b3ef12b3dd9c52d.1518941073.git.lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2018-02-19  9:49       ` Rafael J. Wysocki
2018-02-19  9:49         ` Rafael J. Wysocki
2018-02-20 21:29     ` Bjorn Helgaas
2018-02-20 21:29       ` Bjorn Helgaas
     [not found]       ` <20180220212922.GC32228-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
2018-02-21  9:57         ` Rafael J. Wysocki
2018-02-21  9:57           ` Rafael J. Wysocki
2018-02-21 12:39           ` Rafael J. Wysocki
2018-02-21 12:39             ` Rafael J. Wysocki
2018-02-25  8:59             ` Lukas Wunner
2018-02-25  8:59               ` Lukas Wunner
2018-02-25  9:31               ` Takashi Iwai
2018-02-25  9:31                 ` Takashi Iwai
2018-02-24 16:26           ` Lukas Wunner [this message]
2018-02-18  8:38 ` [PATCH 5/7] vga_switcheroo: Use device link for HDA controller Lukas Wunner
     [not found]   ` <99358da18f1c61b226678c7c70240e4407ac575b.1518941073.git.lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2018-02-20 22:20     ` Bjorn Helgaas
2018-02-20 22:20       ` Bjorn Helgaas
     [not found]       ` <20180220222059.GD32228-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
2018-02-23  9:51         ` Lukas Wunner
2018-02-23  9:51           ` Lukas Wunner
     [not found]           ` <20180223095147.GB17092-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2018-02-23 14:23             ` Bjorn Helgaas
2018-02-23 14:23               ` Bjorn Helgaas
2018-02-18  8:38 ` [PATCH 3/7] vga_switcheroo: Update PCI current_state on power change Lukas Wunner
2018-02-18  8:38 ` [PATCH 7/7] drm/nouveau: Runtime suspend despite HDA being unbound Lukas Wunner
2018-02-18  8:38 ` [PATCH 4/7] vga_switcheroo: Deduplicate power state tracking Lukas Wunner
2018-02-18  8:38 ` [PATCH 2/7] PCI: Make pci_wakeup_bus() & pci_bus_set_current_state() public Lukas Wunner
     [not found]   ` <9d36522bc3d7e0ed1c1d5f653514d9fb0d34c0a8.1518941073.git.lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2018-02-22 17:45     ` Bjorn Helgaas
2018-02-22 17:45       ` Bjorn Helgaas
2018-02-25 23:24 ` [PATCH 0/7] Modernize vga_switcheroo by using device link for HDA Mike Lothian
2018-02-25 23:24   ` Mike Lothian

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=20180224162604.GA25961@wunner.de \
    --to=lukas@wunner.de \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.