Nouveau - Dec 2017 - [PATCH 2/2] kms/gf119-: always use a 256-entry lut for now

This is what was done prior to the big refactor in kernel 3.8, and what
was done by xf86-video-nv. Experimentally, it seems like there's some
sort of issue with the high-res lut to be used there. Tested on G92.

This ends up mattering because fbcon/fbdev chooses the C8 fb format for
low-vram systems, which can occur with some IGP-based configurations
with little "stolen" vram.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---

There's more to be done here I think since the first modeset ends up
skipping a bunch of stuff for some reason. But I can't figure out how to
get it to not do that.

But this is a start.

 drm/nouveau/nv50_display.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drm/nouveau/nv50_display.c b/drm/nouveau/nv50_display.c
index 584466ef..0e8f4b76 100644
--- a/drm/nouveau/nv50_display.c
+++ b/drm/nouveau/nv50_display.c
@@ -1800,12 +1800,14 @@ nv50_head_lut_set(struct nv50_head *head, struct
nv50_head_atom *asyh)
 	if ((push = evo_wait(core, 7))) {
 		if (core->base.user.oclass < G82_DISP_CORE_CHANNEL_DMA) {
 			evo_mthd(push, 0x0840 + (head->base.index * 0x400), 2);
-			evo_data(push, 0xc0000000);
+			evo_data(push, asyh->base.depth == 8 ?
+				 0x80000000 : 0xc0000000);
 			evo_data(push, asyh->lut.offset >> 8);
 		} else
 		if (core->base.user.oclass < GF110_DISP_CORE_CHANNEL_DMA) {
 			evo_mthd(push, 0x0840 + (head->base.index * 0x400), 2);
-			evo_data(push, 0xc0000000);
+			evo_data(push, asyh->base.depth == 8 ?
+				 0x80000000 : 0xc0000000);
 			evo_data(push, asyh->lut.offset >> 8);
 			evo_mthd(push, 0x085c + (head->base.index * 0x400), 1);
 			evo_data(push, asyh->lut.handle);
-- 
2.13.6

Unfortunately the ABI is a little annoying around almost requiring a
256-entry lut. While that is being worked out, allow proper mapping of
colors in 30bpp framebuffers.

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---

If I bump the gamma size to 1024, then all existing software will start
failing since the gamma set ioctl expects the size to match. But
xf86-video-nouveau does not pull in the "real" gaamma size and just
assumes the default 256.

This lets 30bpp get going a bit though while the proper solution is
figured out.

 drm/nouveau/nv50_display.c | 15 ++++-----------
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drm/nouveau/nv50_display.c b/drm/nouveau/nv50_display.c
index 0e8f4b76..6ce4467a 100644
--- a/drm/nouveau/nv50_display.c
+++ b/drm/nouveau/nv50_display.c
@@ -1813,7 +1813,7 @@ nv50_head_lut_set(struct nv50_head *head, struct
nv50_head_atom *asyh)
 			evo_data(push, asyh->lut.handle);
 		} else {
 			evo_mthd(push, 0x0440 + (head->base.index * 0x300), 4);
-			evo_data(push, 0x83000000);
+			evo_data(push, 0x81000000);
 			evo_data(push, asyh->lut.offset >> 8);
 			evo_data(push, 0x00000000);
 			evo_data(push, 0x00000000);
@@ -2214,16 +2214,9 @@ nv50_head_lut_load(struct drm_crtc *crtc)
 	b = g + crtc->gamma_size;
 
 	for (i = 0; i < 256; i++) {
-		if (disp->disp->oclass < GF110_DISP) {
-			writew((*r++ >> 2) + 0x0000, lut + (i * 0x08) + 0);
-			writew((*g++ >> 2) + 0x0000, lut + (i * 0x08) + 2);
-			writew((*b++ >> 2) + 0x0000, lut + (i * 0x08) + 4);
-		} else {
-			/* 0x6000 interferes with the 14-bit color??? */
-			writew((*r++ >> 2) + 0x6000, lut + (i * 0x20) + 0);
-			writew((*g++ >> 2) + 0x6000, lut + (i * 0x20) + 2);
-			writew((*b++ >> 2) + 0x6000, lut + (i * 0x20) + 4);
-		}
+		writew((*r++ >> 2) + 0x0000, lut + (i * 0x08) + 0);
+		writew((*g++ >> 2) + 0x0000, lut + (i * 0x08) + 2);
+		writew((*b++ >> 2) + 0x0000, lut + (i * 0x08) + 4);
 	}
 }
 
-- 
2.13.6