[PATCH] Add the LED burst trigger

[PATCH] Add the LED burst trigger

[lgxue]

From: Joe Xue <lgxue@hotmail.com>

Allow LEDs blink in burst mode. Three parameters are exported to
sysfs: freq, delay_off and times.

	new file:   Documentation/leds/ledtrig-burst.txt
	modified:   drivers/leds/trigger/Kconfig
	modified:   drivers/leds/trigger/Makefile
	new file:   drivers/leds/trigger/ledtrig-burst.c

Signed-off-by: Joe Xue <lgxue@hotmail.com>
---
 Documentation/leds/ledtrig-burst.txt |  58 ++++++++
 drivers/leds/trigger/Kconfig         |  10 ++
 drivers/leds/trigger/Makefile        |   1 +
 drivers/leds/trigger/ledtrig-burst.c | 250 +++++++++++++++++++++++++++++++++++
 4 files changed, 319 insertions(+)
 create mode 100644 Documentation/leds/ledtrig-burst.txt
 create mode 100644 drivers/leds/trigger/ledtrig-burst.c

diff --git a/Documentation/leds/ledtrig-burst.txt b/Documentation/leds/ledtrig-burst.txt
new file mode 100644
index 0000000..50a7955
--- /dev/null
+++ b/Documentation/leds/ledtrig-burst.txt
@@ -0,0 +1,58 @@
+LED Burst Trigger
+=================
+
+0. Introduction
+
+Sometimes, the system has only one no-color led to indicate different stats.
+The LED timer trigger can let LEDs to blink in different frequency, but most
+people maybe just can discriminate two states, slow and fast.
+
+In this case, Morse code maybe is a good choice :-), but who can bear it.
+
+Besides the Morse code, another way is using burst mode. People can easily tell
+how many times the LED blinks in one cycle.
+
+Burst trigger is designed for this purpose.
+
+1. How to use
+
+Burst trigger can be enabled and disabled from user space on led class
+devices that support this trigger as shown below:
+
+     echo burst > trigger
+
+Three properties are exported. They are freq, times and delay_off.
+
+     freq      - the blink frequency, default value is 3 means 3HZ
+     times     - burst blink times in one cycle, no default value
+     delay_off - off time between two burst blinks, default value is 500 ms
+
+2. Case studies
+
+     Example 1
+
+     echo burst > trigger
+     echo 2 > times
+
+     The behaviour is like below:
+
+     on(1/6s)off(1/6s)on(1/6s)off(1/6m)
+     ...off 500ms...
+     on(1/6s)off(1/6s)on(1/3s)off(1/6m)
+     ...off 500ms
+     ...
+
+     Example 2
+
+     echo burst > trigger
+     echo 4 > freq
+     echo 3 > times
+     echo 1000 > delay_off
+
+     The behaviour is like below:
+
+     on(1/8s)off(1/8s)on(1/8s)off(1/8m)on(1/8s)off(1/8m)
+     ...off 1s...
+     on(1/8s)off(1/8s)on(1/8s)off(1/8m)on(1/8s)off(1/8m)
+     ...off 1s
+     ...
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index 49794b4..8f4ebbf 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -108,4 +108,14 @@ config LEDS_TRIGGER_CAMERA
 	  This enables direct flash/torch on/off by the driver, kernel space.
 	  If unsure, say Y.
 
+config LEDS_TRIGGER_BURST
+	tristate "LED Burst Trigger"
+	depends on LEDS_TRIGGERS
+	help
+	  This allows LEDs to blink in burst mode with parameters
+	  controlled via sysfs.  It's useful to notify different states
+	  by using one led.
+	  For more details read Documentation/leds/leds-burst.txt.
+	  If unsure, say Y.
+
 endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index 1abf48d..6c48517 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_LEDS_TRIGGER_CPU)		+= ledtrig-cpu.o
 obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON)	+= ledtrig-default-on.o
 obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT)	+= ledtrig-transient.o
 obj-$(CONFIG_LEDS_TRIGGER_CAMERA)	+= ledtrig-camera.o
+obj-$(CONFIG_LEDS_TRIGGER_BURST)	+= ledtrig-burst.o
diff --git a/drivers/leds/trigger/ledtrig-burst.c b/drivers/leds/trigger/ledtrig-burst.c
new file mode 100644
index 0000000..95eda2a
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-burst.c
@@ -0,0 +1,250 @@
+/*
+ * LED Kernel Burst Trigger
+ *
+ * Copyright (C) 2013 Joe Xue <lgxue@hotmail.com>
+ *
+ * Based on Richard Purdie's ledtrig-timer.c and Atsushi Nemoto's
+ * ledtrig-heartbeat.c and Shuah Khan's ledtrig-burst.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+/*
+ * Burst trigger allows LEDs to blink in burst mode. The difference
+ * between burst trigger and timer trigger is timer trigger makes the
+ * LEDs blink continually in a frequency while burst trigger makes the
+ * LEDs blink some times in a special frequency then have a stop.
+ * Burst trigger allows LEDs to indicate different stats. Users can easy
+ * to describe it to support engineers by saying 3/4/5/X times burst
+ * blink.
+*/
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/timer.h>
+#include <linux/leds.h>
+#include "../leds.h"
+
+struct burst_trig_data {
+	int state;
+	unsigned long freq;
+	unsigned long times;
+	unsigned long count;
+	unsigned long delay_off;
+	int brightness_on;
+	struct timer_list timer;
+};
+
+static void burst_timer_function(unsigned long data)
+{
+	struct led_classdev *led_cdev = (struct led_classdev *) data;
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+
+	if (burst_data->count > 0) {
+		/* revert the light state */
+		burst_data->state = 1 - burst_data->state;
+		__led_set_brightness(led_cdev,
+				burst_data->state*burst_data->brightness_on);
+		burst_data->count--;
+		/* the delay time for on and off are 1000/(freq*2) = 500/freq */
+		mod_timer(&burst_data->timer,
+			jiffies + msecs_to_jiffies(500/burst_data->freq));
+	} else {
+		burst_data->count = burst_data->times * 2;
+		mod_timer(&burst_data->timer,
+			jiffies + msecs_to_jiffies(burst_data->delay_off));
+	}
+}
+
+static ssize_t burst_delay_off_show(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	struct led_classdev *led_cdev = dev_get_drvdata(dev);
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+
+	return sprintf(buf, "%lu\n", burst_data->delay_off);
+}
+
+static ssize_t burst_delay_off_store(struct device *dev,
+		struct device_attribute *attr, const char *buf, size_t size)
+{
+	struct led_classdev *led_cdev = dev_get_drvdata(dev);
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+	unsigned long state;
+	ssize_t ret = -EINVAL;
+
+	ret = kstrtoul(buf, 10, &state);
+	if (ret)
+		return ret;
+
+	burst_data->delay_off = state;
+
+	return size;
+}
+
+static ssize_t burst_times_show(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	struct led_classdev *led_cdev = dev_get_drvdata(dev);
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+
+	return sprintf(buf, "%lu\n", burst_data->times);
+}
+
+static ssize_t burst_times_store(struct device *dev,
+		struct device_attribute *attr, const char *buf, size_t size)
+{
+	struct led_classdev *led_cdev = dev_get_drvdata(dev);
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+	unsigned long state;
+	ssize_t ret = -EINVAL;
+
+	ret = kstrtoul(buf, 10, &state);
+	if (ret)
+		return ret;
+
+	/* if the times is larger then 0 then use it else stop burst */
+	if (state > 0) {
+		burst_data->times = state;
+		burst_data->count = state*2;
+		del_timer_sync(&burst_data->timer);
+		mod_timer(&burst_data->timer, jiffies + 1);
+	} else {
+		del_timer_sync(&burst_data->timer);
+	}
+
+	return size;
+}
+
+static ssize_t burst_freq_show(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	struct led_classdev *led_cdev = dev_get_drvdata(dev);
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+
+	return sprintf(buf, "%lu\n", burst_data->freq);
+}
+
+static ssize_t burst_freq_store(struct device *dev,
+		struct device_attribute *attr, const char *buf, size_t size)
+{
+	struct led_classdev *led_cdev = dev_get_drvdata(dev);
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+	unsigned long state;
+	ssize_t ret = -EINVAL;
+
+	ret = kstrtoul(buf, 10, &state);
+	if (ret)
+		return ret;
+
+	/* the frequency can not be 0 */
+	if (state == 0)
+		return -EINVAL;
+
+	burst_data->freq = state;
+
+	return size;
+}
+
+static DEVICE_ATTR(freq, 0644, burst_freq_show, burst_freq_store);
+static DEVICE_ATTR(times, 0644, burst_times_show, burst_times_store);
+static DEVICE_ATTR(delay_off, 0644,
+		burst_delay_off_show, burst_delay_off_store);
+
+static void burst_trig_activate(struct led_classdev *led_cdev)
+{
+	int rc;
+	struct burst_trig_data *tdata;
+
+	tdata = kzalloc(sizeof(struct burst_trig_data), GFP_KERNEL);
+	if (!tdata) {
+		dev_err(led_cdev->dev,
+			"unable to allocate burst trigger\n");
+		return;
+	}
+	/* default frequency 3HZ */
+	tdata->freq = 3;
+	/* default delay_off 500ms */
+	tdata->delay_off = 500;
+
+	tdata->state = 0;
+
+	led_cdev->trigger_data = tdata;
+
+	rc = device_create_file(led_cdev->dev, &dev_attr_freq);
+	if (rc)
+		goto err_out;
+
+	rc = device_create_file(led_cdev->dev, &dev_attr_times);
+	if (rc)
+		goto err_out_times;
+
+	rc = device_create_file(led_cdev->dev, &dev_attr_delay_off);
+	if (rc)
+		goto err_out_delay_off;
+
+	setup_timer(&tdata->timer, burst_timer_function,
+		    (unsigned long) led_cdev);
+
+	tdata->brightness_on = led_get_brightness(led_cdev);
+	if (tdata->brightness_on == LED_OFF)
+		tdata->brightness_on = led_cdev->max_brightness;
+
+	__led_set_brightness(led_cdev, LED_OFF);
+	led_cdev->activated = true;
+
+	return;
+
+err_out_delay_off:
+	device_remove_file(led_cdev->dev, &dev_attr_times);
+err_out_times:
+	device_remove_file(led_cdev->dev, &dev_attr_freq);
+err_out:
+	dev_err(led_cdev->dev, "unable to register burst trigger\n");
+	led_cdev->trigger_data = NULL;
+	kfree(tdata);
+}
+
+static void burst_trig_deactivate(struct led_classdev *led_cdev)
+{
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+
+	if (led_cdev->activated) {
+		del_timer_sync(&burst_data->timer);
+		device_remove_file(led_cdev->dev, &dev_attr_freq);
+		device_remove_file(led_cdev->dev, &dev_attr_times);
+		device_remove_file(led_cdev->dev, &dev_attr_delay_off);
+		led_cdev->trigger_data = NULL;
+		led_cdev->activated = false;
+		kfree(burst_data);
+	}
+	__led_set_brightness(led_cdev, LED_OFF);
+}
+
+static struct led_trigger burst_trigger = {
+	.name     = "burst",
+	.activate = burst_trig_activate,
+	.deactivate = burst_trig_deactivate,
+};
+
+static int __init burst_trig_init(void)
+{
+	return led_trigger_register(&burst_trigger);
+}
+
+static void __exit burst_trig_exit(void)
+{
+	led_trigger_unregister(&burst_trigger);
+}
+
+module_init(burst_trig_init);
+module_exit(burst_trig_exit);
+
+MODULE_AUTHOR("Joe Xue <lgxue@hotmail.com");
+MODULE_DESCRIPTION("Burst LED trigger");
+MODULE_LICENSE("GPL");
-- 
1.8.1.2

