From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54913) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzq4X-00033T-OP for qemu-devel@nongnu.org; Thu, 27 Oct 2016 15:10:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzq4S-0001UQ-PI for qemu-devel@nongnu.org; Thu, 27 Oct 2016 15:10:41 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:47042) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bzq4S-00011i-Ic for qemu-devel@nongnu.org; Thu, 27 Oct 2016 15:10:36 -0400 Date: Thu, 27 Oct 2016 12:09:53 -0700 From: Guenter Roeck Message-ID: <20161027190953.GC9699@roeck-us.net> References: <1477361212-18833-1-git-send-email-linux@roeck-us.net> <20161025182107.GA31474@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] hw/arm/pxa2xx: Correctly handle external GPIO reset requests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers On Thu, Oct 27, 2016 at 03:34:29PM +0100, Peter Maydell wrote: > On 25 October 2016 at 19:21, Guenter Roeck wrote: > > Problem though is that the kernel doesn't really set GPIO01. > > It sets SPITZ_GPIO_ON_RESET (for spitz), which is 89. > > This is mapped to the reset function in spitz.c. > > /* Handle reset */ > > qdev_connect_gpio_out(cpu->gpio, SPITZ_GPIO_ON_RESET, cpu->reset); > > > > This doesn't seem correct; with that override, the reset is supposed > > to happen unconditionally, not only if bit 4 of PCFR is set (and that > > bit isn't set for spitz). > > Yes, that code looks dodgy (among other things it shouldn't > be reaching into the PXA2xxState's structure members directly > like that; par for the course on an unmaintained elderly bit > of QEMU code like this though). > > > How should I correctly handle that situation ? Allocate a second irq > > for non-GPIO01 reset requests ? > > What does the hardware actually do here? It seems unlikely that > the board really wires up the GPIO 89 pin back into the CPU/SoC to > ask the CPU to do a full reset, rather than just handling reset itself. Yes, I am quite sure that is what it does. > If it's handled at board level then the right thing would be > for the spitz.c code to have its own GPIO handler that does > a power-on-reset. > Makes sense. I'll fix spitz.c (and tosa.c, which does the same) along that line. Thanks, Guenter