similar to: [PATCH] [RESEND v2] drm/nouveau/clk: fix gcc-7 -Wint-in-bool-context warning

gcc thinks that interpreting a multiplication result as a bool is confusing: drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll': drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean context, suggest '&&' instead [-Werror=int-in-bool-context] Adding a temporary variable to contain the divisor helps make it clear what is

On Wed, Sep 6, 2017 at 3:56 PM, Arnd Bergmann <arnd at arndb.de> wrote: > gcc thinks that interpreting a multiplication result as a bool > is confusing: > > drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll': > drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean context, suggest '&&' instead

gcc thinks that interpreting a multiplication result as a bool is confusing: drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll': drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean context, suggest '&&' instead [-Werror=int-in-bool-context] In this instance, I think using multiplication is more intuitive than

gcc thinks that interpreting a multiplication result as a bool is confusing: drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll': drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean context, suggest '&&' instead [-Werror=int-in-bool-context] In this instance, I think using multiplication is more intuitive than

On Wed, Sep 6, 2017 at 10:11 PM, Arnd Bergmann <arnd at arndb.de> wrote: > On Wed, Sep 6, 2017 at 4:20 PM, Karol Herbst <karolherbst at gmail.com> wrote: >>> In this instance, I think using multiplication is more intuitive >>> than '&&', so I'm adding a comparison to zero instead to shut up >>> the warning. To further improve

On Wed, Sep 6, 2017 at 4:20 PM, Karol Herbst <karolherbst at gmail.com> wrote: >> In this instance, I think using multiplication is more intuitive >> than '&&', so I'm adding a comparison to zero instead to shut up >> the warning. To further improve readability, I also make the >> error case indented and leave the normal case as the final

v2: Check for PFIFO, don't pause if it's not yet running. This should fix reclocking on boot Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/Makefile | 1 + drivers/gpu/drm/nouveau/core/engine/device/nv50.c | 4 +- .../gpu/drm/nouveau/core/include/subdev/clock.h | 4 + drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c | 439

v2: Check for PFIFO, don't pause if it's not yet running. This should fix reclocking on boot v3: Tiny clean up Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/Makefile | 1 + drivers/gpu/drm/nouveau/core/engine/device/nv50.c | 4 +- .../gpu/drm/nouveau/core/include/subdev/clock.h | 4 +

Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c | 73 +++++++++++++++--------- drivers/gpu/drm/nouveau/core/subdev/clock/nva3.h | 2 +- drivers/gpu/drm/nouveau/core/subdev/fb/ramnva3.c | 2 +- 3 files changed, 48 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c

this code will change for gf100 and newer Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/nvkm/subdev/clk/base.c | 14 ++++++-------- drm/nouveau/nvkm/subdev/clk/g84.c | 1 + drm/nouveau/nvkm/subdev/clk/gf100.c | 1 + drm/nouveau/nvkm/subdev/clk/gk104.c | 1 + drm/nouveau/nvkm/subdev/clk/gk20a.c | 1 + drm/nouveau/nvkm/subdev/clk/gm20b.c | 1 +

Corresponds with GT215. Don't rely on the lock test logic being unconditionally enabled, and disable test logic when done (presumably to save power). v2: Remove warning, nvkm_msec already warns on time-out Signed-off-by: Roy Spliet <nouveau at spliet.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/clk/gf100.c | 8 +++++++- drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk104.c | 8 +++++++- 2

Signed-off-by: Roy Spliet <nouveau at spliet.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/clk/gf100.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gf100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gf100.c index f9a4918..80c6dd6 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gf100.c +++

v2: fix typo it's -> its Signed-off-by: Roy Spliet <nouveau at spliet.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/clk/gf100.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gf100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gf100.c index 026baff..89d5543 100644 ---

Following a series of patches to improve nouveaus clock tree parsing. Reclocking these engines (all but memory) is pretty stable on the cards I've tested. Please review and merge when approved. These patches do not solve the problem that core/shader engine doesn't like to be clocked up too far without fb following, with visible corruption as a result. I suspect this problem is unrelated

Corresponds with GT215. Don't rely on the lock test logic being unconditionally enabled, and disable test logic when done (presumably to save power). Warn when locking fails. Signed-off-by: Roy Spliet <nouveau at spliet.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/clk/gf100.c | 15 ++++++++++++--- drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk104.c | 15 ++++++++++++--- 2 files changed, 24

On Fri, Dec 6, 2013 at 8:30 AM, Thomas Glanzmann <thomas at glanzmann.de> wrote: > Hello Ilia, > >> > [ 7.569394] nouveau [ DEVICE][0000:02:00.0] BOOT0 : 0x0ac080b1 >> > [ 7.569460] nouveau [ DEVICE][0000:02:00.0] Chipset: MCP79/MCP7A (NVAC) >> > [ 7.569530] nouveau [ DEVICE][0000:02:00.0] Family : NV50 >> > [ 7.571151] nouveau [

Reclocking of NVAA/NVAC is substantially different from NV50+, enough to justify a separate clock implementation. This code is a forward-port of reclocking code that has been sitting in a branch for a while, and has been tested on my NVAC. Traces show no significant reasons why this shouldn't work on NVAA, but testers are always welcome. And since these are IGPs without dedicated RAM to

Hello Ilia, > > [ 7.569394] nouveau [ DEVICE][0000:02:00.0] BOOT0 : 0x0ac080b1 > > [ 7.569460] nouveau [ DEVICE][0000:02:00.0] Chipset: MCP79/MCP7A (NVAC) > > [ 7.569530] nouveau [ DEVICE][0000:02:00.0] Family : NV50 > > [ 7.571151] nouveau [ VBIOS][0000:02:00.0] checking PRAMIN for image... > > [ 7.633082] nouveau [ VBIOS][0000:02:00.0]

Dear sirs/madams, I am using smbmount (mount -t smbfs) version 2.2.8a for mounting shares from a Windows 2003 server on a Linux machine. This works fine, but there seems to be a security problem; ordinary users can write to files, even when the Unix protection does not allow this. The user cannot remove the file or create a new one, but can do what he/she wants with an existing one. Is this a

some chipset have working engine reclocking, but broken memory reclocking like Fermi. We should for now, add the functionality to allow partly reclocking for those. Allthough this doesn't give as much performance as one might wish, it is till noticeable and may improve performance enough to be noted. Karol Herbst (2): clk: seperate engine and memory reclock toggles clk: allow engine