Re: [PATCH] drm/amd/display: fix usage of DC_FPU_{BEGIN,END} with PREEMPT_RT

Mikhail Gavrilov <[email protected]> Wed, 29 Jul 2026 19:39:34 +0500
Newsgroups dev.linux.lists.linux-rt-devel,org.freedesktop.lists.amd-gfx,org.kernel.vger.linux-kernel,org.kernel.vger.linux-next,org.kernel.vger.stable
Message-ID <CABXGCsONHe2ST-==Gso2748i7W_POPiUAF2MrrmTuqoQr7z3gg@mail.gmail.com>
On Wed, Jul 29, 2026 at 5:36=E2=80=AFPM Bert Karwatzki <[email protected]> w=
rote:
>
> I did try a different approach, using DC_RUN_WITH_PREEMPTION_ENABLED furt=
her
> upward in the calltrace (This would have the slight benefit of more code
> running with preemption enabled). This does not work because dml21_utils.=
c is compiled
> as a _LINUX_FPU_COMPILATION_UNIT, so DC_RUN_WITH_PREEMPTION_ENABLED does =
nothing.

Confirmed, and the chain is worth spelling out because it is not obvious
from the call site:

  Makefile:1127:      CC_FLAGS_FPU +=3D -D_LINUX_FPU_COMPILATION_UNIT
  dc/dml2_0/Makefile: applies $(CC_FLAGS_FPU) to every object under
                      dc/dml2_0/ ("Add FPU flags to all dml2 files by
                      default")

so both files you tried are built with -D_LINUX_FPU_COMPILATION_UNIT,
and in that branch of dc_fpu.h the macro is:

  #define DC_RUN_WITH_PREEMPTION_ENABLED(code) code

What I think is the real problem here: in the same branch DC_FP_START()
and DC_FP_END() are defined as BUILD_BUG(), so misusing those inside an
FPU compilation unit fails the build.  DC_RUN_WITH_PREEMPTION_ENABLED()
silently degrades to a plain call instead.  It compiles cleanly, looks
correct on review, and does nothing - which is exactly the trap you just
walked into.  Making it BUILD_BUG() as well would turn that into a
compile error.  I can send that as a separate patch if AMD agrees it is
the right direction.

This also explains the asymmetry with 183182235f6d: dc/resource/dcn32/
does not get the FPU flags, so the call-site wrap there expands to the
real thing, while the equivalent wrap in the dml21 path would have been
a no-op.  Another reason to guard the allocation in the callee, as your
patch does.

--=20
Thanks,
Mikhail