[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADnq5_PAg8xg2J3WUfjxK_-WFaLOK7cQd6bqWDnfVqE6fpXq2Q@mail.gmail.com>
Date: Wed, 13 Jul 2022 21:11:14 -0400
From: Alex Deucher <alexdeucher@...il.com>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Rodrigo Siqueira Jordao <Rodrigo.Siqueira@....com>,
Harry Wentland <harry.wentland@....com>,
Leo Li <sunpeng.li@....com>,
Michael Ellerman <mpe@...erman.id.au>,
LKML <linux-kernel@...r.kernel.org>,
amd-gfx list <amd-gfx@...ts.freedesktop.org>,
David Airlie <airlied@...ux.ie>,
Maling list - DRI developers
<dri-devel@...ts.freedesktop.org>,
Alex Deucher <alexander.deucher@....com>,
Christian König <christian.koenig@....com>,
Daniel Axtens <dja@...ens.net>
Subject: Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for
PPC64 builds
On Wed, Jul 13, 2022 at 7:09 PM Guenter Roeck <linux@...ck-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.
Alex
Powered by blists - more mailing lists