Re: [PATCH] ARM: vfp: fix fpsid register subarchitecture fieldmask width

[Russell King - ARM Linux]

On Fri, Feb 22, 2013 at 12:08:05AM -0800, Stephen Boyd wrote:
> From: Steve Muckle <smuckle@xxxxxxxxxxxxxx>
> 
> The subarchitecture field in the fpsid register is 7 bits wide.
> The topmost bit is used to designate that the subarchitecture
> designer is not ARM. We use this field to determine which VFP
> version is supported by the CPU. Since the topmost bit is masked
> off we detect non-ARM subarchitectures as supporting only
> HWCAP_VFP and not HWCAP_VFPv3 as it should be for Qualcomm's
> processors.
> 
> Use the proper width for the mask so that we report the correct
> elf_hwcap of non-ARM designed processors.

This is a *big* can of worms.  How this register is defined depends on
what document you look at:

DDI0238A/B/C: 0x41011090: (VFP9) 
 23:	0 = hw,
 22:21:	00 = FSTMX/FLDMX format is standard format 1,
 20: 	0 = Single-precision and double-precision data supported
 19:16: 0001 = architecture version
DDI0133A: 0x410000A0: (VFP10) 
 23:16: 0 = architecture version
DDI0274F: 0x410120B3: (VFP11) 
 23:	0 = hw,
 22:21: 00 = FSTMX/FLDMX format is standard format 1,
 20:	0 = Single-precision and double-precision data supported
 19:16:	0001 = architecture version
DDI0406A/B/C:
 23: hw, 22:16: architecture version

Now, DDI0238C was updated on 4th August 2010.  The ARM ARM revs A and B
were published before this version - only ARM ARM rev C post-dates this.

The ARM ARM defines bit 22 to be zero for any ARM produced VFP hardware,
and must be one for non-ARM designed VFP hardware.

Now, the ARM ARM gives these as possible values for bits 22:16:

 0000000 - VFPv1
 0000001 - VFPv2
 0000010 - VFPv3 with common VFPv2
 0000011 - VFPv3 h/w only
 0000100 - VFPv3 with common VFPv3

We _do_ test bit 20 to determine if there is support for 32 double
precision registers, and if this bit is set, we ignore the VFP.  From
the description in the ARM ARM, this is wrong if the implementer is
not ARM.

If the information above _does_ correspond accurately with all ARM
produced hardware (VFP9S, VFP10, VFP11, plus any other variants in
ARMs CPUs) then they will always have bits 22:20 as zero.  This means
we can extend the architecture field to include those bits.  We should
also arrange for VFP support to fail if any of these bits are set.

How do we handle non-ARM produced VFP hardware?  I've no idea - the
stinking pile of dogs poo that ARM Ltd have created here means that
we're going to have to decode this register in a per-designer way -
and if we don't have support for your designer, then the support code
_must_ fail to initialize and report _any_ VFP support.

This is going to be horrendously disruptive, because _I_ don't know
what values of FPSID register can be found out in the wild.  I know
that the Dove chips have a Marvell implementer value (0x56), but
these report a subarch value of 2 (which seems to correspond with
ARM Ltd's implementation of architecture coding.)  Is it fully
compatible?  Don't know.

I think the only way we're going to find out is to end up with VFP
disabled on most CPUs and wait for people to stream reports in of
their hardware breaking.  Again, way to go ARM Ltd!  What a truely
excellent situation this is!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/