lkml.org 
[lkml]   [2017]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Blank console but X11 works on MCP79 - old regression since 3.8
Date
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

\
 
 \ /
  Last update: 2017-11-17 20:27    [W:0.048 / U:6.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site