ARM: dts: imx53: ppd: alarm LEDs use kernel LED interface
diff mbox series

Message ID 20200416145123.73039-1-sebastian.reichel@collabora.com
State In Next
Commit 8a915ec0c820b50dfa6eaf580f3053c1d81e47fe
Headers show
Series
  • ARM: dts: imx53: ppd: alarm LEDs use kernel LED interface
Related show

Commit Message

Sebastian Reichel April 16, 2020, 2:51 p.m. UTC
From: Ian Ray <ian.ray@ge.com>

Use kernel LED interface for the alarm LEDs.

Signed-off-by: Ian Ray <ian.ray@ge.com>
[Rebased]
Signed-off-by: Samu Nuutamo <samu.nuutamo@vincit.fi>
[Rebased]
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
 arch/arm/boot/dts/imx53-ppd.dts | 49 +++++++++++++++++++++++++++------
 1 file changed, 40 insertions(+), 9 deletions(-)

Comments

Pavel Machek April 24, 2020, 9:32 a.m. UTC | #1
On Thu 2020-04-16 16:51:23, Sebastian Reichel wrote:
> From: Ian Ray <ian.ray@ge.com>
> 
> Use kernel LED interface for the alarm LEDs.

Could we get these changes cced to LED maintainers?

> +		alarm1 {
> +			label = "alarm:red";
> +			gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
> +		};

So... What is function of these leds, and can we get naming more
consistent with rest of the kernel?
							Pavel
Sebastian Reichel April 24, 2020, 12:44 p.m. UTC | #2
Hi,

On Fri, Apr 24, 2020 at 11:32:26AM +0200, Pavel Machek wrote:
> On Thu 2020-04-16 16:51:23, Sebastian Reichel wrote:
> > From: Ian Ray <ian.ray@ge.com>
> > 
> > Use kernel LED interface for the alarm LEDs.
> 
> Could we get these changes cced to LED maintainers?

Sorry, you are not turning up via get_maintainer.pl and usually
subsystem maintainers are not CC'd for every DT device instance.
E.g. I do not want to be always CC'd for DT board file containing
a battery/charger. I'm quite surprised you want to be CC'd for
them, just looking at ARM DT files there are over 1000 instances
of leds.

> > +		alarm1 {
> > +			label = "alarm:red";
> > +			gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
> > +		};
> 
> So... What is function of these leds, and can we get naming more
> consistent with rest of the kernel?

The device is a medical patient monitor and these are alarm LEDs
informing about critical device or patient status. They are
referenced by their color (those are discrete LEDs, not a
multi-color one) basically everywhere. The only exception is
"silenced", which means that audible alarm is surpressed. I
don't think we have something comparable for any of those LEDs
in the mainline tree.

-- Sebastian
Sebastian Reichel May 29, 2020, 2:05 p.m. UTC | #3
Hi,

ping?

-- Sebastian

On Fri, Apr 24, 2020 at 02:44:23PM +0200, Sebastian Reichel wrote:
> Hi,
> 
> On Fri, Apr 24, 2020 at 11:32:26AM +0200, Pavel Machek wrote:
> > On Thu 2020-04-16 16:51:23, Sebastian Reichel wrote:
> > > From: Ian Ray <ian.ray@ge.com>
> > > 
> > > Use kernel LED interface for the alarm LEDs.
> > 
> > Could we get these changes cced to LED maintainers?
> 
> Sorry, you are not turning up via get_maintainer.pl and usually
> subsystem maintainers are not CC'd for every DT device instance.
> E.g. I do not want to be always CC'd for DT board file containing
> a battery/charger. I'm quite surprised you want to be CC'd for
> them, just looking at ARM DT files there are over 1000 instances
> of leds.
> 
> > > +		alarm1 {
> > > +			label = "alarm:red";
> > > +			gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
> > > +		};
> > 
> > So... What is function of these leds, and can we get naming more
> > consistent with rest of the kernel?
> 
> The device is a medical patient monitor and these are alarm LEDs
> informing about critical device or patient status. They are
> referenced by their color (those are discrete LEDs, not a
> multi-color one) basically everywhere. The only exception is
> "silenced", which means that audible alarm is surpressed. I
> don't think we have something comparable for any of those LEDs
> in the mainline tree.
> 
> -- Sebastian
Pavel Machek May 29, 2020, 4:02 p.m. UTC | #4
Hi!

> ping?

Well, I thought that we maybe do not need standard LEDs on medical hardware.

