Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

[Randy Dunlap <rdunlap@infradead.org>]

On 4/19/21 6:16 AM, Michael Ellerman wrote:
> Randy Dunlap <rdunlap@infradead.org> writes:
>> On 4/18/21 10:46 AM, Segher Boessenkool wrote:
>>> On Sun, Apr 18, 2021 at 06:24:29PM +0200, Christophe Leroy wrote:
>>>> Le 17/04/2021 à 22:17, Randy Dunlap a écrit :
>>>>> Should the code + Kconfigs/Makefiles handle that kind of
>>>>> kernel config or should ALTIVEC always mean PPC_FPU as well?
>>>>
>>>> As far as I understand, Altivec is completely independant of FPU in Theory. 
>>>
>>> And, as far as the hardware is concerned, in practice as well.
>>>
>>>> So it should be possible to use Altivec without using FPU.
>>>
>>> Yup.
>>>
>>>> However, until recently, it was not possible to de-activate FPU support on 
>>>> book3s/32. I made it possible in order to reduce unneccessary processing on 
>>>> processors like the 832x that has no FPU.
>>>
>>> The processor has to implement FP to be compliant to any version of
>>> PowerPC, as far as I know?  So that is all done by emulation, including
>>> all the registers?  Wow painful.
>>>
>>>> As far as I can see in cputable.h/.c, 832x is the only book3s/32 without 
>>>> FPU, and it doesn't have ALTIVEC either.
>>>
>>> 602 doesn't have double-precision hardware, also no 64-bit FP registers.
>>> But that CPU was never any widely used :-)
>>>
>>>> So we can in the future ensure that Altivec can be used without FPU 
>>>> support, but for the time being I think it is OK to force selection of FPU 
>>>> when selecting ALTIVEC in order to avoid build failures.
>>>
>>> It is useful to allow MSR[VEC,FP]=1,0 but yeah there are no CPUs that
>>> have VMX (aka AltiVec) but that do not have FP.  I don't see how making
>>> that artificial dependency buys anything, but maybe it does?
>>>
>>>>> I have patches to fix the build errors with the config as
>>>>> reported but I don't know if that's the right thing to do...
>>>
>>> Neither do we, we cannot see those patches :-)
>>
>> Sure.  I'll post them later today.
>> They keep FPU and ALTIVEC as independent (build) features.
> 
> Those patches look OK.
> 
> But I don't think it makes sense to support that configuration, FPU=n
> ALTVEC=y. No one is ever going to make a CPU like that. We have enough

Agreed.

> testing surface due to configuration options, without adding artificial
> combinations that no one is ever going to use.
> 
> IMHO :)
> 
> So I'd rather we just make ALTIVEC depend on FPU.
> 
> cheers

Makes sense and sounds good to me.

thanks.
-- 
~Randy