On Tue, Jun 16, 2015 at 3:25 PM, Liviu Ionescu <i...@livius.net> wrote: > >> On 16 Jun 2015, at 19:10, Peter Crosthwaite <peter.crosthwa...@xilinx.com> >> wrote: >> >> ... In my proposal the machine model would do this. >> >> qdev_connect_gpio_out_named(mcu, "name", index, qdev_get_gpio_in(gpio_dev, >> 0)); >> >> Or something like that. > > connecting a gpio_out to a gpio_in seems not possible, gpio_in irqs are > parented to the device and parenting them to the gpio_out fail with the > parent != 0 assertion. >
This should work. Can I see the backtrace of that abort? Regards. Peter > however I was able to connect_gpio_out for standalone irqs. > > the actual connection sequence is: > > qemu_irq irq = GENERIC_GPIO_LED_STATE(led)->irq; > > qdev_connect_gpio_out(DEVICE(object_resolve_path("/machine/stm32/gpio[c]", > NULL)), 12, irq); > > I'm not very happy with it, since it is quite long. > > any suggestions how to make it more readable? > >> E.g. if the SoC define "bank A" gpios, then a >> suitable string name would be "bank-A". This should match the SoC >> level, not the board level so it wouldn't be names like "green-led". > > this is still too tricky for me. > > since the default names were unusable (like device[7], etc), I created two > containers (cortexm and stm32) and placed the peripherals inside, with names > like /cortexm/nvic, cortexm/itm, stm32/rcc, stm32/gpio[%c], etc. > > I used calls like: > > state->container = container_get(qdev_get_machine(), "/stm32"); > > object_property_add_child(state->container, "rcc", OBJECT(state->rcc), > NULL); > > > would this be acceptable? > > > regards, > > Liviu > > > > >