We simulate the PSCI CPU_OFF operation by reseting the core via RMR.
For secondaries, that already puts them in the holding pen waiting for a
"warm boot" request as part of PSCI CPU_ON. For the BSP, we have to add
logic to distinguish a regular boot from a CPU_OFF state, where, like the
secondaries, the BSP needs to wait foor a "warm boot" request as part
of CPU_ON.

Testing done:

- ACS suite now passes more tests (since it repeatedly
calls code on secondaries via CPU_ON).

- Linux testing including offlining/onlineing CPU0, e.g.
"echo 0 > /sys/devices/system/cpu/cpu0/online".

Change-Id: Id0ae11a0ee0721b20fa2578b54dadc72dcbd69e0
Link: https://developer.trustedfirmware.org/T686
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
[Andre: adapt to unified plat_helpers.S, smaller fixes]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

When writing to arbitrary locations in memory using a constructed
pointer, there is no guarantee that the compiler does not optimise away
the access, since it cannot detect any dependency.

One typical solution is to use the "volatile" keyword, but using MMIO
accessors in usually the better answer, to avoid torn writes.

Replace the usage of an array with such an MMIO accessor function in
rpi3_pwr_domain_on(), to make sure the write is really happening.

Change-Id: Ia18163c95e92f1557471089fd18abc6dc7fee0c7
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

The hooks were populated but the power down left the CPU in limbo-land.
What we need to do - until there is a way to actually power off - is to
turn off the MMU and enter the spinning loop as if we were cold-booted.
This allows the on-call to pick up the CPU again.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Change-Id: Iefc7a58424e3578ad3dd355a7bd6eaba4b412699

As the PSCI "power" management functions for the Raspberry Pi 3 port
will be shared with the upcoming RPi4 support, we need to prepare them
for dealing with the GIC interrupt controller.
Splitting this code just for those simple calls to the generic GIC
routines does not seem worthwhile, so just use a #define the protect the
GIC code from being included by the existing RPi3 code.

Change-Id: Iaca6b0214563852b28ad4a088ec45348ae8be40d
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

To be able to share code more easily between the existing Raspberry Pi 3
and the upcoming Raspberry Pi 4 platform, move some code which is not
board specific into a "common" directory.

Change-Id: I9211ab2d754b040128fac13c2f0a30a5cc8c7f2c
Signed-off-by: Andre Przywara <andre.przywara@arm.com>