Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



O 07/13, Alex Deucher wrote:
> On Wed, Jul 13, 2022 at 7:09 PM Guenter Roeck <linux@xxxxxxxxxxxx> 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

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux