Lines Matching +full:led +full:- +full:2

1 # Physical LED Design Support
4 (Jayashree), [jayashree-d@hcl](mailto:jayashree-d@hcl.com)
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
22 front edge of the board in a grid. The grid will be 2 × rows of 2 × LEDs to
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
29 Based on the current design in phosphor-led-sysfs application, pairing groups
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 +-----------------------------+
42 | |----------->| |-------->| |
43 | LED 1 | Event 2 | | LED 2 | Service 1 : |
44 | |----------->| UDEV |-------->| xyz.openbmc_project. |
45 | LED 2 | ..... | Events | .... | Led.Controller.LED1 |
46 | | ..... | | .... | Service 2 : |
47 | LED 3 | Event N | | LED N | xyz.openbmc_project. |
48 | |----------->| |-------->| Led.Controller.LED2 |
49 | LED 4 | +----------+ | ....... |
53 | ....... | | Led.Controller.LEDN |
54 | | +-----------------------------+
55 | LED N | |
57 +------------+ V
58 +----------------------------------+
63 | Service 2 : |
71 +----------------------------------+
73 PHOSPHSOR-LED-SYSFS DAEMON
77 The existing design uses sysfs entry as udev events for particular LED and
79 that specified service. It exposes one service per LED.
84 busctl tree xyz.openbmc_project.LED.Controller.led1
85 `-/xyz
86 `-/xyz/openbmc_project
87 `-/xyz/openbmc_project/led
88 `-/xyz/openbmc_project/led/physical
89 `-/xyz/openbmc_project/led/physical/led1
91 busctl tree xyz.openbmc_project.LED.Controller.led2
92 `-/xyz
93 `-/xyz/openbmc_project
94 `-/xyz/openbmc_project/led
95 `-/xyz/openbmc_project/led/physical
96 `-/xyz/openbmc_project/led/physical/led2
102 - To support the systemd service to trigger script.
104 - Add DBUS API method for phosphor-led-sysfs daemon.
108 The below diagram represents the overview for proposed physical LED design.
112 KERNEL PHOSPHOR-LED-SYSFS DAEMON
114 +------------+ Event 1 +--------+ +---------+ +--------------+
115 | |----------> | | | | | |
116 | LED 1 | Event 2 | UDEV | | SYSFS | | EXECUTABLE |
117 | |----------> | Events |----->| SERVICE |----->| (DBUS Method |
118 | LED 2 | ..... | | | | | call) |
120 | LED 3 |----------> +--------+ +---------+ +--------------+
123 | LED 4 | +------------------------------------------------------+
124 | | | +-----------+ +---------------------------------+ |
127 | ....... | | | SERVICE | | /xyz/openbmc_project/led/<led1>| |
128 | | | | ( LED. |-->| /xyz/openbmc_project/led/<led2>| |
129 | LED N | | |Controller)| | ..... | |
131 | | | | | | /xyz/openbmc_project/led/<ledN>| |
132 +------------+ | +-----------+ +---------------------------------+ |
133 +------------------------------------------------------+
137 This document proposes a new design for physical LED implementation.
139 - Physical Leds are defined in the device tree under "leds" section and
144 compatible = "gpio-leds";
153 - Dbus API method will be created in the phosphor-led-sysfs repository under
154 **_xyz.openbmc_project.Led.Sysfs.Internal_** interface name to add or remove
155 the LED, which will be coming from each udev LED event.
160 xyz.openbmc_project.Led.Sysfs.Internal interface - - -
161 .AddLED method s - -
162 .RemoveLED method s - -
166 - udev event will be triggered for each LED and service will be invoked to run
167 the executable for each LED event.
169 - Executable will call Dbus API method in the phosphor-led-sysfs repository to
170 pass LED name as argument from udev, after the primary service started.
172 - Phosphor-led-sysfs will have a single systemd service (primary service)
173 **_(xyz.openbmc_project.LED.Controller.service)_** running by default at
176 - Once Dbus API method call invoked, phosphor-led-sysfs daemon will retrieve the
177 LED name as parameter and map the name with /sys/class/leds path in the
179 single systemd service (xyz.openbmc_project.LED.Controller).
181 - The schema will be implemented in the phosphor-led-sysfs daemon. A group of
183 group to activate one LED which must be Blink/ON/OFF state and set the
190 SERVICE xyz.openbmc_project.LED.Controller
192 INTERFACE xyz.openbmc_project.LED.Physical
196 busctl tree xyz.openbmc_project.LED.Controller
197 `-/xyz
198 `-/xyz/openbmc_project
199 `-/xyz/openbmc_project/led
200 `-/xyz/openbmc_project/led/physical
201 `-/xyz/openbmc_project/led/physical/led1
202 `-/xyz/openbmc_project/led/physical/led2
205 `-/xyz/openbmc_project/led/physical/ledN
212 When the udev event is initialized for the LED, it will save those LED names in
213 a file utilizing the script. Phosphor-led-sysfs will monitor the file using
219 udev events and phosphor-led-sysfs application. Since, udev events can be
231 **_xyz.openbmc_project.LED.Controller_** instead of multiple services.
237 **_Manual Test_** - The physical LEDs status will be tested using busctl
240 **_Robot Test_** - The physical LEDs will be tested under robotframework using
243 **_Unit Test_** - The proposed code can be covered by the unit tests which are