From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4xAQ-00008n-TF for Qemu-devel@nongnu.org; Tue, 16 Jun 2015 16:09:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4xAM-0006SR-Gp for Qemu-devel@nongnu.org; Tue, 16 Jun 2015 16:09:06 -0400 Received: from mail-yh0-f52.google.com ([209.85.213.52]:33862) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4xAM-0006Ri-Dc for Qemu-devel@nongnu.org; Tue, 16 Jun 2015 16:09:02 -0400 Received: by yhid80 with SMTP id d80so19411392yhi.1 for ; Tue, 16 Jun 2015 13:09:02 -0700 (PDT) MIME-Version: 1.0 Sender: peter.crosthwaite@petalogix.com In-Reply-To: <879C3CA6-9C78-4126-8CD0-F7D3CC98773F@livius.net> References: <499A9B83-4600-4B16-ACA2-C7AAE2C472B3@livius.net> <5322F480-B136-4765-9E09-F1CC5AE7F4A2@livius.net> <879C3CA6-9C78-4126-8CD0-F7D3CC98773F@livius.net> Date: Tue, 16 Jun 2015 13:09:01 -0700 Message-ID: From: Peter Crosthwaite Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] generic-gpio-led & stm32-gpio-led List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Liviu Ionescu , Alistair Francis Cc: Peter Maydell , QEMU Developers On Tue, Jun 16, 2015 at 12:22 PM, Liviu Ionescu wrote: > >> On 16 Jun 2015, at 21:19, Peter Crosthwaite wrote: >> >> Your autoformatter does a surprisingly good job of getting close to >> qemu coding style. Can the rules just be tweaked any maybe QEMU coding >> style can be added to eclipse? > > this is exactly what I did, I took the K&R and tweaked it where possible.= unfortunately the closing brace position is not configurable. > >> They are not really aliases, they are the GPIO names proper. >> qdev_[init|get|connect]_gpio_[in|out]_named are direct replacements >> for the non named variants. The non-human internal names should go >> away if you use them. The name of the GPIO should match something in >> the TRM for the device. 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". >> Your new code handles that information. For your generic LED however, >> that is a QEMU invention which is why I propose a single unnamed GPIO >> in that case. > > oops... you lost me... I need to dig a bit to understand this. > >> I have to wonder though if the printfery is the right approach. > > blinking leds with printf() is just the first step, or the backup solutio= n if graphics are not available. the plan was to enable graphics, present a= picture of the board, and blink the led by painting a saturated square in = the led location. however I don't know yet how much effort this may take, a= nd if it is worth doing it, but it would definitely be a good marketing too= l ;-) > >> Can >> eclipse use QEMUs existing GPIO introspection capabilites to get the >> LED states and do something with them? Then the LED definition is pure >> GPIO passing and these is no need for new devices at all. > > I do not know the QEMU introspection capabilities (hint?) but my Eclipse = plug-in can be extended to connect to any reasonable protocol. > qtest protocol I think. I would grep qdev_intercept_gpio_out and go from th= ere. Regards, Peter > --- > > I'm currently reworking the (generic-)gpio-led to be standalone and accom= modate your suggestions, but it'll take me some time to figure out the deta= ils of nodes naming. > > I also had a small problem with the objects tree. initially my gpio-led o= bject was not derived from SysBusDevice, since I considered it a separate o= bject. it was functional, but made 'info qtree' fail. I changed the node pa= rent to SysBusDevice but I'm not sure what would be the best topology for m= y object tree. > That SysBus parenting will lead to a false topology anyways. The correct parent for the LED is TYPE_DEVICE. don't worry about the qtree, Andreas was working on a correct solution for the tree-dump that uses QOM rather than the legacy qbus tree (qtree). Regards, Peter > > regards, > > Liviu > >