Re: [Qemu-devel] [PATCH target-arm v4 2/3] zynq_slcr: Add links to the CPUs

[Peter Crosthwaite]

On Sat, Jan 11, 2014 at 4:11 AM, Peter Maydell <address@hidden> wrote:
> On 2 January 2014 07:31, Peter Crosthwaite <address@hidden> wrote:
>> The SLCR needs to be able to reset the CPUs, so link the CPUs to the
>> SLCR.
>
>> @@ -496,10 +500,17 @@ static const MemoryRegionOps slcr_ops = {
>>  static int zynq_slcr_init(SysBusDevice *dev)
>>  {
>>      ZynqSLCRState *s = ZYNQ_SLCR(dev);
>> +    int i;
>>
>>      memory_region_init_io(&s->iomem, OBJECT(s), &slcr_ops, s, "slcr", 
>> 0x1000);
>>      sysbus_init_mmio(dev, &s->iomem);
>>
>> +    for (i = 0; i < NUM_CPUS; ++i) {
>> +        gchar *name = g_strdup_printf("cpu%d", i);
>> +        object_property_add_link(OBJECT(dev), name, TYPE_CPU,
>> +                                 (Object **)&s->cpus[i], NULL);
>> +        g_free(name);
>> +    }
>
> This is where we get into the nasty questions of how
> we ought to be modelling reset. I don't think that
> reset controllers ought to work by having direct links
> to a pile of QOM device objects. I'd much rather we tried
> to work towards modelling this the way the hardware does,
> ie a QOM device has one or more inbound GPIO lines
> corresponding to the hardware's reset signals, and the
> SoC or board wires those up to the reset controller
> appropriately.
>

So all nice solutions to this really want named GPIOs which is
something of a long term sore-point. Are you happy to take a simple
addition of a reset GPIO to ARMCPU  (which itself just calls
cpu_reset) without the need for the big planned GPIO fixups (whether
than be pins of Andreas' QOMification)?

Regards,
Peter

> thanks
> -- PMM
>