AetherDroid/android_kernel_samsung_on5xelte
1
0
Fork 0
mirror of https://github.com/AetherDroid/android_kernel_samsung_on5xelte.git synced 2025-09-05 16:07:46 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Fixed MTP to work with TWRP

Browse source
This commit is contained in:
awab228 2018-06-19 23:16:04 +02:00
commit f6dfaef42e
50820 changed files with 20846062 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

22
Documentation/leds/00-INDEX Normal file
View file

@ -0,0 +1,22 @@
00-INDEX
- This file
leds-blinkm.txt
- Driver for BlinkM LED-devices.
leds-class.txt
- documents LED handling under Linux.
leds-lp3944.txt
- notes on how to use the leds-lp3944 driver.
leds-lp5521.txt
- notes on how to use the leds-lp5521 driver.
leds-lp5523.txt
- notes on how to use the leds-lp5523 driver.
leds-lp5562.txt
- notes on how to use the leds-lp5562 driver.
leds-lp55xx.txt
- description about lp55xx common driver.
leds-lm3556.txt
- notes on how to use the leds-lm3556 driver.
ledtrig-oneshot.txt
- One-shot LED trigger for both sporadic and dense events.
ledtrig-transient.txt
- LED Transient Trigger, one shot timer activation.

80
Documentation/leds/leds-blinkm.txt Normal file
View file

@ -0,0 +1,80 @@
The leds-blinkm driver supports the devices of the BlinkM family.
They are RGB-LED modules driven by a (AT)tiny microcontroller and
communicate through I2C. The default address of these modules is
0x09 but this can be changed through a command. By this you could
dasy-chain up to 127 BlinkMs on an I2C bus.
The device accepts RGB and HSB color values through separate commands.
Also you can store blinking sequences as "scripts" in
the controller and run them. Also fading is an option.
The interface this driver provides is 2-fold:
a) LED class interface for use with triggers
############################################
The registration follows the scheme:
blinkm-<i2c-bus-nr>-<i2c-device-nr>-<color>
$ ls -h /sys/class/leds/blinkm-6-*
/sys/class/leds/blinkm-6-9-blue:
brightness device max_brightness power subsystem trigger uevent
/sys/class/leds/blinkm-6-9-green:
brightness device max_brightness power subsystem trigger uevent
/sys/class/leds/blinkm-6-9-red:
brightness device max_brightness power subsystem trigger uevent
(same is /sys/bus/i2c/devices/6-0009/leds)
We can control the colors separated into red, green and blue and
assign triggers on each color.
E.g.:
$ cat blinkm-6-9-blue/brightness
05
$ echo 200 > blinkm-6-9-blue/brightness
$
$ modprobe ledtrig-heartbeat
$ echo heartbeat > blinkm-6-9-green/trigger
$
b) Sysfs group to control rgb, fade, hsb, scripts ...
#####################################################
This extended interface is available as folder blinkm
in the sysfs folder of the I2C device.
E.g. below /sys/bus/i2c/devices/6-0009/blinkm
$ ls -h /sys/bus/i2c/devices/6-0009/blinkm/
blue green red test
Currently supported is just setting red, green, blue
and a test sequence.
E.g.:
$ cat *
00
00
00
#Write into test to start test sequence!#
$ echo 1 > test
$
$ echo 255 > red
$
as of 6/2012
dl9pf <at> gmx <dot> de

97
Documentation/leds/leds-class.txt Normal file
View file

