similar to: [RFC] drm: don't continue with anything after the GPU couldn't be woken 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

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

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

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

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

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

On Tue, Nov 21, 2017 at 08:03:20PM +0100, Karol Herbst wrote: > 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.

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

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. > > v2: do the same in nouveau_pmops_resume > > Tested-by: Karl Hastings <kazen at

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.

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

This both uses the legacy modesetting structures in a racy manner, and additionally also doesn't even check the right variable (enabled != the CRTC is actually turned on for atomic). This fixes issues on my P50 regarding the dedicated GPU not entering runtime suspend. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: stable at vger.kernel.org ---

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,

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 a failed resume we may experience unrecoverable errors. Plumb the error code through to actually let the driver fail. On a reverse-prime setup this helps the drm subsystem to at least recover the integrated gpu. This can especially happen with secboot timing out, leaving the hardware in a non-functioning state. Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de>

Here's some fixes for the less important DP AUX issues I mentioned a while back. Lyude Paul (2): drm/dp: Add ->pre/post_transfer() hooks for drm_dp_aux drm/nouveau: Grab an rpm reference before/after DP AUX transactions drivers/gpu/drm/drm_dp_helper.c | 5 ++ drivers/gpu/drm/nouveau/nouveau_connector.c | 36 ++++++++ drivers/gpu/drm/nouveau/nouveau_drm.c | 12 ++-

As it turns out, on cards that actually have CRTCs on them we're already calling drm_kms_helper_poll_enable(drm_dev) from nouveau_display_resume() before we call it in nouveau_pmops_runtime_resume(). This leads us to accidentally trying to enable polling twice, which results in a potential deadlock between the RPM locks and drm_dev->mode_config.mutex if we end up trying to enable polling

On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrote: > 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: > > > > > >