similar to: [PATCH] nouveau: fix acpi edid retrieval

https://bugs.freedesktop.org/show_bug.cgi?id=55412 Priority: medium Bug ID: 55412 Assignee: nouveau at lists.freedesktop.org Summary: Screen turns black during boot after driver tries to set mode on NV50 QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux

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

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

While investigating the runpm issues on my GP107 I noticed that something inside devinit makes runpm break. If Nouveau loads up to the point right before doing devinit, runpm works without any issues, if devinit is ran, not anymore. Out of curiousity I even tried to "bisect" devinit by not running it on vbios provided signed PMU image, but on the devinit parser we have inside Nouveau.

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

CCing linux-pci and Bjorn Helgaas. Maybe we could get better insights on how a reasonable fix would look like. Anyway, to me this entire issue looks like something which has to be fixed on a PCI level instead of inside a driver, so it makes sense to ask the pci folks if they have any better suggestions. Original cover letter: While investigating the runpm issues on my GP107 I noticed that

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM

This is especially true when variables or functions are just called dsm without specifying the v1. Changes since v1: * Fix typo in commit explanation * Change has_dsm to has_mux in nouveau_dsm_detect Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau/nouveau_acpi.c | 72 +++++++++++++++++++++++----------------------- drm/nouveau/nouveau_acpi.h | 4 +--

This is especially true when variables or functions are just called dsm without precising the v1. Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau/nouveau_acpi.c | 64 +++++++++++++++++++++++----------------------- drm/nouveau/nouveau_acpi.h | 4 +-- drm/nouveau/nouveau_drm.c | 4 +-- drm/nouveau/nouveau_vga.c | 10 ++++---- 4 files changed, 41 insertions(+), 41

This patch certainly needs some more work, but I'd like to get some comments. Not sure if it is really related to the gmux or if it is a different Optimus _DSM version. I tested it on my laptop (MCP79/7A + G96) and the G96 successfully goes to sleep, however it is still marked as PWR in vga_switcheroo, despite `vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF)` being called. ---

My old machine started getting a bit flaky, so I have kicked it off my desk, but still wanted to get some nouveau bugs fixed on it. (In fact it's easier now that I can reboot it more easily.) So I put a spare old hard drive on it and rebuilt it, but I'm having a heck of a time getting it working. Whenever it tries to load the nouveau module, it blows up. What's funny is that it

https://bugs.freedesktop.org/show_bug.cgi?id=69349 Priority: medium Bug ID: 69349 Assignee: nouveau at lists.freedesktop.org Summary: Random image corruptions (in Debian Wheezy with Linux 3.2) QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All

Dear R folks, I am sorry to ask this simple question, but my search for the right way/command was unsuccessful. I have a vector > x <- c(2, 2, 3, 3, 4, 6) Now the values of x should be considered the index of another vector with possible greater length, say 8, and the value should be how often the indexes appeared in the original vector x. > length(result) [1] 8 > result [1] 0

This oops manifests itself on the following hardware: 01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce G 103M] (rev a1) Oct 09 14:17:46 lp-sasha kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oct 09 14:17:46 lp-sasha kernel: #PF: supervisor read access in kernel mode Oct 09 14:17:46 lp-sasha kernel: #PF: error_code(0x0000) - not-present page Oct 09