qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] [PATCH v3 4/7] bcm2835_peripherals: add roll


From: Andrew Baumann
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH v3 4/7] bcm2835_peripherals: add rollup device for bcm2835 peripherals
Date: Wed, 6 Jan 2016 06:07:01 +0000

> From: Alistair Francis [mailto:address@hidden
> Sent: Tuesday, 5 January 2016 18:14
> On Thu, Dec 31, 2015 at 4:31 PM, Andrew Baumann
> <address@hidden> wrote:
> > This device maintains all the non-CPU peripherals on bcm2835 (Pi1)
> > which are also present on bcm2836 (Pi2). It also implements the
> > private address spaces used for DMA and mailboxes.
[...]
> > +    obj = object_property_get_link(OBJECT(dev), "ram", &err);
> > +    if (obj == NULL) {
> > +        error_setg(errp, "%s: required ram link not found: %s",
> > +                   __func__, error_get_pretty(err));
> > +        return;
> > +    }
> 
> I only had a quick read of this patch, but this RAM linking looks fine
> to me. Out of curiosity is there a reason you use
> object_property_get_link() instead of object_property_add_link() in
> the init?

I'm not sure I understand your question... it wouldn't work the other way. I 
allocate the ram and add the link using object_property_add_const_link() in 
hw/arm/raspi.c. This file needs to consume the ram to setup alias mappings, so 
it is using get_link(). (Note there's also level of indirection; raspi creates 
bcm2836, which does nothing but get the link set by its parent and add it to 
its bcm2835_peripherals child.)

I suppose I could do it the other way around (allocate and set link in 
bcm2835_peripherals, based on a size passed from the board), but it seemed more 
logical to treat the RAM as created/owned of the board rather than the SoC.

Cheers,
Andrew

reply via email to

[Prev in Thread] Current Thread [Next in Thread]