Re: [PATCH] Add the LED burst trigger

[Pavel Machek]

Hi!

> +Sometimes, the system has only one no-color led to indicate different stats.
> +The LED timer trigger can let LEDs to blink in different frequency, but most
> +people maybe just can discriminate two states, slow and fast.
> +
> +In this case, Morse code maybe is a good choice :-), but who can bear it.
> +
> +Besides the Morse code, another way is using burst mode. People can easily tell
> +how many times the LED blinks in one cycle.

Would it make sense to make this a bit more capable, including the
morse code?

Actually... N900 has rather complex LED blinking hardware. (Yes, it
has dedicated chip that can run simple "programs" for LED blinking).

It would be cool to have reasonable interface for N900 leds... and
perhaps its subset would work for you, too...

http://wiki.maemo.org/LED_patterns

									Pavel

> +     on(1/6s)off(1/6s)on(1/6s)off(1/6m)
> +     ...off 500ms...
> +     on(1/6s)off(1/6s)on(1/3s)off(1/6m)
> +     ...off 500ms
> +     ...
> +
> +     Example 2
> +
> +     echo burst > trigger
> +     echo 4 > freq
> +     echo 3 > times
> +     echo 1000 > delay_off

Hmm, would something like

echo 40 > step_length_ms
echo "- - -          " > pattern

do the same trick?

Plus, you could for example do

echo "- ---        " > pattern

to do morse code...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: [PATCH] Add the LED burst trigger

[Joe Xue]

Hi,

Yes, Morse code can indicate any means. But when we look at the LEDs, would we like to also have a Morse code book in hand?

The burst led blink idea is because it is easy to use and easy to describe. Mostly when users on site are describing the LEDs states to the support engineer.

Joe

----------------------------------------
> Date: Thu, 26 Dec 2013 00:09:35 +0100
> From: pavel@ucw.cz
> To: lgxue@hotmail.com
> CC: cooloney@gmail.com; rpurdie@rpsys.net; rob@landley.net; milo.kim@ti.com; linux-leds@vger.kernel.org; linux-kernel@vger.kernel.org; linux-doc@vger.kernel.org
> Subject: Re: [PATCH] Add the LED burst trigger
>
> Hi!
>
>> +Sometimes, the system has only one no-color led to indicate different stats.
>> +The LED timer trigger can let LEDs to blink in different frequency, but most
>> +people maybe just can discriminate two states, slow and fast.
>> +
>> +In this case, Morse code maybe is a good choice :-), but who can bear it.
>> +
>> +Besides the Morse code, another way is using burst mode. People can easily tell
>> +how many times the LED blinks in one cycle.
>
> Would it make sense to make this a bit more capable, including the
> morse code?
>
> Actually... N900 has rather complex LED blinking hardware. (Yes, it
> has dedicated chip that can run simple "programs" for LED blinking).
>
> It would be cool to have reasonable interface for N900 leds... and
> perhaps its subset would work for you, too...
>
> http://wiki.maemo.org/LED_patterns
>
> Pavel
>
>> + on(1/6s)off(1/6s)on(1/6s)off(1/6m)
>> + ...off 500ms...
>> + on(1/6s)off(1/6s)on(1/3s)off(1/6m)
>> + ...off 500ms
>> + ...
>> +
>> + Example 2
>> +
>> + echo burst> trigger
>> + echo 4> freq
>> + echo 3> times
>> + echo 1000> delay_off
>
> Hmm, would something like
>
> echo 40> step_length_ms
> echo "- - - "> pattern
>
> do the same trick?
>
> Plus, you could for example do
>
> echo "- --- "> pattern
>
> to do morse code...
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/ 		 	   		  

Re: [PATCH] Add the LED burst trigger

[Geert Uytterhoeven]

On Tue, Dec 24, 2013 at 3:30 PM,  <lgxue@hotmail.com> wrote:
> +Three properties are exported. They are freq, times and delay_off.
> +
> +     freq      - the blink frequency, default value is 3 means 3HZ

Please write "3 Hz". In the kernel "HZ" means the number of jiffies per
second, and "3 HZ" thus represents a 3-second period.

> +     times     - burst blink times in one cycle, no default value
> +     delay_off - off time between two burst blinks, default value is 500 ms
> +
> +2. Case studies
> +
> +     Example 1
> +
> +     echo burst > trigger
> +     echo 2 > times
> +
> +     The behaviour is like below:
> +
> +     on(1/6s)off(1/6s)on(1/6s)off(1/6m)
> +     ...off 500ms...
> +     on(1/6s)off(1/6s)on(1/3s)off(1/6m)

on(1/6s)off(1/6s)on(1/6s)off(1/6s)

> +     ...off 500ms

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] Add the LED burst trigger

[Pavel Machek]

Hi!

> Yes, Morse code can indicate any means. But when we look at the LEDs, would we like to also have a Morse code book in hand?
> 
> The burst led blink idea is because it is easy to use and easy to describe. Mostly when users on site are describing the LEDs states to the support engineer.
>

Well.. above 7 or so blinks, people will be unable to count. "one
short, one long" will help to extend that. 

Plus, there may be patterns such as "keep it ON, count number of brief
OFFs"... 

That's why I suggested:

> > echo 40> step_length_ms
> > echo "- - - "> pattern
> >
> > do the same trick?
> >
> > Plus, you could for example do
> >
> > echo "- --- "> pattern
> >
> > to do morse code...

Interface

(Note that your client stripped some spaces out of it).

With that, it should be very easy to program all the reasonable
blinking patterns for single LED without PWM.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: [PATCH] Add the LED burst trigger

[Joe Xue]

Hi Pavel,

Yes, your suggest looks reasonable. Only issue maybe is not easy to called by program. After all, the interface is called by program more ofter then by human being.

I would like to change the way what you suggest, let see if other guys agree with your idea.

Before that, I'll submit another change as per Geert's suggest that change HZ to Hz.

Joe

----------------------------------------
> Date: Thu, 26 Dec 2013 15:26:08 +0100
> From: pavel@ucw.cz
> To: lgxue@hotmail.com
> CC: cooloney@gmail.com; rpurdie@rpsys.net; rob@landley.net; milo.kim@ti.com; linux-leds@vger.kernel.org; linux-kernel@vger.kernel.org; linux-doc@vger.kernel.org
> Subject: Re: [PATCH] Add the LED burst trigger
>
> Hi!
>
>> Yes, Morse code can indicate any means. But when we look at the LEDs, would we like to also have a Morse code book in hand?
>>
>> The burst led blink idea is because it is easy to use and easy to describe. Mostly when users on site are describing the LEDs states to the support engineer.
>>
>
> Well.. above 7 or so blinks, people will be unable to count. "one
> short, one long" will help to extend that.
>
> Plus, there may be patterns such as "keep it ON, count number of brief
> OFFs"...
>
> That's why I suggested:
>
>>> echo 40> step_length_ms
>>> echo "- - - "> pattern
>>>
>>> do the same trick?
>>>
>>> Plus, you could for example do
>>>
>>> echo "- --- "> pattern
>>>
>>> to do morse code...
>
> Interface
>
> (Note that your client stripped some spaces out of it).
>
> With that, it should be very easy to program all the reasonable
> blinking patterns for single LED without PWM.
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/ 		 	   		  

[PATCH] Add the LED burst trigger

[lgxue]

From: Joe Xue <lgxue@hotmail.com>

As per Geert's suggestion, change the HZ to Hz

Allow LEDs blink in burst mode. Three parameters are exported to
sysfs: freq, delay_off and times.

	new file:   Documentation/leds/ledtrig-burst.txt
	modified:   drivers/leds/trigger/Kconfig
	modified:   drivers/leds/trigger/Makefile
	new file:   drivers/leds/trigger/ledtrig-burst.c

Signed-off-by: Joe Xue <lgxue@hotmail.com>
---
 Documentation/leds/ledtrig-burst.txt |  58 ++++++++
 drivers/leds/trigger/Kconfig         |  10 ++
 drivers/leds/trigger/Makefile        |   1 +
 drivers/leds/trigger/ledtrig-burst.c | 250 +++++++++++++++++++++++++++++++++++
 4 files changed, 319 insertions(+)
 create mode 100644 Documentation/leds/ledtrig-burst.txt
 create mode 100644 drivers/leds/trigger/ledtrig-burst.c

diff --git a/Documentation/leds/ledtrig-burst.txt b/Documentation/leds/ledtrig-burst.txt
new file mode 100644
index 0000000..a6864e8
--- /dev/null
+++ b/Documentation/leds/ledtrig-burst.txt
@@ -0,0 +1,58 @@
+LED Burst Trigger
+=================
+
+0. Introduction
+
+Sometimes, the system has only one no-color led to indicate different stats.
+The LED timer trigger can let LEDs to blink in different frequency, but most
+people maybe just can discriminate two states, slow and fast.
+
+In this case, Morse code maybe is a good choice :-), but who can bear it.
+
+Besides the Morse code, another way is using burst mode. People can easily tell
+how many times the LED blinks in one cycle.
+
+Burst trigger is designed for this purpose.
+
+1. How to use
+
+Burst trigger can be enabled and disabled from user space on led class
+devices that support this trigger as shown below:
+
+     echo burst > trigger
+
+Three properties are exported. They are freq, times and delay_off.
+
+     freq      - the blink frequency, default value is 3 means 3Hz
+     times     - burst blink times in one cycle, no default value
+     delay_off - off time between two burst blinks, default value is 500 ms
+
+2. Case studies
+
+     Example 1
+
+     echo burst > trigger
+     echo 2 > times
+
+     The behaviour is like below:
+
+     on(1/6s)off(1/6s)on(1/6s)off(1/6m)
+     ...off 500ms...
+     on(1/6s)off(1/6s)on(1/3s)off(1/6m)
+     ...off 500ms
+     ...
+
+     Example 2
+
+     echo burst > trigger
+     echo 4 > freq
+     echo 3 > times
+     echo 1000 > delay_off
+
+     The behaviour is like below:
+
+     on(1/8s)off(1/8s)on(1/8s)off(1/8m)on(1/8s)off(1/8m)
+     ...off 1s...
+     on(1/8s)off(1/8s)on(1/8s)off(1/8m)on(1/8s)off(1/8m)
+     ...off 1s
+     ...
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index 49794b4..8f4ebbf 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -108,4 +108,14 @@ config LEDS_TRIGGER_CAMERA
 	  This enables direct flash/torch on/off by the driver, kernel space.
 	  If unsure, say Y.
 
