[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH arm-midr v2 1/2] ARM: Convert MIDR to a property
From: |
Peter Crosthwaite |
Subject: |
Re: [Qemu-devel] [PATCH arm-midr v2 1/2] ARM: Convert MIDR to a property |
Date: |
Sun, 19 Jan 2014 11:46:55 +1000 |
On Sun, Jan 19, 2014 at 11:12 AM, Peter Maydell
<address@hidden> wrote:
> On 19 January 2014 00:59, Peter Crosthwaite
> <address@hidden> wrote:
>> Do you even need this now? The normal arrayified dc->props properties
>> are added at device::init time. As TYPE_DEVICE is a parent class, its
>> init function is called before CPUs (normal inits are called in
>> parent->child order, the post_inits are reverse). This means the
>> cpu::init fns should correctly set the device-specific default after
>> device::init, trampling the bogus default defined in the property
>> array.
>>
>> All of this however assumes that MIDR is unconditionally existent for
>> all ARMCPU. Peter, are you able to confirm that thats ok before we
>> commit to this implementation over the conditional post_init approach?
>
> IIRC ARMv4 and earlier didn't define the MIDR, but we don't
> actually emulate any of those. In general, my intent with all these
> constant fields in the ARMCPU struct was that we'd end up making
> them just properties available on all ARMCPU objects, and if the
> particular subtype of ARMCPU happened not to have FP and so
> didn't need the reset_fpsid, for example, it would just ignore whatever
> value you set the property to. I don't think we need to tie ourselves
> in knots to restrict the properties to particular CPUs if it is too
> implementationally awkward (though it would be nice if we can
> tie them to ARM_FEATURE_* bits for more or less free).
>
ARM_FEATURE_V5 exists. Will that do the job? That will exclude just
the V4T AFAICT. Worth bothering?
Regards,
Peter
> thanks
> -- PMM
>
[Qemu-devel] [PATCH arm-midr v2 2/2] ZYNQ: Implement board MIDR control for Zynq, Alistair Francis, 2014/01/13