From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:59155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1SVC-0001Le-Fx for qemu-devel@nongnu.org; Wed, 06 Mar 2019 04:06:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h1SVB-0007Fn-93 for qemu-devel@nongnu.org; Wed, 06 Mar 2019 04:06:14 -0500 Received: from greensocs.com ([193.104.36.180]:44009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1SVA-000708-2p for qemu-devel@nongnu.org; Wed, 06 Mar 2019 04:06:13 -0500 From: Damien Hedde References: <63b980a2-6b28-d5e2-891c-6245ddb1e851@redhat.com> <20190304102912.GC6010@toto> Message-ID: <4c1c9c2c-73e9-bacf-b4c4-3fa425480e3f@greensocs.com> Date: Wed, 6 Mar 2019 10:05:50 +0100 MIME-Version: 1.0 In-Reply-To: <20190304102912.GC6010@toto> Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] multi phase reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Edgar E. Iglesias" , Peter Maydell Cc: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , Mark Burton , QEMU Developers Hi Edgar, On 3/4/19 11:29 AM, Edgar E. Iglesias wrote: > Hi Damien and others, > > A few questions from my side. > > We sometimes see that wires from generic GPIO blocks get connected to reset inputs. > This happens both to off-chip perihperals but we also see it on-chip. > > To avoid having GPIO modules know that some of their outputs are being used as > reset signals it would be nice to have a reset proxy that allows any qemu_irq to > drive resets for a given device. Perhaps even with built-in options for both interpreting > "active-low" and "active-high". I think it would even be useful to have this > in qdev but that may be pushing it too far. Any thoughts on that? Do you mean for Device or other objects as well ? I planned to add a function so that a Device could declare one of its gpio/irq input as reset. It is straightforward since we just need to set the proper handler to the irq. The device controlling the irq (output) would have no knowledge of that. > > Have you thought about what happens if someone does an MMIO access to a device while > its reset is active? Were you planning to have some "default" SysBus level handling to > block MMIO while in reset or anything like that? Or would that be handled individually > by each device model?Right know it would be handled individually by each model. With In my first power/clock gating implementation (last year), I tried to do a kind of default deactivation of mmio memory region in SysbusDevice object and it appears to me it is complicated for 2 reasons: + A device has to handle its memory region flag/properties during migration (if we automatically disable things, should we automatically migrate this ?) + Some memory regions may already be disabled, so we cannot simply disabled the mmio array and re-enabled it later. Right know for the cadence_uart, I check this in the Device itself. I'm no expert of memory regions, so there is maybe a simple solution I don't see. > > Another question is regarding reset of CPUs. It would be nice to be able to expose > similar interfaces and have some defined behaviour for CPUs that are in reset. E.g, > if reset is active the CPU does not execute etc. > > Cheers, > Edgar >