> On Fri, Apr 24, 2020 at 02:44:23PM +0200, Sebastian Reichel wrote:
> > Hi,
> > 
> > On Fri, Apr 24, 2020 at 11:32:26AM +0200, Pavel Machek wrote:
> > > On Thu 2020-04-16 16:51:23, Sebastian Reichel wrote:
> > > > From: Ian Ray <ian.ray@ge.com>
> > > > 
> > > > Use kernel LED interface for the alarm LEDs.
> > > 
> > > Could we get these changes cced to LED maintainers?
> > 
> > Sorry, you are not turning up via get_maintainer.pl and usually
> > subsystem maintainers are not CC'd for every DT device instance.
> > E.g. I do not want to be always CC'd for DT board file containing
> > a battery/charger. I'm quite surprised you want to be CC'd for
> > them, just looking at ARM DT files there are over 1000 instances
> > of leds.

Well, we have mess in the naming; I'd like to clear it up.

> > > > +		alarm1 {
> > > > +			label = "alarm:red";
> > > > +			gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
> > > > +		};
> > > 
> > > So... What is function of these leds, and can we get naming more
> > > consistent with rest of the kernel?
> > 
> > The device is a medical patient monitor and these are alarm LEDs
> > informing about critical device or patient status. They are
> > referenced by their color (those are discrete LEDs, not a
> > multi-color one) basically everywhere. The only exception is
> > "silenced", which means that audible alarm is surpressed. I
> > don't think we have something comparable for any of those LEDs
> > in the mainline tree.

Actually, we have "platform:*:mute" LEDs, that could be used for
"silenced".

Best regards,
									Pavel
Sebastian Reichel May 29, 2020, 6:03 p.m. UTC | #5
Hi,

On Fri, May 29, 2020 at 06:02:04PM +0200, Pavel Machek wrote:
> > ping?
> 
> Well, I thought that we maybe do not need standard LEDs on medical hardware.

The discussion died and the patch was not applied :) In general
IDK how worthwhile it is to use standard LED names for them. I
suppose the number of people planning to create something like
OpenWRT for medical devices is not so big.

> > On Fri, Apr 24, 2020 at 02:44:23PM +0200, Sebastian Reichel wrote:
> > > On Fri, Apr 24, 2020 at 11:32:26AM +0200, Pavel Machek wrote:
> > > > On Thu 2020-04-16 16:51:23, Sebastian Reichel wrote:
> > > > > From: Ian Ray <ian.ray@ge.com>
> > > > > 
> > > > > Use kernel LED interface for the alarm LEDs.
> > > > 
> > > > Could we get these changes cced to LED maintainers?
> > > 
> > > Sorry, you are not turning up via get_maintainer.pl and usually
> > > subsystem maintainers are not CC'd for every DT device instance.
> > > E.g. I do not want to be always CC'd for DT board file containing
> > > a battery/charger. I'm quite surprised you want to be CC'd for
> > > them, just looking at ARM DT files there are over 1000 instances
> > > of leds.
> 
> Well, we have mess in the naming; I'd like to clear it up.

I understand.

> > > > > +		alarm1 {
> > > > > +			label = "alarm:red";
> > > > > +			gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
> > > > > +		};
> > > > 
> > > > So... What is function of these leds, and can we get naming more
> > > > consistent with rest of the kernel?
> > > 
> > > The device is a medical patient monitor and these are alarm LEDs
> > > informing about critical device or patient status. They are
> > > referenced by their color (those are discrete LEDs, not a
> > > multi-color one) basically everywhere. The only exception is
> > > "silenced", which means that audible alarm is surpressed. I
> > > don't think we have something comparable for any of those LEDs
> > > in the mainline tree.
> 
> Actually, we have "platform:*:mute" LEDs, that could be used for
> "silenced".

I see you point, but wonder if mute is the right choice. The LED
signals a silenced alarm, which IMHO is not the same:

* The alarm silencing is temporary and system unsilences after
  1-2 minutes.
* LED is usually blinking instead of solid like a laptop mute LED
  (so that operator is aware of silenced alarm)
* Device usually cannot be put into silenced mode before the alarm
  appears
* Some medical devices still generate perodic beeps

AFAIK this is named alarm silencing by basically everyone for
medical devices. So I think naming this platfrom:*:mute would
increase the mess.

-- Sebastian
Pavel Machek May 29, 2020, 10:52 p.m. UTC | #6
Hi!

> On Fri, May 29, 2020 at 06:02:04PM +0200, Pavel Machek wrote:
> > > ping?
> > 
> > Well, I thought that we maybe do not need standard LEDs on medical hardware.
> 
> The discussion died and the patch was not applied :) In general
> IDK how worthwhile it is to use standard LED names for them. I
> suppose the number of people planning to create something like
> OpenWRT for medical devices is not so big.

:-)