+config LEDS_TRIGGER_BURST
+	tristate "LED Burst Trigger"
+	depends on LEDS_TRIGGERS
+	help
+	  This allows LEDs to blink in burst mode with parameters
+	  controlled via sysfs.  It's useful to notify different states
+	  by using one led.
+	  For more details read Documentation/leds/leds-burst.txt.
+	  If unsure, say Y.
+
 endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index 1abf48d..6c48517 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_LEDS_TRIGGER_CPU)		+= ledtrig-cpu.o
 obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON)	+= ledtrig-default-on.o
 obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT)	+= ledtrig-transient.o
 obj-$(CONFIG_LEDS_TRIGGER_CAMERA)	+= ledtrig-camera.o
+obj-$(CONFIG_LEDS_TRIGGER_BURST)	+= ledtrig-burst.o
diff --git a/drivers/leds/trigger/ledtrig-burst.c b/drivers/leds/trigger/ledtrig-burst.c
new file mode 100644
index 0000000..4ba097a
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-burst.c
@@ -0,0 +1,250 @@
+/*
+ * LED Kernel Burst Trigger
+ *
+ * Copyright (C) 2013 Joe Xue <lgxue@hotmail.com>
+ *
+ * Based on Richard Purdie's ledtrig-timer.c and Atsushi Nemoto's
+ * ledtrig-heartbeat.c and Shuah Khan's ledtrig-burst.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+/*
+ * Burst trigger allows LEDs to blink in burst mode. The difference
+ * between burst trigger and timer trigger is timer trigger makes the
+ * LEDs blink continually in a frequency while burst trigger makes the
+ * LEDs blink some times in a special frequency then have a stop.
+ * Burst trigger allows LEDs to indicate different stats. Users can easy
+ * to describe it to support engineers by saying 3/4/5/X times burst
+ * blink.
+*/
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/timer.h>
+#include <linux/leds.h>
+#include "../leds.h"
+
+struct burst_trig_data {
+	int state;
+	unsigned long freq;
+	unsigned long times;
+	unsigned long count;
+	unsigned long delay_off;
+	int brightness_on;
+	struct timer_list timer;
+};
+
+static void burst_timer_function(unsigned long data)
+{
+	struct led_classdev *led_cdev = (struct led_classdev *) data;
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+
+	if (burst_data->count > 0) {
+		/* revert the light state */
+		burst_data->state = 1 - burst_data->state;
+		__led_set_brightness(led_cdev,
+				burst_data->state*burst_data->brightness_on);
+		burst_data->count--;
+		/* the delay time for on and off are 1000/(freq*2) = 500/freq */
+		mod_timer(&burst_data->timer,
+			jiffies + msecs_to_jiffies(500/burst_data->freq));
+	} else {
+		burst_data->count = burst_data->times * 2;
+		mod_timer(&burst_data->timer,
+			jiffies + msecs_to_jiffies(burst_data->delay_off));
+	}
+}
+
+static ssize_t burst_delay_off_show(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	struct led_classdev *led_cdev = dev_get_drvdata(dev);
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+
+	return sprintf(buf, "%lu\n", burst_data->delay_off);
+}
+
+static ssize_t burst_delay_off_store(struct device *dev,
+		struct device_attribute *attr, const char *buf, size_t size)
+{
+	struct led_classdev *led_cdev = dev_get_drvdata(dev);
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+	unsigned long state;
+	ssize_t ret = -EINVAL;
+
+	ret = kstrtoul(buf, 10, &state);
+	if (ret)
+		return ret;
+
+	burst_data->delay_off = state;
+
+	return size;
+}
+
+static ssize_t burst_times_show(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	struct led_classdev *led_cdev = dev_get_drvdata(dev);
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+
+	return sprintf(buf, "%lu\n", burst_data->times);
+}
+
+static ssize_t burst_times_store(struct device *dev,
+		struct device_attribute *attr, const char *buf, size_t size)
+{
+	struct led_classdev *led_cdev = dev_get_drvdata(dev);
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+	unsigned long state;
+	ssize_t ret = -EINVAL;
+
+	ret = kstrtoul(buf, 10, &state);
+	if (ret)
+		return ret;
+
+	/* if the times is larger then 0 then use it else stop burst */
+	if (state > 0) {
+		burst_data->times = state;
+		burst_data->count = state*2;
+		del_timer_sync(&burst_data->timer);
+		mod_timer(&burst_data->timer, jiffies + 1);
+	} else {
+		del_timer_sync(&burst_data->timer);
+	}
+
+	return size;
+}
+
+static ssize_t burst_freq_show(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	struct led_classdev *led_cdev = dev_get_drvdata(dev);
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+
+	return sprintf(buf, "%lu\n", burst_data->freq);
+}
+
+static ssize_t burst_freq_store(struct device *dev,
+		struct device_attribute *attr, const char *buf, size_t size)
+{
+	struct led_classdev *led_cdev = dev_get_drvdata(dev);
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+	unsigned long state;
+	ssize_t ret = -EINVAL;
+
+	ret = kstrtoul(buf, 10, &state);
+	if (ret)
+		return ret;
+
+	/* the frequency can not be 0 */
+	if (state == 0)
+		return -EINVAL;
+
+	burst_data->freq = state;
+
+	return size;
+}
+
+static DEVICE_ATTR(freq, 0644, burst_freq_show, burst_freq_store);
+static DEVICE_ATTR(times, 0644, burst_times_show, burst_times_store);
+static DEVICE_ATTR(delay_off, 0644,
+		burst_delay_off_show, burst_delay_off_store);
+
+static void burst_trig_activate(struct led_classdev *led_cdev)
+{
+	int rc;
+	struct burst_trig_data *tdata;
+
+	tdata = kzalloc(sizeof(struct burst_trig_data), GFP_KERNEL);
+	if (!tdata) {
+		dev_err(led_cdev->dev,
+			"unable to allocate burst trigger\n");
+		return;
+	}
+	/* default frequency 3Hz */
+	tdata->freq = 3;
+	/* default delay_off 500ms */
+	tdata->delay_off = 500;
+
+	tdata->state = 0;
+
+	led_cdev->trigger_data = tdata;
+
+	rc = device_create_file(led_cdev->dev, &dev_attr_freq);
+	if (rc)
+		goto err_out;
+
+	rc = device_create_file(led_cdev->dev, &dev_attr_times);
+	if (rc)
+		goto err_out_times;
+
+	rc = device_create_file(led_cdev->dev, &dev_attr_delay_off);
+	if (rc)
+		goto err_out_delay_off;
+
+	setup_timer(&tdata->timer, burst_timer_function,
+		    (unsigned long) led_cdev);
+
+	tdata->brightness_on = led_get_brightness(led_cdev);
+	if (tdata->brightness_on == LED_OFF)
+		tdata->brightness_on = led_cdev->max_brightness;
+
+	__led_set_brightness(led_cdev, LED_OFF);
+	led_cdev->activated = true;
+
+	return;
+
+err_out_delay_off:
+	device_remove_file(led_cdev->dev, &dev_attr_times);
+err_out_times:
+	device_remove_file(led_cdev->dev, &dev_attr_freq);
+err_out:
+	dev_err(led_cdev->dev, "unable to register burst trigger\n");
+	led_cdev->trigger_data = NULL;
+	kfree(tdata);
+}
+
+static void burst_trig_deactivate(struct led_classdev *led_cdev)
+{
+	struct burst_trig_data *burst_data = led_cdev->trigger_data;
+
+	if (led_cdev->activated) {
+		del_timer_sync(&burst_data->timer);
+		device_remove_file(led_cdev->dev, &dev_attr_freq);
+		device_remove_file(led_cdev->dev, &dev_attr_times);
+		device_remove_file(led_cdev->dev, &dev_attr_delay_off);
+		led_cdev->trigger_data = NULL;
+		led_cdev->activated = false;
+		kfree(burst_data);
+	}
+	__led_set_brightness(led_cdev, LED_OFF);
+}
+
+static struct led_trigger burst_trigger = {
+	.name     = "burst",
+	.activate = burst_trig_activate,
+	.deactivate = burst_trig_deactivate,
+};
+
+static int __init burst_trig_init(void)
+{
+	return led_trigger_register(&burst_trigger);
+}
+
+static void __exit burst_trig_exit(void)
+{
+	led_trigger_unregister(&burst_trigger);
+}
+
+module_init(burst_trig_init);
+module_exit(burst_trig_exit);
+
+MODULE_AUTHOR("Joe Xue <lgxue@hotmail.com");
+MODULE_DESCRIPTION("Burst LED trigger");
+MODULE_LICENSE("GPL");
-- 
1.8.1.2

RE: [PATCH] Add the LED burst trigger

[Joe Xue]

Hi all,

I think Pavel's suggestion is a good idea, I'm starting to write another trigger named Morse code trigger.

I prefer to keeping this burst trigger and add another Morse code trigger for different application. But I know the Morse code trigger will be the super set of the burst. Say the patten ... Morse code is same as the 3 times burst blinking.

Anyway, after I finish that trigger, let community to decide which one will be adapted, or both.

Any suggestion about the new Morse trigger, please let me know.

Thank you Pavel.

Joe

----------------------------------------
> From: lgxue@hotmail.com
> To: pavel@ucw.cz
> CC: cooloney@gmail.com; rpurdie@rpsys.net; rob@landley.net; milo.kim@ti.com; linux-leds@vger.kernel.org; linux-kernel@vger.kernel.org; linux-doc@vger.kernel.org
> Subject: RE: [PATCH] Add the LED burst trigger
> Date: Thu, 26 Dec 2013 10:02:38 -0500
>
> Hi Pavel,
>
> Yes, your suggest looks reasonable. Only issue maybe is not easy to called by program. After all, the interface is called by program more ofter then by human being.
>
> I would like to change the way what you suggest, let see if other guys agree with your idea.
>
> Before that, I'll submit another change as per Geert's suggest that change HZ to Hz.
>
> Joe
>
> ----------------------------------------
>> Date: Thu, 26 Dec 2013 15:26:08 +0100
>> From: pavel@ucw.cz
>> To: lgxue@hotmail.com
>> CC: cooloney@gmail.com; rpurdie@rpsys.net; rob@landley.net; milo.kim@ti.com; linux-leds@vger.kernel.org; linux-kernel@vger.kernel.org; linux-doc@vger.kernel.org
>> Subject: Re: [PATCH] Add the LED burst trigger
>>
>> Hi!
>>
>>> Yes, Morse code can indicate any means. But when we look at the LEDs, would we like to also have a Morse code book in hand?
>>>
>>> The burst led blink idea is because it is easy to use and easy to describe. Mostly when users on site are describing the LEDs states to the support engineer.
>>>
>>
>> Well.. above 7 or so blinks, people will be unable to count. "one
>> short, one long" will help to extend that.
>>
>> Plus, there may be patterns such as "keep it ON, count number of brief
>> OFFs"...
>>
>> That's why I suggested:
>>
>>>> echo 40> step_length_ms
>>>> echo "- - - "> pattern
>>>>
>>>> do the same trick?
>>>>
>>>> Plus, you could for example do
>>>>
>>>> echo "- --- "> pattern
>>>>
>>>> to do morse code...
>>
>> Interface
>>
>> (Note that your client stripped some spaces out of it).
>>
>> With that, it should be very easy to program all the reasonable
>> blinking patterns for single LED without PWM.
>> Pavel
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/ --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/ 		 	   		  

