On 8/15/07, Paul Brook <[EMAIL PROTECTED]> 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.