search for: pci_pm_runtime_suspend

...estore as "inflating the code"; I > > would think of it as "having fewer special cases", i.e., we always use > > the same restore path instead of having the main one plus a special > > one for unbound devices. > > That is a fair point, but if you look at pci_pm_runtime_suspend(), it > doesn't actually save anything for devices without drivers, so we'd > just restore the original initial state for them every time. > > If we are to restore the entire state on runtime resume, > pci_pm_runtime_suspend() should be changed to call pci_save_state() >...

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

...t think of a full-blown restore as "inflating the code"; I > would think of it as "having fewer special cases", i.e., we always use > the same restore path instead of having the main one plus a special > one for unbound devices. That is a fair point, but if you look at pci_pm_runtime_suspend(), it doesn't actually save anything for devices without drivers, so we'd just restore the original initial state for them every time. If we are to restore the entire state on runtime resume, pci_pm_runtime_suspend() should be changed to call pci_save_state() before returning 0 in the !dev...

...e+0x14a/0x740 [ 246.899614] [<ffffffff8c0e1c10>] ? wake_atomic_t_function+0x60/0x60 [ 246.899617] [<ffffffff8c6012e3>] pm_runtime_forbid+0x43/0x50 [ 246.899678] [<ffffffffc08f67c5>] nouveau_pmops_runtime_suspend+0xc5/0xd0 [nouveau] [ 246.899684] [<ffffffff8c4ced8d>] pci_pm_runtime_suspend+0x5d/0x190 [ 246.899687] [<ffffffff8c4ced30>] ? pci_pm_runtime_resume+0xa0/0xa0 [ 246.899690] [<ffffffff8c5ff252>] __rpm_callback+0x32/0x70 [ 246.899693] [<ffffffff8c5ff2b4>] rpm_callback+0x24/0x80 [ 246.899695] [<ffffffff8c4ced30>] ? pci_pm_runtime_resume+0xa0/0xa0...

On Wed, Feb 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...

Hi, same for me. The screen does not freeze anymore and the boot succeeds. But now I have this kernel message during boot (for the second card): [ 24.382045] pci_pm_runtime_suspend(): nouveau_pmops_runtime_suspend+0x0/0xe0 [nouveau] returns -22 Do you want to have the complete dmesg log? I think this is a new bug. Your patch works for the previous one, so you can close it. Yours, Claas On 27.03.2014 11:54, Patrick Clara wrote: > I have tested this patch. I can confirm...

...xa0/0xa0 > [ 12.768299] ? nouveau_display_fini+0x56/0xd0 [nouveau] > [ 12.768339] ? nouveau_display_suspend+0x51/0x110 [nouveau] > [ 12.768378] ? nouveau_do_suspend+0x76/0x1c0 [nouveau] > [ 12.768413] ? nouveau_pmops_runtime_suspend+0x54/0xb0 [nouveau] > [ 12.768416] ? pci_pm_runtime_suspend+0x5c/0x160 > [ 12.768419] ? __rpm_callback+0xb6/0x1e0 > [ 12.768423] ? kobject_uevent_env+0x111/0x5e0 > [ 12.768425] ? pci_pm_runtime_resume+0xa0/0xa0 > [ 12.768427] ? rpm_callback+0x1f/0x70 > [ 12.768429] ? pci_pm_runtime_resume+0xa0/0xa0 > [ 12.768431] ? rpm_su...

...42 localhost.localdomain kernel: [<ffffffffc05b7437>] nouveau_do_suspend+0x147/0x2d0 [nouveau] Aug 02 14:19:42 localhost.localdomain kernel: [<ffffffffc05b8317>] nouveau_pmops_runtime_suspend+0x47/0xa0 [nouveau] Aug 02 14:19:42 localhost.localdomain kernel: [<ffffffff949c6622>] pci_pm_runtime_suspend+0x62/0x190 Aug 02 14:19:42 localhost.localdomain kernel: [<ffffffff94ab4796>] __rpm_callback+0x36/0x80 Aug 02 14:19:42 localhost.localdomain kernel: [<ffffffff94ab4804>] rpm_callback+0x24/0x80 Aug 02 14:19:42 localhost.localdomain kernel: [<ffffffff94ab4981>] rpm_suspend+0x121/...

