[PATCH] drm/amdgpu: Re-enable DCN for 64-bit powerpc

[Michael Ellerman]

Guenter Roeck <linux at roeck-us.net> writes:
> On 7/25/22 13:42, Segher Boessenkool wrote:
>> On Mon, Jul 25, 2022 at 02:34:08PM -0500, Timothy Pearson wrote:
>>>>> Further digging shows that the build failures only occur with compilers
>>>>> that default to 64-bit long double.
>>>>
>>>> Where the heck do we have 'long double' things anywhere in the kernel?
>>>>
>>>> I tried to grep for it, and failed miserably. I found some constants
>>>> that would qualify, but they were in the v4l colorspaces-details.rst
>>>> doc file.
>>>>
>>>> Strange.
>>>
>>> We don't, at least not that I can see.  The affected code uses standard doubles.
>>>
>>> What I'm wondering is if the compiler is getting confused between standard and long doubles when they are both the same bit length...
>> 
>> The compiler emits the same code (DFmode things, double precision float)
>> in both cases, and it itself does not see any difference anymore fairly
>> early in the pipeline.  Compare to int and long on most 32-bit targets,
>> both are SImode, the compiler will not see different types anymore:
>> there *are* no types, except in the compiler frontend.
>> 
>> It only happens for powerpc64le things, and not for powerpc64 builds.
>> 
>> It is probably a GCC problem.  I don't see what forces the GCC build
>> here to use 64-bit long double either btw?  Compilers build via buildall
>> have all kinds of unnecessary things disabled, but not that, not
>> directly at least.
>> 
>
>  From what little documentation I can find, there appears to be
> "--with-long-double-128" and "--with-long-double-format=ieee".
> That looks like something that would need to be enabled, not disabled.
>
> FWIW, depending on compiler build options such as the above for kernel
> builds seems to be a little odd to me, and I am not sure I'd want to
> blame gcc if the kernel wants to be built with 128-bit floating point
> as default.

The kernel doesn't care what the size is, but ld refuses to link objects
built with soft/hard float if the long double size is 64-bits.

> At the very least, that should be documented somewhere,
> and if possible the kernel should refuse to build if the compiler build
> options don't meet the requirements.

The ABI says long double is 128-bits. So it's documented there :)

The kernel expects that passing `-m64 -mlittle-endian -mabi=elfv2` will
produce code that conforms to the 64-bit Little Endian ELFv2 ABI :D

But it seems those flags are not sufficient.

There is an -mlong-double-128 flag, which appears to do the right thing
regardless of how the compiler was built. I will probably add that to
the kernel CFLAGS, but that's not a change I want to do just before the
v5.19 release.

cheers