kernel.git/drivers/gpu/drm/i915/intel_atomic.c, branch linux-4.12.y

drm/i915: Skip useless watermark/FIFO related work on VLV/CHV when not needed

2017-03-03T14:50:10Z

Check whether anything relevant has actually change when we compute new watermarks for each plane in the state. If the watermarks for no primary/sprite planes changed we don't have to recompute the FIFO split or reprogram the DSBARB registers. And even the cursor watermarks didn't change we can skip the merge+invert step between all the planes on the pipe as well. v2: s/noninverted/raw/ for consistency with other platforms v3: Drop duplicated vlv_get_fifo_size() call during init Signed-off-by: Ville Syrjälä Reviewed-by: Maarten Lankhorst Link: http://patchwork.freedesktop.org/patch/msgid/20170302171508.1666-9-ville.syrjala@linux.intel.com

drm/i915/glk: Fix Geminilake scalers mode programming

2017-02-23T12:57:01Z

Geminilake scalers can do 7x7 filtering for all supported input sizes, so it doesn't need the "high quality" mode programming, which was actually removed from that platform. v2: Split dev_priv parameter change out. (Ville) Cc: Ville Syrjälä , Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/20170223071600.14356-5-ander.conselvan.de.oliveira@intel.com

drm/i915/glk: Pass dev_priv to intel_atomic_setup_scalers()

2017-02-23T12:56:51Z

Pass dev_priv to intel_atomic_setup_scalers(). The next patch will need a dev_priv pointer. Cc: Ville Syrjälä Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/20170223071600.14356-4-ander.conselvan.de.oliveira@intel.com

drm/i915: Move intel_atomic_get_shared_dpll_state() to intel_dpll_mgr.c

2017-01-02T09:31:53Z

The function intel_atomic_get_shared_dpll_state() is only called from intel_dpll_mgr.c and it concerns the same data structures as the other functions in that file, so move it there and make it static. Signed-off-by: Ander Conselvan de Oliveira Suggested-by: Daniel Vetter Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1483024933-3726-8-git-send-email-ander.conselvan.de.oliveira@intel.com

drm/i915: Rename intel_shared_dpll_config to intel_shared_dpll_state

2016-12-30T07:26:10Z

