search for: rpm_check_suspend_allowed

On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: > nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0, > but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally. > We therefore leak a runtime pm ref whenever nouveau is loaded with > runpm=0 and then unloaded. The GPU will subsequently never runtime > suspend even if nouveau is loaded again

...llowed to change to "suspended". So it'll appear to the kernel as if it was suspended but in reality it stays in D0. Once runtime pm for PCIe ports gets merged, the root port above the GPU will indeed go to D3 in such a situation because the check pm_children_suspended() (called from rpm_check_suspend_allowed()) returns true. I'm not sure if this is desirable or not. If we keep unbound devices in D0, should we allow ports above them to go to D3? In any case, when nouveau is loaded again, local_pci_probe() will call pm_runtime_get_sync(), which will implicitly set the runtime status to "active...

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. -

...;suspended". So it'll appear to the kernel as if it was suspended > but in reality it stays in D0. > > Once runtime pm for PCIe ports gets merged, the root port above the > GPU will indeed go to D3 in such a situation because the check > pm_children_suspended() (called from rpm_check_suspend_allowed()) > returns true. > > I'm not sure if this is desirable or not. If we keep unbound devices > in D0, should we allow ports above them to go to D3? Maybe Rafael (linux-pm / linux-pci) can answer this question better? The comments in local_pci_probe, pci_pm_runtime_suspend and pci_p...