From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1j5w-0000pc-L3 for qemu-devel@nongnu.org; Fri, 10 Jan 2014 15:54:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1j5o-00071E-5K for qemu-devel@nongnu.org; Fri, 10 Jan 2014 15:54:20 -0500 Received: from cantor2.suse.de ([195.135.220.15]:37885 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1j5n-00070e-Vj for qemu-devel@nongnu.org; Fri, 10 Jan 2014 15:54:12 -0500 Message-ID: <52D05DEF.1080208@suse.de> Date: Fri, 10 Jan 2014 21:54:07 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH target-arm v4 2/3] zynq_slcr: Add links to the CPUs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , QEMU Developers , Anthony Liguori Am 10.01.2014 21:20, schrieb Peter Crosthwaite: > On Sat, Jan 11, 2014 at 4:11 AM, Peter Maydell wrote: >> On 2 January 2014 07:31, Peter Crosthwaite wrote: >>> The SLCR needs to be able to reset the CPUs, so link the CPUs to the >>> SLCR. >> >>> @@ -496,10 +500,17 @@ static const MemoryRegionOps slcr_ops =3D { >>> static int zynq_slcr_init(SysBusDevice *dev) >>> { >>> ZynqSLCRState *s =3D ZYNQ_SLCR(dev); >>> + int i; >>> >>> memory_region_init_io(&s->iomem, OBJECT(s), &slcr_ops, s, "slcr"= , 0x1000); >>> sysbus_init_mmio(dev, &s->iomem); >>> >>> + for (i =3D 0; i < NUM_CPUS; ++i) { >>> + gchar *name =3D g_strdup_printf("cpu%d", i); >>> + object_property_add_link(OBJECT(dev), name, TYPE_CPU, >>> + (Object **)&s->cpus[i], NULL); >>> + g_free(name); >>> + } >> >> This is where we get into the nasty questions of how >> we ought to be modelling reset. I don't think that >> reset controllers ought to work by having direct links >> to a pile of QOM device objects. I'd much rather we tried >> to work towards modelling this the way the hardware does, >> ie a QOM device has one or more inbound GPIO lines >> corresponding to the hardware's reset signals, and the >> SoC or board wires those up to the reset controller >> appropriately. >> >=20 > So all nice solutions to this really want named GPIOs which is > something of a long term sore-point. Are you happy to take a simple > addition of a reset GPIO to ARMCPU (which itself just calls > cpu_reset) without the need for the big planned GPIO fixups (whether > than be pins of Andreas' QOMification)? Pins are Anthony's topic, not mine. :) I rather recently suggested to do a transparent QOM'ification. I thus have no objections against adding a reset IRQ! That had BTW been discussed as possible solution for partial/soft resets in PReP and x86 context. Andreas --=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