drm/i915: Use crtc->state->active in ilk/skl watermark calculations (v3)
Existing watermark code calls intel_crtc_active() to determine whether a CRTC is active for the purpose of watermark calculations (and bails out early if it determines the CRTC is not active). However intel_crtc_active() only returns true if crtc->primary->fb is non-NULL, which isn't appropriate in the modern age of universal planes and atomic modeset since userspace can now disable the primary plane, but leave the CRTC (and other planes) running. Note that commit commit 0fda6568 Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Date: Fri Feb 27 15:12:35 2015 +0000 drm/i915/skl: Update watermarks for Y tiling adds a test for primary plane enable/disable to trigger a watermark update (previously we ignored updates to primary planes, which wasn't really correct, but we got lucky since we always pretended the primary plane was on). Tvrtko's patch tries to update watermarks when we re-enable the primary plane, but that watermark computation gets aborted early because intel_crtc_active() returns false due to the disabled primary plane. Switch the ILK and SKL watermark code over to use crtc->state->active rather than calling intel_crtc_active() so that we'll properly compute watermarks when re-enabling the primary plane. Note that this commit doesn't touch callsites in the watermark code for older platforms since there were concerns that doing so would lead to other types of breakage. Also note that all of the watermark calculation at the moment takes place after new crtc/plane states are swapped into the DRM objects. This will change in the future, so we'll be working with in-flight state objects, but for the time being, crtc->state is what we want to operate on. v2: Don't drop primary->fb check from intel_crtc_active(), but rather replace ILK/SKL callsites with direct tests of crtc->state->active. There is concern that messing with intel_crtc_active() will lead to other breakage for old hardware platforms. (Ville) v3: Use intel_crtc->active for now rather than crtc->state->active since we don't have CRTC states properly hooked up and initialized yet. We'll defer the switch to crtc->state->active until the atomic CRTC state work is farther along. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Showing
Please register or sign in to comment