Revert "checkpoint i8259"

This reverts commit a2e2c8b.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

The PIT is not an ISA device.  It raises interrupts on IRQ 0 which is not
exposed via the ISA bus.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Still needs to be converted to memory API

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

We're now ready for QOM-ification.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

DMA_hold_DREQ already schedules DMA immediately so calling it explicitly is not
necessary.  As it turns out, fdc.c is the only caller.

dma.c hasn't been touched in years.  It's got a mix of "malc style" along with
normal QEMU style.  It's never been converted to qdev, abuses bottoms halves,
and uses way too many globals.

It's time to significantly refactor this code but before we do, let's bring it
into line with coding style.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Seems to work...

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

This is strictly code movement to reflect the new separation of 'serial' and
'isa-serial'.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

serial.c was a classic example of a "shallow" qdev conversion.  This is not the
fault of the converter, but rather the lack of good infrastructure in qdev.

The notion of every device is-a child of a single bus breaks down with uarts.
It's pretty darn common to wire up a uart chip to GPIO pins on a processor.
Heck, I've even done this myself.  There's simply no notion of a "bus" in most
cases when it comes to uarts.

But on the PC, it was absolutely possible to have an ISA expansion card with a
UART on it.  In this case, the expansion card had a standard UART chip on it
with a little bit of logic to participate in the ISA bus protocol.

This refactoring models this.  There is now a 'serial' device that does not
participate in any bus protocol but exposes a MemoryRegion and a Pin.  Most
boards now simply create this device, and then do what they need to with the
MemoryRegion and Pin.

There is also an 'isa-serial' device which has-a 'serial' device and bridges the
MemoryRegion and Pin from the 'serial' device to the ISA bus protocol.

It is now the case that every instance of SerialState is a device.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

We need to forward the chardev property from isa-serial to serial in order to
maintain compatibility.  That means we have to drop the checks for having one
device set for a given chardev.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Expose a MemoryRegion and a Pin as properties and then let the callers hook it
up however they want.  Provide a convenience interface to hook it up to an
existing ISABus.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>