diff options
Diffstat (limited to 'Documentation/leds')
| -rw-r--r-- | Documentation/leds/index.rst | 3 | ||||
| -rw-r--r-- | Documentation/leds/leds-class-multicolor.rst | 86 | ||||
| -rw-r--r-- | Documentation/leds/leds-class.rst | 10 | ||||
| -rw-r--r-- | Documentation/leds/leds-el15203000.rst | 140 | ||||
| -rw-r--r-- | Documentation/leds/leds-lm3556.rst | 28 | ||||
| -rw-r--r-- | Documentation/leds/leds-qcom-lpg.rst | 78 | ||||
| -rw-r--r-- | Documentation/leds/leds-sc27xx.rst | 27 | ||||
| -rw-r--r-- | Documentation/leds/ledtrig-transient.rst | 9 | ||||
| -rw-r--r-- | Documentation/leds/well-known-leds.txt | 72 |
9 files changed, 421 insertions, 32 deletions
diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst index 060f4e485897..e5d63b940045 100644 --- a/Documentation/leds/index.rst +++ b/Documentation/leds/index.rst @@ -9,6 +9,7 @@ LEDs leds-class leds-class-flash + leds-class-multicolor ledtrig-oneshot ledtrig-transient ledtrig-usbport @@ -16,6 +17,7 @@ LEDs uleds leds-blinkm + leds-el15203000 leds-lm3556 leds-lp3944 leds-lp5521 @@ -23,3 +25,4 @@ LEDs leds-lp5562 leds-lp55xx leds-mlxcpld + leds-sc27xx diff --git a/Documentation/leds/leds-class-multicolor.rst b/Documentation/leds/leds-class-multicolor.rst new file mode 100644 index 000000000000..c57b98bfd387 --- /dev/null +++ b/Documentation/leds/leds-class-multicolor.rst @@ -0,0 +1,86 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================================== +Multicolor LED handling under Linux +==================================== + +Description +=========== +The multicolor class groups monochrome LEDs and allows controlling two +aspects of the final combined color: hue and lightness. The former is +controlled via the multi_intensity array file and the latter is controlled +via brightness file. + +Multicolor Class Control +======================== +The multicolor class presents files that groups the colors as indexes in an +array. These files are children under the LED parent node created by the +led_class framework. The led_class framework is documented in led-class.rst +within this documentation directory. + +Each colored LED will be indexed under the multi_* files. The order of the +colors will be arbitrary. The multi_index file can be read to determine the +color name to indexed value. + +The multi_index file is an array that contains the string list of the colors as +they are defined in each multi_* array file. + +The multi_intensity is an array that can be read or written to for the +individual color intensities. All elements within this array must be written in +order for the color LED intensities to be updated. + +Directory Layout Example +======================== +root:/sys/class/leds/multicolor:status# ls -lR +-rw-r--r-- 1 root root 4096 Oct 19 16:16 brightness +-r--r--r-- 1 root root 4096 Oct 19 16:16 max_brightness +-r--r--r-- 1 root root 4096 Oct 19 16:16 multi_index +-rw-r--r-- 1 root root 4096 Oct 19 16:16 multi_intensity + +Multicolor Class Brightness Control +=================================== +The brightness level for each LED is calculated based on the color LED +intensity setting divided by the global max_brightness setting multiplied by +the requested brightness. + +led_brightness = brightness * multi_intensity/max_brightness + +Example: +A user first writes the multi_intensity file with the brightness levels +for each LED that are necessary to achieve a certain color output from a +multicolor LED group. + +cat /sys/class/leds/multicolor:status/multi_index +green blue red + +echo 43 226 138 > /sys/class/leds/multicolor:status/multi_intensity + +red - + intensity = 138 + max_brightness = 255 +green - + intensity = 43 + max_brightness = 255 +blue - + intensity = 226 + max_brightness = 255 + +The user can control the brightness of that multicolor LED group by writing the +global 'brightness' control. Assuming a max_brightness of 255 the user +may want to dim the LED color group to half. The user would write a value of +128 to the global brightness file then the values written to each LED will be +adjusted base on this value. + +cat /sys/class/leds/multicolor:status/max_brightness +255 +echo 128 > /sys/class/leds/multicolor:status/brightness + +adjusted_red_value = 128 * 138/255 = 69 +adjusted_green_value = 128 * 43/255 = 21 +adjusted_blue_value = 128 * 226/255 = 113 + +Reading the global brightness file will return the current brightness value of +the color LED group. + +cat /sys/class/leds/multicolor:status/brightness +128 diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst index a0708d3f3d0b..cd155ead8703 100644 --- a/Documentation/leds/leds-class.rst +++ b/Documentation/leds/leds-class.rst @@ -177,13 +177,3 @@ The LED Trigger core cannot be a module as the simple trigger functions would cause nightmare dependency issues. I see this as a minor issue compared to the benefits the simple trigger functionality brings. The rest of the LED subsystem can be modular. - - -Future Development -================== - -At the moment, a trigger can't be created specifically for a single LED. -There are a number of cases where a trigger might only be mappable to a -particular LED (ACPI?). The addition of triggers provided by the LED driver -should cover this option and be possible to add without breaking the -current interface. diff --git a/Documentation/leds/leds-el15203000.rst b/Documentation/leds/leds-el15203000.rst new file mode 100644 index 000000000000..12c23d79724d --- /dev/null +++ b/Documentation/leds/leds-el15203000.rst @@ -0,0 +1,140 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================== +Kernel driver for Crane EL15203000 +================================== + +/sys/class/leds/<led>/hw_pattern +-------------------------------- + +Specify a hardware pattern for the EL15203000 LED. + +The LEDs board supports only predefined patterns by firmware +for specific LEDs. + +Breathing mode for Screen frame light tube:: + + "0 4000 1 4000" + + ^ + | + Max-| --- + | / \ + | / \ + | / \ / + | / \ / + Min-|- --- + | + 0------4------8--> time (sec) + +Cascade mode for Pipe LED:: + + "1 800 2 800 4 800 8 800 16 800" + + ^ + | + 0 On -|----+ +----+ +--- + | | | | | + Off-| +-------------------+ +-------------------+ + | + 1 On -| +----+ +----+ + | | | | | + Off |----+ +-------------------+ +------------------ + | + 2 On -| +----+ +----+ + | | | | | + Off-|---------+ +-------------------+ +------------- + | + 3 On -| +----+ +----+ + | | | | | + Off-|--------------+ +-------------------+ +-------- + | + 4 On -| +----+ +----+ + | | | | | + Off-|-------------------+ +-------------------+ +--- + | + 0---0.8--1.6--2.4--3.2---4---4.8--5.6--6.4--7.2---8--> time (sec) + +Inverted cascade mode for Pipe LED:: + + "30 800 29 800 27 800 23 800 15 800" + + ^ + | + 0 On -| +-------------------+ +-------------------+ + | | | | | + Off-|----+ +----+ +--- + | + 1 On -|----+ +-------------------+ +------------------ + | | | | | + Off | +----+ +----+ + | + 2 On -|---------+ +-------------------+ +------------- + | | | | | + Off-| +----+ +----+ + | + 3 On -|--------------+ +-------------------+ +-------- + | | | | | + Off-| +----+ +----+ + | + 4 On -|-------------------+ +-------------------+ +--- + | | | | | + Off-| +----+ +----+ + | + 0---0.8--1.6--2.4--3.2---4---4.8--5.6--6.4--7.2---8--> time (sec) + +Bounce mode for Pipe LED:: + + "1 800 2 800 4 800 8 800 16 800 16 800 8 800 4 800 2 800 1 800" + + ^ + | + 0 On -|----+ +-------- + | | | + Off-| +---------------------------------------+ + | + 1 On -| +----+ +----+ + | | | | | + Off |----+ +-----------------------------+ +-------- + | + 2 On -| +----+ +----+ + | | | | | + Off-|---------+ +-------------------+ +------------- + | + 3 On -| +----+ +----+ + | | | | | + Off-|--------------+ +---------+ +------------------ + | + 4 On -| +---------+ + | | | + Off-|-------------------+ +----------------------- + | + 0---0.8--1.6--2.4--3.2---4---4.8--5.6--6.4--7.2---8--> time (sec) + +Inverted bounce mode for Pipe LED:: + + "30 800 29 800 27 800 23 800 15 800 15 800 23 800 27 800 29 800 30 800" + + ^ + | + 0 On -| +---------------------------------------+ + | | | + Off-|----+ +-------- + | + 1 On -|----+ +-----------------------------+ +-------- + | | | | | + Off | +----+ +----+ + | + 2 On -|---------+ +-------------------+ +------------- + | | | | | + Off-| +----+ +----+ + | + 3 On -|--------------+ +---------+ +------------------ + | | | | | + Off-| +----+ +----+ + | + 4 On -|-------------------+ +----------------------- + | | | + Off-| +---------+ + | + 0---0.8--1.6--2.4--3.2---4---4.8--5.6--6.4--7.2---8--> time (sec) diff --git a/Documentation/leds/leds-lm3556.rst b/Documentation/leds/leds-lm3556.rst index 1ef17d7d800e..32e3983473ba 100644 --- a/Documentation/leds/leds-lm3556.rst +++ b/Documentation/leds/leds-lm3556.rst @@ -23,7 +23,7 @@ from 93.75 mA to 1500 mA.The Flash currents are adjusted via the CURRENT CONTROL REGISTER(0x09).Flash mode is activated by the ENABLE REGISTER(0x0A), or by pulling the STROBE pin HIGH. -LM3556 Flash can be controlled through sys/class/leds/flash/brightness file +LM3556 Flash can be controlled through /sys/class/leds/flash/brightness file * if STROBE pin is enabled, below example control brightness only, and ON / OFF will be controlled by STROBE pin. @@ -32,17 +32,17 @@ Flash Example: OFF:: - #echo 0 > sys/class/leds/flash/brightness + #echo 0 > /sys/class/leds/flash/brightness 93.75 mA:: - #echo 1 > sys/class/leds/flash/brightness + #echo 1 > /sys/class/leds/flash/brightness ... 1500 mA:: - #echo 16 > sys/class/leds/flash/brightness + #echo 16 > /sys/class/leds/flash/brightness Torch Mode ^^^^^^^^^^ @@ -51,7 +51,7 @@ In Torch Mode, the current source(LED) is programmed via the CURRENT CONTROL REGISTER(0x09).Torch Mode is activated by the ENABLE REGISTER(0x0A) or by the hardware TORCH input. -LM3556 torch can be controlled through sys/class/leds/torch/brightness file. +LM3556 torch can be controlled through /sys/class/leds/torch/brightness file. * if TORCH pin is enabled, below example control brightness only, and ON / OFF will be controlled by TORCH pin. @@ -59,22 +59,22 @@ Torch Example: OFF:: - #echo 0 > sys/class/leds/torch/brightness + #echo 0 > /sys/class/leds/torch/brightness 46.88 mA:: - #echo 1 > sys/class/leds/torch/brightness + #echo 1 > /sys/class/leds/torch/brightness ... 375 mA:: - #echo 8 > sys/class/leds/torch/brightness + #echo 8 > /sys/class/leds/torch/brightness Indicator Mode ^^^^^^^^^^^^^^ -Indicator pattern can be set through sys/class/leds/indicator/pattern file, +Indicator pattern can be set through /sys/class/leds/indicator/pattern file, and 4 patterns are pre-defined in indicator_pattern array. According to N-lank, Pulse time and N Period values, different pattern wiill @@ -87,13 +87,13 @@ Indicator pattern example: pattern 0:: - #echo 0 > sys/class/leds/indicator/pattern + #echo 0 > /sys/class/leds/indicator/pattern ... pattern 3:: - #echo 3 > sys/class/leds/indicator/pattern + #echo 3 > /sys/class/leds/indicator/pattern Indicator brightness can be controlled through sys/class/leds/indicator/brightness file. @@ -102,17 +102,17 @@ Example: OFF:: - #echo 0 > sys/class/leds/indicator/brightness + #echo 0 > /sys/class/leds/indicator/brightness 5.86 mA:: - #echo 1 > sys/class/leds/indicator/brightness + #echo 1 > /sys/class/leds/indicator/brightness ... 46.875mA:: - #echo 8 > sys/class/leds/indicator/brightness + #echo 8 > /sys/class/leds/indicator/brightness Notes ----- diff --git a/Documentation/leds/leds-qcom-lpg.rst b/Documentation/leds/leds-qcom-lpg.rst new file mode 100644 index 000000000000..de7ceead9337 --- /dev/null +++ b/Documentation/leds/leds-qcom-lpg.rst @@ -0,0 +1,78 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================== +Kernel driver for Qualcomm LPG +============================== + +Description +----------- + +The Qualcomm LPG can be found in a variety of Qualcomm PMICs and consists of a +number of PWM channels, a programmable pattern lookup table and a RGB LED +current sink. + +To facilitate the various use cases, the LPG channels can be exposed as +individual LEDs, grouped together as RGB LEDs or otherwise be accessed as PWM +channels. The output of each PWM channel is routed to other hardware +blocks, such as the RGB current sink, GPIO pins etc. + +The each PWM channel can operate with a period between 27us and 384 seconds and +has a 9 bit resolution of the duty cycle. + +In order to provide support for status notifications with the CPU subsystem in +deeper idle states the LPG provides pattern support. This consists of a shared +lookup table of brightness values and per channel properties to select the +range within the table to use, the rate and if the pattern should repeat. + +The pattern for a channel can be programmed using the "pattern" trigger, using +the hw_pattern attribute. + +/sys/class/leds/<led>/hw_pattern +-------------------------------- + +Specify a hardware pattern for a Qualcomm LPG LED. + +The pattern is a series of brightness and hold-time pairs, with the hold-time +expressed in milliseconds. The hold time is a property of the pattern and must +therefor be identical for each element in the pattern (except for the pauses +described below). As the LPG hardware is not able to perform the linear +transitions expected by the leds-trigger-pattern format, each entry in the +pattern must be followed a zero-length entry of the same brightness. + +Simple pattern:: + + "255 500 255 0 0 500 0 0" + + ^ + | + 255 +----+ +----+ + | | | | ... + 0 | +----+ +---- + +----------------------> + 0 5 10 15 time (100ms) + +The LPG supports specifying a longer hold-time for the first and last element +in the pattern, the so called "low pause" and "high pause". + +Low-pause pattern:: + + "255 1000 255 0 0 500 0 0 255 500 255 0 0 500 0 0" + + ^ + | + 255 +--------+ +----+ +----+ +--------+ + | | | | | | | | ... + 0 | +----+ +----+ +----+ +---- + +-----------------------------> + 0 5 10 15 20 25 time (100ms) + +Similarily, the last entry can be stretched by using a higher hold-time on the +last entry. + +In order to save space in the shared lookup table the LPG supports "ping-pong" +mode, in which case each run through the pattern is performed by first running +the pattern forward, then backwards. This mode is automatically used by the +driver when the given pattern is a palindrome. In this case the "high pause" +denotes the wait time before the pattern is run in reverse and as such the +specified hold-time of the middle item in the pattern is allowed to have a +different hold-time. diff --git a/Documentation/leds/leds-sc27xx.rst b/Documentation/leds/leds-sc27xx.rst new file mode 100644 index 000000000000..6bdf6ba3c9fd --- /dev/null +++ b/Documentation/leds/leds-sc27xx.rst @@ -0,0 +1,27 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================== +Kernel driver for Spreadtrum SC27XX +=================================== + +/sys/class/leds/<led>/hw_pattern +-------------------------------- + +Specify a hardware pattern for the SC27XX LED. For the SC27XX +LED controller, it only supports 4 stages to make a single +hardware pattern, which is used to configure the rise time, +high time, fall time and low time for the breathing mode. + +For the breathing mode, the SC27XX LED only expects one brightness +for the high stage. To be compatible with the hardware pattern +format, we should set brightness as 0 for rise stage, fall +stage and low stage. + +- Min stage duration: 125 ms +- Max stage duration: 31875 ms + +Since the stage duration step is 125 ms, the duration should be +a multiplier of 125, like 125ms, 250ms, 375ms, 500ms ... 31875ms. + +Thus the format of the hardware pattern values should be: +"0 rise_duration brightness high_duration 0 fall_duration 0 low_duration". diff --git a/Documentation/leds/ledtrig-transient.rst b/Documentation/leds/ledtrig-transient.rst index d921dc830cd0..63072f310660 100644 --- a/Documentation/leds/ledtrig-transient.rst +++ b/Documentation/leds/ledtrig-transient.rst @@ -17,12 +17,6 @@ set a timer to hold a state, however when user space application crashes or goes away without deactivating the timer, the hardware will be left in that state permanently. -As a specific example of this use-case, let's look at vibrate feature on -phones. Vibrate function on phones is implemented using PWM pins on SoC or -PMIC. There is a need to activate one shot timer to control the vibrate -feature, to prevent user space crashes leaving the phone in vibrate mode -permanently causing the battery to drain. - Transient trigger addresses the need for one shot timer activation. The transient trigger can be enabled and disabled just like the other leds triggers. @@ -157,9 +151,8 @@ repeat the following step as needed:: echo 1 > activate - start timer = duration to run once echo none > trigger -This trigger is intended to be used for for the following example use cases: +This trigger is intended to be used for the following example use cases: - - Control of vibrate (phones, tablets etc.) hardware by user space app. - Use of LED by user space app as activity indicator. - Use of LED by user space app as a kind of watchdog indicator -- as long as the app is alive, it can keep the LED illuminated, if it dies diff --git a/Documentation/leds/well-known-leds.txt b/Documentation/leds/well-known-leds.txt new file mode 100644 index 000000000000..2160382c86be --- /dev/null +++ b/Documentation/leds/well-known-leds.txt @@ -0,0 +1,72 @@ +-*- org -*- + +It is somehow important to provide consistent interface to the +userland. LED devices have one problem there, and that is naming of +directories in /sys/class/leds. It would be nice if userland would +just know right "name" for given LED function, but situation got more +complex. + +Anyway, if backwards compatibility is not an issue, new code should +use one of the "good" names from this list, and you should extend the +list where applicable. + +Legacy names are listed, too; in case you are writing application that +wants to use particular feature, you should probe for good name, first, +but then try the legacy ones, too. + +Notice there's a list of functions in include/dt-bindings/leds/common.h . + +* Gamepads and joysticks + +Game controllers may feature LEDs to indicate a player number. This is commonly +used on game consoles in which multiple controllers can be connected to a system. +The "player LEDs" are then programmed with a pattern to indicate a particular +player. For example, a game controller with 4 LEDs, may be programmed with "x---" +to indicate player 1, "-x--" to indicate player 2 etcetera where "x" means on. +Input drivers can utilize the LED class to expose the individual player LEDs +of a game controller using the function "player". +Note: tracking and management of Player IDs is the responsibility of user space, +though drivers may pick a default value. + +Good: "input*:*:player-{1,2,3,4,5} + +* Keyboards + +Good: "input*:*:capslock" +Good: "input*:*:scrolllock" +Good: "input*:*:numlock" +Legacy: "shift-key-light" (Motorola Droid 4, capslock) + +Set of common keyboard LEDs, going back to PC AT or so. + +Legacy: "tpacpi::thinklight" (IBM/Lenovo Thinkpads) +Legacy: "lp5523:kb{1,2,3,4,5,6}" (Nokia N900) + +Frontlight/backlight of main keyboard. + +Legacy: "button-backlight" (Motorola Droid 4) + +Some phones have touch buttons below screen; it is different from main +keyboard. And this is their backlight. + +* Sound subsystem + +Good: "platform:*:mute" +Good: "platform:*:micmute" + +LEDs on notebook body, indicating that sound input / output is muted. + +* System notification + +Legacy: "status-led:{red,green,blue}" (Motorola Droid 4) +Legacy: "lp5523:{r,g,b}" (Nokia N900) + +Phones usually have multi-color status LED. + +* Power management + +Good: "platform:*:charging" (allwinner sun50i) + +* Screen + +Good: ":backlight" (Motorola Droid 4) |