From: Nathan Chancellor <nathan@kernel.org>
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 König" <christian.koenig@amd.com>,
"Pan, Xinhui" <Xinhui.Pan@amd.com>
Cc: Tom Rix <trix@redhat.com>,
llvm@lists.linux.dev, Nick Desaulniers <ndesaulniers@google.com>,
patches@lists.linux.dev, dri-devel@lists.freedesktop.org,
Nathan Chancellor <nathan@kernel.org>,
amd-gfx@lists.freedesktop.org,
Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Subject: [PATCH 0/5] drm/amd/display: Reduce stack usage for clang
Date: Tue, 30 Aug 2022 13:34:04 -0700 [thread overview]
Message-ID: <20220830203409.3491379-1-nathan@kernel.org> (raw)
Hi all,
This series aims to address the following warnings, which are visible
when building x86_64 allmodconfig with clang after commit 3876a8b5e241
("drm/amd/display: Enable building new display engine with KCOV
enabled").
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3542:6: error: stack frame size (2200) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
^
1 error generated.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3908:6: error: stack frame size (2216) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
^
1 error generated.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:1721:6: error: stack frame size (2152) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml32_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
^
1 error generated.
This series is based on commit b3235e8635e1 ("drm/amd/display: clean up
some inconsistent indentings"). These warnings are fatal for
allmodconfig due to CONFIG_WERROR so ideally, I would like to see these
patches cherry-picked to a branch targeting mainline to allow our builds
to go back to green. However, since this series is not exactly trivial
in size, I can understand not wanting to apply these to mainline during
the -rc cycle. If they cannot be cherry-picked to mainline, I can add a
patch raising the value of -Wframe-larger-than for these files that can
be cherry-picked to 6.0/mainline then add a revert of that change as the
last patch in the stack so everything goes back to normal for -next/6.1.
I am open to other options though!
I have built this series against clang 16.0.0 (ToT) and GCC 12.2.0 for
x86_64. It has seen no runtime testing, as my only test system with AMD
graphics is a Renoir one, which as far as I understand it uses DCN 2.1.
Nathan Chancellor (5):
drm/amd/display: Reduce number of arguments of
dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport()
drm/amd/display: Reduce number of arguments of
dml32_CalculatePrefetchSchedule()
drm/amd/display: Reduce number of arguments of dml31's
CalculateWatermarksAndDRAMSpeedChangeSupport()
drm/amd/display: Reduce number of arguments of dml31's
CalculateFlipSchedule()
drm/amd/display: Mark dml30's UseMinimumDCFCLK() as noinline for stack
usage
.../dc/dml/dcn30/display_mode_vba_30.c | 2 +-
.../dc/dml/dcn31/display_mode_vba_31.c | 420 +++++-------------
.../dc/dml/dcn32/display_mode_vba_32.c | 236 +++-------
.../dc/dml/dcn32/display_mode_vba_util_32.c | 323 ++++++--------
.../dc/dml/dcn32/display_mode_vba_util_32.h | 51 +--
5 files changed, 318 insertions(+), 714 deletions(-)
base-commit: b3235e8635e1dd7ac1a27a73330e9880dfe05154
--
2.37.2
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org>
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 König" <christian.koenig@amd.com>,
"Pan, Xinhui" <Xinhui.Pan@amd.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
Tom Rix <trix@redhat.com>,
Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
llvm@lists.linux.dev, patches@lists.linux.dev,
Nathan Chancellor <nathan@kernel.org>
Subject: [PATCH 0/5] drm/amd/display: Reduce stack usage for clang
Date: Tue, 30 Aug 2022 13:34:04 -0700 [thread overview]
Message-ID: <20220830203409.3491379-1-nathan@kernel.org> (raw)
Hi all,
This series aims to address the following warnings, which are visible
when building x86_64 allmodconfig with clang after commit 3876a8b5e241
("drm/amd/display: Enable building new display engine with KCOV
enabled").
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3542:6: error: stack frame size (2200) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
^
1 error generated.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3908:6: error: stack frame size (2216) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
^
1 error generated.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:1721:6: error: stack frame size (2152) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml32_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
^
1 error generated.
This series is based on commit b3235e8635e1 ("drm/amd/display: clean up
some inconsistent indentings"). These warnings are fatal for
allmodconfig due to CONFIG_WERROR so ideally, I would like to see these
patches cherry-picked to a branch targeting mainline to allow our builds
to go back to green. However, since this series is not exactly trivial
in size, I can understand not wanting to apply these to mainline during
the -rc cycle. If they cannot be cherry-picked to mainline, I can add a
patch raising the value of -Wframe-larger-than for these files that can
be cherry-picked to 6.0/mainline then add a revert of that change as the
last patch in the stack so everything goes back to normal for -next/6.1.
I am open to other options though!
I have built this series against clang 16.0.0 (ToT) and GCC 12.2.0 for
x86_64. It has seen no runtime testing, as my only test system with AMD
graphics is a Renoir one, which as far as I understand it uses DCN 2.1.
Nathan Chancellor (5):
drm/amd/display: Reduce number of arguments of
dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport()
drm/amd/display: Reduce number of arguments of
dml32_CalculatePrefetchSchedule()
drm/amd/display: Reduce number of arguments of dml31's
CalculateWatermarksAndDRAMSpeedChangeSupport()
drm/amd/display: Reduce number of arguments of dml31's
CalculateFlipSchedule()
drm/amd/display: Mark dml30's UseMinimumDCFCLK() as noinline for stack
usage
.../dc/dml/dcn30/display_mode_vba_30.c | 2 +-
.../dc/dml/dcn31/display_mode_vba_31.c | 420 +++++-------------
.../dc/dml/dcn32/display_mode_vba_32.c | 236 +++-------
.../dc/dml/dcn32/display_mode_vba_util_32.c | 323 ++++++--------
.../dc/dml/dcn32/display_mode_vba_util_32.h | 51 +--
5 files changed, 318 insertions(+), 714 deletions(-)
base-commit: b3235e8635e1dd7ac1a27a73330e9880dfe05154
--
2.37.2
next reply other threads:[~2022-08-30 20:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-30 20:34 Nathan Chancellor [this message]
2022-08-30 20:34 ` [PATCH 0/5] drm/amd/display: Reduce stack usage for clang Nathan Chancellor
2022-08-30 20:34 ` [PATCH 1/5] drm/amd/display: Reduce number of arguments of dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport() Nathan Chancellor
2022-08-30 20:34 ` Nathan Chancellor
2022-08-30 20:34 ` [PATCH 2/5] drm/amd/display: Reduce number of arguments of dml32_CalculatePrefetchSchedule() Nathan Chancellor
2022-08-30 20:34 ` Nathan Chancellor
2022-08-30 20:34 ` [PATCH 3/5] drm/amd/display: Reduce number of arguments of dml31's CalculateWatermarksAndDRAMSpeedChangeSupport() Nathan Chancellor
2022-08-30 20:34 ` Nathan Chancellor
2022-08-30 20:34 ` [PATCH 4/5] drm/amd/display: Reduce number of arguments of dml31's CalculateFlipSchedule() Nathan Chancellor
2022-08-30 20:34 ` Nathan Chancellor
2022-08-30 20:34 ` [PATCH 5/5] drm/amd/display: Mark dml30's UseMinimumDCFCLK() as noinline for stack usage Nathan Chancellor
2022-08-30 20:34 ` Nathan Chancellor
2022-09-11 20:58 ` [PATCH 0/5] drm/amd/display: Reduce stack usage for clang Maíra Canal
2022-09-11 20:58 ` Maíra Canal
2022-09-12 21:50 ` Rodrigo Siqueira Jordao
2022-09-12 21:50 ` Rodrigo Siqueira Jordao
2022-09-12 22:02 ` Nathan Chancellor
2022-09-12 22:02 ` Nathan Chancellor
2022-09-12 22:02 ` Nathan Chancellor
2022-09-13 22:48 ` Rodrigo Siqueira Jordao
2022-09-13 22:48 ` Rodrigo Siqueira Jordao
2022-09-13 22:48 ` Rodrigo Siqueira Jordao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220830203409.3491379-1-nathan@kernel.org \
--to=nathan@kernel.org \
--cc=Rodrigo.Siqueira@amd.com \
--cc=Xinhui.Pan@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=llvm@lists.linux.dev \
--cc=ndesaulniers@google.com \
--cc=patches@lists.linux.dev \
--cc=sudipm.mukherjee@gmail.com \
--cc=sunpeng.li@amd.com \
--cc=trix@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.