similar to: [PATCH 34/37] drm/nouveau/nvkm/engine/gr/tu102: Completely remove unused function ‘tu102_gr_load’

smatch reports drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: symbol 'tu102_gr_load' was not declared. Should it be static? This function is not used so remove it. Signed-off-by: Tom Rix <trix at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c | 13 ------------- 1 file changed, 13 deletions(-) diff --git

On Fri, Mar 17, 2023 at 9:23?AM Lee Jones <lee at kernel.org> wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: ?tu102_gr_load? defined but not used [-Wunused-function] > mhh, this looks a little fishy and might be a mistake not using this function. Ben, is it safe to remove it? The code seems to

From: Arnd Bergmann <arnd at arndb.de> tu102_gr_load() is completely unused and can be removed to address this warning: drivers/gpu/drm/nouveau/dispnv50/disp.c:2517:1: error: no previous prototype for 'nv50_display_create' Another patch was sent in the meantime to mark the function static but that would just cause a different warning about an unused function. Fixes: 1cd97b5490c8

This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Lee Jones (15): drm/xlnx/zynqmp_disp: Use correct kerneldoc formatting in zynqmp_disp drm/xlnx/zynqmp_dp: Fix function name zynqmp_dp_link_train() -> zynqmp_dp_train() drm/vkms/vkms_composer: Fix a few different kerneldoc formatting

Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous prototype for ?tu102_gr_load? [-Wmissing-prototypes] Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Karol Herbst <kherbst at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: David Airlie <airlied at gmail.com> Cc: Daniel Vetter <daniel at

This is an initial series of patches to improve channel recovery on Turing GPUs with the goal of improving reliability enough to eventually enable SVM for Turing. It's likely follow up patches will be required to fully address problems with less trivial workloads than what I have been able to test thus far. This series primarily addresses a number of hardware changes to interrupt layout and

Turing introduced a new simplified page kind scheme, reducing the number of possible page kinds from 256 to 16. It also is the first NVIDIA GPU in which the highest possible page kind value is not reserved as an "invalid" page kind. To address this, the invalid page kind is made an explicit property of the MMU HAL, and a new table of page kinds is added to the tu102 MMU HAL. One

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 1e339ab2ac3c769c1b06b9fb7d532f8495ebc56d ] On Turing, an input LUT is required to transform inputs in fixed-point formats to FP16 for the internal display pipe. We provide an identity mapping whenever a window is enabled for this reason. HW has error checks to ensure when the input is already FP16, that the input LUT is also

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 1e339ab2ac3c769c1b06b9fb7d532f8495ebc56d ] On Turing, an input LUT is required to transform inputs in fixed-point formats to FP16 for the internal display pipe. We provide an identity mapping whenever a window is enabled for this reason. HW has error checks to ensure when the input is already FP16, that the input LUT is also

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

Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/dispnv04/crtc.c:453: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/nouveau/dispnv04/crtc.c:629: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer

From: Thierry Reding <treding at nvidia.com> Tegra firmware doesn't actually use any version numbers and passing -1 causes the existing firmware binaries not to be found. Use version 0 to find the correct files. Signed-off-by: Thierry Reding <treding at nvidia.com> --- drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

From: Thierry Reding <treding at nvidia.com> [ Upstream commit 21454fe697fde188ad6fb541f94b9838fa73ab38 ] Tegra firmware doesn't actually use any version numbers and passing -1 causes the existing firmware binaries not to be found. Use version 0 to find the correct files. Fixes: ef16dc278ec2 ("drm/nouveau/gr/gf100-: select implementation based on available FW")

nouveau changes up to here are: Reviewed-by: Karol Herbst <kherbst at redhat.com> On Fri, Mar 17, 2023 at 9:23?AM Lee Jones <lee at kernel.org> wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/dispnv04/crtc.c:453: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer

The call site of nouveau_dsm_pci_probe() uses single set of output variables for all invocations. So, we must not write anything to them unless it's an NVIDIA device. Otherwise, if we are called with another device after the NVIDIA device, we'll clober the result of the NVIDIA device. For example, if the other device doesn't have _PR3 resources, the detection later would miss the

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

For future reference: https://sourceforge.net/p/mingw-w64/mailman/message/35747206/ On Wed, Mar 22, 2017 at 2:12 PM, Jeroen Ooms <jeroenooms at gmail.com> wrote: > This looks like a bug in mingw-w64 CRT. The problem can be produced > with C++ without R: > > #include <iostream> > #include <cmath> > #include <complex> > > int main(){ >

smatch reports drivers/gpu/drm/nouveau/nvkm/subdev/gsp/ga102.c:49:1: warning: symbol 'ga102_gsps' was not declared. Should it be static? This variable is only used in its defining file, so it should be static Signed-off-by: Tom Rix <trix at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/ga102.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Hi I'm trying to build an Asterisk packages for a C3 system (256MB memory, cpuinfo below). /proc/cpuinfo: processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 9 model name : VIA Nehemiah stepping : 8 cpu MHz : 1000.736 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu

Dear all, We seem to have found a "strange" behaviour in the hyperbolic tangent function tanh on Windows. When running tanh(356 + 0i) the Windows result is NaN + 0.i while on Mac the result is 1 + 0i. It doesn't seem to be a floating point error because on Mac it is possible to run arbitrarily large numbers (say tanh(