similar to: [PATCH] nouveau: nv50: fix ->pseudo_palette usage

The vma field of struct nouveau_framebuffer is a special field for the the accelerated fbdev console. Hence there's at most one single instance for the active console. Moving it into struct nouveau_fbdev makes struct nouveau_framebuffer slightly smaller and brings it closer to struct drm_framebuffer. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> ---

Revised patch set v2. [PATCH 1/8] drm/nouveau: bo read/write wrappers for nv04_crtc.c [PATCH 2/8] drm/nouveau: use bo accessors for push buffers [PATCH 3/8] drm/nouveau: OUT_RINGp - optimize OUT_RING loops [PATCH 4/8] drm/nv50: proper notifier_bo access in nv50_display_vblank_crtc_handler() [PATCH 5/8] drm/nouveau: access fbcon notifier via bo accessors [PATCH 6/8] drm/nouveau: screen_base and

It's mostly a cleanup, but in nv50_fbcon_accel_init gpu lockup message was printed, but HWACCEL_DISBALED flag was not set. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 15 +++++++++++---- drivers/gpu/drm/nouveau/nouveau_fbcon.h | 2 ++ drivers/gpu/drm/nouveau/nv04_fbcon.c | 15 +++++----------

All fields in struct nouveau_framebuffer appear to be obsolete. The data structure can be replaced by struct drm_framebuffer entirely. Patch 1 removes several unused fields from struct nouveau_framebuffer. Patch 2 moves the field vma to struct nouveau_fbdev. The information in vma is only relevant for fbdev emulation, and as such he field is only used there. Patch 3 removes nvbo from struct

The patch f045f459d925 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses") tries to fix some out of memory accesses. Unfortunatelly, the patch breaks the display when using fonts with width that is not divisiable by 8. The monochrome bitmap for each character is stored in memory by lines from top to bottom. Each line is padded to a full byte. For example, for 22x11 font, each line

It will be useful for various synchronization purposes, mostly stolen from "[PATCH] drm/nv50: synchronize user channel after buffer object move on kernel channel" by Maarten Maathuis. Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_channel.c | 4 +++- drivers/gpu/drm/nouveau/nouveau_dma.c | 17 +++++++++++++++++

- This is not yet a generic implementation that will work everywhere, but it's a start. - This will fix the corruption surrounding pixmap/texture bo moves on nv50. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 8 ++- drivers/gpu/drm/nouveau/nouveau_channel.c | 9 ++- drivers/gpu/drm/nouveau/nouveau_dma.c | 26

- Depth and stencil buffers are supposed to be large enough in general. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index e342a41..9fc4bd6 100644 ---

From: Ben Skeggs <bskeggs at redhat.com> --- src/nv50_accel.c | 38 ++++++++------------------------------ src/nv50_accel.h | 1 - src/nv50_exa.c | 45 ++++++++++++++++++++------------------------- 3 files changed, 28 insertions(+), 56 deletions(-) diff --git a/src/nv50_accel.c b/src/nv50_accel.c index 1218e18..db8c744 100644 --- a/src/nv50_accel.c +++ b/src/nv50_accel.c @@

Turns out we used a misaligned long instruction near the end, and the shader was getting killed after writing R, A components. This has gone unnoticed since the remaining G, B outputs aren't actually used. --- src/nv50_accel.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/nv50_accel.c b/src/nv50_accel.c index 5fa539c..1218e18 100644 --- a/src/nv50_accel.c

* Kill the A8+A8 hack. Recent enough X servers (>=1.7) fall back to ARGB glyphs for drivers not supporting A8 render targets. * Kill all the global state. It doesn't matter a lot yet but it might if we get multicard working at some point. * Other random clean-ups with no functional changes. Some numbers from x11perf -aa10text -aa24text -comppixwin10 -comppixwin500: * Before, with A

This has two purposes : - cleaner code - reduce the diff between nv30 and nv40 exa for a possible nvfx_exa merge ? The main differences seem to be that nv30 uses rect texture format (and does not support repeat on that). Then there are some minor changes in TX_FORMAT RT_FORMAT and TEX_FILTER usage. And NVAccelInitNVx0TCL look complete different. Tested with: ./rendercheck -t

This fixes a somewhat indeterministic corruption problem on nv17 when there is stuff going on the other fifos (e.g. gallium but I've also reproduced it with an app just SIFM-ing memory around): in some cases it made the blits the X server had scheduled use the wrong pitch. Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- src/nv04_exa.c | 22 ++++++++++++---------- 1

From: Maarten Lankhorst <maarten.lankhorst at canonical.com> Commit de7b7d59d54852c introduced tiled GART, but a linear copy is still performed. This may result in errors on eviction, fix it by checking tiling from memtype. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> Cc: stable at vger.kernel.org #3.10+ --- drivers/gpu/drm/nouveau/nouveau_bo.c | 33

The current code for primitive splitting and emission on pre-nv50 is severely broken. In particular: 1. Quads and lines are totally broken because "&= 3" should be "&= ~3" and similar for lines 2. Triangle fans and polygons are broken because the first vertex must be repeated for each split chunk 3. Line loops are broken because the must be converted to a line strip,

It seems that Noveau is assuming that once the FIFO pointer is past a command, that command has finished executing, and all the buffers it used are no longer needed. However, this seems to be false at least on G71. In particular, the card may not have even finished reading the input vertex buffers when the pushbuffer "fence" triggers. While Mesa does not reuse the buffer object itself,

Hi all, I am trying to use the 0x110 SERIALIZE (or 0x108 WAIT_FOR_IDLE?) command to barrier the PGRAPH commands. Unfortunately, I do not find any examples either in nouveau or gallium. If it plays just a barrier, I guess it should work by something like (in case of m2mf): BEGIN_RING(chan, m2mf, 0x110, 1); OUT_RING(chan, 1); Otherwise, it may actually play to serialize some commands, then I

A cleanup of nouveau_dma_wait(): extract a sub-function and eliminate two variables to improve readability. No functional changes. Signed-off-by: Pekka Paalanen <pq at iki.fi> --- drivers/gpu/drm/nouveau/nouveau_dma.c | 72 ++++++++++++++++++--------------- 1 files changed, 39 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dma.c

- Added flush notify functions for NV30 and NV40. - NV30 and NV40 need testing. --- src/gallium/drivers/nouveau/nouveau_stateobj.h | 42 ++++++++++++++++++------ src/gallium/drivers/nv04/nv04_surface_2d.c | 9 +++-- src/gallium/drivers/nv30/nv30_context.c | 3 ++ src/gallium/drivers/nv30/nv30_context.h | 1 + src/gallium/drivers/nv30/nv30_state_emit.c | 10

- This avoids problematic "reloc'ed while mapped" messages and some associated corruption as well. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- src/gallium/drivers/nouveau/nouveau_screen.c | 21 +++++++++++++++++++++ src/gallium/drivers/nouveau/nouveau_screen.h | 3 +++ src/gallium/drivers/nouveau/nouveau_stateobj.h | 13 +++++++++++++