similar to: [PATCH] drm/nouveau/devinit/gf100-: try to avoid double-running vbios scripts

Turns out some VBIOSes don't actually set the bit in question in 2240c. Use the nv50-style detection to try avoiding running the vbios twice. Fixes: a6a0f67ca7aa ("drm/nouveau/devinit/gf100-: detect if BIOS invoked devinit") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97620 Cc: <stable at vger.kernel.org> # v4.6+ Signed-off-by: Ilia Mirkin <imirkin at

We never use any nv50-specific member in this nv50_devinit_preinit(). Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/devinit/nv50.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/devinit/nv50.c b/drm/nouveau/nvkm/subdev/devinit/nv50.c index 337c2c6..c714b09 100644 ---

It is not advisable to perform devinit if it has already been done. VBIOS will very likely have invoked devinit if the GPU is the primary graphics device, but there is no accurate way to detect this fact yet. This patch adds such a method for gf100 and later chips, by means of the NV_PTOP_SCRATCH1_DEVINIT_COMPLETED bit. This bit is set to 1 by devinit, and reset to 0 when the GPU is powered.

In case of successful suspend, devinit will have to be run and this is the behavior currently hardcoded. However, as FD bug 94725 suggests, there might be cases where runtime suspend leaves the GPU powered, and in such cases devinit should not be run on resume. On GF100+ we have a reliable way to know whether we need to run devinit. Use it instead of blindly trusting the flag set by

https://bugs.freedesktop.org/show_bug.cgi?id=97620 Bug ID: 97620 Summary: [REGRESSION] KMS having issues after kernel upgrade (4.5.1-1 to 4.6.4-1) Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium

From: Dave Airlie <airlied at redhat.com> GSP should be handling this and I can see no evidence in opengpu driver that this register should be touched. Fixed acceleration on 2080 Ti GPUs. Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM") Signed-off-by: Dave Airlie <airlied at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/devinit/r535.c | 1 - 1

vring_create_virtqueue() allows the caller to specify via the may_reduce_num parameter whether the vring code is allowed to allocate a smaller ring than specified. However, the split ring allocation code tries to allocate a smaller ring on allocation failure regardless of what the caller specified. This may cause trouble for e.g. virtio-pci in legacy mode, which does not support ring resizing.

Hello Ben Skeggs, The patch 88524bc06926: "drm/nouveau/devinit: move simple pll setting routines to devinit" from Mar 5, 2013, leads to the following static checker warning: drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv50.c:53 nv50_devinit_pll_set() info: return a literal instead of 'ret' drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv50.c 34 int 35

On 25/03/2014 23:24, Ilia Mirkin wrote: > On Tue, Mar 25, 2014 at 6:11 PM, Martin Peres <martin.peres at free.fr> wrote: >> Other kind of accesses are unreliable on Maxwell cards. As advised by NVIDIA, > Maxwell or Kepler? Damn, I meant Kepler. I updated the patch in my git tree: http://cgit.freedesktop.org/~mperes/nouveau/commit/?id=661a5c599565686f72e729600b0dd6aa6e472f0c

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 143119 Addresses-Coverity-ID: 143120 Addresses-Coverity-ID: 143121 Addresses-Coverity-ID: 143122 Addresses-Coverity-ID: 143123 Addresses-Coverity-ID: 143124 Signed-off-by: Gustavo A. R. Silva <garsilva at embeddedor.com> ---

On Tue, Mar 25, 2014 at 6:11 PM, Martin Peres <martin.peres at free.fr> wrote: > Other kind of accesses are unreliable on Maxwell cards. As advised by NVIDIA, Maxwell or Kepler? > let's only use 32-bit accesses to fetch the vbios from PROM. > > This fixes vbios fetching on my nve7 which failed in certain specific > conditions. > > I suggest we Cc stable, for all

NVIDIA GPUs include a common scripting language (devinit) that can be interpreted by a number of "engines", e.g. within a kernel-mode software driver, the VGA BIOS or an on-board small microcontroller which provides certain security assertions (the 'PMU'). This system allows a GPU programming sequence to be shared by multiple entities that would not otherwise be able to execute

Other kind of accesses are unreliable on Maxwell cards. As advised by NVIDIA, let's only use 32-bit accesses to fetch the vbios from PROM. This fixes vbios fetching on my nve7 which failed in certain specific conditions. I suggest we Cc stable, for all kernels they still maintain after the big rewrite. Suggested-by: Christian Zander <czander at nvidia.com> Signed-off-by: Martin Peres

On Sun, Jan 19, 2014 at 4:18 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > Also make nv_lockvgac work for nv50+ devices. This should fix IO_CONDITION and > related VBIOS opcodes that read/write the crtc regs. > > See https://bugs.freedesktop.org/show_bug.cgi?id=60680 > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > > Ben, is this what you

That's great -- can you just confirm that this is what you did (every so often things work for the wrong reasons): (a) grabbed the ~darktama repo (b) took the MXM patch, futzed with the paths (since it was against the linux tree), applied it (c) took the patch off the mailing list, applied it (paths should have been fine) (d) DID NOT apply the vbios-pq1 patch in any form And then you built

https://bugs.freedesktop.org/show_bug.cgi?id=99372 Bug ID: 99372 Summary: Nvidia 640M devinit fails Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

Coefficients are based on the formula: uV = 0.1 * arg[0] + 150.5 * arg[1] + 22.65025 * arg[2] It seems to be rounded downwards. I have no idea why the voltage isn't specified in the bios directly. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> ---- diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/vmap.c b/drivers/gpu/drm/nouveau/core/subdev/bios/vmap.c

On 25/03/2014 17:17, Christian Zander wrote: > On Mon, Mar 24, 2014 at 11:59:46AM -0700, Martin Peres wrote: >> Hello, >> >> One of my GPU (GK107/NVE7) fails to properly fetch its vbios from PROM >> at boot time but, if I blacklist the module and load it myself later on, >> it always succeeds. To make things weirder, the same card works great on >> another

On Sat, Apr 5, 2014 at 7:53 AM, Claas Lorenz <cllorenz at uni-potsdam.de> wrote: > Hi, same for me. The screen does not freeze anymore and the boot Great! And that's without the nouveau.config=NvBios= stuff that you added as a workaround, right? > succeeds. But now I have this kernel message during boot (for the second > card): > > [ 24.382045]

I have tested this patch. I can confirm that now nouveau loads correctly without errors. Thank you 2014-03-27 0:37 GMT+01:00 Ilia Mirkin <imirkin at alum.mit.edu>: > There appear to be a crop of new hardware where the vbios is not > available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. > The data read from PCIROM almost invariably contains invalid > instructions