microsoft
/
WSL2-Linux-Kernel
зеркало из https://github.com/microsoft/WSL2-Linux-Kernel.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
WSL2-Linux-Kernel/drivers/leds/Kconfig

474 строки
14 KiB
Plaintext
Исходник Обычный вид История

leds: move LEDS_GPIO_REGISTER out of menuconfig NEW_LEDS Commit 4440673a95e6 ("leds: provide helper to register "leds-gpio" devices") broke the display of the NEW_LEDS menu as it didn't depend on NEW_LEDS and so made "LED drivers" and "LED Triggers" appear at the same level as "LED Support" instead of below it as it was before 4440673a. Moving LEDS_GPIO_REGISTER out of the menuconfig NEW_LEDS fixes this unintended side effect. Reported-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-06-16 02:08:31 +04:00
config LEDS_GPIO_REGISTER
bool
help
This option provides the function gpio_led_register_device.
As this function is used by arch code it must not be compiled as a
module.
leds: Use menuconfig objects II - LED Change Kconfig objects from "menu, config" into "menuconfig" so that the user can disable the whole feature without having to enter the menu first. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-05-10 13:44:11 +04:00
menuconfig NEW_LEDS
[PATCH] LED: add LED class Add the foundations of a new LEDs subsystem. This patch adds a class which presents LED devices within sysfs and allows their brightness to be controlled. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31 14:31:04 +04:00
bool "LED Support"
help
[PATCH] LED: Improve Kconfig information Improve the NEW_LEDS Kconfig information to say what it does as well as what it doesn't. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-05-15 20:44:14 +04:00
Say Y to enable Linux LED support. This allows control of supported
LEDs from both userspace and optionally, by kernel events (triggers).
This is not related to standard keyboard LEDs which are controlled
via the input system.
[PATCH] LED: add LED class Add the foundations of a new LEDs subsystem. This patch adds a class which presents LED devices within sysfs and allows their brightness to be controlled. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31 14:31:04 +04:00
leds: fix the incorrect display in menuconfig Seems when a config option does not have a dependency of the menuconfig, it messes the display of the rest configs, even if it's a hidden one. Signed-off-by: Eric Miao <eric.y.miao@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu> Cc: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-06-16 02:08:40 +04:00
if NEW_LEDS
[PATCH] LED: add LED class Add the foundations of a new LEDs subsystem. This patch adds a class which presents LED devices within sysfs and allows their brightness to be controlled. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31 14:31:04 +04:00
config LEDS_CLASS
led-class: change back LEDS_CLASS to tristate instead of bool After moving some core functions to led-core.c, led-class.c can be built as module again. Signed-off-by: Bryan Wu <bryan.wu@canonical.com> Acked-by: Richard Purdie <richard.purdie@linuxfoundation.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-03-24 02:02:14 +04:00
tristate "LED Class Support"
[PATCH] LED: add LED class Add the foundations of a new LEDs subsystem. This patch adds a class which presents LED devices within sysfs and allows their brightness to be controlled. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31 14:31:04 +04:00
help
This option enables the led sysfs class in /sys/class/leds. You'll
need this to do anything useful with LEDs. If unsure, say N.
[PATCH] leds: reorganise Kconfig Reorganise the drivers/leds Kconfig file to have the LED trigger enable with the triggers themselves. Also add comments to divide up the sections into the drivers and triggers Signed-off-by: Ben Dooks <ben-linux@fluff.org> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11 09:54:01 +04:00
comment "LED drivers"
[PATCH] LED: add LED trigger tupport Add support for LED triggers to the LED subsystem. "Triggers" are events which change the state of an LED. Two kinds of trigger are available, simple ones which can be added to exising code with minimum disruption and complex ones for implementing new or more complex functionality. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31 14:31:05 +04:00
led: Enable led in 88pm860x Enable led sub device in Marvell 88PM860x. Two LED arrays can be supported. Each LED array can be used for R,G,B leds. Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2010-01-07 01:10:09 +03:00
config LEDS_88PM860X
tristate "LED Support for Marvell 88PM860x PMIC"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig fixes Soekris net5501 is x86 only and cleanup some undeeded dependencies Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-05-27 16:08:33 +04:00
depends on MFD_88PM860X
led: Enable led in 88pm860x Enable led sub device in Marvell 88PM860x. Two LED arrays can be supported. Each LED array can be used for R,G,B leds. Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2010-01-07 01:10:09 +03:00
help
This option enables support for on-chip LED drivers found on Marvell
Semiconductor 88PM8606 PMIC.
PWM LED driver This is a LED driver using the PWM on newer SOCs from Atmel; brightness is controlled by changing the PWM duty cycle. So for example if you've set up two leds labeled "pwm0" and "pwm1": echo 0 > /sys/class/leds/pwm2/brightness # off (0%) echo 80 > /sys/class/leds/pwm2/brightness echo 255 > /sys/class/leds/pwm2/brightness # on (100%) Note that "brightness" here isn't linear; maybe that should change. Going from 4 to 8 probably doubles perceived brightness, while 244 to 248 is imperceptible. This is mostly intended to be a simple example of PWM, although it's realistic since LCD backlights are often driven with PWM to conserve battery power (and offer brightness options). Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Andrew Victor <linux@maxim.org.za> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 15:21:22 +03:00
config LEDS_ATMEL_PWM
tristate "LED Support using Atmel PWM outputs"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on ATMEL_PWM
PWM LED driver This is a LED driver using the PWM on newer SOCs from Atmel; brightness is controlled by changing the PWM duty cycle. So for example if you've set up two leds labeled "pwm0" and "pwm1": echo 0 > /sys/class/leds/pwm2/brightness # off (0%) echo 80 > /sys/class/leds/pwm2/brightness echo 255 > /sys/class/leds/pwm2/brightness # on (100%) Note that "brightness" here isn't linear; maybe that should change. Going from 4 to 8 probably doubles perceived brightness, while 244 to 248 is imperceptible. This is mostly intended to be a simple example of PWM, although it's realistic since LCD backlights are often driven with PWM to conserve battery power (and offer brightness options). Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Andrew Victor <linux@maxim.org.za> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 15:21:22 +03:00
help
This option enables support for LEDs driven using outputs
of the dedicated PWM controller found on newer Atmel SOCs.
leds: add driver for LM3530 ALS Simple backlight driver for National Semiconductor LM3530. Presently only manual mode is supported, PWM and ALS support to be added. Signed-off-by: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com> Cc: Linus Walleij <linus.walleij@stericsson.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-23 02:30:16 +03:00
config LEDS_LM3530
tristate "LCD Backlight driver for LM3530"
depends on LEDS_CLASS
depends on I2C
help
This option enables support for the LCD backlight using
LM3530 ambient light sensor chip. This ALS chip can be
controlled manually or using PWM input or using ambient
light automatically.
leds: add LM3533 LED driver Add sub-driver for the LEDs on National Semiconductor / TI LM3533 lighting power chips. The chip provides 256 brightness levels, hardware accelerated blinking as well as ambient-light-sensor and pwm input control. Signed-off-by: Johan Hovold <jhovold@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Rob Landley <rob@landley.net> Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Jonathan Cameron <jic23@cam.ac.uk> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Bryan Wu <bryan.wu@canonical.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-30 02:07:31 +04:00
config LEDS_LM3533
tristate "LED support for LM3533"
depends on LEDS_CLASS
depends on MFD_LM3533
help
This option enables support for the LEDs on National Semiconductor /
TI LM3533 Lighting Power chips.
The LEDs can be controlled directly, through PWM input, or by the
ambient-light-sensor interface. The chip supports
hardware-accelerated blinking with maximum on and off periods of 9.8
and 77 seconds respectively.
leds: Add new LED driver for lm3642 chips This driver is a general version for LM642 led chip of TI. LM3642 : The LM3642 is a 4MHz fixed-frequency synchronous boost converter plus 1.5A constant current driver for a high-current white LED. The LM3642 is controlled via an I2C-compatible interface. Signed-off-by: G.Shark Jeong <gshark.jeong@gmail.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-12 16:05:50 +04:00
config LEDS_LM3642
tristate "LED support for LM3642 Chip"
depends on LEDS_CLASS && I2C
select REGMAP_I2C
help
This option enables support for LEDs connected to LM3642.
The LM3642 is a 4MHz fixed-frequency synchronous boost
converter plus 1.5A constant current driver for a high-current
white LED.
[PATCH] LED: add LED device support for locomo devices Adds an LED driver for LEDs exported by the Sharp LOCOMO chip as found on some models of Sharp Zaurus. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31 14:31:10 +04:00
config LEDS_LOCOMO
tristate "LED Support for Locomo device"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on SHARP_LOCOMO
[PATCH] LED: add LED device support for locomo devices Adds an LED driver for LEDs exported by the Sharp LOCOMO chip as found on some models of Sharp Zaurus. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31 14:31:10 +04:00
help
This option enables support for the LEDs on Sharp Locomo.
Zaurus models SL-5500 and SL-5600.
leds: Add rb532 LED driver for the User LED Mikrotik built six LEDs into the Routerboard 532, from which one is destined for custom use, the so called "User LED". This patch adds a driver for it, based on the LEDs class. Signed-off-by: Phil Sutter <n0-1@freewrt.org> Acked-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-01-22 21:35:48 +03:00
config LEDS_MIKROTIK_RB532
tristate "LED Support for Mikrotik Routerboard 532"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on MIKROTIK_RB532
leds: Add rb532 LED driver for the User LED Mikrotik built six LEDs into the Routerboard 532, from which one is destined for custom use, the so called "User LED". This patch adds a driver for it, based on the LEDs class. Signed-off-by: Phil Sutter <n0-1@freewrt.org> Acked-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-01-22 21:35:48 +03:00
help
This option enables support for the so called "User LED" of
Mikrotik's Routerboard 532.
[PATCH] S3C24XX GPIO LED support GPIO LED support for Samsung S3C24XX SoC series processors. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11 09:54:00 +04:00
config LEDS_S3C24XX
tristate "LED Support for Samsung S3C24XX GPIO LEDs"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
ARM: S3C24XX: change the ARCH_S3C2410 to ARCH_S3C24XX This patch changes the ARCH name to "ARCH_S3C24XX" for Samsung S3C2410, S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, S3C2443, and S3C2450 SoCs so that we can merge the mach-xxx directories and plat-s3c24xx dir. to just one mach-s3c24xx for them. I think this should be sent to upstream via samsung tree because this touches many samsung stuff. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Chris Ball <cjb@laptop.org> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Greg Kroah-Hartman <gregkh@suse.de> [for the gadget part:] Acked-by: Felipe Balbi <balbi@ti.com> [for the framebuffer (video) part:] Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> [For the watchdog-part:] Acked-by: Wim Van Sebroeck <wim@iguana.be> Cc: Sangbeom Kim <sbkim73@samsung.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-02-03 09:29:23 +04:00
depends on ARCH_S3C24XX
[PATCH] S3C24XX GPIO LED support GPIO LED support for Samsung S3C24XX SoC series processors. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11 09:54:00 +04:00
help
This option enables support for LEDs connected to GPIO lines
on Samsung S3C24XX series CPUs, such as the S3C2410 and S3C2440.
[PATCH] LED Class support for Soekris net48xx Add LED Class device support for the Soekris net48xx Error LED. Tested only on a net4801, but should work on a net4826 as well. I'd love to find a way of detecting a Soekris net48xx device but there is no DMI or any Soekris-specific PCI devices. [akpm@osdl.org: fixlets, cleanups] Signed-off-by: Chris Boot <bootc@bootc.net> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-10 15:45:34 +04:00
config LEDS_NET48XX
tristate "LED Support for Soekris net48xx series Error LED"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on SCx200_GPIO
[PATCH] LED Class support for Soekris net48xx Add LED Class device support for the Soekris net48xx Error LED. Tested only on a net4801, but should work on a net4826 as well. I'd love to find a way of detecting a Soekris net48xx device but there is no DMI or any Soekris-specific PCI devices. [akpm@osdl.org: fixlets, cleanups] Signed-off-by: Chris Boot <bootc@bootc.net> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-10 15:45:34 +04:00
help
This option enables support for the Soekris net4801 and net4826 error
LED.
leds: Add new driver for the LEDs on the Freecom FSG-3 The LEDs on the Freecom FSG-3 are connected to an external memory-mapped latch on the ixp4xx expansion bus, and therefore cannot be supported by any of the existing LEDs drivers. Signed-off-by: Rod Whitby <rod@whitby.id.au> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-04-25 02:43:09 +04:00
config LEDS_FSG
tristate "LED Support for the Freecom FSG-3"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on MACH_FSG
leds: Add new driver for the LEDs on the Freecom FSG-3 The LEDs on the Freecom FSG-3 are connected to an external memory-mapped latch on the ixp4xx expansion bus, and therefore cannot be supported by any of the existing LEDs drivers. Signed-off-by: Rod Whitby <rod@whitby.id.au> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-04-25 02:43:09 +04:00
help
This option enables support for the LEDs on the Freecom FSG-3.
[PATCH] PCEngines WRAP LED Support A driver for the PCEngines WRAP boards (http://www.pcengines.ch), which are very similar to the Soekris net4801 (same NS SC1100 geode reference design). The LEDs on the WRAP are on different GPIO lines and I have modified and copied the net48xx error led support for this. It also includes support for an "extra" led (in addition to error). The three LEDs on the WRAP are at GPIO lines 2,3,18 (WRAP LEDs from left to right). This driver gives access to the second and third LEDs by twiddling GPIO lines 3 & 18. Because these boards are so similar to the net48xx, I basically sed-ed that driver to form the basis for leds-wrap.c. The only changes from leds-net48xx.c are: - #define WRAP_EXTRA_LED_GPIO - name changes - duplicate relevant sections to provide support for the "extra" led - reverse the various *_led_set values. The WRAP is "backwards" from the net48xx, and these needed to be updated for that. [akpm@osdl.org: build fix] Signed-off-by: Kristian Kielhofner <kris@krisk.org> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-07 07:37:28 +03:00
config LEDS_WRAP
tristate "LED Support for the WRAP series LEDs"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on SCx200_GPIO
[PATCH] PCEngines WRAP LED Support A driver for the PCEngines WRAP boards (http://www.pcengines.ch), which are very similar to the Soekris net4801 (same NS SC1100 geode reference design). The LEDs on the WRAP are on different GPIO lines and I have modified and copied the net48xx error led support for this. It also includes support for an "extra" led (in addition to error). The three LEDs on the WRAP are at GPIO lines 2,3,18 (WRAP LEDs from left to right). This driver gives access to the second and third LEDs by twiddling GPIO lines 3 & 18. Because these boards are so similar to the net48xx, I basically sed-ed that driver to form the basis for leds-wrap.c. The only changes from leds-net48xx.c are: - #define WRAP_EXTRA_LED_GPIO - name changes - duplicate relevant sections to provide support for the "extra" led - reverse the various *_led_set values. The WRAP is "backwards" from the net48xx, and these needed to be updated for that. [akpm@osdl.org: build fix] Signed-off-by: Kristian Kielhofner <kris@krisk.org> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-07 07:37:28 +03:00
help
This option enables support for the PCEngines WRAP programmable LEDs.
leds: Rename leds-cobalt driver The leds-cobalt driver only supports the Coable Qube series (not included in Cobalt Raq series). Rename the driver and update Kconfig/Makefile. Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Acked-by: Florian Fainelli <florian.fainelli@telecomint.eu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-09-21 03:02:47 +04:00
config LEDS_COBALT_QUBE
tristate "LED Support for the Cobalt Qube series front LED"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on MIPS_COBALT
leds: Add support for Cobalt Server front LED Add support for Cobalt Server front LED (MIPS) Signed-off-by: Florian Fainell <florian.fainelli@int-evry.fr> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-02-13 02:16:27 +03:00
help
leds: Rename leds-cobalt driver The leds-cobalt driver only supports the Coable Qube series (not included in Cobalt Raq series). Rename the driver and update Kconfig/Makefile. Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Acked-by: Florian Fainelli <florian.fainelli@telecomint.eu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-09-21 03:02:47 +04:00
This option enables support for the front LED on Cobalt Qube series
leds: Add support for Cobalt Server front LED Add support for Cobalt Server front LED (MIPS) Signed-off-by: Florian Fainell <florian.fainelli@int-evry.fr> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-02-13 02:16:27 +03:00
leds: Add Cobalt Raq series LEDs support Add Cobalt Raq series LEDs support. Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-09-27 12:51:05 +04:00
config LEDS_COBALT_RAQ
bool "LED Support for the Cobalt Raq series"
leds: fix Cobalt Raq LED dependency Cobalt Raq LEDs require LEDS_CLASS=y. Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2008-12-03 11:09:28 +03:00
depends on LEDS_CLASS=y && MIPS_COBALT
leds: Add Cobalt Raq series LEDs support Add Cobalt Raq series LEDs support. Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-09-27 12:51:05 +04:00
select LEDS_TRIGGERS
help
This option enables support for the Cobalt Raq series LEDs.
leds: Add driver for Sunfire UltraSPARC server LEDs. Signed-off-by: David S. Miller <davem@davemloft.net>
2008-09-01 07:26:48 +04:00
config LEDS_SUNFIRE
tristate "LED support for SunFire servers."
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on SPARC64
leds: Add driver for Sunfire UltraSPARC server LEDs. Signed-off-by: David S. Miller <davem@davemloft.net>
2008-09-01 07:26:48 +04:00
select LEDS_TRIGGERS
help
This option enables support for the Left, Middle, and Right
LEDs on the I/O and CPU boards of SunFire UltraSPARC servers.
leds: Add HP Jornada 6xx driver Add support for the LEDs on the HP Jornada 620/660/680/690 devices. Signed-off-by: Kristoffer Ericson <kristoffer.ericson@gmail.com> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-02-07 13:10:28 +03:00
config LEDS_HP6XX
tristate "LED Support for the HP Jornada 6xx"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on SH_HP6XX
leds: Add HP Jornada 6xx driver Add support for the LEDs on the HP Jornada 620/660/680/690 devices. Signed-off-by: Kristoffer Ericson <kristoffer.ericson@gmail.com> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-02-07 13:10:28 +03:00
help
trivial: fix typos/grammar errors in Kconfig texts Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-01-26 13:12:25 +03:00
This option enables LED support for the handheld
leds: Add HP Jornada 6xx driver Add support for the LEDs on the HP Jornada 620/660/680/690 devices. Signed-off-by: Kristoffer Ericson <kristoffer.ericson@gmail.com> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-02-07 13:10:28 +03:00
HP Jornada 620/660/680/690.
leds: Add pca9532 led driver NXP pca9532 is a LED dimmer/controller attached to i2c bus. It allows attaching upto 16 leds which can either be on, off or dimmed and/or blinked with the two PWM modulators available. This driver is a "new-style" i2c driver that adheres to the driver model and implements the led framework api. Since the leds connected to the driver are platform specific, it is only useful when platform data is passed to the driver to define what leds are connected to which pins. Signed-off-by: Riku Voipio <riku.voipio@iki.fi> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-05-31 17:43:41 +04:00
config LEDS_PCA9532
tristate "LED driver for PCA9532 dimmer"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
drivers/leds: remove depends on CONFIG_EXPERIMENTAL The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. CC: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17 06:53:41 +04:00
depends on I2C && INPUT
leds: Add pca9532 led driver NXP pca9532 is a LED dimmer/controller attached to i2c bus. It allows attaching upto 16 leds which can either be on, off or dimmed and/or blinked with the two PWM modulators available. This driver is a "new-style" i2c driver that adheres to the driver model and implements the led framework api. Since the leds connected to the driver are platform specific, it is only useful when platform data is passed to the driver to define what leds are connected to which pins. Signed-off-by: Riku Voipio <riku.voipio@iki.fi> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-05-31 17:43:41 +04:00
help
This option enables support for NXP pca9532
trivial: fix typos/grammar errors in Kconfig texts Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-01-26 13:12:25 +03:00
LED controller. It is generally only useful
leds: Add pca9532 led driver NXP pca9532 is a LED dimmer/controller attached to i2c bus. It allows attaching upto 16 leds which can either be on, off or dimmed and/or blinked with the two PWM modulators available. This driver is a "new-style" i2c driver that adheres to the driver model and implements the led framework api. Since the leds connected to the driver are platform specific, it is only useful when platform data is passed to the driver to define what leds are connected to which pins. Signed-off-by: Riku Voipio <riku.voipio@iki.fi> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-05-31 17:43:41 +04:00
as a platform driver
drivers/leds/leds-pca9532.c: add gpio capability Allow unused leds on pca9532 to be used as gpio. The board I am working on now has no less than 6 pca9532 chips. One chips is used for only leds, one has 14 leds and 2 gpio and the rest of the chips are gpio only. There is also one board in mainline which could use this capabilty; arch/arm/mach-iop32x/n2100.c 232 { .type = PCA9532_TYPE_NONE }, /* power OFF gpio */ 233 { .type = PCA9532_TYPE_NONE }, /* reset gpio */ This patch defines a new pin type, PCA9532_TYPE_GPIO, and registers a gpiochip if any pin has this type set. The gpio will registers all chip pins but will filter on gpio_request. [randy.dunlap@oracle.com: fix build when GPIOLIB is not enabled] Signed-off-by: Joachim Eastwood <joachim.eastwood@jotron.com> Reviewed-by: Wolfram Sang <w.sang@pengutronix.de> Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Jan Weitzel <j.weitzel@phytec.de> Cc: Juergen Kilb <j.kilb@phytec.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 04:13:23 +04:00
config LEDS_PCA9532_GPIO
bool "Enable GPIO support for PCA9532"
depends on LEDS_PCA9532
depends on GPIOLIB
help
Allow unused pins on PCA9532 to be used as gpio.
To use a pin as gpio pca9532_type in pca9532_platform data needs to
set to PCA9532_TYPE_GPIO.
leds: Add generic GPIO LED driver This patch adds support for GPIO connected leds via the new GPIO framework. Information about leds (gpio, polarity, name, default trigger) is passed to the driver via platform_data. Signed-off-by: Raphael Assenat <raph@8d.com> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-02-27 22:49:53 +03:00
config LEDS_GPIO
tristate "LED Support for GPIO connected LEDs"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
Convert selectors of GENERIC_GPIO to GPIOLIB GENERIC_GPIO is now equivalent to GPIOLIB and features that depended on GENERIC_GPIO can now depend on GPIOLIB to allow removal of this option. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2013-03-28 15:34:56 +04:00
depends on GPIOLIB
leds: Add generic GPIO LED driver This patch adds support for GPIO connected leds via the new GPIO framework. Information about leds (gpio, polarity, name, default trigger) is passed to the driver via platform_data. Signed-off-by: Raphael Assenat <raph@8d.com> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-02-27 22:49:53 +03:00
help
This option enables support for the LEDs connected to GPIO
outputs. To be useful the particular board must have LEDs
leds: Add openfirmware platform device support Add bindings to support LEDs defined as of_platform devices in addition to the existing bindings for platform devices. New options in Kconfig allow the platform binding code and/or the of_platform code to be turned on. The of_platform code is of course only available on archs that have OF support. The existing probe and remove methods are refactored to use new functions create_gpio_led(), to create and register one led, and delete_gpio_led(), to unregister and free one led. The new probe and remove methods for the of_platform driver can then share most of the common probe and remove code with the platform driver. The suspend and resume methods aren't shared, but they are very short. The actual led driving code is the same for LEDs created by either binding. The OF bindings are based on patch by Anton Vorontsov <avorontsov@ru.mvista.com>. They have been extended to allow multiple LEDs per device. Signed-off-by: Trent Piepho <tpiepho@freescale.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Sean MacLennan <smaclennan@pikatech.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-01-10 20:26:01 +03:00
and they must be connected to the GPIO lines. The LEDs must be
defined as platform devices and/or OpenFirmware platform devices.
The code to use these bindings can be selected below.
leds: LED driver for National Semiconductor LP3944 Funlight Chip LEDs driver for National Semiconductor LP3944 Funlight Chip http://www.national.com/pf/LP/LP3944.html This helper chip 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 LP3944 can be found on Motorola A910 smartphone, where it drives the rgb leds, the camera flash light and the displays backlights. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-06-19 15:55:42 +04:00
config LEDS_LP3944
tristate "LED Support for N.S. LP3944 (Fun Light) I2C chip"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on I2C
leds: LED driver for National Semiconductor LP3944 Funlight Chip LEDs driver for National Semiconductor LP3944 Funlight Chip http://www.national.com/pf/LP/LP3944.html This helper chip 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 LP3944 can be found on Motorola A910 smartphone, where it drives the rgb leds, the camera flash light and the displays backlights. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-06-19 15:55:42 +04:00
help
leds: Fix indentation in LEDS_LP3944 Kconfig entry Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-07-03 18:18:45 +04:00
This option enables support for LEDs connected to the National
Semiconductor LP3944 Lighting Management Unit (LMU) also known as
Fun Light Chip.
leds: LED driver for National Semiconductor LP3944 Funlight Chip LEDs driver for National Semiconductor LP3944 Funlight Chip http://www.national.com/pf/LP/LP3944.html This helper chip 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 LP3944 can be found on Motorola A910 smartphone, where it drives the rgb leds, the camera flash light and the displays backlights. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-06-19 15:55:42 +04:00
To compile this driver as a module, choose M here: the
module will be called leds-lp3944.
leds-lp55xx: add new common driver for lp5521/5523 This patch supports basic common driver code for LP5521, LP5523/55231 devices. ( Driver Structure Data ) lp55xx_led and lp55xx_chip 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 ( Platform Data ) LP5521 and LP5523/55231 have own specific platform data. However, this data can be handled with just one platform data structure. The lp55xx platform data is declared in the header. This structure is derived from leds-lp5521.h and leds-lp5523.h Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-05 13:01:23 +04:00
config LEDS_LP55XX_COMMON
leds: add new LP5562 LED driver LP5562 can drive up to 4 channels, RGB and White. LEDs can be controlled directly via the led class control interface. LP55xx common driver LP5562 is one of LP55xx family device, so LP55xx common code are used. On the other hand, chip specific configuration is defined in the structure 'lp55xx_device_config' LED pattern data LP5562 has also internal program memory which is used for running various LED patterns. LP5562 driver supports the firmware interface and the predefined pattern data as well. LP5562 device attributes: 'led_pattern' and 'engine_mux' A 'led_pattern' is an index code which runs the predefined pattern data. And 'engine_mux' is updated with the firmware interface is activated. Detailed description has been updated in the documentation files, 'leds-lp55xx.txt' and 'leds-lp5562.txt'. Changes on the header file LP5562 configurable definitions are added. Pattern RGB data is fixed as constant value. (No side effect on other devices, LP5521 or LP5523.) (cooloney@gmail.com: remove redundant mutex_unlock(). Reported by Dan Carpenter <dan.carpenter@oracle.com>) Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-19 09:10:14 +04:00
tristate "Common Driver for TI/National LP5521, LP5523/55231 and LP5562"
depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562
leds-lp55xx: support firmware interface This patch provides additional device attributes which enable loading the firmware. ('select_engine' and 'run_engine') To run a LED pattern, two parts of driver should be enabled. Common features : lp55xx-common =============================== Firmware interface for loading LED patterns Chip specific features : leds-lp5521, leds-lp5523 ================================================= Register addresses for loading firmware data Register addresses for running selected engine Pattern programming sequence ============================ LP55xx chips have three program engines. To load and run a LED pattern, the programming sequence is as follows. (1) Select an engine number (1/2/3) (2) Set engine mode to load (3) Write pattern data into selected area (4) Set engine mode to run This sequence is almost same as the firmware interface. (1) Select an engine number : 'select_engine' dev attribute (2) Mode change to load : 'loading' of firmware class (3) Write pattern data into selected area : 'data' of firmware class (4) Mode change to run : 'run_engine' dev attribute (1) and (4) are device specific features which provide callback functions (2) and (3) are common features. For example, echo 1 or 2 or 3 > /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 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. Device specific data structure ============================== o Firmware callback load selected engine and update program memory o Run engine change the engine mode o 'engine_idx' and firmware data, 'fw' Those are used in the driver internally with callback functions Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-05 14:17:20 +04:00
select FW_LOADER
leds-lp55xx: add new common driver for lp5521/5523 This patch supports basic common driver code for LP5521, LP5523/55231 devices. ( Driver Structure Data ) lp55xx_led and lp55xx_chip 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 ( Platform Data ) LP5521 and LP5523/55231 have own specific platform data. However, this data can be handled with just one platform data structure. The lp55xx platform data is declared in the header. This structure is derived from leds-lp5521.h and leds-lp5523.h Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-05 13:01:23 +04:00
help
This option supports common operations for LP5521 and LP5523/55231
devices.
leds: update LP552x support Kconfig and Makefile Provide configuration and compilation support for LP5521 and LP5523 Signed-off-by: Samu Onkalo <samu.p.onkalo@nokia.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-11-12 01:05:23 +03:00
config LEDS_LP5521
tristate "LED Support for N.S. LP5521 LED driver chip"
depends on LEDS_CLASS && I2C
leds-lp55xx: add new common driver for lp5521/5523 This patch supports basic common driver code for LP5521, LP5523/55231 devices. ( Driver Structure Data ) lp55xx_led and lp55xx_chip 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 ( Platform Data ) LP5521 and LP5523/55231 have own specific platform data. However, this data can be handled with just one platform data structure. The lp55xx platform data is declared in the header. This structure is derived from leds-lp5521.h and leds-lp5523.h Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-05 13:01:23 +04:00
select LEDS_LP55XX_COMMON
leds: update LP552x support Kconfig and Makefile Provide configuration and compilation support for LP5521 and LP5523 Signed-off-by: Samu Onkalo <samu.p.onkalo@nokia.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-11-12 01:05:23 +03:00
help
If you say yes here you get support for the National Semiconductor
LP5521 LED driver. It is 3 channel chip with programmable engines.
Driver provides direct control via LED class and interface for
programming the engines.
config LEDS_LP5523
leds-lp5523: support new LP55231 device New TI LP55231 device has same I2C register layout as LP5523. Therefore, all of LED operations can be shared with the LP5523 driver. To support new LP55231 device explicitly, the device description is added in the configuration file. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-04 11:06:11 +04:00
tristate "LED Support for TI/National LP5523/55231 LED driver chip"
leds: update LP552x support Kconfig and Makefile Provide configuration and compilation support for LP5521 and LP5523 Signed-off-by: Samu Onkalo <samu.p.onkalo@nokia.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-11-12 01:05:23 +03:00
depends on LEDS_CLASS && I2C
leds-lp55xx: add new common driver for lp5521/5523 This patch supports basic common driver code for LP5521, LP5523/55231 devices. ( Driver Structure Data ) lp55xx_led and lp55xx_chip 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 ( Platform Data ) LP5521 and LP5523/55231 have own specific platform data. However, this data can be handled with just one platform data structure. The lp55xx platform data is declared in the header. This structure is derived from leds-lp5521.h and leds-lp5523.h Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-05 13:01:23 +04:00
select LEDS_LP55XX_COMMON
leds: update LP552x support Kconfig and Makefile Provide configuration and compilation support for LP5521 and LP5523 Signed-off-by: Samu Onkalo <samu.p.onkalo@nokia.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-11-12 01:05:23 +03:00
help
leds-lp5523: support new LP55231 device New TI LP55231 device has same I2C register layout as LP5523. Therefore, all of LED operations can be shared with the LP5523 driver. To support new LP55231 device explicitly, the device description is added in the configuration file. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-04 11:06:11 +04:00
If you say yes here you get support for TI/National Semiconductor
LP5523/55231 LED driver.
It is 9 channel chip with programmable engines.
leds: update LP552x support Kconfig and Makefile Provide configuration and compilation support for LP5521 and LP5523 Signed-off-by: Samu Onkalo <samu.p.onkalo@nokia.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-11-12 01:05:23 +03:00
Driver provides direct control via LED class and interface for
programming the engines.
leds: add new LP5562 LED driver LP5562 can drive up to 4 channels, RGB and White. LEDs can be controlled directly via the led class control interface. LP55xx common driver LP5562 is one of LP55xx family device, so LP55xx common code are used. On the other hand, chip specific configuration is defined in the structure 'lp55xx_device_config' LED pattern data LP5562 has also internal program memory which is used for running various LED patterns. LP5562 driver supports the firmware interface and the predefined pattern data as well. LP5562 device attributes: 'led_pattern' and 'engine_mux' A 'led_pattern' is an index code which runs the predefined pattern data. And 'engine_mux' is updated with the firmware interface is activated. Detailed description has been updated in the documentation files, 'leds-lp55xx.txt' and 'leds-lp5562.txt'. Changes on the header file LP5562 configurable definitions are added. Pattern RGB data is fixed as constant value. (No side effect on other devices, LP5521 or LP5523.) (cooloney@gmail.com: remove redundant mutex_unlock(). Reported by Dan Carpenter <dan.carpenter@oracle.com>) Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-19 09:10:14 +04:00
config LEDS_LP5562
tristate "LED Support for TI LP5562 LED driver chip"
depends on LEDS_CLASS && I2C
select LEDS_LP55XX_COMMON
help
If you say yes here you get support for TI LP5562 LED driver.
It is 4 channels chip with programmable engines.
Driver provides direct control via LED class and interface for
programming the engines.
leds: add new lp8788 led driver TI LP8788 PMU has the current sink as the keyboard led driver. The brightness is controlled by the i2c commands. Configurable parameters can be defined in the platform side. Patch v2. (a) use workqueue on changing the brightness (b) use mutex_lock/unlock when the brightness is set and the led block of lp8788 device is enabled (c) remove err_dev on _probe() : just return as returned value if any errors (d) replace module_init/exit() with module_platform_driver() (e) add led configuration structure and loading them by default if platform data is null Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-20 12:43:59 +04:00
config LEDS_LP8788
tristate "LED support for the TI LP8788 PMIC"
depends on LEDS_CLASS
depends on MFD_LP8788
help
This option enables support for the Keyboard LEDs on the LP8788 PMIC.
leds: Add clevo notebook LED driver The driver supports the mail LED commonly found on different Clevo notebooks. The driver access the LED through the i8042 hardware which is handled by the input subsystem. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-10-31 13:46:41 +03:00
config LEDS_CLEVO_MAIL
leds: remove experimental flag from leds-clevo-mail The leds-clevo-mail driver is in the mainline kernel since 2.6.25 and works without severe problems. Make this driver available for a larger audience. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-04-03 09:42:47 +04:00
tristate "Mail LED on Clevo notebook"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on X86 && SERIO_I8042 && DMI
leds: Add clevo notebook LED driver The driver supports the mail LED commonly found on different Clevo notebooks. The driver access the LED through the i8042 hardware which is handled by the input subsystem. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-10-31 13:46:41 +03:00
help
This driver makes the mail LED accessible from userspace
programs through the leds subsystem. This LED have three
known mode: off, blink at 0.5Hz and blink at 1Hz.
leds: hw acceleration for Clevo mail LED driver Add support for hardware accelerated LED blinking for the mail LED commonly found on Clevo notebooks. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-10-31 17:09:05 +03:00
The driver supports two kinds of interface: using ledtrig-timer
or through /sys/class/leds/clevo::mail/brightness. As this LED
cannot change it's brightness it blinks instead. The brightness
value 0 means off, 1..127 means blink at 0.5Hz and 128..255 means
blink at 1Hz.
leds: Add clevo notebook LED driver The driver supports the mail LED commonly found on different Clevo notebooks. The driver access the LED through the i8042 hardware which is handled by the input subsystem. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-10-31 13:46:41 +03:00
This module can drive the mail LED for the following notebooks:
leds: Add mail LED support for "Clevo D400P" The leds-clevo-mail module also works with model "Clevo D400P", add this model to the white list. Signed-off-by: Mrton Nmeth <nm127@freemail.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-03-09 23:47:59 +03:00
Clevo D400P
leds: Add clevo notebook LED driver The driver supports the mail LED commonly found on different Clevo notebooks. The driver access the LED through the i8042 hardware which is handled by the input subsystem. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-10-31 13:46:41 +03:00
Clevo D410J
Clevo D410V
Clevo D400V/D470V (not tested, but might work)
Clevo M540N
Clevo M5x0N (not tested, but might work)
Positivo Mobile (Clevo M5x0V)
leds: Add mail LED support for "Clevo D400P" The leds-clevo-mail module also works with model "Clevo D400P", add this model to the white list. Signed-off-by: Mrton Nmeth <nm127@freemail.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-03-09 23:47:59 +03:00
If your model is not listed here you can try the "nodetect"
trivial: fix typos/grammar errors in Kconfig texts Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-01-26 13:12:25 +03:00
module parameter.
leds: Add mail LED support for "Clevo D400P" The leds-clevo-mail module also works with model "Clevo D400P", add this model to the white list. Signed-off-by: Mrton Nmeth <nm127@freemail.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-03-09 23:47:59 +03:00
leds: Add clevo notebook LED driver The driver supports the mail LED commonly found on different Clevo notebooks. The driver access the LED through the i8042 hardware which is handled by the input subsystem. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-10-31 13:46:41 +03:00
To compile this driver as a module, choose M here: the
module will be called leds-clevo-mail.
leds: Add support for Philips PCA955x I2C LED drivers This driver supports the PCA9550, PCA9551, PCA9552, and PCA9553 LED driver chips. Signed-off-by: Nate Case <ncase@xes-inc.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-07-17 01:49:55 +04:00
config LEDS_PCA955X
tristate "LED Support for PCA955x I2C chips"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on I2C
leds: Add support for Philips PCA955x I2C LED drivers This driver supports the PCA9550, PCA9551, PCA9552, and PCA9553 LED driver chips. Signed-off-by: Nate Case <ncase@xes-inc.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-07-17 01:49:55 +04:00
help
This option enables support for LEDs connected to PCA955x
LED driver chips accessed via the I2C bus. Supported
devices include PCA9550, PCA9551, PCA9552, and PCA9553.
drivers/leds: add driver for PCA9633 I2C chip Driver for the PCA9633 I2C chip supporting four LEDs and 255 brightness levels. [akpm@linux-foundation.org: fix kcalloc() call] [axel.lin@gmail.com: fix kcalloc parameters swapped] Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com> Signed-off-by: Axel Lin <axel.lin@gmail.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-03-24 02:02:10 +04:00
config LEDS_PCA9633
tristate "LED support for PCA9633 I2C chip"
depends on LEDS_CLASS
depends on I2C
help
This option enables support for LEDs connected to the PCA9633
LED driver chip accessed via the I2C bus.
leds: Add WM831x status LED driver The WM831x devices feature two software controlled status LEDs with hardware assisted blinking. The device can also autonomously control the LEDs based on a selection of sources. This can be configured at boot time using either platform data or the chip OTP. A sysfs file in the style of that for triggers allowing the control source to be configured at run time. Triggers can't be used here since they can't depend on the implementation details of a specific LED type. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-09-05 17:09:21 +04:00
config LEDS_WM831X_STATUS
tristate "LED support for status LEDs on WM831x PMICs"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on MFD_WM831X
leds: Add WM831x status LED driver The WM831x devices feature two software controlled status LEDs with hardware assisted blinking. The device can also autonomously control the LEDs based on a selection of sources. This can be configured at boot time using either platform data or the chip OTP. A sysfs file in the style of that for triggers allowing the control source to be configured at run time. Triggers can't be used here since they can't depend on the implementation details of a specific LED type. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-09-05 17:09:21 +04:00
help
This option enables support for the status LEDs of the WM831x
series of PMICs.
leds: Add WM8350 LED driver The voltage and current regulators on the WM8350 AudioPlus PMIC can be used in concert to provide a power efficient LED driver. This driver implements support for this within the standard LED class. Platform initialisation code should configure the LED hardware in the init callback provided by the WM8350 core driver. The callback should use wm8350_isink_set_flash(), wm8350_dcdc25_set_mode() and wm8350_dcdc_set_slot() to configure the operating parameters of the regulators for their hardware and then then use wm8350_register_led() to instantiate the LED driver. This driver was originally written by Liam Girdwood, though it has been extensively modified since then. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2008-12-04 19:52:33 +03:00
config LEDS_WM8350
tristate "LED Support for WM8350 AudioPlus PMIC"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on MFD_WM8350
leds: Add WM8350 LED driver The voltage and current regulators on the WM8350 AudioPlus PMIC can be used in concert to provide a power efficient LED driver. This driver implements support for this within the standard LED class. Platform initialisation code should configure the LED hardware in the init callback provided by the WM8350 core driver. The callback should use wm8350_isink_set_flash(), wm8350_dcdc25_set_mode() and wm8350_dcdc_set_slot() to configure the operating parameters of the regulators for their hardware and then then use wm8350_register_led() to instantiate the LED driver. This driver was originally written by Liam Girdwood, though it has been extensively modified since then. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2008-12-04 19:52:33 +03:00
help
This option enables support for LEDs driven by the Wolfson
Microelectronics WM8350 AudioPlus PMIC.
leds: da903x: Add support for LEDs found on DA9030/DA9034 Signed-off-by: Mike Rapoport <mike@compulab.co.il> Signed-off-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2008-10-13 12:06:10 +04:00
config LEDS_DA903X
tristate "LED Support for DA9030/DA9034 PMIC"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on PMIC_DA903X
leds: da903x: Add support for LEDs found on DA9030/DA9034 Signed-off-by: Mike Rapoport <mike@compulab.co.il> Signed-off-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2008-10-13 12:06:10 +04:00
help
This option enables support for on-chip LED drivers found
on Dialog Semiconductor DA9030/DA9034 PMICs.
leds: driver for DA9052/53 PMIC v2 LED Driver for Dialog Semiconductor DA9052/53 PMICs. [akpm@linux-foundation.org: make led_reg static] Signed-off-by: David Dajun Chen <dchen@diasemi.com> Signed-off-by: Ashish Jangam <ashish.jangam@kpitcummins.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Bryan Wu <bryan.wu@canonical.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-30 02:07:26 +04:00
config LEDS_DA9052
tristate "Dialog DA9052/DA9053 LEDS"
depends on LEDS_CLASS
depends on PMIC_DA9052
help
This option enables support for on-chip LED drivers found
on Dialog Semiconductor DA9052-BC and DA9053-AA/Bx PMICs.
leds: Add dac124s085 driver Add an LED driver using the DAC124S085 DAC from NatSemi [randy.dunlap@oracle.com: use header files for interfaces] Signed-off-by: Guennadi Liakhovetski <lg@denx.de> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-01-10 21:58:28 +03:00
config LEDS_DAC124S085
tristate "LED Support for DAC124S085 SPI DAC"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on SPI
leds: Add dac124s085 driver Add an LED driver using the DAC124S085 DAC from NatSemi [randy.dunlap@oracle.com: use header files for interfaces] Signed-off-by: Guennadi Liakhovetski <lg@denx.de> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-01-10 21:58:28 +03:00
help
This option enables support for DAC124S085 SPI DAC from NatSemi,
which can be used to control up to four LEDs.
leds: simple driver for pwm driven LEDs Add a simple driver for pwm driver LEDs. pwm_id and period can be defined in board file. It is developed for pxa, however it is probably generic enough to be used on other platforms with pwm. Signed-off-by: Luotao Fu <l.fu@pengutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-02-12 00:24:40 +03:00
config LEDS_PWM
tristate "PWM driven LED Support"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: leds-pwm: make it depend on PWM and not HAVE_PWM The correct dependency for the leds-pwm is PWM and not HAVE_PWM since PWM drivers now have their own subsystem. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-01-23 12:35:04 +04:00
depends on PWM
leds: simple driver for pwm driven LEDs Add a simple driver for pwm driver LEDs. pwm_id and period can be defined in board file. It is developed for pxa, however it is probably generic enough to be used on other platforms with pwm. Signed-off-by: Luotao Fu <l.fu@pengutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-02-12 00:24:40 +03:00
help
This option enables support for pwm driven LEDs
leds: Add LED class driver for regulator driven LEDs. This driver provides an interface for controlling LEDs (or vibrators) connected to PMICs for which there is a regulator framework driver. This driver can be used, for instance, to control vibrator on all Motorola EZX phones using the pcap-regulator driver services. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-12-07 17:08:13 +03:00
config LEDS_REGULATOR
tristate "REGULATOR driven LED support"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on REGULATOR
leds: Add LED class driver for regulator driven LEDs. This driver provides an interface for controlling LEDs (or vibrators) connected to PMICs for which there is a regulator framework driver. This driver can be used, for instance, to control vibrator on all Motorola EZX phones using the pcap-regulator driver services. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-12-07 17:08:13 +03:00
help
This option enables support for regulator driven LEDs.
leds: add BD2802GU LED driver ROHM BD2802GU is a RGB LED controller attached to i2c bus and specifically engineered for decoration purposes. This RGB controller incorporates lighting patterns and illuminates. This driver is designed to minimize power consumption, so when there is no emitting LED, it enters to reset state. And because the BD2802GU has lots of features that can't be covered by the current LED framework, it provides Advanced Configuration Function(ADF) mode, so that user applications can set registers of BD2802GU directly. Here are basic usage examples : ; to turn on LED (not blink) $ echo 1 > /sys/class/leds/led1_R/brightness ; to blink LED $ echo timer > /sys/class/leds/led1_R/trigger $ echo 1 > /sys/class/leds/led1_R/delay_on $ echo 1 > /sys/class/leds/led1_R/delay_off ; to turn off LED $ echo 0 > /sys/class/leds/led1_R/brightness [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Kim Kyuwon <chammoru@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-03-04 22:59:29 +03:00
config LEDS_BD2802
tristate "LED driver for BD2802 RGB LED"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on I2C
leds: add BD2802GU LED driver ROHM BD2802GU is a RGB LED controller attached to i2c bus and specifically engineered for decoration purposes. This RGB controller incorporates lighting patterns and illuminates. This driver is designed to minimize power consumption, so when there is no emitting LED, it enters to reset state. And because the BD2802GU has lots of features that can't be covered by the current LED framework, it provides Advanced Configuration Function(ADF) mode, so that user applications can set registers of BD2802GU directly. Here are basic usage examples : ; to turn on LED (not blink) $ echo 1 > /sys/class/leds/led1_R/brightness ; to blink LED $ echo timer > /sys/class/leds/led1_R/trigger $ echo 1 > /sys/class/leds/led1_R/delay_on $ echo 1 > /sys/class/leds/led1_R/delay_off ; to turn off LED $ echo 0 > /sys/class/leds/led1_R/brightness [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Kim Kyuwon <chammoru@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-03-04 22:59:29 +03:00
help
This option enables support for BD2802GU RGB LED driver chips
accessed via the I2C bus.
leds: LED driver for Intel NAS SS4200 series (v5) This code is based on a driver that came in the "Open-source and GPL components" download here: http://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Server+Products&ProductLine=Intel%C2%AE+Storage+Systems&ProductProduct=Intel%C2%AE+Entry+Storage+System+SS4200-E&OSVersion=OS+Independent It was in a file called nasgpio.c inside of a second zip file called SS4200-E_Linux_SIO_Driver-v1.4.zip and is based on this updated to use the LED subsystem with the ioctl and hardware monitor support removed. I don't have any need for brightness control, and its code is *completely* separate from the on/off controls implemented here. If anyone else wants it, I'd be happy to look into adding it, but I don't care enough for now. Except for the probe routines, I rewrote most of it. I also Note that I don't have any hardware documentation except for the original driver. Thanks go to Arjan for his help in getting the original source for this released and for chasing down some licensing issues. Signed-off-by: Dave Hansen <dave@sr71.net> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-10-02 02:43:32 +04:00
config LEDS_INTEL_SS4200
tristate "LED driver for Intel NAS SS4200 series"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on PCI && DMI
leds: LED driver for Intel NAS SS4200 series (v5) This code is based on a driver that came in the "Open-source and GPL components" download here: http://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Server+Products&ProductLine=Intel%C2%AE+Storage+Systems&ProductProduct=Intel%C2%AE+Entry+Storage+System+SS4200-E&OSVersion=OS+Independent It was in a file called nasgpio.c inside of a second zip file called SS4200-E_Linux_SIO_Driver-v1.4.zip and is based on this updated to use the LED subsystem with the ioctl and hardware monitor support removed. I don't have any need for brightness control, and its code is *completely* separate from the on/off controls implemented here. If anyone else wants it, I'd be happy to look into adding it, but I don't care enough for now. Except for the probe routines, I rewrote most of it. I also Note that I don't have any hardware documentation except for the original driver. Thanks go to Arjan for his help in getting the original source for this released and for chasing down some licensing issues. Signed-off-by: Dave Hansen <dave@sr71.net> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-10-02 02:43:32 +04:00
help
This option enables support for the Intel SS4200 series of
Network Attached Storage servers. You may control the hard
drive or power LEDs on the front panel. Using this driver
can stop the front LED from blinking after startup.
leds: Add driver for LT3593 controlled LEDs The LT3593 is a step-up DC/DC converter designed to drive up to ten white LEDs in series. The current flow can be set with a control pin. This driver controls any number of such devices connected on generic GPIOs and exports the function as as platform_driver. The gpio_led platform data struct definition is reused for this purpose. Successfully tested on a PXA embedded board. Signed-off-by: Daniel Mack <daniel@caiaq.de> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-10-15 04:59:35 +04:00
config LEDS_LT3593
tristate "LED driver for LT3593 controllers"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
Convert selectors of GENERIC_GPIO to GPIOLIB GENERIC_GPIO is now equivalent to GPIOLIB and features that depended on GENERIC_GPIO can now depend on GPIOLIB to allow removal of this option. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca>
2013-03-28 15:34:56 +04:00
depends on GPIOLIB
leds: Add driver for LT3593 controlled LEDs The LT3593 is a step-up DC/DC converter designed to drive up to ten white LEDs in series. The current flow can be set with a control pin. This driver controls any number of such devices connected on generic GPIOs and exports the function as as platform_driver. The gpio_led platform data struct definition is reused for this purpose. Successfully tested on a PXA embedded board. Signed-off-by: Daniel Mack <daniel@caiaq.de> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-10-15 04:59:35 +04:00
help
This option enables support for LEDs driven by a Linear Technology
LT3593 controller. This controller uses a special one-wire pulse
coding protocol to set the brightness.
leds: Add driver for ADP5520/ADP5501 MFD PMICs Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-10-08 12:00:19 +04:00
config LEDS_ADP5520
tristate "LED Support for ADP5520/ADP5501 PMIC"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
depends on PMIC_ADP5520
leds: Add driver for ADP5520/ADP5501 MFD PMICs Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-10-08 12:00:19 +04:00
help
This option enables support for on-chip LED drivers found
on Analog Devices ADP5520/ADP5501 PMICs.
To compile this driver as a module, choose M here: the module will
be called leds-adp5520.
leds: Add Dell Business Class Netbook LED driver This patch adds an LED driver to support the Dell Activity LED on the Dell Latitude 2100 netbook and future products to come. The Activity LED is visible externally in the lid so classroom instructors can observe it from a distance. The driver uses the sysfs led_class and provides a standard LED interface. Signed-off by: Bob Rodgers <Robert_Rodgers@dell.com> Signed-off-by: Louis Davis <Louis_Davis@dell.com> Signed-off-by: Jim Dailey <Jim_Dailey@dell.com>, Developers Acked-by: Matthew Garrett <mjg@redhat.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-02-18 00:23:31 +03:00
config LEDS_DELL_NETBOOKS
tristate "External LED on Dell Business Netbooks"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Add Dell Business Class Netbook LED driver This patch adds an LED driver to support the Dell Activity LED on the Dell Latitude 2100 netbook and future products to come. The Activity LED is visible externally in the lid so classroom instructors can observe it from a distance. The driver uses the sysfs led_class and provides a standard LED interface. Signed-off by: Bob Rodgers <Robert_Rodgers@dell.com> Signed-off-by: Louis Davis <Louis_Davis@dell.com> Signed-off-by: Jim Dailey <Jim_Dailey@dell.com>, Developers Acked-by: Matthew Garrett <mjg@redhat.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-02-18 00:23:31 +03:00
depends on X86 && ACPI_WMI
help
This adds support for the Latitude 2100 and similar
notebooks that have an external LED.
leds: Add mc13783 LED support This add basic led support for Freescale MC13783 PMIC. Signed-off-by: Philippe Rétornaz <philippe.retornaz@epfl.ch> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-05-19 11:24:31 +04:00
config LEDS_MC13783
leds: leds-mc13783: Add MC13892 LED support Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Tested-by: Philippe Retornaz <philippe.retornaz@epfl.ch> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-10 20:59:31 +04:00
tristate "LED Support for MC13XXX PMIC"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: leds-mc13783: Add MC13892 LED support Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Tested-by: Philippe Retornaz <philippe.retornaz@epfl.ch> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-10 20:59:31 +04:00
depends on MFD_MC13XXX
leds: Add mc13783 LED support This add basic led support for Freescale MC13783 PMIC. Signed-off-by: Philippe Rétornaz <philippe.retornaz@epfl.ch> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-05-19 11:24:31 +04:00
help
This option enable support for on-chip LED drivers found
leds: leds-mc13783: Add MC13892 LED support Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Tested-by: Philippe Retornaz <philippe.retornaz@epfl.ch> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-10 20:59:31 +04:00
on Freescale Semiconductor MC13783/MC13892 PMIC.
leds: Add mc13783 LED support This add basic led support for Freescale MC13783 PMIC. Signed-off-by: Philippe Rétornaz <philippe.retornaz@epfl.ch> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-05-19 11:24:31 +04:00
leds: add LED driver for Network Space v2 LEDs This patch add a LED class driver for the dual-GPIO LEDs found on the Network Space v2 board (and parents). This include Internet Space v2, Network Space (Max) v2 and d2 Network v2 boards. This dual-GPIO LED is wired to a CPLD and can blink in relation with the SATA activity. The driver expose this capability through a "sata" sysfs attribute. Signed-off-by: Simon Guinot <sguinot@lacie.com> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
2010-07-06 18:08:46 +04:00
config LEDS_NS2
tristate "LED support for Network Space v2 GPIO LEDs"
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-03 01:31:14 +03:00
depends on LEDS_CLASS
leds: Kconfig: Fix typo 'D2NET_V2' Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Acked-by: Simon Guinot <sguinot@lacie.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:25:42 +04:00
depends on MACH_NETSPACE_V2 || MACH_INETSPACE_V2 || \
ARM: kirkwood: DT board setup for Network Space v2 and parents This patch adds DT board setup for LaCie Network Space v2 and parents, based on the Marvell Kirkwood 6281 SoC. This includes Network Space v2 (Max) and Internet Space v2. Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-10-17 14:09:04 +04:00
MACH_NETSPACE_MAX_V2 || MACH_D2NET_V2 || \
MACH_NETSPACE_V2_DT || MACH_INETSPACE_V2_DT || \
ARM: kirkwood: DT board setup for Network Space Mini v2 This patch adds DT board setup for the LaCie NAS Network Space Mini v2 (aka SafeBox). The hardware characteristics are very close to those of the Network Space Lite v2. The main difference are: - A GPIO fan which is only available on the NS2 Mini. - A single USB host port is wired on the NS2 Mini. The NS2 Lite provides an additional dual-mode USB port (host/device). Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-10-17 14:09:06 +04:00
MACH_NETSPACE_MAX_V2_DT || MACH_NETSPACE_MINI_V2_DT
leds: add LED driver for Network Space v2 LEDs This patch add a LED class driver for the dual-GPIO LEDs found on the Network Space v2 board (and parents). This include Internet Space v2, Network Space (Max) v2 and d2 Network v2 boards. This dual-GPIO LED is wired to a CPLD and can blink in relation with the SATA activity. The driver expose this capability through a "sata" sysfs attribute. Signed-off-by: Simon Guinot <sguinot@lacie.com> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
2010-07-06 18:08:46 +04:00
default y
help
This option enable support for the dual-GPIO LED found on the
Network Space v2 board (and parents). This include Internet Space v2,
Network Space (Max) v2 and d2 Network v2 boards.
leds: add LED driver for Big Network series LEDs This patch add a LED class driver for LEDs found on the LaCie 2Big and 5Big Network v2 boards. The LEDs are wired to a CPLD and are controlled through a GPIO extension bus. Signed-off-by: Simon Guinot <sguinot@lacie.com> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
2010-10-07 18:38:49 +04:00
config LEDS_NETXBIG
tristate "LED support for Big Network series LEDs"
depends on MACH_NET2BIG_V2 || MACH_NET5BIG_V2
drivers/leds/leds-netxbig: make LEDS_NETXBIG depend on LEDS_CLASS We call led_classdev_register/led_classdev_unregister in create_netxbig_led/delete_netxbig_led, thus make LEDS_NETXBIG depend on LEDS_CLASS. This patch fixes below build error if LEDS_CLASS is not configured. LD .tmp_vmlinux1 drivers/built-in.o: In function `create_netxbig_led': drivers/leds/leds-netxbig.c:350: undefined reference to `led_classdev_register' drivers/leds/leds-netxbig.c:361: undefined reference to `led_classdev_unregister' drivers/built-in.o: In function `delete_netxbig_led': drivers/leds/leds-netxbig.c:313: undefined reference to `led_classdev_unregister' Signed-off-by: Axel Lin <axel.lin@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Acked-by: Simon Guinot <sguinot@lacie.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-07-26 04:13:16 +04:00
depends on LEDS_CLASS
leds: add LED driver for Big Network series LEDs This patch add a LED class driver for LEDs found on the LaCie 2Big and 5Big Network v2 boards. The LEDs are wired to a CPLD and are controlled through a GPIO extension bus. Signed-off-by: Simon Guinot <sguinot@lacie.com> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
2010-10-07 18:38:49 +04:00
default y
help
This option enable support for LEDs found on the LaCie 2Big
and 5Big Network v2 boards. The LEDs are wired to a CPLD and are
controlled through a GPIO extension bus.
leds: Add ASIC3 LED support Add LED support for the HTC ASIC3. Underlying support is provided by the mfd/asic3 and leds/leds-asic3 drivers. An example configuration is provided by the pxa/hx4700 platform. Signed-off-by: Paul Parsons <lost.distance@yahoo.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2011-05-13 22:52:56 +04:00
config LEDS_ASIC3
bool "LED support for the HTC ASIC3"
leds: Make LEDS_ASIC3 and LEDS_RENESAS_TPU depend on LEDS_CLASS=y Otherwise, I got below build error when CONFIG_LEDS_CLASS=m. LD init/built-in.o drivers/built-in.o: In function `asic3_led_probe': clkdev.c:(.devinit.text+0x4680): undefined reference to `led_classdev_register' drivers/built-in.o: In function `r_tpu_probe': clkdev.c:(.devinit.text+0x4838): undefined reference to `led_classdev_register' drivers/built-in.o: In function `asic3_led_remove': clkdev.c:(.devexit.text+0x564): undefined reference to `led_classdev_unregister' drivers/built-in.o: In function `r_tpu_remove': clkdev.c:(.devexit.text+0x5a0): undefined reference to `led_classdev_unregister' make: *** [vmlinux] Error 1 Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-06-09 03:41:42 +04:00
depends on LEDS_CLASS=y
leds: Add ASIC3 LED support Add LED support for the HTC ASIC3. Underlying support is provided by the mfd/asic3 and leds/leds-asic3 drivers. An example configuration is provided by the pxa/hx4700 platform. Signed-off-by: Paul Parsons <lost.distance@yahoo.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2011-05-13 22:52:56 +04:00
depends on MFD_ASIC3
default y
help
This option enables support for the LEDs on the HTC ASIC3. The HTC
ASIC3 LED GPIOs are inputs, not outputs, thus the leds-gpio driver
cannot be used. This driver supports hardware blinking with an on+off
period from 62ms to 125s. Say Y to enable LEDs on the HP iPAQ hx4700.
leds: add driver for TCA6507 LED controller TI's TCA6507 is the LED driver in the GTA04 Openmoko motherboard. The driver provides full support for brightness levels and hardware blinking. This driver can drive each of 7 outputs as an LED or a GPIO output, and provides hardware-assist blinking. [akpm@linux-foundation.org: fix __mod_i2c_device_table alias] [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: NeilBrown <neilb@suse.de> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Randy Dunlap <rdunlap@xenotime.net> Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-01-11 03:09:40 +04:00
config LEDS_TCA6507
tristate "LED Support for TCA6507 I2C chip"
depends on LEDS_CLASS && I2C
help
This option enables support for LEDs connected to TC6507
LED driver chips accessed via the I2C bus.
Driver support brightness control and hardware-assisted blinking.
leds: Add suuport for MAX8997-LED driver This patch enables LED controller in MAX8997 PMIC. Signed-off-by: Donggeun Kim <dg77.kim@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2011-12-14 13:23:56 +04:00
config LEDS_MAX8997
tristate "LED support for MAX8997 PMIC"
depends on LEDS_CLASS && MFD_MAX8997
help
This option enables support for on-chip LED drivers on
MAXIM MAX8997 PMIC.
leds: Add new LED driver for lm355x chips This driver is a general version for LM355x,lm3554 and lm3556,led chips of TI. LM3554 : The LM3554 is a 2 MHz fixed-frequency synchronous boost converter with 1.2A dual high side led drivers. Datasheet: www.ti.com/lit/ds/symlink/lm3554.pdf LM3556 : The LM3556 is a 4 MHz fixed-frequency synchronous boost converter plus 1.5A constant current driver for a high-current white LED. Datasheet: www.national.com/ds/LM/LM3556.pdf (bryan.wu@canonical.com: use flush_work() to replace flush_work_sync() which is deprecated) Signed-off-by: G.Shark Jeong <gshark.jeong@gmail.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-05 11:05:58 +04:00
config LEDS_LM355x
tristate "LED support for LM355x Chips, LM3554 and LM3556"
leds: Add LED driver for lm3556 chip LM3556 : The LM3556 is a 4 MHz fixed-frequency synchronous boost converter plus 1.5A constant current driver for a high-current white LED. Datasheet: www.national.com/ds/LM/LM3556.pdf Tested on OMAP4430 (bryan.wu@canonical.com: use module_i2c_driver() rather than lm3556_init/lm3556_exit for code simplicity; fixed some typo pointed out by Rob Landley) Signed-off-by: G.Shark Jeong <gshark.jeong@gmail.com> Reviewed-by: Axel Lin <axel.lin@gmail.com> Reviewed-by: Kim, Milo <Milo.Kim@ti.com> Acked-by: Rob Landley <rob@landley.net> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-06-22 04:12:06 +04:00
depends on LEDS_CLASS && I2C
select REGMAP_I2C
help
leds: Add new LED driver for lm355x chips This driver is a general version for LM355x,lm3554 and lm3556,led chips of TI. LM3554 : The LM3554 is a 2 MHz fixed-frequency synchronous boost converter with 1.2A dual high side led drivers. Datasheet: www.ti.com/lit/ds/symlink/lm3554.pdf LM3556 : The LM3556 is a 4 MHz fixed-frequency synchronous boost converter plus 1.5A constant current driver for a high-current white LED. Datasheet: www.national.com/ds/LM/LM3556.pdf (bryan.wu@canonical.com: use flush_work() to replace flush_work_sync() which is deprecated) Signed-off-by: G.Shark Jeong <gshark.jeong@gmail.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-05 11:05:58 +04:00
This option enables support for LEDs connected to LM355x.
LM355x includes Torch, Flash and Indicator functions.
leds: Add LED driver for lm3556 chip LM3556 : The LM3556 is a 4 MHz fixed-frequency synchronous boost converter plus 1.5A constant current driver for a high-current white LED. Datasheet: www.national.com/ds/LM/LM3556.pdf Tested on OMAP4430 (bryan.wu@canonical.com: use module_i2c_driver() rather than lm3556_init/lm3556_exit for code simplicity; fixed some typo pointed out by Rob Landley) Signed-off-by: G.Shark Jeong <gshark.jeong@gmail.com> Reviewed-by: Axel Lin <axel.lin@gmail.com> Reviewed-by: Kim, Milo <Milo.Kim@ti.com> Acked-by: Rob Landley <rob@landley.net> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-06-22 04:12:06 +04:00
leds: add led driver for Bachmann's ot200 Add support for leds on Bachmann's ot200 visualisation device. The device has three leds on the back panel (led_err, led_init and led_run) and can handle up to seven leds on the front panel. The driver was written by Linutronix on behalf of Bachmann electronic GmbH. It incorporates feedback from Lars-Peter Clausen [akpm@linux-foundation.org: add dependency on HAS_IOMEM] Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-01-21 02:33:59 +04:00
config LEDS_OT200
tristate "LED support for the Bachmann OT200"
depends on LEDS_CLASS && HAS_IOMEM
help
This option enables support for the LEDs on the Bachmann OT200.
Say Y to enable LEDs on the Bachmann OT200.
LEDS: add BlinkM RGB LED driver, documentation and update MAINTAINERS Add driver for BlinkM device to drivers/leds/. Add entry to MAINTAINERS file. Add documentation in Documentation/leds/. A BlinkM is a RGB LED controlled through I2C. This driver implements an interface to the LED framework and another sysfs group to access the internal options of the BlinkM. rev6: Use module_i2c_driver(). rev5: Removed own workqueue in favor of events wq. rev4: Fixed comments by Bryan Wu. rev3: Fixed issues found by Jonathan Neuschäfer. (bryan.wu@canonical.com: remove 2 trailing whitespace) Signed-off-by: Jan-Simon Möller <jansimon.moeller@gmx.de> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-20 12:49:06 +04:00
config LEDS_BLINKM
tristate "LED support for the BlinkM I2C RGB LED"
depends on LEDS_CLASS
depends on I2C
help
This option enables support for the BlinkM RGB LED connected
through I2C. Say Y to enable support for the BlinkM LED.
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-21 02:08:30 +03:00
comment "LED Triggers"
leds: move LED trigger drivers into new subdirectory For better driver management, new subdirectory, 'trigger' is created. All LED trigger drivers are moved into this directory. Internal header, 'leds.h' is included in each LED trigger drivers. Fix the location of header file, "leds.h" -> "../leds.h" in driver files. One exception is here, 'ledtrig-timer.c'. There is no need to include 'leds.h'. so '#include "leds.h"' line was removed. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-20 12:36:01 +04:00
source "drivers/leds/trigger/Kconfig"
leds: add new transient trigger for one shot timer activation 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. 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. Signed-off-by: Shuah Khan <shuahkhan@gmail.com> Cc: Jonas Bonn <jonas@southpole.se> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: NeilBrown <neilb@suse.de> Cc: Bryan Wu <bryan.wu@canonical.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-30 02:07:30 +04:00
leds: Use menuconfig objects II - LED Change Kconfig objects from "menu, config" into "menuconfig" so that the user can disable the whole feature without having to enter the menu first. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-05-10 13:44:11 +04:00
endif # NEW_LEDS