[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
>
- Re: [RFC PATCH v2 1/5] hw/misc: Add a LED device, (continued)
[RFC PATCH v2 2/5] hw/misc/led: Add LED_STATUS_CHANGED QAPI event, Philippe Mathieu-Daudé, 2020/06/12
[RFC PATCH v2 3/5] hw/misc/led: Add create_led_by_gpio_id() helper, Philippe Mathieu-Daudé, 2020/06/12
[RFC PATCH v2 4/5] hw/arm/microbit: Add a fake LED to use as proof-of-concept with Zephyr, Philippe Mathieu-Daudé, 2020/06/12
[RFC PATCH v2 5/5] hw/arm/tosa: Use LED device for the Bluetooth led, Philippe Mathieu-Daudé, 2020/06/12