@ -0,0 +1,97 @@
LED handling under Linux
========================
If you're reading this and thinking about keyboard leds, these are
handled by the input subsystem and the led class is *not* needed.
In its simplest form, the LED class just allows control of LEDs from
userspace. LEDs appear in /sys/class/leds/. The maximum brightness of the
LED is defined in max_brightness file. The brightness file will set the brightness
of the LED (taking a value 0-max_brightness). Most LEDs don't have hardware
brightness support so will just be turned on for non-zero brightness settings.
The class also introduces the optional concept of an LED trigger. A trigger
is a kernel based source of led events. Triggers can either be simple or
complex. A simple trigger isn't configurable and is designed to slot into
existing subsystems with minimal additional code. Examples are the ide-disk,
nand-disk and sharpsl-charge triggers. With led triggers disabled, the code
optimises away.
Complex triggers whilst available to all LEDs have LED specific
parameters and work on a per LED basis. The timer trigger is an example.
The timer trigger will periodically change the LED brightness between
LED_OFF and the current brightness setting. The "on" and "off" time can
be specified via /sys/class/leds/<device>/delay_{on,off} in milliseconds.
You can change the brightness value of a LED independently of the timer
trigger. However, if you set the brightness value to LED_OFF it will
also disable the timer trigger.
You can change triggers in a similar manner to the way an IO scheduler
is chosen (via /sys/class/leds/<device>/trigger). Trigger specific
parameters can appear in /sys/class/leds/<device> once a given trigger is
selected.
Design Philosophy
=================
The underlying design philosophy is simplicity. LEDs are simple devices
and the aim is to keep a small amount of code giving as much functionality
as possible. Please keep this in mind when suggesting enhancements.
LED Device Naming
=================
Is currently of the form:
"devicename:colour:function"
There have been calls for LED properties such as colour to be exported as
individual led class attributes. As a solution which doesn't incur as much
overhead, I suggest these become part of the device name. The naming scheme
above leaves scope for further attributes should they be needed. If sections
of the name don't apply, just leave that section blank.
Hardware accelerated blink of LEDs
==================================
Some LEDs can be programmed to blink without any CPU interaction. To
support this feature, a LED driver can optionally implement the
blink_set() function (see <linux/leds.h>). To set an LED to blinking,
however, it is better to use the API function led_blink_set(), as it
will check and implement software fallback if necessary.
To turn off blinking again, use the API function led_brightness_set()
as that will not just set the LED brightness but also stop any software
timers that may have been required for blinking.
The blink_set() function should choose a user friendly blinking value
if it is called with *delay_on==0 && *delay_off==0 parameters. In this
case the driver should give back the chosen value through delay_on and
delay_off parameters to the leds subsystem.
Setting the brightness to zero with brightness_set() callback function
should completely turn off the LED and cancel the previously programmed
hardware blinking function, if any.
Known Issues
============
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.

85
Documentation/leds/leds-lm3556.txt Normal file
View file

@ -0,0 +1,85 @@
Kernel driver for lm3556
========================
*Texas Instrument:
1.5 A Synchronous Boost LED Flash Driver w/ High-Side Current Source
* Datasheet: http://www.national.com/ds/LM/LM3556.pdf
Authors:
Daniel Jeong
Contact:Daniel Jeong(daniel.jeong-at-ti.com, gshark.jeong-at-gmail.com)
Description
-----------
There are 3 functions in LM3556, Flash, Torch and Indicator.
FLASH MODE
In Flash Mode, the LED current source(LED) provides 16 target current levels
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
* if STROBE pin is enabled, below example control brightness only, and
ON / OFF will be controlled by STROBE pin.
Flash Example:
OFF : #echo 0 > sys/class/leds/flash/brightness
93.75 mA: #echo 1 > sys/class/leds/flash/brightness
... .....
1500 mA: #echo 16 > sys/class/leds/flash/brightness
TORCH MODE
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.
* if TORCH pin is enabled, below example control brightness only,
and ON / OFF will be controlled by TORCH pin.
Torch Example:
OFF : #echo 0 > sys/class/leds/torch/brightness
46.88 mA: #echo 1 > sys/class/leds/torch/brightness
... .....
375 mA : #echo 8 > sys/class/leds/torch/brightness
INDICATOR MODE
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
be generated.If you want new patterns for your own device, change
indicator_pattern array with your own values and INDIC_PATTERN_SIZE.
Please refer datasheet for more detail about N-Blank, Pulse time and N Period.
Indicator pattern example:
pattern 0: #echo 0 > sys/class/leds/indicator/pattern
....
pattern 3: #echo 3 > sys/class/leds/indicator/pattern
Indicator brightness can be controlled through
sys/class/leds/indicator/brightness file.
Example:
OFF : #echo 0 > sys/class/leds/indicator/brightness
5.86 mA : #echo 1 > sys/class/leds/indicator/brightness
........
46.875mA : #echo 8 > sys/class/leds/indicator/brightness
Notes
-----
Driver expects it is registered using the i2c_board_info mechanism.
To register the chip at address 0x63 on specific adapter, set the platform data
according to include/linux/platform_data/leds-lm3556.h, set the i2c board info
Example:
static struct i2c_board_info board_i2c_ch4[] __initdata = {
{
I2C_BOARD_INFO(LM3556_NAME, 0x63),
.platform_data = &lm3556_pdata,
},
};
and register it in the platform init function
Example:
board_register_i2c_bus(4, 400,
board_i2c_ch4, ARRAY_SIZE(board_i2c_ch4));

