[Intel-gfx] drm/i915: Postpone plane readout until after encoder readout, v2.

[Daniel Vetter]

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 at linux.intel.com>
> >>
> >> 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 at linux.intel.com>
> >> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> > 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