| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
|
|
| |
A simpler way to make pattern to trigger immediately is to initialize
blink_next_event to 0 instead of current time value. Save a function
call and convert the code to do just that.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
|
|
| |
The code doesn't seem to be time-sensitive enough to warrant calling
get_time_ns() twice instead of caching its value and using it no both
places.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
|
|
|
| |
The led_poller function blink_func uses for flashing and blinking only the
values 1/0 for setting the leds. In case of an e.g. gpio led this is true. But
in case of pwm driven leds, where someone could dimm the leds, the value of 1
dimms the led. Use the max value for blinking and flashing of a led when enabling.
Signed-off-by: Oleg Karfich <oleg.karfich@wago.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
| |
Signed-off-by: Oleg Karfich <oleg.karfich@wago.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to have a static array of trigger types which, allows only one led
per trigger. While this is enough for panic and heartbeat, it falls short when
multiple leds are associated to the default-on trigger. The default-on trigger
is used to turn on a led statically from devicetree and may be used multiple
times.
This patch reworks the led triggers so that a trigger struct is allocated
dynamically when needed and put onto a list.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
|
|
| |
Since the LED framework now supports blinking/flashing, use this
functionality in the LED triggers.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far blinking/flashing LEDs is only supported on led-trigger level.
Even without triggers it useful to be able to blink/flash LEDs, so
add this functionality to the LED core.
A led_blink_pattern consists of a number of on and off-periods which
are described in an array. Using such an array you can encode nearly
every blink pattern you need.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
|
| |
Free requested GPIOs on unregistration of mono-, bi-, and tri-color
GPIO leds.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
| |
Analog to the other led_unregister prototypes this must take
the LED type specific struct.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
|
|
|
| |
GPIO LEDs can suffer from deferred probing due to failing gpio request.
Instead of registering each gpio led independently, pre-allocate an
array of struct gpio_led for all and tear it down properly if probing
of one leds fails. While at it, silence error messages on -EPROBE_DEFER.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
| |
This patch adds support for the default-state device tree property.
Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
| |
The current code continuously turns leds off. Preserve the current
led status so that we only turn it off once.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
| |
For PWM LEDs '1' may be really dark. Use max_value instead.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|\
| |
| |
| |
| | |
Conflicts:
lib/Makefile
|
| |
| |
| |
| |
| | |
Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Here is compiler's message:
drivers/led/led-triggers.c:148:5: warning: no previous prototype for 'trigger_init' [-Wmissing-prototypes]
int trigger_init(void)
^
Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here is a sample crash log on Ritmix RZX-50:
barebox:/ trigger
0: panic
1: heartbeat
2: net rx
3: net tx
4: net
5: default on (led 0)
barebox:/ trigger -d 5
...
Ooops, TLB miss on store!
Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
| |
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
| |
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
| |
So that other LED drivers can use it.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
|
|
| |
This disables LEDs that have a trigger function assigned right before
the trigger is installed. As the trigger was parsed before the LED has
been registered, also swap LED registration and trigger parsing.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
| |
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
|
| |
This adds a driver option to probe GPIO LEDs from device tree compatible
with "gpio-leds" device tree nodes.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
|
| |
Registering a LED can fail. If someone calls led_set for such
a LED no set function will be there. Fail gracefully in this
case.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
| |
So we can ensure a gpio is not used for something else
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
| |
those led can have 2 colors but one at a time otherwise they are black
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
| |
The FSF address has changed in the past. Instead of updating it
each time the address changes, just drop it completely treewide.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
| |
The LED core itself does not need gpio support, so remove include
so that it compiles on architectures without gpio support.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
|
| |
This patch allows to associate LEDs with certain triggers, such
as heartbeat or network activity.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
|
|
|
| |
This patch adds support for registering gpios as LEDs.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
This patch adds core functionality for controlling LEDs.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|