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

[Liviu Ionescu]

> On 16 Jun 2015, at 21:19, Peter Crosthwaite <address@hidden> 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.

---

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.


regards,

Liviu