Re: [PATCH 06/19] drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the stack to the heap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 19, 2021 at 2:47 PM Christian König
<christian.koenig@xxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxx>
> >>> Cc: Leo Li <sunpeng.li@xxxxxxx>
> >>> Cc: Alex Deucher <alexander.deucher@xxxxxxx>
> >>> Cc: "Christian König" <christian.koenig@xxxxxxx>
> >>> Cc: David Airlie <airlied@xxxxxxxx>
> >>> Cc: Daniel Vetter <daniel@xxxxxxxx>
> >>> Cc: Colin Ian King <colin.king@xxxxxxxxxxxxx>
> >>> Cc: amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> >>> Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
> >>> Signed-off-by: Lee Jones <lee.jones@xxxxxxxxxx>
> >>> ---
> >>>   .../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@xxxxxxx>
> >
> > 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@xxxxxxxxxxxxxxxxxxxxx
> >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel>
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux