The Linaro tracking kernel and UEFI do not work OOB in GICv3 mode. This patch
adds instructions to the user-guide.md for changes required to both these
components in order to run them with the GICv3 only driver in ARM TF.

Change-Id: I57aebadfa65566c83a37b2501f43608f1ea77212

This patch makes temporary changes to the FVP port to use the GICv3 driver. The
major changes are as follows:

1. The driver expects a separate list of interrupts IDs corresponding to Group0
   and Group1 Secure interrupts. SGI0 and SGI6 are marked as Group0 interrupts
   as an example.

2. The hash function used to convert an MPIDR into a linear index by
   plat_get_core_pos_by_mpidr() and plat_get_my_core_pos() APIs is passed to the
   driver to enable conversion of GIC affinity values from GICR_TYPER to
   processor numbers.

3. The common driver for handling interrupts in plat/common/plat_gic.c has been
   changed to assume the presence of only a GICv3 driver.

Change-Id: I7fc27d61fc6c2a60cea2436b676c5737d0257df6

This patch adds a driver for ARM GICv3 systems that need to run software stacks
where affinity routing is enabled across all privileged exception levels for
both security states. This driver does not cater for legacy support of
interrupts and asymmetric configurations.

The existing GIC driver has been preserved. Its code has been refactored such
that functionality common to GICv2 and GICv3 systems has been moved to
common/arm_gic_common.c. The corresponding header is in
drivers/arm/arm_gic_common.h.

The driver interface has been implemented in v3/arm_gicv3_main.c. The
corresponding header is in drivers/arm/arm_gicv3.h. Helper functions have been
implemented in v3/arm_gicv3_helpers.c and are accessible through the
arm_gicv3_private.h header.

Change-Id: I8c3c834a1d049d05b776b4dcb76b18ccb927444a

On a GICv2 system, interrupts that should be handled in the secure world are
typically signalled as FIQs. On a GICv3 system, these interrupts are signalled
as IRQs instead. The mechanism for handling both types of interrupts is the same
in both cases. This patch enables the TSP to run on a GICv3 system by:

1. adding support for handling IRQs in the exception handling code.
2. removing use of "fiq" in the names of data structures, macros and functions.

The build option TSPD_ROUTE_IRQ_TO_EL3 has been renamed to
TSP_NS_INT_ASYNC_PREEMPT. The documentation is also updated accordingly.

Change-Id: I1807d371f41c3656322dd259340a57649833065e

The TSP passes control back to EL3 through an SMC in response to an interrupt in
the following scenarios:

1. An FIQ that has preempted normal world execution is handed to the TSP by EL3
   firmware. The interrupt is deasserted or is preempted by a higher priority
   interrupt by the time the TSP acknowledges it. In this case, the TSP issues
   an SMC with the ID as TSP_EL3_FIQ.

2. An IRQ preempts TSP execution while it is handling a standard SMC. In this
   case, the TSP issues an SMC with the ID as TSP_PREEMPTED.

In both the cases, the TSPD hands control back to the normal world. In 2. it
additionally returns an error code to the normal to indicate that the standard
SMC it had issued has been preempted but not completed.

This patch unifies the handling of these two cases in the TSPD and ensures that
the TSP only uses TSP_PREEMPTED instead of separate SMC IDs. The TSPD is able to
distinguish between the two scenarios by checking if a standard SMC is in
progress.

On a GICv3 system, when the secure world has affinity routing enabled, in 2. an
FIQ will preempt TSP execution instead of an IRQ. The FIQ could be a result of a
Group 0 or a Group 1 NS interrupt. In both case, the TSPD passes control back to
the normal world upon receipt of the TSP_PREEMPTED SMC. A Group 0 interrupt will
immediately preempt execution to EL3 where it will be handled.

Change-Id: I9895344db74b188021e3f6a694701ad272fb40d4

Re-design bakery lock allocation and algorithm

Add more configurability options in ARM platform port code

This patch update Mediatek port to use the `DEFINE_BAKERY_LOCK` macro instead of
specifying the exact data structure to use for a bakery lock and the input
linker section that it should be allocated to.

Change-Id: I2116dbe27010bb46d7cc64fafef55c7240c4c721

This patch updates ARM platform ports to use the new unified bakery locks
API. The caller does not have to use a different bakery lock API depending upon
the value of the USE_COHERENT_MEM build option.

NOTE: THIS PATCH CAN BE USED AS A REFERENCE TO UPDATE OTHER PLATFORM PORTS.

Change-Id: I1b26afc7c9a9808a6040eb22f603d30192251da7

This patch unifies the bakery lock api's across coherent and normal
memory implementation of locks by using same data type `bakery_lock_t`
and similar arguments to functions.

A separate section `bakery_lock` has been created and used to allocate
memory for bakery locks using `DEFINE_BAKERY_LOCK`. When locks are
allocated in normal memory, each lock for a core has to spread
across multiple cache lines. By using the total size allocated in a
separate cache line for a single core at compile time, the memory for
other core locks is allocated at link time by multiplying the single
core locks size with (PLATFORM_CORE_COUNT - 1). The normal memory lock
algorithm now uses lock address instead of the `id` in the per_cpu_data.
For locks allocated in coherent memory, it moves locks from
tzfw_coherent_memory to bakery_lock section.

The bakery locks are allocated as part of bss or in coherent memory
depending on usage of coherent memory. Both these regions are
initialised to zero as part of run_time_init before locks are used.
Hence, bakery_lock_init() is made an empty function as the lock memory
is already initialised to zero.

The above design lead to the removal of psci bakery locks from
non_cpu_power_pd_node to psci_locks.

NOTE: THE BAKERY LOCK API WHEN USE_COHERENT_MEM IS NOT SET HAS CHANGED.
THIS IS A BREAKING CHANGE FOR ALL PLATFORM PORTS THAT ALLOCATE BAKERY
LOCKS IN NORMAL MEMORY.

Change-Id: Ic3751c0066b8032dcbf9d88f1d4dc73d15f61d8b