summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2018-10-23 08:55:03 +0100
committerLinus Torvalds <torvalds@linux-foundation.org>2018-10-23 08:55:03 +0100
commit6fd577cd4b257ce5cb761adcdedeea55501d84d9 (patch)
tree017101c3dd83b6173031eac9a57f8498d0258419 /Documentation
parent114b5f8f7efc036dd7dd16efb0f218a88e6c6c02 (diff)
parent8dbac65f5c181e4723586ab738b703bb23bc3f2a (diff)
downloadlinux-6fd577cd4b257ce5cb761adcdedeea55501d84d9.tar.bz2
Merge tag 'leds-for-4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
Pull LED updates from Jacek Anaszewski: "We introduce LED pattern trigger - the idea that was proposed three years ago now received enough attention and determination to drive it to the successful end. There is also one new LED class driver and couple of improvements to the existing ones. New LED class driver: - add support for Panasonic AN30259A with related DT bindings New LED trigger: - introduce LED pattern trigger leds-sc27xx-bltc: - implement pattern_set/clear ops to enable support for pattern trigger's hw_pattern sysfs file Improvements to existing LED class drivers: - leds-pwm: don't print error message on -EPROBE_DEFER - leds-gpio: try to lookup gpiod from device - leds-as3645a: convert to using %pOFn instead of device_node.name" * tag 'leds-for-4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds: leds: sc27xx: Add pattern_set/clear interfaces for LED controller leds: core: Introduce LED pattern trigger leds: add Panasonic AN30259A support dt-bindings: leds: document Panasonic AN30259A bindings leds: gpio: Try to lookup gpiod from device leds: pwm: silently error out on EPROBE_DEFER leds: Convert to using %pOFn instead of device_node.name
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/ABI/testing/sysfs-class-led-driver-sc27xx22
-rw-r--r--Documentation/ABI/testing/sysfs-class-led-trigger-pattern82
-rw-r--r--Documentation/devicetree/bindings/leds/leds-an30259a.txt43
3 files changed, 147 insertions, 0 deletions
diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
new file mode 100644
index 000000000000..45b1e605d355
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
@@ -0,0 +1,22 @@
+What: /sys/class/leds/<led>/hw_pattern
+Date: September 2018
+KernelVersion: 4.20
+Description:
+ 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/ABI/testing/sysfs-class-led-trigger-pattern b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
new file mode 100644
index 000000000000..fb3d1e03b881
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
@@ -0,0 +1,82 @@
+What: /sys/class/leds/<led>/pattern
+Date: September 2018
+KernelVersion: 4.20
+Description:
+ Specify a software pattern for the LED, that supports altering
+ the brightness for the specified duration with one software
+ timer. It can do gradual dimming and step change of brightness.
+
+ The pattern is given by a series of tuples, of brightness and
+ duration (ms). The LED is expected to traverse the series and
+ each brightness value for the specified duration. Duration of
+ 0 means brightness should immediately change to new value, and
+ writing malformed pattern deactivates any active one.
+
+ 1. For gradual dimming, the dimming interval now is set as 50
+ milliseconds. So the tuple with duration less than dimming
+ interval (50ms) is treated as a step change of brightness,
+ i.e. the subsequent brightness will be applied without adding
+ intervening dimming intervals.
+
+ The gradual dimming format of the software pattern values should be:
+ "brightness_1 duration_1 brightness_2 duration_2 brightness_3
+ duration_3 ...". For example:
+
+ echo 0 1000 255 2000 > pattern
+
+ It will make the LED go gradually from zero-intensity to max (255)
+ intensity in 1000 milliseconds, then back to zero intensity in 2000
+ milliseconds:
+
+ LED brightness
+ ^
+ 255-| / \ / \ /
+ | / \ / \ /
+ | / \ / \ /
+ | / \ / \ /
+ 0-| / \/ \/
+ +---0----1----2----3----4----5----6------------> time (s)
+
+ 2. To make the LED go instantly from one brigntess value to another,
+ we should use use zero-time lengths (the brightness must be same as
+ the previous tuple's). So the format should be:
+ "brightness_1 duration_1 brightness_1 0 brightness_2 duration_2
+ brightness_2 0 ...". For example:
+
+ echo 0 1000 0 0 255 2000 255 0 > pattern
+
+ It will make the LED stay off for one second, then stay at max brightness
+ for two seconds:
+
+ LED brightness
+ ^
+ 255-| +---------+ +---------+
+ | | | | |
+ | | | | |
+ | | | | |
+ 0-| -----+ +----+ +----
+ +---0----1----2----3----4----5----6------------> time (s)
+
+What: /sys/class/leds/<led>/hw_pattern
+Date: September 2018
+KernelVersion: 4.20
+Description:
+ Specify a hardware pattern for the LED, for LED hardware that
+ supports autonomously controlling brightness over time, according
+ to some preprogrammed hardware patterns. It deactivates any active
+ software pattern.
+
+ Since different LED hardware can have different semantics of
+ hardware patterns, each driver is expected to provide its own
+ description for the hardware patterns in their ABI documentation
+ file.
+
+What: /sys/class/leds/<led>/repeat
+Date: September 2018
+KernelVersion: 4.20
+Description:
+ Specify a pattern repeat number. -1 means repeat indefinitely,
+ other negative numbers and number 0 are invalid.
+
+ This file will always return the originally written repeat
+ number.
diff --git a/Documentation/devicetree/bindings/leds/leds-an30259a.txt b/Documentation/devicetree/bindings/leds/leds-an30259a.txt
new file mode 100644
index 000000000000..6ffb861083c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-an30259a.txt
@@ -0,0 +1,43 @@
+* Panasonic AN30259A 3-channel LED driver
+
+The AN30259A is a LED controller capable of driving three LEDs independently. It supports
+constant current output and sloping current output modes. The chip is connected over I2C.
+
+Required properties:
+ - compatible: Must be "panasonic,an30259a".
+ - reg: I2C slave address.
+ - #address-cells: Must be 1.
+ - #size-cells: Must be 0.
+
+Each LED is represented as a sub-node of the panasonic,an30259a node.
+
+Required sub-node properties:
+ - reg: Pin that the LED is connected to. Must be 1, 2, or 3.
+
+Optional sub-node properties:
+ - label: see Documentation/devicetree/bindings/leds/common.txt
+ - linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+led-controller@30 {
+ compatible = "panasonic,an30259a";
+ reg = <0x30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ linux,default-trigger = "heartbeat";
+ label = "red:indicator";
+ };
+
+ led@2 {
+ reg = <2>;
+ label = "green:indicator";
+ };
+
+ led@3 {
+ reg = <3>;
+ label = "blue:indicator";
+ };
+};