RE: [PATCH] Add the LED burst trigger

[Joe Xue]

Hi,

I'm writing the Morse code trigger.
what about this

echo "-.-. *"> patten
-              a long on then a off
.              a short on then a off
space     a long off
*             mean repeat the patten
s             mean indicate the patten just one time then stop

Do we also need a  "step_length_ms" as Pavel's suggestion?
If so, we can define long on as 2*step_length_ms and short on as 1*step_length_ms.

Any other parameters do you guys think we should add?

Any suggestion is very appreciated.

Thanks

Joe



----------------------------------------
> Date: Thu, 26 Dec 2013 15:26:08 +0100
> From: pavel@ucw.cz
> To: lgxue@hotmail.com
> CC: cooloney@gmail.com; rpurdie@rpsys.net; rob@landley.net; milo.kim@ti.com; linux-leds@vger.kernel.org; linux-kernel@vger.kernel.org; linux-doc@vger.kernel.org
> Subject: Re: [PATCH] Add the LED burst trigger
>
> Hi!
>
>> Yes, Morse code can indicate any means. But when we look at the LEDs, would we like to also have a Morse code book in hand?
>>
>> The burst led blink idea is because it is easy to use and easy to describe. Mostly when users on site are describing the LEDs states to the support engineer.
>>
>
> Well.. above 7 or so blinks, people will be unable to count. "one
> short, one long" will help to extend that.
>
> Plus, there may be patterns such as "keep it ON, count number of brief
> OFFs"...
>
> That's why I suggested:
>
>>> echo 40> step_length_ms
>>> echo "- - - "> pattern
>>>
>>> do the same trick?
>>>
>>> Plus, you could for example do
>>>
>>> echo "- --- "> pattern
>>>
>>> to do morse code...
>
> Interface
>
> (Note that your client stripped some spaces out of it).
>
> With that, it should be very easy to program all the reasonable
> blinking patterns for single LED without PWM.
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html 		 	   		  --
To unsubscribe from this list: send the line "unsubscribe linux-leds" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add the LED burst trigger

[Pavel Machek]

Hi!

> I'm writing the Morse code trigger.
> what about this
> 
> echo "-.-. *"> patten
> -              a long on then a off
> .              a short on then a off
> space     a long off
> *             mean repeat the patten
> s             mean indicate the patten just one time then stop

Actually, that's a bit more complex that it needs to be.

Make it

"#" -- LED on

" " -- LED off.

To do morse -.-., you use "### # ### #    " pattern. But this is more
flexible, you can for example do "led mostly on, two blinks to off per
cycle" using

"########### ## ###########"

pattern.

Hmm?
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Add the LED burst trigger

[One Thousand Gnomes]

On Wed, 25 Dec 2013 20:02:33 -0500
Joe Xue <lgxue@hotmail.com> wrote:

> Hi,
> 
> Yes, Morse code can indicate any means. But when we look at the LEDs, would we like to also have a Morse code book in hand?
> 
> The burst led blink idea is because it is easy to use and easy to describe. Mostly when users on site are describing the LEDs states to the support engineer.

Sure but 
- Why bother putting it into the kernel when you can do it in user space
- Why use morse code when you are probably better using something that
  can be decoded in software off a phone video and so has FEC (viterbi or
  similar) on it ?

Re: [PATCH] Add the LED burst trigger

[Geert Uytterhoeven]

On Fri, Dec 27, 2013 at 1:31 AM, Joe Xue <lgxue@hotmail.com> wrote:
> echo "-.-. *"> patten
> -              a long on then a off
> .              a short on then a off
> space     a long off
> *             mean repeat the patten
> s             mean indicate the patten just one time then stop

Why both "*" and "s"? What happens if none of them is specified?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] Add the LED burst trigger

[Rob Landley]

On 12/26/13 10:58, Joe Xue wrote:
> Hi all,
>
> I think Pavel's suggestion is a good idea, I'm starting to write another trigger named Morse code trigger.

Those who don't know history are doomed to fail the class and have to 
retake it with the same instructor next year:

https://lkml.org/lkml/2003/1/30/43

And it didn't go very far because a decade ago not many people actually 
knew morse code anymore, even back then. (And I think that was back 
before they finally dropped the requirement to get a ham radio license...)

Rob

Re: [PATCH] Add the LED burst trigger

[Pavel Machek]

Hi!

> > Yes, Morse code can indicate any means. But when we look at the LEDs, would we like to also have a Morse code book in hand?
> > 
> > The burst led blink idea is because it is easy to use and easy to describe. Mostly when users on site are describing the LEDs states to the support engineer.
> 
> Sure but 
> - Why bother putting it into the kernel when you can do it in user
> space

At least nokia N900 actually has "hardware acceleration" for LED
blinking. (Tiny CPU connected over i2c, able to control 3 LEDs, turing
complete with something like 20 _bits_ of storage and 30 program
steps). Apparently, it makes more stable patterns (timing is very hard
to guarantee from userspace) and better power consumption (no need to
wake the CPU to blink the LEDs).

Now, wins from going userspace->kernel will not be too huge. But "If
the hardware can accelerate it, kernel should offer it even on
hardware that can not do it, for consistency".

[Ok, I should mention that N900 can actually do 3-colored LED with PWM
and synchronization between the colors -- so it can do smooth power
ramp ups. Proposed interface does not cover that.

Actually even better interface might be:

integer: time in msec for each step
pattern: binary string, with each u8 being intensity in 0-255 range

That would cover N900 features that are easy to emulate while being
practical to do on machines that do not have hardware acceleration for
LEDs. But it still does not cover synchronization between the three
RGB channels :-(.]

> - Why use morse code when you are probably better using something that
>   can be decoded in software off a phone video and so has FEC (viterbi or
>   similar) on it ?

I'd say decoding "3 blinks" -- dishwasher lacks water is easier than
pulling than installing decoding app on a phone.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Add the LED burst trigger

[Pavel Machek]

On Fri 2013-12-27 06:39:55, Rob Landley wrote:
> On 12/26/13 10:58, Joe Xue wrote:
> >Hi all,
> >
> >I think Pavel's suggestion is a good idea, I'm starting to write another trigger named Morse code trigger.
> 
> Those who don't know history are doomed to fail the class and have
> to retake it with the same instructor next year:
> 
> https://lkml.org/lkml/2003/1/30/43
> 
> And it didn't go very far because a decade ago not many people
> actually knew morse code anymore, even back then. (And I think that
> was back before they finally dropped the requirement to get a ham
> radio license...)

Don't get too fixated on the morse code aspect. It should be general
enough to allow the morse code, burst-of-blinks, various lighthouse
patterns, etc...

I do not propose to put morse code encoder into kernel (like someone
did with 2003), and with multicolor leds pretty much standard on the
cell phones these days...

Yes, it would be good to be able to say 'blink blue twice, then pause,
then repeat' for SMS message. (Like N900 already does; and yes, that's
under Linux. And yes, it needs better interface).

And ideally, it would also be offloaded to the LED controller, like
N900 already does, so your battery is not drained as the cellphone
waits for you to read the message.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Add the LED burst trigger

[One Thousand Gnomes]

> At least nokia N900 actually has "hardware acceleration" for LED
> blinking. (Tiny CPU connected over i2c, able to control 3 LEDs, turing
> complete with something like 20 _bits_ of storage and 30 program
> steps). Apparently, it makes more stable patterns (timing is very hard
> to guarantee from userspace) and better power consumption (no need to
> wake the CPU to blink the LEDs).
> 
> Now, wins from going userspace->kernel will not be too huge. But "If
> the hardware can accelerate it, kernel should offer it even on
> hardware that can not do it, for consistency".

Why ? My x86-64 box can run with 8GB processes, perhaps we should emulate
64bit on a 32bit kernel for consistency ?

It's another waste of resources - pages of memory that would cumulatively
be vastly more efficiently used by user space. Yes the N800 might want a
little driver but the rest belongs in a library and the library can use
accelerators (of any kind) if available, or even things like lightbulbs
via X10 so you can have the big red light in the control room flash if
the machine dies  8)

Alan

Re: [PATCH] Add the LED burst trigger

[Pavel Machek]

On Fri 2013-12-27 14:18:26, One Thousand Gnomes wrote:
> > At least nokia N900 actually has "hardware acceleration" for LED
> > blinking. (Tiny CPU connected over i2c, able to control 3 LEDs, turing
> > complete with something like 20 _bits_ of storage and 30 program
> > steps). Apparently, it makes more stable patterns (timing is very hard
> > to guarantee from userspace) and better power consumption (no need to
> > wake the CPU to blink the LEDs).
> > 
> > Now, wins from going userspace->kernel will not be too huge. But "If
> > the hardware can accelerate it, kernel should offer it even on
> > hardware that can not do it, for consistency".
> 
> Why ? My x86-64 box can run with 8GB processes, perhaps we should emulate
> 64bit on a 32bit kernel for consistency ?

Umm, you know that we can't really emulate 8GB processes. I believe
this is more like TCP; it could be done in userspace library, but it
is probably better in kernel.

But we already have perfectly good LED trigger system, including
"heartbeat" LED.

> It's another waste of resources - pages of memory that would cumulatively
> be vastly more efficiently used by user space. Yes the N800 might
> want a

Well, this one will be really smaller. And yes, it will make some
memory non-swappable, but I believe with triggers and infrastructure
for N900 (and similar) it will be worth it.

Plus, it will actually save CPU cycles, and thus significant power.

Lets see:

0) on N900, zero CPU wakeups.

1) in kernel: hw timer wakes up cpu, it toggles led, goes back to
sleep. (It might be even optimized not to wake the CPU all the way, as
in zaurus charging case)

2) in user space: hw timer wakes the cpu, switch to userland
application, something like 4 syscalls to write to /sys toggling the
LED (== 8 context switches). On otherwise idle arm system, it might be
factor of 2 in power, and well worth optimizing for.

> little driver but the rest belongs in a library and the library can use
> accelerators (of any kind) if available, or even things like lightbulbs
> via X10 so you can have the big red light in the control room flash if
> the machine dies  8)

Well, I'd prefer my cellphone to signal me "you have a message" by
flashing blue light, not by dimming lights in the control room ;-).

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Add the LED burst trigger

[One Thousand Gnomes]

> Well, this one will be really smaller. And yes, it will make some
> memory non-swappable, but I believe with triggers and infrastructure
> for N900 (and similar) it will be worth it.

Ah yes thats such a major proportion of platforms

> Plus, it will actually save CPU cycles, and thus significant power.

All of which will be totally wiped out if you bump all the millions of
x86 server boxes in the world up by one page of kernel space and cause a
few disk I/Os

> > little driver but the rest belongs in a library and the library can use
> > accelerators (of any kind) if available, or even things like lightbulbs
> > via X10 so you can have the big red light in the control room flash if
> > the machine dies  8)
> 
> Well, I'd prefer my cellphone to signal me "you have a message" by
> flashing blue light, not by dimming lights in the control room ;-).

