lkml.org 
[lkml]   [2022]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds
O 07/13, Alex Deucher wrote:
> On Wed, Jul 13, 2022 at 7:09 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Wed, Jul 13, 2022 at 05:20:40PM -0400, Alex Deucher wrote:
> > > >
> > > > The problem is not the FPU operations, but the fact that soft-float
> > > > and hard-float compiled code is linked together. The soft-float and
> > > > hard-float ABIs on powerpc are not compatible, so one ends up with
> > > > an object file which is partially soft-float and partially hard-float
> > > > compiled and thus uses different ABIs. That can only create chaos,
> > > > so the linker complains about it.
> > >
> > > I get that, I just don't see why only DCN 3.1.x files have this
> > > problem. The DCN 2.x files should as well.
> > >
> >
> > Seen in drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile:
> >
> > # prevent build errors regarding soft-float vs hard-float FP ABI tags
> > # this code is currently unused on ppc64, as it applies to Renoir APUs only
> > ifdef CONFIG_PPC64
> > CFLAGS_$(AMDDALPATH)/dc/clk_mgr/dcn21/rn_clk_mgr.o := $(call cc-option,-mno-gnu-attribute)
> > endif
> >
> > Does that explain it ?
>
> I would expect to see it in dcn20_resource.c and dcn30_clk_mgr.c for
> example. They follow the same pattern as the dcn 3.1.x files. They
> call functions that use FP, but maybe there is some FP code still in
> those functions that we missed somehow.

Hi,

I'm a little late here, but I'm not able to reproduce the issue yet.
I have this setup:
- gcc 11.3.0
- binutils 2.38.50
- mainline kernel (torvalds) version: 5.19.0-rc6 (cross-compiling)
-> make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- allmodconfig
=> DRM_AMD_DC [=y] && HAS_IOMEM [=y] && DRM [=m] && DRM_AMDGPU [=m] && (X86 || PPC64 [=y]) && (!KCOV_INSTRUMENT_ALL [=n] || !KCOV_ENABLE_COMPARISONS [=n])
-> make -j16 ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu-

Am I missing something?

So, as Alex mentioned the possibility of some non-isolated FPU code in
3.1, I reviewed dcn31 code and my best bet so far is that the issue
is here:

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c#L1721

Although dcn31_update_soc_for_wm_a() is only called inside
dml/dcn31/dcn31_fpu:
- dc->res_pool->funcs->update_soc_for_wm_a(dc, context);

it's declared in dcn31_resource and has FPU code. So, we should move it
to dml/dcn31/dcn31_fpu.

However, as I can't reproduce the issue, I don't know if it addresses
the problem reported here and also if everything will be clean after
moving it.

Guenter,

Can you provide more info about your setup: cross-compile or not, any
flags, branch, etc?

Best Regards,

Melissa

>
> Alex
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2022-07-14 20:52    [W:0.106 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site