Re: Blank console but X11 works on MCP79 - old regression since 3.8

[Ondrej Zary <linux@rainbow-software.org>]

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