On Thu, Aug 27, 2015 at 01:05:12PM +0200, Maarten Lankhorst wrote: > Hey, > > Op 26-08-15 om 16:43 schreef Daniel Vetter: > > On Wed, Aug 05, 2015 at 12:45:48PM +0200, Maarten Lankhorst wrote: > >> From: Patrik Jakobsson <patrik.jakobsson@xxxxxxxxxxxxxxx> > >> > >> When reading out hw state for planes we disable inactive planes which in > >> turn triggers an update of the watermarks. The update depends on the > >> crtc_clock being set which is done when reading out encoders. Thus > >> postpone the plane readout until after encoder readout. > >> > >> This prevents a warning in skl_compute_linetime_wm() where pixel_rate > >> becomes 0 when crtc_clock is 0. > >> > >> Changes since v1: > >> - Set all modes after all state is read out. (Maarten) > >> > >> References: https://bugs.freedesktop.org/show_bug.cgi?id=91428 > >> Signed-off-by: Patrik Jakobsson <patrik.jakobsson@xxxxxxxxxxxxxxx> > >> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > > Hm I still think we have a bit a mess here - the plane readout code is > > still spread out between modeset_readout_hw_state and the per-plane loop > > in intel_modeset_init after setup_hw_state. > > > > I thought that we only ever need to do the plane state readout on initial > > load (they're all off on resume anyway and we force a full modeset to make > > sure plane state is correct again). Can't we just have a setup_plane_state > > which has that loop from the end of modeset_init with all the other plane > > state unified there? > > > Perhaps, but intel_crtc_disable_noatomic cares about visibility state. I don't see a need for that any more at all, since disable_noatomic is only used in sanitize_crtc. And that's only called when the bios fucks something up and i915.ko needs to patch it up. No way a pageflip or anything else is pending there. Also we don't seem to set up plane_mask early enough for that function to correctly kill the primary plane. That might explain some of the display faults Chris is seeing ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
