Message ID | Y8POxreeC3EvOXhC@ubun2204.myguest.virtualbox.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp672905wrn; Sun, 15 Jan 2023 02:13:57 -0800 (PST) X-Google-Smtp-Source: AMrXdXu+v2PSKJH4N0u21IglgVu5V3+yJruo2IIoH8nq1qG7Z9C9dG/K19efbQ7PsbHB89x/J3K7 X-Received: by 2002:a17:906:1d41:b0:86e:b750:d0fe with SMTP id o1-20020a1709061d4100b0086eb750d0femr3460200ejh.32.1673777637195; Sun, 15 Jan 2023 02:13:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673777637; cv=none; d=google.com; s=arc-20160816; b=lyCfk/YxNJp6hnI8wCE/pSTziyV4xRMWx6tshGCYUfz/7bDM1SkS5O4nFr39VLGGYa t1xV3hlMXNOPbtcKXGh+4weY3zIBEftUpOKuVacKNL1m1t2ULBa88U8oEyzubTqWEp8Z xvSvbjIOIa3oGrAuJckuVh4dQivzOaogj4YH99g1+SSqKBl+ltIWnevn4yiged6etlrS C7Pknc7YaB4jtiZkltBYKB8sl55Lv1tLU6V1VNa4VsJDL4cibzknC4KfBrtljMi8eY98 ZvKJRjuJmiCgOqveXgtIxD8JKP9iKEkuxa4zcOnBjLVkA8TTFXrNGr7Eb/WnIa3MZgtx m0rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:cc:to:from:date:dkim-signature; bh=E8PW3DuawPEJORYPlyEoHVC3ab9jhMFs5xxNNzZNo3w=; b=yUx9FJMe+wJ9JtsloxoZ9YpUy7h6pjnc7vkDd3B0oFqTbUvWJRRNoZC/UGjx3JrExM MOqjhzbD/8/1TKUtHB5XeF1IYyJDxIubqBsn6TkyqnNTKWJKKP/cOwEA2BHefbtiSTFW mZnkCsHHanlgHVyvS4BVPtSiY/XWtNQSjSj/z/6tgJfaSxXNKPDbqcplhAHBwfY9CfFX 7KuhfpUeq4AMnpjJclEzOdJR096K/mSvquPdWRrfd0ZAJ6I2TUULCLgCfN2TQ34MthII xn8HNKeJvc0HB/lCf6nXBrXO+EQr/nyrErvmgvlpRZlJDU7F4TAST8A8kdKgMCILekE8 7stQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mailo.com header.s=mailo header.b="j/AHSimE"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sd22-20020a1709076e1600b008705d3c6d2bsi251946ejc.107.2023.01.15.02.13.28; Sun, 15 Jan 2023 02:13:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@mailo.com header.s=mailo header.b="j/AHSimE"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230318AbjAOKAz (ORCPT <rfc822;stefanalexe802@gmail.com> + 99 others); Sun, 15 Jan 2023 05:00:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47590 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229988AbjAOKAx (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 15 Jan 2023 05:00:53 -0500 Received: from msg-1.mailo.com (msg-1.mailo.com [213.182.54.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 92AB4C16C for <linux-kernel@vger.kernel.org>; Sun, 15 Jan 2023 02:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1673776843; bh=/iD5FdGsACL4AeAQezA9XNB8C/O5bx6Q/X5pHtL9znk=; h=X-EA-Auth:Date:From:To:Cc:Subject:Message-ID:MIME-Version: Content-Type; b=j/AHSimET66MvDWv+l8/PtEAWvnrhLtKagZQwJmMQZcGGc2STk00RUpyw8LALrtNM ZnsIOPFDKQvAX/0CNhJx6g+LV5WxkZpCK/+5ao00eYs/low/H+qAJjJcLjhzpGnWfw tEoHNhFdf3SdsMewyN0YhTKDmukAc7EcXt/C0cQo= Received: by b-2.in.mailobj.net [192.168.90.12] with ESMTP via ip-206.mailobj.net [213.182.55.206] Sun, 15 Jan 2023 11:00:43 +0100 (CET) X-EA-Auth: QUVQkKdtaa3ThPmH0jN9hkKBEF3clhbPL9AScoOFF2o6Ipb8m9b2YiEd1CacQfHgw+lTtqJAFAhum5ZmXRrFw35fBU6TjDC8 Date: Sun, 15 Jan 2023 15:30:38 +0530 From: Deepak R Varma <drv@mailo.com> To: Harry Wentland <harry.wentland@amd.com>, Leo Li <sunpeng.li@amd.com>, Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>, Alex Deucher <alexander.deucher@amd.com>, Christian =?iso-8859-1?q?K=F6nig?= <christian.koenig@amd.com>, "Pan, Xinhui" <Xinhui.Pan@amd.com>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: Saurabh Singh Sengar <ssengar@microsoft.com>, Praveen Kumar <kumarpraveen@linux.microsoft.com> Subject: [PATCH] drm/amd/display: Simplify same effect if/else blocks Message-ID: <Y8POxreeC3EvOXhC@ubun2204.myguest.virtualbox.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755083059473703697?= X-GMAIL-MSGID: =?utf-8?q?1755083059473703697?= |
Series |
drm/amd/display: Simplify same effect if/else blocks
|
|
Commit Message
Deepak R Varma
Jan. 15, 2023, 10 a.m. UTC
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@mailo.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.
drivers/gpu/drm/amd/display/dc/core/dc.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
Comments
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@mailo.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; > } >
On Sun, Jan 15, 2023 at 12:52:10PM -0800, Joe Perches wrote: > 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@mailo.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. Thank you Joe for the recommendation. Hi Rodrigo, Can you review and comment on if and what is wrong with your commit? Thank you, ./drv > > > 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; > > } > > >
On Mon, Jan 23, 2023 at 12:23:19AM +0530, Deepak R Varma wrote: > On Sun, Jan 15, 2023 at 12:52:10PM -0800, Joe Perches wrote: > > 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@mailo.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. > > Thank you Joe for the recommendation. > > Hi Rodrigo, > Can you review and comment on if and what is wrong with your commit? Hello Rodrigo, Alex, Could you please suggest what would be the necessary fix for this typo error? Thank you, Deepak. > > Thank you, > ./drv > > > > > > 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; > > > } > > > > > > >
On 3/1/23 15:21, Deepak R Varma wrote: > On Mon, Jan 23, 2023 at 12:23:19AM +0530, Deepak R Varma wrote: >> On Sun, Jan 15, 2023 at 12:52:10PM -0800, Joe Perches wrote: >>> 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@mailo.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. >> >> Thank you Joe for the recommendation. >> >> Hi Rodrigo, >> Can you review and comment on if and what is wrong with your commit? > > Hello Rodrigo, Alex, > Could you please suggest what would be the necessary fix for this typo error? > It's not quite a "typo" error. When I look at this code in our internal repo I see a couple missing lock calls here that differ between the two cases. I don't know why this was never ported over and am surprised it doesn't lead to issues. I would prefer we keep the code as-is for now until this gets sorted. Harry > Thank you, > Deepak. > >> >> Thank you, >> ./drv >> >>> >>>> 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; >>>> } >>>> >>> >> >> > >
On Thu, Mar 02, 2023 at 11:37:30AM -0500, Harry Wentland wrote: > > > On 3/1/23 15:21, Deepak R Varma wrote: > > On Mon, Jan 23, 2023 at 12:23:19AM +0530, Deepak R Varma wrote: > >> On Sun, Jan 15, 2023 at 12:52:10PM -0800, Joe Perches wrote: > >>> 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@mailo.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. > >> > >> Thank you Joe for the recommendation. > >> > >> Hi Rodrigo, > >> Can you review and comment on if and what is wrong with your commit? > > > > Hello Rodrigo, Alex, > > Could you please suggest what would be the necessary fix for this typo error? > > > > It's not quite a "typo" error. When I look at this code in our internal repo I see > a couple missing lock calls here that differ between the two cases. I don't know why > this was never ported over and am surprised it doesn't lead to issues. > > I would prefer we keep the code as-is for now until this gets sorted. Sounds good. Do let me know if I can be of any help. Deepak. > > Harry > > > Thank you, > > Deepak. > > > >> > >> Thank you, > >> ./drv > >> > >>> > >>>> 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; > >>>> } > >>>> > >>> > >> > >> > > > > >
On 3/2/23 11:37, Harry Wentland wrote: > > > On 3/1/23 15:21, Deepak R Varma wrote: >> On Mon, Jan 23, 2023 at 12:23:19AM +0530, Deepak R Varma wrote: >>> On Sun, Jan 15, 2023 at 12:52:10PM -0800, Joe Perches wrote: >>>> 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@mailo.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. >>> >>> Thank you Joe for the recommendation. >>> >>> Hi Rodrigo, >>> Can you review and comment on if and what is wrong with your commit? >> >> Hello Rodrigo, Alex, >> Could you please suggest what would be the necessary fix for this typo error? >> > > It's not quite a "typo" error. When I look at this code in our internal repo I see > a couple missing lock calls here that differ between the two cases. I don't know why > this was never ported over and am surprised it doesn't lead to issues. > > I would prefer we keep the code as-is for now until this gets sorted. > Actually I was wrong. Too many similar-looking snippets in this function made me look at the wrong thing. This change is fine and Reviewed-by: Harry Wentland <harry.wentland@amd.com. Harry > Harry > >> Thank you, >> Deepak. >> >>> >>> Thank you, >>> ./drv >>> >>>> >>>>> 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; >>>>> } >>>>> >>>> >>> >>> >> >> >
On 1/15/23 05:00, 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@mailo.com> Applied, thanks! > --- > 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. > > drivers/gpu/drm/amd/display/dc/core/dc.c | 11 +++-------- > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c > index 0cb8d1f934d1..776209e5d21f 100644 > --- 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); > - } > - > + 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; > } >
On Fri, 2023-03-03 at 15:35 -0500, Harry Wentland wrote: > Actually I was wrong. Too many similar-looking snippets in this > function made me look at the wrong thing. This change is fine and > Reviewed-by: Harry Wentland <harry.wentland@amd.com. So why was the change made in the first place? Please explain commit 9114b55fabae.
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c index 0cb8d1f934d1..776209e5d21f 100644 --- 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); - } - + 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; }