similar to: [PATCH] drm/nouveau: suspend to D3hot, not to D3cold

On Sat, 2019-05-04 at 18:32 +0200, Karol Herbst wrote: > Signed-off-by: Karol Herbst <kherbst at redhat.com> > --- > drm/nouveau/nouveau_acpi.c | 6 +++--- > drm/nouveau/nouveau_acpi.h | 4 ++-- > drm/nouveau/nouveau_drm.c | 15 +++++++++++---- > drm/nouveau/nouveau_drv.h | 2 ++ > 4 files changed, 18 insertions(+), 9 deletions(-) > > diff --git

Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nouveau_acpi.c | 6 +++--- drm/nouveau/nouveau_acpi.h | 4 ++-- drm/nouveau/nouveau_drm.c | 15 +++++++++++---- drm/nouveau/nouveau_drv.h | 2 ++ 4 files changed, 18 insertions(+), 9 deletions(-) diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c index ffb19585..49b11d22 100644 ---

v2: rework detection of if Nouveau calling a DSM method or not Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nouveau_acpi.c | 7 ++++++- drm/nouveau/nouveau_acpi.h | 2 ++ drm/nouveau/nouveau_drm.c | 14 +++++++++++--- drm/nouveau/nouveau_drv.h | 2 ++ 4 files changed, 21 insertions(+), 4 deletions(-) diff --git a/drm/nouveau/nouveau_acpi.c

When looking into the runpm issues, the first workaround I came up with was setting the PCIe link speed to whatever it was before running devinit on the GPU. As I was playing around with my patches today, it seems like that just reworking the runpm bits itself fixed it on my machine as well. Hopefully this will be enough for other laptops as well. Anyhow, it's a nice rework and if it's

When looking into the runpm issues, the first workaround I came up with was setting the PCIe link speed to whatever it was before running devinit on the GPU. As I was playing around with my patches today, it seems like that just reworking the runpm bits itself fixed it on my machine as well. Hopefully this will be enough for other laptops as well. Anyhow, it's a nice rework and if it's

On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote: > On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Wed, Nov 20, 2019 at 12:58:00PM +0100, Karol Herbst wrote: > > > overall, what I really want to know is, _why_ does it work on windows? > > > > So do I ;-) > > > > > Or what are

On Tue, May 7, 2019 at 9:16 PM Lyude Paul <lyude at redhat.com> wrote: > > On Sat, 2019-05-04 at 18:32 +0200, Karol Herbst wrote: > > Signed-off-by: Karol Herbst <kherbst at redhat.com> > > --- > > drm/nouveau/nouveau_acpi.c | 6 +++--- > > drm/nouveau/nouveau_acpi.h | 4 ++-- > > drm/nouveau/nouveau_drm.c | 15 +++++++++++---- > >

why the nouveau_is_rpm_worker stuff? On Sat, Nov 17, 2018 at 2:50 AM Lyude Paul <lyude at redhat.com> wrote: > > Now that we have ->pre_transfer() and ->post_transfer() for DP AUX > channel devices, we can implement these hooks in order to ensure that > the GPU is actually woken up before AUX transactions happen. This fixes > /dev/drm_dp_aux* not working while the GPU is

In order to fix all of the spots that need to have runtime PM get/puts() added, we need to ensure that it's possible for us to call pm_runtime_get/put() in any context, regardless of how deep, since almost all of the spots that are currently missing refs can potentially get called in the runtime suspend/resume path. Otherwise, we'll try to resume the GPU as we're trying to resume the

On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg <mika.westerberg at intel.com> wrote: > > On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote: > > On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg > > <mika.westerberg at intel.com> wrote: > > > > > > On Wed, Nov 20, 2019 at 12:58:00PM +0100, Karol Herbst wrote: > > > > overall,

Now that we have ->pre_transfer() and ->post_transfer() for DP AUX channel devices, we can implement these hooks in order to ensure that the GPU is actually woken up before AUX transactions happen. This fixes /dev/drm_dp_aux* not working while the GPU is suspended, along with some more rare issues where the GPU might runtime-suspend if the time between two DP AUX channel transactions ends up

This should make systems more stable where resuming the GPU fails. This can happen due to bad firmware or due to a bug within the kernel. The last thing which should happen in either case is an unusable system. v2: do the same in nouveau_pmops_resume Tested-by: Karl Hastings <kazen at redhat.com> Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nouveau_drm.c | 31

There are PCI devices which are power-manageable by a nonstandard means, such as a custom ACPI method. One example are discrete GPUs in hybrid graphics laptops, another are Thunderbolt controllers in Macs. Such devices can't be put into D3cold with pci_set_power_state() because pci_platform_power_transition() fails with -ENODEV. Instead they're put into D3hot by pci_set_power_state()

nouveau's ->suspend and ->resume callbacks are currently skipped if the device's status is either DRM_SWITCH_POWER_OFF (powered off by vga_switcheroo manual power control) or DRM_SWITCH_POWER_DYNAMIC_OFF (runtime suspended). In the former case this makes sense since the device is powered off behind the PM core's back: It will try to execute the ->suspend and ->resume

Hi Ben, On Tue, Nov 08, 2016 at 09:29:38PM +0100, Peter Wu wrote: > On Tue, Nov 08, 2016 at 12:57:00PM +0100, Lukas Wunner wrote: > > nouveau's ->suspend and ->resume callbacks are currently skipped if the > > device's status is either DRM_SWITCH_POWER_OFF (powered off by > > vga_switcheroo manual power control) or DRM_SWITCH_POWER_DYNAMIC_OFF > > (runtime

On Wed, Oct 16, 2019 at 11:37 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > [+cc linux-acpi] > > On Wed, Oct 16, 2019 at 09:18:32PM +0200, Karol Herbst wrote: > > but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the > > platform means of putting the device into D3cold, right? That's > > actually what should still happen, just the D3hot step

but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the platform means of putting the device into D3cold, right? That's actually what should still happen, just the D3hot step should be skipped. On Wed, Oct 16, 2019 at 9:14 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > On Wed, Oct 16, 2019 at 04:44:49PM +0200, Karol Herbst wrote: > > Fixes state transitions of

On Tue, Nov 08, 2016 at 12:57:00PM +0100, Lukas Wunner wrote: > nouveau's ->suspend and ->resume callbacks are currently skipped if the > device's status is either DRM_SWITCH_POWER_OFF (powered off by > vga_switcheroo manual power control) or DRM_SWITCH_POWER_DYNAMIC_OFF > (runtime suspended). > > In the former case this makes sense since the device is powered off

Hi all, if a device doesn''t support power management (pm_cap == 0) but it is acpi_pci_power_manageable() because there is a _PS0 method declared for it and _EJ0 is also declared for the slot then nobody is going to set current_state = PCI_D0 for this device. This is what I think it is happening: pci_enable_device | __pci_enable_device_flags /* here we do not set current_state

On Tue, Nov 21, 2017 at 6:46 PM, Thierry Reding <thierry.reding at gmail.com> wrote: > On Tue, Nov 21, 2017 at 04:01:16PM +0100, Karol Herbst wrote: >> This should make systems more stable where resuming the GPU fails. This >> can happen due to bad firmware or due to a bug within the kernel. The >> last thing which should happen in either case is an unusable system.