Re: [Qemu-devel] [RFC] generic-gpio-led & stm32-gpio-led

[Peter Crosthwaite]

On Tue, Jun 16, 2015 at 3:25 PM, Liviu Ionescu <address@hidden> wrote:
>
>> 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.
>

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
>
>
>
>
>