From: Michael Ellerman <mpe@ellerman.id.au>
To: Daniel Kolesa <daniel@octaforge.org>, linuxppc-dev@lists.ozlabs.org
Cc: dan@danny.cz, alexdeucher@gmail.com,
tpearson@raptorengineering.com, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: drop the long-double-128 powerpc check/hack
Date: Fri, 31 Mar 2023 21:53:57 +1100 [thread overview]
Message-ID: <87o7o9b396.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <dab9cbd8-2626-4b99-8098-31fe76397d2d@app.fastmail.com>
"Daniel Kolesa" <daniel@octaforge.org> writes:
> Commit c653c591789b ("drm/amdgpu: Re-enable DCN for 64-bit powerpc")
> introduced this check as a workaround for the driver not building
> with toolchains that default to 64-bit long double.
...
> In mainline, this work is now fully done, so this check is fully
> redundant and does not do anything except preventing AMDGPU DC
> from being built on systems such as those using musl libc. The
> last piece of work to enable this was commit c92b7fe0d92a
> ("drm/amd/display: move remaining FPU code to dml folder")
> and this has since been backported to 6.1 stable (in 6.1.7).
>
> Relevant issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2288
I looked to pick this up for 6.3 but was still seeing build errors with
some compilers. I assumed that was due to some fixes coming in
linux-next that I didn't have.
But applying the patch on v6.3-rc4 I still see build errors. This is
building allyesconfig with the kernel.org GCC 12.2.0 / binutils 2.39
toolchain:
powerpc64le-linux-gnu-ld: drivers/gpu/drm/amd/display/dc/dml/display_mode_lib.o uses hard float, arch/powerpc/lib/test_emulate_step.o uses soft float
powerpc64le-linux-gnu-ld: failed to merge target specific data of file drivers/gpu/drm/amd/display/dc/dml/display_mode_lib.o
etc.
All the conflicts are between test_emulate_step.o and some file in drivers/gpu/drm/amd/display/dc/dml.
So even with all the hard-float code isolated in the dml folder, we
still hit build errors, because allyesconfig wants to link those
hard-float using objects with soft-float objects from elsewhere in the
kernel.
It seems like the only workable fix is to force the kernel build to use
128-bit long double. I'll send a patch doing that.
cheers
next prev parent reply other threads:[~2023-03-31 13:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-01 18:46 [PATCH] drm/amdgpu: drop the long-double-128 powerpc check/hack Daniel Kolesa
2023-02-01 18:46 ` Daniel Kolesa
2023-02-01 18:57 ` kernel test robot
2023-02-01 19:27 ` Deucher, Alexander
2023-02-01 19:27 ` Deucher, Alexander
2023-03-31 10:53 ` Michael Ellerman [this message]
2023-12-07 13:11 ` Christophe Leroy
2023-12-07 22:03 ` Michael Ellerman
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=87o7o9b396.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dan@danny.cz \
--cc=daniel@octaforge.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=tpearson@raptorengineering.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.