50
Documentation/leds/leds-lp3944.txt Normal file
View file

@ -0,0 +1,50 @@
Kernel driver lp3944
====================
* National Semiconductor LP3944 Fun-light Chip
Prefix: 'lp3944'
Addresses scanned: None (see the Notes section below)
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LP/LP3944.html
Authors:
Antonio Ospite <ospite@studenti.unina.it>
Description
-----------
The LP3944 is a helper chip that can drive up to 8 leds, with two programmable
DIM modes; it could even be used as a gpio expander but this driver assumes it
is used as a led controller.
The DIM modes are used to set _blink_ patterns for leds, the pattern is
specified supplying two parameters:
- period: from 0s to 1.6s
- duty cycle: percentage of the period the led is on, from 0 to 100
Setting a led in DIM0 or DIM1 mode makes it blink according to the pattern.
See the datasheet for details.
LP3944 can be found on Motorola A910 smartphone, where it drives the rgb
leds, the camera flash light and the lcds power.
Notes
-----
The chip is used mainly in embedded contexts, so this driver expects it is
registered using the i2c_board_info mechanism.
To register the chip at address 0x60 on adapter 0, set the platform data
according to include/linux/leds-lp3944.h, set the i2c board info:
static struct i2c_board_info a910_i2c_board_info[] __initdata = {
{
I2C_BOARD_INFO("lp3944", 0x60),
.platform_data = &a910_lp3944_leds,
},
};
and register it in the platform init function
i2c_register_board_info(0, a910_i2c_board_info,
ARRAY_SIZE(a910_i2c_board_info));

101
Documentation/leds/leds-lp5521.txt Normal file
View file

@ -0,0 +1,101 @@
Kernel driver for lp5521
========================
* National Semiconductor LP5521 led driver chip
* Datasheet: http://www.national.com/pf/LP/LP5521.html
Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo
Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
Description
-----------
LP5521 can drive up to 3 channels. Leds can be controlled directly via
the led class control interface. Channels have generic names:
lp5521:channelx, where x is 0 .. 2
All three channels can be also controlled using the engine micro programs.
More details of the instructions can be found from the public data sheet.
LP5521 has the internal program memory for running various LED patterns.
There are two ways to run LED patterns.
1) Legacy interface - enginex_mode and enginex_load
Control interface for the engines:
x is 1 .. 3
enginex_mode : disabled, load, run
enginex_load : store program (visible only in engine load mode)
Example (start to blink the channel 2 led):
cd /sys/class/leds/lp5521:channel2/device
echo "load" > engine3_mode
echo "037f4d0003ff6000" > engine3_load
echo "run" > engine3_mode
To stop the engine:
echo "disabled" > engine3_mode
2) Firmware interface - LP55xx common interface
For the details, please refer to 'firmware' section in leds-lp55xx.txt
sysfs contains a selftest entry.
The test communicates with the chip and checks that
the clock mode is automatically set to the requested one.
Each channel has its own led current settings.
/sys/class/leds/lp5521:channel0/led_current - RW
/sys/class/leds/lp5521:channel0/max_current - RO
Format: 10x mA i.e 10 means 1.0 mA
example platform data:
Note: chan_nr can have values between 0 and 2.
The name of each channel can be configurable.
If the name field is not defined, the default name will be set to 'xxxx:channelN'
(XXXX : pdata->label or i2c client name, N : channel number)
static struct lp55xx_led_config lp5521_led_config[] = {
{
.name = "red",
.chan_nr = 0,
.led_current = 50,
.max_current = 130,
}, {
.name = "green",
.chan_nr = 1,
.led_current = 0,
.max_current = 130,
}, {
.name = "blue",
.chan_nr = 2,
.led_current = 0,
.max_current = 130,
}
};
static int lp5521_setup(void)
{
/* setup HW resources */
}
static void lp5521_release(void)
{
/* Release HW resources */
}
static void lp5521_enable(bool state)
{
/* Control of chip enable signal */
}
static struct lp55xx_platform_data lp5521_platform_data = {
.led_config = lp5521_led_config,
.num_channels = ARRAY_SIZE(lp5521_led_config),
.clock_mode = LP55XX_CLOCK_EXT,
.setup_resources = lp5521_setup,
.release_resources = lp5521_release,
.enable = lp5521_enable,
};
If the current is set to 0 in the platform data, that channel is
disabled and it is not visible in the sysfs.

