Re: Regression in kernel linux-2.6.20-rc1/2: Problems with poweroff
On Mon, Feb 05, 2007 at 10:28:34PM -0500, Len Brown wrote: > > On Tue, Jan 02, 2007 at 12:41:59AM +0100, Berthold Cogel wrote: > > > > >> 'shutdown -h now' doesn't work for my system (Acer Extensa 3002 WLMi) > > > >> with linux-2.6.20-rc kernels. The system reboots instead. > > > >> I've checked linux-2.6.19.1 with an almost identical .config file > > > >> (differences because of new or changed options). For pre 2.6.20 kernels > > > >> shutdown works for my computer. > > Try CONFIG_USB=n CONFIG_USB_SUSPEND=n is most likely enough. That's an unfixed 2.6.20-rc regression reported more than once, the first time in December last year... > http://bugzilla.kernel.org/show_bug.cgi?id=7945 http://bugzilla.kernel.org/show_bug.cgi?id=7828 > -Len 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: Regression in kernel linux-2.6.20-rc1/2: Problems with poweroff
> On Tue, Jan 02, 2007 at 12:41:59AM +0100, Berthold Cogel wrote: > > >> 'shutdown -h now' doesn't work for my system (Acer Extensa 3002 WLMi) > > >> with linux-2.6.20-rc kernels. The system reboots instead. > > >> I've checked linux-2.6.19.1 with an almost identical .config file > > >> (differences because of new or changed options). For pre 2.6.20 kernels > > >> shutdown works for my computer. Try CONFIG_USB=n http://bugzilla.kernel.org/show_bug.cgi?id=7945 -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
Re: 2.6.20 poweroff regression on se7525gp2
On Monday 05 February 2007 00:12, Len Brown 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. Turns out that USB broke poweroff: http://bugzilla.kernel.org/show_bug.cgi?id=7945 -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
Re: [patch 06/13] ACPI: updates rtc-cmos device platform_data
By the way ... in case I was unclear about this, this does need to _follow_ the patch defining the rtc-cmos driver and its platform data. Which I'm sure it does in the MM tree, as it does in my own patchsets. :) - Dave - 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 06/13] ACPI: updates rtc-cmos device platform_data
On Mon, 5 Feb 2007 17:07:34 -0800 David Brownell <[EMAIL PROTECTED]> wrote: > By the way ... in case I was unclear about this, this does need to _follow_ > the > patch defining the rtc-cmos driver and its platform data. Which I'm sure it > does in the MM tree, as it does in my own patchsets. :) > Oh. Len, please drop. And, ideally, ack it - then I'll send both patches to Linus at the same time. Thanks. - 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
On Mon, 2007-02-05 at 14:34 +0800, Luming Yu wrote: > Well, enter a acpi bug on bugzilla with acpidump output and dmesg > attached. I put my acpidump here http://bugzilla.kernel.org/show_bug.cgi?id=6419#c65 this is the correct way to post acpidump , or do you prefer binary ? acpidump send to stderr this message: "Wrong checksum for generic table!" is this a problem ? Thanks, -- Sérgio M.B. smime.p7s Description: S/MIME cryptographic signature
Re: Synaptic touchpad freezes and lost sync messages in dmesg
I am nearly sure that it is a Synaptics device, as all OS's, that I tried recognized it as a Synaptics touchpad (Linux, FreeBSD,NetBSD) and the driver CD of the laptop (for Win) has a Synaptics driver. But thanks for the hint. Gabor 2007/2/6, Adrian Yee <[EMAIL PROTECTED]>: Hi Gabor, On Sun, 4 Feb 2007 21:18:14 +0100 "Gabor Gabris" <[EMAIL PROTECTED]> wrote: > I encountered problems on my laptop, which is an Albacomp Eco > Traveller V4 (AFAIK it is a rebranded Clevo M660S), it does not bot > Linux without ACPI (at least my UHU-Linux with kernel 2.6.17 does not > boot with acpi=off parameter), but when I use the Synaptics touchpad > in X, the cursor often freezes, and in dmesg i can see the following: Are you sure your notebook uses a Synaptics touchpad? With my Sony TX850, Debian automatically chooses to use the synaptics driver, which results in the freezing cursor and lost interrupts (iirc). My notebook actually has an ALPS touchpad, so tweaking the synaptics driver X configuration accordingly fixes things. Take a look at the README.alps file that comes with the synaptics driver if this is the case. Adrian - 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
On Mon, 2007-02-05 at 07:04 +0100, Pavel Troller wrote: > Hi! > I posted the following question, when 2.6.19 was freshly out. However, > nobody > has answered. OK, I told myself, let's get things to stabilize, and I waited > patiently for 2.6.20. Now, the things are absolutely the same, and IMHO wrong. > Could anybody look at this and decide, whether it is a real bug, which has to > be fixed, or not ? Hi , I also have a Pentium D with a very strange things http://bugzilla.kernel.org/show_bug.cgi?id=6419 have you test yours in older kernels? > With regards, Pavel Troller > > - Forwarded message from Pavel Troller <[EMAIL PROTECTED]> - > > From: Pavel Troller <[EMAIL PROTECTED]> > To: linux-acpi@vger.kernel.org > Subject: Strange things on 2.6.19 for a dual-core CPU > Mail-Followup-To: Pavel Troller <[EMAIL PROTECTED]>, > linux-acpi@vger.kernel.org > Content-Disposition: inline > User-Agent: Mutt/1.5.9i > > Hi! > I've updated to vanilla 2.6.19 on my Pentium-D (dual-core x86_64) box. > Now I can't see even C1 in the /proc/acpi/processor/*/power output: > [EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU1/power > active state:C0 > max_cstate: C8 > bus master activity: > maximum allowed latency: 2000 usec > states: > [EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU2/power > active state:C0 > max_cstate: C8 > bus master activity: > maximum allowed latency: 2000 usec > states: > > 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 -- Sérgio M.B. smime.p7s Description: S/MIME cryptographic signature
[patch 06/13] ACPI: updates rtc-cmos device platform_data
From: David Brownell <[EMAIL PROTECTED]>
Update ACPI to export its RTC extension information through platform_data
to the PNPACPI or platform bus device node used on the system being set up.
This will need to be updated later to provide a firmware hook to handle
system suspend with an alarm pending.
Len notes that "Eventually we may bundle ACPI/PNP/PNPACPI..." but if/when
that happens, ACPI can simplify this without my help.
And until it does, the separate patch creating a platform_device (on all
X86_PC systems, even without ACPI) will be needed.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Acked-by: Len Brown <[EMAIL PROTECTED]>
Cc: Bjorn Helgaas <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/acpi/glue.c | 89 ++
1 file changed, 89 insertions(+)
diff -puN drivers/acpi/glue.c~acpi-updates-rtc-cmos-device-platform_data
drivers/acpi/glue.c
--- a/drivers/acpi/glue.c~acpi-updates-rtc-cmos-device-platform_data
+++ a/drivers/acpi/glue.c
@@ -241,3 +241,92 @@ static int __init init_acpi_device_notif
}
arch_initcall(init_acpi_device_notify);
+
+
+#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE)
+
+/* Every ACPI platform has a mc146818 compatible "cmos rtc". Here we find
+ * its device node and pass extra config data. This helps its driver use
+ * capabilities that the now-obsolete mc146818 didn't have, and informs it
+ * that this board's RTC is wakeup-capable (per ACPI spec).
+ */
+#include
+
+static struct cmos_rtc_board_info rtc_info;
+
+
+#ifdef CONFIG_PNPACPI
+
+/* PNP devices are registered in a subsys_initcall();
+ * ACPI specifies the PNP IDs to use.
+ */
+#include
+
+static int __init pnp_match(struct device *dev, void *data)
+{
+ static const char *ids[] = { "PNP0b00", "PNP0b01", "PNP0b02", };
+ struct pnp_dev *pnp = to_pnp_dev(dev);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(ids); i++) {
+ if (compare_pnp_id(pnp->id, ids[i]) != 0)
+ return 1;
+ }
+ return 0;
+}
+
+static struct device *__init get_rtc_dev(void)
+{
+ return bus_find_device(&pnp_bus_type, NULL, NULL, pnp_match);
+}
+
+#else
+
+/* We expect non-PNPACPI platforms to register an RTC device, usually
+ * at or near arch_initcall(). That also helps for example PCs that
+ * aren't configured with ACPI (where this code wouldn't run, but the
+ * RTC would still be available). The device name matches the driver;
+ * that's how the platform bus works.
+ */
+#include
+
+static int __init platform_match(struct device *dev, void *data)
+{
+ struct platform_device *pdev;
+
+ pdev = container_of(dev, struct platform_device, dev);
+ return strcmp(pdev->name, "rtc_cmos") == 0;
+}
+
+static struct device *__init get_rtc_dev(void)
+{
+ return bus_find_device(&platform_bus_type, NULL, NULL, platform_match);
+}
+
+#endif
+
+static int __init acpi_rtc_init(void)
+{
+ struct device *dev = get_rtc_dev();
+
+ if (dev) {
+ rtc_info.rtc_day_alarm = acpi_gbl_FADT.day_alarm;
+ rtc_info.rtc_mon_alarm = acpi_gbl_FADT.month_alarm;
+ rtc_info.rtc_century = acpi_gbl_FADT.century;
+
+ /* NOTE: acpi_gbl_FADT->rtcs4 is NOT currently useful */
+
+ dev->platform_data = &rtc_info;
+
+ /* RTC always wakes from S1/S2/S3, and often S4/STD */
+ device_init_wakeup(dev, 1);
+
+ put_device(dev);
+ } else
+ pr_debug("ACPI: RTC unavailable?\n");
+ return 0;
+}
+/* do this between RTC subsys_initcall() and rtc_cmos driver_initcall() */
+fs_initcall(acpi_rtc_init);
+
+#endif
_
-
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 07/13] sony acpi driver
From: Stelian Pop <[EMAIL PROTECTED]> Sony ACPI driver. From: Bjorn Helgaas <[EMAIL PROTECTED]> Even though the devices claimed by sony_acpi.c can not be hot-plugged, the driver registration infrastructure allows the .add() and .remove() methods to be called at any time while the driver is registered. So remove __init and __exit from them. From: Matthew Garrett <[EMAIL PROTECTED]> in -mm only [UBUNTU:acpi/sony] Add FN hotkey support Source URL of Patch: http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=7a9b49cba4919e8506604629db03add8e0b85767 Signed-off-by: Ben Collins <[EMAIL PROTECTED]> Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- Documentation/acpi/sony_acpi.txt | 87 ++ drivers/acpi/Kconfig | 14 + drivers/acpi/Makefile|1 drivers/acpi/sony_acpi.c | 397 + 4 files changed, 499 insertions(+) diff -puN /dev/null Documentation/acpi/sony_acpi.txt --- /dev/null +++ a/Documentation/acpi/sony_acpi.txt @@ -0,0 +1,87 @@ +ACPI Sony Notebook Control Driver (SNC) Readme +-- + Copyright (C) 2004- 2005 Stelian Pop <[EMAIL PROTECTED]> + +This mini-driver drives the ACPI SNC device present in the +ACPI BIOS of the Sony Vaio laptops. + +It gives access to some extra laptop functionalities. In +its current form, this driver is mainly useful for controlling the +screen brightness, but it may do more in the future. + +You should probably start by trying the sonypi driver, and try +sony_acpi only if sonypi doesn't work for you. + +Usage: +-- + +Loading the sony_acpi module will create a /proc/acpi/sony/ +directory populated with a couple of files. + +You then read/write integer values from/to those files by using +standard UNIX tools. + +The files are: + brightness current screen brightness + brightness_default screen brightness which will be set + when the laptop will be rebooted + cdpower power on/off the internal CD drive + +Note that some files may be missing if they are not supported +by your particular laptop model. + +Example usage: + # echo "1" > /proc/acpi/sony/brightness +sets the lowest screen brightness, + # echo "8" > /proc/acpi/sony/brightness +sets the highest screen brightness, + # cat /proc/acpi/sony/brightness +retrieves the current screen brightness. + +Development: + + +If you want to help with the development of this driver (and +you are not afraid of any side effects doing strange things with +your ACPI BIOS could have on your laptop), load the driver and +pass the option 'debug=1'. + +REPEAT: DON'T DO THIS IF YOU DON'T LIKE RISKY BUSINESS. + +In your kernel logs you will find the list of all ACPI methods +the SNC device has on your laptop. You can see the GBRT/SBRT methods +used to get/set the brightness, but there are others. + +I HAVE NO IDEA WHAT THOSE METHODS DO. + +The sony_acpi driver creates, for some of those methods (the most +current ones found on several Vaio models), an entry under +/proc/acpi/sony/, just like the 'brightness' one. You can create +other entries corresponding to your own laptop methods by further +editing the source (see the 'sony_acpi_values' table, and add a new +structure to this table with your get/set method names). + +Your mission, should you accept it, is to try finding out what +those entries are for, by reading/writing random values from/to those +files and find out what is the impact on your laptop. + +Should you find anything interesting, please report it back to me, +I will not disavow all knowledge of your actions :) + +Bugs/Limitations: +- + +* This driver is not based on official documentation from Sony + (because there is none), so there is no guarantee this driver + will work at all, or do the right thing. Although this hasn't + happened to me, this driver could do very bad things to your + laptop, including permanent damage. + +* The sony_acpi and sonypi drivers do not interact at all. In the + future, sonypi could use sony_acpi to do (part of) its business. + +* spicctrl, which is the userspace tool used to communicate with the + sonypi driver (through /dev/sonypi) does not try to use the + sony_acpi driver. In the future, spicctrl could try sonypi first, + and if it isn't present, try sony_acpi instead. + diff -puN drivers/acpi/Kconfig~2.6-sony_acpi4 drivers/acpi/Kconfig --- a/drivers/acpi/Kconfig~2.6-sony_acpi4 +++ a/drivers/acpi/Kconfig @@ -278,6 +278,20 @@ config ACPI_TOSHIBA If you have a legacy free Toshiba laptop (such as the Libretto L1 series), say Y. +config ACPI_SONY + tristate "Sony Laptop Extras" + depends on X86 && ACPI + default m + ---help--- + This mini-driver drives the ACPI SNC device present in the +
[patch 09/13] acpi: add backlight support to the sony_acpi driver
From: Alessandro Guido <[EMAIL PROTECTED]>
Make the sony_acpi use the backlight subsystem to adjust brightness value
instead of using the /proc/sony/brightness file. (Other settings will
still have a /proc/sony/... entry)
Signed-off-by: Alessandro Guido <[EMAIL PROTECTED]>
Cc: Stelian Pop <[EMAIL PROTECTED]>
Cc: Richard Purdie <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/acpi/Kconfig |1
drivers/acpi/sony_acpi.c | 53 +
2 files changed, 49 insertions(+), 5 deletions(-)
diff -puN drivers/acpi/Kconfig~acpi-add-backlight-support-to-the-sony_acpi
drivers/acpi/Kconfig
--- a/drivers/acpi/Kconfig~acpi-add-backlight-support-to-the-sony_acpi
+++ a/drivers/acpi/Kconfig
@@ -281,6 +281,7 @@ config ACPI_TOSHIBA
config ACPI_SONY
tristate "Sony Laptop Extras"
depends on X86 && ACPI
+ select BACKLIGHT_CLASS_DEVICE
default m
---help---
This mini-driver drives the ACPI SNC device present in the
diff -puN drivers/acpi/sony_acpi.c~acpi-add-backlight-support-to-the-sony_acpi
drivers/acpi/sony_acpi.c
--- a/drivers/acpi/sony_acpi.c~acpi-add-backlight-support-to-the-sony_acpi
+++ a/drivers/acpi/sony_acpi.c
@@ -27,13 +27,19 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
#define ACPI_SNC_CLASS "sony"
#define ACPI_SNC_HID "SNY5001"
-#define ACPI_SNC_DRIVER_NAME "ACPI Sony Notebook Control Driver v0.2"
+#define ACPI_SNC_DRIVER_NAME "ACPI Sony Notebook Control Driver v0.3"
+
+/* the device uses 1-based values, while the backlight subsystem uses
+ 0-based values */
+#define SONY_MAX_BRIGHTNESS8
#define LOG_PFXKERN_WARNING "sony_acpi: "
@@ -49,6 +55,16 @@ MODULE_PARM_DESC(debug, "set this to 1 (
static acpi_handle sony_acpi_handle;
static struct proc_dir_entry *sony_acpi_dir;
+static int sony_backlight_update_status(struct backlight_device *bd);
+static int sony_backlight_get_brightness(struct backlight_device *bd);
+static struct backlight_device *sony_backlight_device;
+static struct backlight_properties sony_backlight_properties = {
+ .owner = THIS_MODULE,
+ .update_status = sony_backlight_update_status,
+ .get_brightness = sony_backlight_get_brightness,
+ .max_brightness = SONY_MAX_BRIGHTNESS - 1,
+};
+
static struct sony_acpi_value {
char*name; /* name of the entry */
struct proc_dir_entry *proc; /* /proc entry */
@@ -65,7 +81,7 @@ static struct sony_acpi_value {
.acpiget= "GBRT",
.acpiset= "SBRT",
.min= 1,
- .max= 8,
+ .max= SONY_MAX_BRIGHTNESS,
.debug = 0,
},
{
@@ -73,7 +89,7 @@ static struct sony_acpi_value {
.acpiget= "GPBR",
.acpiset= "SPBR",
.min= 1,
- .max= 8,
+ .max= SONY_MAX_BRIGHTNESS,
.debug = 0,
},
{
@@ -276,6 +292,7 @@ static int sony_acpi_add(struct acpi_dev
{
acpi_status status;
int result;
+ acpi_handle handle;
struct sony_acpi_value *item;
sony_acpi_handle = device->handle;
@@ -303,9 +320,15 @@ static int sony_acpi_add(struct acpi_dev
}
}
- for (item = sony_acpi_values; item->name; ++item) {
- acpi_handle handle;
+ if (ACPI_SUCCESS(acpi_get_handle(sony_acpi_handle, "GBRT", &handle))) {
+ sony_backlight_device = backlight_device_register("sony", NULL,
+ NULL, &sony_backlight_properties);
+ if (IS_ERR(sony_backlight_device)) {
+ printk(LOG_PFX "unable to register backlight device\n");
+ }
+ }
+ for (item = sony_acpi_values; item->name; ++item) {
if (!debug && item->debug)
continue;
@@ -358,6 +381,9 @@ static int sony_acpi_remove(struct acpi_
acpi_status status;
struct sony_acpi_value *item;
+ if (sony_backlight_device)
+ backlight_device_unregister(sony_backlight_device);
+
if (debug) {
status = acpi_remove_notify_handler(sony_acpi_handle,
ACPI_DEVICE_NOTIFY,
@@ -375,6 +401,23 @@ static int sony_acpi_remove(struct acpi_
return 0;
}
+static int sony_backlight_update_status(struct backlight_device *bd)
+{
+ return acpi_callsetfunc(sony_acpi_handle, "SBRT",
+ bd->props->brightness + 1,
+ NULL);
+}
+
+static int sony_backlight_get_brightness(struct backlight_device *bd)
+{
+ int value;
+
+ if (acpi_callgetfunc(sony_acpi_h
[patch 10/13] sony_acpi: add acpi_bus_generate event
From: Stelian Pop <[EMAIL PROTECTED]>
Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi subsystem,
and made correspondent necessary changes for this to work.
From: Mattia Dongili <[EMAIL PROTECTED]>
Allow the existence of a setter method without a getter and viceversa,
additionaly set /proc file permissions reflecting it. Fix also the error
exit path.
Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]>
Signed-off-by: Nilton Volpato <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/acpi/sony_acpi.c | 75 ++---
1 file changed, 45 insertions(+), 30 deletions(-)
diff -puN drivers/acpi/sony_acpi.c~sony_acpi-addacpi_bus_generate-event
drivers/acpi/sony_acpi.c
--- a/drivers/acpi/sony_acpi.c~sony_acpi-addacpi_bus_generate-event
+++ a/drivers/acpi/sony_acpi.c
@@ -54,6 +54,7 @@ MODULE_PARM_DESC(debug, "set this to 1 (
static acpi_handle sony_acpi_handle;
static struct proc_dir_entry *sony_acpi_dir;
+static struct acpi_device *sony_acpi_acpi_device = NULL;
static int sony_backlight_update_status(struct backlight_device *bd);
static int sony_backlight_get_brightness(struct backlight_device *bd);
@@ -270,7 +271,9 @@ static int sony_acpi_resume(struct acpi_
static void sony_acpi_notify(acpi_handle handle, u32 event, void *data)
{
- printk(LOG_PFX "sony_acpi_notify\n");
+ if (debug)
+ printk(LOG_PFX "sony_acpi_notify, event: %d\n", event);
+ acpi_bus_generate_event(sony_acpi_acpi_device, 1, event);
}
static acpi_status sony_walk_callback(acpi_handle handle, u32 level,
@@ -293,8 +296,11 @@ static int sony_acpi_add(struct acpi_dev
acpi_status status;
int result;
acpi_handle handle;
+ mode_t proc_file_mode;
struct sony_acpi_value *item;
+ sony_acpi_acpi_device = device;
+
sony_acpi_handle = device->handle;
acpi_driver_data(device) = NULL;
@@ -308,16 +314,16 @@ static int sony_acpi_add(struct acpi_dev
result = -ENODEV;
goto outwalk;
}
+ }
- status = acpi_install_notify_handler(sony_acpi_handle,
-ACPI_DEVICE_NOTIFY,
-sony_acpi_notify,
-NULL);
- if (ACPI_FAILURE(status)) {
- printk(LOG_PFX "unable to install notify handler\n");
- result = -ENODEV;
- goto outnotify;
- }
+ status = acpi_install_notify_handler(sony_acpi_handle,
+ACPI_DEVICE_NOTIFY,
+sony_acpi_notify,
+NULL);
+ if (ACPI_FAILURE(status)) {
+ printk(LOG_PFX "unable to install notify handler\n");
+ result = -ENODEV;
+ goto outnotify;
}
if (ACPI_SUCCESS(acpi_get_handle(sony_acpi_handle, "GBRT", &handle))) {
@@ -329,20 +335,31 @@ static int sony_acpi_add(struct acpi_dev
}
for (item = sony_acpi_values; item->name; ++item) {
+ proc_file_mode = 0;
+
if (!debug && item->debug)
continue;
if (item->acpiget &&
- ACPI_FAILURE(acpi_get_handle(sony_acpi_handle,
+ ACPI_SUCCESS(acpi_get_handle(sony_acpi_handle,
item->acpiget, &handle)))
- continue;
+ proc_file_mode = S_IRUSR;
+ else
+ printk(LOG_PFX "unable to get ACPI handle for %s
(get)\n",
+ item->name);
if (item->acpiset &&
- ACPI_FAILURE(acpi_get_handle(sony_acpi_handle,
+ ACPI_SUCCESS(acpi_get_handle(sony_acpi_handle,
item->acpiset, &handle)))
- continue;
+ proc_file_mode |= S_IWUSR;
+ else
+ printk(LOG_PFX "unable to get ACPI handle for %s
(set)\n",
+ item->name);
+
+ if (proc_file_mode == 0)
+ continue;
- item->proc = create_proc_entry(item->name, 0600,
+ item->proc = create_proc_entry(item->name, proc_file_mode,
acpi_device_dir(device));
if (!item->proc) {
printk(LOG_PFX "unable to create proc entry\n");
@@ -361,17 +378,15 @@ static int sony_acpi_add(struct acpi_dev
return 0;
outproc:
- if (debug) {
- status = acpi_remove_notify_handler(sony_acpi_handle,
- ACPI_DEVICE_NOTIFY,
-
[patch 08/13] sony_apci: add resume handling
From: Andrew Morton <[EMAIL PROTECTED]>
Avoid dimness on resume.
Cc: Stelian Pop <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/acpi/sony_acpi.c | 49 +
1 file changed, 34 insertions(+), 15 deletions(-)
diff -puN drivers/acpi/sony_acpi.c~sony_apci-resume drivers/acpi/sony_acpi.c
--- a/drivers/acpi/sony_acpi.c~sony_apci-resume
+++ a/drivers/acpi/sony_acpi.c
@@ -46,19 +46,6 @@ module_param(debug, int, 0);
MODULE_PARM_DESC(debug, "set this to 1 (and RTFM) if you want to help "
"the development of this driver");
-static int sony_acpi_add (struct acpi_device *device);
-static int sony_acpi_remove (struct acpi_device *device, int type);
-
-static struct acpi_driver sony_acpi_driver = {
- .name = ACPI_SNC_DRIVER_NAME,
- .class = ACPI_SNC_CLASS,
- .ids= ACPI_SNC_HID,
- .ops= {
- .add= sony_acpi_add,
- .remove = sony_acpi_remove,
- },
-};
-
static acpi_handle sony_acpi_handle;
static struct proc_dir_entry *sony_acpi_dir;
@@ -69,6 +56,8 @@ static struct sony_acpi_value {
char*acpiset;/* name of the ACPI get function */
int min; /* minimum allowed value or -1 */
int max; /* maximum allowed value or -1 */
+ int value; /* current setting */
+ int valid; /* Has ever been set */
int debug; /* active only in debug mode ? */
} sony_acpi_values[] = {
{
@@ -239,10 +228,30 @@ static int sony_acpi_write(struct file *
if (acpi_callsetfunc(sony_acpi_handle, item->acpiset, value, NULL) < 0)
return -EIO;
-
+ item->value = value;
+ item->valid = 1;
return count;
}
+static int sony_acpi_resume(struct acpi_device *device)
+{
+ struct sony_acpi_value *item;
+
+ for (item = sony_acpi_values; item->name; item++) {
+ int ret;
+
+ if (!item->valid)
+ continue;
+ ret = acpi_callsetfunc(sony_acpi_handle, item->acpiset,
+ item->value, NULL);
+ if (ret < 0) {
+ printk("%s: %d\n", __FUNCTION__, ret);
+ break;
+ }
+ }
+ return 0;
+}
+
static void sony_acpi_notify(acpi_handle handle, u32 event, void *data)
{
printk(LOG_PFX "sony_acpi_notify\n");
@@ -344,7 +353,6 @@ outwalk:
return result;
}
-
static int sony_acpi_remove(struct acpi_device *device, int type)
{
acpi_status status;
@@ -367,6 +375,17 @@ static int sony_acpi_remove(struct acpi_
return 0;
}
+static struct acpi_driver sony_acpi_driver = {
+ .name = ACPI_SNC_DRIVER_NAME,
+ .class = ACPI_SNC_CLASS,
+ .ids= ACPI_SNC_HID,
+ .ops= {
+ .add= sony_acpi_add,
+ .remove = sony_acpi_remove,
+ .resume = sony_acpi_resume,
+ },
+};
+
static int __init sony_acpi_init(void)
{
int result;
_
-
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 12/13] sony_acpi: allow multiple sony_acpi_values for the same .name
From: Mattia Dongili <[EMAIL PROTECTED]>
The acpi handles are kept _only_ if both the requested .acpiget and .acpiset
are available in the DSDT. Currently only the SCDP/CDPW dualism is known.
Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/acpi/sony_acpi.c | 44 +
1 file changed, 25 insertions(+), 19 deletions(-)
diff -puN
drivers/acpi/sony_acpi.c~sony_acpi-allow-multiple-sony_acpi_values-for-the-same-name
drivers/acpi/sony_acpi.c
---
a/drivers/acpi/sony_acpi.c~sony_acpi-allow-multiple-sony_acpi_values-for-the-same-name
+++ a/drivers/acpi/sony_acpi.c
@@ -68,7 +68,7 @@ static struct backlight_properties sony_
static struct sony_acpi_value {
char*name; /* name of the entry */
- struct proc_dir_entry *proc; /* /proc entry */
+ struct proc_dir_entry *proc; /* /proc entry */
char*acpiget;/* name of the ACPI get function */
char*acpiset;/* name of the ACPI get function */
int min; /* minimum allowed value or -1 */
@@ -78,6 +78,7 @@ static struct sony_acpi_value {
int debug; /* active only in debug mode ? */
} sony_acpi_values[] = {
{
+ /* for backward compatibility only */
.name = "brightness",
.acpiget= "GBRT",
.acpiset= "SBRT",
@@ -107,6 +108,14 @@ static struct sony_acpi_value {
.debug = 0,
},
{
+ .name = "cdpower",
+ .acpiget= "GCDP",
+ .acpiset= "CDPW",
+ .min= 0,
+ .max= 1,
+ .debug = 0,
+ },
+ {
.name = "audiopower",
.acpiget= "GAZP",
.acpiset= "AZPW",
@@ -356,27 +365,24 @@ static int sony_acpi_add(struct acpi_dev
if (!debug && item->debug)
continue;
- if (item->acpiget &&
- ACPI_SUCCESS(acpi_get_handle(sony_acpi_handle,
-item->acpiget, &handle)))
- proc_file_mode = S_IRUSR;
- else
- printk(LOG_PFX "unable to get ACPI handle for %s
(get)\n",
- item->name);
-
- if (item->acpiset &&
- ACPI_SUCCESS(acpi_get_handle(sony_acpi_handle,
-item->acpiset, &handle)))
- proc_file_mode |= S_IWUSR;
- else
- printk(LOG_PFX "unable to get ACPI handle for %s
(set)\n",
- item->name);
+ if (item->acpiget) {
+ if (ACPI_FAILURE(acpi_get_handle(sony_acpi_handle,
+ item->acpiget,
&handle)))
+ continue;
- if (proc_file_mode == 0)
- continue;
+ proc_file_mode |= S_IRUSR;
+ }
+
+ if (item->acpiset) {
+ if (ACPI_FAILURE(acpi_get_handle(sony_acpi_handle,
+ item->acpiset,
&handle)))
+ continue;
+
+ proc_file_mode |= S_IWUSR;
+ }
item->proc = create_proc_entry(item->name, proc_file_mode,
- acpi_device_dir(device));
+ acpi_device_dir(device));
if (!item->proc) {
printk(LOG_PFX "unable to create proc entry\n");
result = -EIO;
_
-
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 11/13] sony_acpi: add lanpower and audiopower controls
From: Mattia Dongili <[EMAIL PROTECTED]>
audiopower works well on my SZ72B so it's not marked has "debug" while
lanpower has at least one report of not resuming power happily so morked as
"debug"
Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/acpi/sony_acpi.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff -puN
drivers/acpi/sony_acpi.c~sony_acpi-add-lanpower-and-audiopower-controls
drivers/acpi/sony_acpi.c
--- a/drivers/acpi/sony_acpi.c~sony_acpi-add-lanpower-and-audiopower-controls
+++ a/drivers/acpi/sony_acpi.c
@@ -102,11 +102,27 @@ static struct sony_acpi_value {
.name = "cdpower",
.acpiget= "GCDP",
.acpiset= "SCDP",
- .min= -1,
- .max= -1,
+ .min= 0,
+ .max= 1,
.debug = 0,
},
{
+ .name = "audiopower",
+ .acpiget= "GAZP",
+ .acpiset= "AZPW",
+ .min= 0,
+ .max= 1,
+ .debug = 0,
+ },
+ {
+ .name = "lanpower",
+ .acpiget= "GLNP",
+ .acpiset= "LNPW",
+ .min= 0,
+ .max= 1,
+ .debug = 1,
+ },
+ {
.name = "PID",
.acpiget= "GPID",
.debug = 1,
_
-
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 03/13] asus_acpi: Add support for Asus Z81SP
From: Matthew C Campbell <[EMAIL PROTECTED]>
Adds support in asus_acpi for the Asus Z81SP laptop. This preserves all
old functionality when improperly detected as well as enabling Bluetooth
support.
Signed-off-by: Matthew C Campbell <[EMAIL PROTECTED]>
Cc: Corentin Chary <[EMAIL PROTECTED]>
Cc: Karol Kozimor <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/acpi/asus_acpi.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff -puN drivers/acpi/asus_acpi.c~asus_acpi-add-support-for-asus-z81sp
drivers/acpi/asus_acpi.c
--- a/drivers/acpi/asus_acpi.c~asus_acpi-add-support-for-asus-z81sp
+++ a/drivers/acpi/asus_acpi.c
@@ -141,6 +141,7 @@ struct asus_hotk {
W5A,//W5A
W3V,//W3030V
xxN,//M2400N, M3700N, M5200N, M6800N, S1300N, S5200N
+ A4S,//Z81sp
//(Centrino)
END_MODEL
} model;//Models currently supported
@@ -397,7 +398,16 @@ static struct model_data model_conf[END_
.brightness_set = "SPLV",
.brightness_get = "GPLV",
.display_set = "SDSP",
-.display_get = "\\ADVG"}
+ .display_get = "\\ADVG"},
+
+ {
+ .name = "A4S",
+ .brightness_set= "SPLV",
+ .brightness_get= "GPLV",
+ .mt_bt_switch = "BLED",
+ .mt_wled = "WLED"
+ }
+
};
/* procdir we use */
@@ -1117,6 +1127,8 @@ static int asus_model_match(char *model)
return W3V;
else if (strncmp(model, "W5A", 3) == 0)
return W5A;
+ else if (strncmp(model, "A4S", 3) == 0)
+ return A4S;
else
return END_MODEL;
}
_
-
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 13/13] sony_acpi: fix sony_acpi backlight registration and unregistration
From: Mattia Dongili <[EMAIL PROTECTED]>
Initialize the current brightness if the driver registration was successful
and unregister the driver in the error exit path.
Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/acpi/sony_acpi.c |8
1 file changed, 8 insertions(+)
diff -puN
drivers/acpi/sony_acpi.c~sony_acpi-fix-sony_acpi-backlight-registration-and-unregistration
drivers/acpi/sony_acpi.c
---
a/drivers/acpi/sony_acpi.c~sony_acpi-fix-sony_acpi-backlight-registration-and-unregistration
+++ a/drivers/acpi/sony_acpi.c
@@ -354,9 +354,14 @@ static int sony_acpi_add(struct acpi_dev
if (ACPI_SUCCESS(acpi_get_handle(sony_acpi_handle, "GBRT", &handle))) {
sony_backlight_device = backlight_device_register("sony", NULL,
NULL, &sony_backlight_properties);
+
if (IS_ERR(sony_backlight_device)) {
printk(LOG_PFX "unable to register backlight device\n");
+ sony_backlight_device = NULL;
}
+ else
+ sony_backlight_properties.brightness =
+
sony_backlight_get_brightness(sony_backlight_device);
}
for (item = sony_acpi_values; item->name; ++item) {
@@ -400,6 +405,9 @@ static int sony_acpi_add(struct acpi_dev
return 0;
outproc:
+ if (sony_backlight_device)
+ backlight_device_unregister(sony_backlight_device);
+
for (item = sony_acpi_values; item->name; ++item)
if (item->proc)
remove_proc_entry(item->name, acpi_device_dir(device));
_
-
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 02/13] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi()
From: Ingo Molnar <[EMAIL PROTECTED]>
During kernel bootup, a new T60 laptop (CoreDuo, 32-bit) hangs about
10%-20% of the time in acpi_init():
Calling initcall 0xc055ce1a: topology_init+0x0/0x2f()
Calling initcall 0xc055d75e: mtrr_init_finialize+0x0/0x2c()
Calling initcall 0xc05664f3: param_sysfs_init+0x0/0x175()
Calling initcall 0xc014cb65: pm_sysrq_init+0x0/0x17()
Calling initcall 0xc0569f99: init_bio+0x0/0xf4()
Calling initcall 0xc056b865: genhd_device_init+0x0/0x50()
Calling initcall 0xc056c4bd: fbmem_init+0x0/0x87()
Calling initcall 0xc056dd74: acpi_init+0x0/0x1ee()
It's a hard hang that not even an NMI could punch through! Frustratingly,
adding printks or function tracing to the ACPI code made the hangs go away
...
After some time an additional detail emerged: disabling the NMI watchdog
made these occasional hangs go away.
So i spent the better part of today trying to debug this and trying out
various theories when i finally found the likely reason for the hang: if
acpi_ns_initialize_devices() executes an _INI AML method and an NMI
happens to hit that AML execution in the wrong moment, the machine would
hang. (my theory is that this must be some sort of chipset setup method
doing stores to chipset mmio registers?)
Unfortunately given the characteristics of the hang it was sheer
impossible to figure out which of the numerous AML methods is impacted
by this problem.
As a workaround i wrote an interface to disable chipset-based NMIs while
executing _INI sections - and indeed this fixed the hang. I did a
boot-loop of 100 separate reboots and none hung - while without the patch
it would hang every 5-10 attempts. Out of caution i did not touch the
nmi_watchdog=2 case (it's not related to the chipset anyway and didnt
hang).
I implemented this for both x86_64 and i686, tested the i686 laptop both
with nmi_watchdog=1 [which triggered the hangs] and nmi_watchdog=2, and
tested an Athlon64 box with the 64-bit kernel as well. Everything builds
and works with the patch applied.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Len Brown <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
arch/i386/kernel/nmi.c | 28
arch/x86_64/kernel/nmi.c| 27 +++
drivers/acpi/namespace/nsinit.c |9 +
include/linux/nmi.h |9 -
4 files changed, 72 insertions(+), 1 deletion(-)
diff -puN
arch/i386/kernel/nmi.c~acpi-i686-x86_64-fix-laptop-bootup-hang-in-init_acpi
arch/i386/kernel/nmi.c
---
a/arch/i386/kernel/nmi.c~acpi-i686-x86_64-fix-laptop-bootup-hang-in-init_acpi
+++ a/arch/i386/kernel/nmi.c
@@ -369,6 +369,34 @@ void enable_timer_nmi_watchdog(void)
}
}
+static void __acpi_nmi_disable(void *__unused)
+{
+ apic_write_around(APIC_LVT0, APIC_DM_NMI | APIC_LVT_MASKED);
+}
+
+/*
+ * Disable timer based NMIs on all CPUs:
+ */
+void acpi_nmi_disable(void)
+{
+ if (atomic_read(&nmi_active) && nmi_watchdog == NMI_IO_APIC)
+ on_each_cpu(__acpi_nmi_disable, NULL, 0, 1);
+}
+
+static void __acpi_nmi_enable(void *__unused)
+{
+ apic_write_around(APIC_LVT0, APIC_DM_NMI);
+}
+
+/*
+ * Enable timer based NMIs on all CPUs:
+ */
+void acpi_nmi_enable(void)
+{
+ if (atomic_read(&nmi_active) && nmi_watchdog == NMI_IO_APIC)
+ on_each_cpu(__acpi_nmi_enable, NULL, 0, 1);
+}
+
#ifdef CONFIG_PM
static int nmi_pm_active; /* nmi_active before suspend */
diff -puN
arch/x86_64/kernel/nmi.c~acpi-i686-x86_64-fix-laptop-bootup-hang-in-init_acpi
arch/x86_64/kernel/nmi.c
---
a/arch/x86_64/kernel/nmi.c~acpi-i686-x86_64-fix-laptop-bootup-hang-in-init_acpi
+++ a/arch/x86_64/kernel/nmi.c
@@ -360,6 +360,33 @@ void enable_timer_nmi_watchdog(void)
}
}
+static void __acpi_nmi_disable(void *__unused)
+{
+ apic_write(APIC_LVT0, APIC_DM_NMI | APIC_LVT_MASKED);
+}
+
+/*
+ * Disable timer based NMIs on all CPUs:
+ */
+void acpi_nmi_disable(void)
+{
+ if (atomic_read(&nmi_active) && nmi_watchdog == NMI_IO_APIC)
+ on_each_cpu(__acpi_nmi_disable, NULL, 0, 1);
+}
+
+static void __acpi_nmi_enable(void *__unused)
+{
+ apic_write(APIC_LVT0, APIC_DM_NMI);
+}
+
+/*
+ * Enable timer based NMIs on all CPUs:
+ */
+void acpi_nmi_enable(void)
+{
+ if (atomic_read(&nmi_active) && nmi_watchdog == NMI_IO_APIC)
+ on_each_cpu(__acpi_nmi_enable, NULL, 0, 1);
+}
#ifdef CONFIG_PM
static int nmi_pm_active; /* nmi_active before suspend */
diff -puN
drivers/acpi/namespace/nsinit.c~acpi-i686-x86_64-fix-laptop-bootup-hang-in-init_acpi
drivers/acpi/namespace/nsinit.c
---
a/drivers/acpi/namespace/nsinit.c~acpi-i686-x86_64-fix-laptop-bootup-hang-in-init_acpi
+++ a/drivers/acpi/namespace/nsinit.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#define _COMPONENT ACPI_NAMESPACE
ACPI_MODULE_NAME("nsinit")
@@ -534,7 +535,15 @@ acpi_ns_init_one_device(acpi_
[patch 05/13] ACPI: Make bay depend on dock
From: Kristen Carlson Accardi <[EMAIL PROTECTED]> Since the bay driver depends on the dock driver for proper notification, make this driver depend on the dock driver. Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/acpi/Kconfig |1 + 1 file changed, 1 insertion(+) diff -puN drivers/acpi/Kconfig~acpi-make-bay-depend-on-dock drivers/acpi/Kconfig --- a/drivers/acpi/Kconfig~acpi-make-bay-depend-on-dock +++ a/drivers/acpi/Kconfig @@ -151,6 +151,7 @@ config ACPI_FAN config ACPI_DOCK tristate "Dock" depends on EXPERIMENTAL + depends on ACPI_DOCK help This driver adds support for ACPI controlled docking stations _ - 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 04/13] Exit ACPI processor module gracefully if acpi is disabled
From: Thomas Renninger <[EMAIL PROTECTED]>
Signed-off-by: Thomas Renninger <[EMAIL PROTECTED]>
Cc: Len Brown <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/acpi/processor_core.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff -puN
drivers/acpi/processor_core.c~exit-acpi-processor-module-gracefully-if-acpi-is-disabled
drivers/acpi/processor_core.c
---
a/drivers/acpi/processor_core.c~exit-acpi-processor-module-gracefully-if-acpi-is-disabled
+++ a/drivers/acpi/processor_core.c
@@ -994,6 +994,8 @@ void acpi_processor_uninstall_hotplug_no
* ACPI, but needs symbols from this driver
*/
+static int processor_driver_registered;
+
static int __init acpi_processor_init(void)
{
int result = 0;
@@ -1019,6 +1021,8 @@ static int __init acpi_processor_init(vo
return result;
}
+ processor_driver_registered = 1;
+
acpi_processor_install_hotplug_notify();
acpi_thermal_cpufreq_init();
@@ -1035,12 +1039,13 @@ static void __exit acpi_processor_exit(v
acpi_thermal_cpufreq_exit();
- acpi_processor_uninstall_hotplug_notify();
-
- acpi_bus_unregister_driver(&acpi_processor_driver);
+ if (processor_driver_registered) {
+ acpi_processor_uninstall_hotplug_notify();
- remove_proc_entry(ACPI_PROCESSOR_CLASS, acpi_root_dir);
+ acpi_bus_unregister_driver(&acpi_processor_driver);
+ remove_proc_entry(ACPI_PROCESSOR_CLASS, acpi_root_dir);
+ }
return;
}
_
-
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 01/13] ACPI: bay: remove ACPI driver struct
From: Kristen Carlson Accardi <[EMAIL PROTECTED]>
The bay driver is a platform driver, and doesn't need to also be an acpi
driver. Remove the acpi driver related structures and callbacks, they didn't
do anything anyway. Switch to uevent for user space event notification.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/acpi/bay.c | 99 +--
1 file changed, 4 insertions(+), 95 deletions(-)
diff -puN drivers/acpi/bay.c~acpi-bay-remove-acpi-driver-struct
drivers/acpi/bay.c
--- a/drivers/acpi/bay.c~acpi-bay-remove-acpi-driver-struct
+++ a/drivers/acpi/bay.c
@@ -47,18 +47,6 @@ MODULE_LICENSE("GPL");
acpi_get_name(h, ACPI_FULL_PATHNAME, &buffer);\
printk(KERN_DEBUG PREFIX "%s: %s\n", prefix, s); }
static void bay_notify(acpi_handle handle, u32 event, void *data);
-static int acpi_bay_add(struct acpi_device *device);
-static int acpi_bay_remove(struct acpi_device *device, int type);
-
-static struct acpi_driver acpi_bay_driver = {
- .name = ACPI_BAY_DRIVER_NAME,
- .class = ACPI_BAY_CLASS,
- .ids = ACPI_BAY_HID,
- .ops = {
- .add = acpi_bay_add,
- .remove = acpi_bay_remove,
- },
-};
struct bay {
acpi_handle handle;
@@ -234,14 +222,6 @@ int eject_removable_drive(struct device
}
EXPORT_SYMBOL_GPL(eject_removable_drive);
-static int acpi_bay_add(struct acpi_device *device)
-{
- bay_dprintk(device->handle, "adding bay device");
- strcpy(acpi_device_name(device), "Dockable Bay");
- strcpy(acpi_device_class(device), "bay");
- return 0;
-}
-
static int acpi_bay_add_fs(struct bay *bay)
{
int ret;
@@ -339,52 +319,6 @@ bay_add_err:
return -ENODEV;
}
-static int acpi_bay_remove(struct acpi_device *device, int type)
-{
- /*** FIXME: do something here */
- return 0;
-}
-
-/**
- * bay_create_acpi_device - add new devices to acpi
- * @handle - handle of the device to add
- *
- * This function will create a new acpi_device for the given
- * handle if one does not exist already. This should cause
- * acpi to scan for drivers for the given devices, and call
- * matching driver's add routine.
- *
- * Returns a pointer to the acpi_device corresponding to the handle.
- */
-static struct acpi_device * bay_create_acpi_device(acpi_handle handle)
-{
- struct acpi_device *device = NULL;
- struct acpi_device *parent_device;
- acpi_handle parent;
- int ret;
-
- bay_dprintk(handle, "Trying to get device");
- if (acpi_bus_get_device(handle, &device)) {
- /*
-* no device created for this object,
-* so we should create one.
-*/
- bay_dprintk(handle, "No device for handle");
- acpi_get_parent(handle, &parent);
- if (acpi_bus_get_device(parent, &parent_device))
- parent_device = NULL;
-
- ret = acpi_bus_add(&device, parent_device, handle,
- ACPI_BUS_TYPE_DEVICE);
- if (ret) {
- pr_debug("error adding bus, %x\n",
- -ret);
- return NULL;
- }
- }
- return device;
-}
-
/**
* bay_notify - act upon an acpi bay notification
* @handle: the bay handle
@@ -394,38 +328,19 @@ static struct acpi_device * bay_create_a
*/
static void bay_notify(acpi_handle handle, u32 event, void *data)
{
- struct acpi_device *dev;
+ struct bay *bay_dev = (struct bay *)data;
+ struct device *dev = &bay_dev->pdev->dev;
bay_dprintk(handle, "Bay event");
switch(event) {
case ACPI_NOTIFY_BUS_CHECK:
- printk("Bus Check\n");
case ACPI_NOTIFY_DEVICE_CHECK:
- printk("Device Check\n");
- dev = bay_create_acpi_device(handle);
- if (dev)
- acpi_bus_generate_event(dev, event, 0);
- else
- printk("No device for generating event\n");
- /* wouldn't it be a good idea to just rescan SATA
-* right here?
-*/
- break;
case ACPI_NOTIFY_EJECT_REQUEST:
- printk("Eject request\n");
- dev = bay_create_acpi_device(handle);
- if (dev)
- acpi_bus_generate_event(dev, event, 0);
- else
- printk("No device for generating eventn");
-
- /* wouldn't it be a good idea to just call the
-* eject_device here if we were a SATA device?
-*/
+ kobject_uevent(&dev->kobj, KOBJ_CHANGE);
break;
default:
- printk("unknown event %d\n", event);
+ printk(KERN_ERR PREFIX "Bay: unknown event %d\n",
Re: Bad libata resume behaviour due to ACPICA change (in acpi-test)
On Mon, 05 Feb 2007, Starikovskiy, Alexey Y wrote: > I cannot reproduce your problem with T43 here on linux-acpi-test with > defconfig (relevant ACPI modules were tried both dynamic and static). > Resume time is about 4-6 seconds, not 20-40 as you mention. Never tried a thinkpad in defconfig mode. Will do. > Could you please send your .config and try defconfig on your machine? > > BTW, my T43 use AHCI mode of SATA controller, if it matters... Mine is stuck in legacy mode, so we are using different drivers (ata_piix in my case). Which BIOS and firmware you got? What is your machine type? I am very interested in a way to get my T43 into AHCI mode... Mine is a ThinkPad T43 2687-DDU, BIOS is 1.29, EC firmware is 1.06. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - 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: Synaptic touchpad freezes and lost sync messages in dmesg
Hi Gabor, On Sun, 4 Feb 2007 21:18:14 +0100 "Gabor Gabris" <[EMAIL PROTECTED]> wrote: > I encountered problems on my laptop, which is an Albacomp Eco > Traveller V4 (AFAIK it is a rebranded Clevo M660S), it does not bot > Linux without ACPI (at least my UHU-Linux with kernel 2.6.17 does not > boot with acpi=off parameter), but when I use the Synaptics touchpad > in X, the cursor often freezes, and in dmesg i can see the following: Are you sure your notebook uses a Synaptics touchpad? With my Sony TX850, Debian automatically chooses to use the synaptics driver, which results in the freezing cursor and lost interrupts (iirc). My notebook actually has an ALPS touchpad, so tweaking the synaptics driver X configuration accordingly fixes things. Take a look at the README.alps file that comes with the synaptics driver if this is the case. Adrian - 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
[Debian etch, Medion MD97600] HAL failes to hibernate
Hello Newsgroup, if I right-cklick on my Gnome Power Manager version 2.14.3 icon and choose 'Tiefschlafmodus'/'Hibernate' my Medion MD97600 laptop computer will show a black screen but apparently nothing else changes. If I move the cursor into the center of the screen, a login dialog appears. After the login a warning appears: "Hibernate problem. HAL failed to hibernate." My ACPI functions partially: The computer reacts to varying processor loads by jumping between ACPI states C1, C2 and C3. My computer configuration is documented in http://www.ubuntuusers.de/paste/7306/ http://www.ubuntuusers.de/paste/7308/ http://www.ubuntuusers.de/paste/7309/ http://www.ubuntuusers.de/paste/7310/ http://www.ubuntuusers.de/paste/7311/ Th computer uses a Intel host bridge 915GM and Intel82801. How can I persuade my computer to suspend and to hibernate? Regards, Detlef -- Debian 4.0 "etch" Linux 2.6.17-grml#1 SMP PREEMPT 2006-07-25 i686 GNOME 2.14.3, Epiphany 2.14.3, Evolution 2.6.3, OO.o ODE 680_m4 Build-1 MD97600, WinXP MCE 2005 - 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
Hi Rudolf, My feeling: I/O-devices that provide different functions via the same register-set, should have a core that takes care of the communication with the I/O-device. (like for instance the w83627hf chipset that has sensor functionailty but also watchdog capabilities). The core needs to make sure that all different drivers can function without interfering with each other (via proper locking mechanism's off-course). You could get something like this: w83627hf_core w83627hf_sensors -> depends on w83627hf_core w83627hf_watchdog -> depends also on w83627hf_core Don't know if this is a solution for the acpi problem also. Greetings, Wim. - 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
Hi, On 2/5/07, Thomas Renninger <[EMAIL PROTECTED]> wrote: 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. Just a limited number of boxes seems to have problems... Maybe Dmitry can comment on that and push this one if still needed? I do not like the idea of removing port at shutdown. I will look into extending psmouse_cleanup so it leaves the port in the same state as psmouse_disconnect. -- Dmitry - 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
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: Bad libata resume behaviour due to ACPICA change (in acpi-test)
Henrique, I cannot reproduce your problem with T43 here on linux-acpi-test with defconfig (relevant ACPI modules were tried both dynamic and static). Resume time is about 4-6 seconds, not 20-40 as you mention. Could you please send your .config and try defconfig on your machine? BTW, my T43 use AHCI mode of SATA controller, if it matters... Regards, Alex. >-Original Message- >From: Henrique de Moraes Holschuh [mailto:[EMAIL PROTECTED] >Sent: Saturday, February 03, 2007 3:42 AM >To: linux-acpi@vger.kernel.org >Cc: Starikovskiy, Alexey Y; Brown, Len >Subject: Bad libata resume behaviour due to ACPICA change (in acpi-test) > >On an otherwise ordinary ThinkPad T43, v2.6.20-rc7-g190ff5b runs and works >beaufully, however if I apply the acpi-test patches, it adds a 40-50s pause >right after libata tries to resume the disks. > >Here's the relevant info: > >1. The relevant detail of logs of a normal resume: >Feb 1 20:50:02 thorin kernel: ata2.00: configured for UDMA/33 >Feb 1 20:50:02 thorin kernel: ata1.00: configured for UDMA/100 >Feb 1 20:50:02 thorin kernel: SCSI device sda: 117210240 512-byte hdwr >sectors (60012 MB) >Feb 1 20:50:02 thorin kernel: sda: Write Protect is off >Feb 1 20:50:02 thorin kernel: sda: Mode Sense: 00 3a 00 00 >Feb 1 20:50:02 thorin kernel: SCSI device sda: write cache: enabled, read >cache: enabled, doesn't support DPO or FUA >Feb 1 20:50:20 thorin kernel: ... > >2. The relevant detail of logs of a resume with the strange pause: >Feb 1 19:21:28 thorin kernel: Restarting tasks ... done. >Feb 1 19:21:29 thorin kernel: ata2.00: configured for UDMA/33 >Feb 1 19:21:29 thorin kernel: ata1.00: configured for UDMA/100 >Feb 1 19:21:29 thorin kernel: SCSI device sda: 117210240 512-byte hdwr >sectors (60012 MB) >Feb 1 19:21:29 thorin kernel: sda: Write Protect is off >Feb 1 19:21:29 thorin kernel: sda: Mode Sense: 00 3a 00 00 >Feb 1 19:21:29 thorin kernel: SCSI device sda: write cache: enabled, read >cache: enabled, doesn't support DPO or FUA >Feb 1 19:21:53 thorin kernel: ... > >Note the timestamps on the two last lines of the log. Another delay I had >was bigger by 20s. It is really, *really* annoying. > >3. The affected PCI device: > >00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller >(rev 03) (prog-if 80 [Master]) >Subsystem: IBM Unknown device 056a >Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >Stepping- SERR- FastB2B- >Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- >SERR- Latency: 0 >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 18c0 [size=16] >Capabilities: [70] Power Management version 2 >Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2- >,D3hot+,D3cold-) >Status: D0 PME-Enable- DSel=0 DScale=0 PME- > >4. The relevant DSDT: >http://acpi.sourceforge.net/dsdt/view.php?id=742 > >5. The culprit (insert ob. Linus-is-a-genius git bisect thanks here): > > 5559e40e60632ab6927f08cd2a2a3b65c088fc03 is first bad commit > commit 5559e40e60632ab6927f08cd2a2a3b65c088fc03 > Author: Bob Moore <[EMAIL PROTECTED]> > Date: Tue Jan 23 15:49:27 2007 +0300 > >ACPICA: Disable all wake GPEs after first one recieved > >Change for GPE support: when a wake GPE is >received, now all wake GPEs are immediately disabled to >prevent the waking GPE from firing again, and to prevent >other wake GPEs from interrupting the wake process. > >Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]> >Signed-off-by: Len Brown <[EMAIL PROTECTED]> > >I will try to run with the above commit reverted, so as to continue playing >with the acpi-test tree. > >If there is anything I can contribute to help shape up the above into >something that is not annoying for ThinkPad T43 onwers, just tell me what, >and I'll see what I can do. > >The bug is reproducible at will. > >-- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh - 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
Hi, I studied ACPI spec once a while and there is only global lock (this is used for SMM ) and also there might be some per device mutexes, but I never seen them implemented. Maybe there might be implemented some per ACPI device mutex, so regions belonging to this device will be locked if the code execution is still in device methods. I dont know if it would work for the "globaly" declared regions... Mutexes are ACPI internal things, they guard either ACPI BIOS vs. ACPI OS-side (Global Lock) or just ACPI os-side. There is no requirement for mutexes to exist for a physical device, so using them to manage access to physical device will not generally work. Second possibility is to have some kind of that port forwarder, which will direct the actual access from ACPI to the Linux driver. The driver then knows if is safe to read or write from/to that location. This principle would be also handy for the super I/O because this chips needs some magic sequence to open them, read the config and close them. There are many drivers (watchdog, parport, irda, mmc, lm-sensors) in the kernel trying to write to same super I/O port (0x2e/0x2f) this generic port forwarder would solve it too. Question for ACPI people: If I would come with some kind of this port-forwarder class - will you accept it as solution if all technical stuff is solved? I mean - will be solution acceptable in principle for you? You should be careful with such forwarder, as ACPI for example tends to be the last to access some ports during shutdown, for example... As I understand your idea, if physical device driver loads, your port forwarder switches direct ACPI access to this driver, so driver needs to advertise itself as capable of this to "forwarder". Also in case of driver suspend/shutdown/unload it needs to notify "forwarder", such that ACPI is able to directly access device again. Also, driver should preserve "state" of the device across ACPI accesses, because ACPI may not initialize device each time. It seems like every device will need in addition of having native driver to have a virtual one for ACPI... I will be glad to see any implementation of this :) Regards, Alex. - 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
Hello Alex, Thanks for the comments. > Why do you think such a solution exists? I asked help to find a solution, this does not mean I believe there is one. > One solution would be to create generic "thermal" interface, under which all > drivers could provide their capabilities... Say if lm-sensors could keep > system from overheating, it could say so, and system could skip loading of > ACPI thermal driver. Problem is, lm-sensors doesn't know, what to do to > control system. You still need to figure out, that for example turning fan #3 > on helps to decrease temp #2... It's not possible to associate termal devices > of ACPI with those from lm-sensors, so lm-sensors cannot steal info about > trip-points from ACPI, or use ACPI as a governor. Well this is quite a different level of abstraction. I believe that thermal control for laptops should be left alone, or driven by ACPI. My current focus is to stop changing the registers from ACPI AML same time as other drivers are using same device. (on desktop/server systems) This causes problems to APCI and also to other drivers. Once such collision is detected we may warn the user to use for example just the thermal module and not lm-sensors one... In ideal case user should use the ACPI thermal policy OR the lm-sensors, but without the actual inspection of ACPI bytecode there is no chance to know if ACPI and lm-sensors driver are talking to same chip? (maybe through the I/O space regions it may work, however not for smbus bused stuff, because it will advertise the controller and not the actual smbus device) > Returning to your example, there are two registers in ACPI space, access to > which should be locked by single mutex. So you could provide mapping from I/O > address to mutex. So if ACPI wants to access IO register, it asks, which > mutex it should acquire. Question on how to extend mutex lock until access to > second register remains open... So if I understand correctly you propose something like I did in 3) in my original post. However this will not help much because we need to hold the mutex longer time. If I look from the "other" side, typical driver just sets the bank, do the reads/writes and then does not care about it. This could be generalized - the driver guards its "transactions" - once done it does not care what happens with the device (suppose the driver preserves the chip state after transaction is done - this is easy for monitoring chips but hard for smbus cotrollers) I studied ACPI spec once a while and there is only global lock (this is used for SMM ) and also there might be some per device mutexes, but I never seen them implemented. Maybe there might be implemented some per ACPI device mutex, so regions belonging to this device will be locked if the code execution is still in device methods. I dont know if it would work for the "globaly" declared regions... Second possibility is to have some kind of that port forwarder, which will direct the actual access from ACPI to the Linux driver. The driver then knows if is safe to read or write from/to that location. This principle would be also handy for the super I/O because this chips needs some magic sequence to open them, read the config and close them. There are many drivers (watchdog, parport, irda, mmc, lm-sensors) in the kernel trying to write to same super I/O port (0x2e/0x2f) this generic port forwarder would solve it too. Question for ACPI people: If I would come with some kind of this port-forwarder class - will you accept it as solution if all technical stuff is solved? I mean - will be solution acceptable in principle for you? Thanks, Regards Rudolf Keep me CCed thanks. - 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
Thermal resume "regression"
Hi, Since 2.6.20 is out and nobody else seem to complain, I thought it's time to ask -- >From kernel version 2.6.18 on my JVC XP731 (a centrino-based subnotebook) would freeze when resuming from echo -n mem > /sys/power/state where it woke up flawlessly before. Turns out it did this because in drivers/acpi/thermal.c, function acpi_thermal_resume, a call to acpi_thermal_check was introduced (that's line 1415 in 2.6.20). The lockup at resume time is deterministic, i.e., it is independent of the actual temperature of the device(s). Commenting it out results in a flawless wakeup (as does removing the thermal module at suspend time). Now, I have to admit I didn't investigate matters much further, but still: acpi_thermal_check does quite a few rather fancy things, and regardless if the freeze on resume is an issue of the JVC (as the lack of other complaints suggests) or not -- is it absolutely necessary to run it during resume, when things are a nightmare to debug (which is one reason I didn't investigate further)? I for one would appreciate if it were only called after the system is up and running, when one could at least see what the kernel thinks it's doing... Disclaimer: I only have very shady ideas what's actually going on with ACPI thermal management. If not calling acpi_thermal_check actually significantly increases the likelihood of fried machines, disregard all this as layman babble, and I'll just add thermal to the list of modules that don't survive a suspend to RAM. Cheers, Markus - 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
Rudolf Marek wrote: 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) There are no any devices in the list above (e.g. there is no sm-bus/fan/thermal, e.t.c chip blocked). Please help me find the solution. Why do you think such a solution exists? One solution would be to create generic "thermal" interface, under which all drivers could provide their capabilities... Say if lm-sensors could keep system from overheating, it could say so, and system could skip loading of ACPI thermal driver. Problem is, lm-sensors doesn't know, what to do to control system. You still need to figure out, that for example turning fan #3 on helps to decrease temp #2... It's not possible to associate termal devices of ACPI with those from lm-sensors, so lm-sensors cannot steal info about trip-points from ACPI, or use ACPI as a governor. Returning to your example, there are two registers in ACPI space, access to which should be locked by single mutex. So you could provide mapping from I/O address to mutex. So if ACPI wants to access IO register, it asks, which mutex it should acquire. Question on how to extend mutex lock until access to second register remains open... Regards, Alex. - 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
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
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]
