From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPAOD-0007hd-Rs for qemu-devel@nongnu.org; Fri, 29 Jan 2016 09:51:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aPAOD-00018F-1L for qemu-devel@nongnu.org; Fri, 29 Jan 2016 09:51:09 -0500 Received: from mail-vk0-x229.google.com ([2607:f8b0:400c:c05::229]:34341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPAOC-000183-Tc for qemu-devel@nongnu.org; Fri, 29 Jan 2016 09:51:08 -0500 Received: by mail-vk0-x229.google.com with SMTP id e185so42968359vkb.1 for ; Fri, 29 Jan 2016 06:51:08 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <56AB7B48.9020007@linaro.org> References: <1454005340-15682-1-git-send-email-wei@redhat.com> <56AB78A6.7070505@redhat.com> <56AB7B48.9020007@linaro.org> From: Peter Maydell Date: Fri, 29 Jan 2016 14:50:49 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 1/1] arm: virt: change GPIO trigger interrupt to pulse List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Shannon Zhao Cc: Wei Huang , "qemu-trivial@nongnu.org" , "qemu-devel@nongnu.org" , "zhaoshenglong@huawei.com" On 29 January 2016 at 14:46, Shannon Zhao wrote: > On 2016/1/29 22:35, Wei Huang wrote: >> On 01/29/2016 04:10 AM, Shannon Zhao wrote: >>> This makes ACPI work well but makes DT not work. The reason is systemd or >>> acpid open /dev/input/event0 failed. So the interrupt could be injected >>> and >>> could see under /proc/interrupts but guest doesn't have any action. I'll >>> investigate why it opens failed later. >> >> >> That is interesting. Could you try it with the following? This reverses >> the order to down-up and worked on ACPI case. >> > Yeah, that's very weird. > >> qemu_set_irq(qdev_get_gpio_in(pl061_dev, 3), 0); >> qemu_set_irq(qdev_get_gpio_in(pl061_dev, 3), 1); >> > I'll try this tomorrow. But even if this works, it's still weird. I wonder if we should be asserting the GPIO pin in the powerdown-request hook and then deasserting it on system reset somewhere... thanks -- PMM