ACPI: SBS in linux-2.6.18-rc1 - Works for me!
Hello! I've tested linux-2.6.18-rc1 with Smart Battery System enabled. It works for my Acer Extensa 3002 WLMi. No compile errors or bugs at first sight. Perhaps there should be some logic in the configuration to disable the ac and battery modules. They are not needed if SBS is active. Is it possible to load sbs and i2c-ec automatically together with the other ACPI modules? On my Debian system I had to load the modules via /etc/modules.conf. Regards, Berthold - 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: SBS in linux-2.6.18-rc1 - Works for me!
Berthold Cogel [EMAIL PROTECTED] writes: I've tested linux-2.6.18-rc1 with Smart Battery System enabled. It works for my Acer Extensa 3002 WLMi. That's good to hear! Is it possible to load sbs and i2c-ec automatically together with the other ACPI modules? On my Debian system I had to load the modules via /etc/modules.conf. I use a similar approach (for the 'old style' SBS) in /etc/rc.local: /sbin/modprobe -r battery /sbin/modprobe -r ac /sbin/modprobe i2c-acpi-ec /sbin/modprobe acpi-sbs W.r.t. enabling/disabling acbattery when sbs is selected: I'm not so sure if that would be a good idea. You build a kernel with modules, and at some later stage it is selected which modules will be actually be used. -- Johan - 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: kacpi_notify?
On Thu, 13 Jul 2006, Starikovskiy, Alexey Y wrote: I'm terribly sorry that my patch broke on your machine. May I ask you to send me or attach to #5534 output of acpidump from this machine? I'll send it in another email, since I already generated it for Len ;) Do you think that the whole idea is crap, or if I limit number of possible spawned threads and forsibly put current thread to sleep (which will release ACPICA executer mutex), as it happens in DSDT of nx6125 it will be possible to use it? I don't think the _idea_ is crap per se, but it would at a minimum need a thread limit. But I think it's the wrong approach: especially if you put the current thread to sleep, you really don't want another thread at all, you are really just working around a problem that is totally internal to acpi (and the AML interpreter in particular). So I think the problem really lies elsewhere, and that the whole thread approach was trying to paper over it. And having a limited set of threads is probably potentially _worse_ then what we have now. Is there no way to have the AML interpreter have some state, and just push that current interrupted state back onto the event queue, and just start executing the new one instead? That sounds like it should fix the _real_ problem - a kind of mini-scheduler for ACPI events? Linus - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 1/5] ACPI: Atlas ACPI driver
Jaya,
Thanks for updating this patch.
Note that this driver can not be accepted into the kernel without
an entry being added to the MAINTAINERS file showing who is
going to look after it.
Preferably, that person should be inside Atlas, or have documentation
or other connections or insight into the platform. I can't maintain it
because I don't have any of the above, and while this platform
specific driver uses ACPI, it is not part of ACPI.
Yes, I know that you were following the existing examples of
platform-specific drivers in /drivers/acpi, but those examples
need to change (and they are a little more complex than this one
b/c they scribble in their own unique ways /proc/acpi...)
But think sonypi, instead.
So when this does make it upstream, it will have to live outside
the /drivers/acpi/ directory, and acpi should not be part of
the driver name. It should build depending on CONFIG_ACPI,
and should load depending on acpi_disabled, and should use
ACPI routines that are exported by the ACPI sub-system (it does,
though the headers are so incestuous at this point that it isn't
enforced)
thanks,
-Len
ps.
I believe that you want to delete the reference below to
/proc/acpi/event, yes?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, July 07, 2006 2:53 AM
To: Brown, Len
Cc: linux-acpi@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; Yu, Luming
Subject: [patch 1/5] ACPI: Atlas ACPI driver
From: [EMAIL PROTECTED]
An ACPI driver for Atlas boards, including input support.
Signed-off-by: Jaya Kumar [EMAIL PROTECTED]
Cc: Brown, Len [EMAIL PROTECTED]
Cc: Dmitry Torokhov [EMAIL PROTECTED]
Cc: Yu, Luming [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/acpi/Kconfig | 13 ++
drivers/acpi/Makefile |1
drivers/acpi/atlas_acpi.c | 191
3 files changed, 204 insertions(+), 1 deletion(-)
diff -puN /dev/null drivers/acpi/atlas_acpi.c
--- /dev/null
+++ a/drivers/acpi/atlas_acpi.c
@@ -0,0 +1,191 @@
+/*
+ * atlas_acpi.c - Atlas Wallmount Touchscreen ACPI Extras
+ *
+ * Copyright (C) 2006 Jaya Kumar
+ * Based on Toshiba ACPI by John Belmonte and ASUS ACPI
+ * This work was sponsored by CIS(M) Sdn Bhd.
+ *
+ * This program is free software; you can redistribute it
and/or modify
+ * it under the terms of the GNU General Public License as
published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/input.h
+#include linux/types.h
+#include linux/proc_fs.h
+#include asm/uaccess.h
+#include acpi/acpi_drivers.h
+
+#define ACPI_ATLAS_NAME Atlas ACPI
+#define ACPI_ATLAS_CLASS Atlas
+#define ACPI_ATLAS_BUTTON_HID ASIM
+
+#ifdef CONFIG_INPUT
+static struct input_dev *input_dev;
+
+static void atlas_input_report(u8 address)
+{
+ int keycode;
+
+ keycode = KEY_F1 + (address 0x0F);
+
+ if (address 0x10)
+ input_report_key(input_dev, keycode, 0);
+ else
+ input_report_key(input_dev, keycode, 1);
+ input_sync(input_dev);
+}
+
+static int atlas_setup_input(void)
+{
+ int err;
+
+ input_dev = input_allocate_device();
+ if (!input_dev) {
+ printk(KERN_ERR atlas: insufficient mem to
allocate input
+ device\n);
+ return -ENOMEM;
+ }
+
+ input_dev-name = Atlas ACPI button driver;
+ input_dev-phys = acpi/input0;
+ input_dev-id.bustype = BUS_HOST;
+ input_dev-evbit[LONG(EV_KEY)] = BIT(EV_KEY);
+ set_bit(KEY_F1, input_dev-keybit);
+ set_bit(KEY_F2, input_dev-keybit);
+ set_bit(KEY_F3, input_dev-keybit);
+ set_bit(KEY_F4, input_dev-keybit);
+ set_bit(KEY_F5, input_dev-keybit);
+ set_bit(KEY_F6, input_dev-keybit);
+ set_bit(KEY_F7, input_dev-keybit);
+ set_bit(KEY_F8, input_dev-keybit);
+ set_bit(KEY_F9, input_dev-keybit);
+
+ err = input_register_device(input_dev);
+ if (err) {
+ printk(KERN_ERR atlas: couldn't register input
device\n);
+ input_free_device(input_dev);
+ return err;
+ }
+
+ return 0;
+}
+
+static void atlas_free_input(void)
+{
+ if (input_dev)
+ input_unregister_device(input_dev);
+
+}
+#else
+#define atlas_free_input(...)
Re: [patch 1/5] ACPI: Atlas ACPI driver
On 7/13/06, Brown, Len [EMAIL PROTECTED] wrote: Jaya, Thanks for updating this patch. Note that this driver can not be accepted into the kernel without an entry being added to the MAINTAINERS file showing who is going to look after it. Preferably, that person should be inside Atlas, or have documentation or other connections or insight into the platform. I can't maintain it because I don't have any of the above, and while this platform specific driver uses ACPI, it is not part of ACPI. Yes, I know that you were following the existing examples of platform-specific drivers in /drivers/acpi, but those examples need to change (and they are a little more complex than this one b/c they scribble in their own unique ways /proc/acpi...) But think sonypi, instead. If you prefer I can stuff it in drivers/input/touchscreen/ . -- 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: [patch 4/5] ACPI: disable SBS by default
Hi, On Sun, 9 Jul 2006, Brown, Len wrote: Default is 'n' when omitted... This default stuff seems to be make-work without any real value. At one time we had default =m to try to show what a reasonable usable configuration was. These got globally replaced to =y because apparently it is taboo to have default =m. But =y defaults don't make much sense either, particularly if you use =m like most people do. The last time we discussed this, Roman suggested deleting all the defaults that require human interaction. As the concept appears to be meaningless, I'm inclined to agree. The problem with using defaults is, if something should be enabled, maybe it shouldn't be a config option at all or at least be hidden. In the future this should all be part of an autoconfiguration process, where a base configuration is generated from different sources (e.g. a script which looks at the current kernel or machine specific default config). The point is that the defaults can depend on a lot of parameters, one of which is the user himself and every user likes different defaults. So until we have a better autoconfiguration it's better to avoid abusing the defaults. The current configuration system is not ready for aunt Tilly yet, it would be far better to provide useful help texts to allow the user to make reasonable a decision and the majority of the defaults should come from a different source anyway (the current kernel configuration) and for any new configuration option which can cause a kernel to be unbootable should maybe not an option. bye, Roman - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/5] ACPI: Atlas ACPI driver
On 7/14/06, Brown, Len [EMAIL PROTECTED] wrote: Note that this driver can not be accepted into the kernel without an entry being added to the MAINTAINERS file showing who is going to look after it. Ok. I'll add a maintainers entry for myself. Yes, I know that you were following the existing examples of platform-specific drivers in /drivers/acpi, but those examples need to change (and they are a little more complex than this one b/c they scribble in their own unique ways /proc/acpi...) But think sonypi, instead. Ok. Will do. I'll move it to drivers/input/touchscreen/ as per Dmitry's suggestion. So when this does make it upstream, it will have to live outside the /drivers/acpi/ directory, and acpi should not be part of the driver name. It should build depending on CONFIG_ACPI, and should load depending on acpi_disabled, and should use ACPI routines that are exported by the ACPI sub-system (it does, though the headers are so incestuous at this point that it isn't enforced) Ok. Will do. thanks, -Len ps. I believe that you want to delete the reference below to /proc/acpi/event, yes? Yes, I did. That one was posted here: http://marc.theaimsgroup.com/?l=linux-acpim=115233799829220w=2 Thanks, jaya - 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 4/5] ACPI: disable SBS by default
Default is 'n' when omitted... This default stuff seems to be make-work without any real value. At one time we had default =m to try to show what a reasonable usable configuration was. These got globally replaced to =y because apparently it is taboo to have default =m. But =y defaults don't make much sense either, particularly if you use =m like most people do. The last time we discussed this, Roman suggested deleting all the defaults that require human interaction. As the concept appears to be meaningless, I'm inclined to agree. The problem with using defaults is, if something should be enabled, maybe it shouldn't be a config option at all or at least be hidden. In the future this should all be part of an autoconfiguration process, where a base configuration is generated from different sources (e.g. a script which looks at the current kernel or machine specific default config). The point is that the defaults can depend on a lot of parameters, one of which is the user himself and every user likes different defaults. So until we have a better autoconfiguration it's better to avoid abusing the defaults. The current configuration system is not ready for aunt Tilly yet, it would be far better to provide useful help texts to allow the user to make reasonable a decision and the majority of the defaults should come from a different source anyway (the current kernel configuration) and for any new configuration option which can cause a kernel to be unbootable should maybe not an option. Lets take a concrete example. CONFIG_ACPI_BUTTON It is totally nuts to to to the trouble of includeing CONFIG_ACPI and not including the few lines of code necessary to handle your power button. But at the same time, most people use =m for this because on a non-ACPI system they want as much out as possible. so we have default y conflicts with most popular use of =m default m taboo default n, no no default makes no sense, give that we get here only if CONFIG_ACPI... Seems the choices are to make the default to =m if modules are enabled, and default to y otherwise, or to simply grow the kernel and have it hard-wired to y with no choice. What do you recommend? 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
