similar to: [Bug 91523] New: [NVE7] driver cannot initialize gpu(failed to parse ramcfg data)

Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/ramcfg.h | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/bios/rammap.c | 3 ++- drivers/gpu/drm/nouveau/nvkm/subdev/bios/timing.c | 2 ++ drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c | 6 ++++-- 4 files changed, 9 insertions(+), 3 deletions(-) diff --git

Hello, Attached a small patch that correctly identifies the DLLoff bit for >=GF100. Marked RFC because I haven't seen any GDDR5 samples that *enable* the DLL. I'd like to verify whether the DLL should be reset when enabled. Could increase likelihood of succesfull reclock. Ben: could you do some experiments with this bit to see if GDDR5 needs some DLL reset logic? Thanks, and happy

https://bugs.freedesktop.org/show_bug.cgi?id=76475 Priority: medium Bug ID: 76475 Assignee: nouveau at lists.freedesktop.org Summary: Nouveau fails to load due to unknown opcode 0x80 QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: patrick.clara at

https://bugs.freedesktop.org/show_bug.cgi?id=77494 Priority: medium Bug ID: 77494 Assignee: nouveau at lists.freedesktop.org Summary: [NVE7] fails to load due to unknown opcode 0xc4 QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mpredosin at

Patch 1 fixes nva3 bailing due to not finding the right ramcfg Patch 2 is a resend rebased on 3.17.0-rc4 for setting the vblank period Patch 3-5 handle writes to per-partition registers, for which NVA3 does not have special broadcast regs available. Patch 6 removes local structs from NVA3 reclocking in favour of the already existing "ram->base." variables, like in NVE0 As always,

Adds reclocking for NVA0, and a whole lot of work for other cards. Had these patches collecting dust for a little, but tested them with both my NVA0, and Martin's a while back. Success not guaranteed, but should be quite a leap forward. Happy reviewing and testing. Cheers, Roy

Following a series of patches that implement memory reclocking for NVA3/5/8 with DDR2, DDR3 and GDDR3 on board. I tested these patches on 6 different graphics cards, but I expect reclocking now to work on many more. Testers can pick up these patches and test it by enabling pstate (nouveau.pstate=1). They should then be able to change clocks by writing to /sys/class/drm/card0/device/pstate. Correct

In correspondence with the other ram_calc implementations. Signed-off-by: Roy Spliet <nouveau at spliet.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c | 37 ++++++++++++----------- 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c index 093223d..fffd01a 100644 ---

Hi, Static Analysis with CoverityScan as detected an issue with the setting of the RON pull value in function nvkm_gddr3_calc in drm/nouveau/bios/ramcfg.c This was introduced by commit: c25bf7b6155cb ("drm/nouveau/bios/ramcfg: Separate out RON pull value") CoverityScan reports the issue as follows: 84 case 0x20: 85 CWL = (ram->next->bios.timing[1] &

From: Colin Ian King <colin.king at canonical.com> Currently, the expression for calculating RON is always going to result in zero no matter the value of ram->mr[1] because the ! operator has higher precedence than the shift >> operator. I believe the missing parentheses around the expression before appying the ! operator will result in the desired result. [ Note, not tested ]

From: Colin Ian King <colin.king at canonical.com> [ Upstream commit 13649101a25c53c87f4ab98a076dfe61f3636ab1 ] Currently, the expression for calculating RON is always going to result in zero no matter the value of ram->mr[1] because the ! operator has higher precedence than the shift >> operator. I believe the missing parentheses around the expression before appying the !

From: Colin Ian King <colin.king at canonical.com> [ Upstream commit 13649101a25c53c87f4ab98a076dfe61f3636ab1 ] Currently, the expression for calculating RON is always going to result in zero no matter the value of ram->mr[1] because the ! operator has higher precedence than the shift >> operator. I believe the missing parentheses around the expression before appying the !

From: Colin Ian King <colin.king at canonical.com> [ Upstream commit 13649101a25c53c87f4ab98a076dfe61f3636ab1 ] Currently, the expression for calculating RON is always going to result in zero no matter the value of ram->mr[1] because the ! operator has higher precedence than the shift >> operator. I believe the missing parentheses around the expression before appying the !

From: Colin Ian King <colin.king at canonical.com> [ Upstream commit 13649101a25c53c87f4ab98a076dfe61f3636ab1 ] Currently, the expression for calculating RON is always going to result in zero no matter the value of ram->mr[1] because the ! operator has higher precedence than the shift >> operator. I believe the missing parentheses around the expression before appying the !

https://bugs.freedesktop.org/show_bug.cgi?id=89558 Bug ID: 89558 Summary: Unknown chipset error for GeForce 840M Product: xorg Version: unspecified Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

v2: style fixes Signed-off-by: Roy Spliet <r.spliet at student.tudelft.nl> --- drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +- drivers/gpu/drm/nouveau/nouveau_mem.c | 25 +++++++++++++++++++------ 2 files changed, 20 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h index b8fa77d..fe242a3 100644 ---

https://bugs.freedesktop.org/show_bug.cgi?id=87179 Bug ID: 87179 Summary: [NVE7] Oops while reenabling Optimus dedicated card Product: xorg Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

https://bugs.freedesktop.org/show_bug.cgi?id=69819 Priority: medium Bug ID: 69819 Assignee: nouveau at lists.freedesktop.org Summary: [NVE7] can't able start X dsiplay Severity: normal Classification: Unclassified OS: All Reporter: samdraiz at gmail.com Hardware: Other Status: NEW

https://bugs.freedesktop.org/show_bug.cgi?id=80865 Ilia Mirkin <imirkin at alum.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Hard hang (GPC0/TPC0/MP |[NVE7] Hard hang |trap: MULTIPLE_WARP_ERRORS |(GPC0/TPC0/MP trap:

https://bugs.freedesktop.org/show_bug.cgi?id=80865 --- Comment #6 from tethys at gmail.com --- localhost:~# rpm -qa | fgrep mesa mesa-libGL-10.1.5-1.20140607.fc20.i686 mesa-libglapi-10.1.5-1.20140607.fc20.x86_64 mesa-filesystem-10.1.5-1.20140607.fc20.x86_64 mesa-libglapi-10.1.5-1.20140607.fc20.i686 mesa-libGLU-9.0.0-5.fc20.x86_64 mesa-libgbm-10.1.5-1.20140607.fc20.x86_64