Re: [Qemu-devel] Re: IRQ handling

[J. Mayer]

On Mon, 2007-04-09 at 14:58 +0100, Paul Brook wrote:
[...]

> > > Having each device keep track of 3 values (callback, opaque and nIRQ; see
> > > earlier) is a real mess, evidenced by the fact that devices don't do this
> > > 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 details.
> 
> > 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 enhancements 
> over a {callpack, opaque, nIRQ} triplet. What it does do is isolate the 
> device (IRQ source) emulation from the implementation details.  As you agreed 
> above, there's no need for the device to know these details.

So, I was confused by some remarks saying that this would give new
features.

> It could be extended to do clever things like multiple sources, shared IRQ 
> lines and tristate pins, but I have not done this. For the current code it is 
> 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,  .... using GPIO, which is not efficient but quite a usual
> 
> We obviously have a different idea of what a "usefully large subset of GPIO 
> pin uses" entails. Most of the hardware I'm familiar with has dedicated I2C 
> hardware, and uses GPIO pins for interrupts and simple signals (eg. card 
> present).

I agree a lot of embedded micro-controllers implement hardware I2C but I
also know a lot that lacks support for some specialised busses, like
SPI, then force developpers to emulate those interfaces using GPIOs, or
share some IO pins for multiple functions.

> I agree that in some cases you may want to model eg. an I2C bus connected to 
> a 
> tristate GPIO pin. I don't have a good solution worked out for that. However 
> I am fairly confident that the current infrastructure could be used as a base 
> 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 
> messing about with pointless triplets of information. For PPC this conversion 
> is incomplete because I don't understand the details well enough to tell how 
> bogus the current code is. eg. the openpic emulation looks like it is capable 
> of raising several outputs, but only one is ever used.

Yes, the implementation is incomplete. I need to use more than one
outputs for embedded PowerPC emulation but the code is not finished.
I just started to rework all this code. If I want to follow your new
scheme, I have to add an emulation for the implementation dependant
hardware internal IRQ controller (fortunately, most usual PowerPC
implementations use the same scheme) and try to change the OpenPIC so it
can easily map its outputs pins to the input pins of the PowerPC, in a
machine dependant way.

-- 
J. Mayer <address@hidden>
Never organized