> > > > The device is a medical patient monitor and these are alarm LEDs
> > > > informing about critical device or patient status. They are
> > > > referenced by their color (those are discrete LEDs, not a
> > > > multi-color one) basically everywhere. The only exception is
> > > > "silenced", which means that audible alarm is surpressed. I
> > > > don't think we have something comparable for any of those LEDs
> > > > in the mainline tree.
> > 
> > Actually, we have "platform:*:mute" LEDs, that could be used for
> > "silenced".
> 
> I see you point, but wonder if mute is the right choice. The LED
> signals a silenced alarm, which IMHO is not the same:
> 
> * The alarm silencing is temporary and system unsilences after
>   1-2 minutes.
> * LED is usually blinking instead of solid like a laptop mute LED
>   (so that operator is aware of silenced alarm)
> * Device usually cannot be put into silenced mode before the alarm
>   appears
> * Some medical devices still generate perodic beeps
> 
> AFAIK this is named alarm silencing by basically everyone for
> medical devices. So I think naming this platfrom:*:mute would
> increase the mess.

Ok, I guess it does not matter much. Generally no two LEDs behave
exactly the same, and I'd believe this would be close enough, but
... it really does not matter.

Best regards,
									Pavel
Sebastian Reichel June 26, 2020, 4:35 p.m. UTC | #7
Hi,

Can this be applied please? There were no changes in 5.8 cycle to
PPD's DT file, so it still applies.

Thanks,

-- Sebastian

