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 >