From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsAJW-00067M-TW for qemu-devel@nongnu.org; Wed, 04 Jun 2014 08:29:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WsAJO-0001Vg-Bu for qemu-devel@nongnu.org; Wed, 04 Jun 2014 08:29:06 -0400 From: Alexander Graf Date: Wed, 4 Jun 2014 14:28:51 +0200 Message-Id: <1401884936-12907-1-git-send-email-agraf@suse.de> Subject: [Qemu-devel] [PATCH 0/5] Platform device support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-ppc@nongnu.org Cc: qemu-devel@nongnu.org, eric.auger@linaro.org Platforms without ISA and/or PCI have had a seriously hard time in the dynamic device creation world of QEMU. Devices on these were modeled as SysBus devices which can only be instantiated in machine files, not through -device. Why is that so? Well, SysBus is trying to be incredibly generic. It allows you to plug any interrupt sender into any other interrupt receiver. It allows you to map a device's memory regions into any other random memory region. All of that only works from C code or via really complicated command line arguments under discussion upstream right now. But do we need that level of complexity for normal devices usually? In a normal platform world (SoCs, PV machines) we have a flat memory layout we can plug our device memory into. We also have a flat IRQ model where we can plug our device IRQs into. So the idea for platform devices arose. A platform device is really just a device that exposes its qemu_irq slots and memory regions to the world. That allows us to write machine specific code that maps a platform device wherever the machine thinks fits nicely. It also allows that same machine to generate a device tree entry for platform devices easily, as it is fully aware of the interrupt lines and places it was mapped to. A device (read: user) may or may not explictly request to be mapped at a specific IRQ and/or memory address. If no explicit mapping is requested, platform devices can get mapped at convenient places by the machine. The actual pressing issue this solves is that today it's impossible to spawn serial ports from the command line. With this patch set, it's possible to do so. But it lays the groundwork for much more... Alexander Graf (5): Platform: Add platform device class Platform: Add serial device PPC: e500: Only create dt entries for existing serial ports PPC: e500: Support platform devices PPC: e500: Add support for platform serial devices default-configs/ppc-softmmu.mak | 2 + default-configs/ppc64-softmmu.mak | 2 + hw/Makefile.objs | 1 + hw/char/Makefile.objs | 1 + hw/char/serial-platform.c | 103 +++++++++++++++ hw/platform/Makefile.objs | 1 + hw/platform/device.c | 108 ++++++++++++++++ hw/ppc/e500.c | 262 +++++++++++++++++++++++++++++++++++++- hw/ppc/e500.h | 1 + hw/ppc/e500plat.c | 1 + include/hw/char/serial-platform.h | 56 ++++++++ include/hw/platform/device.h | 45 +++++++ 12 files changed, 577 insertions(+), 6 deletions(-) create mode 100644 hw/char/serial-platform.c create mode 100644 hw/platform/Makefile.objs create mode 100644 hw/platform/device.c create mode 100644 include/hw/char/serial-platform.h create mode 100644 include/hw/platform/device.h -- 1.8.1.4