Struct intel_shared_dpll_config is used to hold the state of the DPLL in the "atomic" sense, so call it state like everything else atomic. v2: Rebase Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Daniel Vetter (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1483024933-3726-4-git-send-email-ander.conselvan.de.oliveira@intel.com

drm: Consolidate plane arrays in drm_atomic_state

2016-06-02T15:20:25Z

It's kinda pointless to have 2 separate mallocs for these. And when we add more per-plane state in the future it's even more pointless. Right now there's no such thing planned, but both Gustavo's per-crtc fence patches, and some nonblocking commit helpers I'm playing around with will add more per-crtc stuff. It makes sense to also consolidate planes, just for consistency. In the future we can use this to store a pointer to the preceeding state, making an atomic update entirely free-standing. This will be needed to be able to queue them up with a depth > 1. Cc: Gustavo Padovan Reviewed-by: Maarten Lankhorst Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1464818821-5736-11-git-send-email-daniel.vetter@ffwll.ch

drm/i915: Use drm_atomic_get_existing_plane_state

2016-06-02T13:39:55Z

We want to encapsulate the drm_atomic_state internals. v2: Use intel_atomic_get_existing_plane_state (Maarten). Reviewed-by: Maarten Lankhorst Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1464818821-5736-3-git-send-email-daniel.vetter@ffwll.ch

drm/i915: Remove some post-commit members from intel_crtc->atomic, v3.

2016-03-16T13:50:25Z

fb_bits is useful to have in the crtc_state for cs flips when the code is updated to use intel_frontbuffer_flip_prepare/complete. So calculate it in advance and move it to crtc_state. The other stuff can be calculated in post_plane_update, and aren't useful elsewhere. Changes since v1: - Changing wording, remove comment about loop. Changes since v2: - Rebase. Signed-off-by: Maarten Lankhorst Reviewed-by: Ander Conselvan de Oliveira Link: http://patchwork.freedesktop.org/patch/msgid/1457516145-32117-1-git-send-email-maarten.lankhorst@linux.intel.com

drm/i915: Fix watermarks for VLV/CHV

2016-03-10T12:02:03Z

commit 92826fcdfc14 ("drm/i915: Calculate watermark related members in the crtc_state, v4.") broke thigns by removing the pre vs. post wm update distinction. We also lost the pre plane wm update entirely for VLV/CHV from the crtc enable path. This caused underruns on modeset and plane enable/disable on CHV, and often those can lead to a dead pipe. So let's bring back the pre vs. post thing, and let's toss in an explicit wm update to valleyview_crtc_enable() to avoid having to put it into the common code. This is more or less a partial revert of the offending commit. Cc: Maarten Lankhorst Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 92826fcdfc14 ("drm/i915: Calculate watermark related members in the crtc_state, v4.") Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1457543247-13987-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst

drm/i915: Add two-stage ILK-style watermark programming (v11)

2016-02-29T16:20:53Z

In addition to calculating final watermarks, let's also pre-calculate a set of intermediate watermark values at atomic check time. These intermediate watermarks are a combination of the watermarks for the old state and the new state; they should satisfy the requirements of both states which means they can be programmed immediately when we commit the atomic state (without waiting for a vblank). Once the vblank does happen, we can then re-program watermarks to the more optimal final value. v2: Significant rebasing/rewriting. v3: - Move 'need_postvbl_update' flag to CRTC state (Daniel) - Don't forget to check intermediate watermark values for validity (Maarten) - Don't due async watermark optimization; just do it at the end of the atomic transaction, after waiting for vblanks. We do want it to be async eventually, but adding that now will cause more trouble for Maarten's in-progress work. (Maarten) - Don't allocate space in crtc_state for intermediate watermarks on platforms that don't need it (gen9+). - Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit now that ilk_update_wm is gone. v4: - Add a wm_mutex to cover updates to intel_crtc->active and the need_postvbl_update flag. Since we don't have async yet it isn't terribly important yet, but might as well add it now. - Change interface to program watermarks. Platforms will now expose .initial_watermarks() and .optimize_watermarks() functions to do watermark programming. These should lock wm_mutex, copy the appropriate state values into intel_crtc->active, and then call the internal program watermarks function. v5: - Skip intermediate watermark calculation/check during initial hardware readout since we don't trust the existing HW values (and don't have valid values of our own yet). - Don't try to call .optimize_watermarks() on platforms that don't have atomic watermarks yet. (Maarten) v6: - Rebase v7: - Further rebase v8: - A few minor indentation and line length fixes v9: - Yet another rebase since Maarten's patches reworked a bunch of the code (wm_pre, wm_post, etc.) that this was previously based on. v10: - Move wm_mutex to dev_priv to protect against racing commits against disjoint CRTC sets. (Maarten) - Drop unnecessary clearing of cstate->wm.need_postvbl_update (Maarten) v11: - Now that we've moved to atomic watermark updates, make sure we call the proper function to program watermarks in {ironlake,haswell}_crtc_enable(); the failure to do so on the previous patch iteration led to us not actually programming the watermarks before turning on the CRTC, which was the cause of the underruns that the CI system was seeing. - Fix inverted logic for determining when to optimize watermarks. We were needlessly optimizing when the intermediate/optimal values were the same (harmless), but not actually optimizing when they differed (also harmless, but wasteful from a power/bandwidth perspective). Cc: Maarten Lankhorst Signed-off-by: Matt Roper Reviewed-by: Maarten Lankhorst Link: http://patchwork.freedesktop.org/patch/msgid/1456276813-5689-1-git-send-email-matthew.d.roper@intel.com