qemu-devel
[Top][All Lists]
Advanced

[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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]