All of lore.kernel.org
 help / color / mirror / Atom feed
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

WARNING: multiple messages have this Message-ID (diff)
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

  parent reply	other threads:[~2018-09-07 15:05 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
     [not found]   ` <3b37e4fd-c793-bd52-7d70-950f846a7d5a-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2018-09-07  8:06     ` Daniel Drake
2018-09-07  8:06       ` Daniel Drake
     [not found] ` <20180907053614.6540-1-drake-6IF/jdPJHihWk0Htik3J/w@public.gmane.org>
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-10 19:57   ` Thomas Martitz
2018-09-10 19:57     ` Thomas Martitz
2018-09-07 21:48 ` Bjorn Helgaas

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-vtkqydcbqhk7dlmcbjsq7g@public.gmane.org \
    --cc=andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
    --cc=drake-6IF/jdPJHihWk0Htik3J/w@public.gmane.org \
    --cc=hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=jonathan.derrick-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=linux-6IF/jdPJHihWk0Htik3J/w@public.gmane.org \
    --cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org \
    --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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.