On Sun, Mar 08, 2015 at 02:00:43PM -0700, Matt Roper wrote:
> With the switch to atomic plumbing for planes, some of our commit-time
> work (e.g., watermarks) is done after the new atomic state is swapped
> into the relevant DRM object, but before the DRM core has a chance to
> update its legacy state values. Switch intel_crtc_active() to look at
> the state objects rather than legacy fields to ensure we operate on the
> proper values.
Maybe clarify that we also set plane->fb in our own plane update code (and
yeah the drm core follows suit), but even that is too late. Thinking about
this ... follow-up patch to stop us from updating plane->fb in various
places and rely upon the drm core once this series has landed?
-Daniel
>
> Suggested-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> Signed-off-by: Matt Roper <matthew.d.roper@xxxxxxxxx>
> ---
> drivers/gpu/drm/i915/intel_display.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index b11528f..4f8c622d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -886,8 +886,6 @@ chv_find_best_dpll(const intel_limit_t *limit, struct intel_crtc *crtc,
>
> bool intel_crtc_active(struct drm_crtc *crtc)
> {
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> -
> /* Be paranoid as we can arrive here with only partial
> * state retrieved from the hardware during setup.
> *
> @@ -897,8 +895,8 @@ bool intel_crtc_active(struct drm_crtc *crtc)
> * We can ditch the crtc->primary->fb check as soon as we can
> * properly reconstruct framebuffers.
> */
> - return crtc->state->active && crtc->primary->fb &&
> - intel_crtc->config->base.adjusted_mode.crtc_clock;
> + return crtc->state->active && crtc->primary->state->fb &&
> + crtc->state->adjusted_mode.crtc_clock;
> }
>
> enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv,
> --
> 1.8.5.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
