From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlJyW-000879-2y for qemu-devel@nongnu.org; Fri, 16 May 2014 11:23:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WlJyQ-00039o-Kj for qemu-devel@nongnu.org; Fri, 16 May 2014 11:23:08 -0400 Received: from cantor2.suse.de ([195.135.220.15]:59035 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlJyQ-00039W-Dd for qemu-devel@nongnu.org; Fri, 16 May 2014 11:23:02 -0400 Message-ID: <53762D53.7020005@suse.de> Date: Fri, 16 May 2014 17:22:59 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v1 2/3] memory: Add sysbus memory device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, alistair.francis@xilinx.com, edgar.iglesias@gmail.com, agraf@suse.de, armbru@redhat.com Peter, Am 15.04.2014 04:21, schrieb Peter Crosthwaite: > Add a sysbus device consisting of a single ram. This allows for > instantiation of RAM just like any other device. There are a number > of good reasons to want to do this this: >=20 > 1: Consistency. RAM is not that special where board level files should > have to instantiate it with a completely different API. This reduces > complexity of board level development by hiding the memory API > completely and handling everything via the sysbus API. >=20 > 2: Device tree completeness. Ram Now shows up in info-qtree and > friends. E.g. Info qtree gives meaningful information under the > root system bus: >=20 > dev: sysbus-memory, id "zynq.ocm_ram" > size =3D 262144 (0x40000) > read-only =3D false > irq 0 > mmio 00000000fffc0000/0000000000040000 > dev: sysbus-memory, id "zynq.ext_ram" > size =3D 134217728 (0x8000000) > read-only =3D false > irq 0 > mmio 0000000000000000/0000000008000000 I had warned that I would nack any patch that justifies changes with "info qtree", so here's your gentle NAK. Please help deciding on the following patches, which do show such devices the QOM way: http://patchwork.ozlabs.org/patch/317224/ http://patchwork.ozlabs.org/patch/343136/ http://patchwork.ozlabs.org/patch/347064/ Note that this doesn't mean we can't create new SysBusDevices, it means the commit message should be changed. Regards, Andreas >=20 > 3: Remove dependence of global state. Board files don't have to > explicity request the global singleton (and much unloved) > address_space_memory() and go hacking on it. address_space_memory() > is still ultimately used, but the ugliness is hidden in one place - the > sysbus core (we can fix that another day). >=20 > 4: Data driven machine creation. There is list discussion on being able > to create or append-to sysbus machines in a data-driven way (whether > thats from command-line, monitor or scripts or whatever). This patch > removes the memory special case from that problem and allows RAM > instantiation to come via whatever solutions we come up with sysbus > device instantiation. >=20 > Signed-off-by: Peter Crosthwaite > --- >=20 > hw/core/Makefile.objs | 1 + > hw/core/sysbus-memory.c | 63 +++++++++++++++++++++++++++++++++++++++++= ++++++++ > 2 files changed, 64 insertions(+) > create mode 100644 hw/core/sysbus-memory.c --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg