qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v2 5/5] hw/arm/tosa: Use LED device for the Bluetooth led


From: Philippe Mathieu-Daudé
Subject: Re: [RFC PATCH v2 5/5] hw/arm/tosa: Use LED device for the Bluetooth led
Date: Mon, 15 Jun 2020 18:18:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 6/15/20 6:00 PM, Peter Maydell wrote:
> On Fri, 12 Jun 2020 at 18:54, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> ---
>>  hw/arm/tosa.c  | 7 +++----
>>  hw/arm/Kconfig | 1 +
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/hw/arm/tosa.c b/hw/arm/tosa.c
>> index 5dee2d76c6..86d7e0283a 100644
>> --- a/hw/arm/tosa.c
>> +++ b/hw/arm/tosa.c
>> @@ -24,6 +24,7 @@
>>  #include "hw/irq.h"
>>  #include "hw/ssi/ssi.h"
>>  #include "hw/sysbus.h"
>> +#include "hw/misc/led.h"
>>  #include "exec/address-spaces.h"
>>
>>  #define TOSA_RAM    0x04000000
>> @@ -68,9 +69,6 @@ static void tosa_microdrive_attach(PXA2xxState *cpu)
>>  static void tosa_out_switch(void *opaque, int line, int level)
>>  {
>>      switch (line) {
>> -        case 0:
>> -            fprintf(stderr, "blue LED %s.\n", level ? "on" : "off");
>> -            break;
>>          case 1:
>>              fprintf(stderr, "green LED %s.\n", level ? "on" : "off");
>>              break;
> 
> Why convert the blue LED and not the green, amber or wlan LEDs ?

I don't have the schematics to verify the mapping is correct:

#define TOSA_GPIO_BT_LED                (TOSA_SCOOP_JC_GPIO_BASE + 0)
#define TOSA_GPIO_NOTE_LED              (TOSA_SCOOP_JC_GPIO_BASE + 1)
#define TOSA_GPIO_CHRG_ERR_LED          (TOSA_SCOOP_JC_GPIO_BASE + 2)
#define TOSA_GPIO_TC6393XB_L3V_ON       (TOSA_SCOOP_JC_GPIO_BASE + 5)
#define TOSA_GPIO_WLAN_LED              (TOSA_SCOOP_JC_GPIO_BASE + 7)

static void tosa_out_switch(void *opaque, int line, int level)
{
    switch (line) {
        case 0:
            fprintf(stderr, "blue LED %s.\n", level ? "on" : "off");
            break;
        case 1:
            fprintf(stderr, "green LED %s.\n", level ? "on" : "off");
            break;
        case 2:
            fprintf(stderr, "amber LED %s.\n", level ? "on" : "off");
            break;
        case 3:
            fprintf(stderr, "wlan LED %s.\n", level ? "on" : "off");
            break;
        default:
            fprintf(stderr, "Uhandled out event: %d = %d\n", line, level);
            break;
    }
}

    qdev_connect_gpio_out(scp1, TOSA_GPIO_BT_LED, outsignals[0]);
    qdev_connect_gpio_out(scp1, TOSA_GPIO_NOTE_LED, outsignals[1]);
    qdev_connect_gpio_out(scp1, TOSA_GPIO_CHRG_ERR_LED, outsignals[2]);
    qdev_connect_gpio_out(scp1, TOSA_GPIO_WLAN_LED, outsignals[3]);

I wanted a simple proof-of-concept I could test with a board,
to show how easy this API can be used.

Using the binaries from here:
https://www.omegamoon.com/blog/static.php?page=ZaurusAndroid

the blue LED never blinks, probably because we remove the
bluetooth stack. Or maybe I haven't figured the correct
command line options.

For the next RFC I plan to rework to have a single LED container
per board, to have a unique singleton object that generates QMP
events.

> 
> thanks
> -- PMM
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]