On 2022-10-11 14:11, Rodrigo Siqueira wrote:
> From: Aurabindo Pillai <aurabindo.pil...@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.kazlaus...@amd.com>
> Cc: Harry Wentland <harry.wentl...@amd.com>
> Reviewed-by: Rodrigo Siqueira <rodrigo.sique...@amd.com>
> Signed-off-by: Aurabindo Pillai <aurabindo.pil...@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);
>