100
Documentation/leds/leds-lp5523.txt Normal file
View file

@ -0,0 +1,100 @@
Kernel driver for lp5523
========================
* National Semiconductor LP5523 led driver chip
* Datasheet: http://www.national.com/pf/LP/LP5523.html
Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo
Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
Description
-----------
LP5523 can drive up to 9 channels. Leds can be controlled directly via
the led class control interface.
The name of each channel is configurable in the platform data - name and label.
There are three options to make the channel name.
a) Define the 'name' in the platform data
To make specific channel name, then use 'name' platform data.
/sys/class/leds/R1 (name: 'R1')
/sys/class/leds/B1 (name: 'B1')
b) Use the 'label' with no 'name' field
For one device name with channel number, then use 'label'.
/sys/class/leds/RGB:channelN (label: 'RGB', N: 0 ~ 8)
c) Default
If both fields are NULL, 'lp5523' is used by default.
/sys/class/leds/lp5523:channelN (N: 0 ~ 8)
LP5523 has the internal program memory for running various LED patterns.
There are two ways to run LED patterns.
1) Legacy interface - enginex_mode, enginex_load and enginex_leds
Control interface for the engines:
x is 1 .. 3
enginex_mode : disabled, load, run
enginex_load : microcode load (visible only in load mode)
enginex_leds : led mux control (visible only in load mode)
cd /sys/class/leds/lp5523:channel2/device
echo "load" > engine3_mode
echo "9d80400004ff05ff437f0000" > engine3_load
echo "111111111" > engine3_leds
echo "run" > engine3_mode
To stop the engine:
echo "disabled" > engine3_mode
2) Firmware interface - LP55xx common interface
For the details, please refer to 'firmware' section in leds-lp55xx.txt
Selftest uses always the current from the platform data.
Each channel contains led current settings.
/sys/class/leds/lp5523:channel2/led_current - RW
/sys/class/leds/lp5523:channel2/max_current - RO
Format: 10x mA i.e 10 means 1.0 mA
Example platform data:
Note - chan_nr can have values between 0 and 8.
static struct lp55xx_led_config lp5523_led_config[] = {
{
.name = "D1",
.chan_nr = 0,
.led_current = 50,
.max_current = 130,
},
...
{
.chan_nr = 8,
.led_current = 50,
.max_current = 130,
}
};
static int lp5523_setup(void)
{
/* Setup HW resources */
}
static void lp5523_release(void)
{
/* Release HW resources */
}
static void lp5523_enable(bool state)
{
/* Control chip enable signal */
}
static struct lp55xx_platform_data lp5523_platform_data = {
.led_config = lp5523_led_config,
.num_channels = ARRAY_SIZE(lp5523_led_config),
.clock_mode = LP55XX_CLOCK_EXT,
.setup_resources = lp5523_setup,
.release_resources = lp5523_release,
.enable = lp5523_enable,
};

120
Documentation/leds/leds-lp5562.txt Normal file
View file

