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