From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzllk-0002BY-Hq for qemu-devel@nongnu.org; Thu, 27 Oct 2016 10:35:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzllb-00044l-3J for qemu-devel@nongnu.org; Thu, 27 Oct 2016 10:34:56 -0400 Received: from mail-vk0-x22b.google.com ([2607:f8b0:400c:c05::22b]:33469) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bzlla-00044f-VB for qemu-devel@nongnu.org; Thu, 27 Oct 2016 10:34:51 -0400 Received: by mail-vk0-x22b.google.com with SMTP id d65so1690334vkg.0 for ; Thu, 27 Oct 2016 07:34:50 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20161025182107.GA31474@roeck-us.net> References: <1477361212-18833-1-git-send-email-linux@roeck-us.net> <20161025182107.GA31474@roeck-us.net> From: Peter Maydell Date: Thu, 27 Oct 2016 15:34:29 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Guenter Roeck Cc: QEMU Developers 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. 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. thanks -- PMM