Where the cellphone has an offload it makes sense to use it, but in the
general case userspace is much more flexible. You may not want a flashing
big red light and a siren but if its in kernel then nobody can have it,
if it's through a library you can.

Alan

Re: [PATCH] Add the LED burst trigger

[Geert Uytterhoeven]

On Fri, Dec 27, 2013 at 7:13 PM, One Thousand Gnomes
<gnomes@lxorguk.ukuu.org.uk> wrote:
>> Plus, it will actually save CPU cycles, and thus significant power.
>
> All of which will be totally wiped out if you bump all the millions of
> x86 server boxes in the world up by one page of kernel space and cause a
> few disk I/Os

FWIW, the former is on battery power, the latter isn't.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] Add the LED burst trigger

[Pavel Machek]

Hi!

> > Well, this one will be really smaller. And yes, it will make some
> > memory non-swappable, but I believe with triggers and infrastructure
> > for N900 (and similar) it will be worth it.
> 
> Ah yes thats such a major proportion of platforms

I don't know other cellphone hardware in details, but there are 900M
Android devices and multi-colored LEDs are quite common.

> > Plus, it will actually save CPU cycles, and thus significant power.
> 
> All of which will be totally wiped out if you bump all the millions of
> x86 server boxes in the world up by one page of kernel space and cause a
> few disk I/Os

I don't suggest people enable this on PCs/servers. This is useful for
small devices, not for PCs. LED subsystem is not usually used on
PCs...

> > > little driver but the rest belongs in a library and the library can use
> > > accelerators (of any kind) if available, or even things like lightbulbs
> > > via X10 so you can have the big red light in the control room flash if
> > > the machine dies  8)
> > 
> > Well, I'd prefer my cellphone to signal me "you have a message" by
> > flashing blue light, not by dimming lights in the control room ;-).
> 
> Where the cellphone has an offload it makes sense to use it, but in the
> general case userspace is much more flexible. You may not want a flashing
> big red light and a siren but if its in kernel then nobody can have it,
> if it's through a library you can.

Well, library is nicer for sending message to the admin over social
network of the month, while kernel module is better for Arduino-based
USB-connected Turing-complete 3-color led.

Unfortunately, collaboration between GNU and Android worlds ends at
the kernel-userspace barrier, so we are unlikely to end up with one
useful library... 

[You are right that we could have done something like lpd and have
library+daemon in the userspace playing the LED patterns. I just
believe that this is easier and better done in kernel.]

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Add the LED burst trigger

[Richard Purdie]

On Fri, 2013-12-27 at 18:13 +0000, One Thousand Gnomes wrote:
> > Well, this one will be really smaller. And yes, it will make some
> > memory non-swappable, but I believe with triggers and infrastructure
> > for N900 (and similar) it will be worth it.
> 
> Ah yes thats such a major proportion of platforms
> 
> > Plus, it will actually save CPU cycles, and thus significant power.
> 
> All of which will be totally wiped out if you bump all the millions of
> x86 server boxes in the world up by one page of kernel space and cause a
> few disk I/Os

FWIW the LED subsystem was designed to take advantage of kernel modules.
If you don't use a given trigger, it needn't be in memory, loaded or
even built at all. If something changed there which made that not
possible, that would be rather sad.

I agree with you that we shouldn't bump the kernel size unnecessarily
but I don't think triggers should do so. I actually think the kernel
could do with going on a diet and at least made so you can untangle more
of the pieces you don't want/need.

Cheers,

Richard

RE: [PATCH] Add the LED burst trigger

[Joe Xue]

Hi Pavel,

Good idea.
I have finished but I'll change it to this way soon and test it in next some days.

What the idea about the character to indicate stop?

I mean this patten maybe indicate just once maybe indicate repeatedly until the next patten.

What about "/"?
If there is a "/" at end then stop it else repeat it?

Thanks.

Joe

----------------------------------------
> Date: Fri, 27 Dec 2013 10:57:05 +0100
> From: pavel@ucw.cz
> To: lgxue@hotmail.com
> CC: cooloney@gmail.com; rpurdie@rpsys.net; rob@landley.net; milo.kim@ti.com; linux-leds@vger.kernel.org; linux-kernel@vger.kernel.org; linux-doc@vger.kernel.org
> Subject: Re: [PATCH] Add the LED burst trigger
>
> Hi!
>
>> I'm writing the Morse code trigger.
>> what about this
>>
>> echo "-.-. *"> patten
>> -              a long on then a off
>> .              a short on then a off
>> space     a long off
>> *             mean repeat the patten
>> s             mean indicate the patten just one time then stop
>
> Actually, that's a bit more complex that it needs to be.
>
> Make it
>
> "#" -- LED on
>
> " " -- LED off.
>
> To do morse -.-., you use "### # ### # " pattern. But this is more
> flexible, you can for example do "led mostly on, two blinks to off per
> cycle" using
>
> "########### ## ###########"
>
> pattern.
>
> Hmm?
> Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/ 		 	   		  

Re: [PATCH] Add the LED burst trigger

[Pavel Machek]

Hi!

> Good idea.
> I have finished but I'll change it to this way soon and test it in next some days.
> 
> What the idea about the character to indicate stop?
> 
> I mean this patten maybe indicate just once maybe indicate repeatedly until the next patten.
> 
> What about "/"?
> If there is a "/" at end then stop it else repeat it?

Actually, I'd put a do_repeat attribute somewhere instead of using
magic character for automatic repeats.

And while " " for pause and "#" for light would work. Maybe we chould
do "\0" for pause and "\177" for light... and interpret everything
between as an intensity. That will make it useful for LEDs with
variable intensites, too...

Thanks,
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: [PATCH] Add the LED burst trigger

[Joe Xue]

Hi

>> Good idea.
>> I have finished but I'll change it to this way soon and test it in next some days.
>>
>> What the idea about the character to indicate stop?
>>
>> I mean this patten maybe indicate just once maybe indicate repeatedly until the next patten.
>>
>> What about "/"?
>> If there is a "/" at end then stop it else repeat it?
>
> Actually, I'd put a do_repeat attribute somewhere instead of using
> magic character for automatic repeats.

Use this way, the user or application don't have to access two attribution files to control LEDs, and without "/" is default. If application need to blink patten once just give a "/" at the end of patten.

> And while " " for pause and "#" for light would work. Maybe we chould
> do "\0" for pause and "\177" for light... and interpret everything
> between as an intensity. That will make it useful for LEDs with
> variable intensites, too...

"\0" is not easy to give if application is a script.
intensity is a good idea, but makes it more complex, and user need to convert the "\num" to a ASCII code.

Joe 		 	   		  

Re: [PATCH] Add the LED burst trigger

[Geert Uytterhoeven]

On Sat, Dec 28, 2013 at 11:16 AM, Pavel Machek <pavel@ucw.cz> wrote:
>> Good idea.
>> I have finished but I'll change it to this way soon and test it in next some days.
>>
>> What the idea about the character to indicate stop?
>>
>> I mean this patten maybe indicate just once maybe indicate repeatedly until the next patten.
>>
>> What about "/"?
>> If there is a "/" at end then stop it else repeat it?
>
> Actually, I'd put a do_repeat attribute somewhere instead of using
> magic character for automatic repeats.
>
> And while " " for pause and "#" for light would work. Maybe we chould
> do "\0" for pause and "\177" for light... and interpret everything
> between as an intensity. That will make it useful for LEDs with
> variable intensites, too...

Sysfs is meant to be human-readable/writable, so please use plain ASCII
numbers in strings instead.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] Add the LED burst trigger

[Pavel Machek]

Hi!

> > And while " " for pause and "#" for light would work. Maybe we chould
> > do "\0" for pause and "\177" for light... and interpret everything
> > between as an intensity. That will make it useful for LEDs with
> > variable intensites, too...
> 
> "\0" is not easy to give if application is a script.
> intensity is a good idea, but makes it more complex, and user need to convert the "\num" to a ASCII code.
> 


OTOH it is easier for C programs _and_ we can support different
brightness levels.

It is not that bad from script:

echo -ne '\0\051\0377' > foo...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)

[Pavel Machek]

On Sat 2013-12-28 19:51:59, Geert Uytterhoeven wrote:
> On Sat, Dec 28, 2013 at 11:16 AM, Pavel Machek <pavel@ucw.cz> wrote:
> >> Good idea.
> >> I have finished but I'll change it to this way soon and test it in next some days.
> >>
> >> What the idea about the character to indicate stop?
> >>
> >> I mean this patten maybe indicate just once maybe indicate repeatedly until the next patten.
> >>
> >> What about "/"?
> >> If there is a "/" at end then stop it else repeat it?
> >
> > Actually, I'd put a do_repeat attribute somewhere instead of using
> > magic character for automatic repeats.
> >
> > And while " " for pause and "#" for light would work. Maybe we chould
> > do "\0" for pause and "\177" for light... and interpret everything
> > between as an intensity. That will make it useful for LEDs with
> > variable intensites, too...
> 
> Sysfs is meant to be human-readable/writable, so please use plain ASCII
> numbers in strings instead.

Actually, sysfs is meant to be one value per file, and it is
understood that data that are "natively blob" are just passed as
blob. (I believe this qualifies).

Sequence of ascii numbers would work for me, but I don't think that is
allowed.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)

[Geert Uytterhoeven]

On Sat, Dec 28, 2013 at 8:29 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> Sysfs is meant to be human-readable/writable, so please use plain ASCII
>> numbers in strings instead.
>
> Actually, sysfs is meant to be one value per file, and it is

Ideally, yes.

> understood that data that are "natively blob" are just passed as
> blob. (I believe this qualifies).

But it doesn't buy us much here, does it? It will make e.g. shell scripts
needlessly complicated.

> Sequence of ascii numbers would work for me, but I don't think that is
> allowed.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)

[Pavel Machek]

Hi!

> >> Sysfs is meant to be human-readable/writable, so please use plain ASCII
> >> numbers in strings instead.
> >
> > Actually, sysfs is meant to be one value per file, and it is
> 
> Ideally, yes.
> 
> > understood that data that are "natively blob" are just passed as
> > blob. (I believe this qualifies).
> 
> But it doesn't buy us much here, does it? It will make e.g. shell scripts
> needlessly complicated.

echo -ne '\012' is not that bad, and parsing array of integers from
kernel will be an ugly piece of code.

Anyway I don't care much, either byte array or ascii array of integers
is fine with me. (But I was under impression that after /proc
experiences, the latter is forbidden; I might be wrong.
/data/l/linux-good/Documentation/sysfs-rules.txt should be updated).

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)

[Greg KH]

On Sat, Dec 28, 2013 at 10:25:23PM +0100, Pavel Machek wrote:
> Hi!
> 
> > >> Sysfs is meant to be human-readable/writable, so please use plain ASCII
> > >> numbers in strings instead.
> > >
> > > Actually, sysfs is meant to be one value per file, and it is
> > 
> > Ideally, yes.
> > 
> > > understood that data that are "natively blob" are just passed as
> > > blob. (I believe this qualifies).
> > 
> > But it doesn't buy us much here, does it? It will make e.g. shell scripts
> > needlessly complicated.
> 
> echo -ne '\012' is not that bad, and parsing array of integers from
> kernel will be an ugly piece of code.

