qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Bhushan Bharat-R65777 <R65777@freescale.com>
Cc: "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"agraf@suse.de" <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH 2/2] Adding BAR0 for e500 PCI controller
Date: Thu, 04 Oct 2012 16:58:02 +0200	[thread overview]
Message-ID: <506DA3FA.2080404@redhat.com> (raw)
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D064B2BBD@039-SN2MPN1-022.039d.mgd.msft.net>

On 10/04/2012 03:46 PM, Bhushan Bharat-R65777 wrote:
> 
> 
>> -----Original Message-----
>> From: Avi Kivity [mailto:avi@redhat.com]
>> Sent: Thursday, October 04, 2012 6:02 PM
>> To: Bhushan Bharat-R65777
>> Cc: qemu-devel@nongnu.org; qemu-ppc@nongnu.org; agraf@suse.de; Bhushan Bharat-
>> R65777
>> Subject: Re: [Qemu-devel] [PATCH 2/2] Adding BAR0 for e500 PCI controller
>> 
>> On 10/03/2012 01:50 PM, Bharat Bhushan wrote:
>> >      sysbus_connect_irq(s, 0, mpic[pci_irq_nrs[0]]); diff --git
>> > a/hw/ppce500_pci.c b/hw/ppce500_pci.c index 92b1dc0..16e4af2 100644
>> > --- a/hw/ppce500_pci.c
>> > +++ b/hw/ppce500_pci.c
>> > @@ -87,6 +87,7 @@ struct PPCE500PCIState {
>> >      /* mmio maps */
>> >      MemoryRegion container;
>> >      MemoryRegion iomem;
>> > +    void *bar0;
>> >  };
>> 
>> void *?  Why?
> 
> Passing parameter via qdev is either possible by value or by void *. That's why I used void *.

Then you shouldn't be using qdev for this.  But if you make the changes
below, it will likely not be necessary.

>> 
>> However this is best done from the pci device's initialization function, not
>> here (the MemoryRegion should be a member of the pci device as well).
> 
> We want to set BAR0 of PCI controller so we did this here. But yes, we also want that all devices under the PCI controller have this mapping, so when they access the MPIC register to send MSI then they can do that.

Please elaborate.  One way to describe what you want is to issue an
'info mtree' and show what changes you want.

> 
> Which device's initialization function you are talking about?

static const TypeInfo e500_host_bridge_info = {
    .name          = "e500-host-bridge",
    .parent        = TYPE_PCI_DEVICE,
    .instance_size = sizeof(PCIDevice),
    .class_init    = e500_host_bridge_class_init,
};

This needs to describe a derived class of PCIDevice, hold the BAR as a
data member, and register the BAR in the init function (which doesn't
exist yet because you haven't subclassed it).  This way the BAR lives in
the device which exposes it, like BARs everywhere.

-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2012-10-04 14:58 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-03 11:49 [Qemu-devel] [PATCH 0/2] e500: creating CCSR region and registering bar0 Bharat Bhushan
2012-10-03 11:49 ` [Qemu-devel] [PATCH 1/2] e500: Adding CCSR memory region Bharat Bhushan
2012-10-03 12:08   ` Alexander Graf
2012-10-03 12:16     ` Bhushan Bharat-R65777
2012-10-03 12:18       ` Alexander Graf
2012-10-03 11:50 ` [Qemu-devel] [PATCH 2/2] Adding BAR0 for e500 PCI controller Bharat Bhushan
2012-10-03 12:11   ` Alexander Graf
2012-10-03 12:23     ` Bhushan Bharat-R65777
2012-10-04 12:31   ` Avi Kivity
2012-10-04 13:46     ` Bhushan Bharat-R65777
2012-10-04 14:58       ` Avi Kivity [this message]
2012-10-04 16:03         ` Bhushan Bharat-R65777
2012-10-04 16:07           ` Alexander Graf
2012-10-04 16:48             ` Bhushan Bharat-R65777
2012-10-04 16:50               ` Alexander Graf
2012-10-04 17:02                 ` Avi Kivity
2012-10-05  7:11             ` Bhushan Bharat-R65777
2012-10-05 11:59               ` Alexander Graf
2012-10-07  9:48                 ` Avi Kivity
2012-10-07 11:57                   ` Alexander Graf
2012-10-07 12:41                     ` Avi Kivity
2012-10-08  8:23                 ` Bhushan Bharat-R65777
2012-10-08  8:50                   ` Alexander Graf
2012-10-08 13:57                     ` Andreas Färber
2012-10-04 15:54   ` Andreas Färber
2012-10-04 16:01     ` Alexander Graf

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=506DA3FA.2080404@redhat.com \
    --to=avi@redhat.com \
    --cc=R65777@freescale.com \
    --cc=agraf@suse.de \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).