qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 01/20] arm: add Faraday a360 SoC platform sup


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH v3 01/20] arm: add Faraday a360 SoC platform support
Date: Sun, 17 Feb 2013 19:01:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2

Am 06.02.2013 10:45, schrieb Kuo-Jung Su:
> +typedef struct FaradayMachState {
> +    ARMCPU       *cpu;
> +    DeviceState  *scu;
> +    DeviceState  *ahbc;
> +    DeviceState  *ddrc;
> +    DeviceState  *hdma[2];  /* AHB DMA */
> +    DeviceState  *pdma[2];  /* APB DMA */
> +    i2c_bus      *i2c[2];
> +
> +    MemoryRegion *as;
> +    MemoryRegion *ram;
> +    MemoryRegion *ram_alias;
> +    pflash_t     *rom;
> +    MemoryRegion *sram;
> +
> +    uint32_t ahb_slave4;    /* AHB slave 4 default value */
> +    uint32_t ahb_slave6;    /* AHB slave 6 default value */
> +    uint32_t ahb_remapped:1;
> +    uint32_t ddr_inited:1;
> +} FaradayMachState;

I think you need to distinguish what's on the SoC and what's on the
evaluation board there...

For the SoC you can have a QOM type with DeviceState parent, but the
stuff on the board should stay separate. Instead of pointers you should
use the actual types (i.e., add field when you introduce the device
model). This will work out-of-the box for your own devices and will work
for ARMCPU once my pull is applied. The purpose would be container-like
grouping of devices and sharing across boards.
However, as Peter pointed out, devices should avoid fiddling with each
other's internals even if they have access to a pointer/field.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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