similar to: [PATCH 0/2] drm/nouveau: Fix GM107 disp init failures on ThinkPad P50

Just like how the P50 will occasionally leave the disp's core channel on before nouveau starts initializing, it will occasionally do the same thing with the rest of the dmac channel in addition to the core channel. Example: [ 1.604375] nouveau 0000:01:00.0: disp: outp 04:0006:0f81: no heads (0 3 4) [ 1.604858] nouveau 0000:01:00.0: disp: outp 04:0006:0f81: aux power -> always [

When I attach an external monitor to my new Dell Precision I always get this and the monitor refuses to recognize video input. If I persist it reaches a point where the machine will boot but won't bring up a login prompt. I have to ssh to get in. And worst of all, it persisted after I remove the external monitor and am forced to re-install CentOS (7.6.1810). Aug 02 14:19:42

From: Colin Ian King <colin.king at canonical.com> The constant values being shifted are 32 bit integers and may potentially overflow on the shift. Avoid this potential overflow by making them unsigned long long values before the shift. Detected by CoverityScan, CID#1469383, 1469400 ("Unintentional integer overflow") Signed-off-by: Colin Ian King <colin.king at

This series is intended to add support for shutting down the GPU on kernel shutdown/reboot using the ->shutdown() hook, similar to what amdgpu does. This is mainly intended to workaround a bios issue on the P50 that was preventing nouveau from initializing the dedicated GM107 GPU on that system properly. You can find more details on this issue in the patch labeled "Shut down GPU on kernel

Hello Ben Skeggs, The patch a9c44a88ca2f: "drm/nouveau/disp/nv50-: add channel interfaces to control error interrupts" from May 8, 2018, leads to the following static checker warning: drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c:169 nv50_disp_chan_intr() warn: should '65537 << chan->chid.user' be a 64 bit type?

Hello Ben Skeggs, The patch a9c44a88ca2f: "drm/nouveau/disp/nv50-: add channel interfaces to control error interrupts" from May 8, 2018, leads to the following static checker warning: drivers/gpu/drm/nouveau/nvkm/engine/disp/changf119.c:55 gf119_disp_chan_intr() warn: should '1 << chan->chid.user' be a 64 bit type?

We get a few warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c:69:1: warning: no previous

Pointer to structure array is assumed not NULL by default. It has the consequence to raise a kernel panic when it's not the case. Basically, running at least a RTX2080TI on Xen makes a bad mmio error which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the code, it's assumed to be not NULL by accessing directly 'mthd->data[0]' which is the reason

We get 2 warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes] In fact, these functions are declared in

The following functions are not declared outside of the file they are in, so make them static to avoid these warnings: drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:745:1: warning: symbol 'gf100_gr_fecs_start_ctxsw' was not declared. Should it be static? drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:760:1: warning: symbol 'gf100_gr_fecs_stop_ctxsw' was not declared. Should it be

Changes since last sent: * add a patch to set the device into DRM_SWITCH_POWER_CHANGING state (can be dropped actually, I thought I was needing it, came up with a different approach and forgot to delete it, doesn't hurt though) * expose information about runtime suspending to nvkm so that we can run the pcie workaround only on runtime suspend Karol Herbst (8): pci: disable ASPM

https://bugs.freedesktop.org/show_bug.cgi?id=101601 Bug ID: 101601 Summary: Nvidia GT 1030 (NV138/GP108) support Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

Hi Fr?d?ric, It appears Ben made his own version of this patch (probably based on the one you added to the kernel bz), and it's already upstream: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.6-rc2&id=0e6176c6d286316e9431b4f695940cfac4ffe6c2 Cheers, -ilia On Thu, Feb 20, 2020 at 12:19 PM Fr?d?ric Pierret <frederic.pierret at qubes-os.org>

Dear Ben Skeggs, Please find attached a patch solving a blocking issue I encountered: https://bugzilla.kernel.org/show_bug.cgi?id=206299 Basically, running at least a RTX2080TI on Xen makes a bad mmio error which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the code, it's assumed to be not NULL by accessing directly 'mthd->data[0]' which is the

https://bugs.freedesktop.org/show_bug.cgi?id=77529 Priority: medium Bug ID: 77529 Assignee: nouveau at lists.freedesktop.org Summary: NVS 510 DP-3 output doesn't work QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All Reporter: tex at sergio.spb.ru

On Wed, Apr 24, 2019 at 03:16:37PM -0400, Lyude Paul wrote: > On Wed, 2019-04-24 at 13:59 -0500, Bjorn Helgaas wrote: > > Not being a scheduled work expert, I was unsure if this experiment was > > equivalent to what I proposed. > > > > I'm always suspicious of singleton solutions like this (using > > schedule_work() in runtime_resume()) because usually they

On a very specific subset of ThinkPad P50 SKUs, particularly ones that come with a Quadro M1000M chip instead of the M2000M variant, the BIOS seems to have a very nasty habit of not always resetting the secondary Nvidia GPU between full reboots if the laptop is configured in Hybrid Graphics mode. The reason for this happening is unknown, but the following steps and possibly a good bit of patience

On Mon, Apr 15, 2019 at 02:07:18PM -0400, Lyude Paul wrote: > On Thu, 2019-04-04 at 09:17 -0500, Bjorn Helgaas wrote: > > [+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime) > > resume")] > > > > On Fri, Mar 22, 2019 at 06:30:15AM -0500, Bjorn Helgaas wrote: > > > On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote:

On Thu, 2019-02-14 at 18:43 -0600, Bjorn Helgaas wrote: > Hi Lyude, > > On Tue, Feb 12, 2019 at 05:02:30PM -0500, Lyude Paul wrote: > > On a very specific subset of ThinkPad P50 SKUs, particularly ones that > > come with a Quadro M1000M chip instead of the M2000M variant, the BIOS > > seems to have a very nasty habit of not always resetting the secondary > >

In https://nouveau.freedesktop.org/KernelModuleParameters.html, there is: Here is a list of engines: DEVICE DMAOBJ PBSP PCE0 PCE1 PCE2 PCRYPT PDISP PFIFO PGRAPH PMPEG PPM PPPP PVP SW Also, in debug: CLIENT I have tried to find a description of those. https://envytools.readthedocs.io/en/latest/ help a bit, but I don't find a