There already is a "default-on" trigger but there are problems with it.

For one, it's a inefficient way to do it and requires led trigger support
to be compiled in.

But the real reason is that is produces a glitch on the LED.  The GPIO is
allocate with the LED *off*, then *later* when the trigger runs it is
turned back on.  If the LED was already on via the GPIO's reset default or
action of the firmware, this produces a glitch where the LED goes from on
to off to on.  While normally this is fast enough that it wouldn't be
noticeable to a human observer, there are still serious problems.

One is that there may be something else on the GPIO line, like a hardware
alarm or watchdog, that is fast enough to notice the glitch.

Another is that the kernel may panic before the LED is turned back on, thus
hanging with the LED in the wrong state.  This is not just speculation, but
actually happened to me with an embedded system that has an LED which
should turn off when the kernel finishes booting, which was left in the
incorrect state due to a bug in the OF LED binding code.

We also let GPIO LEDs get their initial value from whatever the current
state of the GPIO line is.  On some systems the LEDs are put into some
state by the firmware or hardware before Linux boots, and it is desired to
have them keep this state which is otherwise unknown to Linux.

This requires that the underlying GPIO driver support reading the value of
output GPIOs.  Some drivers support this and some do not.

The platform device binding gains a field in the platform data
"default_state" that controls this.  There are three constants defined to
select from on, off, or keeping the current state.  The OpenFirmware
binding uses a property named "default-state" that can be set to "on",
"off", or "keep".  The default if the property isn't present is off.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NWolfram Sang <w.sang@pengutronix.de>
Acked-by: NSean MacLennan <smaclennan@pikatech.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

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: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Indent using tabs, not spaces.
Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Acked-by: NRiku Voipio <riku.voipio@iki.fi>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Remove an orphan Kconfig entry (LEDS_LP5521)
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Add initialisation of GPIO ports for compatibility with boards with Award
BIOS (e.g.  ALIX.3D3).
Signed-off-by: NTobias Mueller <Tobias_Mueller@twam.info>
Reviewed-by: NConstantin Baranov <const@mimas.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

WARNING: drivers/leds/leds-gpio.o(.text+0x153): Section mismatch in reference from the function gpio_led_probe() to the function .devinit.text:create_gpio_led()

The function gpio_led_probe() references the function __devinit
create_gpio_led().  This is often because gpio_led_probe lacks a __devinit
annotation or the annotation of create_gpio_led is wrong.
Signed-off-by: NZhenwen Xu <helight.xu@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

leds: add the sysfs interface into the leds-bd2802 driver for changing wave pattern and led current.

Allow the user application to change the wave pattern and led current by
'wave_pattern' and 'rgb_current' sysfs files.
Signed-off-by: NKim Kyuwon <q1.kim@samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Change the license to 'GPL v2'
Signed-off-by: NKim Kyuwon <q1.kim@samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

LED_CORE_SUSPENDRESUME flag is not needed in the bd2802 driver, because
all works for suspend/resume is done in bd2802_suspend and bd2802_suspend
functions.  And this patch allows bd2802 to be configured again when it
resumes from suspend.
Signed-off-by: NKim Kyuwon <q1.kim@samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Move all the gpio functions out of <mach/hardware.h> as
this file is for defining the generic IO base addresses
for the kernel IO calls.

Make a new header <mach/gpio-fns.h> to take this and
include it via the chain from <linux/gpio.h> which is
what most of these files should be using (and will be
changed as soon as possible).

Note, this does make minor changes to some drivers but
should not mess up any pending merges.

CC: Richard Purdie <rpurdie@rpsys.net>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
CC: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Fix build problems with leds-gpio:

  CC      drivers/leds/leds-gpio.o
drivers/leds/leds-gpio.c: In function 'create_gpio_led':
drivers/leds/leds-gpio.c:85: warning: 'return' with no value, in function returning non-void
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

LP5521 is a three channel led driver with support
for hardware accelerated patterns (currently used
via lp5521-only sysfs interface).

Currently, it's used on n810 device.
Signed-off-by: NFelipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Sometimes it's awkward to make sure that the array in the
platform_data handed to the leds-gpio driver has only valid
data ... some leds may not be always available, and coping
with that currently requires patching or rebuilding the array.

This patch fixes that by making it be OK to pass an invalid
GPIO (such as "-EINVAL") ... such table entries are skipped.

[rpurdie@linux.intel.com: adjusted to apply against other led tree changes]
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Tested-by: NDiego Dompe <diego.dompe@ridgerun.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

This fixes the expression in the driver to do the correct thing,
not that I think anyone would send SND_* without EV_SND.