...nouveau_display_fini+0x56/0xd0 [nouveau] >>> [ 12.768339] ? nouveau_display_suspend+0x51/0x110 [nouveau] >>> [ 12.768378] ? nouveau_do_suspend+0x76/0x1c0 [nouveau] >>> [ 12.768413] ? nouveau_pmops_runtime_suspend+0x54/0xb0 [nouveau] >>> [ 12.768416] ? pci_pm_runtime_suspend+0x5c/0x160 >>> [ 12.768419] ? __rpm_callback+0xb6/0x1e0 >>> [ 12.768423] ? kobject_uevent_env+0x111/0x5e0 >>> [ 12.768425] ? pci_pm_runtime_resume+0xa0/0xa0 >>> [ 12.768427] ? rpm_callback+0x1f/0x70 >>> [ 12.768429] ? pci_pm_runtime_resume...

We need to call drm_helper_hpd_irq_event() on resume to properly detect monitor connection / disconnection on some laptops. For runtime-resume (which gets called on resume from normal suspend too) we must call drm_helper_hpd_irq_event() from a workqueue to avoid a deadlock. Rename acpi_work to hpd_work, and move it out of the #ifdef CONFIG_ACPI blocks to make it suitable for generic work.

...[ttm] [ 1730.734358] ttm_bo_force_list_clean+0x6b/0x110 [ttm] [ 1730.734360] ttm_bo_evict_mm+0x26/0x50 [ttm] [ 1730.734375] nouveau_do_suspend+0xa9/0x1d0 [nouveau] [ 1730.734389] nouveau_pmops_runtime_suspend+0x59/0xc0 [nouveau] [ 1730.734391] ? pci_pm_runtime_resume+0xa0/0xa0 [ 1730.734392] pci_pm_runtime_suspend+0x55/0x170 [ 1730.734393] ? pci_pm_runtime_resume+0xa0/0xa0 [ 1730.734394] __rpm_callback+0xc1/0x1f0 [ 1730.734395] ? set_next_entity+0x162/0x610 [ 1730.734396] ? pci_pm_runtime_resume+0xa0/0xa0 [ 1730.734397] rpm_callback+0x24/0x80 [ 1730.734398] ? pci_pm_runtime_resume+0xa0/0xa0 [ 1730.7343...

On Sat, 2017-07-15 at 14:52 -0400, Ilia Mirkin wrote: > > OK, so this issue appears to be that we're calling > drm_crtc_vblank_off() on a crtc for which vblank is already disabled. > My guess is that this happens because the crtc is disabled. > > Not sure what the proper check is to see if vblanks are already disabled... Seems so, the below shut up suspend for both 8600 GT

...8] ? drm_mm_scan_color_evict+0x66/0xd0 [drm] [410260.351678] ttm_mem_evict_first+0x262/0x340 [ttm] [410260.351678] ttm_bo_force_list_clean+0xa4/0x160 [ttm] [410260.351678] nouveau_do_suspend+0x80/0x170 [nouveau] [410260.351678] nouveau_pmops_runtime_suspend+0x40/0xa0 [nouveau] [410260.351678] pci_pm_runtime_suspend+0x58/0x140 [410260.351678] ? __switch_to_asm+0x40/0x70 [410260.351678] ? pci_pm_thaw_noirq+0xa0/0xa0 [410260.351678] __rpm_callback+0xc1/0x140 [410260.351678] ? pci_pm_thaw_noirq+0xa0/0xa0 [410260.351678] rpm_callback+0x1f/0x70 [410260.351678] rpm_suspend+0x10a/0x5a0 [410260.351678] ? __swit...

After resuming more than once on battery these HP Ivybridge laptops, the XHCI devices stop working. Have anyone seen this before? I wanted to check before diving in deeper. Let me know if you have any ideas. Thanks! Facts - Xen 4.0.3, Linux 3.2.7 PVOPs - Happens on HP Ivybridge. Doesn''t happen on very similar HP Sandybridge Clash system. - Happens on battery, but not on AC. -

...m_runtime_resume+0xa0/0xa0 [ 49.196329] ? warn_slowpath_fmt+0x4a/0x50 [ 49.196349] ? gen6_read32+0x92/0x1e0 [i915] [ 49.196369] ? hsw_enable_pc8+0x6b7/0x720 [i915] [ 49.196371] ? pci_pm_runtime_resume+0xa0/0xa0 [ 49.196384] ? intel_runtime_suspend+0x142/0x250 [i915] [ 49.196386] ? pci_pm_runtime_suspend+0x50/0x140 [ 49.196387] ? __rpm_callback+0xb1/0x1f0 [ 49.196389] ? rpm_callback+0x1a/0x70 [ 49.196390] ? pci_pm_runtime_resume+0xa0/0xa0 [ 49.196392] ? rpm_suspend+0x11d/0x670 [ 49.196396] ? _raw_write_unlock_irq+0xe/0x20 [ 49.196400] ? finish_task_switch+0xa7/0x260 [ 49.196403]...

...gt; wrote: > Hi, same for me. The screen does not freeze anymore and the boot Great! And that's without the nouveau.config=NvBios= stuff that you added as a workaround, right? > succeeds. But now I have this kernel message during boot (for the second > card): > > [ 24.382045] pci_pm_runtime_suspend(): > nouveau_pmops_runtime_suspend+0x0/0xe0 [nouveau] returns -22 > > Do you want to have the complete dmesg log? I think this is a new bug. New to you, perhaps :) Try http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=adbbdbac04f093c0abf946b1e93e4e5291808491. Or yo...

...ffa02956ec>] nouveau_handle_fini+0xbc/0x2a0 [nouveau] [<ffffffffa02941e2>] nouveau_client_fini+0x62/0xb0 [nouveau] [<ffffffffa0314548>] nouveau_do_suspend+0x238/0x2b0 [nouveau] [<ffffffffa0314b5c>] nouveau_pmops_runtime_suspend+0x5c/0xe0 [nouveau] [<ffffffff81395451>] pci_pm_runtime_suspend+0x61/0x140 [<ffffffff81470f11>] __rpm_callback+0x31/0x80 [<ffffffff81470f84>] rpm_callback+0x24/0x80 [<ffffffff81471116>] rpm_suspend+0x136/0x6d0 [<ffffffff8147279a>] pm_runtime_work+0x7a/0xb0 [<ffffffff810a68b6>] process_one_work+0x176/0x430 [<ffffffff810a754...

...thread+0x2e/0x390 INFO: task kworker/0:2:252 blocked for more than 120 seconds. Workqueue: pm pm_runtime_work Call Trace: schedule+0x28/0x80 schedule_timeout+0x1e3/0x370 wait_for_completion+0x123/0x190 flush_work+0x142/0x1c0 nouveau_pmops_runtime_suspend+0x7e/0xd0 [nouveau] pci_pm_runtime_suspend+0x5c/0x180 vga_switcheroo_runtime_suspend+0x1e/0xa0 __rpm_callback+0xc1/0x200 rpm_callback+0x1f/0x70 rpm_suspend+0x13c/0x640 pm_runtime_work+0x6e/0x90 process_one_work+0x184/0x380 worker_thread+0x2e/0x390 Bugzilla: https://bugs.archlinux.org/task/53497 Bugzilla: https://bugs.d...

...? pci_pm_runtime_resume+0xa0/0xa0 [ 12.768299] ? nouveau_display_fini+0x56/0xd0 [nouveau] [ 12.768339] ? nouveau_display_suspend+0x51/0x110 [nouveau] [ 12.768378] ? nouveau_do_suspend+0x76/0x1c0 [nouveau] [ 12.768413] ? nouveau_pmops_runtime_suspend+0x54/0xb0 [nouveau] [ 12.768416] ? pci_pm_runtime_suspend+0x5c/0x160 [ 12.768419] ? __rpm_callback+0xb6/0x1e0 [ 12.768423] ? kobject_uevent_env+0x111/0x5e0 [ 12.768425] ? pci_pm_runtime_resume+0xa0/0xa0 [ 12.768427] ? rpm_callback+0x1f/0x70 [ 12.768429] ? pci_pm_runtime_resume+0xa0/0xa0 [ 12.768431] ? rpm_suspend+0x11f/0x640 [ 12.76844...

...rivers/pci/pci-driver.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index 3bed6beda051..6a67cdbd0e6a 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -1224,11 +1224,14 @@ static int pci_pm_runtime_suspend(struct device *dev) int error; /* - * If pci_dev->driver is not set (unbound), the device should - * always remain in D0 regardless of the runtime PM status + * If pci_dev->driver is not set (unbound), we leave the device in D0, + * but it may go to D3cold when the bridge above it r...