summaryrefslogtreecommitdiffstats
path: root/include/linux/leds.h
Commit message (Collapse)AuthorAgeFilesLines
* leds: Futher document blink_setRichard Purdie2009-06-231-1/+2
| | | | | | Futher document blink_set function pointer Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* leds: Add options to have GPIO LEDs start on or keep their stateTrent Piepho2009-06-231-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* leds: Further document parameters for blink_set()Mark Brown2009-06-231-1/+3
| | | | | | | | The documentation for the parameters of blink_set() was a bit hard to find so put some where I'd expected to find it. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* leds: Add suspend/resume state flags to leds-gpioRichard Purdie2009-04-061-1/+2
| | | | | | | | 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>
* leds: allow led-drivers to use a variable range of brightness valuesGuennadi Liakhovetski2009-04-061-0/+1
| | | | | | | | | | 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: Guennadi Liakhovetski <lg@denx.de> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* leds: Add suspend/resume to the core classRichard Purdie2009-01-081-0/+3
| | | | | | | 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.
* leds: Make header variable naming consistentWolfram Sang2009-01-081-1/+1
| | | | | | | | There is one place where the struct led_classdev as the function argument is named differently. Fix it. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* leds: Make default trigger fields constTrent Piepho2008-10-201-2/+2
| | | | | | | | | | | | | | | | The default_trigger fields of struct gpio_led and thus struct led_classdev are pretty much always assigned from a string literal, which means the string can't be modified. Which is fine, since there is no reason to modify the string and in fact it never is. But they should be marked const to prevent such code from being added, to prevent warnings if -Wwrite-strings is used, when assigned from a constant string other than a string literal (which produces a warning under current kernel compiler flags), and for general good coding practices. Signed-off-by: Trent Piepho <tpiepho@freescale.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* leds: Add support for Philips PCA955x I2C LED driversNate Case2008-07-231-0/+14
| | | | | | | | | 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>
* leds: mark led_classdev.default_trigger as constAnton Vorontsov2008-07-231-1/+1
| | | | | | | | | LED classdev core doesn't modify memory pointed by the default_trigger, so mark it as const and we'll able to pass const char *s without getting compiler warnings. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
* leds: Document the context brightness_set needsRichard Purdie2008-04-241-0/+1
| | | | | | | Make sure there is no confusion about the contexts brightness_set can be called under by documenting it. Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
* leds: Add support to leds with readable statusHenrique de Moraes Holschuh2008-04-241-0/+2
| | | | | | | | | | | | | | | | | Some led hardware allows drivers to query the led state, and this patch adds a hook to let the led class take advantage of that information when available. Without this functionality, when access to the led hardware is not exclusive (i.e. firmware or hardware might change its state behind the kernel's back), reality goes out of sync with the led class' idea of what the led is doing, which is annoying at best. Behaviour for drivers that do not or cannot read the led status is unchanged. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
* leds: enable support for blink_set() platform hook in leds-gpioHerbert Valerio Riedel2008-04-241-0/+3
| | | | | | | | | 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>
* PM: Remove destroy_suspended_device()Rafael J. Wysocki2008-04-191-9/+1
| | | | | | | | | | | | | | | | | | After 2.6.24 there was a plan to make the PM core acquire all device semaphores during a suspend/hibernation to protect itself from concurrent operations involving device objects. That proved to be too heavy-handed and we found a better way to achieve the goal, but before it happened, we had introduced the functions device_pm_schedule_removal() and destroy_suspended_device() to allow drivers to "safely" destroy a suspended device and we had adapted some drivers to use them. Now that these functions are no longer necessary, it seems reasonable to remove them and modify their users to use the normal device unregistration instead. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* leds: Add support for hardware accelerated LED flashingMárton Németh2008-02-071-0/+5
| | | | | | | | | Extends the leds subsystem with a blink_set() callback function which can be optionally implemented by a LED driver. If implemented, the driver can use the hardware acceleration for blinking a LED. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
* leds: add possibility to remove leds classdevs during suspend/resumeRafael J. Wysocki2008-02-051-1/+9
| | | | | | | | | | | | | | | | | Make it possible to unregister a led classdev object in a safe way during a suspend/resume cycle. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Michael Buesch <mb@bu3sch.de> Cc: Pavel Machek <pavel@ucw.cz> Cc: "John W. Linville" <linville@tuxdriver.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Len Brown <lenb@kernel.org> Cc: Greg KH <greg@kroah.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* leds: Fix led trigger locking bugsRichard Purdie2007-12-071-1/+2
| | | | | | | | Convert part of the led trigger core from rw spinlocks to rw semaphores. We're calling functions which can sleep from invalid contexts otherwise. Fixes bug #9264. Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
* leds: Add missing include for leds.hYoichi Yuasa2007-09-111-0/+1
| | | | | | | | This patch has added #include <linux/spinlock.h> to include/linux/leds.h for rwlock_t. Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
* Merge branch 'for-linus' of git://git.o-hand.com/linux-rpurdie-ledsLinus Torvalds2007-07-221-2/+15
|\ | | | | | | | | | | | | | | | | | | | | * 'for-linus' of git://git.o-hand.com/linux-rpurdie-leds: leds: Convert from struct class_device to struct device leds: leds-gpio for ngw100 leds: Add warning printks in error paths leds: Fix trigger unregister_simple if register_simple fails leds: Use menuconfig objects II - LED leds: Teach leds-gpio to handle timer-unsafe GPIOs leds: Add generic GPIO LED driver
| * leds: Convert from struct class_device to struct deviceRichard Purdie2007-07-161-2/+1
| | | | | | | | | | | | | | | | Convert the LEDs class from struct class_device to struct device since class_device is scheduled for removal. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
| * leds: Add generic GPIO LED driverRaphael Assenat2007-07-161-0/+14
| | | | | | | | | | | | | | | | | | | | 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>
* | Remove unnecessary includes of spinlock.h under include/linuxRobert P. J. Day2007-07-161-1/+0
|/ | | | | | | | | | Remove the obviously unnecessary includes of <linux/spinlock.h> under the include/linux/ directory, and fix the couple errors that are introduced as a result of that. Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] make leds.h include relevant headersJohannes Berg2006-09-291-0/+3
| | | | | | | | | | Make it possible to include linux/leds.h without first including list.h and spinlock.h. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] leds: re-layout include/linux/leds.hBen Dooks2006-04-111-26/+25
| | | | | | | | | | | Lay out the structure definitions in include/linux/leds.h to be aligned as much as possible. Also minor updates to the comments to make them more concise. 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>
* [PATCH] LED: Add IDE disk activity LED triggerRichard Purdie2006-03-311-0/+8
| | | | | | | | | | Add an LED trigger for IDE disk activity to the ide-disk driver. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Acked-by: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] LED: add LED trigger tupportRichard Purdie2006-03-311-0/+52
| | | | | | | | | | | | 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>
* [PATCH] LED: add LED classRichard Purdie2006-03-311-0/+51
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-25 18:39:02 +0000