> > 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; 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.
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 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.
Paul
