On 5/29/19 8:08 AM, Markus Armbruster wrote:
> Peter Maydell <peter.mayd...@linaro.org> writes:
>
>> On Mon, 27 May 2019 at 08:52, Markus Armbruster <arm...@redhat.com> wrote:
>>>
>>> Peter Maydell <peter.mayd...@linaro.org> writes:
>>>> Suggestions for how to restructure reset so this doesn't
>>>> happen are welcome... "reset follows the bus hierarchy"
>>>> works well in some places but is a bit weird in others
>>>> (for SoC containers and the like "follow the QOM
>>>> hierarchy" would make more sense, but I have no idea
>>>> how to usefully transition to a model where you could
>>>> say "for these devices, follow QOM tree for reset" or
>>>> what an API for that would look like).
>>>
>>> Here's a QOM composition tree for the ARM virt machine (-nodefaults
>>> -device e1000) as visible in qom-fuse under /machine, with irq and
>>> qemu:memory-region ommitted for brevity:
>>
>> virt is a bit of an outlier because as a purely-virtual
>> machine it has no "SoC" -- it's just a bag of devices
>> at the machine level. It would be interesting to
>> also look at a machine that's emulating something
>> closer to real hardware (eg one of the aspeed machines,
>> or mps2-an521).
>
> Here you go: witherspoon-bmc (aspeed SoC) with -nodefaults and -device
> m25p80 -device m25p80,id=qdev-id. The -device are purely for
> illustrating how user-plugged devices get added to the two trees. I'm
> not claiming they make sense.
>
> QOM composition tree as visible in qom-fuse under /machine, with irq and
> qemu:memory-region ommitted for brevity:
>
> machine witherspoon-bmc-machine
> +-- peripheral container
> | +-- qdev-id m25p80
> +-- peripheral-anon container
> | +-- device[0] m25p80
> +-- soc ast2500-a1
> | +-- cpu arm1176-arm-cpu
> | +-- fmc aspeed.smc.ast2500-fmc
> | | +-- spi SSI
> | +-- ftgmac100 ftgmac100
> | +-- i2c aspeed.i2c
> | | +-- aspeed.i2c.0 i2c-bus
> | | .
> | | . more i2c-bus
> | | .
> | | +-- aspeed.i2c.13 i2c-bus
> | +-- scu aspeed.scu
> | +-- sdmc aspeed.sdmc
> | +-- spi[0] aspeed.smc.ast2500-spi1
> | | +-- spi SSI
> | +-- spi[1] aspeed.smc.ast2500-spi2
> | | +-- spi SSI
> | +-- timerctrl aspeed.timer
> | +-- vic aspeed.vic
> | +-- wdt[0] aspeed.wdt
> | +-- wdt[1] aspeed.wdt
> | +-- wdt[2] aspeed.wdt
> +-- unattached container
> +-- device[0] unimplemented-device
> +-- device[1] mx25l25635e
> +-- device[2] mx25l25635e
> +-- device[3] mx66l1g45g
> +-- device[4] pca9552
> +-- device[5] tmp423
> +-- device[6] tmp423
> +-- device[7] tmp105
> +-- device[8] ds1338
> +-- device[9] smbus-eeprom
> +-- device[10] pca9552
> +-- sysbus System
>
> Observations (same as for ARM virt, more or less):
>
> * Where ARM virt had its onboard components as direct children of
> machine, witherspoon-bmc-machine has them wrapped in soc ast2500-a1.
>
> * machine additionally has a few containers: peripheral,
> peripheral-anon, unattached.
>
> * machine/peripheral and machine/peripheral-anon contain the -device
> with and without ID, respectively.
>
> * machine/unattached contains everything else created by code without an
> explicit parent device. Some (all?) of them should perhaps be direct
> children of machine or (unlike ARM virt) soc instead.
>
> qdev tree shown by info qtree:
>
> bus: main-system-bus
> type System
> dev: unimplemented-device, id ""
> size = 2097152 (0x200000)
> name = "aspeed_soc.io"
> mmio 000000001e600000/0000000000200000
> dev: ftgmac100, id ""
> gpio-out "sysbus-irq" 1
> aspeed = true
> mac = "52:54:00:12:34:56"
> netdev = ""
> mmio 000000001e660000/0000000000002000
> dev: aspeed.wdt, id ""
> silicon-rev = 67175171 (0x4010303)
> mmio 000000001e785040/0000000000000020
> dev: aspeed.wdt, id ""
> silicon-rev = 67175171 (0x4010303)
> mmio 000000001e785020/0000000000000020
> dev: aspeed.wdt, id ""
> silicon-rev = 67175171 (0x4010303)
> mmio 000000001e785000/0000000000000020
> dev: aspeed.sdmc, id ""
> silicon-rev = 67175171 (0x4010303)
> ram-size = 536870912 (0x20000000)
> max-ram-size = 1073741824 (0x40000000)
> mmio 000000001e6e0000/0000000000001000
> dev: aspeed.smc.ast2500-spi2, id ""
> gpio-out "sysbus-irq" 2
> num-cs = 1 (0x1)
> mmio 000000001e631000/0000000000000100
> mmio 0000000038000000/0000000008000000
> bus: spi
> type SSI
> dev: m25p80, id "qdev-id"
> gpio-in "ssi-gpio-cs" 1
> nonvolatile-cfg = 36863 (0x8fff)
> spansion-cr1nv = 0 (0x0)
> spansion-cr2nv = 8 (0x8)
> spansion-cr3nv = 2 (0x2)
> spansion-cr4nv = 16 (0x10)
> drive = ""
> dev: m25p80, id ""
> gpio-in "ssi-gpio-cs" 1
> nonvolatile-cfg = 36863 (0x8fff)
> spansion-cr1nv = 0 (0x0)
> spansion-cr2nv = 8 (0x8)
> spansion-cr3nv = 2 (0x2)
> spansion-cr4nv = 16 (0x10)
> drive = ""
> dev: aspeed.smc.ast2500-spi1, id ""
> gpio-out "sysbus-irq" 2
> num-cs = 1 (0x1)
> mmio 000000001e630000/0000000000000100
> mmio 0000000030000000/0000000008000000
> bus: spi
> type SSI
> dev: mx66l1g45g, id ""
> gpio-in "ssi-gpio-cs" 1
> nonvolatile-cfg = 36863 (0x8fff)
> spansion-cr1nv = 0 (0x0)
> spansion-cr2nv = 8 (0x8)
> spansion-cr3nv = 2 (0x2)
> spansion-cr4nv = 16 (0x10)
> drive = ""
> dev: aspeed.smc.ast2500-fmc, id ""
> gpio-out "sysbus-irq" 3
> num-cs = 2 (0x2)
> mmio 000000001e620000/0000000000000100
> mmio 0000000020000000/0000000010000000
> bus: spi
> type SSI
> dev: mx25l25635e, id ""
> gpio-in "ssi-gpio-cs" 1
> nonvolatile-cfg = 36863 (0x8fff)
> spansion-cr1nv = 0 (0x0)
> spansion-cr2nv = 8 (0x8)
> spansion-cr3nv = 2 (0x2)
> spansion-cr4nv = 16 (0x10)
> drive = ""
> dev: mx25l25635e, id ""
> gpio-in "ssi-gpio-cs" 1
> nonvolatile-cfg = 36863 (0x8fff)
> spansion-cr1nv = 0 (0x0)
> spansion-cr2nv = 8 (0x8)
> spansion-cr3nv = 2 (0x2)
> spansion-cr4nv = 16 (0x10)
> drive = ""
> dev: aspeed.i2c, id ""
> gpio-out "sysbus-irq" 1
> mmio 000000001e78a000/0000000000001000
> bus: aspeed.i2c.13
> type i2c-bus
> ... more i2c-bus
> bus: aspeed.i2c.0
> type i2c-bus
> dev: aspeed.timer, id ""
> gpio-out "sysbus-irq" 8
> mmio 000000001e782000/0000000000001000
> dev: aspeed.vic, id ""
> gpio-out "sysbus-irq" 2
> gpio-in "" 51
> mmio 000000001e6c0000/0000000000020000
> dev: aspeed.scu, id ""
> silicon-rev = 67175171 (0x4010303)
> hw-strap1 = 4044018182 (0xf10ad206)
> hw-strap2 = 0 (0x0)
> hw-prot-key = 0 (0x0)
> mmio 000000001e6e2000/0000000000001000
>
> Observations (same as for ARM virt):
>
> * machine's containers are not in the qtree.
>
> * Composition tree node arm1176-arm-cpu is not in the qtree. That's
> because it isn't connected to a qbus.
>
> Same for pca9552, tmp423, tmp105, ds1338, smbus-eeprom, I guess.
That is odd:
static void witherspoon_bmc_i2c_init(AspeedBoardState *bmc)
{
AspeedSoCState *soc = &bmc->soc;
i2c_create_slave(
aspeed_i2c_get_bus(DEVICE(&soc->i2c), 3),
TYPE_PCA9552, 0x60);
...
DeviceState *i2c_create_slave(I2CBus *bus, const char *name, ...
{
DeviceState *dev;
dev = qdev_create(&bus->qbus, name);
...
static void aspeed_i2c_realize(DeviceState *dev, Error **errp)
{
SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
AspeedI2CState *s = ASPEED_I2C(dev);
for (i = 0; i < ASPEED_I2C_NR_BUSSES; i++) {
s->busses[i].bus = i2c_init_bus(dev, name);
...
I2CBus *i2c_init_bus(DeviceState *parent, const char *name)
{
I2CBus *bus;
bus = I2C_BUS(qbus_create(TYPE_I2C_BUS, parent, name));
...
static const TypeInfo i2c_bus_info = {
.name = TYPE_I2C_BUS,
.parent = TYPE_BUS,
...
> * In the qtree, every other inner node is a qbus. These are *leaves* in
> the composition tree. The qtree's vertex from qbus to qdev is a
> *link* in the composition tree.
>
> Example: main-system-bus -> scu is
> machine/unattached/sysbus/child[0] ->
> ../../../machine/soc/scu.
>
> Example: main-system-bus -> unimplemented-device is
> machine/unattached/sysbus/child[12] ->
> ../../../machine/unattached/device[12].
>
> Example: main-system-bus/aspeed.smc.ast2500-spi1/spi -> mx66l1g45g is
> machine/soc/spi\[0\]/spi/child[0] ->
> ../../../../machine/unattached/device[3].
>
> Example: main-system-bus/aspeed.smc.ast2500-spi2/spi -> m25p80
> (the one without a qdev ID) is
> machine/soc/spi\[1\]/spi/child[0] ->
> ../../../../machine/peripheral-anon/device[0]
>
> Example: main-system-bus/aspeed.smc.ast2500-spi2/spi -> m25p80
> (the one with qdev ID "qdev-id") is
> machine/soc/spi\[1\]/spi/child[1] ->
> ../../../../machine/peripheral/qdev-id
>
