qemu/hw/gpio
Wei Huang b527db44ad ARM: PL061: Clear PL061 device state after reset
Current QEMU doesn't clear PL061 state after reset. This causes a
weird issue with guest reboot via GPIO. Here is the device state
with two reboot requests:

  (PL061State fields)           data   old_in_data   istate
VM boot                         0      0             0
After 1st ACPI reboot request   8      8             8
After VM PL061 driver ACK       8      8             0
After VM reboot                 8      8             0
------------------------------------------------------------
2nd ACPI reboot request         8

In the second reboot request above, because the old_in_data field is 8,
QEMU decides that there is a pending edge IRQ already (see
pl061_update()) in input; so it doesn't raise up IRQ again. As a result
the second reboot request is lost. The correct way is to clear PL061
device state after reset.

The default reset state is found from the documents listed below. Per
Peter's suggestion that QEMU automatically calls reset function after
device initialization, this patch removes calling pl061_reset() from
pl061_initfn().

Reference:
[1] PL061 Technical Reference Manual
[2] Stellaris LM3S8962 Microcontroller Data Sheet
[3] Stellaris LM3S5P31 Microcontroller Data Sheet

Signed-off-by: Wei Huang <wei@redhat.com>
Message-id: 1455729552-28026-2-git-send-email-wei@redhat.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-02-18 14:26:33 +00:00
..
imx_gpio.c arm: Clean up includes 2016-01-29 15:07:23 +00:00
Makefile.objs i.MX: Add GPIO device 2015-09-14 14:39:49 +01:00
max7310.c hw: Clean up includes 2016-01-29 15:07:25 +00:00
mpc8xxx.c hw: Clean up includes 2016-01-29 15:07:25 +00:00
omap_gpio.c arm devices: Clean up includes 2016-01-29 15:07:25 +00:00
pl061.c ARM: PL061: Clear PL061 device state after reset 2016-02-18 14:26:33 +00:00
puv3_gpio.c unicore: Clean up includes 2016-01-29 15:07:22 +00:00
zaurus.c arm devices: Clean up includes 2016-01-29 15:07:25 +00:00