The PMUv2 specification reserves a number of event encodings
for common events.
This patch adds these events to the common event enumeration
in preparation for PMUv2 cores, such as Cortex-A15.
Acked-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
The comment about measuring TLB misses and refills in the ARMv7 perf
backend makes little sense and refers loosely to raw counters that
should be used instead.
This patch removes the comments to avoid any confusion.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Multicore implementations of the Cortex-A15 require bit 6 of the
auxiliary control register to be set in order for cache and TLB
maintenance operations to be broadcast between CPUs.
This patch adds a new proc_info structure for Cortex-A15, which enables
the SMP bit during setup and includes the new HWCAP for integer
division.
Signed-off-by: Will Deacon <will.deacon@arm.com>
This patch adds processor info for ARM Ltd. Cortex A5,
which has SCU initialisation procedure identical to A9.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
As most of the proc info content is common across all v7
processors, this patch converts existing A9 and generic v7
descriptions into a macro (allowing extra flags in future).
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
The presence of VFPv4 cannot be detected simply by looking at the FPSID
subarchitecture field, as a value >= 2 signifies the architecture as
VFPv3 or later.
This patch reads from MVFR1 to check whether or not the fused multiply
accumulate instructions are supported. Since these are introduced with
VFPv4, this tells us what we need to know.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Modern ARMv7-A cores can optionally implement these new hardware
features:
- VFPv4:
The latest version of the ARMv7 vector floating-point extensions,
including hardware support for fused multiple accumulate. D16 or D32
variants may be implemented.
- Integer divide:
The SDIV and UDIV instructions provide signed and unsigned integer
division in hardware. When implemented, these instructions may be
available in either both Thumb and ARM, or Thumb only.
This patch adds new HWCAP defines to describe these new features. The
integer divide capabilities are split into two bits for ARM and Thumb
respectively. Whilst HWCAP_IDIVA should never be set if HWCAP_IDIVT is
clear, separating the bits makes it easier to interpret from userspace.
Signed-off-by: Will Deacon <will.deacon@arm.com>
The HWCAP numbers are defined as constants, each one being a power of 2.
This has become slightly unwieldy now that we have reached 32k.
This patch changes the HWCAP defines to use (1 << n) instead of coding
the constant directly. The values remain unchanged.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Without this patch, xscale_80200_A0_A1 is missing the
icache_flush_all entry, which would result in the wrong functions
being called at run-time.
This patch re-uses xscale_icache_flush_all for
xscale_80200_A0_A1_cache_fns.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
This patch also defines a suitable flush_icache_all implementation
which would otherwise be missing, resulting in a link failure.
Thanks to Nicolas Pitre for suggesting the code for this.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Declaring strings in assembler source involves a certain amount of
tedious boilerplate code in order to annotate the resulting symbol
correctly.
Encapsulating this boilerplate in a macro should help to avoid some
duplication and the occasional mistake.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
This patch adds some generic macros to reduce boilerplate when
declaring certain common structures in arch/arm/mm/*.S
Thanks to Russell King for outlining what the
define_processor_functions macro could look like.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
