[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN6PR12MB1652D3DE81BA07C8634AF5D5F7DD0@BN6PR12MB1652.namprd12.prod.outlook.com>
Date: Wed, 28 Jun 2017 15:40:49 +0000
From: "Deucher, Alexander" <Alexander.Deucher@....com>
To: "'Gustavo A. R. Silva'" <garsilva@...eddedor.com>,
"Koenig, Christian" <Christian.Koenig@....com>,
David Airlie <airlied@...ux.ie>
CC: "amd-gfx@...ts.freedesktop.org" <amd-gfx@...ts.freedesktop.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [gpu-drm-radeon] question about potential dead code in
vce_v2_0_enable_mgcg()
> -----Original Message-----
> From: Gustavo A. R. Silva [mailto:garsilva@...eddedor.com]
> Sent: Wednesday, June 28, 2017 10:22 AM
> To: Deucher, Alexander; Koenig, Christian; David Airlie
> Cc: amd-gfx@...ts.freedesktop.org; dri-devel@...ts.freedesktop.org; linux-
> kernel@...r.kernel.org
> Subject: [gpu-drm-radeon] question about potential dead code in
> vce_v2_0_enable_mgcg()
>
>
> Hello everybody,
>
> While looking into Coverity ID 1198635 I ran into the following piece
> of code at drivers/gpu/drm/radeon/vce_v2_0.c:107:
>
> 107void vce_v2_0_enable_mgcg(struct radeon_device *rdev, bool enable)
> 108{
> 109 bool sw_cg = false;
> 110
> 111 if (enable && (rdev->cg_flags &
> RADEON_CG_SUPPORT_VCE_MGCG)) {
> 112 if (sw_cg)
> 113 vce_v2_0_set_sw_cg(rdev, true);
> 114 else
> 115 vce_v2_0_set_dyn_cg(rdev, true);
> 116 } else {
> 117 vce_v2_0_disable_cg(rdev);
> 118
> 119 if (sw_cg)
> 120 vce_v2_0_set_sw_cg(rdev, false);
> 121 else
> 122 vce_v2_0_set_dyn_cg(rdev, false);
> 123 }
> 124}
>
> The issue here is that local variable sw_cg is never updated again
> after its initialization; which cause some code to be logically dead.
>
> My question here is if such variable is there for testing purposes or
> if it is a sort of an old code leftover that should be removed?
>
> In any case I can send a patch to add a comment or remove the dead code.
>
> I'd really appreciate any comments on this.
I wanted to leave the code in for debugging if we ran into problems with dynamic clockgating.
Alex
Powered by blists - more mailing lists