lso
> > fix the issue that was worked around in commit 7c53a722459c ("r8169:
> > don't use MSI-X on RTL8168g").
> >
> > Thomas Martitz reports that this change also solves an issue where
> > the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive
>
On Wed, Sep 12, 2018 at 02:45:23PM +0800, Daniel Drake wrote:
> On 38+ Intel-based Asus products, the nvidia GPU becomes unusable
> after S3 suspend/resume. The affected products include multiple
> generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs
> many errors such as:
>
>
On Fri, Sep 07, 2018 at 05:26:47PM -0500, Bjorn Helgaas wrote:
> [+cc LKML, Dave, Luming]
>
> On Fri, Sep 07, 2018 at 05:05:15PM +0200, Peter Wu wrote:
> > On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote:
> > <..>
> > > Thomas Martitz reports that
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:
On Wed, Sep 05, 2018 at 02:26:51PM +0800, Daniel Drake wrote:
> On Tue, Aug 28, 2018 at 5:57 PM, Peter Wu wrote:
> > Only non-bridge devices can be passed to a guest, but perhaps logging
> > access to the emulated bridge is already sufficient. The Prefetchable
> > Base U
On Thu, Aug 30, 2018 at 03:41:43PM +0800, Daniel Drake wrote:
> On Tue, Aug 28, 2018 at 5:57 PM, Peter Wu wrote:
> > Just to be sure, after "sleep", do both devices report "suspended" in
> > /sys/bus/pci/devices/:00:1c.0/power/runtime_status
> >
On Tue, Aug 28, 2018 at 10:23:24AM +0800, Daniel Drake wrote:
> On Fri, Aug 24, 2018 at 11:42 PM, Peter Wu wrote:
> > Are these systems also affected through runtime power management? For
> > example:
> >
> > modprobe nouveau# should enable runtime PM
> &g
press
Link Control and more, but applying these changes were so far not really
successful.
Some supporting files for that investigation are here:
https://github.com/Lekensteyn/acpi-stuff/tree/master/d3test
Karol noticed that by not setting the State in PMCSR to D3 for the
Nvidia GPU during runtim
audio function (see also nouveau
bug https://bugs.freedesktop.org/show_bug.cgi?id=75985) so most of the
above issues should not occur.
Hope it helps, and if desired you can add:
Tested-by: Peter Wu <pe...@lekensteyn.nl>
For the following patches, you can also add my Reviewed-by:
vga_
It is already available (I have that dGPU myself). Newer kernels are
recommended (Linux 4.8+), you need either xf86-video-modesetting driver (known
working with xorg 1.18) or xf86-video-nouveau (from git).
Also note that many laptops with these card suffer from a problem that cause
lockups
-37,6 +37,8 @@
> * - implemented limited ABI16/NVIF interop
> */
>
> +#include
> +
> #include
> #include
> #include
> @@ -161,6 +163,10 @@ struct nouveau_drm {
> struct nvbios vbios;
> struct nouveau_display *display;
> struct backlight_device *backlight;
> +#ifdef CONFIG_ACPI
> + struct notifier_block acpi_nb;
> + struct work_struct acpi_work;
> +#endif
>
> /* power management */
> struct nouveau_hwmon *hwmon;
> --
> 2.9.3
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
]
So indeed we can be sure that the device is runtime-resumed before
suspend. System resume is not documented explicitly, but it seems
reasonable that the device is not runtime-suspended between system
suspend and resume.
Reviewed-by: Peter Wu <pe...@lekensteyn.nl>
> ---
> drivers/gpu
On Fri, Nov 04, 2016 at 06:36:17PM +0900, Alexandre Courbot wrote:
> Look for firmware files using the legacy ("nouveau/nvxx_fuc") path
> if they cannot be found in the new, "official" path. User setups were
> broken by the switch, which is bad.
>
> There are only 4 firmware files we may want
On Tue, Nov 01, 2016 at 09:24:23AM -0400, Alex Deucher wrote:
> On Tue, Nov 1, 2016 at 12:55 AM, Dave Airlie <airl...@gmail.com> wrote:
> > On 1 November 2016 at 08:48, Peter Wu <pe...@lekensteyn.nl> wrote:
> >> Check whether the kernel really supports power resource
esktop.org/show_bug.cgi?id=98398
Reported-and-tested-by: Rick Kerkhof <rick.2...@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
---
v2: collected tags from Rick and Mika; added ACPICA note as requested b
hu, Oct 27, 2016 at 06:06:48PM +0200, Peter Wu wrote:
> > > On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote:
> > > > On Thu, Oct 27, 2016 at 09:42:28AM +, Rick Kerkhof wrote:
> > > > >No, there are not. Here is the recursive directory list
uveau/acpi: fix lockup with PCIe runtime PM")
Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
---
Hi,
Maybe Cc: stable (4.8+)?
Compile-tested only. Rick, can you test if this patch fixes the problem for you?
This check was actually in the original patch, but it was changed:
https://lists
On Fri, Oct 28, 2016 at 02:19:07PM +0300, Mika Westerberg wrote:
> On Fri, Oct 28, 2016 at 01:09:30PM +0200, Peter Wu wrote:
> > On Fri, Oct 28, 2016 at 11:56:30AM +0300, Mika Westerberg wrote:
> > > On Thu, Oct 27, 2016 at 06:06:48PM +0200, Peter Wu wrote:
> > > >
On Fri, Oct 28, 2016 at 11:56:30AM +0300, Mika Westerberg wrote:
> On Thu, Oct 27, 2016 at 06:06:48PM +0200, Peter Wu wrote:
> > On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote:
> > > On Thu, Oct 27, 2016 at 09:42:28AM +, Rick Kerkhof wrote:
> > > &
On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote:
> On Thu, Oct 27, 2016 at 09:42:28AM +, Rick Kerkhof wrote:
> >No, there are not. Here is the recursive directory listing:
>
> Are you able to try the following patch and send me dmesg (or attach it
> to that bug)? It should
e_active_kids
-r--r--r-- 1 root root 4096 26 okt 22:11 runtime_active_time
-r--r--r-- 1 root root 4096 26 okt 22:11 runtime_enabled
-r--r--r-- 1 root root 4096 26 okt 22:11 runtime_status
-r--r--r-- 1 root root 4096 26 okt 22:11 runtime_suspended_time
-r--r--r-- 1 root root 40
On Thu, Oct 27, 2016 at 11:17:48AM +0300, Mika Westerberg wrote:
> On Thu, Oct 27, 2016 at 12:56:41AM +0200, Peter Wu wrote:
> > Hi PCI/ACPI PM experts,
> >
> > Since Linux 4.8, nouveau switched to rely on the PCIe port driver to
> > transition to D3cold. This however
below.
Kind regards,
Peter
On Wed, Oct 26, 2016 at 10:42:07PM +, bugzilla-dae...@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=98398
>
> --- Comment #11 from Peter Wu <pe...@lekensteyn.nl> ---
> So 4.7 and before used the "DSM" method on ru
before checking bridge_d3
(in case the user changed d3cold_allowed), but that is such an unlikely
case and likely fragile anyway. The current patch is suggested by Mika
in http://www.spinics.net/lists/linux-pci/msg52599.html
Cc: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by:
, Jul 15, 2016 at 03:12:14PM +0200, Peter Wu wrote:
> Hi,
>
> Here are two patches to fix an issue reported on kernel bugzilla (infinite
> loop
> due to unchecked function) and a more important fix to fix hanging Optimus
> machines when runtime PM is enabled (w
On Fri, Jul 15, 2016 at 06:54:27PM +0200, Peter Wu wrote:
> On Fri, Jul 15, 2016 at 12:41:49PM -0400, Ilia Mirkin wrote:
> > On Fri, Jul 15, 2016 at 12:36 PM, Peter Wu <pe...@lekensteyn.nl> wrote:
> > > On Fri, Jul 15, 2016 at 12:10:23PM -0400, Ilia Mirkin wrote:
> >
On Fri, Jul 15, 2016 at 12:41:49PM -0400, Ilia Mirkin wrote:
> On Fri, Jul 15, 2016 at 12:36 PM, Peter Wu <pe...@lekensteyn.nl> wrote:
> > On Fri, Jul 15, 2016 at 12:10:23PM -0400, Ilia Mirkin wrote:
> >> On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu <pe...@leke
On Fri, Jul 15, 2016 at 12:10:23PM -0400, Ilia Mirkin wrote:
> On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu <pe...@lekensteyn.nl> wrote:
> > Hi,
> >
> > Here are two patches to fix an issue reported on kernel bugzilla (infinite
> > loop
> > due to unchecked fu
y for _PR3. Added affected machines.
v3: fixed block comment coding style.
Reviewed-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 35 ++
1 file changed, 31 inse
Return the set of supported functions to the caller. No functional
changes.
Reviewed-by: Hans de Goede <hdego...@redhat.com>
Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
ede <hdego...@redhat.com>
Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 5
tps://lists.freedesktop.org/archives/dri-devel/2016-July/112759.html
Peter Wu (4):
drm/nouveau/acpi: ensure matching ACPI handle and supported functions
drm/nouveau/acpi: return supported DSM functions
drm/nouveau/acpi: check for function 0x1B before using it
drm/nouveau/acpi: fix lockup with P
this implicit assumption more obvious.
Convert int to bool and rename has_dsm to has_mux while at it. Let the
caller set nouveau_dsm_priv.dhandle as needed.
v2: pass dhandle to the caller.
Reviewed-by: Hans de Goede <hdego...@redhat.com>
Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
---
On Wed, Jul 13, 2016 at 06:17:47PM +0100, Chris Wilson wrote:
> On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote:
> > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called
> > while nouveau was runtime suspended, a deadlock would occur due to
> > nouv
On Wed, Jul 13, 2016 at 04:57:19PM +0200, Daniel Vetter wrote:
> On Wed, Jul 13, 2016 at 02:40:50PM +0200, Peter Wu wrote:
> > On Wed, Jul 13, 2016 at 11:54:49AM +0200, Daniel Vetter wrote:
> > > On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote:
> > > > The
links" series
> hasn't landed yet, it's still possible I think to ask for feature
> requests should it not work for this particular use case. The
> linux...@vger.kernel.org mailing list is the right place to inquire
> about the series.
>
> Thanks for raising this important question.
I'll give this a go after finishing the PR3 nouveau patches and fixing
some locking issues.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Wed, Jul 13, 2016 at 11:54:49AM +0200, Daniel Vetter wrote:
> On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote:
> > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called
> > while nouveau was runtime suspended, a deadlock
On Tue, Jul 12, 2016 at 09:16:22PM +0200, Lukas Wunner wrote:
> On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote:
> > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called
> > while nouveau was runtime suspended, a deadlock would occur due to
> > nouv
was done for performance reasons though).
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
---
Tested on top of v4.7-rc5, the deadlock is gone.
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +--
drive
of pci_bridge_d3_possible(). I'll send a
separate mail for this to linux-pci.
Kind regards,
Peter
[1]: https://lists.freedesktop.org/archives/nouveau/2016-May/025116.html
[2]: https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/?h=pci/pm
Peter Wu (4):
drm/nouveau/acpi: ensure matching ACPI handle
Return the set of supported functions to the caller. No functional
changes.
Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acp
y for _PR3. Added affected machines.
Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouvea
Do not unconditionally invoke function 0x1B without checking for its
availability, it leads to an infinite loop on some firmware.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104791
Fixes: 5addcf0a5f0fad ("nouveau: add runtime PM support (v0.9)")
Signed-off-by: Pe
this implicit assumption more obvious.
Convert int to bool and rename has_dsm to has_mux while at it. Let the
caller set nouveau_dsm_priv.dhandle as needed.
v2: pass dhandle to the caller.
Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
---
drivers/gpu/drm/nouveau/nouveau_acpi.
On Wed, Jun 01, 2016 at 12:28:47PM +0300, Mika Westerberg wrote:
> On Tue, May 31, 2016 at 01:02:31PM +0200, Peter Wu wrote:
> > On Tue, May 31, 2016 at 11:43:56AM +0300, Mika Westerberg wrote:
> > > On Mon, May 30, 2016 at 06:13:51PM +0200, Peter Wu wrote:
> > > &g
On Tue, May 31, 2016 at 02:20:26PM +0200, Lukas Wunner wrote:
> On Mon, May 30, 2016 at 06:13:51PM +0200, Peter Wu wrote:
> > Do you have any suggestions for the case where the pcieport driver
> > refuses to put the bridge in D3 (because the BIOS is too old)? In that
> > ca
On Tue, May 31, 2016 at 01:34:43PM +0200, Lukas Wunner wrote:
> On Mon, May 30, 2016 at 07:03:46PM +0200, Peter Wu wrote:
> > On Sun, May 29, 2016 at 05:50:06PM +0200, Lukas Wunner wrote:
> > > How exactly did you reach the situation where the root port didn't wake
> > >
On Tue, May 31, 2016 at 11:43:56AM +0300, Mika Westerberg wrote:
> On Mon, May 30, 2016 at 06:13:51PM +0200, Peter Wu wrote:
> > Do you have any suggestions for the case where the pcieport driver
> > refuses to put the bridge in D3 (because the BIOS is too old)? In that
> > ca
On Sun, May 29, 2016 at 05:50:06PM +0200, Lukas Wunner wrote:
> Hi Peter,
>
> On Fri, May 27, 2016 at 03:07:33AM +0200, Peter Wu wrote:
> > On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote:
> > > nouveau_drm_load() calls pm_runtime_put() if
t; though the runtime PM on the PCIe port does nothing.
>
> Somehow it does not feel right to poke parent device's fields directly.
>
> What if you just check if it has the method like:
>
> bool no_dsm = acpi_has_method(parent_adev->handle, "_PR3");
>
On Mon, May 30, 2016 at 12:57:09PM +0300, Mika Westerberg wrote:
> +Rafael
>
> On Fri, May 27, 2016 at 01:10:37PM +0200, Peter Wu wrote:
> > On Wed, May 25, 2016 at 04:55:35PM +0300, Mika Westerberg wrote:
> > > On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote:
On Mon, May 30, 2016 at 11:48:34AM +0100, Emil Velikov wrote:
> On 27 May 2016 at 22:31, Peter Wu <pe...@lekensteyn.nl> wrote:
> > On Fri, May 27, 2016 at 02:01:39PM +0100, Emil Velikov wrote:
> >> Hi Peter,
> >>
> >> On 24 May 2016 at 23:53, Peter Wu <
On Fri, May 27, 2016 at 02:01:39PM +0100, Emil Velikov wrote:
> Hi Peter,
>
> On 24 May 2016 at 23:53, Peter Wu <pe...@lekensteyn.nl> wrote:
> > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port
> > can be runtime-suspended wh
On Wed, May 25, 2016 at 04:55:35PM +0300, Mika Westerberg wrote:
> On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote:
> > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port
> > can be runtime-suspended which disables power resources via ACPI.
pm_runtime_get_sync(dev->dev);
> + if (nouveau_runtime_pm != 0) {
> + pm_runtime_get_sync(dev->dev);
> + }
> +
> nouveau_fbcon_fini(dev);
> nouveau_accel_fini(drm);
> nouveau_hwmon_fini(dev);
> --
> 2.8.1
>
> ______
Return the set of supported functions to the caller. No functional
changes.
Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acp
this implicit assumption more obvious.
Convert int to bool and rename has_dsm to has_mux while at it.
Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 55 ++
1 file changed, 23 insertions(+), 32 deletions(-)
diff
nd newer[1] (as observed via an AMLi
debugger trace) and stop using the DSM functions for D3cold when power
resources are available on the parent PCIe port.
[1]:
https://msdn.microsoft.com/windows/hardware/drivers/bringup/firmware-requirements-for-d3cold
Signed-off-by: Peter Wu <pe...@
vv >/dev/null; systemctl suspend
Kind regards,
Peter
[1]: https://lkml.kernel.org/r/20160524211309.gh1...@lahna.fi.intel.com
Peter Wu (4):
drm/nouveau/acpi: ensure matching ACPI handle and supported functions
drm/nouveau/acpi: return supported DSM functions
drm/nouveau/acpi: check for func
Do not unconditionally invoke function 0x1B without checking for its
availability, it leads to an infinite loop on some firmware.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104791
Fixes: 5addcf0a5f0fad ("nouveau: add runtime PM support (v0.9)")
Signed-off-by: Pe
cifications.)
The first parameter for CreateField is evaluated as buffer (sec 19.6.21).
According to 19.3.5.6 (Data Types and Type Conversions) an implicit
conversion to a Buffer is only possible from an Integer and String, a
Package does not belong to the possibilities.
Note that the return value may be an integer for unsupported revision
IDs or UUIDs (like 0x8002). These should be compatible with Buffers
though as stated above and acpi_check_dsm() can handle that case, but
unfortunately sets a Package as fourth argument and can therefore not be
used in nouveau.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Do not unconditionally invoke function 0x1B without checking for its
availability, it leads to an infinite loop on some firmware.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104791
Fixes: 5addcf0a5f0fad ("nouveau: add runtime PM support (v0.9)")
Signed-off-by: Pe
62 matches
Mail list logo
