| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Add the device to the notify callback's arguments in the PWM backlight
driver. This brings the notify callback into line with the other
callbacks defined by this driver.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Simtec Linux Team <linux@simtec.co.uk>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
This allows platform code to manipulate GPIOs and brightness level as
needed.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Patch mostly from Eric Miao, with minor edits by rmk to convert
Eric's driver to a generic PWM-based backlight driver.
Signed-off-by: eric miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
