From: Anthony Liguori <anthony@codemonkey.ws>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Avi Kivity <avi@redhat.com>, QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] modelling omap_gpmc with the hierarchical memory API
Date: Tue, 02 Aug 2011 15:56:31 -0500 [thread overview]
Message-ID: <4E38647F.3010509@codemonkey.ws> (raw)
In-Reply-To: <CAFEAcA-j3HvYtBUx5inFx=oe9zVFSOFX+9TuEgO8bF5VBJ_gSg@mail.gmail.com>
On 08/02/2011 01:21 PM, Peter Maydell wrote:
> On 2 August 2011 19:05, Avi Kivity<avi@redhat.com> wrote:
>> On 08/02/2011 08:21 PM, Peter Maydell wrote:
>>> So I think we just need a sysbus_mmio_get_memoryregion()
>>> (and convert the devices I need to attach to use memory
>>> regions, and live with not being able to attach unconverted
>>> devices).
>>
>> I don't follow - why do we need get_memoryregion? who would call it?
>
> The machine model would call it. So you do something like
> DeviceState *dev = qdev_create(NULL, "whatever");
> /* Note the parallel here to the existing
> * sysbus_mmio_map(sysbus_from_qdev(dev), mmio_idx, addr);
> */
> MemoryRegion *mr =
> sysbus_mmio_get_memoryregion(sysbus_from_qdev(dev), mmio_idx);
> omap_gpmc_attach(gpmc, 7, mr);
>
> ie the machine model is where we wire up the subdevices
> to the gpmc, and at the machine model level what you have is
> a pointer to an entire device, so you need to be able to
> convert the (sysbus*, mmio_index) tuple to a MemoryRegion*.
Hrm, this looks like badness to me.
You're effectively using MemoryRegions to implement an ad-hoc interface.
This is not what MemoryRegions are meant to do though. You want
something like:
class WhateverDevice : public Device, implements SimpleDevice
{
MemoryRegion *get_memory_region(void);
};
class OmapGmc : public Device
{
SimpleDevice *slots[8];
};
In qdev of today, you should implement something other than SysBus as a
base class and make OmapGmc a bus.
>
>>> [That is, the only reason I'm passing SysBus objects around
>>> is that at the moment that is the only useful abstraction we
>>> have for saying "I'm an arbitrary device object and I provide
>>> some GPIO pins and some memory mappable regions". MemoryRegion*
>>> allows me to pass around a memory mappable region in a more
>>> direct way than having to pass a (SysBus*, mmio_index) tuple.]
>>
>> I think I see. Perhaps you're describing qdev/MemoryRegion integration.
>
> I think qdev devices need to be able to expose MemoryRegions
> as first class named 'properties' or 'plugs' or 'sockets' or
> whatever we want to call them, yes. (Ditto gpio/irq, which at
> the moment we can kind of expose but not by name.)
I disagree in this case. I think MemoryRegion is a bit too low level of
a connecting point. I think an interface would be a stronger interface
to use.
What's the relationship between the omap_gpmc and the devices in real
hardware? Are the devices designed to connect to the GPMC explicitly
via a common set of pins? Is there an intermediate bridge chip or
something?
Regards,
Anthony Liguori
>
> -- PMM
>
next prev parent reply other threads:[~2011-08-02 20:56 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-02 15:47 [Qemu-devel] modelling omap_gpmc with the hierarchical memory API Peter Maydell
2011-08-02 15:58 ` Avi Kivity
2011-08-02 17:21 ` Peter Maydell
2011-08-02 18:05 ` Avi Kivity
2011-08-02 18:21 ` Peter Maydell
2011-08-02 19:11 ` Avi Kivity
2011-08-02 19:38 ` Peter Maydell
2011-08-02 21:00 ` Anthony Liguori
2011-08-02 21:25 ` Avi Kivity
2011-08-02 20:56 ` Anthony Liguori [this message]
2011-08-02 21:28 ` Peter Maydell
2011-08-02 21:48 ` Avi Kivity
2011-08-02 22:04 ` Peter Maydell
2011-08-03 2:26 ` Anthony Liguori
2011-08-03 6:50 ` Avi Kivity
2011-08-03 2:25 ` Anthony Liguori
2011-08-03 9:10 ` Peter Maydell
2011-08-03 9:23 ` Avi Kivity
2011-08-02 18:07 ` Jan Kiszka
2011-08-02 19:15 ` Avi Kivity
2011-08-02 21:06 ` Anthony Liguori
2011-08-02 21:29 ` Avi Kivity
2011-08-03 2:33 ` Anthony Liguori
2011-08-03 6:56 ` Avi Kivity
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=4E38647F.3010509@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=peter.maydell@linaro.org \
--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.