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

[Kuo-Jung Su]

2013/2/18 Andreas Färber <address@hidden>:
> 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.
>

If I register my own customized reset function with qemu_register_reset()
before calling any sysbus_create_xxxx() or qdev_create(),
would it work properlly?

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



--
Best wishes,
Kuo-Jung Su