Ick, no.  What are you trying to do here?  Have the kernel intrepret a
sequence of bytes to flash an LED?  I thought we have frameworks in
userspace already to handle this type of thing.  Please don't invent new
ways of doing stuff...

greg k-h

Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)

[Pavel Machek]

On Sat 2013-12-28 13:50:42, Greg KH wrote:
> On Sat, Dec 28, 2013 at 10:25:23PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > >> Sysfs is meant to be human-readable/writable, so please use plain ASCII
> > > >> numbers in strings instead.
> > > >
> > > > Actually, sysfs is meant to be one value per file, and it is
> > > 
> > > Ideally, yes.
> > > 
> > > > understood that data that are "natively blob" are just passed as
> > > > blob. (I believe this qualifies).
> > > 
> > > But it doesn't buy us much here, does it? It will make e.g. shell scripts
> > > needlessly complicated.
> > 
> > echo -ne '\012' is not that bad, and parsing array of integers from
> > kernel will be an ugly piece of code.
> 
> Ick, no.  What are you trying to do here?  Have the kernel intrepret a
> sequence of bytes to flash an LED?  I thought we have frameworks in
> userspace already to handle this type of thing.  Please don't invent new
> ways of doing stuff...

Idea would be "sequence of brigtnesses" (one file) and "delay between
changes" (second file).

Reason to do it in kernel is that some machines actually have
"coprocessor" on i2c that can do it while main CPU is suspended. (For
more reasons, see beggining of thread).

Binary attribute with array of bytes should be acceptable, rights?

(IOW write(..., buf, size) )

Ascii array of decimal integers -- no so, right?

(IOW printf("%d %d ..", buf[0], buf[1]) )

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: [PATCH] Add the LED burst trigger

[Joe Xue]

Hi Pavel,

I have finished the patten trigger and have tested it.
Do you mind me putting your name as suggest-by? For part idea is from you.

Joe
----------------------------------------
> Date: Sat, 28 Dec 2013 20:26:30 +0100
> From: pavel@ucw.cz
> To: lgxue@hotmail.com
> CC: cooloney@gmail.com; rpurdie@rpsys.net; rob@landley.net; milo.kim@ti.com; linux-leds@vger.kernel.org; linux-kernel@vger.kernel.org; linux-doc@vger.kernel.org
> Subject: Re: [PATCH] Add the LED burst trigger
>
> Hi!
>
>>> And while " " for pause and "#" for light would work. Maybe we chould
>>> do "\0" for pause and "\177" for light... and interpret everything
>>> between as an intensity. That will make it useful for LEDs with
>>> variable intensites, too...
>>
>> "\0" is not easy to give if application is a script.
>> intensity is a good idea, but makes it more complex, and user need to convert the "\num" to a ASCII code.
>>
>
>
> OTOH it is easier for C programs _and_ we can support different
> brightness levels.
>
> It is not that bad from script:
>
> echo -ne '\0\051\0377'> foo...
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/ 		 	   		  

Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)

[Greg KH]

On Sun, Dec 29, 2013 at 12:50:46AM +0100, Pavel Machek wrote:
> On Sat 2013-12-28 13:50:42, Greg KH wrote:
> > On Sat, Dec 28, 2013 at 10:25:23PM +0100, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > >> Sysfs is meant to be human-readable/writable, so please use plain ASCII
> > > > >> numbers in strings instead.
> > > > >
> > > > > Actually, sysfs is meant to be one value per file, and it is
> > > > 
> > > > Ideally, yes.
> > > > 
> > > > > understood that data that are "natively blob" are just passed as
> > > > > blob. (I believe this qualifies).
> > > > 
> > > > But it doesn't buy us much here, does it? It will make e.g. shell scripts
> > > > needlessly complicated.
> > > 
> > > echo -ne '\012' is not that bad, and parsing array of integers from
> > > kernel will be an ugly piece of code.
> > 
> > Ick, no.  What are you trying to do here?  Have the kernel intrepret a
> > sequence of bytes to flash an LED?  I thought we have frameworks in
> > userspace already to handle this type of thing.  Please don't invent new
> > ways of doing stuff...
> 
> Idea would be "sequence of brigtnesses" (one file) and "delay between
> changes" (second file).

Ick.

> Reason to do it in kernel is that some machines actually have
> "coprocessor" on i2c that can do it while main CPU is suspended. (For
> more reasons, see beggining of thread).

Ick ick.

> Binary attribute with array of bytes should be acceptable, rights?

Not at all.

> (IOW write(..., buf, size) )
> 
> Ascii array of decimal integers -- no so, right?
> 
> (IOW printf("%d %d ..", buf[0], buf[1]) )

Use an ioctl with a structure to get things correct as a character
device.  As odds are, you aren't going to be able to create a "generic"
format for all of this for all types of devices that support such a
"co-processor".

greg k-h

Re: [PATCH] Add the LED burst trigger

[Pavel Machek]

Hi!
> 
> I have finished the patten trigger and have tested it.
> Do you mind me putting your name as suggest-by? For part idea is
>from you.

Feel free to do that, thanks :-).
							Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)

[Pavel Machek]

Hi!

> > Idea would be "sequence of brigtnesses" (one file) and "delay between
> > changes" (second file).
> 
> Ick.
> 
> > Reason to do it in kernel is that some machines actually have
> > "coprocessor" on i2c that can do it while main CPU is suspended. (For
> > more reasons, see beggining of thread).
> 
> Ick ick.
> 
> > Binary attribute with array of bytes should be acceptable, rights?
> 
> Not at all.
> 
> > (IOW write(..., buf, size) )
> > 
> > Ascii array of decimal integers -- no so, right?
> > 
> > (IOW printf("%d %d ..", buf[0], buf[1]) )
> 
> Use an ioctl with a structure to get things correct as a character
> device.  As odds are, you aren't going to be able to create a "generic"
> format for all of this for all types of devices that support such a
> "co-processor".

Well, we already do have hw-specific driver in the tree,
drivers/leds/leds-lp55xx-common.c . But the interface is
"interesting" and I believe we should have generic interface and it
should use existing trigger framework -- array of brightnesses does
not seem too complicated.

Do you have suggestion how to pass the brightnesses over sysfs?

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: [PATCH] Add the LED burst trigger

[Joe Xue]

Hi All, I have finished the pattern trigger and submitted it. For your convince to discuss, I also put it here.

Joe 

The LED pattern trigger allows LEDs blink in user defined pattern.

    new file:   Documentation/leds/ledtrig-pattern.txt
    modified:   drivers/leds/trigger/Kconfig
    modified:   drivers/leds/trigger/Makefile
    new file:   drivers/leds/trigger/ledtrig-pattern.c

Suggested-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Joe Xue <lgxue@hotmail.com>
---
 Documentation/leds/ledtrig-pattern.txt |  60 ++++++++++
 drivers/leds/trigger/Kconfig           |   9 ++
 drivers/leds/trigger/Makefile          |   1 +
 drivers/leds/trigger/ledtrig-pattern.c | 207 +++++++++++++++++++++++++++++++++
 4 files changed, 277 insertions(+)
 create mode 100644 Documentation/leds/ledtrig-pattern.txt
 create mode 100644 drivers/leds/trigger/ledtrig-pattern.c

diff --git a/Documentation/leds/ledtrig-pattern.txt b/Documentation/leds/ledtrig-pattern.txt
new file mode 100644
index 0000000..4b546c3
--- /dev/null
+++ b/Documentation/leds/ledtrig-pattern.txt
@@ -0,0 +1,60 @@
+LED Pattern Trigger
+===================
+
+0. Introduction
+
+LED Pattern trigger is designed to let LEDs indicate the patterns defined by
+users. This is very useful for those scenarios where only one non-color led
+needs to indicate different states.
+
+1. How to use
+
+Pattern trigger can be enabled and disabled from user space on led class
+devices that support this trigger as shown below:
+
+     echo pattern> trigger
+
+When the pattern trigger is activated, it will get the current brightness as
+its brightness if the led is on. Otherwise, it will use the maximum brightness.
+
+If the led supports different values rather than ON/OFF, the brightness can be
+set in advance before enabling the trigger.
+
+     echo 128> brightness
+     echo pattern> trigger
+
+Two properties are exported. They are delay_unit and pattern.
+
+     delay_unit - a delay time unit, default value is 125 ms
+     pattern    - blink pattern, includes three legal characters
+                  '#', ' '(space), and '/'
+                  '#' let LED on and last delay_unit long time
+                  ' ' let LED off and last delay_unit long time
+                  '/' stop pattern
+                      pattern will be repeated without it
+
+3. Examples
+
+     Example 1
+
+     echo pattern> trigger
+     echo "# ## /"
+
+     The behaviour is like below:
+
+     on(125ms)off(125ms)on(250ms)off
+     This is Morse code 'A'
+
+     Example 2
+
+     echo pattern> trigger
+     echo 200> delay_unit
+     echo "# #    "
+
+     The behaviour is like below:
+
+     on(200ms)off(200ms)on(200ms)off(800ms)
+     on(200ms)off(200ms)on(200ms)off(800ms)
+     ...(Repeat)
+
+     This is 2 times burst blinking.
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index 49794b4..23d0967 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -108,4 +108,13 @@ config LEDS_TRIGGER_CAMERA
       This enables direct flash/torch on/off by the driver, kernel space.
       If unsure, say Y.
 
+config LEDS_TRIGGER_PATTERN
+    tristate "LED Pattern Trigger"
+    depends on LEDS_TRIGGERS
+    help
+      This allows LEDs to blink in a user defined pattern controlled via
+          sysfs. It's useful to notify different states by using one led.
+      For more details read Documentation/leds/leds-pattern.txt.
+      If unsure, say Y.
+
 endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index 1abf48d..a739429 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_LEDS_TRIGGER_CPU)        += ledtrig-cpu.o
 obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON)    += ledtrig-default-on.o
 obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT)    += ledtrig-transient.o
 obj-$(CONFIG_LEDS_TRIGGER_CAMERA)    += ledtrig-camera.o
