On Thu, Apr 26, 2018 at 05:56:14PM +0300, Ville Syrjälä wrote: > On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote: > > [ 1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A with fb: size=800x600@32, offset=0, pitch 3200, size 0x1d4c00 > > [ 1.176161] [drm:i915_gem_object_create_stolen_for_preallocated] creating preallocated stolen object: stolen_offset=0x0000000000000000, gtt_offset=0x0000000000000000, size=0x00000000001d5000 > > [ 1.176312] [drm:intel_alloc_initial_plane_obj.isra.127] initial plane fb obj (ptrval) > > [ 1.176351] [drm:intel_modeset_init] pipe A active planes 0x1 > > [ 1.176456] [drm:drm_atomic_helper_check_plane_state] Plane must cover entire CRTC > > [ 1.176481] [drm:drm_rect_debug_print] dst: 800x600+0+0 > > [ 1.176494] [drm:drm_rect_debug_print] clip: 1366x768+0+0 > > OK, so that's the problem right there. The fb we took over from the > BIOS was 800x600, but now we're trying to set up a 1366x768 mode. > > We seem to be missing checks to make sure the initial fb is actually > big enough for the mode we're currently using :( Actually we do read out the pipe src size as 800x600 initially, which make sense. And we even stuff that into the mode.h/vdisplay, so up to that point everything is pretty much correct. It goes wrong is when intel_modeset_readout_hw_state() calls intel_mode_from_pipe_config() as that will override the h/vdisplay with the actual crtc timings instead of the pipe src size. So I suppose we should be able to just add the sanity checks for the fb vs. h/vdisplay, and at least we should get past this error. A slightly bigger mystery is what will happen later when our pipe src size doesn't actually agree with the h/vdisplay. The first modeset will correct it, but we might want some kind of extra sanitize step for fastboot type of stuff. -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
