[Nouveau] [PATCH] drm/nouveau: fix null pointer deref on init

2013-03-05 Thread Maarten Lankhorst
My nv96 claims to have a DCB_OUTPUT_TV, which is currently not implemented for 
nv50, this triggers the following oops:

[   30.110017] nouveau W[ DRM] failed to create encoder 0/1/0: -19
[   30.110020] nouveau W[ DRM] TV-1 has no encoders, removing
[   30.134089] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[   30.134096] IP: [a0366f69] nv50_crtc_destroy+0x29/0x110 [nouveau]
[   30.134127] PGD 0
[   30.134129] Oops:  [#1] PREEMPT SMP
[   30.134131] Modules linked in: snd_hda_codec_realtek snd_hda_intel 
snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_seq_midi snd_seq_midi_event 
nouveau(+) snd_rawmidi snd_seq kvm_intel kvm snd_seq_device snd_timer 
usb_storage video fan thermal drm_kms_helper snd ttm drm acpi_cpufreq mperf 
soundcore processor agpgart thermal_sys mei parport_pc ppdev parport nfsd
[   30.134151] CPU 0
[   30.134154] Pid: 557, comm: modprobe Not tainted 3.9.0-rc1-patser+ #1116 
Acer Aspire M3985/Aspire M3985
[   30.134157] RIP: 0010:[a0366f69]  [a0366f69] 
nv50_crtc_destroy+0x29/0x110 [nouveau]
[   30.134179] RSP: 0018:880261e65928  EFLAGS: 00010286
[   30.134182] RAX: 88025c2a9e40 RBX: 8802832ac000 RCX: 8800
[   30.134184] RDX: 002a RSI: 8802832aca60 RDI: 8802832ac000
[   30.134186] RBP: 880261e65948 R08: 00029cd39000 R09: 0001
[   30.134188] R10: 0002 R11:  R12: 
[   30.134190] R13: 88028314e468 R14: a03be590 R15: 88025c2a9e40
[   30.134193] FS:  7fba2ff1b740() GS:88029c60() 
knlGS:
[   30.134196] CS:  0010 DS:  ES:  CR0: 80050033
[   30.134198] CR2:  CR3: 000261a1a000 CR4: 001407f0
[   30.134200] DR0:  DR1:  DR2: 
[   30.134203] DR3:  DR6: 0ff0 DR7: 0400
[   30.134205] Process modprobe (pid: 557, threadinfo 880261e64000, task 
880261e621c0)
[   30.134208] Stack:
[   30.134209]  88028314e000 88028314e478 880282d08000 
88028314e000
[   30.134213]  880261e65978 a0121190 880261e65968 
88028314e000
[   30.134216]  ffed 5fc41aa0 880261e659d8 
a0337bf5
[   30.134220] Call Trace:
[   30.134230]  [a0121190] drm_mode_config_cleanup+0x1a0/0x1f0 [drm]
[   30.134252]  [a0337bf5] nouveau_display_create+0x445/0x820 
[nouveau]
[   30.134272]  [a032102a] nouveau_drm_load+0x3aa/0x980 [nouveau]
[   30.134277]  [813f2d89] ? device_register+0x19/0x20
[   30.134284]  [a011d931] ? drm_sysfs_device_add+0x81/0xb0 [drm]
[   30.134292]  [a011c129] drm_get_pci_dev+0x179/0x290 [drm]
[   30.134295]  [8135c856] ? __pci_set_master+0x26/0x80
[   30.134315]  [a032002a] nouveau_drm_probe+0x25a/0x290 [nouveau]
[   30.134318]  [81360946] local_pci_probe+0x46/0x80
[   30.134321]  [81362179] pci_device_probe+0xf9/0x120
[   30.134324]  [813f5336] driver_probe_device+0x76/0x220
[   30.134327]  [813f557b] __driver_attach+0x9b/0xa0
[   30.134330]  [813f54e0] ? driver_probe_device+0x220/0x220
[   30.134333]  [813f3876] bus_for_each_dev+0x56/0x90
[   30.134335]  [813f4e89] driver_attach+0x19/0x20
[   30.134338]  [813f49be] bus_add_driver+0xee/0x250
[   30.134341]  [813f5a75] driver_register+0x75/0x150
[   30.134344]  [81361186] __pci_register_driver+0x46/0x50
[   30.134350]  [a011c35a] drm_pci_init+0x11a/0x130 [drm]
[   30.134353]  [a01b3000] ? 0xa01b2fff
[   30.134356]  [a01b3000] ? 0xa01b2fff
[   30.134371]  [a01b304d] nouveau_drm_init+0x4d/0x1000 [nouveau]
[   30.134375]  [8100021a] do_one_initcall+0x3a/0x160
[   30.134379]  [8109bf96] load_module+0x1be6/0x2320
[   30.134382]  [810992e0] ? show_initstate+0x50/0x50
[   30.134386]  [8109c774] sys_init_module+0xa4/0xd0
[   30.134389]  [816cae52] system_call_fastpath+0x16/0x1b
[   30.134391] Code: 1f 00 55 48 8d b7 60 0a 00 00 48 89 e5 41 54 53 48 89 fb 
48 83 ec 10 48 8b 07 48 8b 80 20 03 00 00 48 8b 80 68 0b 00 00 4c 8b 20 49 8b 
3c 24 e8 9e fd ff ff 49 8b 3c 24 48 8d b3 a8 0a 00 00 e8
[   30.134414] RIP  [a0366f69] nv50_crtc_destroy+0x29/0x110 [nouveau]
[   30.134434]  RSP 880261e65928
[   30.134436] CR2: 
[   30.134692] ---[ end trace 4678de513b8e8da0 ]---

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com

---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index a4d2d3a..b044c4a 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -1271,10 +1271,14 @@ nv50_crtc_destroy(struct drm_crtc *crtc)
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
struct nv50_disp *disp = 

[Nouveau] [Bug 61854] New: [nv50]glClipPlane not clipping correctly for glsl

2013-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61854

  Priority: medium
Bug ID: 61854
  Assignee: nouveau@lists.freedesktop.org
   Summary: [nv50]glClipPlane not clipping correctly for glsl
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: b...@taniwha.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/DRI/nouveau
   Product: Mesa

Created attachment 75953
  -- https://bugs.freedesktop.org/attachment.cgi?id=75953action=edit
blender file demonstrating FF vs GLSL behavior of glClipPlane

hw: NVIDIA Corporation G80 [GeForce 8800 GTS] (rev a2)


The problem was found using the alt-b clipping border option in blender.

In blender's default scene, press alt-b with the mouse in the 3d view and
select part of the cube. It gets clipped properly. However, turn on matcap
(press N to get the properties panel, scroll down and open the display
sub-panel, and turn on Matcap) and the clipping of the cube will depend on
the viewer's position and angle with respect to the clipping planes. However,
the highlighted wire-frame of the cube is always clipped correctly.

I was told by Ton (blender leader) that blender uses glClipPlane for the
clipping border, and that enabling matcap simply causes blender to use glsl for
the solid rendering.

Although I've included the url to the bug report in blender's bug tracker, I've
also attached the same blend file to this report. For the blend file, turning
off matcap will cause the cube to clip correctly, independently of the viewer's
position and angle. Zooming in a little (mouse wheel) with matcap enabled will
cause the cube's surface to become partially visible, but it will still be
incorrect.

Blender bug tracker url:
http://projects.blender.org/tracker/?func=detailatid=231aid=34492group_id=9

-- 
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] drm/nouveau: fix regression in vblanking

