search for: pci_restore_standard_config

...urn 0; > >> + } > >> > >> if (!pm || !pm->runtime_resume) > >> return -ENOSYS; > > So if pci_pm_runtime_suspend() is modified to call pci_save_state() > before returning 0 in the !dev->driver case, we can just move the > pci_restore_standard_config() invocation in pci_pm_runtime_resume() up > to the very top and check dev->driver later. I mean something like the patch below, overall (untested). Tentatively-signed-off-by: Rafael J. Wysocki <rafael.j.wysocki at intel.com> --- drivers/pci/pci-driver.c | 16 ++++++++++------ 1 fi...

This fixes some nasty issues I found in nouveau that were being caused looping through connectors using racy legacy methods, along with some caused by making incorrect assumptions about the drm_connector structs in nouveau's connector list. Most of these memory corruption issues could be reproduced by using an MST hub with nouveau. Cc: Karol Herbst <karolherbst at gmail.com> Cc: stable

.../0x10 [nouveau] [ 56.593350] nvif_client_resume+0x14/0x20 [nouveau] [ 56.593365] nouveau_do_resume+0x4d/0x130 [nouveau] [ 56.593379] nouveau_pmops_runtime_resume+0x72/0x150 [nouveau] [ 56.593381] pci_pm_runtime_resume+0x7b/0xa0 [ 56.593382] __rpm_callback+0xc6/0x210 [ 56.593383] ? pci_restore_standard_config+0x40/0x40 [ 56.593384] rpm_callback+0x24/0x80 [ 56.593385] ? pci_restore_standard_config+0x40/0x40 [ 56.593385] rpm_resume+0x47d/0x680 [ 56.593400] ? i915_gem_timeline_init+0xe/0x10 [i915] [ 56.593401] __pm_runtime_resume+0x4f/0x80 [ 56.593415] nouveau_drm_open+0x3b/0x1b0 [nouveau...

...039133] nouveau_display_resume+0x5c0/0x810 [nouveau] [ 201.039173] ? nvkm_client_ioctl+0x20/0x20 [nouveau] [ 201.039215] nouveau_do_resume+0x19f/0x570 [nouveau] [ 201.039256] nouveau_pmops_runtime_resume+0xd8/0x2a0 [nouveau] [ 201.039264] pci_pm_runtime_resume+0x130/0x250 [ 201.039269] ? pci_restore_standard_config+0x70/0x70 [ 201.039275] __rpm_callback+0x1f2/0x5d0 [ 201.039279] ? rpm_resume+0x560/0x18a0 [ 201.039283] ? pci_restore_standard_config+0x70/0x70 [ 201.039287] ? pci_restore_standard_config+0x70/0x70 [ 201.039291] ? pci_restore_standard_config+0x70/0x70 [ 201.039296] rpm_callback+0x175/0...

...[ 1102.005269]  nvkm_object_init+0x39/0x100 [nouveau] [ 1102.005284]  nvkm_object_init+0x6c/0x100 [nouveau] [ 1102.005299]  nvkm_object_init+0x6c/0x100 [nouveau] [ 1102.005328]  nouveau_do_resume+0x23/0xb0 [nouveau] [ 1102.005357]  nouveau_pmops_runtime_resume+0x7c/0x150 [nouveau] [ 1102.005360]  ? pci_restore_standard_config+0x40/0x40 [ 1102.005361]  pci_pm_runtime_resume+0x6f/0xc0 [ 1102.005362]  ? pci_restore_standard_config+0x40/0x40 [ 1102.005363]  __rpm_callback+0x76/0x120 [ 1102.005365]  ? pci_restore_standard_config+0x40/0x40 [ 1102.005366]  rpm_callback+0x1a/0x70 [ 1102.005367]  ? pci_restore_standard_config+0x...

...21, 2018 at 01:39:34PM +0100, Rafael J. Wysocki wrote: > On Wednesday, February 21, 2018 10:57:14 AM CET Rafael J. Wysocki wrote: > > So if pci_pm_runtime_suspend() is modified to call pci_save_state() > > before returning 0 in the !dev->driver case, we can just move the > > pci_restore_standard_config() invocation in pci_pm_runtime_resume() up > > to the very top and check dev->driver later. > > I mean something like the patch below, overall (untested). > > Tentatively-signed-off-by: Rafael J. Wysocki <rafael.j.wysocki at intel.com> Okay I've tested this success...

This fixes some nasty issues I found in nouveau that were being caused looping through connectors using racy legacy methods, along with some caused by making incorrect assumptions about the drm_connector structs in nouveau's connector list. Most of these memory corruption issues could be reproduced by using an MST hub with nouveau. Next version of

...(unbound), the device should - * always remain in D0 regardless of the runtime PM status + * Restoring config space is necessary even if the device is not bound + * to a driver because although we left it in D0, it may have gone to + * D3cold when the bridge above it runtime suspended. */ + pci_restore_standard_config(pci_dev); + if (!pci_dev->driver) return 0; if (!pm || !pm->runtime_resume) return -ENOSYS; - pci_restore_standard_config(pci_dev); pci_fixup_device(pci_fixup_resume_early, pci_dev); pci_enable_wake(pci_dev, PCI_D0, false); pci_fixup_device(pci_fixup_resume, pci_dev); --...

On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote: > PCI devices not bound to a driver are supposed to stay in D0 during > runtime suspend. Doesn't "runtime suspend" mean an individual device is suspended while the rest of the system remains active? If so, maybe it would be more direct to say "PCI devices not bound to a driver cannot be runtime

