From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40926) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9U5B-0002eS-QE for qemu-devel@nongnu.org; Wed, 23 Nov 2016 04:43:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9U58-0006qa-IW for qemu-devel@nongnu.org; Wed, 23 Nov 2016 04:43:13 -0500 Date: Wed, 23 Nov 2016 04:43:01 -0500 (EST) From: Paolo Bonzini Message-ID: <1761115996.1384447.1479894181425.JavaMail.zimbra@redhat.com> In-Reply-To: <1479856790.11116.111.camel@au1.ibm.com> References: <1479357400-17441-1-git-send-email-alastair@au1.ibm.com> <1479357400-17441-3-git-send-email-alastair@au1.ibm.com> <3888651b-fd60-e827-a9f8-575a8f01be72@redhat.com> <1479853887.11116.95.camel@au1.ibm.com> <6d4e34f8-4b0b-85f2-93d6-6f0b3e2e7fb3@redhat.com> <1479856790.11116.111.camel@au1.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/4] qtest: Support named interrupts List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alastair D'Silva Cc: =?utf-8?Q?C=C3=A9dric?= Le Goater , qemu-arm@nongnu.org, qemu-devel@nongnu.org, Peter Maydell , Andrew Jeffery , Joel Stanley ----- Original Message ----- > From: "Alastair D'Silva" > To: "Paolo Bonzini" , "C=C3=A9dric Le Goater" , qemu-arm@nongnu.org > Cc: qemu-devel@nongnu.org, "Peter Maydell" , "A= ndrew Jeffery" , "Joel > Stanley" > Sent: Wednesday, November 23, 2016 12:19:50 AM > Subject: Re: [PATCH 2/4] qtest: Support named interrupts >=20 > On Tue, 2016-11-22 at 23:39 +0100, Paolo Bonzini wrote: > > On 22/11/2016 23:31, Alastair D'Silva wrote: > > > >=20 > > > > This seems wrong.=C2=A0=C2=A0The IRQ should not be modifiable by th= e > > > > test. > > >=20 > > > Thanks Paolo, could you please advise as to why that is? >=20 > Could you answer this please? I would like to understand why. Well, I didn't know yet until I knew what the GPIO line was for. :) But in general, the idea is that the qtest acts as the CPU. The test cases can control the passing of time precisely, and they can _observe_ additional events (such as interrupts or GPIO lines) but they don't inject anything that the CPU cannot inject. The reason is to make the tests more like small programs. It does mean that you are limited by the connections of the board. > > > The situation I am addressing is that I device under test that > > > changes > > > behaviour when a GPIO line is raised. Is there another way I should > > > be > > > raising that line from within qtest? > >=20 > > What causes the GPIO line to be raised in the normal emulated case? > > It would be wired to a GPIO line from the host microcontroller, under > software control. Note I said the normal emulated case, not the real hardware case. Is there a GPIO controller that is not yet part of the ASpeed models? If the emulated ASpeed board cannot yet work with FOut, I would just leave it out of the testcases. Paolo > In this test case, the device is connected to a "borrowed" board via > the command line: > =C2=A0 =C2=A0 snprintf(args, sizeof(args), "-display none -machine imx25-= pdk " > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"= -device rx8900,bus=3Di2c.0,address=3D0x%x,id=3D%s", > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0R= X8900_ADDR, RX8900_TEST_ID); >=20 > I couldn't see a way to wire in the the GPIO to the host via the > command line, but even if there was, manipulating it would require > manipulating the host CPU, which would broaden the scope of the test. > At the moment, the test has no dependency on/interaction with the host > CPU, it's just using it to provide an I2C bus.