Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Ondrej Zary <linux@rainbow-software.org>
To:     Ilia Mirkin <imirkin@alum.mit.edu>
Subject: Re: Blank console but X11 works on MCP79 - old regression since 3.8
Date:   Fri, 17 Nov 2017 21:06:16 +0100
User-Agent: KMail/1.9.10 (enterprise35 0.20100827.1168748)
Cc:     Ben Skeggs <bskeggs@redhat.com>,
        "nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <201711171526.01053.linux@rainbow-software.org> <CAKb7Uvjv23Po+a5cJWgYSPRDOO7UEv7o2LzD_OGLuUGT3dZ_3A@mail.gmail.com> <CAKb7UvhoHYp5ucpO0PED0-Angzyw=Wm_V1_uGJyWTkoyYpGhjQ@mail.gmail.com>
In-Reply-To: <CAKb7UvhoHYp5ucpO0PED0-Angzyw=Wm_V1_uGJyWTkoyYpGhjQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201711172106.16346.linux@rainbow-software.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Friday 17 November 2017 20:52:45 Ilia Mirkin wrote:
> On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> > On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux@rainbow-software.org> 
wrote:
> >> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote:
> >>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
> >>>
> >>> <linux@rainbow-software.org> 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.
> >
> > By the way, instead of booting $kernel, you can use modetest from
> > libdrm/tests. Not sure if it supports C8 though =/
> >
> > I think the issue is this:
> >
> > -               OUT_RING(evo, nv_crtc->lut.depth == 8 ?
> > -                               NV50_EVO_CRTC_CLUT_MODE_OFF :
> > -                               NV50_EVO_CRTC_CLUT_MODE_ON);
> >
> > Whereas now we always set 0xC0000000 (aka "ON").
>

Changing that to 0x80000000 does not help :(

> In case I was being unclear, I'm talking about
>
> https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nv50_display.c#L
>1808
>
> and surrounding items. Looks like lut_clr sets 0x40000000 which was
> previously not used. Not sure what the difference between that and
> 0x00000000 is. This is what we have in rnndb for it:

lut_clr is not called during boot so we can ignore it for now.

> https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml
>#L408
>
> So bit 30 is mode, set is "high res", unset is "low res". So really
> what we want is 0x80000000 which leaves the LUT enabled but uses the
> low-res mode?
>
> All this could use some playing-around with.
>
>   -ilia


-- 
Ondrej Zary

From 1584377548652982217@xxx Sat Nov 18 04:42:55 +0000 2017
X-GM-THRID: 1584342040192660961
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread