Recent commits break multi-platform v6+v7 builds

[kmihelich]

The commits 3aaac88 and c2def2a by @popcornmix break building the kernel in a multi-platform v6+v7 configuration, which has worked for the entire 4.9 release:

CONFIG_ARCH_MULTIPLATFORM=y
CONFIG_ARCH_MULTI_V6=y
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y

giving the following errors, which are obvious from looking at the second commit listed above:

arch/arm/mm/cache-v7.o: In function `rpi_dma_inv_range':
(.text+0x1fc): multiple definition of `rpi_dma_inv_range'
arch/arm/mm/cache-v6.o:(.text+0xb4): first defined here
arch/arm/mm/cache-v7.o: In function `rpi_dma_clean_range':
(.text+0x244): multiple definition of `rpi_dma_clean_range'
arch/arm/mm/cache-v6.o:(.text+0x100): first defined here

[popcornmix]

Understood. I'll look for a solution tomorrow.

[popcornmix]

Can you build okay now?

[kmihelich]

This does build now, but since both CONFIG_CPU_CACHE_V7 and CONFIG_CPU_CACHE_V6 are defined, the v7 assembly will be run on a v6 platform. Since these are separate versions of the function, I'd assume that a v6 core is not intended to run v7_dma_inv_range. If you want to export these functions, you might look to the implementation of other exported functions to see how to handle this safely, particularly if you ever intend for this modification to be submitted upstream.

[popcornmix]

This will not be upstreamed (certainly in current form).
The API is purely designed for the HEVC optimisation work which will only ever run on Pi2/Pi3, so while it is ugly, it is not a serious problem.
Do you know of a runtime check for whether we are v6 or v7 when using a multiplatform build?

[kmihelich]

Offhand, there are the CPU ID functions in arch/arm/kernel/setup.c that are used for /proc/cpuinfo.

[invisiblek]

How about something like this?
invisiblek@c30003d

I have to admit, when we start talking assembly its out of my wheelhouse, but this seems logical to me. Pretty much all android kernels use these APIs this way.

However, there's about 3 changes there that can, and probably should, be split into separate commits.