After some discussion with Alex and Oliver, I think we still need to disable the whole CONFIG_NEON for our lucid kernel. Although my dynamic chip rev checking patch can make some testing pass, we still have some potential issues from user space NEON applications.
There are 2 types NEON applications:
Type 1 applications will be built twice and will generate 2 version of .so or executable files. One is -neon version and the other is -none-neon one. Then these applications will determine whether NEON is available from the hardware, if
NEON is there, it will run neon version code. Otherwise run none neon version.
Type 2 applications will enable NEON instruction code when building. And it will not determine the NEON flag from kernel. Such as Chromium.
According to the impact from second type applications, I think we will switch back to turn on the CONFIG_NEON.
@Dave,
After some discussion with Alex and Oliver, I think we still need to disable the whole CONFIG_NEON for our lucid kernel. Although my dynamic chip rev checking patch can make some testing pass, we still have some potential issues from user space NEON applications.
There are 2 types NEON applications:
Type 1 applications will be built twice and will generate 2 version of .so or executable files. One is -neon version and the other is -none-neon one. Then these applications will determine whether NEON is available from the hardware, if
NEON is there, it will run neon version code. Otherwise run none neon version.
Type 2 applications will enable NEON instruction code when building. And it will not determine the NEON flag from kernel. Such as Chromium.
According to the impact from second type applications, I think we will switch back to turn on the CONFIG_NEON.
Thanks,
-Bryan