On Tue, Jun 16, 2015 at 12:22 PM, Liviu Ionescu <i...@livius.net> wrote: > >> On 16 Jun 2015, at 21:19, Peter Crosthwaite <peter.crosthwa...@xilinx.com> >> 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 solution 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, and if > it is worth doing it, but it would definitely be a good marketing tool ;-) > >> 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 there. Regards, Peter > --- > > I'm currently reworking the (generic-)gpio-led to be standalone and > accommodate your suggestions, but it'll take me some time to figure out the > details of nodes naming. > > I also had a small problem with the objects tree. initially my gpio-led > object was not derived from SysBusDevice, since I considered it a separate > object. it was functional, but made 'info qtree' fail. I changed the node > parent to SysBusDevice but I'm not sure what would be the best topology for > my 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 > >
