qemu-devel
[Top][All Lists]
Advanced

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

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


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH target-arm v4 2/3] zynq_slcr: Add links to the CPUs
Date: Fri, 10 Jan 2014 21:54:07 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Am 10.01.2014 21:20, schrieb 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)?

Pins are Anthony's topic, not mine. :) I rather recently suggested to do
a transparent QOM'ification. I thus have no objections against adding a
reset IRQ! That had BTW been discussed as possible solution for
partial/soft resets in PReP and x86 context.

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]