In systems with multiple framebuffer devices, one of the devices might be blanked while another is unblanked. In order for the backlight blanking logic to know whether to turn off the backlight for a particular framebuffer's blanking notification, it needs to be able to check if a given framebuffer device corresponds to the backlight. This plumbs the check_fb hook from core backlight through the pwm_backlight helper to allow platform code to plug in a check_fb hook. Originally reviewed on http://git-master/r/21716 Reviewed-on: http://git-master/r/23100 (cherry picked from commit c7831cb27fc6a2701b020676a6daf9c76e9470d9) Change-Id: I32895d6f2c5988b09680a350e169f1f3c9b56da6 Reviewed-on: http://git-master/r/23725 Reviewed-by: Robert Morell <rmorell@nvidia.com> Tested-by: Gaurav Sarode <gsarode@nvidia.com> Reviewed-by: Mayuresh Kulkarni <mkulkarni@nvidia.com> Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
The intensity of the backlight can be varied from a range of max_brightness to zero. Though most, if not all the pwm based backlight devices start flickering at lower brightness value. And also for each device there exists a brightness value below which the backlight appears to be turned off though the value is not equal to zero. If the range of brightness for a device is from zero to max_brightness. A graph is plotted for brightness Vs intensity for the pwm based backlight device has to be a linear graph. intensity | / | / | / |/ --------- 0 max_brightness But pratically on measuring the above we note that the intensity of backlight goes to zero(OFF) when the value in not zero almost nearing to zero(some x%). so the graph looks like intensity | / | / | / | | ------------ 0 x max_brightness In order to overcome this drawback knowing this x% i.e nothing but the low threshold beyond which the backlight is off and will have no effect, the brightness value is being offset by the low threshold value(retaining the linearity of the graph). Now the graph becomes intensity | / | / | / | / ------------- 0 max_brightness With this for each and every digit increment in the brightness from zero there is a change in the intensity of backlight. Devices having this behaviour can set the low threshold brightness(lth_brightness) and pass the same as platform data else can have it as zero. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Arun Murthy <arun.murthy@stericsson.com> Acked-by: Linus Walleij <linus.walleij@stericsson.com> Acked-by: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Reviewed-on: http://git-master/r/23099 (cherry picked from commit 92db79791aa60cacb3fa90d1cb2e942420c29408) Change-Id: Icbe49b593dfa6608934ff274b4c9281e43c30b5c Reviewed-on: http://git-master/r/23724 Tested-by: Gaurav Sarode <gsarode@nvidia.com> Reviewed-by: Mayuresh Kulkarni <mkulkarni@nvidia.com> Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
bug 773671 Change-Id: Ib93f0dcb7e22220fe297c81d403c401548f3c649 Reviewed-on: http://git-master/r/18280 Tested-by: Joseph Lehrer <jlehrer@nvidia.com> Reviewed-by: Thomas Cherry <tcherry@nvidia.com> Reviewed-by: Jonathan Mayo <jmayo@nvidia.com> Reviewed-by: Sachin Nikam <snikam@nvidia.com> Reviewed-by: Daniel Willemsen <dwillemsen@nvidia.com>
commit d1d73578e053b981c3611e5a211534290d24a5eb upstream.
According to the comment describing ops_lock in the definition of struct
backlight_device and when comparing with other functions in backlight.c
the mutex must be hold when checking ops to be non-NULL.
Fixes a problem added by c835ee7f4154992e6 ("backlight: Add suspend/resume
support to the backlight core") in Jan 2009.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Richard Purdie <rpurdie@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
pavel@suse.cz no longer works, replace it with working address. Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
I2C drivers can use the clientdata-pointer to point to private data. As I2C devices are not really unregistered, but merely detached from their driver, it used to be the drivers obligation to clear this pointer during remove() or a failed probe(). As a couple of drivers forgot to do this, it was agreed that it was cleaner if the i2c-core does this clearance when appropriate, as there is no guarantee for the lifetime of the clientdata-pointer after remove() anyhow. This feature was added to the core with commit e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers. As there is no need anymore to clear the clientdata-pointer, remove all current occurrences in the drivers to simplify the code and prevent confusion. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Richard Purdie <rpurdie@linux.intel.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Jean Delvare <khali@linux-fr.org>
This patch adds a backlight driver for controlling the pcf50633 LED module. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
This patch properly unregisters a previously registered backlight device object in error handling Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Properly unregister a previously registered backlight device object in error handling of max8925_backlight_probe. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Error handling fixes: 1. In the case of kzalloc failure, simple return -ENOMEM instead of goto err. ( priv is NULL in this case ) 2. In the case of gpio_request fail for reset_gpio and data_enable_gpio, properly release resources by goto err and err2 respectively. Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Alberto Panizzo <maramaopercheseimorto@gmail.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>