similar to: [PATCH] devinit/gf100: make devinit on resume safer

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.

Some OEMs manage to mess up their VBIOS such that GPIO isn't initialized correctly at boot time. The NVIDIA proprietary driver seems to initialize GPIO unconditionally at boot. Nouveau doesn't because it assumes GPIO is set up correctly. This patch adds a new config option, NvForceGpio, which allow users with broken VBIOS to force a GPIO reset at boot time. This issue seems to be rare

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

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 alum.mit.edu>

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

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

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

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

From: Martin Peres <martin.peres at free.fr> Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/include/nvkm/core/device.h | 83 +++++++++---------- drm/nouveau/include/nvkm/subdev/iccsense.h | 10 +++ drm/nouveau/nvkm/core/subdev.c | 83 +++++++++---------- drm/nouveau/nvkm/engine/device/base.c | 124 +++++++++++++++--------------

From: Martin Peres <martin.peres at free.fr> Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/include/nvkm/core/device.h | 83 +++++++++---------- drm/nouveau/include/nvkm/subdev/iccsense.h | 10 +++ drm/nouveau/nvkm/core/subdev.c | 83 +++++++++---------- drm/nouveau/nvkm/engine/device/base.c | 124 +++++++++++++++--------------

https://bugs.freedesktop.org/show_bug.cgi?id=39550 Summary: Brightness stuck to low value after suspend/resume Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

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

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

On Dec 12, 2013, at 04:25 , Gasiunas, Vaidas <vaidas.gasiunas at sap.com> wrote: > To address these requirements we have developed a set of patches improving performance and malfunction safety of certain compiler passes and would be interested in contributing them at some point. Before proposing concrete changes, we would like to know what the general interest is with respect to making

On 04/14/2016 03:59 AM, Richard W.M. Jones wrote: > The current implementation of getumask involves writing a file with > mode 0777 and then testing what mode was created by the kernel. This > doesn't work properly if the user set a per-mount umask (or fmask/ > dmask). > > This alternative method was suggested by Josh Stone. By forking, we > can use the thread-unsafe

On 04/14/2016 07:57 AM, Richard W.M. Jones wrote: > On Thu, Apr 14, 2016 at 07:38:23AM -0600, Eric Blake wrote: >>> + /* Read the umask. */ >>> + if (read (fd[0], &mask, sizeof mask) != sizeof mask) { >>> + perrorf (g, "read"); >>> + close (fd[0]); >>> + return -1; >> >> Oops - this strands a child process. You

BTW this causes valgrind to fail in a particularly strange way. I filed a bug upstream with a minimal reproducer. Do you have any ideas? https://bugs.kde.org/show_bug.cgi?id=361810 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual

The network-bridge script is fragile because of how grep is used. As one example, if I already have "xenbridge", I can''t create "xenbr". (It''s actually worse than that, because it''s even grepping the header output by brctl show.) Assuming dom0 is on Linux with /sys mounted (is that a safe assumption?) we can check for the existence of a bridge, and

On 04/13/2016 03:43 PM, Richard W.M. Jones wrote: > The current implementation of getumask involves writing a file with > mode 0777 and then testing what mode was created by the kernel. This > doesn't work properly if the user set a per-mount umask (or fmask/ > dmask). > > This alternative method was suggested by Josh Stone. By forking, we > can use the thread-unsafe

virtio pci device reset actually just does an I/O write, which in PCI is really posted, that is it can complete on CPU before the device has received it. Further, interrupts might have been pending on another CPU, so device callback might get invoked after reset. This conflicts with how drivers use reset, which is typically: reset unregister a callback running after reset completed can race