@ -0,0 +1,120 @@
Kernel driver for LP5562
========================
* TI LP5562 LED Driver
Author: Milo(Woogyom) Kim <milo.kim@ti.com>
Description
LP5562 can drive up to 4 channels. R/G/B and White.
LEDs can be controlled directly via the led class control interface.
All four channels can be also controlled using the engine micro programs.
LP5562 has the internal program memory for running various LED patterns.
For the details, please refer to 'firmware' section in leds-lp55xx.txt
Device attribute: engine_mux
3 Engines are allocated in LP5562, but the number of channel is 4.
Therefore each channel should be mapped to the engine number.
Value : RGB or W
This attribute is used for programming LED data with the firmware interface.
Unlike the LP5521/LP5523/55231, LP5562 has unique feature for the engine mux,
so additional sysfs is required.
LED Map
Red ... Engine 1 (fixed)
Green ... Engine 2 (fixed)
Blue ... Engine 3 (fixed)
White ... Engine 1 or 2 or 3 (selective)
How to load the program data using engine_mux
Before loading the LP5562 program data, engine_mux should be written between
the engine selection and loading the firmware.
Engine mux has two different mode, RGB and W.
RGB is used for loading RGB program data, W is used for W program data.
For example, run blinking green channel pattern,
echo 2 > /sys/bus/i2c/devices/xxxx/select_engine # 2 is for green channel
echo "RGB" > /sys/bus/i2c/devices/xxxx/engine_mux # engine mux for RGB
echo 1 > /sys/class/firmware/lp5562/loading
echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
echo 0 > /sys/class/firmware/lp5562/loading
echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
To run a blinking white pattern,
echo 1 or 2 or 3 > /sys/bus/i2c/devices/xxxx/select_engine
echo "W" > /sys/bus/i2c/devices/xxxx/engine_mux
echo 1 > /sys/class/firmware/lp5562/loading
echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
echo 0 > /sys/class/firmware/lp5562/loading
echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
How to load the predefined patterns
Please refer to 'leds-lp55xx.txt"
Setting Current of Each Channel
Like LP5521 and LP5523/55231, LP5562 provides LED current settings.
The 'led_current' and 'max_current' are used.
(Example of Platform data)
To configure the platform specific data, lp55xx_platform_data structure is used.
static struct lp55xx_led_config lp5562_led_config[] = {
{
.name = "R",
.chan_nr = 0,
.led_current = 20,
.max_current = 40,
},
{
.name = "G",
.chan_nr = 1,
.led_current = 20,
.max_current = 40,
},
{
.name = "B",
.chan_nr = 2,
.led_current = 20,
.max_current = 40,
},
{
.name = "W",
.chan_nr = 3,
.led_current = 20,
.max_current = 40,
},
};
static int lp5562_setup(void)
{
/* setup HW resources */
}
static void lp5562_release(void)
{
/* Release HW resources */
}
static void lp5562_enable(bool state)
{
/* Control of chip enable signal */
}
static struct lp55xx_platform_data lp5562_platform_data = {
.led_config = lp5562_led_config,
.num_channels = ARRAY_SIZE(lp5562_led_config),
.setup_resources = lp5562_setup,
.release_resources = lp5562_release,
.enable = lp5562_enable,
};
If the current is set to 0 in the platform data, that channel is
disabled and it is not visible in the sysfs.

194
Documentation/leds/leds-lp55xx.txt Normal file
View file

