arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
Add red, green and blue LED channels for the RGB device connected to
PMC8380C PWM-LED pins.
Signed-off-by: Tingguo Cheng <tingguo.cheng@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
index df8d6e5c1f45e04a9f225b1df2ac6d4c4930e83f..a0b392984f43b6f525d6e82c6f31416b93795b9b 100644
--- a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
+++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
@@ -5,6 +5,7 @@
/dts-v1/;
+#include <dt-bindings/leds/common.h>
#include "hamoa-iot-som.dtsi"
/ {
@@ -867,6 +868,33 @@ usb0_1p8_reg_en: usb0-1p8-reg-en-state {
};
};
+&pm8550_pwm {
+ status = "okay";
+
+ multi-led {
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_STATUS;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@3 {
+ reg = <3>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+};
+
&pmc8380_5_gpios {
usb0_pwr_1p15_reg_en: usb0-pwr-1p15-reg-en-state {
pins = "gpio8";
---
base-commit: 18ffc9eacb541fa128e9e529f8fd6c6e795624f0
change-id: 20251017-add-rgb-led-for-hamoa-iot-evk-43ed6bda73a5
Best regards,
--
Tingguo Cheng <tingguo.cheng@oss.qualcomm.com>
On 10/17/25 10:06 AM, Tingguo Cheng wrote: > Add red, green and blue LED channels for the RGB device connected to > PMC8380C PWM-LED pins. > > Signed-off-by: Tingguo Cheng <tingguo.cheng@oss.qualcomm.com> > --- Just to make sure, is this a "multicolor LED" consisting of 3 ones, and *not* three LEDs that are supposed to communicate different functions (i.e. network, power, disk i/o)? Konrad
On 10/17/2025 4:09 PM, Konrad Dybcio wrote: > On 10/17/25 10:06 AM, Tingguo Cheng wrote: >> Add red, green and blue LED channels for the RGB device connected to >> PMC8380C PWM-LED pins. >> >> Signed-off-by: Tingguo Cheng<tingguo.cheng@oss.qualcomm.com> >> --- > Just to make sure, is this a "multicolor LED" consisting of 3 ones, > and *not* three LEDs that are supposed to communicate different > functions (i.e. network, power, disk i/o)? Yes, it's a multicolor LED composed of three individual LEDs within a single package—not three separate LEDs for different functions like network, power, or disk I/O. However, there's one exception worth mentioning: The blue channel is connected to two sourcing signals—the EDL indicator and the PMIC PWM-RGB blue LED—via two resistors. These resistors allow selection between the two sources. By default, the board is configured with the resistor soldered to connect the blue LED to the EDL indicator. To support software control, I’ve added the blue channel in the DTS, enabling the capability to light the blue LED from the software side. Some developers may choose to re-solder the resistor to connect the blue LED to the PMIC PWM-RGB output instead, depending on their hardware setup. > Konrad
On Tue, Oct 21, 2025 at 02:29:22PM +0800, Tingguo Cheng wrote: > > On 10/17/2025 4:09 PM, Konrad Dybcio wrote: > > On 10/17/25 10:06 AM, Tingguo Cheng wrote: > > > Add red, green and blue LED channels for the RGB device connected to > > > PMC8380C PWM-LED pins. > > > > > > Signed-off-by: Tingguo Cheng<tingguo.cheng@oss.qualcomm.com> > > > --- > > Just to make sure, is this a "multicolor LED" consisting of 3 ones, > > and *not* three LEDs that are supposed to communicate different > > functions (i.e. network, power, disk i/o)? > Yes, it's a multicolor LED composed of three individual LEDs within a single > package—not three separate LEDs for different functions like network, power, > or disk I/O. > However, there's one exception worth mentioning: > The blue channel is connected to two sourcing signals—the EDL indicator and > the PMIC PWM-RGB blue LED—via two resistors. These resistors allow selection > between the two sources. > By default, the board is configured with the resistor soldered to connect > the blue LED to the EDL indicator. > To support software control, I’ve added the blue channel in the DTS, > enabling the capability to light the blue LED from the software side. > Some developers may choose to re-solder the resistor to connect the blue LED > to the PMIC PWM-RGB output instead, depending on their hardware setup. Sounds like we have a RG LED, and if the user chooses to modify their hardware, they have different hardware...which they can easily describe by updating their DeviceTree. It's a bit weird, but does it work to make this LED_COLOR_ID_MULTI with just the RED and GREEN channels described? Regards, Bjorn > > Konrad
On 10/26/2025 11:15 AM, Bjorn Andersson wrote: > On Tue, Oct 21, 2025 at 02:29:22PM +0800, Tingguo Cheng wrote: >> On 10/17/2025 4:09 PM, Konrad Dybcio wrote: >>> On 10/17/25 10:06 AM, Tingguo Cheng wrote: >>>> Add red, green and blue LED channels for the RGB device connected to >>>> PMC8380C PWM-LED pins. >>>> >>>> Signed-off-by: Tingguo Cheng<tingguo.cheng@oss.qualcomm.com> >>>> --- >>> Just to make sure, is this a "multicolor LED" consisting of 3 ones, >>> and *not* three LEDs that are supposed to communicate different >>> functions (i.e. network, power, disk i/o)? >> Yes, it's a multicolor LED composed of three individual LEDs within a single >> package—not three separate LEDs for different functions like network, power, >> or disk I/O. >> However, there's one exception worth mentioning: >> The blue channel is connected to two sourcing signals—the EDL indicator and >> the PMIC PWM-RGB blue LED—via two resistors. These resistors allow selection >> between the two sources. >> By default, the board is configured with the resistor soldered to connect >> the blue LED to the EDL indicator. >> To support software control, I’ve added the blue channel in the DTS, >> enabling the capability to light the blue LED from the software side. >> Some developers may choose to re-solder the resistor to connect the blue LED >> to the PMIC PWM-RGB output instead, depending on their hardware setup. > Sounds like we have a RG LED, and if the user chooses to modify their > hardware, they have different hardware...which they can easily describe > by updating their DeviceTree. > > > It's a bit weird, but does it work to make this LED_COLOR_ID_MULTI with > just the RED and GREEN channels described? Yes, I tired before with enabling RED and GREEN only, it works. (What you said makes sense) Let me send V2 for *only enabling RED and GREEN* > > Regards, > Bjorn > >>> Konrad
On 10/21/25 8:29 AM, Tingguo Cheng wrote: > > On 10/17/2025 4:09 PM, Konrad Dybcio wrote: >> On 10/17/25 10:06 AM, Tingguo Cheng wrote: >>> Add red, green and blue LED channels for the RGB device connected to >>> PMC8380C PWM-LED pins. >>> >>> Signed-off-by: Tingguo Cheng<tingguo.cheng@oss.qualcomm.com> >>> --- >> Just to make sure, is this a "multicolor LED" consisting of 3 ones, >> and *not* three LEDs that are supposed to communicate different >> functions (i.e. network, power, disk i/o)? > Yes, it's a multicolor LED composed of three individual LEDs within a single package—not three separate LEDs for different functions like network, power, or disk I/O. > However, there's one exception worth mentioning: > The blue channel is connected to two sourcing signals—the EDL indicator and the PMIC PWM-RGB blue LED—via two resistors. These resistors allow selection between the two sources. > By default, the board is configured with the resistor soldered to connect the blue LED to the EDL indicator. > To support software control, I’ve added the blue channel in the DTS, enabling the capability to light the blue LED from the software side. > Some developers may choose to re-solder the resistor to connect the blue LED to the PMIC PWM-RGB output instead, depending on their hardware setup. Ehhh didn't know we had to save money on onboard LEDs.. This is really inconvenient to handle in software, because if e.g. userspace configures RGB=0/0/255 to signal a notification, Linux may program the light pulse generator, but the user will never receive it. On the flip side, not describing it here will not let anyone use it.. I'm not sure which way is worse Konrad
© 2016 - 2026 Red Hat, Inc.