[PATCH 3/3] drm/amd/display: Move dc_state copy in commit_tail after dc_commit_state

[Harry Wentland]

On 2022-10-11 14:11, Rodrigo Siqueira wrote:
> From: Aurabindo Pillai <aurabindo.pillai at amd.com>
> 
> [Why&How]
> With the new commit sequence, we do not want the state to be copied before
> the call to dc_commit_state() since this leaks the phantom streams into
> new state.
> 

What are phantom streams? Why are they needed? Please elaborate.

> Fix this by doing the dc state copy right after the dc_commit_state()
> call.
> 
> Cc: Nicholas Kazlauskas <nicholas.kazlauskas at amd.com>
> Cc: Harry Wentland <harry.wentland at amd.com>
> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira at amd.com>
> Signed-off-by: Aurabindo Pillai <aurabindo.pillai at amd.com>
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c   | 17 +++++++++--------
>  1 file changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 63f076a46260..17a9108f8186 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7999,15 +7999,8 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state)
>  	drm_atomic_helper_update_legacy_modeset_state(dev, state);
>  
>  	dm_state = dm_atomic_get_new_state(state);
> -	if (dm_state && dm_state->context) {
> +	if (dm_state && dm_state->context)
>  		dc_state = dm_state->context;
> -	} else {
> -		/* No state changes, retain current state. */
> -		dc_state_temp = dc_create_state(dm->dc);
> -		ASSERT(dc_state_temp);
> -		dc_state = dc_state_temp;
> -		dc_resource_state_copy_construct_current(dm->dc, dc_state);
> -	}

If I understand this right this change means that when we do a
"fast" update we'll simply modify the existing dc_state directly,
instead of operating on a copy. Is this safe? Keep in mind that
calls in amdgpu_dm can be multi-threaded, unlike calls on other
OSes that use our driver.

In particular, it looks like dm_enable_per_frame_crtc_master_sync
is called on dc_state before the dc_lock is taken. Could this
lead to issues similar to the ones outlined by Nick in his commit
when he wrote this code: 
eb3dc8978596 ("drm/amd/display: Use private obj helpers for dm_atomic_state")

>  
>  	for_each_oldnew_crtc_in_state (state, crtc, old_crtc_state,
>  				       new_crtc_state, i) {
> @@ -8127,6 +8120,14 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state)
>  		mutex_unlock(&dm->dc_lock);
>  	}
>  
> +	if (dc_state == NULL) {
> +		/* No state changes, retain current state. */
> +		dc_state_temp = dc_create_state(dm->dc);
> +		ASSERT(dc_state_temp);
> +		dc_state = dc_state_temp;
> +		dc_resource_state_copy_construct_current(dm->dc, dc_state);
> +	}
> +

Does moving this down serve a purpose other than the one to preserve
this code?

Moving this means that dc_commit_state (now delegating to
dc_commit_streams on some ASICs) is operating on dc->current_state
whereas dc_commit_updates_for_stream (now delegating to
dc_update_planes_and_stream on some ASICs) is operating on
the state copy, i.e. the local dc_state.

Is this really the intention? Will this make our lives easier or
harder? This code is already hard to parse. I fail to see how this
will improve that situation.

Harry

>  	for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
>  		struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc);
>