RFC: Dynamic hwcaps

[Dave Martin]

Hi,

On Tue, Dec 7, 2010 at 11:04 AM, Russell King - ARM Linux
<linux at 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