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: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH target-arm v4 2/3] zynq_slcr: Add links to the CPUs
Date: Fri, 10 Jan 2014 18:11:04 +0000

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.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]