Thanks to Roel Kluin <roel.kluin@gmail.com> for noticing.
Signed-off-by: NRiku Voipio <riku.voipio@iki.fi>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

A pointer to h1940leds_probe is passed to the core via
platform_driver_register and so the function must not disappear when the
.init sections are discarded.  Otherwise (if also having HOTPLUG=y)
unbinding and binding a device to the driver via sysfs will result in an
oops as does a device being registered late.

An alternative to this patch is using platform_driver_probe instead of
platform_driver_register plus removing the pointer to the probe function
from the struct platform_driver.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

This goto is unnecessary.
Signed-off-by: NZhenwen Xu <helight.xu@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

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: NKim Kyuwon <chammoru@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

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: NMárton Németh <nm127@freemail.hu>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Signed-off-by: NAdam Nielsen <a.nielsen@shikadi.net>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

The gpio led trigger will allow leds to be triggered by
gpio events.

When we give the led a gpio number, the trigger will
request_irq() on that so we don't have to keep polling
for gpio state.

It's useful for usecases as n810's keypad leds that could
be triggered by the gpio event generated when user slides
up to show the keypad.

We also provide means for userland to tell us what is the
desired brightness for that special led when it goes on
so userland could use information from ambient light sensors
and not set led brightness too high if it's not necessary.
Signed-off-by: NFelipe Balbi <me@felipebalbi.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

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: NPhil Sutter <n0-1@freewrt.org>
Acked-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Add an option to preserve LED state when suspending/resuming to the LED
gpio driver. Based on a suggestion from Robert Jarzmik.
Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

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: NLuotao Fu <l.fu@pengutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

You can't have multiple module_init()/module_exit calls so resort to messy
ifdefs potentially pending some code refactoring.
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Add an LED driver using the DAC124S085 DAC from NatSemi

[randy.dunlap@oracle.com: use header files for interfaces]
Signed-off-by: NGuennadi Liakhovetski <lg@denx.de>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

This patch allows drivers to override the default maximum brightness value
of 255.  We take care to preserve backwards-compatibility as much as
possible, so that user-space ABI doesn't change for existing drivers.
LED trigger code has also been updated to use the per-LED maximum.
Signed-off-by: NGuennadi Liakhovetski <lg@denx.de>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

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: NTrent Piepho <tpiepho@freescale.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NSean MacLennan <smaclennan@pikatech.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Update my email address.
Signed-off-by: NRiku Voipio <riku.voipio@iki.fi>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NMatt LaPlante <kernel1@cyberdogtech.com>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Kernel module providing implementation of LED netfilter target.  Each
instance of the target appears as a led-trigger device, which can be
associated with one or more LEDs in /sys/class/leds/
Signed-off-by: NAdam Nielsen <a.nielsen@shikadi.net>
Acked-by: NRichard Purdie <rpurdie@linux.intel.com>
Signed-off-by: NPatrick McHardy <kaber@trash.net>

Move the second part of the HP laptop disk protection functionality (a red
led) to the same driver.  From a purely Linux developer's point of view,
the led and the accelerometer have nothing related.  However, they
correspond to the same ACPI functionality, and so will always be used
together, moreover as they share the same ACPI PNP alias, there is no
other simple to allow to have same loaded at the same time if they are not
in the same module.  Also make it requires the led class to compile and
update the Kconfig text.
Signed-off-by: NPavel Machek <pavel@suse.cz>
Signed-off-by: NEric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NRodolfo Giometti <giometti@linux.it>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Add suspend/resume to the core class and remove all the now unneeded
code from various drivers. Originally the class code couldn't support
suspend/resume but since class_device can there is no reason for
each driver doing its own suspend/resume anymore.

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: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Apparently these might be called under atomic context,
and i2c operations may sleep. BUG found by
Ross Burton <ross@burtonini.com>
Signed-off-by: NRiku Voipio <riku.voipio@iki.fi>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

When the registration fails, we need to release the memory we allocated.
Also we need to save the error from led_classdev_register and propagate
it up, else we'll return success, even if we failed.
Signed-off-by: NRiku Voipio <riku.voipio@iki.fi>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

We want to go upwards, not downwards.
Signed-off-by: NSven Wegener <sven.wegener@stealer.net>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Cobalt Raq LEDs require LEDS_CLASS=y.
Signed-off-by: NYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

drivers/leds/leds-ams-delta.c:154:2: warning: returning void-valued expression
Signed-off-by: NSven Wegener <sven.wegener@stealer.net>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Signed-off-by: NSven Wegener <sven.wegener@stealer.net>
Signed-off-by: NRichard Purdie <rpurdie@intel.linux.com>