similar to: [PATCH] drm/nouveau/devinit/nv04: mark expected switch fall-throughs

On Wed, 8 Jul 2020 at 03:31, Gustavo A. R. Silva <gustavoars at kernel.org> wrote: > > Replace the existing /* fall through */ comments and its variants with > the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary > fall-through markings when it is the case. I really like this! I was not a fan of explicitly marking those with comments. Thank you, taken in my

Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org> ---

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

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.

Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/nv04_graph.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv04_graph.c b/drivers/gpu/drm/nouveau/nv04_graph.c index 396ee92..d561d77 100644 --- a/drivers/gpu/drm/nouveau/nv04_graph.c +++ b/drivers/gpu/drm/nouveau/nv04_graph.c @@ -543,7 +543,7 @@

I am debugging the memory issue that manifests itself like this: *** glibc detected *** ../app/app.OWS: free(): invalid pointer: 0x0ad391fc *** ======= Backtrace: ========= /lib/libc.so.6(+0x6c501)[0x4f6501] /lib/libc.so.6(+0x6dd70)[0x4f7d70] /lib/libc.so.6(cfree+0x6d)[0x4fae5d] ../app/app.OWS(_ZNSt8_Rb_treeIjjSt9_IdentityIjESt4lessIjESaIjEE5eraseESt17_Rb_tree_iteratorIjES7_+0x4b)[0x83de6eb]

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

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>

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

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

<dropping llvm-commits> On Jul 2, 2012, at 9:59 AM, Alexander Kornienko wrote: > Hi llvmdev, llvm-commits, > > There was a discussion on this topic a while ago, and now I've decided to make a formal proposal and post it here. I missed the earlier discussion, so I'm sorry for chiming in late. > I propose to add the LLVM_FALLTHROUGH macro for specifying intended

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1260018 Addresses-Coverity-ID: 1260019 Addresses-Coverity-ID: 1260022 Signed-off-by: Gustavo A. R. Silva <garsilva at embeddedor.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/bios/timing.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git

From: "Gustavo A. R. Silva" <gustavo at embeddedor.com> Date: Sat, 4 Aug 2018 21:42:05 -0500 > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Addresses-Coverity-ID: 1402059 ("Missing break in switch") > Addresses-Coverity-ID: 1402060 ("Missing break in switch") >

ThibG from irc reported an issue with transparent cursors, i noticed the ddx had a workaround, which wasn't in the kms code. ThibG (whoever you are), please test. The patch is untested. Maarten. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-nv04-import-hw-workaround-for-partially-transparent-.patch Type: text/x-patch Size: 4908 bytes Desc: not

Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com> --- Noticed while looking at an issue reported by Rafa? Mi?ecki. Seems like the right thing to do, but I don't know the specifics behind the mode_set_base_atomic() so cannot comment if nouveau_fbcon_save/restore is even needed or not. Cheers Emil drivers/gpu/drm/nouveau/dispnv04/crtc.c | 7 ++++--- 1 file changed, 4

The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP and PCI varieties, rather than a core PCIE chip with a bridge for AGP/PCI as necessary. As a result, it appears that the MMU is also non-functional. For AGP cards, the vast majority of the NV4A lineup, this worked out since we force AGP cards to use the nv04 mmu. However for PCI variants, this did not work. Switching to the

match_string() returns the array index of a matching string. Use it instead of the open-coded implementation. Signed-off-by: YueHaibing <yuehaibing at huawei.com> --- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c index

drivers/gpu/drm/nouveau/dispnv04/arb.c: In function nv04_calc_arb: drivers/gpu/drm/nouveau/dispnv04/arb.c:56:21: warning: variable width set but not used [-Wunused-but-set-variable] 'width' is never used, so remove it. Reported-by: Hulk Robot <hulkci at huawei.com> Signed-off-by: YueHaibing <yuehaibing at huawei.com> --- drivers/gpu/drm/nouveau/dispnv04/arb.c | 3 +-- 1

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