Re: [Intel-gfx] [PATCH v1 1/3] drm/i915: Decouple cdclk calculation from modeset checks

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Mon, Mar 16, 2020 at 01:37:42PM +0200, Stanislav Lisovskiy wrote:
> We need to calculate cdclk after watermarks/ddb has been calculated
> as with recent hw CDCLK needs to be adjusted accordingly to DBuf
> requirements, which is not possible with current code organization.
> 
> Setting CDCLK according to DBuf BW requirements and not just rejecting
> if it doesn't satisfy BW requirements, will allow us to save power when
> it is possible and gain additional bandwidth when it's needed - i.e
> boosting both our power management and perfomance capabilities.
> 
> This patch is preparation for that, first we now extract modeset
> calculation from modeset checks, in order to call it after wm/ddb
> has been calculated.
> 
> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 22 ++++++++++++++++----
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index 8f23c4d51c33..cdff3054b344 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14542,6 +14542,14 @@ static int intel_modeset_checks(struct intel_atomic_state *state)
>  			return ret;
>  	}
>  
> +	return 0;
> +}
> +
> +static int intel_modeset_cdclk(struct intel_atomic_state *state)
> +{

Misleading name here since you didn't extract just the cdclk part.
IMO just move intel_modeset_calc_cdclk() alone out from
intel_modeset_checks(), and keep the reordering minimal in that
patch. Ie. just call intel_modeset_calc_cdclk() right after
intel_modeset_checks().

Then in the next patch you can do the
intel_modeset_calc_cdclk()+intel_atomic_check_crtcs() vs. wm reorder.

The two things that currently need cdclk in intel_crtc_atomic_check()
would appear to be ips and linetime watermarks. The rest looks like
safe to reorder.

Though at least one thing that I think is totally misplaced is the
.crtc_compute_clock() call. That really should be done much earlier,
even earlier than where it is now. However since it doesn't
adjust .crtc_clock with the results of the computation doesn't really
matter for now. So looks like we can ignore this particular mess
for now.

>
> +	struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> +	int ret;
> +
>  	ret = intel_modeset_calc_cdclk(state);
>  	if (ret)
>  		return ret;
> @@ -14879,10 +14887,6 @@ static int intel_atomic_check(struct drm_device *dev,
>  			goto fail;
>  	}
>  
> -	ret = intel_atomic_check_crtcs(state);
> -	if (ret)
> -		goto fail;
> -
>  	intel_fbc_choose_crtc(dev_priv, state);
>  	ret = calc_watermark_data(state);
>  	if (ret)
> @@ -14892,6 +14896,16 @@ static int intel_atomic_check(struct drm_device *dev,
>  	if (ret)
>  		goto fail;
>  
> +	if (any_ms) {
> +		ret = intel_modeset_cdclk(state);
> +		if (ret)
> +			goto fail;
> +	}
> +
> +	ret = intel_atomic_check_crtcs(state);
> +	if (ret)
> +		goto fail;
>  	for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
>  					    new_crtc_state, i) {
>  		if (!needs_modeset(new_crtc_state) &&
> -- 
> 2.24.1.485.gad05a3d8e5

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx