qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] hw/arm/pxa2xx: Correctly handle external GPIO reset requests
Date: Thu, 27 Oct 2016 15:34:29 +0100

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.
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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]