Hi, just for your information and maybe for some help: with 5.1rc1 and SVM enabled i see the following backtrace [1] when the nouveau card (reverse prime) goes to sleep, for now i have papered over with [2] which leaves me with userspace hangs. Any pointers where to look for the actual culprit? PS: Card is: nouveau 0000:01:00.0: NVIDIA GP106 (136000a1) Greetings, Tobias [1]: BUG: unable

The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called while nouveau was runtime suspended, a deadlock would occur due to nouveau_fbcon_set_suspend also trying to obtain console_lock(). Fix this by delaying the drm_fb_helper_set_suspend call. Based on the i915 code (which was done for performance reasons though). Cc: Chris Wilson <chris at chris-wilson.co.uk> Cc: Daniel

...ume+0x79/0x120 [nouveau] Jul 13 17:05:59 acer kernel: [24873.946800] [<ffffffff814448eb>] pci_pm_runtime_resume+0x7b/0xa0 Jul 13 17:05:59 acer kernel: [24873.946801] [<ffffffff815676d3>] __rpm_callback+0x33/0x70 Jul 13 17:05:59 acer kernel: [24873.946803] [<ffffffff81444870>] ? pci_restore_standard_config+0x40/0x40 Jul 13 17:05:59 acer kernel: [24873.946804] [<ffffffff81567734>] rpm_callback+0x24/0x80 Jul 13 17:05:59 acer kernel: [24873.946806] [<ffffffff81444870>] ? pci_restore_standard_config+0x40/0x40 Jul 13 17:05:59 acer kernel: [24873.946807] [<ffffffff81567ee1>] rpm_resume...

...[nouveau] > Jul 13 17:05:59 acer kernel: [24873.946800] [<ffffffff814448eb>] pci_pm_runtime_resume+0x7b/0xa0 > Jul 13 17:05:59 acer kernel: [24873.946801] [<ffffffff815676d3>] __rpm_callback+0x33/0x70 > Jul 13 17:05:59 acer kernel: [24873.946803] [<ffffffff81444870>] ? pci_restore_standard_config+0x40/0x40 > Jul 13 17:05:59 acer kernel: [24873.946804] [<ffffffff81567734>] rpm_callback+0x24/0x80 > Jul 13 17:05:59 acer kernel: [24873.946806] [<ffffffff81444870>] ? pci_restore_standard_config+0x40/0x40 > Jul 13 17:05:59 acer kernel: [24873.946807] [<ffffffff81567ee1&...

https://bugs.freedesktop.org/show_bug.cgi?id=101553 Bug ID: 101553 Summary: [ 8.944203] nouveau 0000:01:00.0: DRM: failed to create kernel channel, -22 Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium

...u_display_init+0x42/0xd0 [nouveau] > [<ffffffffa021eda5>] ? nouveau_display_resume+0x15/0xa0 [nouveau] > [<ffffffffa020e7cb>] ? nouveau_pmops_runtime_resume+0x9b/0x100 [nouveau] > [<ffffffff812ac745>] ? pci_pm_runtime_resume+0x85/0xc0 > [<ffffffff812ac6c0>] ? pci_restore_standard_config+0x30/0x30 > [<ffffffff8137b6f6>] ? __rpm_callback+0x36/0x80 > [<ffffffff8137b768>] ? rpm_callback+0x28/0x90 > [<ffffffff8137c48d>] ? rpm_resume+0x39d/0x570 > [<ffffffff81071483>] ? __wake_up+0x43/0x70 > [<ffffffff8137c8f8>] ? __pm_runtime_resume+0x4...

https://bugs.freedesktop.org/show_bug.cgi?id=108857 Bug ID: 108857 Summary: display becomes unresponsive and keyboard input fails Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau

...mically. > >> return 0; >> + } >> >> if (!pm || !pm->runtime_resume) >> return -ENOSYS; So if pci_pm_runtime_suspend() is modified to call pci_save_state() before returning 0 in the !dev->driver case, we can just move the pci_restore_standard_config() invocation in pci_pm_runtime_resume() up to the very top and check dev->driver later.

Modernize vga_switcheroo by using a device link to enforce a runtime PM dependency from an HDA controller to the GPU it's integrated into, v2. Changes since v1: - Replace patch [1/7] to use pci_save_state() / pci_restore_state() for consistency between runtime PM code path of bound and unbound devices. (Rafael, Bjorn) - Patch [5/7]: Drop an unnecessary initialization. (Bjorn) Rephrase

...a2>] ? nouveau_display_init+0x42/0xd0 [nouveau] [<ffffffffa021eda5>] ? nouveau_display_resume+0x15/0xa0 [nouveau] [<ffffffffa020e7cb>] ? nouveau_pmops_runtime_resume+0x9b/0x100 [nouveau] [<ffffffff812ac745>] ? pci_pm_runtime_resume+0x85/0xc0 [<ffffffff812ac6c0>] ? pci_restore_standard_config+0x30/0x30 [<ffffffff8137b6f6>] ? __rpm_callback+0x36/0x80 [<ffffffff8137b768>] ? rpm_callback+0x28/0x90 [<ffffffff8137c48d>] ? rpm_resume+0x39d/0x570 [<ffffffff81071483>] ? __wake_up+0x43/0x70 [<ffffffff8137c8f8>] ? __pm_runtime_resume+0x48/0x70 [<ffffff...

https://bugs.freedesktop.org/show_bug.cgi?id=94725 Bug ID: 94725 Summary: Nouveau driver fails to load on GM204 Product: xorg Version: unspecified Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at