[Intel-gfx] [PATCH] drm/i915/skl: Correct other-pipe watermark update condition check (v2)
Kumar, Mahesh
mahesh1.kumar at intel.com
Mon Oct 26 23:16:25 PDT 2015
Yes, it doesn't solve all warnings.
Other than fbdev restore, there is one warning which I faced during
DPMS/Hot-plug, which is due to calculation of watermarks twice. Once for
first CRTC "Pipe-A" (during which it consider/calculates watermark for
other pipe "Pipe-B" as well & stores in structure
"intel_crtc->wm.active.skl") & Now in same atomic_commit, when it
calculate watermark for second CRTC "Pipe-B" , that time watermark for
other-pipe (in this case pipe-A) already have calculated values so it
gives !wm_changed warning.
Hoping 2-stage watermark programming will take care of this, as in that
case, If I'm not misunderstood final results should be stored after
calculation for all pipes.
Regards,
-Mahesh
On 10/23/2015 10:11 PM, Matt Roper wrote:
> From: "Kumar, Mahesh" <mahesh1.kumar at intel.com>
>
> If ddb allocation for planes in current CRTC is changed, that doesn't
> lead to ddb allocation change for other CRTCs, because our DDB allocation
> is not dynamic according to plane parameters, ddb is allocated according
> to number of CRTC enabled, & divided equally among CTRC's.
>
> In current condition check during Watermark calculation, if number of
> plane/ddb allocation changes for current CRTC, Watermark for other pipes
> are recalculated. But there is no change in DDB allocation of other pipe
> so watermark is also not changed, This leads to warning messages.
> WARN_ON(!wm_changed)
>
> This patch corrects this and check if DDB allocation for pipes is changed,
> then only recalculate watermarks.
>
> v2 (by Matt): Rebased to latest -nightly and fixed a typo
>
> Signed-off-by: Kumar, Mahesh <mahesh1.kumar at intel.com>
> Reviewed-by(v1): Ville Syrjälä <ville.syrjala at linux.intel.com>
> Signed-off-by: Matt Roper <matthew.d.roper at intel.com>
> ---
> I don't think this solves all the !wm_changed warnings (I still see one during
> fbdev restore following various igt tests), but it seems like a move in the
> right direction so I figured I'd go ahead and rebase Mahesh' patch so it can
> get merged.
>
> drivers/gpu/drm/i915/intel_pm.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 0fb0459..0467e34 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3064,14 +3064,12 @@ static bool skl_ddb_allocation_changed(const struct skl_ddb_allocation *new_ddb,
> struct drm_device *dev = intel_crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> const struct skl_ddb_allocation *cur_ddb = &dev_priv->wm.skl_hw.ddb;
> - enum pipe pipe = intel_crtc->pipe;
> -
> - if (memcmp(new_ddb->plane[pipe], cur_ddb->plane[pipe],
> - sizeof(new_ddb->plane[pipe])))
> - return true;
>
> - if (memcmp(&new_ddb->plane[pipe][PLANE_CURSOR], &cur_ddb->plane[pipe][PLANE_CURSOR],
> - sizeof(new_ddb->plane[pipe][PLANE_CURSOR])))
> + /*
> + * If ddb allocation of pipes changed, it may require recalculation of
> + * watermarks
> + */
> + if (memcmp(new_ddb->pipe, cur_ddb->pipe, sizeof(new_ddb->pipe)))
> return true;
>
> return false;
More information about the Intel-gfx
mailing list