From 2f230f300497f695bec65439b20df3293eabf889 Mon Sep 17 00:00:00 2001 From: Dan Murphy Date: Mon, 6 May 2019 14:16:09 -0500 Subject: dt-bindings: mfd: LMU: Add the ramp up/down property Document the ramp-up and ramp-down property in the binding. Removing the "sec" from the property definition as seconds is implied. Signed-off-by: Dan Murphy Reviewed-by: Rob Herring Acked-by: Lee Jones Signed-off-by: Jacek Anaszewski --- Documentation/devicetree/bindings/mfd/ti-lmu.txt | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt b/Documentation/devicetree/bindings/mfd/ti-lmu.txt index 86ca786d54fc..160eb0a5e21a 100644 --- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt @@ -23,8 +23,14 @@ Required properties: 0x36 for LM3633, LM3697 0x63 for LM3695 -Optional property: +Optional properties: - enable-gpios: A GPIO specifier for hardware enable pin. + - ramp-up-us: Current ramping from one brightness level to + the a higher brightness level. + Range from 2048 us - 117.44 s + - ramp-down-us: Current ramping from one brightness level to + the a lower brightness level. + Range from 2048 us - 117.44 s Required node: - backlight: All LMU devices have backlight child nodes. @@ -90,7 +96,7 @@ lm3631@29 { lcd_bl { led-sources = <0 1>; - ramp-up-msec = <300>; + ramp-up-us = <300000>; }; }; }; @@ -152,15 +158,15 @@ lm3633@36 { main { label = "main_lcd"; led-sources = <1 2>; - ramp-up-msec = <500>; - ramp-down-msec = <500>; + ramp-up-us = <500000>; + ramp-down-us = <500000>; }; front { label = "front_lcd"; led-sources = <0>; - ramp-up-msec = <1000>; - ramp-down-msec = <0>; + ramp-up-us = <1000000>; + ramp-down-us = <0>; }; }; @@ -212,8 +218,8 @@ lm3697@36 { lcd { led-sources = <0 1 2>; - ramp-up-msec = <200>; - ramp-down-msec = <200>; + ramp-up-us = <200000>; + ramp-down-us = <200000>; }; }; -- cgit v1.2.3 From d0147554d004e7cc427f6cfecf871916e34e8b67 Mon Sep 17 00:00:00 2001 From: Dan Murphy Date: Mon, 6 May 2019 14:16:10 -0500 Subject: dt-bindings: mfd: LMU: Add ti,brightness-resolution Add ti,brightness-resolution to the TI LMU binding to define whether the device uses 8-bit brightness or 11-bit brightness. Signed-off-by: Dan Murphy Reviewed-by: Rob Herring Signed-off-by: Jacek Anaszewski --- Documentation/devicetree/bindings/mfd/ti-lmu.txt | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt b/Documentation/devicetree/bindings/mfd/ti-lmu.txt index 160eb0a5e21a..e3efefb194c5 100644 --- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt @@ -31,6 +31,16 @@ Optional properties: - ramp-down-us: Current ramping from one brightness level to the a lower brightness level. Range from 2048 us - 117.44 s + - ti,brightness-resolution - This determines whether to use 8 bit brightness + mode or 11 bit brightness mode. If this value is + not set the device is defaulted to the preferred + 8bit brightness mode per 7.3.4.1 of the data + sheet. This setting can either be in the parent + node or as part of the LED child nodes. This + is determined by the part itself if the strings + have a common brightness register or individual + brightness registers. + The values are 255 (8bit) or 2047 (11bit). Required node: - backlight: All LMU devices have backlight child nodes. @@ -217,6 +227,7 @@ lm3697@36 { compatible = "ti,lm3697-backlight"; lcd { + ti,brightness-resolution = <255>; led-sources = <0 1 2>; ramp-up-us = <200000>; ramp-down-us = <200000>; -- cgit v1.2.3 From e7c787cb2697ee4c101109bf21b4fc397cea150b Mon Sep 17 00:00:00 2001 From: Christian Mauderer Date: Mon, 13 May 2019 21:33:06 +0200 Subject: dt-bindings: leds: Add binding for spi-byte LED. This patch adds the binding documentation for a simple SPI based LED controller which use only one byte for setting the brightness. Signed-off-by: Christian Mauderer Reviewed-by: Rob Herring Signed-off-by: Jacek Anaszewski --- .../devicetree/bindings/leds/leds-spi-byte.txt | 44 ++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-spi-byte.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/leds-spi-byte.txt b/Documentation/devicetree/bindings/leds/leds-spi-byte.txt new file mode 100644 index 000000000000..28b6b2d9091e --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-spi-byte.txt @@ -0,0 +1,44 @@ +* Single Byte SPI LED Device Driver. + +The driver can be used for controllers with a very simple SPI protocol: +- one LED is controlled by a single byte on MOSI +- the value of the byte gives the brightness between two values (lowest to + highest) +- no return value is necessary (no MISO signal) + +The value for lowest and highest brightness is dependent on the device and +therefore on the compatible string. + +Depending on the compatible string some special functions (like hardware +accelerated blinking) might can be supported too. + +The driver currently only supports one LED. The properties of the LED are +configured in a sub-node in the device node. + +Required properties: +- compatible: should be one of + * "ubnt,acb-spi-led" microcontroller (SONiX 8F26E611LA) based device + used for example in Ubiquiti airCube ISP + +Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt +apply. + +LED sub-node properties: +- label: + see Documentation/devicetree/bindings/leds/common.txt +- default-state: + see Documentation/devicetree/bindings/leds/common.txt + Only "on" and "off" are supported. + +Example: + +led-controller@0 { + compatible = "ubnt,acb-spi-led"; + reg = <0>; + spi-max-frequency = <100000>; + + led { + label = "white:status"; + default-state = "on"; + }; +}; -- cgit v1.2.3 From 1372bbe66a59528e65d10ae67416835d3ec2452e Mon Sep 17 00:00:00 2001 From: Dan Murphy Date: Mon, 6 May 2019 14:16:12 -0500 Subject: dt-bindings: ti-lmu: Modify dt bindings for the LM3697 The LM3697 is a single function LED driver. The single function LED driver needs to reside in the LED directory as a dedicated LED driver and not as a MFD device. The device does have common brightness and ramp features and those can be accomodated by a TI LMU framework. The LM3697 dt binding needs to be moved from the ti-lmu.txt and a dedicated LED dt binding needs to be added. The new LM3697 LED dt binding will then reside in the Documentation/devicetree/bindings/leds directory and follow the current LED and general bindings guidelines. Signed-off-by: Dan Murphy Reviewed-by: Rob Herring Acked-by: Lee Jones Signed-off-by: Jacek Anaszewski --- .../devicetree/bindings/leds/leds-lm3697.txt | 73 ++++++++++++++++++++++ Documentation/devicetree/bindings/mfd/ti-lmu.txt | 27 +------- 2 files changed, 74 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3697.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/leds-lm3697.txt b/Documentation/devicetree/bindings/leds/leds-lm3697.txt new file mode 100644 index 000000000000..63992d732959 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-lm3697.txt @@ -0,0 +1,73 @@ +* Texas Instruments - LM3697 Highly Efficient White LED Driver + +The LM3697 11-bit LED driver provides high- +performance backlight dimming for 1, 2, or 3 series +LED strings while delivering up to 90% efficiency. + +This device is suitable for display and keypad lighting + +Required properties: + - compatible: + "ti,lm3697" + - reg : I2C slave address + - #address-cells : 1 + - #size-cells : 0 + +Optional properties: + - enable-gpios : GPIO pin to enable/disable the device + - vled-supply : LED supply + +Required child properties: + - reg : 0 - LED is Controlled by bank A + 1 - LED is Controlled by bank B + - led-sources : Indicates which HVLED string is associated to which + control bank. This is a zero based property so + HVLED1 = 0, HVLED2 = 1, HVLED3 = 2. + Additional information is contained + in Documentation/devicetree/bindings/leds/common.txt + +Optional child properties: + - ti,brightness-resolution - see Documentation/devicetree/bindings/mfd/ti-lmu.txt + - ramp-up-us: see Documentation/devicetree/bindings/mfd/ti-lmu.txt + - ramp-down-us: see Documentation/devicetree/bindings/mfd/ti-lmu.txt + - label : see Documentation/devicetree/bindings/leds/common.txt + - linux,default-trigger : + see Documentation/devicetree/bindings/leds/common.txt + +Example: + +HVLED string 1 and 3 are controlled by control bank A and HVLED 2 string is +controlled by control bank B. + +led-controller@36 { + compatible = "ti,lm3697"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x36>; + + enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>; + vled-supply = <&vbatt>; + + led@0 { + reg = <0>; + led-sources = <0 2>; + ti,brightness-resolution = <2047>; + ramp-up-us = <5000>; + ramp-down-us = <1000>; + label = "white:first_backlight_cluster"; + linux,default-trigger = "backlight"; + }; + + led@1 { + reg = <1>; + led-sources = <1>; + ti,brightness-resolution = <255>; + ramp-up-us = <500>; + ramp-down-us = <1000>; + label = "white:second_backlight_cluster"; + linux,default-trigger = "backlight"; + }; +} + +For more product information please see the link below: +http://www.ti.com/lit/ds/symlink/lm3697.pdf diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt b/Documentation/devicetree/bindings/mfd/ti-lmu.txt index e3efefb194c5..782d3c9812ed 100644 --- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt @@ -8,7 +8,6 @@ TI LMU driver supports lighting devices below. LM3632 Backlight and regulator LM3633 Backlight, LED and fault monitor LM3695 Backlight - LM3697 Backlight and fault monitor Required properties: - compatible: Should be one of: @@ -16,11 +15,10 @@ Required properties: "ti,lm3632" "ti,lm3633" "ti,lm3695" - "ti,lm3697" - reg: I2C slave address. 0x11 for LM3632 0x29 for LM3631 - 0x36 for LM3633, LM3697 + 0x36 for LM3633 0x63 for LM3695 Optional properties: @@ -51,7 +49,6 @@ Optional nodes: Required properties: - compatible: Should be one of: "ti,lm3633-fault-monitor" - "ti,lm3697-fault-monitor" - leds: LED properties for LM3633. Please refer to [2]. - regulators: Regulator properties for LM3631 and LM3632. Please refer to [3]. @@ -216,25 +213,3 @@ lm3695@63 { }; }; }; - -lm3697@36 { - compatible = "ti,lm3697"; - reg = <0x36>; - - enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>; - - backlight { - compatible = "ti,lm3697-backlight"; - - lcd { - ti,brightness-resolution = <255>; - led-sources = <0 1 2>; - ramp-up-us = <200000>; - ramp-down-us = <200000>; - }; - }; - - fault-monitor { - compatible = "ti,lm3697-fault-monitor"; - }; -}; -- cgit v1.2.3 From 4665743276c3e8efaa4da54eabe8f54b2f99e335 Mon Sep 17 00:00:00 2001 From: Dan Murphy Date: Wed, 5 Jun 2019 07:56:30 -0500 Subject: dt-bindings: mfd: Add lm36274 bindings to ti-lmu Add the LM36274 backlight driver with regulator support. This is a multi-function device for backlight applications. Backlight properties will be documented in it's a supplemental bindings document. Regulator support is documented in the regulator/lm363x-regulator.txt http://www.ti.com/lit/ds/symlink/lm36274.pdf Signed-off-by: Dan Murphy Reviewed-by: Rob Herring Acked-by: Lee Jones Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski --- Documentation/devicetree/bindings/mfd/ti-lmu.txt | 54 ++++++++++++++++++++++++ 1 file changed, 54 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt b/Documentation/devicetree/bindings/mfd/ti-lmu.txt index 782d3c9812ed..2296b8f24de4 100644 --- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt @@ -8,6 +8,7 @@ TI LMU driver supports lighting devices below. LM3632 Backlight and regulator LM3633 Backlight, LED and fault monitor LM3695 Backlight + LM36274 Backlight and regulator Required properties: - compatible: Should be one of: @@ -15,11 +16,13 @@ Required properties: "ti,lm3632" "ti,lm3633" "ti,lm3695" + "ti,lm36274" - reg: I2C slave address. 0x11 for LM3632 0x29 for LM3631 0x36 for LM3633 0x63 for LM3695 + 0x11 for LM36274 Optional properties: - enable-gpios: A GPIO specifier for hardware enable pin. @@ -50,12 +53,14 @@ Optional nodes: - compatible: Should be one of: "ti,lm3633-fault-monitor" - leds: LED properties for LM3633. Please refer to [2]. + LED properties for LM36274. Please refer to [4]. - regulators: Regulator properties for LM3631 and LM3632. Please refer to [3]. [1] ../leds/backlight/ti-lmu-backlight.txt [2] ../leds/leds-lm3633.txt [3] ../regulator/lm363x-regulator.txt +[4] ../leds/leds-lm36274.txt lm3631@29 { compatible = "ti,lm3631"; @@ -213,3 +218,52 @@ lm3695@63 { }; }; }; + +lm36274@11 { + compatible = "ti,lm36274"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x11>; + + enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>; + regulators { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,lm363x-regulator"; + + enable-gpios = <&pioC 0 GPIO_ACTIVE_HIGH>, + <&pioC 1 GPIO_ACTIVE_HIGH>; + + vboost { + regulator-name = "lcd_boost"; + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <7150000>; + regulator-always-on; + }; + + vpos { + regulator-name = "lcd_vpos"; + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <6500000>; + }; + + vneg { + regulator-name = "lcd_vneg"; + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <6500000>; + }; + }; + + backlight { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,lm36274-backlight"; + + led@0 { + reg = <0>; + led-sources = <0 2>; + label = "white:backlight_cluster"; + linux,default-trigger = "backlight"; + }; + }; +}; -- cgit v1.2.3 From 04f4dc1bc5f0f64640026497f97e2f3c063f7831 Mon Sep 17 00:00:00 2001 From: Dan Murphy Date: Wed, 5 Jun 2019 07:56:33 -0500 Subject: dt-bindings: leds: Add LED bindings for the LM36274 Add the LM36274 LED specific bindings. Signed-off-by: Dan Murphy Reviewed-by: Rob Herring Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski --- .../devicetree/bindings/leds/leds-lm36274.txt | 85 ++++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-lm36274.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/leds-lm36274.txt b/Documentation/devicetree/bindings/leds/leds-lm36274.txt new file mode 100644 index 000000000000..456a589c65f0 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-lm36274.txt @@ -0,0 +1,85 @@ +* Texas Instruments LM36274 4-Channel LCD Backlight Driver w/Integrated Bias + +The LM36274 is an integrated four-channel WLED driver and LCD bias supply. +The backlight boost provides the power to bias four parallel LED strings with +up to 29V total output voltage. The 11-bit LED current is programmable via +the I2C bus and/or controlled via a logic level PWM input from 60 uA to 30 mA. + +Parent device properties are documented in +Documentation/devicetree/bindings/mfd/ti_lmu.txt + +Regulator properties are documented in +Documentation/devicetree/bindings/regulator/lm363x-regulator.txt + +Required backlight properties: + - compatible: + "ti,lm36274-backlight" + - reg : 0 + - #address-cells : 1 + - #size-cells : 0 + - led-sources : Indicates which LED strings will be enabled. + Values from 0-3, sources is 0 based so strings will be + source value + 1. + +Optional backlight properties: + - label : see Documentation/devicetree/bindings/leds/common.txt + - linux,default-trigger : + see Documentation/devicetree/bindings/leds/common.txt + +Example: + +HVLED string 1 and 3 are controlled by control bank A and HVLED 2 string is +controlled by control bank B. + +lm36274@11 { + compatible = "ti,lm36274"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x11>; + + enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>; + + regulators { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,lm363x-regulator"; + + enable-gpios = <&pioC 0 GPIO_ACTIVE_HIGH>, + <&pioC 1 GPIO_ACTIVE_HIGH>; + + vboost { + regulator-name = "lcd_boost"; + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <7150000>; + regulator-always-on; + }; + + vpos { + regulator-name = "lcd_vpos"; + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <6500000>; + }; + + vneg { + regulator-name = "lcd_vneg"; + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <6500000>; + }; + }; + + backlight { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,lm36274-backlight"; + + led@0 { + reg = <0>; + led-sources = <0 2>; + label = "white:backlight_cluster"; + linux,default-trigger = "backlight"; + }; + }; +}; + +For more product information please see the link below: +http://www.ti.com/lit/ds/symlink/lm36274.pdf -- cgit v1.2.3 From 8dab91970a8c01ffc7816bf8a4c4cd587b481f34 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 28 Jun 2019 09:20:20 -0300 Subject: docs: leds: convert to ReST Rename the leds documentation files to ReST, add an index for them and adjust in order to produce a nice html output via the Sphinx build system. At its new index.rst, let's add a :orphan: while this is not linked to the main index.rst file, in order to avoid build warnings. Signed-off-by: Mauro Carvalho Chehab Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski --- Documentation/laptops/thinkpad-acpi.txt | 4 +- Documentation/leds/index.rst | 25 ++++ Documentation/leds/leds-blinkm.rst | 84 ++++++++++++ Documentation/leds/leds-blinkm.txt | 80 ----------- Documentation/leds/leds-class-flash.rst | 90 +++++++++++++ Documentation/leds/leds-class-flash.txt | 73 ---------- Documentation/leds/leds-class.rst | 125 +++++++++++++++++ Documentation/leds/leds-class.txt | 122 ----------------- Documentation/leds/leds-lm3556.rst | 137 +++++++++++++++++++ Documentation/leds/leds-lm3556.txt | 85 ------------ Documentation/leds/leds-lp3944.rst | 59 ++++++++ Documentation/leds/leds-lp3944.txt | 50 ------- Documentation/leds/leds-lp5521.rst | 115 ++++++++++++++++ Documentation/leds/leds-lp5521.txt | 101 -------------- Documentation/leds/leds-lp5523.rst | 147 ++++++++++++++++++++ Documentation/leds/leds-lp5523.txt | 130 ------------------ Documentation/leds/leds-lp5562.rst | 137 +++++++++++++++++++ Documentation/leds/leds-lp5562.txt | 120 ----------------- Documentation/leds/leds-lp55xx.rst | 224 +++++++++++++++++++++++++++++++ Documentation/leds/leds-lp55xx.txt | 194 -------------------------- Documentation/leds/leds-mlxcpld.rst | 118 ++++++++++++++++ Documentation/leds/leds-mlxcpld.txt | 110 --------------- Documentation/leds/ledtrig-oneshot.rst | 44 ++++++ Documentation/leds/ledtrig-oneshot.txt | 43 ------ Documentation/leds/ledtrig-transient.rst | 167 +++++++++++++++++++++++ Documentation/leds/ledtrig-transient.txt | 152 --------------------- Documentation/leds/ledtrig-usbport.rst | 46 +++++++ Documentation/leds/ledtrig-usbport.txt | 41 ------ Documentation/leds/uleds.rst | 37 +++++ Documentation/leds/uleds.txt | 36 ----- MAINTAINERS | 2 +- drivers/leds/trigger/Kconfig | 2 +- drivers/leds/trigger/ledtrig-transient.c | 2 +- net/netfilter/Kconfig | 2 +- 34 files changed, 1561 insertions(+), 1343 deletions(-) create mode 100644 Documentation/leds/index.rst create mode 100644 Documentation/leds/leds-blinkm.rst delete mode 100644 Documentation/leds/leds-blinkm.txt create mode 100644 Documentation/leds/leds-class-flash.rst delete mode 100644 Documentation/leds/leds-class-flash.txt create mode 100644 Documentation/leds/leds-class.rst delete mode 100644 Documentation/leds/leds-class.txt create mode 100644 Documentation/leds/leds-lm3556.rst delete mode 100644 Documentation/leds/leds-lm3556.txt create mode 100644 Documentation/leds/leds-lp3944.rst delete mode 100644 Documentation/leds/leds-lp3944.txt create mode 100644 Documentation/leds/leds-lp5521.rst delete mode 100644 Documentation/leds/leds-lp5521.txt create mode 100644 Documentation/leds/leds-lp5523.rst delete mode 100644 Documentation/leds/leds-lp5523.txt create mode 100644 Documentation/leds/leds-lp5562.rst delete mode 100644 Documentation/leds/leds-lp5562.txt create mode 100644 Documentation/leds/leds-lp55xx.rst delete mode 100644 Documentation/leds/leds-lp55xx.txt create mode 100644 Documentation/leds/leds-mlxcpld.rst delete mode 100644 Documentation/leds/leds-mlxcpld.txt create mode 100644 Documentation/leds/ledtrig-oneshot.rst delete mode 100644 Documentation/leds/ledtrig-oneshot.txt create mode 100644 Documentation/leds/ledtrig-transient.rst delete mode 100644 Documentation/leds/ledtrig-transient.txt create mode 100644 Documentation/leds/ledtrig-usbport.rst delete mode 100644 Documentation/leds/ledtrig-usbport.txt create mode 100644 Documentation/leds/uleds.rst delete mode 100644 Documentation/leds/uleds.txt (limited to 'Documentation') diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 6cced88de6da..75ef063622d2 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -679,7 +679,7 @@ status as "unknown". The available commands are: sysfs notes: The ThinkLight sysfs interface is documented by the LED class -documentation, in Documentation/leds/leds-class.txt. The ThinkLight LED name +documentation, in Documentation/leds/leds-class.rst. The ThinkLight LED name is "tpacpi::thinklight". Due to limitations in the sysfs LED class, if the status of the ThinkLight @@ -779,7 +779,7 @@ All of the above can be turned on and off and can be made to blink. sysfs notes: The ThinkPad LED sysfs interface is described in detail by the LED class -documentation, in Documentation/leds/leds-class.txt. +documentation, in Documentation/leds/leds-class.rst. The LEDs are named (in LED ID order, from 0 to 12): "tpacpi::power", "tpacpi:orange:batt", "tpacpi:green:batt", diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst new file mode 100644 index 000000000000..9885f7c1b75d --- /dev/null +++ b/Documentation/leds/index.rst @@ -0,0 +1,25 @@ +:orphan: + +==== +LEDs +==== + +.. toctree:: + :maxdepth: 1 + + leds-class + leds-class-flash + ledtrig-oneshot + ledtrig-transient + ledtrig-usbport + + uleds + + leds-blinkm + leds-lm3556 + leds-lp3944 + leds-lp5521 + leds-lp5523 + leds-lp5562 + leds-lp55xx + leds-mlxcpld diff --git a/Documentation/leds/leds-blinkm.rst b/Documentation/leds/leds-blinkm.rst new file mode 100644 index 000000000000..c74b5bc877b1 --- /dev/null +++ b/Documentation/leds/leds-blinkm.rst @@ -0,0 +1,84 @@ +================== +Leds BlinkM driver +================== + +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--- + + $ 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 gmx de diff --git a/Documentation/leds/leds-blinkm.txt b/Documentation/leds/leds-blinkm.txt deleted file mode 100644 index 9dd92f4cf4e1..000000000000 --- a/Documentation/leds/leds-blinkm.txt +++ /dev/null @@ -1,80 +0,0 @@ -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--- - -$ 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 gmx de - diff --git a/Documentation/leds/leds-class-flash.rst b/Documentation/leds/leds-class-flash.rst new file mode 100644 index 000000000000..6ec12c5a1a0e --- /dev/null +++ b/Documentation/leds/leds-class-flash.rst @@ -0,0 +1,90 @@ +============================== +Flash LED handling under Linux +============================== + +Some LED devices provide two modes - torch and flash. In the LED subsystem +those modes are supported by LED class (see Documentation/leds/leds-class.rst) +and LED Flash class respectively. The torch mode related features are enabled +by default and the flash ones only if a driver declares it by setting +LED_DEV_CAP_FLASH flag. + +In order to enable the support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol +must be defined in the kernel config. A LED Flash class driver must be +registered in the LED subsystem with led_classdev_flash_register function. + +Following sysfs attributes are exposed for controlling flash LED devices: +(see Documentation/ABI/testing/sysfs-class-led-flash) + + - flash_brightness + - max_flash_brightness + - flash_timeout + - max_flash_timeout + - flash_strobe + - flash_fault + + +V4L2 flash wrapper for flash LEDs +================================= + +A LED subsystem driver can be controlled also from the level of VideoForLinux2 +subsystem. In order to enable this CONFIG_V4L2_FLASH_LED_CLASS symbol has to +be defined in the kernel config. + +The driver must call the v4l2_flash_init function to get registered in the +V4L2 subsystem. The function takes six arguments: + +- dev: + flash device, e.g. an I2C device +- of_node: + of_node of the LED, may be NULL if the same as device's +- fled_cdev: + LED flash class device to wrap +- iled_cdev: + LED flash class device representing indicator LED associated with + fled_cdev, may be NULL +- ops: + V4L2 specific ops + + * external_strobe_set + defines the source of the flash LED strobe - + V4L2_CID_FLASH_STROBE control or external source, typically + a sensor, which makes it possible to synchronise the flash + strobe start with exposure start, + * intensity_to_led_brightness and led_brightness_to_intensity + perform + enum led_brightness <-> V4L2 intensity conversion in a device + specific manner - they can be used for devices with non-linear + LED current scale. +- config: + configuration for V4L2 Flash sub-device + + * dev_name + the name of the media entity, unique in the system, + * flash_faults + bitmask of flash faults that the LED flash class + device can report; corresponding LED_FAULT* bit definitions are + available in , + * torch_intensity + constraints for the LED in TORCH mode + in microamperes, + * indicator_intensity + constraints for the indicator LED + in microamperes, + * has_external_strobe + determines whether the flash strobe source + can be switched to external, + +On remove the v4l2_flash_release function has to be called, which takes one +argument - struct v4l2_flash pointer returned previously by v4l2_flash_init. +This function can be safely called with NULL or error pointer argument. + +Please refer to drivers/leds/leds-max77693.c for an exemplary usage of the +v4l2 flash wrapper. + +Once the V4L2 sub-device is registered by the driver which created the Media +controller device, the sub-device node acts just as a node of a native V4L2 +flash API device would. The calls are simply routed to the LED flash API. + +Opening the V4L2 flash sub-device makes the LED subsystem sysfs interface +unavailable. The interface is re-enabled after the V4L2 flash sub-device +is closed. diff --git a/Documentation/leds/leds-class-flash.txt b/Documentation/leds/leds-class-flash.txt deleted file mode 100644 index 8da3c6f4b60b..000000000000 --- a/Documentation/leds/leds-class-flash.txt +++ /dev/null @@ -1,73 +0,0 @@ - -Flash LED handling under Linux -============================== - -Some LED devices provide two modes - torch and flash. In the LED subsystem -those modes are supported by LED class (see Documentation/leds/leds-class.txt) -and LED Flash class respectively. The torch mode related features are enabled -by default and the flash ones only if a driver declares it by setting -LED_DEV_CAP_FLASH flag. - -In order to enable the support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol -must be defined in the kernel config. A LED Flash class driver must be -registered in the LED subsystem with led_classdev_flash_register function. - -Following sysfs attributes are exposed for controlling flash LED devices: -(see Documentation/ABI/testing/sysfs-class-led-flash) - - flash_brightness - - max_flash_brightness - - flash_timeout - - max_flash_timeout - - flash_strobe - - flash_fault - - -V4L2 flash wrapper for flash LEDs -================================= - -A LED subsystem driver can be controlled also from the level of VideoForLinux2 -subsystem. In order to enable this CONFIG_V4L2_FLASH_LED_CLASS symbol has to -be defined in the kernel config. - -The driver must call the v4l2_flash_init function to get registered in the -V4L2 subsystem. The function takes six arguments: -- dev : flash device, e.g. an I2C device -- of_node : of_node of the LED, may be NULL if the same as device's -- fled_cdev : LED flash class device to wrap -- iled_cdev : LED flash class device representing indicator LED associated with - fled_cdev, may be NULL -- ops : V4L2 specific ops - * external_strobe_set - defines the source of the flash LED strobe - - V4L2_CID_FLASH_STROBE control or external source, typically - a sensor, which makes it possible to synchronise the flash - strobe start with exposure start, - * intensity_to_led_brightness and led_brightness_to_intensity - perform - enum led_brightness <-> V4L2 intensity conversion in a device - specific manner - they can be used for devices with non-linear - LED current scale. -- config : configuration for V4L2 Flash sub-device - * dev_name - the name of the media entity, unique in the system, - * flash_faults - bitmask of flash faults that the LED flash class - device can report; corresponding LED_FAULT* bit definitions are - available in , - * torch_intensity - constraints for the LED in TORCH mode - in microamperes, - * indicator_intensity - constraints for the indicator LED - in microamperes, - * has_external_strobe - determines whether the flash strobe source - can be switched to external, - -On remove the v4l2_flash_release function has to be called, which takes one -argument - struct v4l2_flash pointer returned previously by v4l2_flash_init. -This function can be safely called with NULL or error pointer argument. - -Please refer to drivers/leds/leds-max77693.c for an exemplary usage of the -v4l2 flash wrapper. - -Once the V4L2 sub-device is registered by the driver which created the Media -controller device, the sub-device node acts just as a node of a native V4L2 -flash API device would. The calls are simply routed to the LED flash API. - -Opening the V4L2 flash sub-device makes the LED subsystem sysfs interface -unavailable. The interface is re-enabled after the V4L2 flash sub-device -is closed. diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst new file mode 100644 index 000000000000..df0120a1ee3c --- /dev/null +++ b/Documentation/leds/leds-class.rst @@ -0,0 +1,125 @@ +======================== +LED handling under Linux +======================== + +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 disk-activity, +nand-disk and sharpsl-charge triggers. With led triggers disabled, the code +optimises away. + +Complex triggers while 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//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//trigger). Trigger specific +parameters can appear in /sys/class/leds/ 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. + + +Brightness setting API +====================== + +LED subsystem core exposes following API for setting brightness: + + - led_set_brightness: + it is guaranteed not to sleep, passing LED_OFF stops + blinking, + + - led_set_brightness_sync: + for use cases when immediate effect is desired - + it can block the caller for the time required for accessing + device registers and can sleep, passing LED_OFF stops hardware + blinking, returns -EBUSY if software blink fallback is enabled. + + +LED registration API +==================== + +A driver wanting to register a LED classdev for use by other drivers / +userspace needs to allocate and fill a led_classdev struct and then call +`[devm_]led_classdev_register`. If the non devm version is used the driver +must call led_classdev_unregister from its remove function before +free-ing the led_classdev struct. + +If the driver can detect hardware initiated brightness changes and thus +wants to have a brightness_hw_changed attribute then the LED_BRIGHT_HW_CHANGED +flag must be set in flags before registering. Calling +led_classdev_notify_brightness_hw_changed on a classdev not registered with +the LED_BRIGHT_HW_CHANGED flag is a bug and will trigger a WARN_ON. + +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 ). 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, use the API function led_brightness_set() +with brightness value LED_OFF, which should 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. diff --git a/Documentation/leds/leds-class.txt b/Documentation/leds/leds-class.txt deleted file mode 100644 index 8b39cc6b03ee..000000000000 --- a/Documentation/leds/leds-class.txt +++ /dev/null @@ -1,122 +0,0 @@ - -LED handling under Linux -======================== - -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 disk-activity, -nand-disk and sharpsl-charge triggers. With led triggers disabled, the code -optimises away. - -Complex triggers while 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//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//trigger). Trigger specific -parameters can appear in /sys/class/leds/ 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. - - -Brightness setting API -====================== - -LED subsystem core exposes following API for setting brightness: - - - led_set_brightness : it is guaranteed not to sleep, passing LED_OFF stops - blinking, - - led_set_brightness_sync : for use cases when immediate effect is desired - - it can block the caller for the time required for accessing - device registers and can sleep, passing LED_OFF stops hardware - blinking, returns -EBUSY if software blink fallback is enabled. - - -LED registration API -==================== - -A driver wanting to register a LED classdev for use by other drivers / -userspace needs to allocate and fill a led_classdev struct and then call -[devm_]led_classdev_register. If the non devm version is used the driver -must call led_classdev_unregister from its remove function before -free-ing the led_classdev struct. - -If the driver can detect hardware initiated brightness changes and thus -wants to have a brightness_hw_changed attribute then the LED_BRIGHT_HW_CHANGED -flag must be set in flags before registering. Calling -led_classdev_notify_brightness_hw_changed on a classdev not registered with -the LED_BRIGHT_HW_CHANGED flag is a bug and will trigger a WARN_ON. - -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 ). 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, use the API function led_brightness_set() -with brightness value LED_OFF, which should 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. diff --git a/Documentation/leds/leds-lm3556.rst b/Documentation/leds/leds-lm3556.rst new file mode 100644 index 000000000000..1ef17d7d800e --- /dev/null +++ b/Documentation/leds/leds-lm3556.rst @@ -0,0 +1,137 @@ +======================== +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)); diff --git a/Documentation/leds/leds-lm3556.txt b/Documentation/leds/leds-lm3556.txt deleted file mode 100644 index 62278e871b50..000000000000 --- a/Documentation/leds/leds-lm3556.txt +++ /dev/null @@ -1,85 +0,0 @@ -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)); diff --git a/Documentation/leds/leds-lp3944.rst b/Documentation/leds/leds-lp3944.rst new file mode 100644 index 000000000000..c2f87dc1a3a9 --- /dev/null +++ b/Documentation/leds/leds-lp3944.rst @@ -0,0 +1,59 @@ +==================== +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 + + +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)); diff --git a/Documentation/leds/leds-lp3944.txt b/Documentation/leds/leds-lp3944.txt deleted file mode 100644 index e88ac3b60c08..000000000000 --- a/Documentation/leds/leds-lp3944.txt +++ /dev/null @@ -1,50 +0,0 @@ -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 - - -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)); diff --git a/Documentation/leds/leds-lp5521.rst b/Documentation/leds/leds-lp5521.rst new file mode 100644 index 000000000000..0432615b083d --- /dev/null +++ b/Documentation/leds/leds-lp5521.rst @@ -0,0 +1,115 @@ +======================== +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:: + + 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, + }; + +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) + + +If the current is set to 0 in the platform data, that channel is +disabled and it is not visible in the sysfs. diff --git a/Documentation/leds/leds-lp5521.txt b/Documentation/leds/leds-lp5521.txt deleted file mode 100644 index d08d8c179f85..000000000000 --- a/Documentation/leds/leds-lp5521.txt +++ /dev/null @@ -1,101 +0,0 @@ -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. diff --git a/Documentation/leds/leds-lp5523.rst b/Documentation/leds/leds-lp5523.rst new file mode 100644 index 000000000000..7d7362a1dd57 --- /dev/null +++ b/Documentation/leds/leds-lp5523.rst @@ -0,0 +1,147 @@ +======================== +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 + enginex_leds: + led mux control + + :: + + 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 + +LP5523 has three master faders. If a channel is mapped to one of +the master faders, its output is dimmed based on the value of the master +fader. + +For example:: + + echo "123000123" > master_fader_leds + +creates the following channel-fader mappings:: + + channel 0,6 to master_fader1 + channel 1,7 to master_fader2 + channel 2,8 to master_fader3 + +Then, to have 25% of the original output on channel 0,6:: + + echo 64 > master_fader1 + +To have 0% of the original output (i.e. no output) channel 1,7:: + + echo 0 > master_fader2 + +To have 100% of the original output (i.e. no dimming) on channel 2,8:: + + echo 255 > master_fader3 + +To clear all master fader controls:: + + echo "000000000" > master_fader_leds + +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:: + + 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, + }; + +Note + chan_nr can have values between 0 and 8. diff --git a/Documentation/leds/leds-lp5523.txt b/Documentation/leds/leds-lp5523.txt deleted file mode 100644 index 0961a060fc4d..000000000000 --- a/Documentation/leds/leds-lp5523.txt +++ /dev/null @@ -1,130 +0,0 @@ -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 - enginex_leds : led mux control - - 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 - -LP5523 has three master faders. If a channel is mapped to one of -the master faders, its output is dimmed based on the value of the master -fader. - -For example, - - echo "123000123" > master_fader_leds - -creates the following channel-fader mappings: - - channel 0,6 to master_fader1 - channel 1,7 to master_fader2 - channel 2,8 to master_fader3 - -Then, to have 25% of the original output on channel 0,6: - - echo 64 > master_fader1 - -To have 0% of the original output (i.e. no output) channel 1,7: - - echo 0 > master_fader2 - -To have 100% of the original output (i.e. no dimming) on channel 2,8: - - echo 255 > master_fader3 - -To clear all master fader controls: - - echo "000000000" > master_fader_leds - -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, -}; diff --git a/Documentation/leds/leds-lp5562.rst b/Documentation/leds/leds-lp5562.rst new file mode 100644 index 000000000000..79bbb2487ff6 --- /dev/null +++ b/Documentation/leds/leds-lp5562.rst @@ -0,0 +1,137 @@ +======================== +Kernel driver for lp5562 +======================== + +* TI LP5562 LED Driver + +Author: Milo(Woogyom) Kim + +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 +======================== + +:: + + 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, + }; + +To configure the platform specific data, lp55xx_platform_data structure is used + + +If the current is set to 0 in the platform data, that channel is +disabled and it is not visible in the sysfs. diff --git a/Documentation/leds/leds-lp5562.txt b/Documentation/leds/leds-lp5562.txt deleted file mode 100644 index 5a823ff6b393..000000000000 --- a/Documentation/leds/leds-lp5562.txt +++ /dev/null @@ -1,120 +0,0 @@ -Kernel driver for LP5562 -======================== - -* TI LP5562 LED Driver - -Author: Milo(Woogyom) Kim - -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. diff --git a/Documentation/leds/leds-lp55xx.rst b/Documentation/leds/leds-lp55xx.rst new file mode 100644 index 000000000000..632e41cec0b5 --- /dev/null +++ b/Documentation/leds/leds-lp55xx.rst @@ -0,0 +1,224 @@ +================================================= +LP5521/LP5523/LP55231/LP5562/LP8501 Common Driver +================================================= + +Authors: Milo(Woogyom) Kim + +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. + +* lp55xx_led + control multi output LED channels such as led current, channel index. +* 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 sequence 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 diff --git a/Documentation/leds/leds-lp55xx.txt b/Documentation/leds/leds-lp55xx.txt deleted file mode 100644 index e23fa91ea722..000000000000 --- a/Documentation/leds/leds-lp55xx.txt +++ /dev/null @@ -1,194 +0,0 @@ -LP5521/LP5523/LP55231/LP5562/LP8501 Common Driver -================================================= - -Authors: Milo(Woogyom) Kim - -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 sequence 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 diff --git a/Documentation/leds/leds-mlxcpld.rst b/Documentation/leds/leds-mlxcpld.rst new file mode 100644 index 000000000000..528582429e0b --- /dev/null +++ b/Documentation/leds/leds-mlxcpld.rst @@ -0,0 +1,118 @@ +======================================= +Kernel driver for Mellanox systems LEDs +======================================= + +Provide system LED support for the nex Mellanox systems: +"msx6710", "msx6720", "msb7700", "msn2700", "msx1410", +"msn2410", "msb7800", "msn2740", "msn2100". + +Description +----------- +Driver provides the following LEDs for the systems "msx6710", "msx6720", +"msb7700", "msn2700", "msx1410", "msn2410", "msb7800", "msn2740": + + - mlxcpld:fan1:green + - mlxcpld:fan1:red + - mlxcpld:fan2:green + - mlxcpld:fan2:red + - mlxcpld:fan3:green + - mlxcpld:fan3:red + - mlxcpld:fan4:green + - mlxcpld:fan4:red + - mlxcpld:psu:green + - mlxcpld:psu:red + - mlxcpld:status:green + - mlxcpld:status:red + + "status" + - CPLD reg offset: 0x20 + - Bits [3:0] + + "psu" + - CPLD reg offset: 0x20 + - Bits [7:4] + + "fan1" + - CPLD reg offset: 0x21 + - Bits [3:0] + + "fan2" + - CPLD reg offset: 0x21 + - Bits [7:4] + + "fan3" + - CPLD reg offset: 0x22 + - Bits [3:0] + + "fan4" + - CPLD reg offset: 0x22 + - Bits [7:4] + + Color mask for all the above LEDs: + + [bit3,bit2,bit1,bit0] or + [bit7,bit6,bit5,bit4]: + + - [0,0,0,0] = LED OFF + - [0,1,0,1] = Red static ON + - [1,1,0,1] = Green static ON + - [0,1,1,0] = Red blink 3Hz + - [1,1,1,0] = Green blink 3Hz + - [0,1,1,1] = Red blink 6Hz + - [1,1,1,1] = Green blink 6Hz + +Driver provides the following LEDs for the system "msn2100": + + - mlxcpld:fan:green + - mlxcpld:fan:red + - mlxcpld:psu1:green + - mlxcpld:psu1:red + - mlxcpld:psu2:green + - mlxcpld:psu2:red + - mlxcpld:status:green + - mlxcpld:status:red + - mlxcpld:uid:blue + + "status" + - CPLD reg offset: 0x20 + - Bits [3:0] + + "fan" + - CPLD reg offset: 0x21 + - Bits [3:0] + + "psu1" + - CPLD reg offset: 0x23 + - Bits [3:0] + + "psu2" + - CPLD reg offset: 0x23 + - Bits [7:4] + + "uid" + - CPLD reg offset: 0x24 + - Bits [3:0] + + Color mask for all the above LEDs, excepted uid: + + [bit3,bit2,bit1,bit0] or + [bit7,bit6,bit5,bit4]: + + - [0,0,0,0] = LED OFF + - [0,1,0,1] = Red static ON + - [1,1,0,1] = Green static ON + - [0,1,1,0] = Red blink 3Hz + - [1,1,1,0] = Green blink 3Hz + - [0,1,1,1] = Red blink 6Hz + - [1,1,1,1] = Green blink 6Hz + + Color mask for uid LED: + [bit3,bit2,bit1,bit0]: + + - [0,0,0,0] = LED OFF + - [1,1,0,1] = Blue static ON + - [1,1,1,0] = Blue blink 3Hz + - [1,1,1,1] = Blue blink 6Hz + +Driver supports HW blinking at 3Hz and 6Hz frequency (50% duty cycle). +For 3Hz duty cylce is about 167 msec, for 6Hz is about 83 msec. diff --git a/Documentation/leds/leds-mlxcpld.txt b/Documentation/leds/leds-mlxcpld.txt deleted file mode 100644 index a0e8fd457117..000000000000 --- a/Documentation/leds/leds-mlxcpld.txt +++ /dev/null @@ -1,110 +0,0 @@ -Kernel driver for Mellanox systems LEDs -======================================= - -Provide system LED support for the nex Mellanox systems: -"msx6710", "msx6720", "msb7700", "msn2700", "msx1410", -"msn2410", "msb7800", "msn2740", "msn2100". - -Description ------------ -Driver provides the following LEDs for the systems "msx6710", "msx6720", -"msb7700", "msn2700", "msx1410", "msn2410", "msb7800", "msn2740": - mlxcpld:fan1:green - mlxcpld:fan1:red - mlxcpld:fan2:green - mlxcpld:fan2:red - mlxcpld:fan3:green - mlxcpld:fan3:red - mlxcpld:fan4:green - mlxcpld:fan4:red - mlxcpld:psu:green - mlxcpld:psu:red - mlxcpld:status:green - mlxcpld:status:red - - "status" - CPLD reg offset: 0x20 - Bits [3:0] - - "psu" - CPLD reg offset: 0x20 - Bits [7:4] - - "fan1" - CPLD reg offset: 0x21 - Bits [3:0] - - "fan2" - CPLD reg offset: 0x21 - Bits [7:4] - - "fan3" - CPLD reg offset: 0x22 - Bits [3:0] - - "fan4" - CPLD reg offset: 0x22 - Bits [7:4] - - Color mask for all the above LEDs: - [bit3,bit2,bit1,bit0] or - [bit7,bit6,bit5,bit4]: - [0,0,0,0] = LED OFF - [0,1,0,1] = Red static ON - [1,1,0,1] = Green static ON - [0,1,1,0] = Red blink 3Hz - [1,1,1,0] = Green blink 3Hz - [0,1,1,1] = Red blink 6Hz - [1,1,1,1] = Green blink 6Hz - -Driver provides the following LEDs for the system "msn2100": - mlxcpld:fan:green - mlxcpld:fan:red - mlxcpld:psu1:green - mlxcpld:psu1:red - mlxcpld:psu2:green - mlxcpld:psu2:red - mlxcpld:status:green - mlxcpld:status:red - mlxcpld:uid:blue - - "status" - CPLD reg offset: 0x20 - Bits [3:0] - - "fan" - CPLD reg offset: 0x21 - Bits [3:0] - - "psu1" - CPLD reg offset: 0x23 - Bits [3:0] - - "psu2" - CPLD reg offset: 0x23 - Bits [7:4] - - "uid" - CPLD reg offset: 0x24 - Bits [3:0] - - Color mask for all the above LEDs, excepted uid: - [bit3,bit2,bit1,bit0] or - [bit7,bit6,bit5,bit4]: - [0,0,0,0] = LED OFF - [0,1,0,1] = Red static ON - [1,1,0,1] = Green static ON - [0,1,1,0] = Red blink 3Hz - [1,1,1,0] = Green blink 3Hz - [0,1,1,1] = Red blink 6Hz - [1,1,1,1] = Green blink 6Hz - - Color mask for uid LED: - [bit3,bit2,bit1,bit0]: - [0,0,0,0] = LED OFF - [1,1,0,1] = Blue static ON - [1,1,1,0] = Blue blink 3Hz - [1,1,1,1] = Blue blink 6Hz - -Driver supports HW blinking at 3Hz and 6Hz frequency (50% duty cycle). -For 3Hz duty cylce is about 167 msec, for 6Hz is about 83 msec. diff --git a/Documentation/leds/ledtrig-oneshot.rst b/Documentation/leds/ledtrig-oneshot.rst new file mode 100644 index 000000000000..69fa3ea1d554 --- /dev/null +++ b/Documentation/leds/ledtrig-oneshot.rst @@ -0,0 +1,44 @@ +==================== +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 sysfs attributes to the LED that are documented in: +Documentation/ABI/testing/sysfs-class-led-trigger-oneshot + +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 diff --git a/Documentation/leds/ledtrig-oneshot.txt b/Documentation/leds/ledtrig-oneshot.txt deleted file mode 100644 index fe57474a12e2..000000000000 --- a/Documentation/leds/ledtrig-oneshot.txt +++ /dev/null @@ -1,43 +0,0 @@ -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 sysfs attributes to the LED that are documented in: -Documentation/ABI/testing/sysfs-class-led-trigger-oneshot - -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 diff --git a/Documentation/leds/ledtrig-transient.rst b/Documentation/leds/ledtrig-transient.rst new file mode 100644 index 000000000000..d921dc830cd0 --- /dev/null +++ b/Documentation/leds/ledtrig-transient.rst @@ -0,0 +1,167 @@ +===================== +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. + +Examples +======== + +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. diff --git a/Documentation/leds/ledtrig-transient.txt b/Documentation/leds/ledtrig-transient.txt deleted file mode 100644 index 3bd38b487df1..000000000000 --- a/Documentation/leds/ledtrig-transient.txt +++ /dev/null @@ -1,152 +0,0 @@ -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. diff --git a/Documentation/leds/ledtrig-usbport.rst b/Documentation/leds/ledtrig-usbport.rst new file mode 100644 index 000000000000..37c2505bfd57 --- /dev/null +++ b/Documentation/leds/ledtrig-usbport.rst @@ -0,0 +1,46 @@ +==================== +USB port LED trigger +==================== + +This LED trigger can be used for signalling to the user a presence of USB device +in a given port. It simply turns on LED when device appears and turns it off +when it disappears. + +It requires selecting USB ports that should be observed. All available ones are +listed as separated entries in a "ports" subdirectory. Selecting is handled by +echoing "1" to a chosen port. + +Please note that this trigger allows selecting multiple USB ports for a single +LED. + +This can be useful in two cases: + +1) Device with single USB LED and few physical ports +==================================================== + +In such a case LED will be turned on as long as there is at least one connected +USB device. + +2) Device with a physical port handled by few controllers +========================================================= + +Some devices may have one controller per PHY standard. E.g. USB 3.0 physical +port may be handled by ohci-platform, ehci-platform and xhci-hcd. If there is +only one LED user will most likely want to assign ports from all 3 hubs. + + +This trigger can be activated from user space on led class devices as shown +below:: + + echo usbport > trigger + +This adds sysfs attributes to the LED that are documented in: +Documentation/ABI/testing/sysfs-class-led-trigger-usbport + +Example use-case:: + + echo usbport > trigger + echo 1 > ports/usb1-port1 + echo 1 > ports/usb2-port1 + cat ports/usb1-port1 + echo 0 > ports/usb1-port1 diff --git a/Documentation/leds/ledtrig-usbport.txt b/Documentation/leds/ledtrig-usbport.txt deleted file mode 100644 index 69f54bfb4789..000000000000 --- a/Documentation/leds/ledtrig-usbport.txt +++ /dev/null @@ -1,41 +0,0 @@ -USB port LED trigger -==================== - -This LED trigger can be used for signalling to the user a presence of USB device -in a given port. It simply turns on LED when device appears and turns it off -when it disappears. - -It requires selecting USB ports that should be observed. All available ones are -listed as separated entries in a "ports" subdirectory. Selecting is handled by -echoing "1" to a chosen port. - -Please note that this trigger allows selecting multiple USB ports for a single -LED. This can be useful in two cases: - -1) Device with single USB LED and few physical ports - -In such a case LED will be turned on as long as there is at least one connected -USB device. - -2) Device with a physical port handled by few controllers - -Some devices may have one controller per PHY standard. E.g. USB 3.0 physical -port may be handled by ohci-platform, ehci-platform and xhci-hcd. If there is -only one LED user will most likely want to assign ports from all 3 hubs. - - -This trigger can be activated from user space on led class devices as shown -below: - - echo usbport > trigger - -This adds sysfs attributes to the LED that are documented in: -Documentation/ABI/testing/sysfs-class-led-trigger-usbport - -Example use-case: - - echo usbport > trigger - echo 1 > ports/usb1-port1 - echo 1 > ports/usb2-port1 - cat ports/usb1-port1 - echo 0 > ports/usb1-port1 diff --git a/Documentation/leds/uleds.rst b/Documentation/leds/uleds.rst new file mode 100644 index 000000000000..83221098009c --- /dev/null +++ b/Documentation/leds/uleds.rst @@ -0,0 +1,37 @@ +============== +Userspace LEDs +============== + +The uleds driver supports userspace LEDs. This can be useful for testing +triggers and can also be used to implement virtual LEDs. + + +Usage +===== + +When the driver is loaded, a character device is created at /dev/uleds. To +create a new LED class device, open /dev/uleds and write a uleds_user_dev +structure to it (found in kernel public header file linux/uleds.h):: + + #define LED_MAX_NAME_SIZE 64 + + struct uleds_user_dev { + char name[LED_MAX_NAME_SIZE]; + }; + +A new LED class device will be created with the name given. The name can be +any valid sysfs device node name, but consider using the LED class naming +convention of "devicename:color:function". + +The current brightness is found by reading a single byte from the character +device. Values are unsigned: 0 to 255. Reading will block until the brightness +changes. The device node can also be polled to notify when the brightness value +changes. + +The LED class device will be removed when the open file handle to /dev/uleds +is closed. + +Multiple LED class devices are created by opening additional file handles to +/dev/uleds. + +See tools/leds/uledmon.c for an example userspace program. diff --git a/Documentation/leds/uleds.txt b/Documentation/leds/uleds.txt deleted file mode 100644 index 13e375a580f9..000000000000 --- a/Documentation/leds/uleds.txt +++ /dev/null @@ -1,36 +0,0 @@ -Userspace LEDs -============== - -The uleds driver supports userspace LEDs. This can be useful for testing -triggers and can also be used to implement virtual LEDs. - - -Usage -===== - -When the driver is loaded, a character device is created at /dev/uleds. To -create a new LED class device, open /dev/uleds and write a uleds_user_dev -structure to it (found in kernel public header file linux/uleds.h). - - #define LED_MAX_NAME_SIZE 64 - - struct uleds_user_dev { - char name[LED_MAX_NAME_SIZE]; - }; - -A new LED class device will be created with the name given. The name can be -any valid sysfs device node name, but consider using the LED class naming -convention of "devicename:color:function". - -The current brightness is found by reading a single byte from the character -device. Values are unsigned: 0 to 255. Reading will block until the brightness -changes. The device node can also be polled to notify when the brightness value -changes. - -The LED class device will be removed when the open file handle to /dev/uleds -is closed. - -Multiple LED class devices are created by opening additional file handles to -/dev/uleds. - -See tools/leds/uledmon.c for an example userspace program. diff --git a/MAINTAINERS b/MAINTAINERS index 5cfbea4ce575..3f8585317525 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10117,7 +10117,7 @@ L: linux-leds@vger.kernel.org S: Supported F: drivers/leds/leds-mlxcpld.c F: drivers/leds/leds-mlxreg.c -F: Documentation/leds/leds-mlxcpld.txt +F: Documentation/leds/leds-mlxcpld.rst MELLANOX PLATFORM DRIVER M: Vadim Pasternak diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig index 23cc85e2e0e5..24e36eef95d3 100644 --- a/drivers/leds/trigger/Kconfig +++ b/drivers/leds/trigger/Kconfig @@ -14,7 +14,7 @@ config LEDS_TRIGGER_TIMER This allows LEDs to be controlled by a programmable timer via sysfs. Some LED hardware can be programmed to start blinking the LED without any further software interaction. - For more details read Documentation/leds/leds-class.txt. + For more details read Documentation/leds/leds-class.rst. If unsure, say Y. diff --git a/drivers/leds/trigger/ledtrig-transient.c b/drivers/leds/trigger/ledtrig-transient.c index a80bb82aacc2..80635183fac8 100644 --- a/drivers/leds/trigger/ledtrig-transient.c +++ b/drivers/leds/trigger/ledtrig-transient.c @@ -3,7 +3,7 @@ // LED Kernel Transient Trigger // // Transient trigger allows one shot timer activation. Please refer to -// Documentation/leds/ledtrig-transient.txt for details +// Documentation/leds/ledtrig-transient.rst for details // Copyright (C) 2012 Shuah Khan // // Based on Richard Purdie's ledtrig-timer.c and Atsushi Nemoto's diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig index 02b281d3c167..ce25459aeee7 100644 --- a/net/netfilter/Kconfig +++ b/net/netfilter/Kconfig @@ -905,7 +905,7 @@ config NETFILTER_XT_TARGET_LED echo netfilter-ssh > /sys/class/leds//trigger For more information on the LEDs available on your system, see - Documentation/leds/leds-class.txt + Documentation/leds/leds-class.rst config NETFILTER_XT_TARGET_LOG tristate "LOG target support" -- cgit v1.2.3 From 2605085fba22792f3d4a6b856c7c5a05492d1fde Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 28 Jun 2019 09:12:26 -0300 Subject: dt: leds-lm36274.txt: fix a broken reference to ti-lmu.txt There's a typo there: ti_lmu.txt -> ti-lmu.txt Signed-off-by: Mauro Carvalho Chehab Acked-by: Pavel Machek Acked-by: Dan Murphy Signed-off-by: Jacek Anaszewski --- Documentation/devicetree/bindings/leds/leds-lm36274.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/leds-lm36274.txt b/Documentation/devicetree/bindings/leds/leds-lm36274.txt index 456a589c65f0..39c230d59a4d 100644 --- a/Documentation/devicetree/bindings/leds/leds-lm36274.txt +++ b/Documentation/devicetree/bindings/leds/leds-lm36274.txt @@ -6,7 +6,7 @@ up to 29V total output voltage. The 11-bit LED current is programmable via the I2C bus and/or controlled via a logic level PWM input from 60 uA to 30 mA. Parent device properties are documented in -Documentation/devicetree/bindings/mfd/ti_lmu.txt +Documentation/devicetree/bindings/mfd/ti-lmu.txt Regulator properties are documented in Documentation/devicetree/bindings/regulator/lm363x-regulator.txt -- cgit v1.2.3