From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753505AbdKQT1B (ORCPT ); Fri, 17 Nov 2017 14:27:01 -0500 Received: from smtp-1b.atlantis.sk ([80.94.52.26]:53755 "EHLO smtp-1b.atlantis.sk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757171AbdKQT01 (ORCPT ); Fri, 17 Nov 2017 14:26:27 -0500 From: Ondrej Zary To: Ilia Mirkin Subject: Re: Blank console but X11 works on MCP79 - old regression since 3.8 Date: Fri, 17 Nov 2017 20:25:14 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20100827.1168748) Cc: Ben Skeggs , "nouveau@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" References: <201711171526.01053.linux@rainbow-software.org> <201711171833.52855.linux@rainbow-software.org> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201711172025.15121.linux@rainbow-software.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: > On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary > > wrote: > > @@ -483,8 +483,8 @@ > > nouveau 0000:02:00.0: disp: 0860: 00000000 -> 00000500 > > nouveau 0000:02:00.0: disp: 0864: 00000000 > > nouveau 0000:02:00.0: disp: 0868: 00000000 -> 04000500 > > -nouveau 0000:02:00.0: disp: 086c: 00000000 -> 00100500 > > -nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 00001e00 > > +nouveau 0000:02:00.0: disp: 086c: 00000000 -> 00100a00 > > +nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 0000e800 > > nouveau 0000:02:00.0: disp: 0874: 00000000 -> ffff0000 > > nouveau 0000:02:00.0: disp: 0878: 00000000 > > nouveau 0000:02:00.0: disp: 0880: 05000000 > > > > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in > > 64MB case. Why? > > > > I get blank screen even with 64MB with video=1280x1024-8 kernel > > parameter. Console works with video=1280x1024-16 even with 32MB stolen > > memory. > > > > Conclusions: 8-bit support is broken and bpp reduction is weird. > > OK, well that makes a *ton* of sense (8bpp being broken). > > I think the idea of bpp reduction is that when you're on your shiny > new Riva TNT with 16MB of VRAM, you don't want to go crazy allocating > all that to a pinned fbcon - almost half of that would go to a single > 32bpp 1600x1200 buffer, more for 1920x1200. You want to be able to > have at least a few fb-sized buffers for backbuffer rendering, etc. > > The specific limits could probably use tweaking - I think they only > consider VRAM size, not the fb size. > > I guess 8bpp worked prior to the change you bisected though, so we > should figure out what we did wrong in the new code. Yes, booted 3.7 (last working kernel) and it's running in 8bpp. I guess that nv50_head_gamma_set() is missing something like this (from nv_crtc_gamma_set()): /* We need to know the depth before we upload, but it's possible to * get called before a framebuffer is bound. If this is the case, * mark the lut values as dirty by setting depth==0, and it'll be * uploaded on the first mode_set_base() */ if (!nv_crtc->base.primary->fb) { nv_crtc->lut.depth = 0; return 0; } That's easy to add but there's no mode_set_base() for nv50 so there's no place to add code like this: if (nv_crtc->lut.depth != drm_fb->format->depth) { nv_crtc->lut.depth = drm_fb->format->depth; nv_crtc_gamma_load(crtc); } -- Ondrej Zary