Re: [Qemu-devel] [PATCH] hw/arm/pxa2xx: Correctly handle external GPIO reset requests

[Guenter Roeck]

On Thu, Oct 27, 2016 at 03:34:29PM +0100, Peter Maydell wrote:
> On 25 October 2016 at 19:21, Guenter Roeck <address@hidden> 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