From: Paul Brook <paul@codesourcery.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: Extending qemu_irq for reset signals
Date: Wed, 15 Aug 2007 18:42:16 +0100 [thread overview]
Message-ID: <200708151842.17437.paul@codesourcery.com> (raw)
In-Reply-To: <f43fc5580708151035i416c6e2h1acc7ed15dbc62d4@mail.gmail.com>
On Wednesday 15 August 2007, Blue Swirl wrote:
> On 8/15/07, Paul Brook <paul@codesourcery.com> wrote:
> > On Wednesday 15 August 2007, Paul Brook wrote:
> > > > 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.
> > >
> > > Ah, I see. The problem here is that you've got a cyclic dependency. For
> > > DMA operations the ESP is in charge, so it makes sense to create the
> > > subservient DMA device first. For the reset signals the DMA controller
> > > is in charge so ideally you create the ESP device first. Because the
> > > DMA interface is most complicated, it's probably takes precedence.
> > >
> > > I think you need to modify or use sparc32_dma_set_reset_data to take a
> > > qemu_irq rather than a callback and opaque argument. Alternatively you
> > > can move things around a bit and have the sun4m code do something
> > > similar. i.e. the ESP and lance devices return the reset lines, then
> > > the sun4m code pokes into the DMA device state.
> >
> > Oh, or you can pass a pointer to a qemu_irq from the DMA to the ESP and
> > have the ESP poke its reset object in there that way.
>
> That's what I had in mind. Should I just extend the API for example with
> /* Change the callback function and/or data */
> void qemu_irq_change(qemu_irq irq, qemu_irq_handler handler,
> void *opaque);
I'm not so keen on that. It breaks the nice property of having the IRQ lines
owned by the receiver. I was thinking something like:
struct DMAState {
qemu_irq device_reset;
};
qemu_irq *dma_init()
{
struct DMAState * d = malloc();
return &d->device_reset;
}
void esp_init(qemu_irq *resetp)
{
ESPState *d = malloc();
*reset = *qemu_irq_alloc(d, 1);
}
void sun4m_init()
{
qemu_irq *p = dma_init();
esp_init(p);
}
Paul
next prev parent reply other threads:[~2007-08-15 17:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-15 16:13 [Qemu-devel] Extending qemu_irq for reset signals Blue Swirl
2007-08-15 16:34 ` [Qemu-devel] " Paul Brook
2007-08-15 16:53 ` Blue Swirl
2007-08-15 17:21 ` Paul Brook
2007-08-15 17:22 ` Paul Brook
2007-08-15 17:35 ` Blue Swirl
2007-08-15 17:42 ` Paul Brook [this message]
2007-08-15 17:52 ` Blue Swirl
2007-08-15 19:33 ` Blue Swirl
2007-08-15 19:44 ` Paul Brook
2007-08-15 17:47 ` Blue Swirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200708151842.17437.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.