Re: [RESEND PATCH 4/6] drm/i915: Update atomic modeset state synchronously

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 19, 2016 at 03:55:37PM +0200, Maarten Lankhorst wrote:
> All of this state should be updated as soon as possible. It shouldn't be
> done later because then future updates may not depend on it.
> 
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
> ---
>  drivers/gpu/drm/i915/intel_display.c | 15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 69b9e91f071e..ba7f7be3aa4f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14341,14 +14341,8 @@ static void intel_atomic_commit_tail(struct drm_atomic_state *state)
>  
>  	drm_atomic_helper_wait_for_dependencies(state);
>  
> -	if (intel_state->modeset) {
> -		memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
> -		       sizeof(intel_state->min_pixclk));
> -		dev_priv->active_crtcs = intel_state->active_crtcs;
> -		dev_priv->atomic_cdclk_freq = intel_state->cdclk;
> -
> +	if (intel_state->modeset)
>  		intel_display_power_get(dev_priv, POWER_DOMAIN_MODESET);
> -	}
>  
>  	for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
>  		struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> @@ -14558,6 +14552,13 @@ static int intel_atomic_commit(struct drm_device *dev,
>  	intel_atomic_track_fbs(state);
>  
>  	drm_atomic_state_get(state);
> +	if (intel_state->modeset) {
> +		memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
> +		       sizeof(intel_state->min_pixclk));
> +		dev_priv->active_crtcs = intel_state->active_crtcs;
> +		dev_priv->atomic_cdclk_freq = intel_state->cdclk;
> +	}
> +

I'm not very happy about this whole intel_atomic_state <-> dev_priv
mess. I think what might be nicer is to have an intel_atomic_device_state
or something, which would be part of the top level atomic state just
like the other states, and we would just a pointer to the current
device state under dev_priv I suppose. This way the top level atomic
state would be more like an atomic transaction thing.

>  	if (nonblock)
>  		queue_work(system_unbound_wq, &state->commit_work);
>  	else
> -- 
> 2.7.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux