From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:41328)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.crosthwaite@petalogix.com>) id 1Z51AE-0006s0-5W
	for Qemu-devel@nongnu.org; Tue, 16 Jun 2015 20:25:11 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peter.crosthwaite@petalogix.com>) id 1Z51A9-0006yG-Ei
	for Qemu-devel@nongnu.org; Tue, 16 Jun 2015 20:25:10 -0400
Received: from mail-yk0-f181.google.com ([209.85.160.181]:33271)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.crosthwaite@petalogix.com>) id 1Z51A9-0006wz-Ak
	for Qemu-devel@nongnu.org; Tue, 16 Jun 2015 20:25:05 -0400
Received: by ykfr66 with SMTP id r66so27441614ykf.0
	for <Qemu-devel@nongnu.org>; Tue, 16 Jun 2015 17:25:04 -0700 (PDT)
MIME-Version: 1.0
Sender: peter.crosthwaite@petalogix.com
In-Reply-To: <BF13B75C-8352-453F-AF12-4884A34B4054@livius.net>
References: <499A9B83-4600-4B16-ACA2-C7AAE2C472B3@livius.net>
	<CAEgOgz41HsWvP4z8kN1KiS-Tcsd=ENe9-jSTqAn3but+_QKCQw@mail.gmail.com>
	<BF13B75C-8352-453F-AF12-4884A34B4054@livius.net>
Date: Tue, 16 Jun 2015 17:25:04 -0700
Message-ID: <CAEgOgz5i1_8LCQZfnzoprTsUqLoibtnhdPg-ZCLk1TgRCdBNgQ@mail.gmail.com>
From: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Qemu-devel] [RFC] generic-gpio-led & stm32-gpio-led
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Liviu Ionescu <ilg@livius.net>
Cc: Peter Maydell <peter.maydell@linaro.org>, QEMU Developers <Qemu-devel@nongnu.org>

On Tue, Jun 16, 2015 at 3:25 PM, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 16 Jun 2015, at 19:10, Peter Crosthwaite <peter.crosthwaite@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
>
>
>
>
>