u-boot.git/include/led.h, branch master Unnamed repository; edit this file 'description' to name the repository. Merge patch series "led: add function naming option from linux" 2025-02-07T17:39:24+00:00 Tom Rini trini@konsulko.com 2025-02-07T16:53:43+00:00 7a20c89bd05155675bd9f316c4cffc36961f1070 Heiko Schocher <hs@denx.de> says: In linux we have the option to create the name of a led optionally through the following properties: - function - color - function-enumerator This series adds support for parsing this properties if there is no label property. Link: https://lore.kernel.org/r/20250128135246.74838-1-hs@denx.de [trini: Document name parameter in led.h] 
Heiko Schocher <hs@denx.de> says:

In linux we have the option to create the name of a led
optionally through the following properties:

- function
- color
- function-enumerator

This series adds support for parsing this properties if there
is no label property.

Link: https://lore.kernel.org/r/20250128135246.74838-1-hs@denx.de
[trini: Document name parameter in led.h]
led: add function naming option from linux 2025-02-07T16:53:39+00:00 Heiko Schocher hs@denx.de 2025-01-28T13:52:46+00:00 592b6f394aeb2c9eec47a70b7b1fc0e5108cfa90 in linux we have the option to create the name of a led optionally through the following properties: - function - color - function-enumerator This patch adds support for parsing this properties if there is no label property. The led name is created in led_post_bind() and we need some storage place for it. Currently this patch prevents to use malloc() instead it stores the name in new member : char name[LED_MAX_NAME_SIZE]; of struct led_uc_plat. While at it append led tests for the new feature. Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> 
in linux we have the option to create the name of a led
optionally through the following properties:

- function
- color
- function-enumerator

This patch adds support for parsing this properties if there
is no label property.

The led name is created in led_post_bind() and we need some
storage place for it. Currently this patch prevents to use
malloc() instead it stores the name in new member :

        char name[LED_MAX_NAME_SIZE];

of struct led_uc_plat. While at it append led tests for the
new feature.

Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
doc: introduce led.rst documentation 2024-10-10T22:02:20+00:00 Christian Marangi ansuelsmth@gmail.com 2024-10-01T12:24:42+00:00 051c448c8b2a0b0ae9a682b4b1fde35f7a127c77 Introduce simple led.rst documentation to document all the additional Kconfig and the current limitation of LED_BLINK and GPIO software blink. Also add missing definition for sw_blink in led_uc_plat struct. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
Introduce simple led.rst documentation to document all the additional
Kconfig and the current limitation of LED_BLINK and GPIO software blink.

Also add missing definition for sw_blink in led_uc_plat struct.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
led: implement LED activity API 2024-10-10T22:02:20+00:00 Christian Marangi ansuelsmth@gmail.com 2024-10-01T12:24:38+00:00 aad8cfa3ca4b1bb18c4a55d2bbee4f58d3095d64 Implement LED activity API similar to BOOT LED API. Usual activity might be a file transfer with TFTP, a flash write... User of this API will call led_activity_on/off/blink() to signal these kind of activity. New Kconfig is implemented similar to BOOT LED, LED_ACTIVITY to enable support for it. It's introduced a new /options/u-boot property "activity-led" and "activity-led-period" to define the activity LED label and the default period when the activity LED is set to blink mode. If "activity-led-period" is not defined, the value of 250 (ms) is used by default. If CONFIG_LED_BLINK or CONFIG_LED_SW_BLINK is not enabled, led_boot_blink call will fallback to simple LED ON. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
Implement LED activity API similar to BOOT LED API.

Usual activity might be a file transfer with TFTP, a flash write...

User of this API will call led_activity_on/off/blink() to signal these
kind of activity.

New Kconfig is implemented similar to BOOT LED, LED_ACTIVITY to
enable support for it.

It's introduced a new /options/u-boot property "activity-led" and
"activity-led-period" to define the activity LED label and the
default period when the activity LED is set to blink mode.

If "activity-led-period" is not defined, the value of 250 (ms) is
used by default.

If CONFIG_LED_BLINK or CONFIG_LED_SW_BLINK is not enabled,
led_boot_blink call will fallback to simple LED ON.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
led: implement LED boot API 2024-10-10T22:02:20+00:00 Christian Marangi ansuelsmth@gmail.com 2024-10-01T12:24:36+00:00 914fd75a5d2f4cfa7828b48abed50a146063d1bd Implement LED boot API to signal correct boot of the system. led_boot_on/off/blink() are introduced to turn ON, OFF and BLINK the designated boot LED. New Kconfig is introduced, CONFIG_LED_BOOT to enable the feature. This makes use of the /options/u-boot property "boot-led" to the define the boot LED. It's also introduced a new /options/u-boot property "boot-led-period" to define the default period when the LED is set to blink mode. If "boot-led-period" is not defined, the value of 250 (ms) is used by default. If CONFIG_LED_BLINK or CONFIG_LED_SW_BLINK is not enabled, led_boot_blink call will fallback to simple LED ON. To cache the data we repurpose the now unused led_uc_priv for storage of global LED uclass info. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
Implement LED boot API to signal correct boot of the system.

led_boot_on/off/blink() are introduced to turn ON, OFF and BLINK the
designated boot LED.