On Thu, Apr 16, 2020 at 04:51:23PM +0200, Sebastian Reichel wrote:
> From: Ian Ray <ian.ray@ge.com>
> 
> Use kernel LED interface for the alarm LEDs.
> 
> Signed-off-by: Ian Ray <ian.ray@ge.com>
> [Rebased]
> Signed-off-by: Samu Nuutamo <samu.nuutamo@vincit.fi>
> [Rebased]
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
>  arch/arm/boot/dts/imx53-ppd.dts | 49 +++++++++++++++++++++++++++------
>  1 file changed, 40 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx53-ppd.dts b/arch/arm/boot/dts/imx53-ppd.dts
> index 5ff9a179c83c..34ce41600098 100644
> --- a/arch/arm/boot/dts/imx53-ppd.dts
> +++ b/arch/arm/boot/dts/imx53-ppd.dts
> @@ -176,7 +176,7 @@ pwm_bl: backlight {
>  		power-supply = <&reg_3v3_lcd>;
>  	};
>  
> -	leds {
> +	leds-brightness {
>  		compatible = "pwm-leds";
>  
>  		alarm-brightness {
> @@ -185,6 +185,32 @@ alarm-brightness {
>  		};
>  	};
>  
> +	leds {
> +		compatible = "gpio-leds";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_alarmled_pins>;
> +
> +		alarm1 {
> +			label = "alarm:red";
> +			gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		alarm2 {
> +			label = "alarm:yellow";
> +			gpios = <&gpio7 7 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		alarm3 {
> +			label = "alarm:blue";
> +			gpios = <&gpio7 8 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		alarm4 {
> +			label = "alarm:silenced";
> +			gpios = <&gpio7 13 GPIO_ACTIVE_HIGH>;
> +		};
> +	};
> +
>  	gpio-poweroff {
>  		compatible = "gpio-poweroff";
>  		gpios = <&gpio3 9 GPIO_ACTIVE_HIGH>;
> @@ -909,18 +935,10 @@ MX53_PAD_NANDF_CS2__GPIO6_15		0x0
>  			MX53_PAD_NANDF_CS3__GPIO6_16		0x0
>  			/* POWER_AND_BOOT_STATUS_INDICATOR */
>  			MX53_PAD_PATA_INTRQ__GPIO7_2		0x1e4
> -			/* ACTIVATE_ALARM_LIGHT_RED */
> -			MX53_PAD_PATA_DIOR__GPIO7_3		0x0
> -			/* ACTIVATE_ALARM_LIGHT_YELLOW */
> -			MX53_PAD_PATA_DA_1__GPIO7_7		0x0
> -			/* ACTIVATE_ALARM_LIGHT_CYAN */
> -			MX53_PAD_PATA_DA_2__GPIO7_8		0x0
>  			/* RUNNING_ON_BATTERY_INDICATOR_GREEN */
>  			MX53_PAD_GPIO_16__GPIO7_11		0x0
>  			/* BATTERY_STATUS_INDICATOR_AMBER */
>  			MX53_PAD_GPIO_17__GPIO7_12		0x0
> -			/* AUDIO_ALARMS_SILENCED_INDICATOR */
> -			MX53_PAD_GPIO_18__GPIO7_13		0x0
>  		>;
>  	};
>  
> @@ -1080,4 +1098,17 @@ pinctrl_usb_otg: usbotggrp {
>  			MX53_PAD_KEY_COL4__USBOH3_USBOTG_OC	0x180
>  		>;
>  	};
> +
> +	pinctrl_alarmled_pins: qmx6alarmledgrp {
> +		fsl,pins = <
> +			/* ACTIVATE_ALARM_LIGHT_RED */
> +			MX53_PAD_PATA_DIOR__GPIO7_3		0x0
> +			/* ACTIVATE_ALARM_LIGHT_YELLOW */
> +			MX53_PAD_PATA_DA_1__GPIO7_7		0x0
> +			/* ACTIVATE_ALARM_LIGHT_CYAN */
> +			MX53_PAD_PATA_DA_2__GPIO7_8		0x0
> +			/* AUDIO_ALARMS_SILENCED_INDICATOR */
> +			MX53_PAD_GPIO_18__GPIO7_13		0x0
> +		>;
> +	};
>  };
> -- 
> 2.25.1
>
Shawn Guo July 11, 2020, 10:39 a.m. UTC | #8
On Thu, Apr 16, 2020 at 04:51:23PM +0200, Sebastian Reichel wrote:
> From: Ian Ray <ian.ray@ge.com>
> 
> Use kernel LED interface for the alarm LEDs.
> 
> Signed-off-by: Ian Ray <ian.ray@ge.com>
> [Rebased]
> Signed-off-by: Samu Nuutamo <samu.nuutamo@vincit.fi>
> [Rebased]
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

s/imx53: ppd/imx53-ppd in subject.

Applied, thanks.

Patch
diff mbox series

diff --git a/arch/arm/boot/dts/imx53-ppd.dts b/arch/arm/boot/dts/imx53-ppd.dts
index 5ff9a179c83c..34ce41600098 100644
--- a/arch/arm/boot/dts/imx53-ppd.dts
+++ b/arch/arm/boot/dts/imx53-ppd.dts
@@ -176,7 +176,7 @@  pwm_bl: backlight {
 		power-supply = <&reg_3v3_lcd>;
 	};
 
-	leds {
+	leds-brightness {
 		compatible = "pwm-leds";
 
 		alarm-brightness {
@@ -185,6 +185,32 @@  alarm-brightness {
 		};
 	};
 
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_alarmled_pins>;
+
+		alarm1 {
+			label = "alarm:red";
+			gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
+		};
+
+		alarm2 {
+			label = "alarm:yellow";
+			gpios = <&gpio7 7 GPIO_ACTIVE_HIGH>;
+		};
+
+		alarm3 {
+			label = "alarm:blue";
+			gpios = <&gpio7 8 GPIO_ACTIVE_HIGH>;
+		};
+
+		alarm4 {
+			label = "alarm:silenced";
+			gpios = <&gpio7 13 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
 	gpio-poweroff {
 		compatible = "gpio-poweroff";
 		gpios = <&gpio3 9 GPIO_ACTIVE_HIGH>;
@@ -909,18 +935,10 @@  MX53_PAD_NANDF_CS2__GPIO6_15		0x0
 			MX53_PAD_NANDF_CS3__GPIO6_16		0x0
 			/* POWER_AND_BOOT_STATUS_INDICATOR */
 			MX53_PAD_PATA_INTRQ__GPIO7_2		0x1e4
-			/* ACTIVATE_ALARM_LIGHT_RED */
-			MX53_PAD_PATA_DIOR__GPIO7_3		0x0
-			/* ACTIVATE_ALARM_LIGHT_YELLOW */
-			MX53_PAD_PATA_DA_1__GPIO7_7		0x0
-			/* ACTIVATE_ALARM_LIGHT_CYAN */
-			MX53_PAD_PATA_DA_2__GPIO7_8		0x0
 			/* RUNNING_ON_BATTERY_INDICATOR_GREEN */
 			MX53_PAD_GPIO_16__GPIO7_11		0x0
 			/* BATTERY_STATUS_INDICATOR_AMBER */
 			MX53_PAD_GPIO_17__GPIO7_12		0x0
-			/* AUDIO_ALARMS_SILENCED_INDICATOR */
-			MX53_PAD_GPIO_18__GPIO7_13		0x0
 		>;
 	};
 
@@ -1080,4 +1098,17 @@  pinctrl_usb_otg: usbotggrp {
 			MX53_PAD_KEY_COL4__USBOH3_USBOTG_OC	0x180
 		>;
 	};
+
+	pinctrl_alarmled_pins: qmx6alarmledgrp {
+		fsl,pins = <
+			/* ACTIVATE_ALARM_LIGHT_RED */
+			MX53_PAD_PATA_DIOR__GPIO7_3		0x0
+			/* ACTIVATE_ALARM_LIGHT_YELLOW */
+			MX53_PAD_PATA_DA_1__GPIO7_7		0x0
+			/* ACTIVATE_ALARM_LIGHT_CYAN */
+			MX53_PAD_PATA_DA_2__GPIO7_8		0x0
+			/* AUDIO_ALARMS_SILENCED_INDICATOR */
+			MX53_PAD_GPIO_18__GPIO7_13		0x0
+		>;
+	};
 };