| /openbmc/u-boot/drivers/led/ |
| H A D | Kconfig | 1 menu "LED Support"
3 config LED config
4 bool "Enable LED support"
8 U-Boot provides a uclass API to implement this feature. LED drivers
13 bool "LED Support for BCM6328"
14 depends on LED && ARCH_BMIPS
17 LED HW controller accessed via MMIO registers.
20 means that if one LED is set to blink at 100ms and then a different
21 LED is set to blink at 200ms, both will blink at 200ms.
24 bool "LED Support for BCM6358"
[all …]
|
| /openbmc/linux/drivers/leds/ |
| H A D | Kconfig | 10 bool "LED Support"
12 Say Y to enable Linux LED support. This allows control of supported
18 tristate "LED Class Support"
20 This option enables the LED sysfs class in /sys/class/leds. You'll
24 tristate "LED Flash Class Support"
27 This option enables the flash LED sysfs class in /sys/class/leds.
28 It wraps LED Class and adds flash LEDs specific sysfs attributes
30 for the flash related features of a LED device. It can be built
34 tristate "LED Multicolor Class Support"
37 This option enables the multicolor LED sysfs class in /sys/class/leds.
[all …]
|
| H A D | TODO | 9 * Review atomicity requirements in LED subsystem
16 * LED names are still a mess
19 userland. Nudge authors into creating common LED names for common
22 ? Perhaps check for known LED names during boot, and warn if there are
27 The number of drivers is getting big, and driver for on/off LED on a
28 i/o port is really quite different from camera flash LED, which is
29 really different from driver for RGB color LED that can run its own
35 Green-Magenta-Ultraviolet LED, but so far all the LEDs we support are
38 Multicolor is not a good fit for RGB LED. It does not really know
39 about LED color. In particular, there's no way to make LED "white".
[all …]
|
| /openbmc/docs/designs/ |
| H A D | multihost-physical-led.md | 1 # Physical LED Design Support
12 The existing phosphor-led-sysfs design exposes one service per LED configuration
20 For example, Power LED and System Identification LED combines into a single
21 bicolor blue-yellow LED per host. A total of 4 × LEDs will be placed along the
25 Depending on the status of each host, blue or yellow LED needs to be Blink, OFF
26 or ON and other LEDs needs to be in OFF state. Therefore, bi-color LED needs to
30 will be difficult, since it exposes one service per LED. To abstract this method
35 The below diagram represents the overview for current physical LED design.
39 KERNEL META-PHOSPHOR PHOSPHOR-LED-SYSFS SERVICE
41 +------------+ Event 1 +----------+ LED 1 +-----------------------------+
[all …]
|
| H A D | ocp-led-policy-support.md | 1 # OCP LED Policy Support
12 OpenBMC must support the [OCP LED Policy](#background-and-references). Currently
24 | 1 | 1 | LED Priority (cannot represent the fault state) |
35 When for example both of these groups are asserted, the change in LED state will
36 be determined by the LED priority. The result is not allowed in the state
47 Here we pretend that LED Priority "Off" is allowed and discover that it will not
59 #### LED Priority
69 | 0 | 0 | 0 | 1 | LED Priority (for reference) |
78 The different possible LED priorities do not matter here, since "Backup due to
80 LED Priority will prevent it from being applied completely when any other state
[all …]
|
| /openbmc/u-boot/doc/ |
| H A D | README.LED | 1 Status LED
4 This README describes the status LED API.
9 > Device Drivers > LED Support.
11 If the LED support is only for specific board, enable
23 CONFIG_STATUS_LED_BIT is passed into the __led_* functions to identify which LED
25 the other CONFIG_STATUS_LED_BIT's. Mapping the value to a physical LED is the
28 CONFIG_STATUS_LED_STATE is the initial state of the LED. It should be set to one
31 CONFIG_STATUS_LED_FREQ determines the LED blink frequency.
34 Some other LED macros
37 CONFIG_STATUS_LED_BOOT is the LED to light when the board is booting.
[all …]
|
| /openbmc/linux/drivers/leds/flash/ |
| H A D | Kconfig | 6 tristate "LED support for the AAT1290"
15 tristate "AS3645A and LM3555 LED flash controllers support"
19 Enable LED flash class support for AS3645A LED flash
24 tristate "LED support for Kinetic KTD2692 flash LED controller"
28 This option enables support for Kinetic KTD2692 LED flash connected
34 tristate "LED support for LM3601x Chips"
42 tristate "LED support for MAX77693 Flash"
52 tristate "LED Support for Mediatek MT6360 PMIC"
59 This option enables support for dual Flash LED drivers found on
61 Independent current sources supply for each flash LED support torch
[all …]
|
| /openbmc/linux/Documentation/firmware-guide/acpi/dsd/ |
| H A D | leds.rst | 9 device node, the LED driver chip. The "reg" property in the LED specific nodes
10 tells the numerical ID of each individual LED output to which the LEDs are
12 number of the LED output.
24 combination of the LED driver device reference and an integer argument,
25 referring to the "reg" property of the relevant LED, is used to identify
27 firmware and software, it uniquely identifies the LED driver outputs.
29 Under the LED driver device, The first hierarchical data extension package list
30 entry shall contain the string "led@" followed by the number of the LED,
31 followed by the referred object name. That object shall be named "LED" followed
32 by the number of the LED.
[all …]
|
| /openbmc/linux/Documentation/leds/ |
| H A D | leds-class-flash.rst | 2 Flash LED handling under Linux
5 Some LED devices provide two modes - torch and flash. In the LED subsystem
6 those modes are supported by LED class (see Documentation/leds/leds-class.rst)
7 and LED Flash class respectively. The torch mode related features are enabled
12 must be defined in the kernel config. A LED Flash class driver must be
13 registered in the LED subsystem with led_classdev_flash_register function.
15 Following sysfs attributes are exposed for controlling flash LED devices:
29 A LED subsystem driver can be controlled also from the level of VideoForLinux2
39 of_node of the LED, may be NULL if the same as device's
41 LED flash class device to wrap
[all …]
|
| H A D | leds-class.rst | 2 LED handling under Linux
5 In its simplest form, the LED class just allows control of LEDs from
7 LED is defined in max_brightness file. The brightness file will set the brightness
8 of the LED (taking a value 0-max_brightness). Most LEDs don't have hardware
11 The class also introduces the optional concept of an LED trigger. A trigger
18 Complex triggers while available to all LEDs have LED specific
19 parameters and work on a per LED basis. The timer trigger is an example.
20 The timer trigger will periodically change the LED brightness between
23 You can change the brightness value of a LED independently of the timer
41 LED Device Naming
[all …]
|
| H A D | leds-class-multicolor.rst | 4 Multicolor LED handling under Linux
17 array. These files are children under the LED parent node created by the
21 Each colored LED will be indexed under the multi_* files. The order of the
30 order for the color LED intensities to be updated.
42 The brightness level for each LED is calculated based on the color LED
50 for each LED that are necessary to achieve a certain color output from a
51 multicolor LED group.
68 The user can control the brightness of that multicolor LED group by writing the
70 may want to dim the LED color group to half. The user would write a value of
71 128 to the global brightness file then the values written to each LED will be
[all …]
|
| H A D | ledtrig-usbport.rst | 2 USB port LED trigger
5 This LED trigger can be used for signalling to the user a presence of USB device
6 in a given port. It simply turns on LED when device appears and turns it off
14 LED.
18 1) Device with single USB LED and few physical ports
21 In such a case LED will be turned on as long as there is at least one connected
29 only one LED user will most likely want to assign ports from all 3 hubs.
37 This adds sysfs attributes to the LED that are documented in:
|
| /openbmc/linux/Documentation/ABI/testing/ |
| H A D | sysfs-class-led-trigger-netdev | 13 Specifies the duration of the LED blink in milliseconds.
28 If set to 0 (default), the LED's normal state is off.
30 If set to 1, the LED's normal state reflects the link state
32 Setting this value also immediately changes the LED state.
42 If set to 0 (default), the LED will not blink on transmission.
44 If set to 1, the LED will blink for the milliseconds specified
57 If set to 0 (default), the LED will not blink on reception.
59 If set to 1, the LED will blink for the milliseconds specified
70 Communicate whether the LED trigger modes are offloaded to
73 If 0, the LED is using software fallback to blink.
[all …]
|
| /openbmc/qemu/docs/interop/ |
| H A D | vnc-ledstate-pseudo-encoding.rst | 1 VNC LED state Pseudo-encoding
7 This document describes the Pseudo-encoding of LED state for RFB which
13 between the lock keys notification LED on the computer running the VNC
17 To solve this problem it attempts to add LED state Pseudo-encoding
18 extension to VNC protocol to deal with setting LED state.
24 LED state extensions to the protocol.
26 The Pseudo-encoding number for LED state defined as:
31 -261 'LED state Pseudo-encoding'
34 LED state Pseudo-encoding
37 The LED state Pseudo-encoding describes the encoding of LED state which
[all …]
|
| /openbmc/docs/architecture/ |
| H A D | LED-architecture.md | 1 # LED Support for OpenBMC
3 This document describes how to add LED support for your machine based upon the
4 OpenBMC [LED Architecture][led d-bus readme] document. LED group management is
11 Service xyx.openbmc_project.LED.GroupManager
25 The LED group state can be changed by setting the Asserted value to boolean 0
39 resource. This is for LED Identify operation only.
42 to LED Group D-Bus object, namely:
48 All applicable LED Group D-Bus objects would have an association mapping to
73 mapping to LED Group D-Bus object, namely;
79 All applicable LED Group D-Bus objects would have an association mapping to
[all …]
|
| /openbmc/linux/drivers/leds/trigger/ |
| H A D | Kconfig | 3 bool "LED Trigger support"
13 tristate "LED Timer Trigger"
16 via sysfs. Some LED hardware can be programmed to start
17 blinking the LED without any further software interaction.
23 tristate "LED One-shot Trigger"
28 or on dense events, where this blinks the LED at constant rate if
36 bool "LED Disk Trigger"
43 bool "LED MTD (NAND/NOR) Trigger"
50 tristate "LED Heartbeat Trigger"
58 tristate "LED backlight Trigger"
[all …]
|
| /openbmc/linux/Documentation/userspace-api/media/v4l/ |
| H A D | ext-ctrls-flash.rst | 13 The interface can support both LED and xenon flash devices. As of
23 Unsynchronised LED flash (software strobe)
26 Unsynchronised LED flash is controlled directly by the host as the
34 Synchronised LED flash (hardware strobe)
37 The synchronised LED flash is pre-programmed by the host (power and
45 LED flash as torch
48 LED flash may be used as torch in conjunction with another use case
61 Defines the mode of the flash LED, the high-power white LED attached
84 Defines the source of the flash LED strobe.
121 Intensity of the flash strobe when the flash LED is in flash mode
[all …]
|
| /openbmc/openbmc-test-automation/gui/test/server_control/ |
| H A D | test_obmc_gui_server_led.robot | 3 Documentation Test OpenBMC GUI "Server LED" sub-menu of "Server control".
19 Verify Existence Of All Sections In Server LED Page
20 [Documentation] Verify existence of all sections in Server LED page.
23 Page Should Contain LED light control
24 Page Should Contain Server LED light
27 Verify Existence Of All Buttons In Server LED Page
28 [Documentation] Verify existence of all buttons in Server LED page.
43 Wait Until Page Contains Server LED
|
| /openbmc/openbmc-test-automation/redfish/systems/ |
| H A D | test_led_indicator_asserted.robot | 22 Verify LED Lamp Test Asserted At Standby
23 [Documentation] Verify the LED asserted at standby is set to off or blinking.
25 [Template] Set and Verify Lamp LED Indicator
32 Verify LED Lamp Test Asserted At Runtime
33 [Documentation] Verify the LED asserted at runtime is set to off or blinking.
35 [Template] Set and Verify Lamp LED Indicator
42 Verify LED Power Supply Units Asserted At Standby
45 [Template] Set and Verify LED Indicator
52 Verify LED Power Supply Units Asserted At Runtime
55 [Template] Set and Verify LED Indicator
[all …]
|
| /openbmc/u-boot/doc/device-tree-bindings/leds/ |
| H A D | leds-gpio.txt | 6 Each LED is represented as a sub-node of the gpio-leds device. Each
7 node's name represents the name of the corresponding LED.
9 LED sub-node properties:
10 - gpios : Should specify the LED's GPIO, see "gpios property" in
17 - default-state: (optional) The initial state of the LED. Valid
18 values are "on", "off", and "keep". If the LED is already on or off
20 glitch should be produced where the LED momentarily turns off (or
21 on). The "keep" setting will keep the LED at whatever its current
37 /* Keep LED on if BIOS detected hardware fault */
|
| H A D | common.txt | 4 - label : The label for this LED. If omitted, the label is
8 string defining the trigger assigned to the LED. Current triggers are:
9 "backlight" - LED will act as a back-light, controlled by the framebuffer
11 "default-on" - LED will turn on (but for leds-gpio see "default-state"
13 "heartbeat" - LED "double" flashes at a load average based rate
14 "ide-disk" - LED indicates disk activity
15 "timer" - LED flashes at a fixed, configurable rate
|
| /openbmc/phosphor-led-manager/ |
| H A D | README.md | 3 This project manages LED groups on dbus. Sometimes many LEDs must be driven
13 ### Configuration: LED Priority
15 Each LED can have "Priority" as "Blink", "Off" or "On". If this property is
16 defined, it should be defined on each instance of the LED in the config.
18 When multiple LED groups are asserted and contain the same LED, "Priority"
19 determines the state of the LED.
24 ## Configuration: LED Group Priority
26 Using LED Priority is fine for simple configurations, but when group state needs
127 When starting the program, our LED group shows up on dbus. Usually there will be
131 $ busctl tree xyz.openbmc_project.LED.GroupManager
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Led/ |
| H A D | README.md | 1 # Managing LED groups and physical LEDs through BMC
9 ## Understanding LED groups
11 While it is entirely possible to act directly on a physical LED, it makes hard
12 when more than one LED is to be acted on for a particular usecase.
15 LED upon reaching some state. However, some other systems may have a requirement
26 requirement of blinking system Enclosure LED indicating an internal problem:
29 that system before acting on it. In one case, the LED group may consist of DIMM
30 LED + Enclosure Fault LED. However, if the DIMM is attached to a Raiser card,
31 then the LED group may consist of DIMM LED + Raise card LED + Enclosure Fault
32 LED. Defining this path will make it easier to locate the box and the exact part
[all …]
|
| /openbmc/linux/Documentation/devicetree/bindings/leds/ |
| H A D | leds-ns2.txt | 1 Binding for dual-GPIO LED found on Network Space v2 (and parents).
6 Each LED is represented as a sub-node of the ns2-leds device.
9 - cmd-gpio: Command LED GPIO. See OF device-tree GPIO specification.
10 - slow-gpio: Slow LED GPIO. See OF device-tree GPIO specification.
11 - modes-map: A mapping between LED modes (off, on or SATA activity blinking) and
16 - label: Name for this LED. If omitted, the label is taken from the node name.
17 - linux,default-trigger: Trigger assigned to the LED.
|
| H A D | leds-mt6323.txt | 1 Device Tree Bindings for LED support on MT6323 PMIC
3 MT6323 LED controller is subfunction provided by MT6323 PMIC, so the LED
23 describes the initial behavior for each LED physically and currently only four
24 LED child nodes can be supported.
26 Required properties for the LED child node:
27 - reg : LED channel number (0..3)
29 Optional properties for the LED child node:
|