+obj-$(CONFIG_LEDS_TRIGGER_PATTERN)    += ledtrig-pattern.o
diff --git a/drivers/leds/trigger/ledtrig-pattern.c b/drivers/leds/trigger/ledtrig-pattern.c
new file mode 100644
index 0000000..80fc238
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-pattern.c
@@ -0,0 +1,207 @@
+/*
+ * LED Kernel Morse Code Trigger
+ *
+ * Copyright (C) 2013 Joe Xue <lgxue@hotmail.com>
+ *
+ * Based on Richard Purdie's ledtrig-timer.c and Atsushi Nemoto's
+ * ledtrig-heartbeat.c and Shuah Khan's ledtrig-transient.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/timer.h>
+#include <linux/leds.h>
+#include "../leds.h"
+
+#define MAX_PATTEN_LEN    255
+
+struct pattern_trig_data {
+    unsigned long delay_unit;
+    unsigned long pattern_len;
+    unsigned long count;
+    int brightness_on;
+    char pattern[MAX_PATTEN_LEN + 1];
+    struct timer_list timer;
+};
+
+static void pattern_timer_function(unsigned long data)
+{
+    struct led_classdev *led_cdev = (struct led_classdev *) data;
+    struct pattern_trig_data *pattern_data = led_cdev->trigger_data;
+
+    if (pattern_data->pattern[pattern_data->count] == '#') {
+        __led_set_brightness(led_cdev, pattern_data->brightness_on);
+        mod_timer(&pattern_data->timer,
+            jiffies + msecs_to_jiffies(pattern_data->delay_unit));
+    } else if (pattern_data->pattern[pattern_data->count] == ' ') {
+        __led_set_brightness(led_cdev, LED_OFF);
+        mod_timer(&pattern_data->timer,
+            jiffies + msecs_to_jiffies(pattern_data->delay_unit));
+    /* stop blinking */
+    } else if (pattern_data->pattern[pattern_data->count] == '/') {
+        return;
+    }
+
+    pattern_data->count++;
+    if (pattern_data->count == pattern_data->pattern_len)
+        pattern_data->count = 0;
+}
+
+static ssize_t pattern_delay_unit_show(struct device *dev,
+        struct device_attribute *attr, char *buf)
+{
+    struct led_classdev *led_cdev = dev_get_drvdata(dev);
+    struct pattern_trig_data *pattern_data = led_cdev->trigger_data;
+
+    return sprintf(buf, "%lu\n", pattern_data->delay_unit);
+}
+
+static ssize_t pattern_delay_unit_store(struct device *dev,
+        struct device_attribute *attr, const char *buf, size_t size)
+{
+    struct led_classdev *led_cdev = dev_get_drvdata(dev);
+    struct pattern_trig_data *pattern_data = led_cdev->trigger_data;
+    unsigned long state;
+    ssize_t ret = -EINVAL;
+
+    ret = kstrtoul(buf, 10, &state);
+    if (ret)
+        return ret;
+
+    pattern_data->delay_unit = state;
+
+    return size;
+}
+
+static ssize_t pattern_pattern_show(struct device *dev,
+        struct device_attribute *attr, char *buf)
+{
+    struct led_classdev *led_cdev = dev_get_drvdata(dev);
+    struct pattern_trig_data *pattern_data = led_cdev->trigger_data;
+
+    return sprintf(buf, "%s\n", pattern_data->pattern);
+}
+
+static ssize_t pattern_pattern_store(struct device *dev,
+        struct device_attribute *attr, const char *buf, size_t size)
+{
+    struct led_classdev *led_cdev = dev_get_drvdata(dev);
+    struct pattern_trig_data *pattern_data = led_cdev->trigger_data;
+    int i;
+    ssize_t ret = -EINVAL;
+
+    int len = (size> MAX_PATTEN_LEN) ? MAX_PATTEN_LEN : (size - 1);
+
+    /* legality check */
+    for (i = 0; i < len; i++) {
+        if (buf[i] != ' ' && buf[i] != '#' && buf[i] != '/')
+            return ret;
+    }
+
+    del_timer_sync(&pattern_data->timer);
+
+    memcpy(pattern_data->pattern, buf, len);
+    pattern_data->pattern[len] = '\0';
+    pattern_data->pattern_len = len;
+    pattern_data->count = 0;
+
+    mod_timer(&pattern_data->timer, jiffies + 1);
+
+    return size;
+}
+
+static DEVICE_ATTR(pattern, 0644, pattern_pattern_show, pattern_pattern_store);
+static DEVICE_ATTR(delay_unit, 0644,
+        pattern_delay_unit_show, pattern_delay_unit_store);
+
+static void pattern_trig_activate(struct led_classdev *led_cdev)
+{
+    int rc;
+    struct pattern_trig_data *tdata;
+
+    tdata = kzalloc(sizeof(struct pattern_trig_data), GFP_KERNEL);
+    if (!tdata) {
+        dev_err(led_cdev->dev,
+            "unable to allocate pattern trigger\n");
+        return;
+    }
+
+    led_cdev->trigger_data = tdata;
+
+    rc = device_create_file(led_cdev->dev, &dev_attr_pattern);
+    if (rc)
+        goto err_out;
+
+    rc = device_create_file(led_cdev->dev, &dev_attr_delay_unit);
+    if (rc)
+        goto err_out_delay_unit;
+
+    memset(tdata->pattern, 0, MAX_PATTEN_LEN + 1);
+    /* default delay_unit 125ms */
+    tdata->delay_unit = 125;
+
+    setup_timer(&tdata->timer, pattern_timer_function,
+            (unsigned long) led_cdev);
+
+    tdata->brightness_on = led_get_brightness(led_cdev);
+    if (tdata->brightness_on == LED_OFF)
+        tdata->brightness_on = led_cdev->max_brightness;
+
+    __led_set_brightness(led_cdev, LED_OFF);
+    led_cdev->activated = true;
+
+    return;
+
+err_out_delay_unit:
+    device_remove_file(led_cdev->dev, &dev_attr_pattern);
+err_out:
+    dev_err(led_cdev->dev, "unable to register pattern trigger\n");
+    led_cdev->trigger_data = NULL;
+    kfree(tdata);
+}
+
+static void pattern_trig_deactivate(struct led_classdev *led_cdev)
+{
+    struct pattern_trig_data *pattern_data = led_cdev->trigger_data;
+
+    if (led_cdev->activated) {
+        del_timer_sync(&pattern_data->timer);
+        device_remove_file(led_cdev->dev, &dev_attr_pattern);
+        device_remove_file(led_cdev->dev, &dev_attr_delay_unit);
+        led_cdev->trigger_data = NULL;
+        led_cdev->activated = false;
+        kfree(pattern_data);
+    }
+    __led_set_brightness(led_cdev, LED_OFF);
+}
+
+static struct led_trigger pattern_trigger = {
+    .name     = "pattern",
+    .activate = pattern_trig_activate,
+    .deactivate = pattern_trig_deactivate,
+};
+
+static int __init pattern_trig_init(void)
+{
+    return led_trigger_register(&pattern_trigger);
+}
+
+static void __exit pattern_trig_exit(void)
+{
+    led_trigger_unregister(&pattern_trigger);
+}
+
+module_init(pattern_trig_init);
+module_exit(pattern_trig_exit);
+
+MODULE_AUTHOR("Joe Xue <lgxue@hotmail.com");
+MODULE_DESCRIPTION("Patten LED trigger");
+MODULE_LICENSE("GPL");
-- 
1.8.1.2

