[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] generic-gpio-led & stm32-gpio-led
From: |
Liviu Ionescu |
Subject: |
Re: [Qemu-devel] [RFC] generic-gpio-led & stm32-gpio-led |
Date: |
Wed, 17 Jun 2015 01:25:34 +0300 |
> On 16 Jun 2015, at 19:10, Peter Crosthwaite <address@hidden> 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.
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