| Age | Commit message (Collapse) | Author |
|---|
|
Backlight device returns the result of update_status(), but
backlight_update_status() ignores it. So the consumers cannot confirm the
result of their function call. This patch makes the result to be returned
back for consumers.
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the final verdict wrt there being a BACKLIGHT_RAW device.
By adding notification acpi-video can listen for backlight devices showing
up after it has loaded, and unregister its backlight device if desired.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
We don't have to update the state and fb_blank properties of a backlight
device every time a blanking or unblanking event comes because they may
have already been what we want. Another thought is that one backlight
device may be shared by multiple framebuffers. The backlight driver
should take the backlight device as a resource shared by all the
associated framebuffers.
This patch adds some logic to record each framebuffer's backlight usage
to determine the backlight device use count and whether the two
properties should be updated or not. To be more specific, only one
unblank operation on a certain blanked framebuffer may increase the
backlight device's use count by one, while one blank operation on a
certain unblanked framebuffer may decrease the use count by one, because
the userspace is likely to unblank an unblanked framebuffer or blank a
blanked framebuffer.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Introduce a new API for modules to query if a specific type of backlight
device has been registered. This is useful for some backlight device
provider module (e.g. ACPI video) to know if a native control
interface(e.g. the interface created by i915) is available and then do
things accordingly (e.g. avoid registering its own on Win8 systems).
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
These functions allow the driver core to automatically clean up any
allocation made by backlight drivers. Thus it simplifies the error
paths.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This function finds the struct backlight_device for a given device tree
node. A dummy function is provided so that it safely compiles out if OF
support is disabled.
[akpm@linux-foundation.org: Don't use IS_ENABLED(CONFIG_OF)]
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
There may be multiple ways of controlling the backlight on a given
machine. Allow drivers to expose the type of interface they are
providing, making it possible for userspace to make appropriate policy
decisions.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Values such as max_brightness should be set before backlights are
registered, but the current API doesn't allow that. Add a parameter to
backlight_device_register and update drivers to ensure that they
set this correctly.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
check_fb from backlight_ops lacks a reference to the backlight_device
that's being referred to. Add this parameter so a backlight_device
can be mapped to a single framebuffer, especially if the same driver
handles multiple devices on a single system.
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
9905a43b2d563e6f89e4c63c4278ada03f2ebb14 went a little to far with const
qualifiers as there are legitiment cases where the function pointers
can change (machine specific setup code for example).
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
Signed-off-by: Emese Revfy <re.emese@gmail.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
Certain hardware will send us events when the backlight brightness
changes. Add a function to update the value in the core, and
additionally send a uevent so that userspace can pop up appropriate
UI. The uevents are flagged depending on whether the update originated
in the kernel or from userspace, making it easier to only display UI
at the appropriate time.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
Add suspend/resume support to the backlight core and enable use of it
by appropriate drivers.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
|
Convert the corgi backlight driver to a more generic version
so it can be reused by other code rather than being Zaurus/PXA
specific.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
|
|
Convert the backlight and LCD classes from struct class_device
to struct device since class_device is scheduled for removal.
One nasty API break is the backlight power attribute has had to be
renamed to bl_power and the LCD power attribute has had to be renamed
to lcd_power since the original names clash with the core. I can't see
a way around this.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Per device data such as brightness belongs to the indivdual device
and should therefore be separate from the the backlight operation
function pointers. This patch splits the two types of data and
allows simplifcation of some code.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
|
|
Convert internal semaphore to a mutex
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
|
|
backlight_device->sem has a very specific use as documented in the
header file. The external users of this are using it for a different
reason, to serialise access to the update_status() method.
backlight users were supposed to implement their own internal
serialisation of update_status() if needed but everyone is doing
things differently and incorrectly. Therefore add a global mutex to
take care of serialisation for everyone, once and for all.
Locking for get_brightness remains optional since most users don't
need it.
Also update the lcd class in a similar way.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
|
|
Remove uneeded owner field from backlight_properties structure.
Nothing uses it and it is unlikely that it will ever be used. The
backlight class uses other means to ensure that nothing references
unloaded code.
Based on a patch from Dmitry Torokhov <dtor@insightbb.com>
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
|
|
This patch set adds generic abstract layer support for acpi video driver to
have generic user interface to control backlight and output switch control by
leveraging the existing backlight sysfs class driver, and by adding a new
video output sysfs class driver.
This patch:
Add dev argument for backlight_device_register to link the class device to
real device object. The platform specific driver should find a way to get the
real device object for their video device.
[akpm@osdl.org: build fix]
[akpm@osdl.org: fix msi-laptop.c]
Signed-off-by: Luming Yu <Luming.yu@intel.com>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
Backlight class attributes are currently easy to implement incorrectly.
Moving certain handling into the backlight core prevents this whilst at the
same time makes the drivers simpler and consistent. The following changes are
included:
The brightness attribute only sets and reads the brightness variable in the
backlight_properties structure.
The power attribute only sets and reads the power variable in the
backlight_properties structure.
Any framebuffer blanking events change a variable fb_blank in the
backlight_properties structure.
The backlight driver has only two functions to implement. One function is
called when any of the above properties change (to update the backlight
brightness), the second is called to return the current backlight brightness
value. A new attribute "actual_brightness" is added to return this brightness
as determined by the driver having combined all the above factors (and any
driver/device specific factors).
Additionally, the backlight core takes care of checking the maximum brightness
is not exceeded and of turning off the backlight before device removal.
The corgi backlight driver is updated to reflect these changes.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
