summaryrefslogtreecommitdiffstats
path: root/LED-architecture.md
blob: cc9fdba3c89d39d4063eae8ca61b474846ea787e (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
# LED Support for OpenBMC

This document describes how to add LED support for your machine based upon the
OpenBMC
[LED Architecture](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Led/README.md)
document.  LED group management is done automatically for machines that support
the use of the MRW and is beyond the scope of this document.

## D-Bus

```
Service     xyx.openbmc_project.LED.GroupManager
Path        /xyz/openbmc_project/led/groups/<label>
Interfaces  xyz.openbmc_project.Led.Group

Signals: none
Attribute: Asserted (boolean)
```

## REST

```
PUT /xyz/openbmc_project/led/groups/\<label\>/attr/Asserted
```

The LED group state can be changed by setting the Asserted value to boolean 0 or 1.
In the following example, the lamp_test group is being asserted...
```
 curl -b cjar -k -X PUT -H "Content-Type: application/json" -d '{"data":  1}' \
  https://bmc/xyz/openbmc_project/led/groups/lamp_test/attr/Asserted
```


## Development Details
There are two significant layers for LED operations.  The physical and the
logical.  The LED Group Manager communicates with the physical LED Manager to
drive the physical LEDs.  The logical groups are defined in the machine's
led.yaml file.  LED Group manager consumes this and creates D-Bus/REST
interfaces for the individual LEDs that are part of the group.

### Defining the physical LED

Physical LED wiring is defined in the `leds` section of the machine's
[device tree](https://github.com/openbmc/linux/tree/dev-4.10/arch/arm/boot/dts).
See the
[Palmetto dts](https://github.com/openbmc/linux/blob/dev-4.10/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts#L39)
as an example.

_Add a fault LED to the device tree with a corresponding gpio pin..._
```
  leds {
    compatible = "gpio-leds";

    fault {
      gpios = <&gpio ASPEED_GPIO(N, 2) GPIO_ACTIVE_LOW>;
    };
  }
```

_The kernel will then create..._

```
 ls -l /sys/class/leds/fault/
total 0
-rw-r--r--    1 root     root          4096 Jun 21 20:04 brightness
lrwxrwxrwx    1 root     root             0 Jun 21 20:29 device -> ../../../leds
-r--r--r--    1 root     root          4096 Jun 21 20:29 max_brightness
drwxr-xr-x    2 root     root             0 Jun 21 20:29 power
lrwxrwxrwx    1 root     root             0 Jun 21 20:04 subsystem -> ../../../../../class/leds
-rw-r--r--    1 root     root          4096 Jun 21 20:04 trigger
-rw-r--r--    1 root     root          4096 Jun 21 20:04 uevent
```

### Defining Groups
A LED Group can contain zero or more LEDs and defined in the machines
[led.yaml](https://github.com/openbmc/phosphor-led-manager/blob/master/led.yaml).
The default one will likely need to be tailored to your machines layout.
Customized yaml files are placed into the machines specific Yocto location.  As
an example....

```
meta-openbmc-machines/meta-openpower/meta-ibm/meta-palmetto/recipes-phosphor/leds/palmetto-led-manager-config/led.yaml
```

The parent properties in the yaml file will be created below `/xyz/openbmc_project/led/groups/`.
The children properties need to map to an LED name in `/sys/class/leds`.

In the example, below two URIs would be created:
`/xyz/openbmc_project/led/groups/enclosure_fault` and
`/xyz/openbmc_project/led/groups/lamp_test`.  Both act on the same physical
LED `fault` but do so differently.  The lamp_test would also drive a blink
signal to the physical `power` led if one was created.


```
EnclosureFault:
    fault:
        Action: 'On'
        DutyOn: 50
        Period: 0
lamp_test:
    fault:
        Action: 'Blink'
        DutyOn: 20
        Period: 100
    power:
        Action: 'Blink'
        DutyOn: 20
        Period: 100

```

### Required Groups
OpenBMC Architecture requires specific LED Groups to be created and are
documented in the
[dbus interface](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Led/README.md)


## Yocto packaging
1.  Create a tailored LED manager file

`meta-openbmc-machines/meta-openpower/meta-ibm/meta-romulus/recipes-phosphor/leds/romulus-led-manager-config-native.bb`
```
SUMMARY = "Phosphor LED Group Management for Romulus"
PR = "r1"

inherit native
inherit obmc-phosphor-utils
inherit obmc-phosphor-license

PROVIDES += "virtual/phosphor-led-manager-config-native"

SRC_URI += "file://led.yaml"
S = "${WORKDIR}"

# Overwrites the default led.yaml
do_install() {
    SRC=${S}
    DEST=${D}${datadir}/phosphor-led-manager
    install -D ${SRC}/led.yaml ${DEST}/led.yaml
}
```
2. Change your machine's peferred provider for the led-manager in the conf file

_i.e. meta-openbmc-machines/meta-openpower/meta-ibm/meta-romulus/conf/machine/romulus.conf_

`PREFERRED_PROVIDER_virtual/phosphor-led-manager-config-native = "romulus-led-manager-config-native"`



## Additional Reading
D-Bus Interfaces [Managing LED groups](https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/xyz/openbmc_project/Led/README.md)
OpenPOWER on IntegriCloud