Am 27.11.2013 10:14, schrieb Peter Maydell:
> On 27 November 2013 09:01, Peter Crosthwaite
> <peter.crosthwa...@xilinx.com> wrote:
>> The reset Value of the CP15 CBAR is a vendor (machine) configurable
>> property. Define arm_cpu_properties and add it.
>>
>> Signed-off-by: Peter Crosthwaite <peter.crosthwa...@xilinx.com>
>> ---
>>
>> target-arm/cpu.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/target-arm/cpu.c b/target-arm/cpu.c
>> index a82fa61..f1c5f6b 100644
>> --- a/target-arm/cpu.c
>> +++ b/target-arm/cpu.c
>> @@ -20,6 +20,7 @@
>>
>> #include "cpu.h"
>> #include "qemu-common.h"
>> +#include "hw/qdev-properties.h"
>> #if !defined(CONFIG_USER_ONLY)
>> #include "hw/loader.h"
>> #endif
>> @@ -847,6 +848,11 @@ typedef struct ARMCPUInfo {
>> void (*class_init)(ObjectClass *oc, void *data);
>> } ARMCPUInfo;
>>
>> +static Property arm_cpu_properties[] = {
>> + DEFINE_PROP_UINT32("cbar", ARMCPU, reset_cbar, 0),
>> + DEFINE_PROP_END_OF_LIST(),
>> +};
>> +
>> static const ARMCPUInfo arm_cpus[] = {
>> #if !defined(CONFIG_USER_ONLY) || !defined(TARGET_AARCH64)
>> { .name = "arm926", .initfn = arm926_initfn },
>> @@ -895,6 +901,7 @@ static void arm_cpu_class_init(ObjectClass *oc, void
>> *data)
>>
>> acc->parent_realize = dc->realize;
>> dc->realize = arm_cpu_realizefn;
>> + dc->props = arm_cpu_properties;
>>
>> acc->parent_reset = cc->reset;
>> cc->reset = arm_cpu_reset;
>
> Hmm. This means we end up with a cbar property on every
> ARM CPU whether that ARM CPU has a cbar or not...
If we turn it into a dynamic property, we could register it conditional
to ARM_FEATURE_CBAR.
The overall idea of the series makes sense to me. I would caution to
think about the naming scheme though - we might want to have a "cbar"
property to access the current value whereas we'll likely end up having
several reset values to configure over time.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