2013-03-05 Thread Maarten Lankhorst
nv50_vblank_enable/disable got switched from 
NV50_PDISPLAY_INTR_EN_1_VBLANK_CRTC_0 (4)  head to 1  head, which is wrong.

4  head is the correct value.

Fixes regression with vblanking since 1d7c71a3e2f77 drm/nouveau/disp: port 
vblank handling to event interface

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
index 5fa1326..02e369f 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
@@ -544,13 +544,13 @@ nv50_disp_curs_ofuncs = {
 static void
 nv50_disp_base_vblank_enable(struct nouveau_event *event, int head)
 {
-   nv_mask(event-priv, 0x61002c, (1  head), (1  head));
+   nv_mask(event-priv, 0x61002c, (4  head), (4  head));
 }
 
 static void
 nv50_disp_base_vblank_disable(struct nouveau_event *event, int head)
 {
-   nv_mask(event-priv, 0x61002c, (1  head), (0  head));
+   nv_mask(event-priv, 0x61002c, (4  head), 0);
 }
 
 static int

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


Re: [Nouveau] nouveau lockdep splat

2013-03-05 Thread Lucas Stach
Dropping Tegra ML, it's not the place where Nouveau mails should go.
Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.

Am Montag, den 04.03.2013, 22:16 +0100 schrieb Borislav Petkov:
 New -rc1, so let the stabilization games begin.
 
 I see the following on rc1, let me know if you need more info.
 
 
 [0.633617] =
 [0.633618] [ INFO: possible recursive locking detected ]
 [0.633618] 3.9.0-rc1 #2 Not tainted
 [0.633619] -
 [0.633619] swapper/0/1 is trying to acquire lock:
 [0.633623]  (dmac-lock){+.+...}, at: [8141bb53] 
 evo_wait+0x43/0xf0
 [0.633624] 
 [0.633624] but task is already holding lock:
 [0.633626]  (dmac-lock){+.+...}, at: [8141bb53] 
 evo_wait+0x43/0xf0
 [0.633626] 
 [0.633626] other info that might help us debug this:
 [0.633626]  Possible unsafe locking scenario:
 [0.633626] 
 [0.633626]CPU0
 [0.633627]
 [0.633627]   lock(dmac-lock);
 [0.633628]   lock(dmac-lock);
 [0.633628] 
 [0.633628]  *** DEADLOCK ***
 [0.633628] 
 [0.633628]  May be due to missing lock nesting notation
 [0.633628] 
 [0.633629] 10 locks held by swapper/0/1:
 [0.633632]  #0:  (__lockdep_no_validate__){..}, at: 
 [8143375b] __driver_attach+0x5b/0xb0
 [0.633633]  #1:  (__lockdep_no_validate__){..}, at: 
 [81433769] __driver_attach+0x69/0xb0
 [0.633636]  #2:  (drm_global_mutex){+.+.+.}, at: [8135a8f6] 
 drm_get_pci_dev+0xc6/0x2d0
 [0.633640]  #3:  (registration_lock){+.+.+.}, at: [812c8e75] 
 register_framebuffer+0x25/0x310
 [0.633642]  #4:  (fb_info-lock){+.+.+.}, at: [812c7d86] 
 lock_fb_info+0x26/0x60
 [0.633644]  #5:  (console_lock){+.+.+.}, at: [812c900a] 
 register_framebuffer+0x1ba/0x310
 [0.633646]  #6:  ((fb_notifier_list).rwsem){.+.+.+}, at: 
 [810694d2] __blocking_notifier_call_chain+0x42/0x80
 [0.633648]  #7:  (dev-mode_config.mutex){+.+.+.}, at: 
 [8135e63a] drm_modeset_lock_all+0x2a/0x70
 [0.633650]  #8:  (crtc-mutex){+.+.+.}, at: [8135e664] 
 drm_modeset_lock_all+0x54/0x70
 [0.633652]  #9:  (dmac-lock){+.+...}, at: [8141bb53] 
 evo_wait+0x43/0xf0
 [0.633652] 
 [0.633652] stack backtrace:
 [0.633653] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc1 #2
 [0.633654] Call Trace:
 [0.633656]  [8109524b] __lock_acquire+0x76b/0x1c20
 [0.633658]  [8137f50c] ? dcb_table+0x1ac/0x2a0
 [0.633659]  [8141bb53] ? evo_wait+0x43/0xf0
 [0.633660]  [81096c6a] lock_acquire+0x8a/0x120
 [0.633662]  [8141bb53] ? evo_wait+0x43/0xf0
 [0.633664]  [815eaf52] ? mutex_lock_nested+0x292/0x330
 [0.633665]  [815ead2e] mutex_lock_nested+0x6e/0x330
 [0.633667]  [8141bb53] ? evo_wait+0x43/0xf0
 [0.633668]  [815eb0b7] ? __mutex_unlock_slowpath+0xc7/0x150
 [0.633669]  [8141bb53] evo_wait+0x43/0xf0
 [0.633671]  [8141e569] nv50_display_flip_next+0x749/0x7d0
 [0.633672]  [8141bc37] ? evo_kick+0x37/0x40
 [0.633674]  [8141e7ee] nv50_crtc_commit+0x10e/0x230
 [0.633676]  [8134c2a5] drm_crtc_helper_set_mode+0x365/0x510
 [0.633677]  [8134d69e] drm_crtc_helper_set_config+0xa4e/0xb70
 [0.633679]  [8135f751] drm_mode_set_config_internal+0x31/0x70
 [0.633680]  [8134b7a1] drm_fb_helper_set_par+0x71/0xf0
 [0.633682]  [812d40e4] fbcon_init+0x514/0x5a0
 [0.633683]  [8132cbdc] visual_init+0xbc/0x120
 [0.633685]  [8132f293] do_bind_con_driver+0x163/0x320
 [0.633686]  [8132f521] do_take_over_console+0x61/0x70
 [0.633687]  [812d2703] do_fbcon_takeover+0x63/0xc0
 [0.633689]  [812d63dd] fbcon_event_notify+0x5fd/0x700
 [0.633690]  [815f23fd] notifier_call_chain+0x4d/0x70
 [0.633691]  [810694e8] __blocking_notifier_call_chain+0x58/0x80
 [0.633692]  [81069526] blocking_notifier_call_chain+0x16/0x20
 [0.633694]  [812c787b] fb_notifier_call_chain+0x1b/0x20
 [0.633695]  [812c9018] register_framebuffer+0x1c8/0x310
 [0.633696]  [8134b4d1] drm_fb_helper_initial_config+0x371/0x520
 [0.633697]  [8134a607] ? 
 drm_fb_helper_single_add_all_connectors+0x47/0xf0
 [0.633700]  [81140a5e] ? kmem_cache_alloc_trace+0xee/0x150
 [0.633701]  [8140578e] nouveau_fbcon_init+0x10e/0x160
 [0.633703]  [813f5f8a] nouveau_drm_load+0x40a/0x5d0
 [0.633705]  [81430cee] ? device_register+0x1e/0x30
 [0.633706]  [8135c086] ? drm_sysfs_device_add+0x86/0xb0
 [0.633708]  [8135a9b6] drm_get_pci_dev+0x186/0x2d0
 [0.633710]  [812b0eab] ? __pci_set_master+0x2b/0x90
 [0.633711]  [813f63ba] 

Re: [Nouveau] [PATCH] drm/nouveau: fix regression in vblanking

2013-03-05 Thread Marcin Slusarz
On Tue, Mar 05, 2013 at 02:59:26PM +0100, Maarten Lankhorst wrote:
 nv50_vblank_enable/disable got switched from 
 NV50_PDISPLAY_INTR_EN_1_VBLANK_CRTC_0 (4)  head to 1  head, which is 
 wrong.
 
 4  head is the correct value.
 
 Fixes regression with vblanking since 1d7c71a3e2f77 drm/nouveau/disp: port 
 vblank handling to event interface
 
 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
 ---
 diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c 
 b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
 index 5fa1326..02e369f 100644
 --- a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
 +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
 @@ -544,13 +544,13 @@ nv50_disp_curs_ofuncs = {
  static void
  nv50_disp_base_vblank_enable(struct nouveau_event *event, int head)
  {
 - nv_mask(event-priv, 0x61002c, (1  head), (1  head));
 + nv_mask(event-priv, 0x61002c, (4  head), (4  head));
  }
  
  static void
  nv50_disp_base_vblank_disable(struct nouveau_event *event, int head)
  {
 - nv_mask(event-priv, 0x61002c, (1  head), (0  head));
 + nv_mask(event-priv, 0x61002c, (4  head), 0);
  }
  
  static int
 

It fixes vblank on my NVA8, thanks.

Tested-by: Marcin Slusarz marcin.slus...@gmail.com
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [RFC PATCH] drm/nouveau: use vmalloc for pgt allocation

2013-03-05 Thread Marcin Slusarz
Page tables on nv50 take 48kB, which can be hard to allocate in one piece.
Let's use vmalloc.

Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: sta...@vger.kernel.org [3.7+]
---
 drivers/gpu/drm/nouveau/core/subdev/vm/base.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
index 77c67fc..e66fb77 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
@@ -362,7 +362,7 @@ nouveau_vm_create(struct nouveau_vmmgr *vmm, u64 offset, 
u64 length,
vm-fpde = offset  (vmm-pgt_bits + 12);
vm-lpde = (offset + length - 1)  (vmm-pgt_bits + 12);
 
-   vm-pgt  = kcalloc(vm-lpde - vm-fpde + 1, sizeof(*vm-pgt), 
GFP_KERNEL);
+   vm-pgt  = vzalloc((vm-lpde - vm-fpde + 1) * sizeof(*vm-pgt));
if (!vm-pgt) {
kfree(vm);
return -ENOMEM;
@@ -371,7 +371,7 @@ nouveau_vm_create(struct nouveau_vmmgr *vmm, u64 offset, 
u64 length,
ret = nouveau_mm_init(vm-mm, mm_offset  12, mm_length  12,
  block  12);
if (ret) {
-   kfree(vm-pgt);
+   vfree(vm-pgt);
kfree(vm);
return ret;
}
@@ -446,7 +446,7 @@ nouveau_vm_del(struct nouveau_vm *vm)
}
 
nouveau_mm_fini(vm-mm);
-   kfree(vm-pgt);
+   vfree(vm-pgt);
kfree(vm);
 }
 
-- 
1.8.1.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [PATCH] drm/nouveau: fix crash in vram manager debug callback

2013-03-05 Thread Marcin Slusarz
It's probably impossible to hit it now on mainline kernel.
I only noticed it because one of my debugging patches uses it.

Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 9be9cb5..9c60ef6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -35,14 +35,16 @@
 static int
 nouveau_vram_manager_init(struct ttm_mem_type_manager *man, unsigned long 
psize)
 {
-   /* nothing to do */
+   struct nouveau_drm *drm = nouveau_bdev(man-bdev);
+   struct nouveau_fb *pfb = nouveau_fb(drm-device);
+   man-priv = pfb;
return 0;
 }
 
 static int
 nouveau_vram_manager_fini(struct ttm_mem_type_manager *man)
 {
-   /* nothing to do */
+   man-priv = NULL;
return 0;
 }
 
@@ -104,7 +106,8 @@ nouveau_vram_manager_new(struct ttm_mem_type_manager *man,
 static void
 nouveau_vram_manager_debug(struct ttm_mem_type_manager *man, const char 
*prefix)
 {
-   struct nouveau_mm *mm = man-priv;
+   struct nouveau_fb *pfb = man-priv;
+   struct nouveau_mm *mm = pfb-vram;
struct nouveau_mm_node *r;
u32 total = 0, free = 0;
 
-- 
1.8.1.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [PATCH] drm/nouveau: drop redundant channel handle and owner info from nv_channel_idle

2013-03-05 Thread Marcin Slusarz
before: nouveau E[X[3162]] failed to idle channel 0x [X[3162]]
after:  nouveau E[X[3162]] failed to idle channel: -16

Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
 drivers/gpu/drm/nouveau/nouveau_chan.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index eaa80a2..c8be059 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -58,8 +58,7 @@ nouveau_channel_idle(struct nouveau_channel *chan)
}
 
if (ret)
-   NV_ERROR(cli, failed to idle channel 0x%08x [%s]\n,
-chan-handle, cli-base.name);
+   NV_ERROR(cli, failed to idle channel: %d\n, ret);
return ret;
 }
 
-- 
1.8.1.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [PATCH] drm/nouveau/nv50: use correct tiling methods for m2mf buffer moves

2013-03-05 Thread Marcin Slusarz
Currently used only on original nv50, nvaa and nvac.

Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
Note: it would be catched much faster (probably even by author, and not after
2 years) if this code would use (known!) register names...
---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 11ca821..7ff1071 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -801,7 +801,7 @@ nv50_bo_move_m2mf(struct nouveau_channel *chan, struct 
ttm_buffer_object *bo,
stride  = 16 * 4;
height  = amount / stride;
 
-   if (new_mem-mem_type == TTM_PL_VRAM 
+   if (old_mem-mem_type == TTM_PL_VRAM 
nouveau_bo_tile_layout(nvbo)) {
ret = RING_SPACE(chan, 8);
if (ret)
@@ -823,7 +823,7 @@ nv50_bo_move_m2mf(struct nouveau_channel *chan, struct 
ttm_buffer_object *bo,
BEGIN_NV04(chan, NvSubCopy, 0x0200, 1);
OUT_RING  (chan, 1);
}
-   if (old_mem-mem_type == TTM_PL_VRAM 
+   if (new_mem-mem_type == TTM_PL_VRAM 
nouveau_bo_tile_layout(nvbo)) {
ret = RING_SPACE(chan, 8);
if (ret)
-- 
1.8.1.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [PATCH] drm/nouveau: idle channel before releasing notify object

2013-03-05 Thread Marcin Slusarz
Unmapping it while it's still in use (e.g. by M2MF) can lead to page faults
and a lot of TRAP_M2MF spam in dmesg.

Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
 drivers/gpu/drm/nouveau/nouveau_abi16.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c 
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 4124192..3b6dc88 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -116,6 +116,11 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16,
 {
struct nouveau_abi16_ntfy *ntfy, *temp;
 
+   /* wait for all activity to stop before releasing notify object, which
+* may be still in use */
+   if (chan-chan  chan-ntfy)
+   nouveau_channel_idle(chan-chan);
+
/* cleanup notifier state */
list_for_each_entry_safe(ntfy, temp, chan-notifiers, head) {
nouveau_abi16_ntfy_fini(chan, ntfy);
-- 
1.8.1.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [PATCH] drm/nv50/disp: ignore encoder initialization failures

2013-03-05 Thread Marcin Slusarz
Nouveau does not support all encoder types, so failure to handle one should
not stop module initialization. And because of other bug, it lead to oops
in nv50_crtc_destroy (nv50_display_destroy sets nouveau_display-priv to NULL,
which is used by nv50_crtc_destroy).

Fixes regression from eb6313add6dddf07ea3e50c4caa33a9c3b2379f1
(drm/nv50: initial kms support for off-chip TMDS/DP encoders).

Reported-by: Richard Yao r...@gentoo.org
Tested-by: Richard Yao r...@gentoo.org
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
 drivers/gpu/drm/nouveau/nv50_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index 87a5a56..2db5799 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -2276,6 +2276,7 @@ nv50_display_create(struct drm_device *dev)
NV_WARN(drm, failed to create encoder %d/%d/%d: %d\n,
 dcbe-location, dcbe-type,
 ffs(dcbe-or) - 1, ret);
+   ret = 0;
}
}
 
-- 
1.8.1.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [libdrm PATCH 1/2] nouveau: return error from pushbuf_validate

2013-03-05 Thread Marcin Slusarz
Without it, libdrm_nouveau user cannot know when validation failed.

Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
 nouveau/pushbuf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nouveau/pushbuf.c b/nouveau/pushbuf.c
index ff8e125..e720a08 100644
--- a/nouveau/pushbuf.c
+++ b/nouveau/pushbuf.c
@@ -524,7 +524,7 @@ pushbuf_validate(struct nouveau_pushbuf *push, bool retry)
}
}
 
-   return 0;
+   return ret;
 }
 
 int
-- 
1.8.1.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [libdrm PATCH 2/2] nouveau: add a way to override single pushbuffer vram/gart limits

2013-03-05 Thread Marcin Slusarz
Add environment variables:
NOUVEAU_LIBDRM_VRAM_LIMIT_PERCENT
NOUVEAU_LIBDRM_GART_LIMIT_PERCENT
which will allow override how much VRAM/GART single pushbuffer can take.
Default to 80.

Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
 nouveau/nouveau.c | 18 --
 nouveau/private.h |  1 +
 nouveau/pushbuf.c |  6 --
 3 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index 9b32e31..ee7893b 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
@@ -77,6 +77,7 @@ nouveau_device_wrap(int fd, int close, struct nouveau_device 
**pdev)
uint64_t chipset, vram, gart, bousage;
drmVersionPtr ver;
int ret;
+   char *tmp;
 
 #ifdef DEBUG
debug_init(getenv(NOUVEAU_LIBDRM_DEBUG));
@@ -114,14 +115,27 @@ nouveau_device_wrap(int fd, int close, struct 
nouveau_device **pdev)
nvdev-have_bo_usage = (bousage != 0);
 
nvdev-close = close;
+
+   tmp = getenv(NOUVEAU_LIBDRM_VRAM_LIMIT_PERCENT);
+   if (tmp)
+   nvdev-vram_limit_percent = atoi(tmp);
+   else
+   nvdev-vram_limit_percent = 80;
+   tmp = getenv(NOUVEAU_LIBDRM_GART_LIMIT_PERCENT);
+   if (tmp)
+   nvdev-gart_limit_percent = atoi(tmp);
+   else
+   nvdev-gart_limit_percent = 80;
DRMINITLISTHEAD(nvdev-bo_list);
nvdev-base.object.oclass = NOUVEAU_DEVICE_CLASS;
nvdev-base.lib_version = 0x0100;
nvdev-base.chipset = chipset;
nvdev-base.vram_size = vram;
nvdev-base.gart_size = gart;
-   nvdev-base.vram_limit = (nvdev-base.vram_size * 80) / 100;
-   nvdev-base.gart_limit = (nvdev-base.gart_size * 80) / 100;
+   nvdev-base.vram_limit =
+   (nvdev-base.vram_size * nvdev-vram_limit_percent) / 100;
+   nvdev-base.gart_limit =
+   (nvdev-base.gart_size * nvdev-gart_limit_percent) / 100;
 
*pdev = nvdev-base;
return 0;
diff --git a/nouveau/private.h b/nouveau/private.h
index 8a5cb26..60714b8 100644
--- a/nouveau/private.h
+++ b/nouveau/private.h
@@ -99,6 +99,7 @@ struct nouveau_device_priv {
uint32_t *client;
int nr_client;
bool have_bo_usage;
+   int gart_limit_percent, vram_limit_percent;
 };
 
 static inline struct nouveau_device_priv *
diff --git a/nouveau/pushbuf.c b/nouveau/pushbuf.c
index e720a08..0fd0c47 100644
--- a/nouveau/pushbuf.c
+++ b/nouveau/pushbuf.c
@@ -347,8 +347,10 @@ pushbuf_submit(struct nouveau_pushbuf *push, struct 
nouveau_object *chan)
  req, sizeof(req));
nvpb-suffix0 = req.suffix0;
nvpb-suffix1 = req.suffix1;
-   dev-vram_limit = (req.vram_available * 80) / 100;
-   dev-gart_limit = (req.gart_available * 80) / 100;
+   dev-vram_limit = (req.vram_available *
+   nouveau_device(dev)-vram_limit_percent) / 100;
+   dev-gart_limit = (req.gart_available *
+   nouveau_device(dev)-gart_limit_percent) / 100;
 #else
if (dbg_on(31))
ret = -EINVAL;
-- 
1.8.1.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 60510] Firefox 18.0.2 Crash On Nvidia GeForce2

2013-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=60510

Marcin Slusarz marcin.slus...@gmail.com changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marcin Slusarz marcin.slus...@gmail.com ---
I pushed it to master.

http://cgit.freedesktop.org/mesa/mesa/commit/?id=f4ebcd133b9c952fc57ce6d5df8bce8e2282d868

-- 
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 61879] New: Python binding of gbm's gbm_create_device fail to create_device

2013-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61879

  Priority: medium
Bug ID: 61879
  Assignee: nouveau@lists.freedesktop.org
   Summary: Python binding of gbm's gbm_create_device fail to
create_device
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: amirouche.boube...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: Drivers/DRI/nouveau
   Product: Mesa

Created attachment 75991
  -- https://bugs.freedesktop.org/attachment.cgi?id=75991action=edit
example script with cffi

I bound gbm_create_device with both cffi and cython of gbm_create_device and
they both fail at the same place

error: Program received signal SIGSEGV, Segmentation fault.

stacktrace:

#0  0x7fffee18af07 in PUSH_DATA (push=0x13c0410, data=536952832) at
../../../../src/gallium/drivers/nouveau/nouveau_winsys.h:35
#1  0x7fffee18b0b2 in BEGIN_NVC0 (push=0x13c0410, subc=2, mthd=0, size=1)
at nvc0_winsys.h:112
#2  0x7fffee18c0c1 in nvc0_screen_create (dev=0x15f8690) at
nvc0_screen.c:496
#3  0x7fffee0c4c3b in nouveau_drm_screen_create (fd=7) at
nouveau_drm_winsys.c:46
#4  0x7fffeb0a6943 in create_screen (fd=7) at pipe_nouveau.c:11
#5  0x7fffec4e5fdb in pipe_loader_drm_create_screen (dev=0x1750130,
library_paths=0x7fffecec0cf2 /usr/lib64/gallium-pipe) at
pipe_loader_drm.c:270
#6  0x7fffec4e570e in pipe_loader_create_screen (dev=0x1750130,
library_paths=0x7fffecec0cf2 /usr/lib64/gallium-pipe) at pipe_loader.c:68
#7  0x7fffec4e5539 in gallium_screen_create (gdrm=0x174fff0) at gbm.c:60
#8  0x7fffec4e69a8 in gbm_gallium_drm_device_create (fd=7) at gbm_drm.c:248
#9  0x7fffef338370 in _gbm_create_device (fd=7) at main/backend.c:124

version: 9.1  git
linux: 3.8.2 gentoo

-- 
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 61879] Python binding of gbm's gbm_create_device fail to create_device

2013-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61879

amirouche amirouche.boube...@gmail.com changed:

   What|Removed |Added

 CC||amirouche.boube...@gmail.co
   ||m
Version|unspecified |git

--- Comment #1 from amirouche amirouche.boube...@gmail.com ---
my card is reported by lspci as:

01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 560
Ti] (rev a1) (prog-if 00 [VGA controller])

eglkms demo from mesa-demo works fine under 9.0.2, 9.1 and git

-- 
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 61879] Python binding of gbm's gbm_create_device fail to create_device

2013-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61879

--- Comment #2 from amirouche amirouche.boube...@gmail.com ---
also there this is this message that shows up before the crash:
dri_init_screen_helper: failed to create pipe_screen

-- 
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 61879] Python binding of gbm's gbm_create_device fail to create_device

2013-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61879

amirouche amirouche.boube...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from amirouche amirouche.boube...@gmail.com ---
I update to libdrm but the bug was in my code I was open the device with python
open instead of the low level os.open which allows for O_RDWR.

-- 
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