aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/leds-class.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/leds-class.txt')
-rw-r--r--Documentation/leds-class.txt29
1 files changed, 23 insertions, 6 deletions
diff --git a/Documentation/leds-class.txt b/Documentation/leds-class.txt
index 8c35c0426110..56757c751d6f 100644
--- a/Documentation/leds-class.txt
+++ b/Documentation/leds-class.txt
@@ -39,12 +39,33 @@ LED Device Naming
39 39
40Is currently of the form: 40Is currently of the form:
41 41
42"devicename:colour" 42"devicename:colour:function"
43 43
44There have been calls for LED properties such as colour to be exported as 44There have been calls for LED properties such as colour to be exported as
45individual led class attributes. As a solution which doesn't incur as much 45individual led class attributes. As a solution which doesn't incur as much
46overhead, I suggest these become part of the device name. The naming scheme 46overhead, I suggest these become part of the device name. The naming scheme
47above leaves scope for further attributes should they be needed. 47above leaves scope for further attributes should they be needed. If sections
48of the name don't apply, just leave that section blank.
49
50
51Hardware accelerated blink of LEDs
52==================================
53
54Some LEDs can be programmed to blink without any CPU interaction. To
55support this feature, a LED driver can optionally implement the
56blink_set() function (see <linux/leds.h>). If implemeted, triggers can
57attempt to use it before falling back to software timers. The blink_set()
58function should return 0 if the blink setting is supported, or -EINVAL
59otherwise, which means that LED blinking will be handled by software.
60
61The blink_set() function should choose a user friendly blinking
62value if it is called with *delay_on==0 && *delay_off==0 parameters. In
63this case the driver should give back the chosen value through delay_on
64and delay_off parameters to the leds subsystem.
65
66Any call to the brightness_set() callback function should cancel the
67previously programmed hardware blinking function so setting the brightness
68to 0 can also cancel the blinking of the LED.
48 69
49 70
50Known Issues 71Known Issues
@@ -55,10 +76,6 @@ would cause nightmare dependency issues. I see this as a minor issue
55compared to the benefits the simple trigger functionality brings. The 76compared to the benefits the simple trigger functionality brings. The
56rest of the LED subsystem can be modular. 77rest of the LED subsystem can be modular.
57 78
58Some leds can be programmed to flash in hardware. As this isn't a generic
59LED device property, this should be exported as a device specific sysfs
60attribute rather than part of the class if this functionality is required.
61
62 79
63Future Development 80Future Development
64================== 81==================