New Kconfig is introduced, CONFIG_LED_BOOT to enable the feature.
This makes use of the /options/u-boot property "boot-led" to the
define the boot LED.
It's also introduced a new /options/u-boot property "boot-led-period"
to define the default period when the LED is set to blink mode.

If "boot-led-period" is not defined, the value of 250 (ms) is
used by default.

If CONFIG_LED_BLINK or CONFIG_LED_SW_BLINK is not enabled,
led_boot_blink call will fallback to simple LED ON.

To cache the data we repurpose the now unused led_uc_priv for storage of
global LED uclass info.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Merge patch series "led: implement software blinking" 2024-07-30T20:31:24+00:00 Tom Rini trini@konsulko.com 2024-07-30T18:36:22+00:00 8877bc51a8a4d921ba2f163208b8b1a57ba47c18 Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> says: v2 changes: * Drop sw_blink_state structure, move its necessary fields to led_uc_plat structure. * Add cyclic_info pointer to led_uc_plat structure. This simplify code a lot. * Remove cyclic function search logic. Not needed anymore. * Fix blinking period. It was twice large. * Other cleanups. v3 changes: * Adapt code to recent cyclic function changes * Move software blinking functions to separate file * Other small changes v4 changes: * Refactoring of led_set_period() function v5 changes * Fix compilation if CONFIG_LED_BLINK is not defined v6 changes: * Enable LEDST_BLINK state unconditionally. * Function led_set_period() becomes available when CONFIG_LED_BLINK is disabled. This makes led code simpler. * Software blinking requires about 100 bytes of data for a led. It's not a good idea to allocate so much memory for each supported led. Change the code to allocate blinking data only for required leds. 
Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> says:

v2 changes:
 * Drop sw_blink_state structure, move its necessary fields to
   led_uc_plat structure.
 * Add cyclic_info pointer to led_uc_plat structure. This
   simplify code a lot.
 * Remove cyclic function search logic. Not needed anymore.
 * Fix blinking period. It was twice large.
 * Other cleanups.

v3 changes:
 * Adapt code to recent cyclic function changes
 * Move software blinking functions to separate file
 * Other small changes

v4 changes:
 * Refactoring of led_set_period() function

v5 changes
 * Fix compilation if CONFIG_LED_BLINK is not defined

v6 changes:
 * Enable LEDST_BLINK state unconditionally.
 * Function led_set_period() becomes available when CONFIG_LED_BLINK
   is disabled. This makes led code simpler.
 * Software blinking requires about 100 bytes of data for a led. It's
   not a good idea to allocate so much memory for each supported led.
   Change the code to allocate blinking data only for required leds.
led: Implement software led blinking 2024-07-30T18:35:23+00:00 Michael Polyntsov michael.polyntsov@iopsys.eu 2024-07-19T09:12:12+00:00 b557f55e90f087ec310592b833441cd326206f61 If hardware (or driver) doesn't support leds blinking, it's now possible to use software implementation of blinking instead. This relies on cyclic functions. Signed-off-by: Michael Polyntsov <michael.polyntsov@iopsys.eu> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> Reviewed-by: Simon Glass <sjg@chromium.org> 
If hardware (or driver) doesn't support leds blinking, it's
now possible to use software implementation of blinking instead.
This relies on cyclic functions.

Signed-off-by: Michael Polyntsov <michael.polyntsov@iopsys.eu>
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Simon Glass <sjg@chromium.org>
led: enable LEDST_BLINK state unconditionally 2024-07-30T18:35:23+00:00 Mikhail Kshevetskiy mikhail.kshevetskiy@iopsys.eu 2024-07-19T09:12:11+00:00 2a15c676fa3413e7995e2a8b47e8932300e9e70b Changes: * enable LEDST_BLINK state unconditionally * function led_set_period() becomes available when CONFIG_LED_BLINK is disabled. This makes led code simpler. * fix cmd/led.c to work properly when LEDST_BLINK present, but CONFIG_LED_BLINK is disabled Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> Reviewed-by: Simon Glass <sjg@chromium.org> 
Changes:
 * enable LEDST_BLINK state unconditionally
 * function led_set_period() becomes available when CONFIG_LED_BLINK
   is disabled. This makes led code simpler.
 * fix cmd/led.c to work properly when LEDST_BLINK present, but
   CONFIG_LED_BLINK is disabled

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Simon Glass <sjg@chromium.org>
led: introduce led_bind_generic() 2023-12-13T16:35:13+00:00 Rasmus Villemoes rasmus.villemoes@prevas.dk 2023-11-17T11:38:08+00:00 3bf0515a07f7e82f2cdbf435bfd7fcd66651852d All existing drivers in drivers/led/ contain a .bind method that does exactly the same thing, with just the actual driver name differing. Create a helper so all those individual methods can be changed to one-liners. Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> 
All existing drivers in drivers/led/ contain a .bind method that does
exactly the same thing, with just the actual driver name
differing. Create a helper so all those individual methods can be
changed to one-liners.

Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
led: Drop led_default_state() 2022-04-28T13:26:44+00:00 Marek Vasut marex@denx.de 2022-04-22T13:41:42+00:00 69245e406e919012d45d40f045f9b7369086ce17 This function is empty, drop it. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Sean Anderson <seanga2@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Steven Lawrance <steven.lawrance@softathome.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> 
This function is empty, drop it.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Steven Lawrance <steven.lawrance@softathome.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>