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 20:25:14 +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> <201711171833.52855.linux@rainbow-software.org> <CAKb7Uvg9BQ6yAXXt+PbVf_c3Wzx3vkA0VdzkcO6qnRC2nJ7AOQ@mail.gmail.com>
In-Reply-To: <CAKb7Uvg9BQ6yAXXt+PbVf_c3Wzx3vkA0VdzkcO6qnRC2nJ7AOQ@mail.gmail.com>
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
Precedence: bulk

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.

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

From 1584358738267792301@xxx Fri Nov 17 23:43:56 +0000 2017
X-GM-THRID: 1584342040192660961
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread