search for: pci_config_pm_runtime_get

...c921820>] schedule+0x40/0x90 [ 246.899909] [<ffffffff8c5ff595>] __pm_runtime_barrier+0x95/0x140 [ 246.899913] [<ffffffff8c0e1c10>] ? wake_atomic_t_function+0x60/0x60 [ 246.899915] [<ffffffff8c60109b>] pm_runtime_barrier+0x5b/0xc0 [ 246.899919] [<ffffffff8c4cce6b>] pci_config_pm_runtime_get+0x3b/0x60 [ 246.899922] [<ffffffff8c4d1bac>] pci_read_config+0x7c/0x260 [ 246.899927] [<ffffffff8c30fe60>] sysfs_kf_bin_read+0x50/0x80 [ 246.899929] [<ffffffff8c30f91a>] kernfs_fop_read+0xba/0x1c0 [ 246.899934] [<ffffffff8c277d98>] __vfs_read+0x28/0x130 [ 246.899939...

...ey're occurring outside of hda_intel.c (think > > config space readout via sysfs). > > I guess this GPU wakeup happens *if* the path accessing the HDA > controller calls pm_runtime_get_sync() or similar, right? Right. > We do have > that in the sysfs config accessors via pci_config_pm_runtime_get(), > but not in the sysfs mmap paths. I think that's a latent PCI core > defect independent of this series. Yes, there may be a few places where the parent of the device is erroneously not runtime resumed when sysfs files are accessed. I've never used the sysfs mmap feature, so neve...

...e GPU to > wake up regardless if they're occurring outside of hda_intel.c (think > config space readout via sysfs). I guess this GPU wakeup happens *if* the path accessing the HDA controller calls pm_runtime_get_sync() or similar, right? We do have that in the sysfs config accessors via pci_config_pm_runtime_get(), but not in the sysfs mmap paths. I think that's a latent PCI core defect independent of this series. We also don't have that in PCI core config accessors. That maybe doesn't matter because the core probably shouldn't be touching devices after enumeration (although there might...

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.

https://bugs.freedesktop.org/show_bug.cgi?id=85471 Bug ID: 85471 Summary: nouveau/kernel 3.18.0-rc1: nouveau deadlocks on 2nd Xorg start or reboot Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium

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. Remove thereby obsoleted code and fix a bunch of bugs. Device links were introduced in v4.10. Users might see a small power saving if the discrete GPU is in use and its HDA controller is not, because the HDA controller is now allowed to runtime