qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 4/8] bcm2835_peripherals: add rollup device f


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH v4 4/8] bcm2835_peripherals: add rollup device for bcm2835 peripherals
Date: Tue, 26 Jan 2016 00:03:08 -0800

On Mon, Jan 25, 2016 at 10:23 PM, Andrew Baumann
<address@hidden> wrote:
>> From: Peter Crosthwaite [mailto:address@hidden
>> Sent: Monday, 25 January 2016 22:14
>>
>> On Fri, Jan 15, 2016 at 3:58 PM, Andrew Baumann
>> <address@hidden> wrote:
> [...]
>> > +static void bcm2835_peripherals_init(Object *obj)
>> > +{
>> > +    BCM2835PeripheralState *s = BCM2835_PERIPHERALS(obj);
>> > +
>> > +    /* Memory region for peripheral devices, which we export to our
>> parent */
>> > +    memory_region_init_io(&s->peri_mr, obj, NULL, s, "bcm2835-
>> peripherals",
>> > +                          0x1000000);
>>
>> Should this just be normal memory_region_init?
>
> I think so -- it's just a container region, and I probably copy and pasted 
> the API here. The two MR init APIs seem almost but not-quite identical when 
> NULL callbacks are used. Can you briefly explain the difference?
>

hmm I guess the defaulting to &unassigned_mem_ops. memory_region_init
looks to assume you will populate the usable subregions. Are you
relying on unassigned ops?

>> > +    object_property_add_child(obj, "peripheral-io", OBJECT(&s->peri_mr),
>> NULL);
>>
>> This seems like a weird parenting, to have the SoC as child to an
>> object it just created. Is the problem you need a parent before others
>> can parent to you?
>
> I'm confused by this question: Unless I'm mistaken, the parent here is 
> BCM2835PeripheralState, the child is the new memory region we just called 
> init on.
>

My bad - I have it backwards.

Regards,
Peter

> Thanks,
> Andrew



reply via email to

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