From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQBYH-0004Zm-AM for qemu-devel@nongnu.org; Mon, 01 Feb 2016 05:17:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQBYC-0000u2-G1 for qemu-devel@nongnu.org; Mon, 01 Feb 2016 05:17:45 -0500 Date: Mon, 1 Feb 2016 11:17:36 +0100 From: Igor Mammedov Message-ID: <20160201111736.155e82fa@nial.brq.redhat.com> In-Reply-To: <56AB818B.1060500@redhat.com> References: <1454005340-15682-1-git-send-email-wei@redhat.com> <56AB78A6.7070505@redhat.com> <56AB7B48.9020007@linaro.org> <56AB818B.1060500@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Wei Huang Cc: "qemu-trivial@nongnu.org" , Peter Maydell , "zhaoshenglong@huawei.com" , Shannon Zhao , "qemu-devel@nongnu.org" On Fri, 29 Jan 2016 09:13:15 -0600 Wei Huang wrote: > On 01/29/2016 08:50 AM, Peter Maydell wrote: > > 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... > > This is another possibility. We can try to reset the pl061 state by > hooking up with dc->reset and see what happens. I think that's what we do on x86. > > > > > thanks > > -- PMM > > >