From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HauSN-0002uI-J5 for qemu-devel@nongnu.org; Mon, 09 Apr 2007 10:02:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HauSM-0002tv-2c for qemu-devel@nongnu.org; Mon, 09 Apr 2007 10:02:54 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HauSL-0002ts-T0 for qemu-devel@nongnu.org; Mon, 09 Apr 2007 10:02:53 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HauOV-0004JG-UV for qemu-devel@nongnu.org; Mon, 09 Apr 2007 09:58:56 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: IRQ handling Date: Mon, 9 Apr 2007 14:58:49 +0100 References: <200704090141.06630.paul@codesourcery.com> <1176117115.1516.277.camel@rapid> In-Reply-To: <1176117115.1516.277.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704091458.50964.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: "J. Mayer" > > In summary the IRQ source (ie. device raising the IRQ) needs to keep > > track of 4 values: > > 1) Callback > > 2) Opaque callback argument > > 3) PIN number > > 4) IRQ state. >... > > I believe (1) and (2) are inherently linked, and it makes no sense to > > set/change them individually. > > OK. > > > Having each device keep track of 3 values (callback, opaque and nIRQ; s= ee > > earlier) is a real mess, evidenced by the fact that devices don't do th= is > > consistently, the PCI code has grown its own slightly different > > mechanisms for signalling IRQs, and the ARM boards had their own > > partially generic implementation. Adding simple and consistent > > infrastructure for signalling interrupts is IMHO a worthwhile change in > > its own right. > > So, you wanted just to hide all the mess in an opaque ? Yes. As you agreed above, there's no need for the device to know the detail= s. > But I still cannot see what functionality this could add, how this could > make SMP feasible, for example (I do think there was no problem for this > before), ... In its current implementation it doesn't provide any functional enhancement= s=20 over a {callpack, opaque, nIRQ} triplet. What it does do is isolate the=20 device (IRQ source) emulation from the implementation details. As you agre= ed=20 above, there's no need for the device to know these details. It could be extended to do clever things like multiple sources, shared IRQ= =20 lines and tristate pins, but I have not done this. For the current code it = is=20 sufficient to model these cases as a virtual fixed-function IRQ controller. > > I have implemented sufficient infrastructure for a single-master > > single-slave bus. The most common example of which is a IRQ line. I > > believe it also covers a usefully large subset GPIO pin uses. > > I don't think so. For most hardware, you need to emulate the actual > hardware behavior if you want to emulate what happens on the GPIO pins. > And I maintain you need to read back the hardware state if you want to > know the logical level of an IO. Think about implementing IIC, > SPI, =A0.... using GPIO, which is not efficient but quite a usual We obviously have a different idea of what a "usefully large subset of GPIO= =20 pin uses" entails. Most of the hardware I'm familiar with has dedicated I2C= =20 hardware, and uses GPIO pins for interrupts and simple signals (eg. card=20 present). I agree that in some cases you may want to model eg. an I2C bus connected t= o a=20 tristate GPIO pin. I don't have a good solution worked out for that. Howeve= r=20 I am fairly confident that the current infrastructure could be used as a ba= se=20 for whatever we do come up with. > I have added a fake internal IRQ controller in > the PowerPC core just to use the same API (the SetIRQ callback / nIRQ / > level) as the rest of the code to easily plug other IRQ controllers to a > PowerPC core. >... > As suggested by Fabrice, > instead of adding mess in the Qemu core code, as I needed to add more > asynchronous exception sources, I decided to hide this using a bitmask > in the CPU structure, which seemed to be cleaner to me. Right, This is that same as what MIPS does, and probably ARM will soon. All I did was to change the "same API" to be abstract object instead of=20 messing about with pointless triplets of information. For PPC this conversi= on=20 is incomplete because I don't understand the details well enough to tell ho= w=20 bogus the current code is. eg. the openpic emulation looks like it is capab= le=20 of raising several outputs, but only one is ever used. Paul