[Nouveau] [Bug 63051] Displist with multiple OpenGL contexts crashes.
https://bugs.freedesktop.org/show_bug.cgi?id=63051 --- Comment #1 from Ilia Mirkin imir...@alum.mit.edu --- What hardware are you on? It looks like you were using mesa-9.1 -- can you try 10.0.x? I'm looking at installing blender, but it seems like Gentoo has gone out of their way to make it a giant pain by requiring python3.3 for everything. Can you get a backtrace, preferably with debug symbols? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 54587] [NV1F] Flickering screen on Geforece 4
https://bugs.freedesktop.org/show_bug.cgi?id=54587 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added Summary|Flickering screen on|[NV1F] Flickering screen on |Geforece 4 |Geforece 4 --- Comment #19 from Ilia Mirkin imir...@alum.mit.edu --- Your logs are from very old versions of nouveau. Does this still happen with a recent kernel (e.g. 3.13.x)? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 67628] [NVC1] [BISECTED] Monitor on Display port shows distortions
https://bugs.freedesktop.org/show_bug.cgi?id=67628 --- Comment #10 from Torsten Wagner torsten.wag...@gmail.com --- Hi Ilia, thanks for the feedback. Attached you will find the kernel log of an working and non-working kernel. A quick look showed that the non-working kernel reads in (or simply log) much more data from the display port init. The lines below can be found in the NON working kernel but not in the working one NOT WORKING KERNEL: (grep DP) [1.742406] nouveau T[ VBIOS][:01:00.0] 0x57ab[1]: DP_CONDITION0x05 0x15 [1.742584] nouveau T[ VBIOS][:01:00.0] 0x591d[ ]: DP_CONDITION0x00 0x08 [1.742589] nouveau D[ PDISP][:01:00.0] DP:0006:0342: 2 lanes at 27 KB/s [1.742772] nouveau D[ PDISP][:01:00.0] DP:0006:0342: training pattern 1 [1.743115] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 0 00 [1.743122] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 1 00 [1.743796] nouveau D[ PDISP][:01:00.0] DP:0006:0342: status 00 00 00 00 cc cc [1.743797] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 0 38 [1.743807] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 1 38 [1.744478] nouveau D[ PDISP][:01:00.0] DP:0006:0342: status 11 00 00 00 cc cc [1.744479] nouveau D[ PDISP][:01:00.0] DP:0006:0342: training pattern 2 [1.745486] nouveau D[ PDISP][:01:00.0] DP:0006:0342: status 11 00 00 00 cc cc [1.745487] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 0 38 [1.745493] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 1 38 [1.746432] nouveau D[ PDISP][:01:00.0] DP:0006:0342: status 11 00 00 00 88 88 [1.746432] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 0 10 [1.746443] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 1 10 [1.747381] nouveau D[ PDISP][:01:00.0] DP:0006:0342: status 11 00 00 00 44 44 [1.747382] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 0 08 [1.747390] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 1 08 [1.748330] nouveau D[ PDISP][:01:00.0] DP:0006:0342: status 11 00 00 00 00 00 [1.748331] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 0 00 [1.748340] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 1 00 [1.749301] nouveau D[ PDISP][:01:00.0] DP:0006:0342: status 11 00 00 00 44 44 [1.749301] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 0 08 [1.749308] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 1 08 [1.750265] nouveau D[ PDISP][:01:00.0] DP:0006:0342: status 77 00 01 00 44 44 [1.750265] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 0 08 [1.750272] nouveau D[ PDISP][:01:00.0] DP:0006:0342: config lane 1 08 [1.750596] nouveau D[ PDISP][:01:00.0] DP:0006:0342: training pattern 0 [1.751350] nouveau T[ VBIOS][:01:00.0] 0x58fd[0]: DP_CONDITION0x00 0x11 vs. WORKING KERNEL (grep DP) [5.677400] nouveau T[ VBIOS][:01:00.0] 0x57ab[1]: DP_CONDITION0x05 0x15 [5.677577] nouveau T[ VBIOS][:01:00.0] 0x591d[ ]: DP_CONDITION0x00 0x08 [5.686368] nouveau T[ VBIOS][:01:00.0] 0x58fd[0]: DP_CONDITION0x00 0x11 As you can see, the entire PDISP part is missing not sure it is simply not logged or it is a new feature which creates the problem. Thanks for looking into this On 5 February 2014 04:21, bugzilla-dae...@freedesktop.org wrote: Comment # 9 on bug 67628 from Ilia Mirkin Can you post boot logs of kernels with and without the problem booted with nouveau.debug=trace drm.debug=0xe You are receiving this mail because: You reported the bug. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 40747] [NV44] dual-link tmds no longer allowed
https://bugs.freedesktop.org/show_bug.cgi?id=40747 --- Comment #20 from Oswald Buddenhagen o...@kde.org --- huh? i said that it is *easy* to convince the kernel to pick the right mode. it's picking a wrong one only automatically. there is no hardware limitation at all here. X appears more tenacious, apparently because it filters out the good mode earlier in the process. it's beyond me why it does that - it makes no sense at all, and the log doesn't indicate anything afaics. this also puts a weird twist on the meaning of _K_MS ... also note that i'm a different person than the OP. i just happen to have pretty much the same configuration (card and monitor) and consequently the same problem. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 72180] [NVE6] Random GPU Lockups, works with blob PGRAPH fw
https://bugs.freedesktop.org/show_bug.cgi?id=72180 --- Comment #29 from Dainius Masiliūnas past...@gmail.com --- With some help I extracted the firmware myself, but the result is the same as before, GPU still hangs often, especially when OpenGL compositing is on. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 72207] [NV67] Error retrieving EDID from VGA
https://bugs.freedesktop.org/show_bug.cgi?id=72207 --- Comment #2 from Priit Laes (irc: plaes) pl...@plaes.org --- (In reply to comment #1) I assume there's a monitor actually connected (that supports EDID)? Did this work with older kernels (if so which)? Please upload a copy of your VBIOS (/sys/kernel/debug/dri/0/vbios.rom) OK, had finally change to test this display (Samsung SyncMaster 2043NW) with another machine (Lenovo X60s laptop) which had the same issue: [83002.030045] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 [83002.030054] Raw EDID: [83002.030060] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff [83002.030063] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.030067] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.030070] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.030073] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.030076] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.030080] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.030083] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.049040] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 [83002.049050] Raw EDID: [83002.049056] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff [83002.049059] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.049063] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.049066] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.049069] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.049073] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.049076] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.049079] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.068039] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 [83002.068048] Raw EDID: [83002.068053] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff [83002.068057] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.068061] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.068064] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.068067] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.068070] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.068073] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.068077] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.087039] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 [83002.087048] Raw EDID: [83002.087054] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff [83002.087058] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.087061] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.087065] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.087068] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.087071] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.087074] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.087077] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [83002.087087] i915 :00:02.0: VGA-1: EDID block 0 invalid. It is fairly old machine and before I installed Fedora on that it was virus-infested Windows XP which apparently supplies better default EDID data in case something goes wrong... -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 72207] [NV67] Error retrieving EDID from VGA
https://bugs.freedesktop.org/show_bug.cgi?id=72207 --- Comment #3 from Priit Laes (irc: plaes) pl...@plaes.org --- Created attachment 93461 -- https://bugs.freedesktop.org/attachment.cgi?id=93461action=edit GeForce-7050-vbios.rom Supplying the rom for completeness :) -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 40747] [NV44] dual-link tmds no longer allowed
https://bugs.freedesktop.org/show_bug.cgi?id=40747 --- Comment #21 from Ilia Mirkin imir...@alum.mit.edu --- (In reply to comment #20) huh? i said that it is *easy* to convince the kernel to pick the right mode. it's picking a wrong one only automatically. Really? It sounds to me like you managed to fool the drm mode-verification logic (or nouveau's is implemented incorrectly). If it was merely picking the wrong one, the 1600x1200 one would be in the mode list, and it is not. there is no hardware limitation at all here. Maybe, maybe not. Should be fairly easy to check. One way to do that would be to try the thing I said. Or to change the 165mhz check to be = 0x44 instead of 0x46. X appears more tenacious, apparently because it filters out the good mode earlier in the process. it's beyond me why it does that - it makes no sense It just gets the list from the kernel. What's in /sys/class/drm/card0-DVI-I-1/modes (or whatever the connector is)? The thing you (or someone else) saw with X seeing the 1600x1200 mode was it reading it from DDC. But I'm pretty sure it doesn't care about that -- X doesn't handle modesetting, the kernel does, and it uses its mode list. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 3/3] drm/nv4c/bios: disallow retrieving from prom on nv4x igp's
Suggested-by: Marcin Kościelnicki koria...@0x04.net Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c index aa0fbbe..ef0c9c4 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c @@ -130,6 +130,10 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios) u16 pcir; int i; + /* there is no prom on nv4x IGP's */ + if (device-card_type == NV_40 device-chipset = 0x4c) + return; + /* enable access to rom */ if (device-card_type = NV_50) pcireg = 0x088050; -- 1.8.3.2 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 1/3] drm/nv4c/mc: nv4x igp's have a different msi rearm register
See https://bugs.freedesktop.org/show_bug.cgi?id=74492
Reported-by: Ronald ronald...@gmail.com
Suggested-by: Marcin Kościelnicki koria...@0x04.net
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
drivers/gpu/drm/nouveau/Makefile | 1 +
drivers/gpu/drm/nouveau/core/engine/device/nv40.c | 10 ++---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/nv04.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/nv44.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/mc/nv4c.c | 45 +++
6 files changed, 54 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/mc/nv4c.c
diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index e88145b..d310c19 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -141,6 +141,7 @@ nouveau-y += core/subdev/mc/base.o
nouveau-y += core/subdev/mc/nv04.o
nouveau-y += core/subdev/mc/nv40.o
nouveau-y += core/subdev/mc/nv44.o
+nouveau-y += core/subdev/mc/nv4c.o
nouveau-y += core/subdev/mc/nv50.o
nouveau-y += core/subdev/mc/nv94.o
nouveau-y += core/subdev/mc/nv98.o
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nv40.c
b/drivers/gpu/drm/nouveau/core/engine/device/nv40.c
index 1b653dd..08b8859 100644
--- a/drivers/gpu/drm/nouveau/core/engine/device/nv40.c
+++ b/drivers/gpu/drm/nouveau/core/engine/device/nv40.c
@@ -311,7 +311,7 @@ nv40_identify(struct nouveau_device *device)
device-oclass[NVDEV_SUBDEV_CLOCK ] = nv40_clock_oclass;
device-oclass[NVDEV_SUBDEV_THERM ] = nv40_therm_oclass;
device-oclass[NVDEV_SUBDEV_DEVINIT] = nv1a_devinit_oclass;
- device-oclass[NVDEV_SUBDEV_MC ] = nv44_mc_oclass;
+ device-oclass[NVDEV_SUBDEV_MC ] = nv4c_mc_oclass;
device-oclass[NVDEV_SUBDEV_BUS] = nv31_bus_oclass;
device-oclass[NVDEV_SUBDEV_TIMER ] = nv04_timer_oclass;
device-oclass[NVDEV_SUBDEV_FB ] = nv46_fb_oclass;
@@ -334,7 +334,7 @@ nv40_identify(struct nouveau_device *device)
device-oclass[NVDEV_SUBDEV_CLOCK ] = nv40_clock_oclass;
device-oclass[NVDEV_SUBDEV_THERM ] = nv40_therm_oclass;
device-oclass[NVDEV_SUBDEV_DEVINIT] = nv1a_devinit_oclass;
- device-oclass[NVDEV_SUBDEV_MC ] = nv44_mc_oclass;
+ device-oclass[NVDEV_SUBDEV_MC ] = nv4c_mc_oclass;
device-oclass[NVDEV_SUBDEV_BUS] = nv31_bus_oclass;
device-oclass[NVDEV_SUBDEV_TIMER ] = nv04_timer_oclass;
device-oclass[NVDEV_SUBDEV_FB ] = nv4e_fb_oclass;
@@ -357,7 +357,7 @@ nv40_identify(struct nouveau_device *device)
device-oclass[NVDEV_SUBDEV_CLOCK ] = nv40_clock_oclass;
device-oclass[NVDEV_SUBDEV_THERM ] = nv40_therm_oclass;
device-oclass[NVDEV_SUBDEV_DEVINIT] = nv1a_devinit_oclass;
- device-oclass[NVDEV_SUBDEV_MC ] = nv44_mc_oclass;
+ device-oclass[NVDEV_SUBDEV_MC ] = nv4c_mc_oclass;
device-oclass[NVDEV_SUBDEV_BUS] = nv31_bus_oclass;
device-oclass[NVDEV_SUBDEV_TIMER ] = nv04_timer_oclass;
device-oclass[NVDEV_SUBDEV_FB ] = nv46_fb_oclass;
@@ -380,7 +380,7 @@ nv40_identify(struct nouveau_device *device)
device-oclass[NVDEV_SUBDEV_CLOCK ] = nv40_clock_oclass;
device-oclass[NVDEV_SUBDEV_THERM ] = nv40_therm_oclass;
device-oclass[NVDEV_SUBDEV_DEVINIT] = nv1a_devinit_oclass;
- device-oclass[NVDEV_SUBDEV_MC ] = nv44_mc_oclass;
+ device-oclass[NVDEV_SUBDEV_MC ] = nv4c_mc_oclass;
device-oclass[NVDEV_SUBDEV_BUS] = nv31_bus_oclass;
device-oclass[NVDEV_SUBDEV_TIMER ] = nv04_timer_oclass;
device-oclass[NVDEV_SUBDEV_FB ] = nv46_fb_oclass;
@@ -403,7 +403,7 @@ nv40_identify(struct nouveau_device *device)
device-oclass[NVDEV_SUBDEV_CLOCK ] = nv40_clock_oclass;
device-oclass[NVDEV_SUBDEV_THERM ] = nv40_therm_oclass;
device-oclass[NVDEV_SUBDEV_DEVINIT] = nv1a_devinit_oclass;
- device-oclass[NVDEV_SUBDEV_MC ] = nv44_mc_oclass;
+ device-oclass[NVDEV_SUBDEV_MC ] = nv4c_mc_oclass;
device-oclass[NVDEV_SUBDEV_BUS] = nv31_bus_oclass;
device-oclass[NVDEV_SUBDEV_TIMER ] = nv04_timer_oclass;
device-oclass[NVDEV_SUBDEV_FB ] = nv46_fb_oclass;
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index adc88b7..3c6738e 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -47,6 +47,7 @@ struct nouveau_mc_oclass {
extern struct
[Nouveau] [PATCH 2/3] drm/nv4c/vga: decode register is in a different place on nv4x igp's
Suggested-by: Marcin Kościelnicki koria...@0x04.net
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
drivers/gpu/drm/nouveau/nouveau_vga.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index 81638d7..471347e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -14,7 +14,9 @@ nouveau_vga_set_decode(void *priv, bool state)
{
struct nouveau_device *device = nouveau_dev(priv);
- if (device-chipset = 0x40)
+ if (device-card_type == NV_40 device-chipset = 0x4c)
+ nv_wr32(device, 0x088060, state);
+ else if (device-chipset = 0x40)
nv_wr32(device, 0x088054, state);
else
nv_wr32(device, 0x001854, state);
--
1.8.3.2
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 74492] v3.13-rc8 nv4e + msi = random lockups
https://bugs.freedesktop.org/show_bug.cgi?id=74492 --- Comment #9 from Ronald ronald...@gmail.com --- I noticed, thanks! -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 74492] v3.13-rc8 nv4e + msi = random lockups
https://bugs.freedesktop.org/show_bug.cgi?id=74492 --- Comment #8 from Ilia Mirkin imir...@alum.mit.edu --- Looks like the nv4x igp's have some registers placed differently... I just cc'd you on a few patches, you can also get them at: http://lists.freedesktop.org/archives/nouveau/2014-February/016032.html http://lists.freedesktop.org/archives/nouveau/2014-February/016033.html http://lists.freedesktop.org/archives/nouveau/2014-February/016034.html -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 70972] [NV67] Modesetting failure at 1280x800
https://bugs.freedesktop.org/show_bug.cgi?id=70972 --- Comment #7 from Ilia Mirkin imir...@alum.mit.edu --- No clue if this will help, but we recently noticed that the NV4x IGP's have some differences in register placement. Perhaps this patch: http://lists.freedesktop.org/archives/nouveau/2014-February/016033.html will help something. (See nouveau list for another patch that possibly fixes MSI that comes with 3.13.) -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RFC 10/16] drm/nouveau/timer: skip calibration on GK20A
On 02/04/2014 01:39 AM, Alexandre Courbot wrote: On 02/04/2014 12:55 PM, Ben Skeggs wrote: On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot acour...@nvidia.com wrote: GK20A's timer is directly attached to the system timer and cannot be calibrated. Skip the calibration phase on that chip since the corresponding registers do not exist. Just a curiosity: What timer resolution does the HW initialise at? On T124 the timer input is the oscillator clock, which depending on the device can run between 12 and 48Mhz (IIUC). On the one Tegra124 board we support upstream, the crystal is 12MHz. I believe this is a typical/common value; almost all the Tegra boards we support upstream run at this rate. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 70972] [NV67] Modesetting failure at 1280x800
https://bugs.freedesktop.org/show_bug.cgi?id=70972 --- Comment #8 from Larry Finger larry.fin...@lwfinger.net --- I am now running 3.14-rc1, and the MSI changes for 3.13 should be in my kernel. I added the patch mentioned in comment #7. I did not alter my xorg.conf.d setup and X did not start, but I still had the screen double-up/faulty wrap in the text screen. Thanks for notifying me. Perhaps there are other register location differences. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 70972] [NV67] Modesetting failure at 1280x800
https://bugs.freedesktop.org/show_bug.cgi?id=70972 --- Comment #9 from Ilia Mirkin imir...@alum.mit.edu --- Well, unrelated to this issue, you probably need http://lists.freedesktop.org/archives/nouveau/2014-February/016032.html For MSI to work properly. We've had reports of issues for people on NV4E, and it's also been confirmed that the registers are in a different place for NV63. It's very likely to also be different on NV67. You can also disable MSI by using nouveau.config=NvMSI=0 . (However if you can confirm that this patch either helps or breaks things, that would be nice -- not a lot of people with this HW.) -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 70972] [NV67] Modesetting failure at 1280x800
https://bugs.freedesktop.org/show_bug.cgi?id=70972 --- Comment #10 from Larry Finger larry.fin...@lwfinger.net --- Unfortunately, neither the patch nor the patch and the nouveau.config boot change made any difference. I certainly understand that not many people have this hardware. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [GSoC2014] Call for projects ideas and mentors
Hi, fellow graphics stack developers, Now that FOSDEM is over, it is time to think about the Google Summer of Code 2014! If you would like to propose a project for the GSoC 2014, please write your proposals at [1], before the 14th of February, in order to increase our chances of being an accepted organization. If you simply would potentially be interested in being a mentor, please also contact me as Google wants to have an estimate of the number of potential mentors we would have. If you have any questions regarding the GSoC or need any additional information, please answer in this thread. Cheers, Martin [1] http://xorg.freedesktop.org/wiki/SummerOfCodeIdeas/ ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
