qemu-devel
[Top][All Lists]
Advanced

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

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


From: Shannon Zhao
Subject: Re: [Qemu-devel] [PATCH 1/1] arm: virt: change GPIO trigger interrupt to pulse
Date: Thu, 4 Feb 2016 14:51:15 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0


On 2016/2/4 14:10, Wei Huang wrote:
> 
> 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 <address@hidden> 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).
> 
Because to make the input work, it should call input_event twice I think.

input_event(input, type, button->code, 1) means the button pressed
input_event(input, type, button->code, 0) means the button released

But We only see guest entering gpio_keys_gpio_report_event once.

My original purpose is like below:

call qemu_set_irq(qdev_get_gpio_in(pl061_dev, 3), 1) to make guest
execute input_event(input, type, button->code, 1)
call qemu_set_irq(qdev_get_gpio_in(pl061_dev, 3), 0) to make guest
execute input_event(input, type, button->code, 0).

But even though it calls qemu_set_irq twice, it only calls pl061_update
once in qemu.

-- 
Shannon




reply via email to

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