Commit Graph

16 Commits

Author SHA1 Message Date
Trent Piepho ed88bae691 leds: Add options to have GPIO LEDs start on or keep their state
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: Trent Piepho <xyzzy@speakeasy.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Sean MacLennan <smaclennan@pikatech.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-06-23 20:21:39 +01:00
Zhenwen Xu 7fd02170e2 leds: leds-gpio - fix a section mismatch
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: Zhenwen Xu <helight.xu@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-06-23 20:20:11 +01:00
David Brownell ac15e95090 leds: just ignore invalid GPIOs in leds-gpio
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: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-04-08 14:13:48 +01:00
David Brownell d379ee8acd leds: just ignore invalid GPIOs in leds-gpio
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: David Brownell <dbrownell@users.sourceforge.net>
Tested-by: Diego Dompe <diego.dompe@ridgerun.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-04-06 16:06:27 +01:00
Richard Purdie defb512d25 leds: Add suspend/resume state flags to leds-gpio
Add an option to preserve LED state when suspending/resuming to the LED
gpio driver. Based on a suggestion from Robert Jarzmik.

Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-04-06 16:06:26 +01:00
Richard Purdie b2bdc3e713 leds: Fix leds-gpio driver multiple module_init/exit usage
You can't have multiple module_init()/module_exit calls so resort to messy
ifdefs potentially pending some code refactoring.

Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-04-06 16:06:26 +01:00
Trent Piepho a7d878af94 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-04-06 16:06:25 +01:00
Richard Purdie 859cb7f2a4 leds: Add suspend/resume to the core class
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.
2009-01-08 17:55:03 +00:00
Herbert Valerio Riedel ca3259b360 leds: enable support for blink_set() platform hook in leds-gpio
Enhance leds-gpio to provide hardware-based led flashing by passing
through the blink_set() call to a optionally set platform-specific
function pointer.

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-04-24 23:37:42 +01:00
Kay Sievers 3c4ded9715 leds: fix platform driver hotplug/coldplug
Since 43cc71eed1, the platform
modalias is prefixed with "platform:". Add MODULE_ALIAS() to the
hotpluggable platform LED drivers, to re-enable auto loading.

[dbrownell@users.sourceforge.net: more drivers, registration fixes]
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-15 19:35:40 -07:00
David Brownell 306dd85c1d leds: Remove incorrect use of preempt_count() from leds-gpio
It appears that we can't just check to see if we're in a task
context ... so instead of trying that, just make the relevant
leds always schedule a little worklet.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-03-31 23:31:13 +01:00
Uwe Kleine-König d95cbe6158 leds: Fix potential leds-gpio oops
Call gpio_cansleep only after gpio_request succeeded avoiding an
oops.

Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-03-31 23:31:13 +01:00
Raphael Assenat 2b7f1b8c8f leds: Fix led-gpio active_low default brightness
When gpio_direction_output() is called, led_dat->active_low is used
as default value. This means that the led will always be off by
default. cdev.brightness should really have been set to LED_OFF
unconditionally to reflect this behavior.

Signed-off-by: Raphael Assenat <raph@8d.com>
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-02-07 09:52:02 +00:00
David Brownell 199fb21d52 leds: bugfixes for leds-gpio
Three bugfixes to the leds-gpio driver, plus minor whitespace tweaks:

 - Do the INIT_WORK() before registering each LED, so if its trigger
   becomes immediately active it can schedule work without oopsing..

 - Use normal registration, not platform_driver_probe(), so that
   devices appearing "late" (hotplug type) can still be bound.

 - Mark the driver remove code as "__devexit", preventing oopses
   when the underlying device is removed.

These issues came up when using this driver with some GPIO expanders
living on serial busses, which act unlike "normal" platform devices:
they can appear and vanish along with the serial bus driver.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-11-05 21:54:41 +00:00
David Brownell 00852279af leds: Teach leds-gpio to handle timer-unsafe GPIOs
Teach the new leds-gpio driver that some GPIOs can't be accessed from
timer callbacks ... which is how all today's standard triggers use them.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-07-16 01:15:50 +01:00
Raphael Assenat 22e03f3b58 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-07-16 01:15:50 +01:00