[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <33ecbe8971bb9c90d72c67d43ca740abac160908.camel@perches.com>
Date: Sun, 15 Jan 2023 12:52:10 -0800
From: Joe Perches <joe@...ches.com>
To: Deepak R Varma <drv@...lo.com>,
Harry Wentland <harry.wentland@....com>,
Leo Li <sunpeng.li@....com>,
Rodrigo Siqueira <Rodrigo.Siqueira@....com>,
Alex Deucher <alexander.deucher@....com>,
Christian König <christian.koenig@....com>,
"Pan, Xinhui" <Xinhui.Pan@....com>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>, amd-gfx@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Cc: Saurabh Singh Sengar <ssengar@...rosoft.com>,
Praveen Kumar <kumarpraveen@...ux.microsoft.com>
Subject: Re: [PATCH] drm/amd/display: Simplify same effect if/else blocks
On Sun, 2023-01-15 at 15:30 +0530, Deepak R Varma wrote:
> The if / else block code has same effect irrespective of the logical
> evaluation. Hence, simply the implementation by removing the unnecessary
> conditional evaluation. While at it, also fix the long line checkpatch
> complaint. Issue identified using cond_no_effect.cocci Coccinelle
> semantic patch script.
>
> Signed-off-by: Deepak R Varma <drv@...lo.com>
> ---
> Please note: The proposed change is compile tested only. If there are any
> inbuilt test cases that I should run for further verification, I will appreciate
> guidance about it. Thank you.
Preface: I do not know the code.
Perhaps Rodrigo Siqueira made a copy/paste error submitting the code for
commit 9114b55fabae ("drm/amd/display: Fix SubVP control flow in the MPO context")
as the code prior to this change is identical.
Perhaps one of the false uses should be true or dependent on the
interdependent_update_lock state.
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c
[]
> @@ -3470,14 +3470,9 @@ static void commit_planes_for_stream(struct dc *dc,
> /* Since phantom pipe programming is moved to post_unlock_program_front_end,
> * move the SubVP lock to after the phantom pipes have been setup
> */
> - if (should_lock_all_pipes && dc->hwss.interdependent_update_lock) {
> - if (dc->hwss.subvp_pipe_control_lock)
> - dc->hwss.subvp_pipe_control_lock(dc, context, false, should_lock_all_pipes, NULL, subvp_prev_use);
> - } else {
> - if (dc->hwss.subvp_pipe_control_lock)
> - dc->hwss.subvp_pipe_control_lock(dc, context, false, should_lock_all_pipes, NULL, subvp_prev_use);
> - }
> -
Perhaps something like:
if (dc->hwss.subvp_pipe_control_lock)
dc->hwss.subvp_pipe_control_lock(dc, context,
should_lock_all_pipes &&
dc->hwss.interdependent_update_lock,
should_lock_all_pipes, NULL, subvp_prev_use);
> + if (dc->hwss.subvp_pipe_control_lock)
> + dc->hwss.subvp_pipe_control_lock(dc, context, false, should_lock_all_pipes,
> + NULL, subvp_prev_use);
> return;
> }
>
Powered by blists - more mailing lists