> > 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.
>
> So, I was confused by some remarks saying that this would give new
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
> > > mec
> > 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
On Mon, 2007-04-09 at 01:41 +0100, Paul Brook wrote:
> [replying to a couple of different mails]
>
> > What do you need to route an IRQ ?
> > -> A peripheral destination
>
> Agreed.
>
> > What we got now ?
> > -> a callback with 3 parameters: an opaque, a PIN (the n_IRQ) and a
> > state
>
> We
[replying to a couple of different mails]
> What do you need to route an IRQ ?
> -> A peripheral destination
Agreed.
> What we got now ?
> -> a callback with 3 parameters: an opaque, a PIN (the n_IRQ) and a
> state
We have this in some places. Other places only have some parts.
> Is more neede
