dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Samuel Holland" <samuel.holland@sifive.com>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Conor.Dooley" <conor.dooley@microchip.com>
Cc: llvm@lists.linux.dev, "Leo Li" <sunpeng.li@amd.com>,
	"Pan Xinhui" <Xinhui.Pan@amd.com>,
	"Rodrigo Siqueira" <Rodrigo.Siqueira@amd.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	amd-gfx@lists.freedesktop.org,
	"Alex Deucher" <alexander.deucher@amd.com>,
	linux-riscv@lists.infradead.org,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V
Date: Sat, 09 Dec 2023 22:42:56 +0100	[thread overview]
Message-ID: <7996d21a-3e97-408b-82a3-3bad432095a2@app.fastmail.com> (raw)
In-Reply-To: <07d27191-12b6-4c84-b80e-75c618df9de4@sifive.com>

On Sat, Dec 9, 2023, at 22:29, Samuel Holland wrote:
> On 2023-12-09 2:38 PM, Arnd Bergmann wrote:
>> On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote:
>>> On 2023-11-29 6:42 PM, Nathan Chancellor wrote:
>>>>
>>>> https://lore.kernel.org/20231019205117.GA839902@dev-arch.thelio-3990X/
>>>
>>> I also see one of these with clang 17 even with KASAN disabled:
>>>
>>> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:37:6:
>>> warning: stack frame size (2208) exceeds limit (2048) in 'dml32_recalculate'
>>> [-Wframe-larger-than]
>>> void dml32_recalculate(struct display_mode_lib *mode_lib)
>>>
>>>      ^
>>> 1532/2208 (69.38%) spills, 676/2208 (30.62%) variables
>>>
>>> So I'm in favor of just raising the limit for these files for clang, like you
>>> suggested in the linked thread.
>> 
>> How about just adding a BUG_ON(IS_ENABLED(CONFIG_RISCV))
>> in that function? That should also avoid the build failure
>> but give a better indication of where the problem is
>> if someone actually runs into that function and triggers
>> a runtime stack overflow.
>
> Won't that break actual users of the driver, trading an unlikely but
> theoretically possible stack overflow for a guaranteed crash? The intent of this
> series is that I have one of these GPUs plugged in to a RISC-V board, and I want
> to use it.

Ah, I thought you just wanted to get it to compile cleanly
so you could use some of the more common cards. If you
are trying to run the dcn32 code specifically, then you
should definitely fix the stack usage of that function
instead.

      Arnd

  reply	other threads:[~2023-12-09 21:44 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-22  3:05 [PATCH 0/3] riscv: Add kernel-mode FPU support for amdgpu Samuel Holland
2023-11-22  3:05 ` [PATCH 1/3] riscv: Add support for kernel-mode FPU Samuel Holland
2023-11-22 20:23   ` kernel test robot
2023-11-23  1:54   ` kernel test robot
     [not found]   ` <ZV283NfE/K5zLXDD@infradead.org>
2023-12-08  4:17     ` Samuel Holland
2023-11-22  3:05 ` [PATCH 2/3] riscv: Factor out riscv-march-y to a separate Makefile Samuel Holland
2023-11-22  3:05 ` [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V Samuel Holland
2023-11-23 14:23   ` Conor Dooley
2023-11-30  0:42     ` Nathan Chancellor
2023-11-30  8:27       ` Conor Dooley
2023-12-08  5:04       ` Samuel Holland
2023-12-09 20:38         ` Arnd Bergmann
2023-12-09 21:29           ` Samuel Holland
2023-12-09 21:42             ` Arnd Bergmann [this message]
2023-12-11 15:17             ` Alex Deucher
2023-12-11 15:40               ` Samuel Holland
     [not found]   ` <ZV2+f/yu3C6xTVqn@infradead.org>
2023-12-08  4:49     ` Samuel Holland
     [not found]       ` <ZXgH6un2uLdjQ48X@infradead.org>
2023-12-12 17:42         ` Josh Poimboeuf

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=7996d21a-3e97-408b-82a3-3bad432095a2@app.fastmail.com \
    --to=arnd@arndb.de \
    --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=conor.dooley@microchip.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=llvm@lists.linux.dev \
    --cc=nathan@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=samuel.holland@sifive.com \
    --cc=sunpeng.li@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).