@ -0,0 +1,194 @@
LP5521/LP5523/LP55231/LP5562/LP8501 Common Driver
=================================================
Authors: Milo(Woogyom) Kim <milo.kim@ti.com>
Description
-----------
LP5521, LP5523/55231, LP5562 and LP8501 have common features as below.
Register access via the I2C
Device initialization/deinitialization
Create LED class devices for multiple output channels
Device attributes for user-space interface
Program memory for running LED patterns
The LP55xx common driver provides these features using exported functions.
lp55xx_init_device() / lp55xx_deinit_device()
lp55xx_register_leds() / lp55xx_unregister_leds()
lp55xx_regsister_sysfs() / lp55xx_unregister_sysfs()
( Driver Structure Data )
In lp55xx common driver, two different data structure is used.
o lp55xx_led
control multi output LED channels such as led current, channel index.
o lp55xx_chip
general chip control such like the I2C and platform data.
For example, LP5521 has maximum 3 LED channels.
LP5523/55231 has 9 output channels.
lp55xx_chip for LP5521 ... lp55xx_led #1
lp55xx_led #2
lp55xx_led #3
lp55xx_chip for LP5523 ... lp55xx_led #1
lp55xx_led #2
.
.
lp55xx_led #9
( Chip Dependent Code )
To support device specific configurations, special structure
'lpxx_device_config' is used.
Maximum number of channels
Reset command, chip enable command
Chip specific initialization
Brightness control register access
Setting LED output current
Program memory address access for running patterns
Additional device specific attributes
( Firmware Interface )
LP55xx family devices have the internal program memory for running
various LED patterns.
This pattern data is saved as a file in the user-land or
hex byte string is written into the memory through the I2C.
LP55xx common driver supports the firmware interface.
LP55xx chips have three program engines.
To load and run the pattern, the programming sequence is following.
(1) Select an engine number (1/2/3)
(2) Mode change to load
(3) Write pattern data into selected area
(4) Mode change to run
The LP55xx common driver provides simple interfaces as below.
select_engine : Select which engine is used for running program
run_engine : Start program which is loaded via the firmware interface
firmware : Load program data
In case of LP5523, one more command is required, 'enginex_leds'.
It is used for selecting LED output(s) at each engine number.
In more details, please refer to 'leds-lp5523.txt'.
For example, run blinking pattern in engine #1 of LP5521
echo 1 > /sys/bus/i2c/devices/xxxx/select_engine
echo 1 > /sys/class/firmware/lp5521/loading
echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
echo 0 > /sys/class/firmware/lp5521/loading
echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
For example, run blinking pattern in engine #3 of LP55231
Two LEDs are configured as pattern output channels.
echo 3 > /sys/bus/i2c/devices/xxxx/select_engine
echo 1 > /sys/class/firmware/lp55231/loading
echo "9d0740ff7e0040007e00a0010000" > /sys/class/firmware/lp55231/data
echo 0 > /sys/class/firmware/lp55231/loading
echo "000001100" > /sys/bus/i2c/devices/xxxx/engine3_leds
echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
To start blinking patterns in engine #2 and #3 simultaneously,
for idx in 2 3
do
echo $idx > /sys/class/leds/red/device/select_engine
sleep 0.1
echo 1 > /sys/class/firmware/lp5521/loading
echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
echo 0 > /sys/class/firmware/lp5521/loading
done
echo 1 > /sys/class/leds/red/device/run_engine
Here is another example for LP5523.
Full LED strings are selected by 'engine2_leds'.
echo 2 > /sys/bus/i2c/devices/xxxx/select_engine
echo 1 > /sys/class/firmware/lp5523/loading
echo "9d80400004ff05ff437f0000" > /sys/class/firmware/lp5523/data
echo 0 > /sys/class/firmware/lp5523/loading
echo "111111111" > /sys/bus/i2c/devices/xxxx/engine2_leds
echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
As soon as 'loading' is set to 0, registered callback is called.
Inside the callback, the selected engine is loaded and memory is updated.
To run programmed pattern, 'run_engine' attribute should be enabled.
The pattern sqeuence of LP8501 is similar to LP5523.
However pattern data is specific.
Ex 1) Engine 1 is used
echo 1 > /sys/bus/i2c/devices/xxxx/select_engine
echo 1 > /sys/class/firmware/lp8501/loading
echo "9d0140ff7e0040007e00a001c000" > /sys/class/firmware/lp8501/data
echo 0 > /sys/class/firmware/lp8501/loading
echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
Ex 2) Engine 2 and 3 are used at the same time
echo 2 > /sys/bus/i2c/devices/xxxx/select_engine
sleep 1
echo 1 > /sys/class/firmware/lp8501/loading
echo "9d0140ff7e0040007e00a001c000" > /sys/class/firmware/lp8501/data
echo 0 > /sys/class/firmware/lp8501/loading
sleep 1
echo 3 > /sys/bus/i2c/devices/xxxx/select_engine
sleep 1
echo 1 > /sys/class/firmware/lp8501/loading
echo "9d0340ff7e0040007e00a001c000" > /sys/class/firmware/lp8501/data
echo 0 > /sys/class/firmware/lp8501/loading
sleep 1
echo 1 > /sys/class/leds/d1/device/run_engine
( 'run_engine' and 'firmware_cb' )
The sequence of running the program data is common.
But each device has own specific register addresses for commands.
To support this, 'run_engine' and 'firmware_cb' are configurable in each driver.
run_engine : Control the selected engine
firmware_cb : The callback function after loading the firmware is done.
Chip specific commands for loading and updating program memory.
( Predefined pattern data )
Without the firmware interface, LP55xx driver provides another method for
loading a LED pattern. That is 'predefined' pattern.
A predefined pattern is defined in the platform data and load it(or them)
via the sysfs if needed.
To use the predefined pattern concept, 'patterns' and 'num_patterns' should be
configured.
Example of predefined pattern data:
/* mode_1: blinking data */
static const u8 mode_1[] = {
0x40, 0x00, 0x60, 0x00, 0x40, 0xFF, 0x60, 0x00,
};
/* mode_2: always on */
static const u8 mode_2[] = { 0x40, 0xFF, };
struct lp55xx_predef_pattern board_led_patterns[] = {
{
.r = mode_1,
.size_r = ARRAY_SIZE(mode_1),
},
{
.b = mode_2,
.size_b = ARRAY_SIZE(mode_2),
},
}
struct lp55xx_platform_data lp5562_pdata = {
...
.patterns = board_led_patterns,
.num_patterns = ARRAY_SIZE(board_led_patterns),
};
Then, mode_1 and mode_2 can be run via through the sysfs.
echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern # red blinking LED pattern
echo 2 > /sys/bus/i2c/devices/xxxx/led_pattern # blue LED always on
To stop running pattern,
echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern

59
Documentation/leds/ledtrig-oneshot.txt Normal file
View file

@ -0,0 +1,59 @@
One-shot LED Trigger
====================
This is a LED trigger useful for signaling the user of an event where there are
no clear trap points to put standard led-on and led-off settings. Using this
trigger, the application needs only to signal the trigger when an event has
happened, than the trigger turns the LED on and than keeps it off for a
specified amount of time.
This trigger is meant to be usable both for sporadic and dense events. In the
first case, the trigger produces a clear single controlled blink for each
event, while in the latter it keeps blinking at constant rate, as to signal
that the events are arriving continuously.
A one-shot LED only stays in a constant state when there are no events. An
additional "invert" property specifies if the LED has to stay off (normal) or
on (inverted) when not rearmed.
The trigger can be activated from user space on led class devices as shown
below:
echo oneshot > trigger
This adds the following sysfs attributes to the LED:
delay_on - specifies for how many milliseconds the LED has to stay at
LED_FULL brightness after it has been armed.
Default to 100 ms.
delay_off - specifies for how many milliseconds the LED has to stay at
LED_OFF brightness after it has been armed.
Default to 100 ms.
invert - reverse the blink logic. If set to 0 (default) blink on for delay_on
ms, then blink off for delay_off ms, leaving the LED normally off. If
set to 1, blink off for delay_off ms, then blink on for delay_on ms,
leaving the LED normally on.
Setting this value also immediately change the LED state.
shot - write any non-empty string to signal an events, this starts a blink
sequence if not already running.
Example use-case: network devices, initialization:
echo oneshot > trigger # set trigger for this led
echo 33 > delay_on # blink at 1 / (33 + 33) Hz on continuous traffic
echo 33 > delay_off
interface goes up:
echo 1 > invert # set led as normally-on, turn the led on
packet received/transmitted:
echo 1 > shot # led starts blinking, ignored if already blinking
interface goes down
echo 0 > invert # set led as normally-off, turn the led off

152
Documentation/leds/ledtrig-transient.txt Normal file
View file

