qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 04/20] arm: add Faraday FTDDRII030 support


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

Am 07.02.2013 18:26, schrieb Igor Mitsyanko:
> On 02/06/2013 01:45 PM, Kuo-Jung Su wrote:
>> +static void ftddrii030_reset(DeviceState *ds)
>> +{
>> +    SysBusDevice *busdev = SYS_BUS_DEVICE(ds);
>> +    Ftddrii030State *s = FTDDRII030(FROM_SYSBUS(Ftddrii030State, busdev));
>> +    FaradayMachState *mach = s->mach;
>> +
>> +    if (!mach) {
>> +        hw_error("ftddrii030: mach is not yet initialized!\n");
>> +        exit(1);
>> +    }
>> +
>> +    if (mach->ddr_inited) {
>> +        if (mach->ahb_remapped) {
> 
> This assumes that DDRII controller will be reseted before AHBC,
> otherwise we'll end up with
> ROM and RAM mapped at 0x0 address after reset. I do not know if we can
> count on a specific device reset ordering,
> maybe someone else can clarify this.

Reset handler registration happens as part of realized property setter.
For most devices that means as part of qdev_init_nofail(), so currently
the order is predictable for those. But this will change once we delay
setting realized = true to the end of machine initialization, since then
realized = true will propagate from "/machine" object to devices in
child<> property order and along busses, as drafted by Paolo.

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]