----------------------------------------
> From: lgxue@hotmail.com
> To: cooloney@gmail.com; rpurdie@rpsys.net; rob@landley.net; milo.kim@ti.com
> CC: lgxue@hotmail.com; linux-leds@vger.kernel.org; linux-kernel@vger.kernel.org; linux-doc@vger.kernel.org
> Subject: [PATCH] Add the LED burst trigger
> Date: Tue, 24 Dec 2013 09:30:07 -0500
>
> From: Joe Xue <lgxue@hotmail.com>
>
> Allow LEDs blink in burst mode. Three parameters are exported to
> sysfs: freq, delay_off and times.
>
> new file: Documentation/leds/ledtrig-burst.txt
> modified: drivers/leds/trigger/Kconfig
> modified: drivers/leds/trigger/Makefile
> new file: drivers/leds/trigger/ledtrig-burst.c
>
> Signed-off-by: Joe Xue <lgxue@hotmail.com>
> ---
> Documentation/leds/ledtrig-burst.txt | 58 ++++++++
> drivers/leds/trigger/Kconfig | 10 ++
> drivers/leds/trigger/Makefile | 1 +
> drivers/leds/trigger/ledtrig-burst.c | 250 +++++++++++++++++++++++++++++++++++
> 4 files changed, 319 insertions(+)
> create mode 100644 Documentation/leds/ledtrig-burst.txt
> create mode 100644 drivers/leds/trigger/ledtrig-burst.c
>
> diff --git a/Documentation/leds/ledtrig-burst.txt b/Documentation/leds/ledtrig-burst.txt
> new file mode 100644
> index 0000000..50a7955
> --- /dev/null
> +++ b/Documentation/leds/ledtrig-burst.txt
> @@ -0,0 +1,58 @@
> +LED Burst Trigger
> +=================
> +
> +0. Introduction
> +
> +Sometimes, the system has only one no-color led to indicate different stats.
> +The LED timer trigger can let LEDs to blink in different frequency, but most
> +people maybe just can discriminate two states, slow and fast.
> +
> +In this case, Morse code maybe is a good choice :-), but who can bear it.
> +
> +Besides the Morse code, another way is using burst mode. People can easily tell
> +how many times the LED blinks in one cycle.
> +
> +Burst trigger is designed for this purpose.
> +
> +1. How to use
> +
> +Burst trigger can be enabled and disabled from user space on led class
> +devices that support this trigger as shown below:
> +
> + echo burst> trigger
> +
> +Three properties are exported. They are freq, times and delay_off.
> +
> + freq - the blink frequency, default value is 3 means 3HZ
> + times - burst blink times in one cycle, no default value
> + delay_off - off time between two burst blinks, default value is 500 ms
> +
> +2. Case studies
> +
> + Example 1
> +
> + echo burst> trigger
> + echo 2> times
> +
> + The behaviour is like below:
> +
> + on(1/6s)off(1/6s)on(1/6s)off(1/6m)
> + ...off 500ms...
> + on(1/6s)off(1/6s)on(1/3s)off(1/6m)
> + ...off 500ms
> + ...
> +
> + Example 2
> +
> + echo burst> trigger
> + echo 4> freq
> + echo 3> times
> + echo 1000> delay_off
> +
> + The behaviour is like below:
> +
> + on(1/8s)off(1/8s)on(1/8s)off(1/8m)on(1/8s)off(1/8m)
> + ...off 1s...
> + on(1/8s)off(1/8s)on(1/8s)off(1/8m)on(1/8s)off(1/8m)
> + ...off 1s
> + ...
> diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
> index 49794b4..8f4ebbf 100644
> --- a/drivers/leds/trigger/Kconfig
> +++ b/drivers/leds/trigger/Kconfig
> @@ -108,4 +108,14 @@ config LEDS_TRIGGER_CAMERA
> This enables direct flash/torch on/off by the driver, kernel space.
> If unsure, say Y.
>
> +config LEDS_TRIGGER_BURST
> + tristate "LED Burst Trigger"
> + depends on LEDS_TRIGGERS
> + help
> + This allows LEDs to blink in burst mode with parameters
> + controlled via sysfs. It's useful to notify different states
> + by using one led.
> + For more details read Documentation/leds/leds-burst.txt.
> + If unsure, say Y.
> +
> endif # LEDS_TRIGGERS
> diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
> index 1abf48d..6c48517 100644
> --- a/drivers/leds/trigger/Makefile
> +++ b/drivers/leds/trigger/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_LEDS_TRIGGER_CPU) += ledtrig-cpu.o
> obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON) += ledtrig-default-on.o
> obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o
> obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o
> +obj-$(CONFIG_LEDS_TRIGGER_BURST) += ledtrig-burst.o
> diff --git a/drivers/leds/trigger/ledtrig-burst.c b/drivers/leds/trigger/ledtrig-burst.c
> new file mode 100644
> index 0000000..95eda2a
> --- /dev/null
> +++ b/drivers/leds/trigger/ledtrig-burst.c
> @@ -0,0 +1,250 @@
> +/*
> + * LED Kernel Burst Trigger
> + *
> + * Copyright (C) 2013 Joe Xue <lgxue@hotmail.com>
> + *
> + * Based on Richard Purdie's ledtrig-timer.c and Atsushi Nemoto's
> + * ledtrig-heartbeat.c and Shuah Khan's ledtrig-burst.c
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +/*
> + * Burst trigger allows LEDs to blink in burst mode. The difference
> + * between burst trigger and timer trigger is timer trigger makes the
> + * LEDs blink continually in a frequency while burst trigger makes the
> + * LEDs blink some times in a special frequency then have a stop.
> + * Burst trigger allows LEDs to indicate different stats. Users can easy
> + * to describe it to support engineers by saying 3/4/5/X times burst
> + * blink.
> +*/
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/device.h>
> +#include <linux/slab.h>
> +#include <linux/timer.h>
> +#include <linux/leds.h>
> +#include "../leds.h"
> +
> +struct burst_trig_data {
> + int state;
> + unsigned long freq;
> + unsigned long times;
> + unsigned long count;
> + unsigned long delay_off;
> + int brightness_on;
> + struct timer_list timer;
> +};
> +
> +static void burst_timer_function(unsigned long data)
> +{
> + struct led_classdev *led_cdev = (struct led_classdev *) data;
> + struct burst_trig_data *burst_data = led_cdev->trigger_data;
> +
> + if (burst_data->count> 0) {
> + /* revert the light state */
> + burst_data->state = 1 - burst_data->state;
> + __led_set_brightness(led_cdev,
> + burst_data->state*burst_data->brightness_on);
> + burst_data->count--;
> + /* the delay time for on and off are 1000/(freq*2) = 500/freq */
> + mod_timer(&burst_data->timer,
> + jiffies + msecs_to_jiffies(500/burst_data->freq));
> + } else {
> + burst_data->count = burst_data->times * 2;
> + mod_timer(&burst_data->timer,
> + jiffies + msecs_to_jiffies(burst_data->delay_off));
> + }
> +}
> +
> +static ssize_t burst_delay_off_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + struct burst_trig_data *burst_data = led_cdev->trigger_data;
> +
> + return sprintf(buf, "%lu\n", burst_data->delay_off);
> +}
> +
> +static ssize_t burst_delay_off_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t size)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + struct burst_trig_data *burst_data = led_cdev->trigger_data;
> + unsigned long state;
> + ssize_t ret = -EINVAL;
> +
> + ret = kstrtoul(buf, 10, &state);
> + if (ret)
> + return ret;
> +
> + burst_data->delay_off = state;
> +
> + return size;
> +}
> +
> +static ssize_t burst_times_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + struct burst_trig_data *burst_data = led_cdev->trigger_data;
> +
> + return sprintf(buf, "%lu\n", burst_data->times);
> +}
> +
> +static ssize_t burst_times_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t size)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + struct burst_trig_data *burst_data = led_cdev->trigger_data;
> + unsigned long state;
> + ssize_t ret = -EINVAL;
> +
> + ret = kstrtoul(buf, 10, &state);
> + if (ret)
> + return ret;
> +
> + /* if the times is larger then 0 then use it else stop burst */
> + if (state> 0) {
> + burst_data->times = state;
> + burst_data->count = state*2;
> + del_timer_sync(&burst_data->timer);
> + mod_timer(&burst_data->timer, jiffies + 1);
> + } else {
> + del_timer_sync(&burst_data->timer);
> + }
> +
> + return size;
> +}
> +
> +static ssize_t burst_freq_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + struct burst_trig_data *burst_data = led_cdev->trigger_data;
> +
> + return sprintf(buf, "%lu\n", burst_data->freq);
> +}
> +
> +static ssize_t burst_freq_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t size)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + struct burst_trig_data *burst_data = led_cdev->trigger_data;
> + unsigned long state;
> + ssize_t ret = -EINVAL;
> +
> + ret = kstrtoul(buf, 10, &state);
> + if (ret)
> + return ret;
> +
> + /* the frequency can not be 0 */
> + if (state == 0)
> + return -EINVAL;
> +
> + burst_data->freq = state;
> +
> + return size;
> +}
> +
> +static DEVICE_ATTR(freq, 0644, burst_freq_show, burst_freq_store);
> +static DEVICE_ATTR(times, 0644, burst_times_show, burst_times_store);
> +static DEVICE_ATTR(delay_off, 0644,
> + burst_delay_off_show, burst_delay_off_store);
> +
> +static void burst_trig_activate(struct led_classdev *led_cdev)
> +{
> + int rc;
> + struct burst_trig_data *tdata;
> +
> + tdata = kzalloc(sizeof(struct burst_trig_data), GFP_KERNEL);
> + if (!tdata) {
> + dev_err(led_cdev->dev,
> + "unable to allocate burst trigger\n");
> + return;
> + }
> + /* default frequency 3HZ */
> + tdata->freq = 3;
> + /* default delay_off 500ms */
> + tdata->delay_off = 500;
> +
> + tdata->state = 0;
> +
> + led_cdev->trigger_data = tdata;
> +
> + rc = device_create_file(led_cdev->dev, &dev_attr_freq);
> + if (rc)
> + goto err_out;
> +
> + rc = device_create_file(led_cdev->dev, &dev_attr_times);
> + if (rc)
> + goto err_out_times;
> +
> + rc = device_create_file(led_cdev->dev, &dev_attr_delay_off);
> + if (rc)
> + goto err_out_delay_off;
> +
> + setup_timer(&tdata->timer, burst_timer_function,
> + (unsigned long) led_cdev);
> +
> + tdata->brightness_on = led_get_brightness(led_cdev);
> + if (tdata->brightness_on == LED_OFF)
> + tdata->brightness_on = led_cdev->max_brightness;
> +
> + __led_set_brightness(led_cdev, LED_OFF);
> + led_cdev->activated = true;
> +
> + return;
> +
> +err_out_delay_off:
> + device_remove_file(led_cdev->dev, &dev_attr_times);
> +err_out_times:
> + device_remove_file(led_cdev->dev, &dev_attr_freq);
> +err_out:
> + dev_err(led_cdev->dev, "unable to register burst trigger\n");
> + led_cdev->trigger_data = NULL;
> + kfree(tdata);
> +}
> +
> +static void burst_trig_deactivate(struct led_classdev *led_cdev)
> +{
> + struct burst_trig_data *burst_data = led_cdev->trigger_data;
> +
> + if (led_cdev->activated) {
> + del_timer_sync(&burst_data->timer);
> + device_remove_file(led_cdev->dev, &dev_attr_freq);
> + device_remove_file(led_cdev->dev, &dev_attr_times);
> + device_remove_file(led_cdev->dev, &dev_attr_delay_off);
> + led_cdev->trigger_data = NULL;
> + led_cdev->activated = false;
> + kfree(burst_data);
> + }
> + __led_set_brightness(led_cdev, LED_OFF);
> +}
> +
> +static struct led_trigger burst_trigger = {
> + .name = "burst",
> + .activate = burst_trig_activate,
> + .deactivate = burst_trig_deactivate,
> +};
> +
> +static int __init burst_trig_init(void)
> +{
> + return led_trigger_register(&burst_trigger);
> +}
> +
> +static void __exit burst_trig_exit(void)
> +{
> + led_trigger_unregister(&burst_trigger);
> +}
> +
> +module_init(burst_trig_init);
> +module_exit(burst_trig_exit);
> +
> +MODULE_AUTHOR("Joe Xue <lgxue@hotmail.com");
> +MODULE_DESCRIPTION("Burst LED trigger");
> +MODULE_LICENSE("GPL");
> --
> 1.8.1.2
> 		 	   		  

Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)

[Bryan Wu]

On Sun, Dec 29, 2013 at 3:21 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> > Idea would be "sequence of brigtnesses" (one file) and "delay between
>> > changes" (second file).
>>
>> Ick.
>>
>> > Reason to do it in kernel is that some machines actually have
>> > "coprocessor" on i2c that can do it while main CPU is suspended. (For
>> > more reasons, see beggining of thread).
>>
>> Ick ick.
>>
>> > Binary attribute with array of bytes should be acceptable, rights?
>>
>> Not at all.
>>
>> > (IOW write(..., buf, size) )
>> >
>> > Ascii array of decimal integers -- no so, right?
>> >
>> > (IOW printf("%d %d ..", buf[0], buf[1]) )
>>
>> Use an ioctl with a structure to get things correct as a character
>> device.  As odds are, you aren't going to be able to create a "generic"
>> format for all of this for all types of devices that support such a
>> "co-processor".
>
> Well, we already do have hw-specific driver in the tree,
> drivers/leds/leds-lp55xx-common.c . But the interface is
> "interesting" and I believe we should have generic interface and it
> should use existing trigger framework -- array of brightnesses does
> not seem too complicated.
>
> Do you have suggestion how to pass the brightnesses over sysfs?
>

What about send those binary stuff as firmware through kernel firmware
interface and LED trigger sysfs is just for parameters setup and
enable/disable controlling.

Thanks,
-Bryan

Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)

[Pavel Machek]

Hi!

> >> > Reason to do it in kernel is that some machines actually have
> >> > "coprocessor" on i2c that can do it while main CPU is suspended. (For
> >> > more reasons, see beggining of thread).
> >>
> >> Ick ick.
> >>
> >> > Binary attribute with array of bytes should be acceptable, rights?
> >>
> >> Not at all.
> >>
> >> > (IOW write(..., buf, size) )
> >> >
> >> > Ascii array of decimal integers -- no so, right?
> >> >
> >> > (IOW printf("%d %d ..", buf[0], buf[1]) )
> >>
> >> Use an ioctl with a structure to get things correct as a character
> >> device.  As odds are, you aren't going to be able to create a "generic"
> >> format for all of this for all types of devices that support such a
> >> "co-processor".
> >
> > Well, we already do have hw-specific driver in the tree,
> > drivers/leds/leds-lp55xx-common.c . But the interface is
> > "interesting" and I believe we should have generic interface and it
> > should use existing trigger framework -- array of brightnesses does
> > not seem too complicated.
> >
> > Do you have suggestion how to pass the brightnesses over sysfs?
> >
> 
> What about send those binary stuff as firmware through kernel firmware
> interface and LED trigger sysfs is just for parameters setup and
> enable/disable controlling.

That might be a bit too heavy. LED patterns do change quite often.

lp5523 driver uses this to push binary data through /sys. (It is code
for lp5523 processor in this case). Something like that would still be
better than firmware loader... 

cd /sys/class/i2c-adapter/i2c-2/2-0032 
echo load > engine1_mode 
echo cd /sys/class/i2c-adapter/i2c-2/2-0032 
echo 9d804000427f0d7f7f007f0042000000  > engine1_load 
echo run > engine1_mode
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html