[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: |
Andrew Baumann |
Subject: |
Re: [Qemu-devel] [PATCH v4 4/8] bcm2835_peripherals: add rollup device for bcm2835 peripherals |
Date: |
Tue, 26 Jan 2016 06:23:39 +0000 |
> 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?
> > + 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.
Thanks,
Andrew
[Qemu-devel] [PATCH v4 6/8] bcm2836: add bcm2836 soc device, Andrew Baumann, 2016/01/15
[Qemu-devel] [PATCH v4 5/8] bcm2836_control: add bcm2836 ARM control logic, Andrew Baumann, 2016/01/15
[Qemu-devel] [PATCH v4 7/8] arm/boot: move highbank secure board setup code to common routine, Andrew Baumann, 2016/01/15