25 May, 2011
1 commit
-
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
26 Mar, 2011
1 commit
-
* 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
...
23 Mar, 2011
1 commit
-
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
31 Jan, 2011
1 commit
-
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
12 Nov, 2010
1 commit
-
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
26 May, 2010
1 commit
-
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
24 Jun, 2009
3 commits
-
Futher document blink_set function pointer
Signed-off-by: Richard Purdie
-
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 -
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
06 Apr, 2009
2 commits
-
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 -
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
Signed-off-by: Richard Purdie
09 Jan, 2009
1 commit
-
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.
08 Jan, 2009
1 commit
-
There is one place where the struct led_classdev as the function
argument is named differently. Fix it.Signed-off-by: Wolfram Sang
Signed-off-by: Richard Purdie
21 Oct, 2008
1 commit
-
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
Signed-off-by: Richard Purdie
23 Jul, 2008
2 commits
-
This driver supports the PCA9550, PCA9551, PCA9552, and PCA9553
LED driver chips.Signed-off-by: Nate Case
Signed-off-by: Andrew Morton
Signed-off-by: Richard Purdie -
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
Signed-off-by: Richard Purdie
25 Apr, 2008
3 commits
-
Make sure there is no confusion about the contexts brightness_set
can be called under by documenting it.Signed-off-by: Richard Purdie
-
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
Signed-off-by: Richard Purdie -
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
Signed-off-by: Richard Purdie
20 Apr, 2008
1 commit
-
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
Acked-by: Pavel Machek
Signed-off-by: Greg Kroah-Hartman
07 Feb, 2008
1 commit
-
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
Signed-off-by: Richard Purdie
06 Feb, 2008
1 commit
-
Make it possible to unregister a led classdev object in a safe way during a
suspend/resume cycle.Signed-off-by: Rafael J. Wysocki
Cc: Michael Buesch
Cc: Pavel Machek
Cc: "John W. Linville"
Cc: Alan Stern
Cc: Len Brown
Cc: Greg KH
Cc: Kay Sievers
Cc: Richard Purdie
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Dec, 2007
1 commit
-
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
12 Sep, 2007
1 commit
-
This patch has added #include to include/linux/leds.h
for rwlock_t.Signed-off-by: Yoichi Yuasa
Signed-off-by: Richard Purdie
23 Jul, 2007
1 commit
-
* '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
17 Jul, 2007
1 commit
-
Remove the obviously unnecessary includes of 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
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
16 Jul, 2007
2 commits
-
Convert the LEDs class from struct class_device to struct device
since class_device is scheduled for removal.Signed-off-by: Richard Purdie
Acked-by: Greg Kroah-Hartman -
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
Signed-off-by: Richard Purdie
30 Sep, 2006
1 commit
-
Make it possible to include linux/leds.h without first including list.h and
spinlock.h.Signed-off-by: Johannes Berg
Acked-by: Richard Purdie
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Apr, 2006
1 commit
-
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
Acked-by: Richard Purdie
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 Apr, 2006
3 commits
-
Add an LED trigger for IDE disk activity to the ide-disk driver.
Signed-off-by: Richard Purdie
Acked-by: Bartlomiej Zolnierkiewicz
Cc: Alan Cox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
Cc: Russell King
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
Cc: Russell King
Cc: Greg KH
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds