Re: [Qemu-trivial] [PATCH 1/1] arm: virt: change GPIO trigger interrupt to pulse

[Wei Huang <wei@redhat.com>]

On 02/03/2016 07:44 PM, Shannon Zhao wrote:
> 
> 
> On 2016/2/4 0:01, Wei Huang wrote:
>>
>> On 2/3/16 04:46, Peter Maydell wrote:
>>>> On 3 February 2016 at 07:15, Michael Tokarev <mjt@tls.msk.ru> wrote:
>>>>>> 28.01.2016 21:22, Wei Huang wrote:
>>>>>>>> When QEMU is hook'ed up with libvirt/virsh, the first ACPI reboot
>>>>>>>> request will succeed; but the following shutdown/reboot requests
>>>>>>>> fail to trigger VMs to react. Notice that in mach-virt machine
>>>>>>>> model GPIO is defined as edge-triggered and active-high in ACPI.
>>>>>>>> This patch changes the behavior of powerdown notifier from PULLUP
>>>>>>>> to PULSE. It solves the problem described above (i.e. reboot
>>>>>>>> continues to work).
>>>>>>
>>>>>> So, what's the outcome of this? :)
>>>>
>>>> This patch is definitely wrong. The patch to fix up the
>>>> gpio reset stuff is definitely the right idea. Whether it
>>>> fixes the reported failure or some further change is also
>>>> needed is currently unclear.
>> I will NAK this one for now. Please see V2 patch, which is necessary. In
>> the meanwhile, I think there is a problem with pulling-up only in
>> current implementation. Let me debug Shannon's DT problem first.
>>
> Hi Wei,
> 
> The reason of DT problem is that when we use qemu_irq_pulse(i.e
> qemu_set_irq(qdev_get_gpio_in(pl061_dev, 3), 1);
> qemu_set_irq(qdev_get_gpio_in(pl061_dev, 3), 0);), it will inject the
> GPIO interrupt until it executes
> qemu_set_irq(qdev_get_gpio_in(pl061_dev, 3), 0) because the qemu main
> thread is serialized and then guest will get the button value as zero,
> so it's failed to report the input event.
> 
> See gpio_keys_gpio_report_event
>  in drivers/input/keyboard/gpio_keys.c
> int state = gpio_get_value_cansleep(button->gpio);
> 
> The state is always zero.

I reversed the order of edge pulling. The state is 1 according to printk
inside gpio_keys driver. However the reboot still failed with two
reboots (1 very early, 1 later).

> 
> The solution I think would be making the each
> qemu_set_irq(qdev_get_gpio_in(pl061_dev, 3), 1 or 0) cloud inject an
> interrupt to guest.
> 
> Thanks,
>