On 4/19/21 6:16 AM, Michael Ellerman wrote: > Randy Dunlap <rdun...@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