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

[Peter Crosthwaite]

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

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