[Qemu-devel] Re: Extending qemu_irq for reset signals

[Blue Swirl]

On 8/15/07, Paul Brook <address@hidden> wrote:
> On Wednesday 15 August 2007, Blue Swirl wrote:
> > Hi,
> >
> > I'd like to use similar mechanism as qemu_irq as reset signal for
> > devices. The difference is that the opaque data and callback are not
> > specified at the time of creating the signal at upstream device, but
> > when the receiving device is created. This does not fit current
> > qemu_irq model.
>
> Either your confused, or not expressing what you want very well. What you
> describe is how qemu_irq works.
>
> The "upstream device" and "receiving device" are the same thing.

Okay, more explaining. This is the case where I'd want to use the
signal: DMA controller ("upstream") can reset the slave device (ESP or
Lance). DMA controller is created first and I also want to allocate
reset signals at that point. Later when ESP is created, it should be
possible to put ESP reset function and opaque data to the signal given
but this is not possible with current API. Currently the DMA data
would be passed to qemu_allocate_irqs.

> The whole point of qemu_irq is to be able to send a single-bit signal without
> having to know or care where it's going. ie. when creating the board/cpu, you
> create the qemu_irq object with appropriate parameters. Then the device
> initiating the reset uses that qemu_irq object.
>
> If the device initiating the reset needs to pass additional information, then
> you're no longer dealing with a single bit of state, so I don't think
> qemu_irq is really appropriate.

Agreed. No data needs to be passed in my case and the qemu_irq model
works except for the API.