user/sven/linux.git/include/linux/leds.h, branch v3.2.65

leds: provide helper to register "leds-gpio" devices

2011-05-25T15:39:51Z

This function makes a deep copy of the platform data to allow it to live in init memory. For a kernel that supports several machines and so includes the definition for several leds-gpio devices this saves quite some memory because all but one definition can be free'd after boot. As the function is used by arch code it must be builtin and so cannot go into leds-gpio.c. [akpm@linux-foundation.org: s/CONFIG_LED_REGISTER_GPIO/CONFIG_LEDS_REGISTER_GPIO/] Signed-off-by: Uwe Kleine-König Cc: Russell King Acked-by: Richard Purdie Cc: Fabio Estevam Cc: Sascha Hauer Tested-by: H Hartley Sweeten Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge git://git.infradead.org/battery-2.6

2011-03-26T04:00:29Z

* git://git.infradead.org/battery-2.6: (30 commits) bq20z75: Fix time and temp units bq20z75: Fix issues with present and suspend z2_battery: Fix count of properties s3c_adc_battery: Fix method names when PM not set z2_battery: Add MODULE_DEVICE_TABLE ds2782_battery: Add MODULE_DEVICE_TABLE bq20z75: Add MODULE_DEVICE_TABLE power_supply: Update power_supply_is_watt_property bq20z75: Add i2c retry mechanism bq20z75: Add optional battery detect gpio twl4030_charger: Make the driver atomic notifier safe bq27x00: Use single i2c_transfer call for property read bq27x00: Cleanup bq27x00_i2c_read bq27x00: Minor cleanups bq27x00: Give more specific reports on battery status bq27x00: Add MODULE_DEVICE_TABLE bq27x00: Add new properties bq27x00: Poll battery state bq27x00: Cache battery registers bq27x00: Add bq27000 support ...

leds: make *struct gpio_led_platform_data.leds const

2011-03-23T00:43:59Z

And fix a typo. Signed-off-by: Uwe Kleine-König Cc: Lars-Peter Clausen Cc: Richard Purdie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

leds: Add ability to blink via simple trigger

2011-01-31T13:30:24Z

As blink API is now available, it's possible to add ability to blink via simple trigger. Signed-off-by: Vasily Khoruzhick Signed-off-by: Anton Vorontsov

led-class: always implement blinking

2010-11-12T15:55:32Z

Currently, blinking LEDs can be awkward because it is not guaranteed that all LEDs implement blinking. The trigger that wants it to blink then needs to implement its own timer solution. Rather than require that, add led_blink_set() API that triggers can use. This function will attempt to use hw blinking, but if that fails implements a timer for it. To stop blinking again, brightness_set() also needs to be wrapped into API that will stop the software blink. As a result of this, the timer trigger becomes a very trivial one, and hopefully we can finally see triggers using blinking as well because it's always easy to use. Signed-off-by: Johannes Berg Acked-by: Richard Purdie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

leds: leds-gpio: Change blink_set callback to be able to turn off blinking

2010-05-26T12:07:55Z

The leds-gpio blink_set() callback follows the same prototype as the main leds subsystem blink_set() one. The problem is that to stop blink, normally, a leds driver does it in the brightness_set() callback when asked to set a new fixed value. However, with leds-gpio, the platform has no hook to do so, as this later callback results in a standard GPIO manipulation. This changes the leds-gpio specific callback to take a new argument that indicates whether the LED should be blinking or not and in what state it should be set if not. We also update the dns323 platform which seems to be the only user of this so far. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Richard Purdie

leds: Futher document blink_set

2009-06-23T19:21:39Z

Futher document blink_set function pointer Signed-off-by: Richard Purdie

leds: Add options to have GPIO LEDs start on or keep their state

2009-06-23T19:21:39Z

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 Acked-by: Grant Likely Acked-by: Wolfram Sang Acked-by: Sean MacLennan Signed-off-by: Richard Purdie

leds: Further document parameters for blink_set()

2009-06-23T19:20:35Z

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 Signed-off-by: Richard Purdie

leds: Add suspend/resume state flags to leds-gpio

2009-04-06T15:06:26Z

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 Signed-off-by: Richard Purdie