[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADnq5_PanwrUoaZbU0vnovkcbQwdw+UUsTZ0-tyKgLWpcTn7=g@mail.gmail.com>
Date: Fri, 19 Mar 2021 15:31:29 -0400
From: Alex Deucher <alexdeucher@...il.com>
To: Christian König <christian.koenig@....com>
Cc: Harry Wentland <harry.wentland@....com>,
Lee Jones <lee.jones@...aro.org>, Leo Li <sunpeng.li@....com>,
LKML <linux-kernel@...r.kernel.org>,
amd-gfx list <amd-gfx@...ts.freedesktop.org>,
David Airlie <airlied@...ux.ie>,
Maling list - DRI developers
<dri-devel@...ts.freedesktop.org>,
Alex Deucher <alexander.deucher@....com>,
Colin Ian King <colin.king@...onical.com>,
Harry Wentland <hwentlan@....com>,
"Kazlauskas, Nicholas" <nicholas.kazlauskas@....com>
Subject: Re: [PATCH 06/19] drm/amd/display/dc/calcs/dce_calcs: Move some large
variables from the stack to the heap
On Fri, Mar 19, 2021 at 2:47 PM Christian König
<christian.koenig@....com> wrote:
>
>
>
> Am 19.03.21 um 19:26 schrieb Harry Wentland:
> > On 2021-03-19 2:13 p.m., Alex Deucher wrote:
> >> + Harry, Nick
> >>
> >> On Fri, Mar 19, 2021 at 4:24 AM Lee Jones <lee.jones@...aro.org> wrote:
> >>>
> >>> Fixes the following W=1 kernel build warning(s):
> >>>
> >>> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In
> >>> function ‘calculate_bandwidth’:
> >>> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2016:1:
> >>> warning: the frame size of 1216 bytes is larger than 1024 bytes
> >>> [-Wframe-larger-than=]
> >>>
> >>> Cc: Harry Wentland <harry.wentland@....com>
> >>> Cc: Leo Li <sunpeng.li@....com>
> >>> Cc: Alex Deucher <alexander.deucher@....com>
> >>> Cc: "Christian König" <christian.koenig@....com>
> >>> Cc: David Airlie <airlied@...ux.ie>
> >>> Cc: Daniel Vetter <daniel@...ll.ch>
> >>> Cc: Colin Ian King <colin.king@...onical.com>
> >>> Cc: amd-gfx@...ts.freedesktop.org
> >>> Cc: dri-devel@...ts.freedesktop.org
> >>> Signed-off-by: Lee Jones <lee.jones@...aro.org>
> >>> ---
> >>> .../gpu/drm/amd/display/dc/calcs/dce_calcs.c | 32
> >>> ++++++++++++++++---
> >>> 1 file changed, 28 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> >>> b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> >>> index e633f8a51edb6..9d8f2505a61c2 100644
> >>> --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> >>> +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> >>> @@ -98,16 +98,16 @@ static void calculate_bandwidth(
> >>> int32_t num_cursor_lines;
> >>>
> >>> int32_t i, j, k;
> >>> - struct bw_fixed yclk[3];
> >>> - struct bw_fixed sclk[8];
> >>> + struct bw_fixed *yclk;
> >>> + struct bw_fixed *sclk;
> >>> bool d0_underlay_enable;
> >>> bool d1_underlay_enable;
> >>> bool fbc_enabled;
> >>> bool lpt_enabled;
> >>> enum bw_defines sclk_message;
> >>> enum bw_defines yclk_message;
> >>> - enum bw_defines tiling_mode[maximum_number_of_surfaces];
> >>> - enum bw_defines surface_type[maximum_number_of_surfaces];
> >>> + enum bw_defines *tiling_mode;
> >>> + enum bw_defines *surface_type;
> >>> enum bw_defines voltage;
> >>> enum bw_defines pipe_check;
> >>> enum bw_defines hsr_check;
> >>> @@ -122,6 +122,22 @@ static void calculate_bandwidth(
> >>> int32_t number_of_displays_enabled_with_margin = 0;
> >>> int32_t number_of_aligned_displays_with_no_margin = 0;
> >>>
> >>> + yclk = kcalloc(3, sizeof(*yclk), GFP_KERNEL);
> >>> + if (!yclk)
> >>> + return;
> >>> +
> >>> + sclk = kcalloc(8, sizeof(*sclk), GFP_KERNEL);
> >>> + if (!sclk)
> >>> + goto free_yclk;
> >>> +
> >>> + tiling_mode = kcalloc(maximum_number_of_surfaces,
> >>> sizeof(*tiling_mode), GFP_KERNEL);
> >>> + if (!tiling_mode)
> >>> + goto free_sclk;
> >>> +
> >>> + surface_type = kcalloc(maximum_number_of_surfaces,
> >>> sizeof(*surface_type), GFP_KERNEL);
> >>> + if (!surface_type)
> >>> + goto free_tiling_mode;
> >>> +
> >>
> >>
> >> Harry or Nick can correct me if I'm wrong, but for this patch and the
> >> next one, I think this can be called from an atomic context.
> >>
> >
> > From what I can see this doesn't seem the case. If I'm missing
> > something someone please correct me.
>
> Have you taken into account that using FP functions require atomic
> context as well?
>
> We had quite a bunch of problems with that and had to replace some
> GFP_KERNEL with GFP_ATOMIC in the DC code because of this.
>
> Could of course be that this code here isn't affected by that, but
> better save than sorry.
DCE hardware uses fixed point math so that should be ok. It's just
the newer DCN hardware that requires FP.
Alex
>
> Christian.
>
> >
> > This and the next (06/19) patch are both
> > Reviewed-by: Harry Wentland <harry.wentland@....com>
> >
> > Harry
> >
> >> Alex
> >>
> >>> yclk[low] = vbios->low_yclk;
> >>> yclk[mid] = vbios->mid_yclk;
> >>> yclk[high] = vbios->high_yclk;
> >>> @@ -2013,6 +2029,14 @@ static void calculate_bandwidth(
> >>> }
> >>> }
> >>> }
> >>> +
> >>> + kfree(surface_type);
> >>> +free_tiling_mode:
> >>> + kfree(tiling_mode);
> >>> +free_yclk:
> >>> + kfree(yclk);
> >>> +free_sclk:
> >>> + kfree(sclk);
> >>> }
> >>>
> >>> /*******************************************************************************
> >>> --
> >>> 2.27.0
> >>>
> >>> _______________________________________________
> >>> dri-devel mailing list
> >>> dri-devel@...ts.freedesktop.org
> >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel>
>
Powered by blists - more mailing lists