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 9d804000427f0d7f7f007f004200  > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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)

[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 9d804000427f0d7f7f007f004200   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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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)

[Bryan Wu]

On Sun, Dec 29, 2013 at 3:21 AM, Pavel Machek  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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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)

[Bryan Wu]

On Sun, Dec 29, 2013 at 3:21 AM, Pavel Machek pa...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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]

n_trig_activate,
+    .deactivate = pattern_trig_deactivate,
+};
+
+static int __init pattern_trig_init(void)
+{
+    return led_trigger_register(_trigger);
+}
+
+static void __exit pattern_trig_exit(void)
+{
+    led_trigger_unregister(_trigger);
+}
+
+module_init(pattern_trig_init);
+module_exit(pattern_trig_exit);
+
+MODULE_AUTHOR("Joe Xue  From: lg...@hotmail.com
> To: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com
> CC: lg...@hotmail.com; linux-l...@vger.kernel.org; 
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: [PATCH] Add the LED burst trigger
> Date: Tue, 24 Dec 2013 09:30:07 -0500
>
> From: Joe Xue 
>
> 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 
> ---
> 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 000..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 000..95eda2a
> --- /dev/null
> +++ b/drivers/leds/trigger/ledtrig-burst.c
> @@ -0,0 +1,250 @@
> +/*
> + * LED Kernel Burst Trigger
> + 

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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!
> 
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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!
 
 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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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)

[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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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]

);
+}
+
+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 lg...@hotmail.com);
+MODULE_DESCRIPTION(Patten LED trigger);
+MODULE_LICENSE(GPL);
-- 
1.8.1.2


 From: lg...@hotmail.com
 To: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com
 CC: lg...@hotmail.com; linux-l...@vger.kernel.org; 
 linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
 Subject: [PATCH] Add the LED burst trigger
 Date: Tue, 24 Dec 2013 09:30:07 -0500

 From: Joe Xue lg...@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 lg...@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 000..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 000..95eda2a
 --- /dev/null
 +++ b/drivers/leds/trigger/ledtrig-burst.c
 @@ -0,0 +1,250 @@
 +/*
 + * LED Kernel Burst Trigger
 + *
 + * Copyright (C) 2013 Joe Xue lg...@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

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 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: pa...@ucw.cz
> To: lg...@hotmail.com
> CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; 
> linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-...@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 majord...@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 majord...@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)

[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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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)

[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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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)

[Geert Uytterhoeven]

On Sat, Dec 28, 2013 at 8:29 PM, Pavel Machek  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 -- ge...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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!

> > 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 majord...@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 Sat, Dec 28, 2013 at 11:16 AM, Pavel Machek  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 -- ge...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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

>> 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   --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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

 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   --
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 Sat, Dec 28, 2013 at 11:16 AM, Pavel Machek pa...@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 -- ge...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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!

  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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 pa...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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)

[Geert Uytterhoeven]

On Sat, Dec 28, 2013 at 8:29 PM, Pavel Machek pa...@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 -- ge...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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)

[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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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)

[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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 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: pa...@ucw.cz
 To: lg...@hotmail.com
 CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; 
 linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; 
 linux-...@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 majord...@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 majord...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 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: pa...@ucw.cz
> To: lg...@hotmail.com
> CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; 
> linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-...@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 majord...@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 majord...@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

[Richard Purdie]

On Fri, 2013-12-27 at 18:13 +, 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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!

> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Fri, Dec 27, 2013 at 7:13 PM, One Thousand Gnomes
 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 -- ge...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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

[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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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

[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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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!

> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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

[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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Fri, Dec 27, 2013 at 1:31 AM, Joe Xue  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 -- ge...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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

[One Thousand Gnomes]

On Wed, 25 Dec 2013 20:02:33 -0500
Joe Xue  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 ?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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!

> 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 majord...@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!

 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 majord...@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

[One Thousand Gnomes]

On Wed, 25 Dec 2013 20:02:33 -0500
Joe Xue lg...@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 ?

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 Fri, Dec 27, 2013 at 1:31 AM, Joe Xue lg...@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 -- ge...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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

[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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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!

  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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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]

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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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

[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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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]

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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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

[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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 Fri, Dec 27, 2013 at 7:13 PM, One Thousand Gnomes
gno...@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 -- ge...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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!

  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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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

[Richard Purdie]

On Fri, 2013-12-27 at 18:13 +, 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

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 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: pa...@ucw.cz
 To: lg...@hotmail.com
 CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; 
 linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; 
 linux-...@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 majord...@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 majord...@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: pa...@ucw.cz
> To: lg...@hotmail.com
> CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; 
> linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-...@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 majord...@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 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: lg...@hotmail.com
> To: pa...@ucw.cz
> CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; 
> linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-...@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: pa...@ucw.cz
>> To: lg...@hotmail.com
>> CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; 
>> milo@ti.com; linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; 
>> linux-...@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 majord...@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 majord...@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 majord...@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 

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 
---
 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 000..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 000..4ba097a
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-burst.c
@@ -0,0 +1,250 @@
+/*
+ * LED Kernel Burst Trigger
+ *
+ * Copyright (C) 2013 Joe Xue 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../leds.h"
+
+struct burst_trig_data {
+   int state;
+   unsigned long freq;

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: pa...@ucw.cz
> To: lg...@hotmail.com
> CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; 
> linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-...@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 majord...@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 majord...@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!

> 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 majord...@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,   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 -- ge...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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!

 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 majord...@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 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: pa...@ucw.cz
 To: lg...@hotmail.com
 CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; 
 linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; 
 linux-...@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 majord...@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 majord...@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 lg...@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 lg...@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 000..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 000..4ba097a
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-burst.c
@@ -0,0 +1,250 @@
+/*
+ * LED Kernel Burst Trigger
+ *
+ * Copyright (C) 2013 Joe Xue lg...@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 

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: lg...@hotmail.com
 To: pa...@ucw.cz
 CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; 
 linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; 
 linux-...@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: pa...@ucw.cz
 To: lg...@hotmail.com
 CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; 
 milo@ti.com; linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; 
 linux-...@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 majord...@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 majord...@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 majord...@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: pa...@ucw.cz
 To: lg...@hotmail.com
 CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; 
 linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; 
 linux-...@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 majord...@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,  lg...@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 -- ge...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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,

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: pa...@ucw.cz
> To: lg...@hotmail.com
> CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; 
> linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-...@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 majord...@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 majord...@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!

> +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 majord...@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!

 +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 majord...@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,

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: pa...@ucw.cz
 To: lg...@hotmail.com
 CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; 
 linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; 
 linux-...@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 majord...@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 majord...@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 

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 
---
 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 000..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 000..95eda2a
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-burst.c
@@ -0,0 +1,250 @@
+/*
+ * LED Kernel Burst Trigger
+ *
+ * Copyright (C) 2013 Joe Xue 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../leds.h"
+
+struct burst_trig_data {
+   int state;
+   unsigned long freq;
+   unsigned long times;
+   unsigned 

[PATCH] Add the LED burst trigger

[lgxue]

From: Joe Xue lg...@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 lg...@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 000..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 000..95eda2a
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-burst.c
@@ -0,0 +1,250 @@
+/*
+ * LED Kernel Burst Trigger
+ *
+ * Copyright (C) 2013 Joe Xue lg...@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