Displaying 20 results from an estimated 600 matches similar to: "[Bug 106662] New: nouveau DPMS poblem with DRI3 (GM107)"
2018 May 19
8
[Bug 106577] New: broken rendering with nine and nouveau (GM107)
https://bugs.freedesktop.org/show_bug.cgi?id=106577
Bug ID: 106577
Summary: broken rendering with nine and nouveau (GM107)
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/DRI/nouveau
Assignee: nouveau
2006 Nov 09
1
Poblem with Centos Logos on X bootup...conversion from whitebox to centos.
Hello all
I migrated my Centos installation from a whitebox install few months
ago. Only one minor issue...on booting up X, the login screen shows
whitebox logos. At that time, I did not tackle it because I assumed that
it will automatically be upgraded with yum...and again it was not
essential to running the OS.
What whitebox rpms do I need to substitute with centos ones to correct
this
2005 Apr 18
1
Poblem while build a package (PR#7798)
Full_Name: Justin Bem
Version: 1.9.1
OS: Windows XP Home
Submission from: (NULL) (196.202.235.48)
I am a R new user !
I have writed procedure that i wantto transform as a package but with
RCMD build packageName [...]
I have 'sh' is not a recognized command in the dos promp I have Active Perl 5.8
!
Does I need to have another software or it is a Perl problem ?
I hope you will find a
2015 Jan 25
1
[PATCH] fuse/gm107: simplify the return logic
Spotted by coccinelle:
drivers/gpu/drm/nouveau/core/subdev/fuse/gm107.c:50:5-8: WARNING: end returns can be simpified
Signed-off-by: Martin Peres <martin.peres at free.fr>
---
drm/nouveau/nvkm/subdev/fuse/gm107.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drm/nouveau/nvkm/subdev/fuse/gm107.c b/drm/nouveau/nvkm/subdev/fuse/gm107.c
index ba19158..0b256aa 100644
2016 Jan 15
0
[PATCH] ltc/gm107: wait on relevant bit in gm107_ltc_cbc_wait
Patch "ltc/gm107: use nvkm_mask to set cbc_ctrl1" sets the 3rd bit
of the CTRL1 register instead of writing it entirely in
gm107_ltc_cbc_clear(). As a counterpart, gm107_ltc_cbc_wait() must also
be modified to wait on that single bit only, otherwise a timeout may
occur if some other bit of that register is set. This happened at least
on GM206 when running glmark2-drm.
While we are at
2016 Aug 29
0
[PATCH] drm/nouveau/gr/gm107: mark symbols static where possible
We get 1 warning when build kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c:312:1: warning: no previous prototype for 'gm107_gr_init' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
so this patch marks this function with 'static'.
Signed-off-by: Baoyou Xie
2016 Mar 04
0
[PATCH 1/2] fb/gm107: maxwell memory reclocking looks like kepler
Signed-off-by: Karol Herbst <nouveau at karolherbst.de>
---
drm/nouveau/nvkm/subdev/fb/gm107.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drm/nouveau/nvkm/subdev/fb/gm107.c b/drm/nouveau/nvkm/subdev/fb/gm107.c
index 2a91df8..9cc7e61 100644
--- a/drm/nouveau/nvkm/subdev/fb/gm107.c
+++ b/drm/nouveau/nvkm/subdev/fb/gm107.c
@@ -29,7 +29,7 @@ gm107_fb = {
.dtor =
2016 Sep 10
0
[PATCH] gm107: separate out sched decoding from regular ops
Unfortunately there's no sure-fire way to distinguish a sched "op" from
regular ones. They happen purely based on position. So for disassembly,
use the byte position in the file to determine whether the current op
should be decoded as sched or as regular.
For assembly, we go back to using a shared table. Ideally we would pick
out which one to use based on the position in the
2016 Oct 22
1
[Bug 98391] New: [GM107] priv: HUB0: 614900 00800000 (1d408200)
https://bugs.freedesktop.org/show_bug.cgi?id=98391
Bug ID: 98391
Summary: [GM107] priv: HUB0: 614900 00800000 (1d408200)
Product: xorg
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Driver/nouveau
2017 Oct 23
1
[Bug 103409] New: [GM107] reboot/suspend/lspci hang with nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=103409
Bug ID: 103409
Summary: [GM107] reboot/suspend/lspci hang with nouveau
Product: Mesa
Version: 17.2
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/DRI/nouveau
2015 Apr 16
3
[Bug 90054] New: white screen reboot on gm107 with multiple monitors
https://bugs.freedesktop.org/show_bug.cgi?id=90054
Bug ID: 90054
Summary: white screen reboot on gm107 with multiple monitors
Product: xorg
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Driver/nouveau
2018 Apr 19
3
[Bug 106132] New: bar.sync encoding incorrect for GM107
https://bugs.freedesktop.org/show_bug.cgi?id=106132
Bug ID: 106132
Summary: bar.sync encoding incorrect for GM107
Product: Mesa
Version: git
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/DRI/nouveau
Assignee: nouveau at
2014 Sep 26
0
[PATCH] gm107/ir: take relative pfetch offset into account
There is no dedicated instruction for this, so just combine it with the
constant offset.
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
Cc: "10.3" <mesa-stable at lists.freedesktop.org>
---
This fixes the spec/glsl-1.50/execution/geometry/dynamic_input_array_index
piglit test.
src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_gm107.cpp | 5 ++++-
1 file changed,
2015 Mar 20
0
VBO flush method on Maxwell (GM107)
Hello,
The method we previously used on Fermi and Kepler (0x142c) to flush
the VBO cache before draw appears to be gone on Maxwell. Is there a
replacement method we should use?
(Or perhaps that method was never meant for VBO cache flush and
instead flushed something related to the vertex quarantine area
defined by 0x17bc/0x17c0/0x17c4, which in turn is gone on Maxwell?)
Thanks for any light you
2014 Aug 16
0
[PATCH 3/3] gm107/therm: add PWM fan support
From: Martin Peres <martin.peres at labri.fr>
Signed-off-by: Martin Peres <martin.peres at free.fr>
---
drm/Kbuild | 1 +
drm/core/subdev/therm/gm107.c | 1 +
nvkm/engine/device/gm100.c | 4 +-
nvkm/include/subdev/therm.h | 1 +
nvkm/subdev/therm/Makefile.am | 3 +-
nvkm/subdev/therm/fan.c | 9 ++++-
nvkm/subdev/therm/gm107.c | 93
2018 Nov 12
1
Question on IPA on GM107
So I'm trying to track an special value in IPA instruction generation.
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp#L2561
Register on 0x14 (20) is set to some source on "insn->op == OP_PINTERP"
I have found while emulation that such value can be set sometimes to
FragCoord.w, I don't however know what that value is and
2014 Sep 25
0
[PATCH] gm107/ir: fix texture argument order
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
Cc: "10.3" <mesa-stable at lists.freedesktop.org>
---
With this, all the tex-miplevel-selection tests pass on maxwell. There is a
minor bit of this change which affects textureGrad on kepler that I have yet
to test, but I'm moderately sure it's correct and was only working by luck
before. (Changing the insbf to use
2018 Aug 20
0
[PATCH 2/2] drm/nouveau: Fix GM107 disp dmac chan init on ThinkPad P50
Just like how the P50 will occasionally leave the disp's core channel on
before nouveau starts initializing, it will occasionally do the same
thing with the rest of the dmac channel in addition to the core channel.
Example:
[ 1.604375] nouveau 0000:01:00.0: disp: outp 04:0006:0f81: no heads (0 3 4)
[ 1.604858] nouveau 0000:01:00.0: disp: outp 04:0006:0f81: aux power -> always
[
2017 Sep 19
6
[Bug 102860] New: Nvidia 940MX (NV118, GM108) is reported as a NV117, GM107
https://bugs.freedesktop.org/show_bug.cgi?id=102860
Bug ID: 102860
Summary: Nvidia 940MX (NV118, GM108) is reported as a NV117,
GM107
Product: xorg
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: minor
Priority: medium
Component:
2007 Apr 18
1
Screensaver flashing instead of normal function
I rebooted my machine this morning and now instead of running normally, my
GLMatrix screen saver flashes as it repaints the screen, more and more
noticeably as the screen fills up with glyphs. I didn't change ANYTHING and
this was not happening before the boot.
Anyone have any ideas why this might be?
Thanks.
Mark Hull-Richter, Linux Kernel Engineer
DATAllegro (www.datallegro.com)
85