The included patch adds support for interacting with the toshiba_acpi
backlight control through the generic backlight interface
(/sys/class/backlight).
ACPI folk: this gives us the benefit of a consistent interface to LCD
brightness. Is it worth me converting the other drivers over?
Signed-Off-By: Matthew Garrett <[email protected]>
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 5243f0c..69ed5c2 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -215,7 +215,7 @@ config ACPI_IBM
config ACPI_TOSHIBA
tristate "Toshiba Laptop Extras"
- depends on X86
+ depends on X86 && BACKLIGHT_DEVICE
default y
---help---
This driver adds support for access to certain system settings
diff --git a/drivers/acpi/toshiba_acpi.c b/drivers/acpi/toshiba_acpi.c
index b2fa688..f263f62 100644
--- a/drivers/acpi/toshiba_acpi.c
+++ b/drivers/acpi/toshiba_acpi.c
@@ -60,6 +60,7 @@
#include <linux/suspend.h>
#include <linux/miscdevice.h>
#include <linux/toshiba.h>
+#include <linux/backlight.h>
#include <asm/io.h>
#include <asm/uaccess.h>
@@ -117,6 +118,8 @@ MODULE_LICENSE("GPL");
#define HCI_VIDEO_OUT_CRT 0x2
#define HCI_VIDEO_OUT_TV 0x4
+static struct backlight_device *tosh_backlight_device;
+
/* utility
*/
@@ -315,6 +318,19 @@ static char *read_lcd(char *p)
return p;
}
+static int tosh_get_brightness(struct backlight_device *bd)
+{
+ int brightness;
+ u32 hci_result;
+
+ hci_read1(HCI_LCD_BRIGHTNESS, &brightness, &hci_result);
+ if (hci_result == HCI_SUCCESS) {
+ brightness = brightness >> HCI_LCD_BRIGHTNESS_SHIFT;
+ return brightness;
+ } else
+ return 0;
+}
+
static unsigned long write_lcd(const char *buffer, unsigned long count)
{
int value;
@@ -333,6 +349,22 @@ static unsigned long write_lcd(const cha
return count;
}
+static int tosh_set_brightness(struct backlight_device *bd, int brightness)
+{
+ u32 hci_result;
+
+ if (brightness >= 0 && brightness < HCI_LCD_BRIGHTNESS_LEVELS) {
+ brightness= brightness << HCI_LCD_BRIGHTNESS_SHIFT;
+ hci_write1(HCI_LCD_BRIGHTNESS, brightness, &hci_result);
+ if (hci_result != HCI_SUCCESS)
+ return -EFAULT;
+ } else {
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static char *read_video(char *p)
{
u32 hci_result;
@@ -588,6 +620,13 @@ static struct miscdevice tosh_device = {
&tosh_fops
};
+static struct backlight_properties toshbl_data = {
+ .owner = THIS_MODULE,
+ .get_brightness = tosh_get_brightness,
+ .set_brightness = tosh_set_brightness,
+ .max_brightness = HCI_LCD_BRIGHTNESS_LEVELS,
+};
+
static void
setup_tosh_info(void)
{
@@ -891,6 +930,12 @@ static int __init toshiba_acpi_init(void
}
}
+ tosh_backlight_device = backlight_device_register ("tosh-bl", NULL,
+ &toshbl_data);
+
+ if (IS_ERR (tosh_backlight_device))
+ printk("Failed to register Toshiba backlight device\n");
+
return (ACPI_SUCCESS(status)) ? 0 : -ENODEV;
}
@@ -909,6 +954,8 @@ static void __exit toshiba_acpi_exit(voi
old_driver_emulation_exit();
+ backlight_device_unregister(tosh_backlight_device);
+
printk(MY_INFO "Toshiba Laptop ACPI Extras unloaded\n");
return;
--
Matthew Garrett | [email protected]
Hi!
> The included patch adds support for interacting with the toshiba_acpi
> backlight control through the generic backlight interface
> (/sys/class/backlight).
>
> ACPI folk: this gives us the benefit of a consistent interface to LCD
> brightness. Is it worth me converting the other drivers over?
Not sure if I'm ACPI folk but yes, consistent interface would be nice.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
>> The included patch adds support for interacting with the toshiba_acpi
>> backlight control through the generic backlight interface
>> (/sys/class/backlight).
>>
>> ACPI folk: this gives us the benefit of a consistent interface to LCD
>> brightness. Is it worth me converting the other drivers over?
>
>Not sure if I'm ACPI folk but yes, consistent interface would be nice.
>
Note to self: Don't forget to change 2.6-sony-acpi?.diff from -mm to use
this /sys/class/backlight instead of /proc/acpi/sony/brightness when it's
ready.
Jan Engelhardt
--
On Thu, Feb 09, 2006 at 05:47:49PM +0100, Jan Engelhardt wrote:
> Note to self: Don't forget to change 2.6-sony-acpi?.diff from -mm to use
> this /sys/class/backlight instead of /proc/acpi/sony/brightness when it's
> ready.
Ah, you're maintaining that now. Here you go (Stelian took a look and
seemed happy with it - the /sys/class/backlight stuff is in mainstream)
diff --git a/drivers/acpi/sony_acpi.c b/drivers/acpi/sony_acpi.c
index 7636bba..6505b24 100644
--- a/drivers/acpi/sony_acpi.c
+++ b/drivers/acpi/sony_acpi.c
@@ -27,6 +27,8 @@
#include <linux/moduleparam.h>
#include <linux/init.h>
#include <linux/types.h>
+#include <linux/backlight.h>
+#include <linux/err.h>
#include <acpi/acpi_drivers.h>
#include <acpi/acpi_bus.h>
#include <asm/uaccess.h>
@@ -62,6 +64,8 @@ static struct acpi_driver sony_acpi_driv
static acpi_handle sony_acpi_handle;
static struct proc_dir_entry *sony_acpi_dir;
+static struct backlight_device *sony_backlight_device;
+
static struct sony_acpi_value {
char *name; /* name of the entry */
struct proc_dir_entry *proc; /* /proc entry */
@@ -258,6 +262,31 @@ static acpi_status sony_walk_callback(ac
return AE_OK;
}
+static int sony_brightness_get(struct backlight_device *bd)
+{
+ int value;
+
+ if (acpi_callgetfunc(sony_acpi_handle, "GBRT", &value))
+ return 0;
+
+ return value-1;
+}
+
+
+static int sony_brightness_set(struct backlight_device *bd, int value) {
+ value &= 0x7;
+ value++;
+
+ return acpi_callsetfunc(sony_acpi_handle, "SBRT", value, NULL);
+}
+
+static struct backlight_properties sonybl_data = {
+ .owner = THIS_MODULE,
+ .get_brightness = sony_brightness_get,
+ .set_brightness = sony_brightness_set,
+ .max_brightness = 7,
+};
+
static int __init sony_acpi_add(struct acpi_device *device)
{
acpi_status status;
@@ -378,12 +407,24 @@ static int __init sony_acpi_init(void)
remove_proc_entry("sony", acpi_root_dir);
return -ENODEV;
}
+
+ sony_backlight_device = backlight_device_register ("sony_bl", NULL,
+ &sonybl_data);
+
+ if (IS_ERR (sony_backlight_device)) {
+ printk("Unable to register backlight\n");
+ acpi_bus_unregister_driver(&sony_acpi_driver);
+ remove_proc_entry("sony", acpi_root_dir);
+ return -ENODEV;
+ }
+
return 0;
}
static void __exit sony_acpi_exit(void)
{
+ backlight_device_unregister(sony_backlight_device);
acpi_bus_unregister_driver(&sony_acpi_driver);
remove_proc_entry("sony", acpi_root_dir);
}
--
Matthew Garrett | [email protected]
>
>> Note to self: Don't forget to change 2.6-sony-acpi?.diff from -mm to use
>> this /sys/class/backlight instead of /proc/acpi/sony/brightness when it's
>> ready.
>
>Ah, you're maintaining that now. Here you go (Stelian took a look and
>seemed happy with it - the /sys/class/backlight stuff is in mainstream)
>
Well, I am not. At least not-yet-officially. But since I happen to have
that hardware, I use it. (And I even have to postpatch the SUSE KOTD ATM
to get there, heh, heh.)
Jan Engelhardt
--
On Tue, 07 Feb 2006 13:34:56 +0000, Matthew Garrett wrote:
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -215,7 +215,7 @@ config ACPI_IBM
>
> config ACPI_TOSHIBA
> tristate "Toshiba Laptop Extras"
> - depends on X86
> + depends on X86 && BACKLIGHT_DEVICE
> default y
> ---help---
> This driver adds support for access to certain system settings
Might this work better:
config ACPI_TOSHIBA
depends on X86
select BACKLIGHT_DEVICE
-
-Ben
--
Ben Slusky | It was only after their population
[email protected] | of 50 mysteriously shrank to eight
[email protected] | that the other seven dwarfs began
PGP keyID ADA44B3B | to suspect Hungry.