[RFC PATCH] report acpi video hot key event through input device
report acpi video hot key event through input device
Signed-off-by: Luming Yu [EMAIL PROTECTED]
--
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 00d25b3..03d84db 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -31,6 +31,7 @@
#include linux/list.h
#include linux/proc_fs.h
#include linux/seq_file.h
+#include linux/input.h
#include linux/backlight.h
#include asm/uaccess.h
@@ -131,6 +132,8 @@ struct acpi_video_bus {
struct semaphore sem;
struct list_head video_device_list;
struct proc_dir_entry *dir;
+ struct input_dev *input;
+ char phys[32]; /* for input device */
};
struct acpi_video_device_flags {
@@ -1714,6 +1717,8 @@ static void acpi_video_bus_notify(acpi_h
{
struct acpi_video_bus *video = data;
struct acpi_device *device = NULL;
+ struct input_dev *input;
+ int keycode;
printk(video bus notify\n);
@@ -1721,11 +1726,13 @@ static void acpi_video_bus_notify(acpi_h
return;
device = video-device;
+ input = video-input;
switch (event) {
case ACPI_VIDEO_NOTIFY_SWITCH: /* User requested a switch,
* most likely via hotkey. */
acpi_bus_generate_event(device, event, 0);
+ keycode = KEY_UNKNOWN;
break;
case ACPI_VIDEO_NOTIFY_PROBE: /* User plugged in or removed a video
@@ -1734,21 +1741,37 @@ static void acpi_video_bus_notify(acpi_h
acpi_video_device_rebind(video);
acpi_video_switch_output(video, event);
acpi_bus_generate_event(device, event, 0);
+ keycode = KEY_UNKNOWN;
break;
case ACPI_VIDEO_NOTIFY_CYCLE: /* Cycle Display output hotkey pressed.
*/
+ acpi_video_switch_output(video, event);
+ acpi_bus_generate_event(device, event, 0);
+ keycode = KEY_UNKNOWN;
+ break;
case ACPI_VIDEO_NOTIFY_NEXT_OUTPUT: /* Next Display output hotkey
pressed. */
+ acpi_video_switch_output(video, event);
+ acpi_bus_generate_event(device, event, 0);
+ keycode = KEY_VIDEO_NEXT;
+ break;
case ACPI_VIDEO_NOTIFY_PREV_OUTPUT: /* previous Display output
hotkey pressed. */
acpi_video_switch_output(video, event);
acpi_bus_generate_event(device, event, 0);
+ keycode = KEY_VIDEO_PREV;
break;
default:
+ keycode = KEY_UNKNOWN;
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
Unsupported event [0x%x]\n, event));
break;
}
+ input_report_key(input, keycode, 1);
+ input_sync(input);
+ input_report_key(input, keycode, 0);
+ input_sync(input);
+
return;
}
@@ -1756,30 +1779,60 @@ static void acpi_video_device_notify(acp
{
struct acpi_video_device *video_device = data;
struct acpi_device *device = NULL;
+ struct acpi_video_bus *bus;
+ struct input_dev *input;
+ int keycode;
if (!video_device)
return;
device = video_device-dev;
+ bus = video_device-video;
+ input = bus-input;
switch (event) {
case ACPI_VIDEO_NOTIFY_SWITCH: /* change in status (cycle output
device) */
case ACPI_VIDEO_NOTIFY_PROBE: /* change in status (output device
status) */
acpi_bus_generate_event(device, event, 0);
+ keycode = KEY_UNKNOWN;
break;
case ACPI_VIDEO_NOTIFY_CYCLE_BRIGHTNESS:/* Cycle brightness */
+ acpi_video_switch_brightness(video_device, event);
+ acpi_bus_generate_event(device, event, 0);
+ keycode = KEY_UNKNOWN;
+ break;
case ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS: /* Increase brightness */
+ acpi_video_switch_brightness(video_device, event);
+ acpi_bus_generate_event(device, event, 0);
+ keycode = KEY_BRIGHTNESS_UP;
+ break;
case ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS: /* Decrease brightness */
+ acpi_video_switch_brightness(video_device, event);
+ acpi_bus_generate_event(device, event, 0);
+ keycode = KEY_BRIGHTNESS_DOWN;
+ break;
case ACPI_VIDEO_NOTIFY_ZERO_BRIGHTNESS: /* zero brightnesss */
+ acpi_video_switch_brightness(video_device, event);
+ acpi_bus_generate_event(device, event, 0);
+ keycode = KEY_BRIGHTNESS_ZERO;
+ break;
case ACPI_VIDEO_NOTIFY_DISPLAY_OFF: /* display device off */
acpi_video_switch_brightness(video_device, event);
acpi_bus_generate_event(device, event, 0);
+ keycode = KEY_BRIGHTNESS_OFF;
break
Re: Asus M6*, A6*, L5D - can't reboot after suspend/resume
Please try the 1st patch: http://bugzilla.kernel.org/show_bug.cgi?id=6655#c8 if not work, please try the 2nd patch: http://bugzilla.kernel.org/show_bug.cgi?id=6655#c23 if still not, I don't know what's the hell about the problem. Need to debug further. Thanks, Luming On 6/29/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Thursday, 28 June 2007 22:52, Mikhail Gusarov wrote: Hi. ping'ing mailing list: there is stuck bug in bugzilla and probably fresh eyes need to look at it to find the obvious solution :) Sorry if this noise is unnecessary. Bug is http://bugzilla.kernel.org/show_bug.cgi?id=8598 Summary: Most recent kernel where this bug did not occur: n/a Distribution: debian/sid Hardware Environment: Asus A6B, A6BA, M6A, M6N, M6NE, L5D notebooks Problem Description: After S3 STR reboot does not work, reboot=w,h and reboot=c,b, no luck. System shows message about restarting system. Caps lock and num lock LEDs flash, but it does not reboot. I personally have only M6N notebook, so can test things only on it. I'm afraid that this is not an easy problem. It shows up on two of my own test machines and I have no idea how to debug it further, let alone fixing. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Asus M6*, A6*, L5D - can't reboot after suspend/resume
OK, let's try linuxfirmware tool to see if it is Linux problem or probably bios problem. you can grab the tool kit from http://www.linuxfirmwarekit.org/ then please do a suspend-resume cycle, then try reboot from the command line. Let's see the results. :-) On 6/29/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Thursday, 28 June 2007 23:51, Luming Yu wrote: Please try the 1st patch: http://bugzilla.kernel.org/show_bug.cgi?id=6655#c8 if not work, please try the 2nd patch: http://bugzilla.kernel.org/show_bug.cgi?id=6655#c23 if still not, I don't know what's the hell about the problem. Need to debug further. Well, the patch at http://bugzilla.kernel.org/show_bug.cgi?id=6655#c39 (based on http://bugzilla.kernel.org/show_bug.cgi?id=6655#c23) works on one of my test boxes, but on the second one (Asus L5D) it doesn't work. Greetings, Rafael On 6/29/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Thursday, 28 June 2007 22:52, Mikhail Gusarov wrote: Hi. ping'ing mailing list: there is stuck bug in bugzilla and probably fresh eyes need to look at it to find the obvious solution :) Sorry if this noise is unnecessary. Bug is http://bugzilla.kernel.org/show_bug.cgi?id=8598 Summary: Most recent kernel where this bug did not occur: n/a Distribution: debian/sid Hardware Environment: Asus A6B, A6BA, M6A, M6N, M6NE, L5D notebooks Problem Description: After S3 STR reboot does not work, reboot=w,h and reboot=c,b, no luck. System shows message about restarting system. Caps lock and num lock LEDs flash, but it does not reboot. I personally have only M6N notebook, so can test things only on it. I'm afraid that this is not an easy problem. It shows up on two of my own test machines and I have no idea how to debug it further, let alone fixing. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Premature optimization is the root of all evil. - Donald Knuth - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.22-rc4-mm1] ACPI Exception (processor_throttling)
Please test the attached patch. Thanks, Luming On 6/7/07, Maciej Rutecki [EMAIL PROTECTED] wrote: ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] On 2.6.20.9 I don't have this exceptions. Other problem: 2.6.22rc4-mm1: rutek:/home/maciek# cat /proc/acpi/processor/CPU0/throttling Naruszenie ochrony pamięci (segmentation fault) compared to 2.6.20.9: [EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T0 states: *T0: 00% T1: 12% T2: 25% T3: 37% T4: 50% T5: 62% T6: 75% T7: 87% Other info (2.6.22-rc4-mm1): rutek:/home/maciek# ls /proc/acpi/processor/CPU0/ info limit power throttling rutek:/home/maciek# cat /proc/acpi/processor/CPU0/info processor id:0 acpi id: 1 bus mastering control: yes power management:yes throttling control: yes limit interface: yes rutek:/home/maciek# cat /proc/acpi/processor/CPU0/limit active limit:P0:T0 user limit: P0:T0 thermal limit: P0:T0 rutek:/home/maciek# cat /proc/acpi/processor/CPU0/power active state:C0 max_cstate: C8 bus master activity: maximum allowed latency: 8000 usec states: C1: type[C1] promotion[--] demotion[--] latency[001] usage[] duration[] C2: type[C2] promotion[--] demotion[--] latency[001] usage[] duration[] For CPU1 is similar. config, dmesg, acpidump: http://www.unixy.pl/maciek/download/kernel/2.6.22-rc4-mm1/ -- Maciej Rutecki http://www.maciek.unixy.pl t.patch Description: Binary data
[PATCH] _TPC,_TSS,_PTC support
adds _TPC,_TSS,_PTC support which support Throttling Present Capabilities
change for ACPI processor driver
signed-off-by: Luming Yu [EMAIL PROTECTED]
--
drivers/acpi/processor_core.c |6
drivers/acpi/processor_throttling.c | 380 +++-
include/acpi/processor.h| 46
3 files changed, 423 insertions(+), 9 deletions(-)
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 60646dd..7dedf3b 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -67,6 +67,7 @@ #define ACPI_PROCESSOR_FILE_THROTTLING
#define ACPI_PROCESSOR_FILE_LIMIT limit
#define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80
#define ACPI_PROCESSOR_NOTIFY_POWER 0x81
+#define ACPI_PROCESSOR_NOTIFY_THROTTLING 0x82
#define ACPI_PROCESSOR_LIMIT_USER 0
#define ACPI_PROCESSOR_LIMIT_THERMAL1
@@ -85,6 +86,8 @@ static int acpi_processor_info_open_fs(s
static void acpi_processor_notify(acpi_handle handle, u32 event, void *data);
static acpi_status acpi_processor_hotadd_init(acpi_handle handle, int *p_cpu);
static int acpi_processor_handle_eject(struct acpi_processor *pr);
+extern int acpi_processor_tstate_has_changed(struct acpi_processor *pr);
+
static struct acpi_driver acpi_processor_driver = {
.name = processor,
@@ -700,6 +703,9 @@ static void acpi_processor_notify(acpi_h
acpi_processor_cst_has_changed(pr);
acpi_bus_generate_event(device, event, 0);
break;
+ case ACPI_PROCESSOR_NOTIFY_THROTTLING:
+ acpi_processor_tstate_has_changed(pr);
+ acpi_bus_generate_event(device, event, 0);
default:
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
Unsupported event [0x%x]\n, event));
diff --git a/drivers/acpi/processor_throttling.c
b/drivers/acpi/processor_throttling.c
index b334860..1bae2e4 100644
--- a/drivers/acpi/processor_throttling.c
+++ b/drivers/acpi/processor_throttling.c
@@ -44,10 +44,222 @@ #define ACPI_PROCESSOR_CLASS
#define _COMPONENT ACPI_PROCESSOR_COMPONENT
ACPI_MODULE_NAME(processor_throttling);
+static int acpi_processor_get_throttling (struct acpi_processor *pr);
+int acpi_processor_set_throttling (struct acpi_processor *pr, int state);
+
+static int acpi_processor_get_platform_limit(struct acpi_processor *pr)
+{
+ acpi_status status = 0;
+ unsigned long tpc = 0;
+
+ if(!pr)
+ return -EINVAL;
+ status = acpi_evaluate_integer(pr-handle, _TPC, NULL, tpc);
+ if(ACPI_FAILURE(status) status != AE_NOT_FOUND){
+ ACPI_EXCEPTION((AE_INFO, status, Evaluating _TPC));
+ return -ENODEV;
+ }
+ pr-throttling_platform_limit = (int)tpc;
+ return 0;
+}
+
+int acpi_processor_tstate_has_changed(struct acpi_processor *pr)
+{
+ return acpi_processor_get_platform_limit(pr);
+}
+
+/* --
+ _PTC, _TSS, _TSD support
+ --
*/
+static int acpi_processor_get_throttling_control(struct acpi_processor *pr)
+{
+ int result = 0;
+ acpi_status status = 0;
+ struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+ union acpi_object *ptc = NULL;
+ union acpi_object obj = { 0 };
+
+ status = acpi_evaluate_object(pr-handle, _PTC, NULL, buffer);
+ if (ACPI_FAILURE(status)) {
+ ACPI_EXCEPTION((AE_INFO, status, Evaluating _PTC));
+ return -ENODEV;
+ }
+
+ ptc = (union acpi_object *)buffer.pointer;
+ if (!ptc || (ptc-type != ACPI_TYPE_PACKAGE)
+ || (ptc-package.count != 2)) {
+ printk(KERN_ERR PREFIX Invalid _PTC data\n);
+ result = -EFAULT;
+ goto end;
+ }
+
+ /*
+* control_register
+*/
+
+ obj = ptc-package.elements[0];
+
+ if ((obj.type != ACPI_TYPE_BUFFER)
+ || (obj.buffer.length sizeof(struct acpi_ptc_register))
+ || (obj.buffer.pointer == NULL)) {
+ printk(KERN_ERR PREFIX Invalid _PTC data
(control_register)\n);
+ result = -EFAULT;
+ goto end;
+ }
+ memcpy(pr-throttling.control_register, obj.buffer.pointer,
+ sizeof(struct acpi_ptc_register));
+
+ /*
+* status_register
+*/
+
+ obj = ptc-package.elements[1];
+
+ if ((obj.type != ACPI_TYPE_BUFFER)
+ || (obj.buffer.length sizeof(struct acpi_ptc_register))
+ || (obj.buffer.pointer == NULL)) {
+ printk(KERN_ERR PREFIX Invalid _PTC data (status_register)\n);
+ result = -EFAULT;
+ goto end;
+ }
+
+ memcpy(pr-throttling.status_register, obj.buffer.pointer,
+ sizeof(struct acpi_ptc_register
Re: BenQ S73U - no ACPI
please enter a bug on bugzilla.kernel.org in ACPI category
On 5/11/07, Jan Willies [EMAIL PROTECTED] wrote:
Luming Yu wrote:
On 5/9/07, Jan Willies [EMAIL PROTECTED] wrote:
I got a BenQ S73U and it doesn't support ACPI very well. I got 23
please describe the problem in detail.
What information are useful? I have put some log-files here:
http://web746.webbox240.server-home.org/acpi/acpid
http://web746.webbox240.server-home.org/acpi/acpi.log
There simply is no S{1,2,3,4,5} with this laptop. It won't even
power-off itself after halt.
errors. This is confusing, it should work well cause they are only
warnings, not errors!
warnings when compiling /proc/acpi/dsdt with the iasl-compiler, but no
compile-time working doesn't mean run-time working.
I discovered that, sadly.
- jcw
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BenQ S73U - no ACPI
On 5/9/07, Jan Willies [EMAIL PROTECTED] wrote: Hello, I got a BenQ S73U and it doesn't support ACPI very well. I got 23 please describe the problem in detail. warnings when compiling /proc/acpi/dsdt with the iasl-compiler, but no errors. This is confusing, it should work well cause they are only warnings, not errors! compile-time working doesn't mean run-time working. Anyway, Sebastian Lammermann managed to turn all warnings down by rewriting the DSDT, but one. Unfortunately the behavior didn't change, shutdown is still not working. The last unsolved warning: dsdt.dsl 1164: Method (_OSC, 5, NotSerialized) Warning 1075 -^ Reserved method has too many arguments (_OSC requires 4) If anyone please have a look at the DSDT, it would be very kind! I'm really desperate to get this thing working under Linux. original: http://openwrt.loswillios.de/dsdt.dsl modified: http://www.hft-leipzig.de/~s03114/dsdt.dsl please in details... I mailed BenQ about this problem, they even replied which surprised me a bit. They promised to pass the mail to their developers, but I don't think it will change something... I reckon I'm not the first one who mailed them about that. That's interesting.. BenQ begins to care about linux? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ACPI video driver output switch sysfs support
To use this patch, you need enable VIDEO_OUTPUT_CONTROL and ACPI_VIDEO.
After loading output.ko and video.ko, you would have
/sys/class/video_output and several device acpi_videoNum there. For
example, I got acpi_video0, acpi_video1,acpi_video2,and acpi_video3
under /sys/class/video_output on my T40.
I can query the status of output device0 by running cat
/sys/class/video_output/acpi_video0
The return value is defined in ACPI SPEC B.5.5 _DCS(Return the
Status of Output Device). Also you can turn off video1 and turn on
video0 by echo 0 acpi_video1; echo 0x8000 acpi_video0.
Please reference ACPI SPEC B.5.7 _DSS for the parameter definition.
Also please note that it may or may NOT works purely depending on if
your vendor providing correct ACPI video extension support in bios.
the driver output.ko and video.ko just works like a interface to
invoke BIOS.
The update patch:
Add output switch sysfs class support for ACPI video driver.
signed-off-by: Luming Yu [EMAIL PROTECTED]
acpi/Kconfig |2 +-
acpi/video.c | 40
video/Kconfig |7 +++
video/Makefile |3 +++
4 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 139f41f..eb4855f 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -124,7 +124,7 @@ config ACPI_BUTTON
config ACPI_VIDEO
tristate Video
- depends on X86 BACKLIGHT_CLASS_DEVICE
+ depends on X86 BACKLIGHT_CLASS_DEVICE VIDEO_OUTPUT_CONTROL
help
This driver implement the ACPI Extensions For Display Adapters
for integrated graphics devices on motherboard, as specified in
diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 00d25b3..39273da 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -33,6 +33,7 @@
#include linux/seq_file.h
#include linux/backlight.h
+#include linux/video_output.h
#include asm/uaccess.h
#include acpi/acpi_bus.h
@@ -169,6 +170,7 @@ struct acpi_video_device {
struct acpi_device *dev;
struct acpi_video_device_brightness *brightness;
struct backlight_device *backlight;
+ struct output_device *output_dev;
};
/* bus */
@@ -272,6 +274,10 @@ static int acpi_video_get_next_level(struct
acpi_video_device *device,
u32 level_current, u32 event);
static void acpi_video_switch_brightness(struct acpi_video_device *device,
int event);
+static int acpi_video_device_get_state(struct acpi_video_device *device,
+ unsigned long *state);
+static int acpi_video_output_get(struct output_device *od);
+static int acpi_video_device_set_state(struct acpi_video_device
*device, int state);
/*backlight device sysfs support*/
static int acpi_video_get_brightness(struct backlight_device *bd)
@@ -297,6 +303,28 @@ static struct backlight_ops acpi_backlight_ops = {
.update_status = acpi_video_set_brightness,
};
+/*video output device sysfs support*/
+static int acpi_video_output_get(struct output_device *od)
+{
+ unsigned long state;
+ struct acpi_video_device *vd =
+ (struct acpi_video_device *)class_get_devdata(od-class_dev);
+ acpi_video_device_get_state(vd, state);
+ return (int)state;
+}
+
+static int acpi_video_output_set(struct output_device *od)
+{
+ unsigned long state = od-request_state;
+ struct acpi_video_device *vd=
+ (struct acpi_video_device *)class_get_devdata(od-class_dev);
+ return acpi_video_device_set_state(vd, state);
+}
+
+static struct output_properties acpi_output_properties = {
+ .set_state = acpi_video_output_set,
+ .get_status = acpi_video_output_get,
+};
/* --
Video Management
--
*/
@@ -626,6 +654,17 @@ static void acpi_video_device_find_cap(struct
acpi_video_device *device)
kfree(name);
}
+ if (device-cap._DCS device-cap._DSS){
+ static int count = 0;
+ char *name;
+ name = kzalloc(MAX_NAME_LEN, GFP_KERNEL);
+ if (!name)
+ return;
+ sprintf(name, acpi_video%d, count++);
+ device-output_dev = video_output_register(name,
+ NULL, device, acpi_output_properties);
+ kfree(name);
+ }
return;
}
@@ -1669,6 +1708,7 @@ static int acpi_video_bus_put_one_device(struct
acpi_video_device *device)
ACPI_DEVICE_NOTIFY,
acpi_video_device_notify);
backlight_device_unregister(device-backlight);
+ video_output_unregister(device
Re: [PATCH 8/9] ACPI: thinkpad-acpi: add sysfs support to hotkey subdriver
I was wondering how you know what action should be associated with what key? I don't. I could though, using model-specific knowledge (i.e. a table) and help from the linux thinkpad community and thinkwiki.org. I don't like the idea of stuffing kernel space with model-specific knowledge (i.e. a table) even if it is in a driver. These tables should be in user space... We deliver to userspace something like Fn+F1 pressed, instead of blank screen pressed, because blank screen is in different keys depending on thinkpad model. Yes, you should generate generic key event through input layer.. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ACPI video: Don't export sysfs backlight interface if query _BCL fail
Ack! On 4/27/07, Danny Kukawka [EMAIL PROTECTED] wrote: Hi, currently the acpi video module export the backlight interface to sysfs also if acpi_video_device_lcd_query_levels() fails to read _BLC method (e.g. because the method is not available). In this case the userspace don't know which brightness level are supported and can't set a brightness level (echo return with: write error: Invalid Argument). This happend e.g. on a ASUS RF1 (correct supported by the asus-laptop module). The video module should not export the backlight interface if query _BLC fail, because you can't set anything from userspace and this make it useless. See also: http://bugzilla.kernel.org/show_bug.cgi?id=8375 Danny From: Danny Kukawka [EMAIL PROTECTED] Subject: ACPI video: Don't export sysfs backlight interface if query _BLC fail if qeuery _BCL fail (e.g. because the method is missing in BIOS) don't export the backlight interface to sysfs. Signed-off-by: Danny Kukawka [EMAIL PROTECTED] --- video.c | 78 -- 1 file changed, 41 insertions(+), 37 deletions(-) --- linux-2.6.21/drivers/acpi/video.c 2007-04-26 13:50:51.0 +0200 +++ linux-2.6.21/drivers/acpi/video.c 2007-04-26 13:50:53.0 +0200 @@ -531,7 +531,6 @@ - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: toshiba video brightness
Hi Len, There are three issues according to your description. Issue 1: The missing of /sys/backlight on your Toshiba seems just due to the sysfs backlight requires bios expose _BCL, _BCM, and _BQC for returning levels supported, controlling brightness, querying the current brightness respectively. I checked the DSDT of the Toshiba box. There is NO _BQC. Without _BQC, the sysfs backlight driver will lose the capability of returning the current brightness level to user space. Maybe it is just not important, and need to loose the condition check to register into back light sysfs layer anyway. Issue 2: Only the values of 0 and 40 have any effect, the others are a NOP I will take a closer look at the related methods to check if that is expected by the BIOS. Issue 3: cannot remove video module It is NOT reproducible on my napa. I will see if it is the consequence of the previous two issues. Thanks, Luming On 3/29/07, Len Brown [EMAIL PROTECTED] wrote: Luming I've got 2.6.21-rc5 running on a Toshiba Satellite Pro laptop. The ACPI video drivers seems to supply 2 brightness levels in proc, but nothing in /sys/backlight, and the toshiba_acpi driver seems to supply 8 levels in /proc. what am I missing? thanks, -Len loading the video driver, I see this: [EMAIL PROTECTED]:/proc/acpi/video ls -R .: VGA ./VGA: CRT DOS info LCD POST POST_info ROM TV ./VGA/CRT: brightness EDID info state ./VGA/LCD: brightness EDID info state ./VGA/TV: brightness EDID info state [EMAIL PROTECTED]:/proc/acpi/video/VGA/LCD cd /proc/acpi/video/VGA/LCD [EMAIL PROTECTED]:/proc/acpi/video/VGA/LCD su Password: toshiba:/proc/acpi/video/VGA/LCD # echo 0 brightness (this dimmed the screen to minimum) toshiba:/proc/acpi/video/VGA/LCD # echo 40 brightness (this make the screen max brightness) toshiba:/proc/acpi/video/VGA/LCD # echo 100 brightness bash: echo: write error: Invalid argument toshiba:/proc/acpi/video/VGA/LCD # echo 20 brightness toshiba:/proc/acpi/video/VGA/LCD # echo 10 brightness toshiba:/proc/acpi/video/VGA/LCD # echo 0 brightness toshiba:/proc/acpi/video/VGA/LCD # echo 40 brightness toshiba:/proc/acpi/video/VGA/LCD # echo 50 brightness toshiba:/proc/acpi/video/VGA/LCD # echo 30 brightness Only the values of 0 and 40 have any effect, the others are a NOP toshiba:/proc/acpi/video/VGA/LCD # cd /proc/acpi/toshiba/ toshiba:/proc/acpi/toshiba # ls fan keys lcd version video toshiba:/proc/acpi/toshiba # cat lcd brightness: 3 brightness_levels: 8 toshiba:/proc/acpi/toshiba # echo brightness:0 lcd toshiba:/proc/acpi/toshiba # echo brightness:2 lcd toshiba:/proc/acpi/toshiba # echo brightness:3 lcd toshiba:/proc/acpi/toshiba # echo brightness:4 lcd toshiba:/proc/acpi/toshiba # echo brightness:5 lcd toshiba:/proc/acpi/toshiba # echo brightness:6 lcd toshiba:/proc/acpi/toshiba # echo brightness:7 lcd toshiba:/proc/acpi/toshiba # echo brightness:8 lcd bash: echo: write error: Invalid argument toshiba:/proc/acpi/toshiba # All of these 8 give a different brightness video.c: brightness 0 = toshiba_acpi brightness 0 video.c: brightness 40 = toshiba_acpi brightness 3 rmmod toshiba_acpi makes no difference. toshiba:/proc/acpi/video/VGA/LCD # ls /sys/class/backlight/ toshiba:/proc/acpi/video/VGA/LCD # toshiba:/proc/acpi/video/VGA/LCD # gunzip -dc /proc/config.gz |grep BACKLIGHT CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_PROGEAR is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_RADEON_BACKLIGHT=y - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: test
why do you think so? On 3/29/07, Conke Hu [EMAIL PROTECTED] wrote: my mail does not work ? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC patch] add GPE count under firmware acpi sysfs
Add GPE count under /sys/firmware/acpi/gpe.
signed-off-by: Luming Yu [EMAIL PROTECTED]
--
drivers/acpi/Makefile |1
drivers/acpi/bus.c | 44 -
drivers/acpi/events/evgpe.c |1
drivers/acpi/gpe_stats.c| 104 +++
drivers/acpi/osl.c | 146
include/acpi/aclocal.h |1
include/linux/acpi.h|7 ++
7 files changed, 303 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 5956e9f..066eeeb 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -60,3 +60,4 @@ obj-$(CONFIG_ACPI_TOSHIBA)+= toshiba_ac
obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o
obj-y += cm_sbs.o
obj-$(CONFIG_ACPI_SBS) += i2c_ec.o sbs.o
+obj-m += gpe_stats.o
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index dd49ea0..b1a8b24 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -735,6 +735,47 @@ #endif
decl_subsys(acpi, NULL, NULL);
+struct acpi_subsys_attr {
+ struct attribute attr;
+ int type;
+ int value;
+ ssize_t(*show) (struct attribute *, char *);
+ ssize_t(*store) (struct attribute *, const char *, size_t count);
+};
+#define to_acpi_attr(k) container_of(k,struct acpi_subsys_attr,attr)
+static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buf)
+{
+ struct acpi_subsys_attr *aattr = to_acpi_attr(attr);
+ if (aattr-show)
+ return aattr-show(attr, buf);
+ else
+ return -EIO;
+}
+
+static ssize_t store(struct kobject *kobj, struct attribute *attr,
+ const char *buf, size_t count)
+{
+ struct acpi_subsys_attr *aattr = to_acpi_attr(attr);
+ if (aattr-store)
+ return aattr-store(attr, buf, count);
+ else
+ return -EIO;
+}
+static struct sysfs_ops sysfs_ops = {
+ .show = show,
+ .store = store,
+};
+
+static struct kobj_type ktype_acpi = {
+ .sysfs_ops = sysfs_ops,
+};
+
+void acpi_subsys_set_sysfs_ops(void)
+{
+ acpi_subsys.kset.kobj.ktype = ktype_acpi;
+ acpi_subsys.kset.ktype = ktype_acpi;
+}
+
static int __init acpi_init(void)
{
int result = 0;
@@ -749,7 +790,7 @@ static int __init acpi_init(void)
if (result 0)
printk(KERN_WARNING %s: firmware_register error: %d\n,
__FUNCTION__, result);
-
+ acpi_subsys_set_sysfs_ops();
result = acpi_bus_init();
if (!result) {
@@ -769,4 +810,5 @@ #endif
return result;
}
+EXPORT_SYMBOL(acpi_subsys);
subsys_initcall(acpi_init);
diff --git a/drivers/acpi/events/evgpe.c b/drivers/acpi/events/evgpe.c
index 635ba44..9b3face 100644
--- a/drivers/acpi/events/evgpe.c
+++ b/drivers/acpi/events/evgpe.c
@@ -621,6 +621,7 @@ acpi_ev_gpe_dispatch(struct acpi_gpe_eve
acpi_gpe_count++;
+ gpe_event_info-count++;
/*
* If edge-triggered, clear the GPE status bit now. Note that
* level-triggered events are cleared after the GPE is serviced.
diff --git a/drivers/acpi/gpe_stats.c b/drivers/acpi/gpe_stats.c
new file mode 100644
index 000..7be639d
--- /dev/null
+++ b/drivers/acpi/gpe_stats.c
@@ -0,0 +1,104 @@
+/*
+ * gpe_stats.c
+ *
+ * Copyright (C) 2007 Luming Yu [EMAIL PROTECTED]
+ *
+ * ~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/sysdev.h
+#include linux/sysfs.h
+#include linux/kobject.h
+#include linux/spinlock.h
+#include linux/acpi.h
+
+typedef ssize_t(*show_func) (struct attribute * attr, char *buf);
+extern struct subsystem acpi_subsys;
+#define to_gpe_attr(k) container_of(k,struct gpe_attr, attr)
+#define GPE_STATS_ATTR(_name,_mode,_show)\
+static struct gpe_attr _attr_##_name = {\
+ .attr = {.name = __stringify(_name), .owner = THIS_MODULE, \
+ .mode = _mode,},\
+ .type = 0,\
+ .value = -1, \
+ .show = _show,\
+};
+extern int acpi_show_gpe_count(char *buf);
+extern int
[patch] ACPI video driver output switch sysfs support
Add output switch sysfs class support for ACPI video driver.
signed-off-by: Luming Yu [EMAIL PROTECTED]
---
drivers/acpi/Kconfig |2 +-
drivers/acpi/video.c | 38 ++
drivers/video/Kconfig|7 +++
drivers/video/Makefile |3 +++
include/acpi/processor.h |0
5 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index e2ce4a9..7d1627b 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -124,7 +124,7 @@ config ACPI_BUTTON
config ACPI_VIDEO
tristate Video
- depends on X86 BACKLIGHT_CLASS_DEVICE
+ depends on X86 BACKLIGHT_CLASS_DEVICE VIDEO_OUTPUT_CONTROL
help
This driver implement the ACPI Extensions For Display Adapters
for integrated graphics devices on motherboard, as specified in
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 00d25b3..3456603 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -33,6 +33,7 @@ #include linux/proc_fs.h
#include linux/seq_file.h
#include linux/backlight.h
+#include linux/video_output.h
#include asm/uaccess.h
#include acpi/acpi_bus.h
@@ -169,6 +170,7 @@ struct acpi_video_device {
struct acpi_device *dev;
struct acpi_video_device_brightness *brightness;
struct backlight_device *backlight;
+ struct output_device *output_dev;
};
/* bus */
@@ -297,6 +299,28 @@ static struct backlight_ops acpi_backlig
.update_status = acpi_video_set_brightness,
};
+/*video output device sysfs support*/
+static int acpi_video_output_get(struct output_device *od)
+{
+ unsigned long state;
+ struct acpi_video_device *vd =
+ (struct acpi_video_device *)class_get_devdata(od-class_dev);
+ acpi_video_device_get_state(vd,state);
+ return (int)state;
+}
+
+static int acpi_video_output_set(struct output_device *od)
+{
+ unsigned long state = od-request_state;
+ struct acpi_video_device *vd=
+ (struct acpi_video_device *)class_get_devdata(od-class_dev);
+ return acpi_video_device_set_state(vd,state);
+}
+
+static struct output_properties acpi_output_properties = {
+ .set_state = acpi_video_output_set,
+ .get_status = acpi_video_output_get,
+};
/* --
Video Management
--
*/
@@ -626,6 +650,19 @@ static void acpi_video_device_find_cap(s
kfree(name);
}
+ if (device-cap._DCS device-cap._DSS){
+ unsigned long tmp;
+ static int count = 0;
+ char *name;
+ name = kzalloc(MAX_NAME_LEN, GFP_KERNEL);
+ if (!name)
+ return;
+ sprintf(name, acpi_video%d, count++);
+ device-output_dev = video_output_register(name,
+ (data-dev-dev),
+ device, acpi_output_properties);
+ kfree(name);
+ }
return;
}
@@ -1669,6 +1706,7 @@ static int acpi_video_bus_put_one_device
ACPI_DEVICE_NOTIFY,
acpi_video_device_notify);
backlight_device_unregister(device-backlight);
+ video_output_unregister(device-output_dev);
return 0;
}
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 7f5a598..bd76a6c 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -6,6 +6,13 @@ menu Graphics support
source drivers/video/backlight/Kconfig
+config VIDEO_OUTPUT_CONTROL
+tristate Lowlevel video output switch controls
+ default m
+ help
+ This framework adds support for low-level control of the video
+ output switch.
+
config FB
tristate Support for frame buffer devices
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 760305c..f5ab032 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -108,3 +108,6 @@ obj-$(CONFIG_FB_OF) += off
# the test framebuffer is last
obj-$(CONFIG_FB_VIRTUAL) += vfb.o
+
+#video output switch sysfs driver
+obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
video_output.patch
Description: Binary data
Re: hwsusp defunct
For acpi issues, please enter bug into bugzilla.kernel.org with dmesg, acpidump output . On 2/7/07, Jiri Slaby [EMAIL PROTECTED] wrote: Cc: linux-acpi not-cc: linux-pm Rafael J. Wysocki napsal(a): On Tuesday, 6 February 2007 12:18, Jiri Slaby wrote: This is blindly written dmesg after resume. See it whole at [2]: Suspending device 0.0 ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (7) is beyon d end of object [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.GTM_] (Node dfe64fcc), AE_AML_PACKAGE_LIMIT ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.CHN0._ GTM] (Node dfe649f0), AE_AML_PACKAGE_LIMIT ... hda: selected mode 0x45 ACPI Error (dsopcode-0481): Attempt to CreateField of length zero [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.RATA] (Node dfe64ec8), AE_AML_OPERAND_VALUE ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.CHN0.D RV1._GTF] (Node dfe64964), AE_AML_OPERAND_VALUE do_drive_get_GTF: Run _GTF error: status = 0x3006 This looks like an ACPI-vs-IDE problem. You can try to use libata drivers instead of the old IDE ones. $ ls -l /sys/block/hda/device lrwxrwxrwx 1 root root 0 úno 6 12:14 /sys/block/hda/device - ../../devices/pci:00/:00:1f.1/ide0/0.0 $ ls -l /sys/block/hda/device/driver lrwxrwxrwx 1 root root 0 úno 6 12:15 /sys/block/hda/device/driver - ../../../../../bus/ide/drivers/ide-disk $ ls -l /sys/block/hda/device/driver/0.0 lrwxrwxrwx 1 root root 0 úno 6 12:16 /sys/block/hda/device/driver/0.0 - ../../../../devices/pci:00/:00:1f.1/ide0/0.0 # lspci -vvvxxs :00:1f.1 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin A routed to IRQ 5 Region 0: I/O ports at 01f0 [size=8] Region 1: I/O ports at 03f4 [size=1] Region 2: I/O ports at 0170 [size=8] Region 3: I/O ports at 0374 [size=1] Region 4: I/O ports at fc00 [size=16] Region 5: Memory at 3010 (32-bit, non-prefetchable) [size=1K] 00: 86 80 db 24 07 00 80 02 02 8a 01 01 00 00 00 00 10: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 20: 01 fc 00 00 00 00 10 30 00 00 00 00 43 10 a6 80 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 Do you want acpidump? I'm not an ACPI expert, it won't tell me a lot, but perhaps you should add linux-acpi to the Cc list. ;-) [...] [1] http://www.fi.muni.cz/~xslaby/sklad/config-mm [2] http://www.fi.muni.cz/~xpapiez/test/dmesg-mm.txt Ok, acpi folks, any suggests? thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fan speeds on HP nc6400 and nc8430
I managed to get a HP NX 6330 laptop to test HP laptop related issues
discussed here.
But the bug http://bugzilla.kernel.org/show_bug.cgi?id=7813 seems to
be NOT reproducible on my NX6330. This fact prompt if there are any
essential difference between NX6330 and NC6400. The BIOS of my NX6330
even declares itself is NC6330.
On 2/6/07, Thomas Renninger [EMAIL PROTECTED] wrote:
On Wed, 2007-01-24 at 09:54 -0700, Bjorn Helgaas wrote:
On Tuesday 23 January 2007 21:38, Bjorn Helgaas wrote:
On Tuesday 23 January 2007 21:19, Luming Yu wrote:
On 1/19/07, emisca [EMAIL PROTECTED] wrote:
The TZ4 thermal zone on all the hp compaq line nx and nc is
not a temperature but the fan speed. You can see this information on
the web and on hp forums.
Where is the hp forums.
I don't work on laptops, so I can't confirm this, but Google found
this (from tz4 thermal zone fan speed hp):
http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=1052925
Someone also sent me this, which I'll include in case it helps anybody
else. Obviously, scripts like the one mentioned below are stop-gaps
that shouldn't be necessary. But the script might have useful hints
about how to fix the kernel so the script would no longer be needed.
Take a look at this:
http://daniel.graziotin.net/2006/12/02/hp-nx6325-and-friends-thermal-problems-solved
this fixed my thermal problem.
And make sure you unload the psmouse module during halt/reboot
otherwise you have problemes when you start your notebook again.
(symptom's: very long BIOS-Boot, ACPI-problems (thermal)..)
I have a patch that should fix the psmouse unload thing (at the end).
Not sure whether it's still needed in 2.6.20-rcX, there was some work
done... it definitely helps on 2.6.18 and 2.6.16 kernels.
Ok, I quickly tried on 2.6.20-rc7 and it seems to work without the
patch.
Maybe Dmitry can comment on that and push this one if still needed?
It's quite difficult to get the overview over the HP problems, as there
are several, some quite weird, and a lot different reports.
I've found out that the psmouse thing really fixes things.
and I got a lot reports that Alexeys patch (and the
unregister_serio_drivers attached) fixes up things:
https://bugzilla.novell.com/show_bug.cgi?id=179702
https://bugzilla.novell.com/show_bug.cgi?id=234475
As this patch broke Linus' machine, I understand that Len is a bit
anxious, but a lot people tested the reworked patch (it's currently in
10.2 and SLE10-SP1 SuSE branches), it would be great if Len can push it
at least for the next kernel cycle...
What is still broken, but patches are available, is fan state after
suspend/resume.
Thanks to Rafael, there is a list of patches that seem to help
(including Alexey's and some others) here:
http://www.sisk.pl/kernel/patches/2.6.20-rc5/
Most of them seem to come from:
http://bugzilla.kernel.org/show_bug.cgi?id=5534
and
http://bugzilla.kernel.org/show_bug.cgi?id=7122
Can someone give an overview about what is already submitted, what is
going to be merged and where/when (-mm, rcX, 2.6.21-rc1, ...).
All kind of comments/review/tests are very welcome...
Some of the patches miss a comment...
Thanks,
Thomas
---
Subject: Unregister serio drivers on shutdown
From: Thomas Renninger [EMAIL PROTECTED]
Unproved theory:
It seems that the Embedded Controller needs this at ACPI shutdown time:
psmouse_set_state(psmouse, PSMOUSE_CMD_MODE);
psmouse_set_state(psmouse, PSMOUSE_IGNORE);
done in psmouse_disconnect in psmouse module.
If this is not done on shutdown it leads to very strange BIOS/EC behaviour
on latest HP laptops which even survives a reboot (cpufreq cannot reach max
freq, BIOS takes long to boot, etc.). Then the fixed kernel needs to
be booted twice, that machine reaches max freq and behaves normal again.
Ref: http://bugzilla.kernel.org/show_bug.cgi?id=7689
https://bugzilla.novell.com/show_bug.cgi?id=179702
Signed-off-by: Thomas Renninger [EMAIL PROTECTED]
drivers/input/serio/serio.c |1 +
1 files changed, 1 insertion(+)
Index: linux-2.6.19/drivers/input/serio/serio.c
===
--- linux-2.6.19.orig/drivers/input/serio/serio.c
+++ linux-2.6.19/drivers/input/serio/serio.c
@@ -973,6 +973,7 @@ static struct bus_type serio_bus = {
.probe = serio_driver_probe,
.remove = serio_driver_remove,
.resume = serio_resume,
+ .shutdown = serio_driver_remove,
};
static int __init serio_init(void)
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ACPI bytecode hardware registers access
Is your ioport included in the microsoft's list being blocked by XP? Please give me an example (acpidump output from a real box) that demonstrates ACPI is missing something which must be done through native driver. I'm wondering the designer of the box should already known AML code will directly access these ioport. why they needs some other native driver to access same set of ioport at same time with acpi. It sounds like obvious broken design. So my real question is the native driver is really wanted by the platform designer? As a hacker, it make senses to discover more hardware/platform features. But do these features make sense to the designer of the box. On 2/5/07, Rudolf Marek [EMAIL PROTECTED] wrote: Hello, To all: Please continue CCing me and the lm-sensors list thanks. Luming Yu wrote: Yes, that is bad to simultaneously access same hardware by ACPI and native drivers without coordination. But the problem is if nativer driver is really needed with the existence of the ACPI support for that device? Yes for example, BIOS will export though ACPI just one temperature _TMP but the chip monitors voltages and more temps etc etc. So from the lm-sensors point of view the answer is yes we need a full driver for hardware monitoring. Do you know the features that are NOT supported by ACPI? Yes as I wrote above - the voltages, fan speeds, various types of alarms... Instead of one temperature reading, I got 9 voltage readings, 3 temps, 5 fans etc etc Probably, just writing a acpi driver for SMBus controler could solve this problem completely. Just my intuition. Please correct me if I'm wrong. Problem is that the device manufacturers may do what they want in ACPI bytecode. We cannot expect them to implement smbus bus control as specified in the specs. They just drive the registers on their own. What I'm trying to implement is the ACPI isolation from selected hardware somehow, because the ACPI bytecode can contain code that modifies virtually any hardware in the system without the clue what others drivers do. Even the windows don't like it: http://www.microsoft.com/whdc/system/pnppwr/powermgmt/BIOSAML.mspx (I/O Ports Blocked from BIOS AML) Please help me find the solution. Thanks, Rudolf - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ACPI bytecode hardware registers access
Yes, that is bad to simultaneously access same hardware by ACPI and
native drivers without coordination. But the problem is if nativer
driver is really needed with the existence of the ACPI support for
that device? Do you know the features that are NOT supported by ACPI?
Probably, just writing a acpi driver for SMBus controler could solve
this problem completely. Just my intuition. Please correct me if I'm
wrong.
On 2/5/07, Rudolf Marek [EMAIL PROTECTED] wrote:
Hello all,
I would like to discuss some issues that we as the lm-sensors (hardware
monitoring) developers see. To make it short: ACPI bytecode pokes the hardware
without letting know the other linux drivers and this is bad. In the past it was
there but it somehow worked. Nowdays it is becoming larger problem not only for
the lm-sensors group but also for other drivers (video...)
ACPI provides the thermal zone methods to read the temps. Now imagine that this
method is implemented and executed:
Method (_TMP, 0, NotSerialized)
{
And (SENF, 0x01, Local6)
If (LEqual (Local6, 0x01))
{
Return (RTMP ())
}
Else
{
Return (0x0B86)
}
}
Method (RTMP, 0, NotSerialized)
{
WBYT (0x4E, 0x01)
Store (RBYT (0x50), Local0)
If (LLess (Local0, 0x80))
{
Multiply (Local0, 0x0A, Local0)
Add (Local0, 0x0AAC, Local0)
}
Else
{
Subtract (Local0, 0x80, Local0)
Multiply (Local0, 0x0A, Local0)
Subtract (0x0AAC, Local0, Local0)
}
If (LEqual (SSHU, 0x01))
{
Return (Local0)
}
Else
{
Return (Local0)
}
}
What it does? It reads the register 0x50 in bank 1 of W83627EHF chip. The
register for bank switch is 0x4e.
The w83627EHF driver update function is also changing the bank switch register.
We have seen already that this might be wrong - you will read nonsense when in
wrong bank... This happened in the past already - with some other drivers and
hw :
http://www.lm-sensors.org/ticket/2072
That is not all. Now imagine that the smbus controller is programed in the
bytecode... (and it is if some special methods are implemented or the sensors is
located on smbus - to make it clear they dont use the APCI specified smbus
interface but the bytecode programs the controller)
Like this:
Method (SWFS, 0, NotSerialized)
{
And (HSTS, 0x02, Local0)
Sleep (0x02)
While (LEqual (Local0, Zero))
{
Stall (0x01)
Sleep (0x02)
And (HSTS, 0x02, Local0)
}
Sleep (0x02)
Store (0xFF, HSTS)
Sleep (0x02)
}
This is no good :/
How can be this prevented/solved? Here are some ideas I had through some time,
none of them is my favourite, but please help me find some solution!
1) APCI AML code based locks.
There are none standard implemented. Asus is using sometimes for their HW
Mutex (\P4SM, 0x00) to deal with concurrent smbus driver/acpi access.
some award based BIOSes contain that magic SENF value check the first example.
Quite a lot of BIOSes have this. Perhaps it is just cut and paste???
Plus with other vendor specific means.
Result: no way
2) some ACPI subsystem locking
Is it possible to stop/resume ACPI bytecode execution somehow? Will this lead to
crashes/deadlocks?
Result: ?
3) reesource region locking
Just imagine that the ioregion/mem resource region would have some kind of lock
in the structure, acpi and driver will need this lock to write to the device -
or at least acpi. This will/may lead to deadlock during suspend/resume
Could it work ever work
Result: ???
4) port forwarding
If the special bit in resource is set, ACPI will not do the actual access to
IO/mem but forward it to driver, which will handle the operation in safe way -
for example preserves the bank. Cares about the transactions...
Something like this would also work for the problems with super I/O chips which
are accessed with different drivers.
Imagine this like some coordinating driver...
Result:
5) some other ideas
I wanted to write this mail long time, however I wrote it as fast as possible to
make it happen. Any questions, proposals etc etc very welcome!
Thanks,
Rudolf
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More
Re: 2.6.20 poweroff regression on se7525gp2
Sounds like a regression of patch from linus ACPI: Allow setting SCI_EN bit in PM1_CONTROL register Linus Torvalds [Wed, 11 Oct 2006 00:14:44 + (17:14 -0700)] This is needed by at least the Mac Mini's, which (incorrectly) come back from suspend with SCI_EN clear. On 2/5/07, Len Brown [EMAIL PROTECTED] wrote: With 2.6.19.2, init 0 works with 2.6.20, it causes this box to reset when it should poweroff, and thus it reboots. any suggestions on where to look first? thanks, -Len Success case: Linux version 2.6.19.2 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #5 SMP Sun Feb Command line: root=/dev/sda2 console=tty0 console=ttyS0,115200n8 debug ... # init 0 ... The system will be halted immediately. Synchronizing SCSI cache for disk sda: ACPI: PCI interrupt for device :06:03.0 disabled ACPI: PCI interrupt for device :05:06.1 disabled ACPI: PCI interrupt for device :05:06.0 disabled ACPI: PCI interrupt for device :05:04.1 disabled ACPI: PCI interrupt for device :05:04.0 disabled Power down. acpi_power_off called hwsleep-0285 [02] enter_sleep_state : Entering sleep state [S5] Failure case: Linux version 2.6.20 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #1 SMP Sun Feb Command line: root=/dev/sda2 console=tty0 console=ttyS0,115200n8 debug ... # init 0 ... The system will be halted immediately. Synchronizing SCSI cache for disk sda: ACPI: PCI interrupt for device :06:03.0 disabled ACPI: PCI interrupt for device :05:06.1 disabled ACPI: PCI interrupt for device :05:06.0 disabled ACPI: PCI interrupt for device :05:04.1 disabled ACPI: PCI interrupt for device :05:04.0 disabled Power down. acpi_power_off called hwsleep-0285 [02] enter_sleep_state : Entering sleep state [S5] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Strange things on 2.6.19/20 for a dual-core CPU
Well, enter a acpi bug on bugzilla with acpidump output and dmesg attached. Another interesting thing is shown here: [EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU1/info processor id:0 acpi id: 1 bus mastering control: no power management:no throttling control: yes limit interface: yes [EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU2/info processor id:1 acpi id: 2 bus mastering control: no power management:no throttling control: no limit interface: no As I remember, both cores were showing the same things formerly. The only line referring to CPUs during boot is ACPI: Processor [CPU1] (supports 8 throttling states) and CPU2 is not mentioned at all. The last (but maybe not acpi-related) strange thing is that in /proc/cpuinfo, CPU1 reports 6403.56 bogomips (as always, approximately twice the clock) and CPU2 8314.32 ones (too much). It's also very suspicious. Formerly the difference was very small. Should I provide more info to debug these things, or is it OK ? With regards, Pavel Troller - End forwarded message - - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fan speeds on HP nc6400 and nc8430
Do you have psmouse module loaded ? (i.e. CONFIG_MOUSE_PS2=m) If yes, Please try remove it, and re-test it. Thanks, Luming On 1/19/07, Pieter De Wit [EMAIL PROTECTED] wrote: Hello List, I have noted that the fan speed on idle is much higher in Linux compared to XP. I have also noted that once fans are turned on, they never seem to return to the off state. I am currently using the 2.6.18 kernel from Gentoo (gentoo-sources-r6). I was wondering if there is a way I can lower the fan speed, or even assist the devs to get info regarding these notebooks (if any is needed). Thanks, Pieter This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this link http://www.vodacom.co.za/legal/email.jsp - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later
But, _ON and _OFF methods set \_TZ.THRM.FNON object to 1 and 0 respectively, so, I think, it could be used as value returned by _STA method. Attached patch for DSDT should solve the fan issue. For reference, it does solve the fan issue - fan stays on during boot, echo 0 and 3 to /proc/acpi/fan/*/state cause the fan to switch on and off respectively. Does it really solve the problem of CPU fan shutting down on load of fan.ko? Could you just re-test, since that is the problem from the beginning. --Luming - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HP Compaq nc6320 - Booting on battery power causes softlock
The first thing is to make sure you are running the latest bios, kernel. Then, you need to sort out the kernel component/modules/drivers that cause the problem. If you guess it is ACPI issue, pleas test boot option acpi=off to see if the problem goes away. If you guess it is battery issue, please remove battery module, etc. Please don't forget to enter a bug in bugzilla.kernel.org. Thanks, Luming On 1/17/07, Peter Clifton [EMAIL PROTECTED] wrote: Hi, I've got an issue with my HP Compaq nc6320, where it won't boot off its battery without softlocking on CPU#0. I remember it booting ok off battery occasionally in the past, but once I've seen the fault - the only way I can get it to boot is off AC. (I usually boot off AC anyway). I'm presuming ACPI as a good starting point, since that is an area where AC / Battery may make a difference. Can anyone suggest a debugging procedure to identify the cause of a softlock, and where would be appropriate (which category) to file a kernel bug for this? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/11] sony_acpi: prepare for prime time (resend)
On 1/15/07, Mattia Dongili [EMAIL PROTECTED] wrote: Hello and sorry for the delay On Mon, Jan 15, 2007 at 04:01:14AM -0500, Luming Yu wrote: Patch series is not clean against 2.6.20-rc5. patch -p1 ../malattia_sony/1_snc_device_support_for_sony_va io.patch patching file Documentation/acpi/sony_acpi.txt patching file drivers/acpi/Kconfig Hunk #1 succeeded at 252 with fuzz 2 (offset -9 lines). patching file drivers/acpi/Makefile Hunk #1 FAILED at 54. 1 out of 1 hunk FAILED -- saving rejects to file drivers/acpi/Makefile.rej patching file drivers/acpi/sony_acpi.c ... uh. I'm developing on the acpi tree test branch, however I just tried the patches on a freshly unpacked/patched .20-rc5 and the patches apply without any reject. I was using linus's linux-2.6 git tree. Then, I tried the patch series on a fresh unpacked 2.6.20-rc5. I still got : # patch -p1 ../malattia_sony/1_snc_device_support_for_sony_vaio.patch patching file Documentation/acpi/sony_acpi.txt patching file drivers/acpi/Kconfig Hunk #1 succeeded at 252 with fuzz 2 (offset -9 lines). patching file drivers/acpi/Makefile Hunk #1 FAILED at 54. 1 out of 1 hunk FAILED -- saving rejects to file drivers/acpi/Makefile.rej patching file drivers/acpi/sony_acpi.c patch -p1 ../malattia_sony/2_avoid_dimness_on_resume.patch patching file drivers/acpi/sony_acpi.c Hunk #1 succeeded at 46 with fuzz 2. Hunk #2 FAILED at 56. Hunk #3 FAILED at 228. Hunk #4 succeeded at 353 with fuzz 1. Hunk #5 succeeded at 375 with fuzz 1. 2 out of 5 hunks FAILED -- saving rejects to file drivers/acpi/sony_acpi.c.rej Is 2_avoid_dimness_on_resume.patch a right patch, or in right order? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/11] sony_acpi: prepare for prime time (resend)
Patch series is not clean against 2.6.20-rc5. patch -p1 ../malattia_sony/1_snc_device_support_for_sony_va io.patch patching file Documentation/acpi/sony_acpi.txt patching file drivers/acpi/Kconfig Hunk #1 succeeded at 252 with fuzz 2 (offset -9 lines). patching file drivers/acpi/Makefile Hunk #1 FAILED at 54. 1 out of 1 hunk FAILED -- saving rejects to file drivers/acpi/Makefile.rej patching file drivers/acpi/sony_acpi.c patch -p1 ../malattia_sony/2_avoid_dimness_on_resume.patch patching file drivers/acpi/sony_acpi.c Hunk #1 succeeded at 46 with fuzz 2. Hunk #2 FAILED at 56. Hunk #3 FAILED at 228. Hunk #4 succeeded at 353 with fuzz 1. Hunk #5 succeeded at 375 with fuzz 1. 2 out of 5 hunks FAILED -- saving rejects to file drivers/acpi/sony_acpi.c.rej patch -p1 ../malattia_sony/3_fix_sony_acpi_resume_call.patc h patching file drivers/acpi/sony_acpi.c Hunk #1 FAILED at 233. 1 out of 1 hunk FAILED -- saving rejects to file drivers/acpi/sony_acpi.c.rej patch -p1 ../malattia_sony/4_add_backlight_support_to_the_s ony_acpi.patch patching file drivers/acpi/Kconfig Hunk #1 FAILED at 264. 1 out of 1 hunk FAILED -- saving rejects to file drivers/acpi/Kconfig.rej patching file drivers/acpi/sony_acpi.c Hunk #2 succeeded at 55 with fuzz 2. Hunk #3 FAILED at 77. Hunk #4 FAILED at 284. Hunk #5 FAILED at 312. Hunk #6 FAILED at 373. Hunk #7 succeeded at 371 with fuzz 2 (offset -22 lines). 4 out of 7 hunks FAILED -- saving rejects to file drivers/acpi/sony_acpi.c.re On 1/13/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello again, as said the following patchset starts to take care of sony_acpi: 1 to 7 are currently in -mm 8 to 10 are my local changes to make sony_acpi make some more interesting things on recent vaios 11 initializes the real brightness value in the backlight props (should this go in the backlight class itself?) and fixes the error exit path for the backlight_device registration will follow shortly with a patch that makes sony_acpi a platform device driver. -- mattia :wq - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HP nc6400 v.03 or v.05 laptop ACPI fails after reboot, works again after booting windows
Since it is somewhat related to ACPI, please open a bug in ACPI category on bugzilla.kernel.org. It is a great place to track this kind of issues. On 12/13/06, Peter Clifton [EMAIL PROTECTED] wrote: On Wed, 2006-12-13 at 02:54 -0500, Lincoln Baxter, III wrote: Wow. You're completely right... so this isn't an ACPI issue (directly.) I don't seem to experience any of the other problems you describe, but I do have a different model. I don't have an external lid-switch sensor. Hm.. Suspend doesn't quite work for me either, I'll look into this farther and get back to you. The battery meters and other ACPI functionality is working now with your workaround. Should this be a bug report? Which group should get the report if this is the case? Thanks so much! Lincoln It was suggested to me to open a kernel bug (possibly starting under ACPI), however I never got to it.. I don't know where kernel bugs are reported officially, and was busy at the time. (still am). I do try and bugzilla.kernel.org reply to others with the same problems though... finding the webpage which suggested that fix was not trivial! It is not easy to track it in emals. My lid switch is just above the keyboard, on the right hand side of the left hand screen hinge. It is just a tiny piece of plastic protruding from the case. Push it, and the screen goes off. Hold it, and wiggle the mouse (touchpad), and the naughty screen comes back on. Most importantly for me, the workaround brings the max CPU speed available with speed step back to what it is supposed to be on my laptop, and the BIOS actually boots much faster. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/5] video sysfs support - take 2: Add dev argument for backlight_device_register.
On 12/30/06, Richard Purdie [EMAIL PROTECTED] wrote:
On Wed, 2006-11-08 at 00:33 +0800, Yu Luming wrote:
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.
Patch 1/5: adds 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.
signed-off-by: Luming Yu [EMAIL PROTECTED]
---
drivers/acpi/asus_acpi.c|2 +-
drivers/acpi/ibm_acpi.c |2 +-
drivers/acpi/toshiba_acpi.c |3 ++-
drivers/video/backlight/backlight.c |7 +--
include/linux/backlight.h |2 +-
5 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 27597c5..1d97cdf 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -190,8 +190,10 @@ static int fb_notifier_callback(struct n
* Creates and registers new backlight class_device. Returns either an
* ERR_PTR() or a pointer to the newly allocated device.
*/
-struct backlight_device *backlight_device_register(const char *name, void
*devdata,
-struct backlight_properties
*bp)
+struct backlight_device *backlight_device_register(const char *name,
+ struct device *dev,
+ void *devdata,
+ struct backlight_properties *bp)
{
int i, rc;
struct backlight_device *new_bd;
This patch breaks several platforms. If you're going to add parameters
to a function like backlight_device_register, you could at least grep
the tree and update all the users :-(.
yes, you are right. I just noticed that there are so many users when I sent
out that patch. And all these users were disabled when I was testing patch.
I'm sorry for that.
To top it off, someone noticed some of the failures and fixed them but
nobody thought to fix the drivers in drivers/video/backlight itself and
a mac reference seems to have escaped too.
If my memory serves me well, there is a patch for mac in mm.
Not sure other drivers in video/backlight. But I should have sent it
to some place.
Need to check.
I'll send a patch to to Andrew to clean up this mess...
thank you!
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sonypc with Sony Vaio VGN-SZ1VP
Luming has a sony laptop and can help with this, but he can't be the permanent maintainer any more than I can, for the same reason. If we can get past #1, then I recommend we apply the patch series in -mm to the acpi-test tree and go from there. Yes, I happen to have a sony laptop. So, I can help the permanent maintainer of sony acpi driver on acpi related issues. --Luming - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.18-mm2] acpi: add backlight support to the sony_acpi driver
*backlight_device_register(const char *name,
- void *devdata, struct backlight_properties *bp);
+ struct device *dev,void *devdata,struct backlight_properties *bp);
extern void backlight_device_unregister(struct backlight_device *bd);
#define to_backlight_device(obj) container_of(obj, struct backlight_device, class_dev)
diff --git a/drivers/video/output.c b/drivers/video/output.c
new file mode 100644
index 000..4142662
--- /dev/null
+++ b/drivers/video/output.c
@@ -0,0 +1,129 @@
+/*
+ * output.c - Display output swither driver
+ *
+ * Copyright (C) 2006 Luming Yu [EMAIL PROTECTED]
+ *
+ * ~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~
+ */
+#include linux/module.h
+#include linux/output.h
+#include linux/err.h
+#include linux/ctype.h
+
+
+MODULE_DESCRIPTION(Display Output Switcher Lowlevel Control Abstraction);
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Luming Yu [EMAIL PROTECTED]);
+
+static ssize_t video_output_show_state(struct class_device *dev,char *buf)
+{
+ ssize_t ret_size = 0;
+ struct output_device *od = to_output_device(dev);
+ if (od-props)
+ ret_size = sprintf(buf,%.8x\n,od-props-get_status(od));
+ return ret_size;
+}
+
+static ssize_t video_output_store_state(struct class_device *dev,
+ const char *buf,size_t count)
+{
+ char *endp;
+ struct output_device *od = to_output_device(dev);
+ int request_state = simple_strtoul(buf,endp,0);
+ size_t size = endp - buf;
+
+if (*endp isspace(*endp))
+size++;
+if (size != count)
+return -EINVAL;
+
+ if (od-props) {
+ od-request_state = request_state;
+ od-props-set_state(od);
+ }
+ return count;
+}
+
+static void video_output_class_release(struct class_device *dev)
+{
+struct output_device *od = to_output_device(dev);
+kfree(od);
+}
+
+static struct class_device_attribute video_output_attributes[] = {
+ __ATTR(state, 0644, video_output_show_state, video_output_store_state),
+ __ATTR_NULL,
+};
+
+static struct class video_output_class = {
+ .name = video_output,
+ .release = video_output_class_release,
+ .class_dev_attrs = video_output_attributes,
+};
+
+struct output_device *video_output_register(const char *name,
+ struct device *dev,
+ void *devdata,
+ struct output_properties *op)
+{
+ struct output_device *new_dev;
+ int ret_code = 0;
+
+ new_dev = kzalloc(sizeof(struct output_device),GFP_KERNEL);
+ if (!new_dev) {
+ ret_code = -ENOMEM;
+ goto error_return;
+ }
+ new_dev-props = op;
+ new_dev-class_dev.class = video_output_class;
+ new_dev-class_dev.dev = dev;
+ strlcpy(new_dev-class_dev.class_id,name,KOBJ_NAME_LEN);
+ class_set_devdata(new_dev-class_dev,devdata);
+ ret_code = class_device_register(new_dev-class_dev);
+ if (ret_code) {
+ kfree(new_dev);
+ goto error_return;
+ }
+ return new_dev;
+
+error_return:
+ return ERR_PTR(ret_code);
+}
+EXPORT_SYMBOL(video_output_register);
+
+void video_output_unregister(struct output_device *dev)
+{
+ if (!dev)
+ return;
+ class_device_unregister(dev-class_dev);
+}
+EXPORT_SYMBOL(video_output_unregister);
+
+static void __exit video_output_class_exit(void)
+{
+ class_unregister(video_output_class);
+}
+
+static int __init video_output_class_init(void)
+{
+ return class_register(video_output_class);
+}
+
+postcore_initcall(video_output_class_init);
+module_exit(video_output_class_exit);
diff --git a/include/linux/output.h b/include/linux/output.h
new file mode 100644
index 000..6fc47f5
--- /dev/null
+++ b/include/linux/output.h
@@ -0,0 +1,42 @@
+/*
+ *
+ * Copyright (C) 2006 Luming Yu [EMAIL PROTECTED]
+ *
+ * ~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details
Re: [PATCH 2.6.18-mm2] acpi: add backlight support to the sony_acpi driver
On Wednesday 25 October 2006 15:07, Pavel Machek wrote:
Hi!
a generic ACPI driver that exports the _BCL and _BCM method
implementations via that same interface, so that systems providing
that will just work. drivers/acpi/video.c currently exports this
via /proc/acpi/video/$DEVICE/brightness, which isn't the same as
/sys/class/backlight. :-(
Yes, I'm working on acpi video driver transition , and have posted a
patch to user backlight for acpi video driver.
http://marc.theaimsgroup.com/?l=linux-acpim=115574087203605w=2
Just updated the backlight and output sysfs support for ACPI Video driver
on bugzilla. If you are interested this, please take a look at
http://bugzilla.kernel.org/show_bug.cgi?id=5749#c18
[patch 1/3] vidoe sysfs support: Add dev argument for baclight sys dev
Two typos in one line :-).
[patch 2/3] Add display output class support
I guess this needs Documentation/ so we can tell if user-kernel
interface is sane..
[patch 3/3] backlight and output sysfs support for acpi video driver
Some whitespace is not okay there...
Pavel
updated version.
[patch 1/4] video sysfs support: Add dev argument for backlight sys dev
drivers/video/backlight/backlight.c |3 ++-
include/linux/backlight.h |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
[patch 2/4] Add display output class support
drivers/video/output.c | 110
+
include/linux/output.h | 23 ++
2 files changed, 133 insertions(+)
[patch 3/4] backlight and output sysfs support for acpi video driver
acpi/Kconfig |2
acpi/video.c | 257
+
video/Kconfig |8 +
video/Makefile |1
4 files changed, 252 insertions(+), 16 deletions(-)
[patch 4/4] Add output class document
video-output.txt | 27 +++
1 file changed, 27 insertions(+)
Thanks,
Luming
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index 27597c5..1a18cdb 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -190,7 +190,7 @@ static int fb_notifier_callback(struct n
* Creates and registers new backlight class_device. Returns either an
* ERR_PTR() or a pointer to the newly allocated device.
*/
-struct backlight_device *backlight_device_register(const char *name, void *devdata,
+struct backlight_device *backlight_device_register(const char *name,struct device *dev, void *devdata,
struct backlight_properties *bp)
{
int i, rc;
@@ -206,6 +206,7 @@ struct backlight_device *backlight_devic
new_bd-props = bp;
memset(new_bd-class_dev, 0, sizeof(new_bd-class_dev));
new_bd-class_dev.class = backlight_class;
+ new_bd-class_dev.dev = dev;
strlcpy(new_bd-class_dev.class_id, name, KOBJ_NAME_LEN);
class_set_devdata(new_bd-class_dev, devdata);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 75e91f5..de8e056 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -54,7 +54,7 @@ struct backlight_device {
};
extern struct backlight_device *backlight_device_register(const char *name,
- void *devdata, struct backlight_properties *bp);
+ struct device *dev, void *devdata, struct backlight_properties *bp);
extern void backlight_device_unregister(struct backlight_device *bd);
#define to_backlight_device(obj) container_of(obj, struct backlight_device, class_dev)
diff --git a/drivers/video/output.c b/drivers/video/output.c
new file mode 100644
index 000..bcb2c53
--- /dev/null
+++ b/drivers/video/output.c
@@ -0,0 +1,110 @@
+/*
+ * Video output switch support
+ */
+
+#include linux/module.h
+#include linux/output.h
+#include linux/err.h
+#include linux/ctype.h
+
+
+MODULE_DESCRIPTION(Output Lowlevel Control Abstraction);
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Luming Yu [EMAIL PROTECTED]);
+
+static ssize_t video_output_show_state (struct class_device *dev, char *buf)
+{
+ ssize_t ret_size = 0;
+ struct output_device *od = to_output_device(dev);
+
+ if(od-props)
+ ret_size = sprintf(buf, %.8x\n, od-props-get_status(od));
+
+ return ret_size;
+}
+
+static ssize_t video_output_store_state (struct class_device *dev, const char *buf, size_t count)
+{
+ char *endp;
+ struct output_device *od = to_output_device(dev);
+ int request_state = simple_strtoul(buf, endp, 0);
+ size_t size = endp -buf;
+
+if (*endp isspace(*endp))
+size++;
+if (size != count)
+return -EINVAL;
+
+ if(od-props){
+ od-request_state = request_state;
+ od-props-set_state(od);
+ }
+ return count;
+}
+
+static void video_output_class_release(struct class_device *dev)
+{
+struct output_device *od = to_output_device(dev);
+kfree(od);
+}
+
+static struct class_device_attribute video_output_attributes[] = {
+ __ATTR(state, 0644
