Re: USB suspend/resume in linux
On Thu, 2006-10-12 at 22:54 -0700, Kaburlasos, Nikos wrote: Does anyone know whether the linux USB drivers support the suspend feature on idle USB ports (i.e. the port has been idle for sometime and so the driver transitions it in to a low-power 'suspend' state) while the system is active and in S0 state? As far as I know, Windows don't support that, I was wondering if linux does. Please note, I have no background on linux or in OS programming (I am a hardware guy), so please be gentle with the level of technical detail in your response :-) AFAIK linux is not doing that. Therefore the ohci (also uhci?) drivers need to poll the ports quite often even there is no device attached. This makes C-states less efficient (what should save more power than the suspended USB ports). I thought Windows is doing that, I at least heard Mac OS is doing it like that, but I don't know for sure. The proper solution to avoid polling should be to suspend idle ports, stop polling and wait for some kind of resume/attach event, but AFAIK nobody really works on that. Would be nice if someone gives this a try... Thomas - 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
[PATCH 1/3] Add support for the generic backlight device to the IBM ACPI driver
Add support for the generic backlight interface below
/sys/class/backlight. The patch keeps the procfs brightness handling for
backward compatibility.
For this to archive, the patch adds two generic functions brightness_get
and brightness_set to be used both by the procfs related and the sysfs
related methods.
Signed-off-by: Holger Macht [EMAIL PROTECTED]
---
This is an updated version of the patch earlier sent which selects the
right Kconfig option BACKLIGHT_DEVICE.
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 0f9d4be..19b0d22 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -200,6 +200,7 @@ config ACPI_ASUS
config ACPI_IBM
tristate IBM ThinkPad Laptop Extras
depends on X86
+ select BACKLIGHT_DEVICE
---help---
This is a Linux ACPI driver for the IBM ThinkPad laptops. It adds
support for Fn-Fx key combinations, Bluetooth control, video
diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index 15fc124..1160f92 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -78,6 +78,7 @@ #include linux/module.h
#include linux/init.h
#include linux/types.h
#include linux/proc_fs.h
+#include linux/backlight.h
#include asm/uaccess.h
#include acpi/acpi_drivers.h
@@ -243,6 +244,8 @@ struct ibm_struct {
static struct proc_dir_entry *proc_dir = NULL;
+static struct backlight_device *ibm_backlight_device;
+
#define onoff(status,bit) ((status) (1 (bit)) ? on : off)
#define enabled(status,bit) ((status) (1 (bit)) ? enabled : disabled)
#define strlencmp(a,b) (strncmp((a), (b), strlen(b)))
@@ -1381,12 +1384,22 @@ static int ecdump_write(char *buf)
static int brightness_offset = 0x31;
+static int brightness_get(struct backlight_device *bd)
+{
+ u8 level;
+ if (!acpi_ec_read(brightness_offset, level))
+ return -EIO;
+
+ level = 0x7;
+ return level;
+}
+
static int brightness_read(char *p)
{
int len = 0;
- u8 level;
+ int level;
- if (!acpi_ec_read(brightness_offset, level)) {
+ if ((level = brightness_get(NULL)) 0) {
len += sprintf(p + len, level:\t\tunreadable\n);
} else {
len += sprintf(p + len, level:\t\t%d\n, level 0x7);
@@ -1401,16 +1414,34 @@ static int brightness_read(char *p)
#define BRIGHTNESS_UP 4
#define BRIGHTNESS_DOWN5
-static int brightness_write(char *buf)
+static int brightness_set(int value)
{
int cmos_cmd, inc, i;
- u8 level;
+ int current_value = brightness_get(NULL);
+
+ value = 7;
+
+ cmos_cmd = value current_value ? BRIGHTNESS_UP : BRIGHTNESS_DOWN;
+ inc = value current_value ? 1 : -1;
+ for (i = current_value; i != value; i += inc) {
+ if (!cmos_eval(cmos_cmd))
+ return -EIO;
+ if (!acpi_ec_write(brightness_offset, i + inc))
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int brightness_write(char *buf)
+{
+ int level;
int new_level;
char *cmd;
while ((cmd = next_cmd(buf))) {
- if (!acpi_ec_read(brightness_offset, level))
- return -EIO;
+ if ((level = brightness_get(NULL)) 0)
+ return level;
level = 7;
if (strlencmp(cmd, up) == 0) {
@@ -1423,19 +1454,17 @@ static int brightness_write(char *buf)
} else
return -EINVAL;
- cmos_cmd = new_level level ? BRIGHTNESS_UP : BRIGHTNESS_DOWN;
- inc = new_level level ? 1 : -1;
- for (i = level; i != new_level; i += inc) {
- if (!cmos_eval(cmos_cmd))
- return -EIO;
- if (!acpi_ec_write(brightness_offset, i + inc))
- return -EIO;
- }
+ brightness_set(new_level);
}
return 0;
}
+static int brightness_update_status(struct backlight_device *bd)
+{
+ return brightness_set(bd-props-brightness);
+}
+
static int volume_offset = 0x30;
static int volume_read(char *p)
@@ -1965,10 +1994,20 @@ IBM_PARAM(brightness);
IBM_PARAM(volume);
IBM_PARAM(fan);
+static struct backlight_properties ibm_backlight_data = {
+.owner = THIS_MODULE,
+.get_brightness = brightness_get,
+.update_status = brightness_update_status,
+.max_brightness = 7,
+};
+
static void acpi_ibm_exit(void)
{
int i;
+ if (ibm_backlight_device)
+ backlight_device_unregister(ibm_backlight_device);
+
for (i = ARRAY_SIZE(ibms) - 1; i = 0; i--)
ibm_exit(ibms[i]);
@@ -2036,6 +2075,14 @@ #endif
}
}
+ ibm_backlight_device = backlight_device_register(ibm, NULL,
+
[PATCH 3/3] Add support for the generic backlight device to the TOSHIBA ACPI driver
Add support for the generic backlight interface below
/sys/class/backlight. The patch keeps the procfs brightness handling for
backward compatibility.
For this to archive, the patch adds two generic functions get_lcd and
set_lcd to be used both by the procfs related and the sysfs related
methods.
Signed-off-by: Holger Macht [EMAIL PROTECTED]
---
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index f0bd84a..d9bb370 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -227,6 +227,7 @@ config ACPI_IBM_DOCK
config ACPI_TOSHIBA
tristate Toshiba Laptop Extras
depends on X86
+ select BACKLIGHT_DEVICE
---help---
This driver adds support for access to certain system settings
on legacy free Toshiba laptops. These laptops can be recognized by
diff --git a/drivers/acpi/toshiba_acpi.c b/drivers/acpi/toshiba_acpi.c
index 7fe0b7a..2f35f89 100644
--- a/drivers/acpi/toshiba_acpi.c
+++ b/drivers/acpi/toshiba_acpi.c
@@ -41,6 +41,8 @@ #include linux/module.h
#include linux/init.h
#include linux/types.h
#include linux/proc_fs.h
+#include linux/backlight.h
+
#include asm/uaccess.h
#include acpi/acpi_drivers.h
@@ -210,6 +212,7 @@ static acpi_status hci_read1(u32 reg, u3
}
static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
+static struct backlight_device *toshiba_backlight_device;
static int force_fan;
static int last_key_event;
static int key_event_valid;
@@ -271,14 +274,23 @@ dispatch_write(struct file *file, const
return result;
}
-static char *read_lcd(char *p)
+static int get_lcd(struct backlight_device *bd)
{
u32 hci_result;
u32 value;
hci_read1(HCI_LCD_BRIGHTNESS, value, hci_result);
if (hci_result == HCI_SUCCESS) {
- value = value HCI_LCD_BRIGHTNESS_SHIFT;
+ return (value HCI_LCD_BRIGHTNESS_SHIFT);
+ } else
+ return -EFAULT;
+}
+
+static char *read_lcd(char *p)
+{
+ int value = get_lcd(NULL);
+
+ if (value = 0) {
p += sprintf(p, brightness: %d\n, value);
p += sprintf(p, brightness_levels: %d\n,
HCI_LCD_BRIGHTNESS_LEVELS);
@@ -289,22 +301,34 @@ static char *read_lcd(char *p)
return p;
}
+static int set_lcd(int value)
+{
+ u32 hci_result;
+
+ value = value HCI_LCD_BRIGHTNESS_SHIFT;
+ hci_write1(HCI_LCD_BRIGHTNESS, value, hci_result);
+ if (hci_result != HCI_SUCCESS)
+ return -EFAULT;
+
+ return 0;
+}
+
+static int set_lcd_status(struct backlight_device *bd)
+{
+ return set_lcd(bd-props-brightness);
+}
+
static unsigned long write_lcd(const char *buffer, unsigned long count)
{
int value;
- u32 hci_result;
+ int ret = count;
if (sscanf(buffer, brightness : %i, value) == 1
- value = 0 value HCI_LCD_BRIGHTNESS_LEVELS) {
- value = value HCI_LCD_BRIGHTNESS_SHIFT;
- hci_write1(HCI_LCD_BRIGHTNESS, value, hci_result);
- if (hci_result != HCI_SUCCESS)
- return -EFAULT;
- } else {
- return -EINVAL;
- }
-
- return count;
+ value = 0 value HCI_LCD_BRIGHTNESS_LEVELS)
+ ret = set_lcd(value);
+ else
+ ret = -EINVAL;
+ return ret;
}
static char *read_video(char *p)
@@ -506,6 +530,26 @@ static acpi_status __exit remove_device(
return AE_OK;
}
+static struct backlight_properties toshiba_backlight_data = {
+.owner = THIS_MODULE,
+.get_brightness = get_lcd,
+.update_status = set_lcd_status,
+.max_brightness = HCI_LCD_BRIGHTNESS_LEVELS - 1,
+};
+
+static void __exit toshiba_acpi_exit(void)
+{
+ if (toshiba_backlight_device)
+ backlight_device_unregister(toshiba_backlight_device);
+
+ remove_device();
+
+ if (toshiba_proc_dir)
+ remove_proc_entry(PROC_TOSHIBA, acpi_root_dir);
+
+ return;
+}
+
static int __init toshiba_acpi_init(void)
{
acpi_status status = AE_OK;
@@ -546,17 +590,15 @@ static int __init toshiba_acpi_init(void
remove_proc_entry(PROC_TOSHIBA, acpi_root_dir);
}
- return (ACPI_SUCCESS(status)) ? 0 : -ENODEV;
-}
-
-static void __exit toshiba_acpi_exit(void)
-{
- remove_device();
-
- if (toshiba_proc_dir)
- remove_proc_entry(PROC_TOSHIBA, acpi_root_dir);
+ toshiba_backlight_device = backlight_device_register(toshiba, NULL,
+ toshiba_backlight_data);
+if (IS_ERR(toshiba_backlight_device)) {
+ printk(KERN_ERR Could not register toshiba backlight
device\n);
+ toshiba_backlight_device = NULL;
+ toshiba_acpi_exit();
+ }
- return;
+ return (ACPI_SUCCESS(status)) ? 0 : -ENODEV;
}
Re: Preventing ACPI from Damaging Your CPU
On Friday, 13 October 2006 06:56, Mathew Brown wrote: Thanks. But is 80C safe for a CPU? As I mentioned, 70C is considered dangerous for an Opteron chip. What type of temperatures can the Turions and the C2D support? I think HP would force the fan at lower temperatures if 80C were considered as dangerous Greetings, Rafael On Fri, 13 Oct 2006 05:53:39 +0100, Matthew Garrett [EMAIL PROTECTED] said: On Thu, Oct 12, 2006 at 09:41:15PM -0700, Mathew Brown wrote: Thanks Matthew. Just out of curiosity, how did you find out about this feature (forcing the fan at 80C)? Also, is this specific to HP or do other vendors also support this? Finally, is 80C safe for the CPU (Intel or AMD?)? I read that Opteron chips could be damaged if their temperature reaches 70C. Thanks for your help. A certain amount of reverse engineering of HP hardware while I was trying to diagnose some fan problems before. The fan control chip that HP use is pretty standard, so I think there are docs around somewhere. -- Matthew Garrett | [EMAIL PROTECTED] -- Mathew Brown [EMAIL PROTECTED] -- You never change things by fighting the existing reality. R. Buckminster Fuller - 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: /proc/acpi/thermal_zone/THRM/temperature always reports 40C - is this a bug?
On Friday, 13 October 2006 07:17, Len Brown wrote: On Wednesday 11 October 2006 21:03, Daniel Drake wrote: Hi, Ethan, at http://bugs.gentoo.org/142635 reports that the thermal zone always reads 40C. Is this something that should be filed at the kernel bugzilla for further investigation, or can we simply blame a buggy/unfixable BIOS? I understand that i2c/hwmon is the more common way of measuring temperatures. Probably this isn't specific to a gentoo build and would happen just the same with a kernel.org build. So if it is a bug, it is probably an upstream bug. However, unless it used to work, or something bad happens, this is sort of an academic failure. I suppose if you ran Windows on the box and it displayed a changing temperature via ACPI but Linux does not, then it would be more interesting. It would be good to verify that ACPI events in general are working on the box -- eg. the power button etc -- as a failure there would also be more interesting than unchanging temperature. I guess it may be related to http://bugzilla.kernel.org/show_bug.cgi?id=5534 Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - 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: USB suspend/resume in linux
On Fri, 13 Oct 2006, Rafael J. Wysocki wrote: On Friday, 13 October 2006 10:39, Thomas Renninger wrote: On Thu, 2006-10-12 at 22:54 -0700, Kaburlasos, Nikos wrote: Does anyone know whether the linux USB drivers support the suspend feature on idle USB ports (i.e. the port has been idle for sometime and so the driver transitions it in to a low-power 'suspend' state) while the system is active and in S0 state? As far as I know, Windows don't support that, I was wondering if linux does. Please note, I have no background on linux or in OS programming (I am a hardware guy), so please be gentle with the level of technical detail in your response :-) AFAIK linux is not doing that. Therefore the ohci (also uhci?) drivers need to poll the ports quite often even there is no device attached. This makes C-states less efficient (what should save more power than the suspended USB ports). I thought Windows is doing that, I at least heard Mac OS is doing it like that, but I don't know for sure. The proper solution to avoid polling should be to suspend idle ports, stop polling and wait for some kind of resume/attach event, but AFAIK nobody really works on that. Would be nice if someone gives this a try... Alan Stern has been working on USB autosuspend for quite some time and there are some patches in -mm and in the recent mainline, AFAICT. Rafael is right. 2.6.19-rc1 already contains code that will suspend ports if the attached device doesn't have a driver. Under testing now is a patch to suspend ports when the attached device is idle, stop polling root-hub ports, and stop DMA activity (which is even worse than polling at keeping the processor out of low-power C states). Alan Stern - 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: USB suspend/resume in linux
Alan, will the 2.6.19-rc1 fix you mention also place USB controllers in D3 (after all the ports under them are in suspend) to save a bit of extra power? Nikos Kaburlasos -Original Message- From: Alan Stern [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 7:19 AM To: Rafael J. Wysocki Cc: [EMAIL PROTECTED]; Kaburlasos, Nikos; linux-acpi@vger.kernel.org Subject: Re: USB suspend/resume in linux On Fri, 13 Oct 2006, Rafael J. Wysocki wrote: On Friday, 13 October 2006 10:39, Thomas Renninger wrote: On Thu, 2006-10-12 at 22:54 -0700, Kaburlasos, Nikos wrote: Does anyone know whether the linux USB drivers support the suspend feature on idle USB ports (i.e. the port has been idle for sometime and so the driver transitions it in to a low-power 'suspend' state) while the system is active and in S0 state? As far as I know, Windows don't support that, I was wondering if linux does. Please note, I have no background on linux or in OS programming (I am a hardware guy), so please be gentle with the level of technical detail in your response :-) AFAIK linux is not doing that. Therefore the ohci (also uhci?) drivers need to poll the ports quite often even there is no device attached. This makes C-states less efficient (what should save more power than the suspended USB ports). I thought Windows is doing that, I at least heard Mac OS is doing it like that, but I don't know for sure. The proper solution to avoid polling should be to suspend idle ports, stop polling and wait for some kind of resume/attach event, but AFAIK nobody really works on that. Would be nice if someone gives this a try... Alan Stern has been working on USB autosuspend for quite some time and there are some patches in -mm and in the recent mainline, AFAICT. Rafael is right. 2.6.19-rc1 already contains code that will suspend ports if the attached device doesn't have a driver. Under testing now is a patch to suspend ports when the attached device is idle, stop polling root-hub ports, and stop DMA activity (which is even worse than polling at keeping the processor out of low-power C states). Alan Stern - 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: USB suspend/resume in linux
On Fri, 13 Oct 2006, Kaburlasos, Nikos wrote: Alan, will the 2.6.19-rc1 fix you mention also place USB controllers in D3 (after all the ports under them are in suspend) to save a bit of extra power? No. My work affects only the USB stack. The controllers belong to the PCI stack. There's another reason not to do this: Power Management Event handling for PCI devices isn't working. So the controller would not automatically go back into D0 when you plugged in a new USB device. Alan Stern - 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: X60s w/t kern 2.6.19-rc1-git: two BUG warnings
On Tue, Oct 10, 2006 at 08:28:26AM +0200, Martin Lorenz wrote: Dear kernel gurus, whatever I do and whic problem I seem to get fixed new ones arise: now I loose ACPI events after suspend/resume. not every time, but roughly 3 out of 4 times. the only errornous things I see in the logs are those: ... Which was the last working kernel? gruss mlo ... cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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 3/3] Add support for the generic backlight device to the TOSHIBA ACPI driver
On Fri, 13 Oct 2006 12:24:19 +0200
Holger Macht [EMAIL PROTECTED] wrote:
+static int set_lcd(int value)
+{
+ u32 hci_result;
+
+ value = value HCI_LCD_BRIGHTNESS_SHIFT;
+ hci_write1(HCI_LCD_BRIGHTNESS, value, hci_result);
+ if (hci_result != HCI_SUCCESS)
+ return -EFAULT;
+
+ return 0;
-EFAULT seems a bit random. Would -EIO be more appropriate?
-
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/2]: acpi: add generic removable drive bay support
On Friday 08 September 2006 16:33, Dave Jones wrote: On Fri, Sep 08, 2006 at 01:21:23PM -0700, Kristen Carlson Accardi wrote: On Fri, 8 Sep 2006 20:58:42 +0100 Matthew Garrett [EMAIL PROTECTED] wrote: can then be used by udev to unmount or rescan depending on the event. It will create a proc entry under /proc/acpi/bay for eject and for status. Writing Do we really want it under /proc? It would seem to make more sense for it to be under /sys. I agree - this is under proc because this is an acpi driver, and the acpi subsystem is still using the /proc fs for driver/user space interface. I thought I would just conform to their standard. It's my understanding from talking with Len that he'd like to see /proc/acpi/ go away over time, so adding more to it seems to be at odds with that goal. Dave is right. We've had a moratorium on new files under /proc/acpi for some time now. The reason is that user-space should not know or care that something is supplied by ACPI -- for on other systems it may be supplied by something else. So new stuff should have generic names under sys -- even if on a large body of systems the functionality beneath happens to be supplied via ACPI. an example of old is the brightness stuff under /proc/acpi and in various platform specific drivers that scribble under /proc/acpi. The corresponding example of new is the backlight I/F under /sys. thanks, -Len - 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
