qdev: Define halting API

Define APIs on the device level for halting and un-halting a device. The
semantic is the device freezes its state and does not respond to any form
of transaction.

The main intended use cases is to implement clock gating and power down. clock
gating is just a halt, whereas power down is a reset() and halt(). Unhalt is
then used to ungate the clock or power up the device.

Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
qom/cpu.c: Encapsulate cpu halting

Set up the Device level halting API to halt cpus. This allows holders of a
pointer to the CPU to halt it from the TYPE_DEVICE abstraction. (i.e. they
can halt it even if they dont know its a CPU).

Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
qom/cpu.c: Hook CPU reset up to device reset

Hookup the CPU::reset function up as the Device::reset function. This allows
devices that abstract away the fact that the device is a CPU to reset it.

Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
sun4m: Use halting API to halt/unhalt CPUs

Example for a change pattern that could be applied to use the halting API rather
than directly modifying the CPU halted bit.

Untested RFC.

Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
xilinx_zynq: added smp support

Added linux smp support for the xilinx zynq platform (2x cpus are supported)

---CHANGELOG---
Changed from v2:
macro defined the maximum number of CPUS
Changed from v1:
Addressed PMM review
Shorted secondary bootloop using MVN instruction.
Used default reset secondary instead of custom one.
Rebased against QOM cpu developments.
Few whitespace fixes.
---END---

Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
zynq_slcr: Add links to the CPUs

The SLCR needs to be able to reset the CPUs, so link the CPUs to the slcr.

---CHANGELOG---
Changed from v2:
Soften type of CPU to Device
Looped link creator
---END---

Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
zynq_slcr: Implement CPU reset and halting

Implement the CPU reset and halt functions of the A9_CPU_RST_CTRL register
(offset 0x244).

---CHANGELOG---
changed from v2:
used device halting API instead of talking to the cpu.
---END---

Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
COVER: Reset and Halting modifications + Zynq SMP

---CHANGELOG---
Hi All. The clock controller module in the Zynq platform has the ability to halt
and reset arbitrary devices, including the CPU. We use this feature to implement
SMP Linux - the kernel halts CPU1 then rewrites the vector table to the
secondary entry point and unhalts.

The clock controller however is reasonable generic, in that in has the ability
to halt and reset any arbitrary device in the Zynq SoC. The interface for doing
this is reasonably consistent. So im looking for unified way to halt and reset
arbitrary devices CPUs included. So given we already have reset() defined on the
TYPE_DEVICE level, i've added halt as well.

This series is based on v3 of the current qom-cpu queue to pick up the move of
cpu halt out of the env. From this I attach the cpu::halted bit to the
Device::(un)halt function.

Next up, CPUs seem to have a different reset path to normal devices. So I have
trivially hooked up CPU::Reset to Device::Reset. This means that anyone who
holds a DeviceState pointer to the CPU can reset it properly without actually
knowing its a CPU.

With the halt API I played with changing an existing device over to use it in
place of the CPU halted bit (sun4m).

I then finally add SMP support to the Zynq machine, and patch the Zynq SLCR
(my clock controller) to have DeviceState pointers to the CPUs. device_reset()
and device_halt() is where the magic happens.

Future work, more devices in Zynq will have halt and reset. My agenda for
abstracting away the fact that attached device is a CPU is to allow for
consistent implementation and a single code path for the clock controlled
devices.
---END---

Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>