qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/12] QOM'ify SuperH CPU and SH7750 SoC


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH 00/12] QOM'ify SuperH CPU and SH7750 SoC
Date: Wed, 14 Mar 2012 19:25:08 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2

Am 14.03.2012 17:06, schrieb Peter Maydell:
> On 14 March 2012 16:01, Andreas Färber <address@hidden> wrote:
>> Based on qom-cpu v4 and object_class_get_list() v2, this series converts
>> the SuperH CPU to QOM.
>>
>> The SH7750 SoC code invited to do some cleanups, making use of the SuperHCPU,
>> so I've QOM'ified the SoC and added the CPU as a link<SuperHCPU> for now.
>>
>> I'm not so happy about the link construct, so it may need to be redone
>> as a SysBus device with qdev properties
> 
> Shouldn't the CPU be a child of the SoC, not a link?

Exactly. Issue was twofold:

1) There is no object_property_set_child(), and using
object_property_add_child() in the machine for the SoC seemed wrong.
Setting the link target allowed to set the field in the state struct via
QOM without reintroducing qdev pointer properties.

2) The SH7750 SoC is expected to have one of three user-selectable CPU
cores (SH7750, SH7750R and SH7751 iirc) and this somewhat violates the
layering. Making it a SysBus device with a string property to tunnel
through the cpu_model is what I'm referring to below for v2.

>> - long-term I'd like to have a
>> "system-on-chip" type derived from TYPE_DEVICE. Deriving it from
>> TYPE_SYS_BUS_DEVICE might make for a better v2.
> 
> I think TYPE_SYS_BUS_DEVICE should go away in favour of everything
> being a TYPE_DEVICE.
> 
> What do you think a "system-on-chip" type would be needed for?
> I would have expected that SoCs would basically just be "containers"
> of devices and directly be TYPE_DEVICEs...

I was thinking that SoCs should have a fixed relation to particular CPU
core(s). -cpu exynos4210 would then select CPUs+x, we therefore need to
type-check it, and only features (NEON) etc. would be tweakable via QOM.
As opposed to having a fixed SoC like this one here and trying to fiddle
with its internals.

In particular I have decoupling of SoC from machine in mind: for Tegra2
I have tegra2.c defining a "tegra2-soc" type and am preparing an "ac100"
machine in tegra2_boards.c that trivially does an
object_new(TYPE_TEGRA2) that in turn instantiates all the SoC-level
SysBus devices in its initfn.

So, I think CPUs, and SoCs as CPU parent, are a special case of device.

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]