@ -0,0 +1,152 @@
LED Transient Trigger
=====================
The leds timer trigger does not currently have an interface to activate
a one shot timer. The current support allows for setting two timers, one for
specifying how long a state to be on, and the second for how long the state
to be off. The delay_on value specifies the time period an LED should stay
in on state, followed by a delay_off value that specifies how long the LED
should stay in off state. The on and off cycle repeats until the trigger
gets deactivated. There is no provision for one time activation to implement
features that require an on or off state to be held just once and then stay in
the original state forever.
Without one shot timer interface, user space can still use timer trigger to
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.
When an led class device driver registers itself, it can specify all leds
triggers it supports and a default trigger. During registration, activation
routine for the default trigger gets called. During registration of an led
class device, the LED state does not change.
When the driver unregisters, deactivation routine for the currently active
trigger will be called, and LED state is changed to LED_OFF.
Driver suspend changes the LED state to LED_OFF and resume doesn't change
the state. Please note that there is no explicit interaction between the
suspend and resume actions and the currently enabled trigger. LED state
changes are suspended while the driver is in suspend state. Any timers
that are active at the time driver gets suspended, continue to run, without
being able to actually change the LED state. Once driver is resumed, triggers
start functioning again.
LED state changes are controlled using brightness which is a common led
class device property. When brightness is set to 0 from user space via
echo 0 > brightness, it will result in deactivating the current trigger.
Transient trigger uses standard register and unregister interfaces. During
trigger registration, for each led class device that specifies this trigger
as its default trigger, trigger activation routine will get called. During
registration, the LED state does not change, unless there is another trigger
active, in which case LED state changes to LED_OFF.
During trigger unregistration, LED state gets changed to LED_OFF.
Transient trigger activation routine doesn't change the LED state. It
creates its properties and does its initialization. Transient trigger
deactivation routine, will cancel any timer that is active before it cleans
up and removes the properties it created. It will restore the LED state to
non-transient state. When driver gets suspended, irrespective of the transient
state, the LED state changes to LED_OFF.
Transient trigger can be enabled and disabled from user space on led class
devices, that support this trigger as shown below:
echo transient > trigger
echo none > trigger
NOTE: Add a new property trigger state to control the state.
This trigger exports three properties, activate, state, and duration. When
transient trigger is activated these properties are set to default values.
- duration allows setting timer value in msecs. The initial value is 0.
- activate allows activating and deactivating the timer specified by
duration as needed. The initial and default value is 0. This will allow
duration to be set after trigger activation.
- state allows user to specify a transient state to be held for the specified
duration.
activate - one shot timer activate mechanism.
1 when activated, 0 when deactivated.
default value is zero when transient trigger is enabled,
to allow duration to be set.
activate state indicates a timer with a value of specified
duration running.
deactivated state indicates that there is no active timer
running.
duration - one shot timer value. When activate is set, duration value
is used to start a timer that runs once. This value doesn't
get changed by the trigger unless user does a set via
echo new_value > duration
state - transient state to be held. It has two values 0 or 1. 0 maps
to LED_OFF and 1 maps to LED_FULL. The specified state is
held for the duration of the one shot timer and then the
state gets changed to the non-transient state which is the
inverse of transient state.
If state = LED_FULL, when the timer runs out the state will
go back to LED_OFF.
If state = LED_OFF, when the timer runs out the state will
go back to LED_FULL.
Please note that current LED state is not checked prior to
changing the state to the specified state.
Driver could map these values to inverted depending on the
default states it defines for the LED in its brightness_set()
interface which is called from the led brightness_set()
interfaces to control the LED state.
When timer expires activate goes back to deactivated state, duration is left
at the set value to be used when activate is set at a future time. This will
allow user app to set the time once and activate it to run it once for the
specified value as needed. When timer expires, state is restored to the
non-transient state which is the inverse of the transient state.
echo 1 > activate - starts timer = duration when duration is not 0.
echo 0 > activate - cancels currently running timer.
echo n > duration - stores timer value to be used upon next
activate. Currently active timer if
any, continues to run for the specified time.
echo 0 > duration - stores timer value to be used upon next
activate. Currently active timer if any,
continues to run for the specified time.
echo 1 > state - stores desired transient state LED_FULL to be
held for the specified duration.
echo 0 > state - stores desired transient state LED_OFF to be
held for the specified duration.
What is not supported:
======================
- Timer activation is one shot and extending and/or shortening the timer
is not supported.
Example use-case 1:
echo transient > trigger
echo n > duration
echo 1 > state
repeat the following step as needed:
echo 1 > activate - start timer = duration to run once
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:
- 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
the LED will be extinguished automatically.
- Use by any user space app that needs a transient GPIO output.