Hi,
On Tue, Dec 7, 2010 at 11:04 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Tue, Dec 07, 2010 at 10:45:42AM +0000, Dave Martin wrote:
Yes-- though I didn't elaborate on it. You need a packager that can understand, say, that a binary built for ARMv5 EABI can interoperate with ARMv7 binaries etc. Again, I've heard it suggested that RPM can handle this, but I haven't looked at it in detail myself.
That is indeed the case - as on x86, it used to be common to build the majority of the distribution for i386, and glibc and a few other bits for a range of ix86 CPUs.
rpm and yum know that i386 is compatible with i486, which is compatible with i586 etc, so it will install an i386 package on i686 if no i486, i586 or i686 package is available.
It does the same for ARM with ARMv3, ARMv4 etc.
That sounds plausible. If you really want to go to town on this it gets more complicated, but there's still a lot of value in modelling the architectural development as a linear progression in this way.
The dynamic hwcaps approach doesn't really solve that problem:
Has anyone investigated whether it is possible to power down things like Neon etc meanwhile leaving the rest of the CPU running? I've not seen anything in the ARM documentation to suggest that's the case.
Even in MPCore based systems, the interface between the SCU and individual processors by default doesn't have the necessary clamps built in to allow individual CPUs to be powered off, and I'm not aware of any designs which decided to enable this feature (as there's a performance penalty). So I'd be really surprised if there was any support for powering down Neon separately from the host CPU.
It's not part of the architecture per se, but some SoCs do put NEON in a separate power domain and can power manage it somewhat indepedently.
However, I guess we need to clarify exactly how this works for SoCs in practice. If NEON and VFP are power-managed co-dependently (for example, but no so likely(?)) this is not so useful to us ... since it's becoming common to build everything with -mfpu=vfp*.
Because the kernel only uses FPEXC.EN to en/disable these extensions, NEON and VFP are somewhat tied together ... though we might be able to get more flexible by toggling the CPACR.ASEDIS control bit instead. I don't believe the kernel currently touches this (?)
If that's the case, it's entirely pointless discussing what userspace can or can't do - if you have Neon available and can't power it down, and it's faster for doing something, you might as well use it so you can put the main CPU into WFI mode or get on with some other useful work.
Indeed ... my layman's understanding is that it is worth it on some platforms, but I guess I need to clarify this with someone who understands the hardware.
Cheers ---Dave