From: Peter Wu <peter@lekensteyn.nl>
To: Daniel Drake <drake@endlessm.com>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
linux@endlessm.com, nouveau@lists.freedesktop.org,
linux-pm@vger.kernel.org, kherbst@redhat.com,
andriy.shevchenko@linux.intel.com, rafael.j.wysocki@intel.com,
keith.busch@intel.com, mika.westerberg@linux.intel.com,
jonathan.derrick@intel.com, kugel@rockbox.org,
davem@davemloft.net, hkallweit1@gmail.com,
netdev@vger.kernel.org, nic_swsd@realtek.com
Subject: Re: [PATCH] PCI: Reprogram bridge prefetch registers on resume
Date: Fri, 7 Sep 2018 17:05:15 +0200 [thread overview]
Message-ID: <20180907150515.GA28739@al> (raw)
In-Reply-To: <20180907053614.6540-1-drake@endlessm.com>
On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote:
<..>
> Thomas Martitz reports that this workaround also solves an issue where
> the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive
> after S3 suspend/resume.
Where was this claimed? It is not stated in the linked bug:
(https://bugs.freedesktop.org/show_bug.cgi?id=105760
> On resume, reprogram the PCI bridge prefetch registers, including the
> magic register mentioned above.
>
> This matches Win10 behaviour, which also rewrites these registers
> during S3 resume (checked with qemu tracing).
Windows 10 unconditionally rewrites these registers (BAR, I/O Base +
Limit, Memory Base + Limit, etc. from top to bottom), see annotations:
https://www.spinics.net/lists/linux-pci/msg75856.html
Linux has a generic "restore" operation that works backwards from the
end of the PCI config space to the beginning, see
pci_restore_config_space. Do you have a dmesg where you see the
"restoring config space at offset" messages?
Would it be reasonable to unconditionally write these registers in
pci_restore_config_dword, like Windows does?
Kind regards,
Peter
WARNING: multiple messages have this Message-ID (diff)
From: Peter Wu <peter-VTkQYDcBqhK7DlmcbJSQ7g@public.gmane.org>
To: Daniel Drake <drake-6IF/jdPJHihWk0Htik3J/w@public.gmane.org>
Cc: mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org,
keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
linux-6IF/jdPJHihWk0Htik3J/w@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
jonathan.derrick-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Subject: Re: [PATCH] PCI: Reprogram bridge prefetch registers on resume
Date: Fri, 7 Sep 2018 17:05:15 +0200 [thread overview]
Message-ID: <20180907150515.GA28739@al> (raw)
In-Reply-To: <20180907053614.6540-1-drake-6IF/jdPJHihWk0Htik3J/w@public.gmane.org>
On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote:
<..>
> Thomas Martitz reports that this workaround also solves an issue where
> the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive
> after S3 suspend/resume.
Where was this claimed? It is not stated in the linked bug:
(https://bugs.freedesktop.org/show_bug.cgi?id=105760
> On resume, reprogram the PCI bridge prefetch registers, including the
> magic register mentioned above.
>
> This matches Win10 behaviour, which also rewrites these registers
> during S3 resume (checked with qemu tracing).
Windows 10 unconditionally rewrites these registers (BAR, I/O Base +
Limit, Memory Base + Limit, etc. from top to bottom), see annotations:
https://www.spinics.net/lists/linux-pci/msg75856.html
Linux has a generic "restore" operation that works backwards from the
end of the PCI config space to the beginning, see
pci_restore_config_space. Do you have a dmesg where you see the
"restoring config space at offset" messages?
Would it be reasonable to unconditionally write these registers in
pci_restore_config_dword, like Windows does?
Kind regards,
Peter
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
next prev parent reply other threads:[~2018-09-07 19:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-07 5:36 [PATCH] PCI: Reprogram bridge prefetch registers on resume Daniel Drake
2018-09-07 5:36 ` Daniel Drake
2018-09-07 5:49 ` [Nouveau] " Lukas Wunner
2018-09-07 6:40 ` Sinan Kaya
2018-09-07 8:06 ` Daniel Drake
2018-09-07 8:06 ` Daniel Drake
2018-09-07 15:05 ` Peter Wu [this message]
2018-09-07 15:05 ` Peter Wu
2018-09-07 22:26 ` Bjorn Helgaas
2018-09-08 12:14 ` Peter Wu
2018-09-08 11:05 ` Thomas Martitz
2018-09-08 11:05 ` Thomas Martitz
2018-09-11 3:35 ` Daniel Drake
2018-09-11 3:35 ` Daniel Drake
2018-09-11 9:08 ` Rafael J. Wysocki
2018-09-07 21:48 ` Bjorn Helgaas
2018-09-10 19:57 ` Thomas Martitz
2018-09-10 19:57 ` Thomas Martitz
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=20180907150515.GA28739@al \
--to=peter@lekensteyn.nl \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=davem@davemloft.net \
--cc=drake@endlessm.com \
--cc=hkallweit1@gmail.com \
--cc=jonathan.derrick@intel.com \
--cc=keith.busch@intel.com \
--cc=kherbst@redhat.com \
--cc=kugel@rockbox.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@endlessm.com \
--cc=mika.westerberg@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
--cc=nouveau@lists.freedesktop.org \
--cc=rafael.j.wysocki@intel.com \
/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.