Re: [0/12] acpi: make ACPI use driver model
On Wed, 2006-10-25 at 14:40 -0600, Bjorn Helgaas wrote: > On Friday 22 September 2006 03:14, Zhang Rui wrote: > > Make ACPI use driver model. > > What's happening with this series? It doesn't seem to be in -mm > yet. Some of this stuff has been kicking around for a year already. > It'd be nice to go forward or give up on the idea. > Len will add them to -mm tree soon. :) thanks, Rui - 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: ia64 acpi-cpufreq driver
>-Original Message- >From: Bjorn Helgaas [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 25, 2006 4:21 PM >To: Pallipadi, Venkatesh >Cc: linux-acpi@vger.kernel.org; linux-ia64@vger.kernel.org >Subject: Re: ia64 acpi-cpufreq driver > >On Monday 23 October 2006 22:46, Pallipadi, Venkatesh wrote: >> >Section 8.4.4.1 (_PCT) of the 3.0 ACPI spec says: >> > >> > OSPM performs processor performance transitions by writing >> > the performance state-specific control value to a Performance >> > Control Register (PERF_CTRL). >> > >> >According to one of our architecture guys, this means we really >> >ought to have an OpRegion driver that encapsulates the >PAL_SET_PSTATE >> >call. >> >> Actually it is slightly different from low_level_read and write. >> Generic ACPI definition of ACPI PERF_CTRL and PERF_STATUS define >> them as if they are registers. But, with FfixedHW, ACPI allows >> architectures to implement this functionality in a native way. > >I'd like to understand this better. Something like the following >patch (not for inclusion, may not even compile) is what I'm >thinking. This seems more in line with the spec intent. > >Apart from details like "bit_width <= 8" vs. "bit_width == 8", >this should be functionally the same. Are you saying it's different >because of those details, or is there a larger difference I don't >understand? > Yes. Something like this will work. I don't think it is the intent of the SPEC. As I understand, FFH in SPEC is intended to be used whenever we have hardware/processor specific interfaces (As described in ACPI 3.0 spec - page 46). Also, it will complicate the code. I think having separate code, even if there is some amount of duplication is there, is better in this case. The reasons: - i386 acpi-cpufreq code has support for both IO port and FFH. Please refer to arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c in 2.6.19-rc2-mm2, which is a lot different from current git. - FFH in i386 works in a different way from IPF. Specifically, PERF_STATUS is just a register read, and hardware performance feedback is by using different APERF/MPERF MSR. But, in IPF it is done through passing a different type parameter to same PAL_GET_PSTATE calls (will be adding this to IPF driver soon). Thanks, Venki - 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: cpufreq frequencies off for Core 2 Duo E6600 "Conroe"
Hi, On Tue, Oct 10, 2006 at 02:41:03AM +0200, Matthias Hentges wrote: > I'm the happy user of a shiny new C2D E6600 CPU. While cpufreq works, it > only offers support for the lowest possible frequency (1596MHz) That's probably because the BIOS only exposes the lowest and the highest frequency. > There is another thing bugging me with cpufreq: > [EMAIL PROTECTED]:../system/cpu/cpu0/cpufreq >cat scaling_cur_freq > 1596000 > [EMAIL PROTECTED]:../system/cpu/cpu0/cpufreq >cat cpuinfo_cur_freq > 1596000 > > Since the machine is overclocked to FSB301 (2.7GHz), the output above is > clearly wrong (should read 6 x 301 = 1806MHz). I wonder if it would be > possible to replace the output with the real frequency, not some > hard-wired frequency/vcore value? Not easily. Dominik - 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: powernow-k8 and thermal / voltage data
Hi, On Mon, Oct 16, 2006 at 06:50:02AM -0700, Mathew Brown wrote: > I've successfully gotten CPU frequency scaling working (which I > tested by looking at the cpu frequency before and during running a > CPU intensive task). However, there are currently 2 issues: > > 1) cat /proc/acpi/thermal_zone/* is empty (there's nothing under the > thermal_zone directory) That's a BIOS issue -- if the BIOS does not expose thermal zones, then they cannot be displayed there. Dominik - 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: ia64 acpi-cpufreq driver
On Monday 23 October 2006 22:46, Pallipadi, Venkatesh wrote:
> >Section 8.4.4.1 (_PCT) of the 3.0 ACPI spec says:
> >
> > OSPM performs processor performance transitions by writing
> > the performance state-specific control value to a Performance
> > Control Register (PERF_CTRL).
> >
> >According to one of our architecture guys, this means we really
> >ought to have an OpRegion driver that encapsulates the PAL_SET_PSTATE
> >call.
>
> Actually it is slightly different from low_level_read and write.
> Generic ACPI definition of ACPI PERF_CTRL and PERF_STATUS define
> them as if they are registers. But, with FfixedHW, ACPI allows
> architectures to implement this functionality in a native way.
I'd like to understand this better. Something like the following
patch (not for inclusion, may not even compile) is what I'm
thinking. This seems more in line with the spec intent.
Apart from details like "bit_width <= 8" vs. "bit_width == 8",
this should be functionally the same. Are you saying it's different
because of those details, or is there a larger difference I don't
understand?
Nacked-by: Bjorn Helgaas
Index: work-1/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
===
--- work-1.orig/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c 2006-10-25
17:04:46.0 -0600
+++ work-1/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c 2006-10-25
17:07:34.0 -0600
@@ -61,55 +61,16 @@
static unsigned int acpi_pstate_strict;
static int
-acpi_processor_write_port(
- u16 port,
- u8 bit_width,
- u32 value)
-{
- if (bit_width <= 8) {
- outb(value, port);
- } else if (bit_width <= 16) {
- outw(value, port);
- } else if (bit_width <= 32) {
- outl(value, port);
- } else {
- return -ENODEV;
- }
- return 0;
-}
-
-static int
-acpi_processor_read_port(
- u16 port,
- u8 bit_width,
- u32 *ret)
-{
- *ret = 0;
- if (bit_width <= 8) {
- *ret = inb(port);
- } else if (bit_width <= 16) {
- *ret = inw(port);
- } else if (bit_width <= 32) {
- *ret = inl(port);
- } else {
- return -ENODEV;
- }
- return 0;
-}
-
-static int
acpi_processor_set_performance (
struct cpufreq_acpi_io *data,
unsigned intcpu,
int state)
{
- u16 port = 0;
- u8 bit_width = 0;
int i = 0;
- int ret = 0;
u32 value = 0;
int retval;
struct acpi_processor_performance *perf;
+ acpi_status status;
dprintk("acpi_processor_set_performance\n");
@@ -132,16 +93,16 @@
* control_register.
*/
- port = perf->control_register.address;
- bit_width = perf->control_register.bit_width;
value = (u32) perf->states[state].control;
- dprintk("Writing 0x%08x to port 0x%04x\n", value, port);
+ dprintk("Writing 0x%08x to PERF_CTRL\n", value);
- ret = acpi_processor_write_port(port, bit_width, value);
- if (ret) {
- dprintk("Invalid port width 0x%04x\n", bit_width);
- return (ret);
+ status = acpi_hw_low_level_write(perf->control_register.bit_width,
+ value, perf->control_register);
+
+ if (ACPI_FAILURE(status)) {
+ dprintk("Failure writing PERF_CTRL\n");
+ return -ENODEV;
}
/*
@@ -157,17 +118,15 @@
* before giving up.
*/
- port = perf->status_register.address;
- bit_width = perf->status_register.bit_width;
-
- dprintk("Looking for 0x%08x from port 0x%04x\n",
- (u32) perf->states[state].status, port);
+ dprintk("Looking for 0x%08x from PERF_CTRL\n",
+ (u32) perf->states[state].status);
for (i = 0; i < 100; i++) {
- ret = acpi_processor_read_port(port, bit_width, &value);
- if (ret) {
- dprintk("Invalid port width 0x%04x\n",
bit_width);
- return (ret);
+ status =
acpi_hw_low_level_read(perf->control_register.bit_width,
+ &value, perf->control_register);
+ if (ACPI_FAILURE(status)) {
+ dprintk("Failure reading PERF_CTRL\n");
+ return -ENODEV;
}
if (value == (u32) perf->states[state].status)
break;
@@ -473,15 +432,6 @@
goto err_unreg;
}
- if ((perf-
Re: [0/12] acpi: make ACPI use driver model
On Friday 22 September 2006 03:14, Zhang Rui wrote: > Make ACPI use driver model. What's happening with this series? It doesn't seem to be in -mm yet. Some of this stuff has been kicking around for a year already. It'd be nice to go forward or give up on the idea. > Patrick has posted patches on rewriting ACPI driver model in November 2005. > And recently Shaohua send me a prototype on making ACPI use driver model. > This patch series bases on both Patrick and Shaohua's previous work. > > Two features are gonna to be changed by applying this series of patches. > 1.ACPI driver model. > ACPI driver are made to follow Linux driver model. > The mainly work is to convert the registeration interfaces, so that > ACPI devices are registered with the global device tree. > Note the new .uevent method mark ACPI drivers by PNPID > instead of by name. Udev script needs to look for "HWID = " > or "COMPTID = " to load the right ACPI driver. > 2.ACPI sysfs interface. > As a result of using driver model, ACPI devices is added in the > /sys/device tree. So after _EJ0 is added as a property of > ACPI device in device tree, /sys/firm/acpi is deleted. > Note that the corresponding userspace script needs to be changed > for hot removal. > > Note that this is only the first step of ACPI sysfs convert project. > The next step is to duplicate /proc/acpi functions in /sys/device tree. > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] ACPI: asus_acpi: return -ENODEV when no device found
This driver is for non-hot-pluggable hardware. Therefore, if the hardware
isn't present, we want to return -ENODEV so a module load will fail.
We previously returned "result" from the acpi_bus_register_driver() call.
Registering the driver usually succeeds even if no devices are present,
because the ACPI core allows you to load a driver before a device is
hot-added.
Someday the kernel will expose enough information so user-space can tell
what ACPI drivers should be loaded. But the kernel doesn't do that yet, so
distros have to load this driver always and rely on the -ENODEV causing the
load to fail if the hardware isn't found.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-1/drivers/acpi/asus_acpi.c
===
--- work-1.orig/drivers/acpi/asus_acpi.c2006-10-24 15:35:24.0
-0600
+++ work-1/drivers/acpi/asus_acpi.c 2006-10-24 15:37:54.0 -0600
@@ -1367,7 +1367,7 @@
if (!asus_hotk_found) {
acpi_bus_unregister_driver(&asus_hotk_driver);
remove_proc_entry(PROC_ASUS, acpi_root_dir);
- return result;
+ return -ENODEV;
}
return 0;
-
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: Runtime GPEs not saved over suspend/resume if type != "platform"
On Wednesday, 25 October 2006 18:35, Alexey Starikovskiy wrote:
> Here is a least intrusive patch by my opinion...
> Just copy pm_disk_mode from pm_ops supplied by platform.
> ACPI sets it to PM_DISK_PLATFORM if it has S4,
> and it should be zero otherwise, patch does not copy it then.
Well, I think the appended patch is sufficient.
If "platform" is unavailable it has no effect and works like "shutdown".
Greetings,
Rafael
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
kernel/power/disk.c |8 +---
kernel/power/main.c |2 +-
2 files changed, 6 insertions(+), 4 deletions(-)
Index: linux-2.6.19-rc2-mm2/kernel/power/main.c
===
--- linux-2.6.19-rc2-mm2.orig/kernel/power/main.c
+++ linux-2.6.19-rc2-mm2/kernel/power/main.c
@@ -28,7 +28,7 @@
DECLARE_MUTEX(pm_sem);
struct pm_ops *pm_ops;
-suspend_disk_method_t pm_disk_mode = PM_DISK_SHUTDOWN;
+suspend_disk_method_t pm_disk_mode = PM_DISK_PLATFORM;
/**
* pm_set_ops - Set the global power method table.
Index: linux-2.6.19-rc2-mm2/kernel/power/disk.c
===
--- linux-2.6.19-rc2-mm2.orig/kernel/power/disk.c
+++ linux-2.6.19-rc2-mm2/kernel/power/disk.c
@@ -61,9 +61,11 @@ static void power_down(suspend_disk_meth
switch(mode) {
case PM_DISK_PLATFORM:
- kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
- error = pm_ops->enter(PM_SUSPEND_DISK);
- break;
+ if (pm_ops && pm_ops->enter) {
+ kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
+ error = pm_ops->enter(PM_SUSPEND_DISK);
+ break;
+ }
case PM_DISK_SHUTDOWN:
kernel_power_off();
break;
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.18-mm2] acpi: add backlight support to the sony_acpi driver
On Wednesday 25 October 2006 15:07, Pavel Machek wrote:
> Hi!
>
> > > > a generic ACPI driver that exports the _BCL and _BCM method
> > > > implementations via that same interface, so that systems providing
> > > > that will "just work". drivers/acpi/video.c currently exports this
> > > > via /proc/acpi/video/$DEVICE/brightness, which isn't the same as
> > > > /sys/class/backlight. :-(
> > >
> > > Yes, I'm working on acpi video driver transition , and have posted a
> > > patch to user backlight for acpi video driver.
> > > http://marc.theaimsgroup.com/?l=linux-acpi&m=115574087203605&w=2
> >
> > Just updated the backlight and output sysfs support for ACPI Video driver
> > on bugzilla. If you are interested this, please take a look at
> > http://bugzilla.kernel.org/show_bug.cgi?id=5749#c18
> >
> > [patch 1/3] vidoe sysfs support: Add dev argument for baclight sys dev
>
> Two typos in one line :-).
>
> > [patch 2/3] Add display output class support
>
> I guess this needs Documentation/ so we can tell if user<->kernel
> interface is sane..
>
> > [patch 3/3] backlight and output sysfs support for acpi video driver
>
> Some whitespace is not okay there...
> Pavel
updated version.
[patch 1/4] video sysfs support: Add dev argument for backlight sys dev
drivers/video/backlight/backlight.c |3 ++-
include/linux/backlight.h |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
[patch 2/4] Add display output class support
drivers/video/output.c | 110
+
include/linux/output.h | 23 ++
2 files changed, 133 insertions(+)
[patch 3/4] backlight and output sysfs support for acpi video driver
acpi/Kconfig |2
acpi/video.c | 257
+
video/Kconfig |8 +
video/Makefile |1
4 files changed, 252 insertions(+), 16 deletions(-)
[patch 4/4] Add output class document
video-output.txt | 27 +++
1 file changed, 27 insertions(+)
Thanks,
Luming
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index 27597c5..1a18cdb 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -190,7 +190,7 @@ static int fb_notifier_callback(struct n
* Creates and registers new backlight class_device. Returns either an
* ERR_PTR() or a pointer to the newly allocated device.
*/
-struct backlight_device *backlight_device_register(const char *name, void *devdata,
+struct backlight_device *backlight_device_register(const char *name,struct device *dev, void *devdata,
struct backlight_properties *bp)
{
int i, rc;
@@ -206,6 +206,7 @@ struct backlight_device *backlight_devic
new_bd->props = bp;
memset(&new_bd->class_dev, 0, sizeof(new_bd->class_dev));
new_bd->class_dev.class = &backlight_class;
+ new_bd->class_dev.dev = dev;
strlcpy(new_bd->class_dev.class_id, name, KOBJ_NAME_LEN);
class_set_devdata(&new_bd->class_dev, devdata);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 75e91f5..de8e056 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -54,7 +54,7 @@ struct backlight_device {
};
extern struct backlight_device *backlight_device_register(const char *name,
- void *devdata, struct backlight_properties *bp);
+ struct device *dev, void *devdata, struct backlight_properties *bp);
extern void backlight_device_unregister(struct backlight_device *bd);
#define to_backlight_device(obj) container_of(obj, struct backlight_device, class_dev)
diff --git a/drivers/video/output.c b/drivers/video/output.c
new file mode 100644
index 000..bcb2c53
--- /dev/null
+++ b/drivers/video/output.c
@@ -0,0 +1,110 @@
+/*
+ * Video output switch support
+ */
+
+#include
+#include
+#include
+#include
+
+
+MODULE_DESCRIPTION("Output Lowlevel Control Abstraction");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Luming Yu <[EMAIL PROTECTED]>");
+
+static ssize_t video_output_show_state (struct class_device *dev, char *buf)
+{
+ ssize_t ret_size = 0;
+ struct output_device *od = to_output_device(dev);
+
+ if(od->props)
+ ret_size = sprintf(buf, "%.8x\n", od->props->get_status(od));
+
+ return ret_size;
+}
+
+static ssize_t video_output_store_state (struct class_device *dev, const char *buf, size_t count)
+{
+ char *endp;
+ struct output_device *od = to_output_device(dev);
+ int request_state = simple_strtoul(buf, &endp, 0);
+ size_t size = endp -buf;
+
+if (*endp && isspace(*endp))
+size++;
+if (size != count)
+return -EINVAL;
+
+ if(od->props){
+ od->request_state = request_state;
+ od->props->set_state(od);
+ }
+ return count;
+}
+
+static void video_output_class_release(struct class_device *dev)
+{
+struct output_device *od = to_output_device(dev);
+kfree(od);
+}
+
+static struct class_device_attribute video_out
Re: Runtime GPEs not saved over suspend/resume if type != "platform"
Here is a least intrusive patch by my opinion...
Just copy pm_disk_mode from pm_ops supplied by platform.
ACPI sets it to PM_DISK_PLATFORM if it has S4,
and it should be zero otherwise, patch does not copy it then.
Regards,
Alex.
Yu, Luming wrote:
>> There is a problem with swsuspend and GPE events.
>> Now they are restored from acpi_pm_finish(), which is called only if we
>> suspend with "platform" option, what means that if we suspended to disk
>> with the default "shutdown" option after resume all the GPEs
>> will be disabled.
>> This presents us with the overheating problem after resume at
>> very least.
>> I see two solutions: one is to make "platform" to be default
>> option if ACPI is enabled,
>> and second -- enable GPE events from some other function,
>> which will be called in any case.
>>
>> What do you think?
>>
>
> I prefer platform S4 as default...
>
> --Luming
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Copy non-null pm_disk_mode option from pm_ops.
From: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
kernel/power/main.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 873228c..2085611 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -38,6 +38,8 @@ void pm_set_ops(struct pm_ops * ops)
{
down(&pm_sem);
pm_ops = ops;
+ if (pm_ops && pm_ops->pm_disk_mode)
+ pm_disk_mode = pm_ops->pm_disk_mode;
up(&pm_sem);
}
RE: Runtime GPEs not saved over suspend/resume if type != "platform"
>Obviously we can "fix" that in the short run by causing >"platform" to be the >default. Still, I think swsusp should work regardless of >whether "platform" >or "shutdown" is used. If a platform support ACPI, I guess, we'd better enable platform S4 by default. Otherwise, sooner or later, it will ran into some issues... Thanks, Luming - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Runtime GPEs not saved over suspend/resume if type != "platform"
> >There is a problem with swsuspend and GPE events. >Now they are restored from acpi_pm_finish(), which is called only if we >suspend with "platform" option, what means that if we suspended to disk >with the default "shutdown" option after resume all the GPEs >will be disabled. >This presents us with the overheating problem after resume at >very least. >I see two solutions: one is to make "platform" to be default >option if ACPI is enabled, >and second -- enable GPE events from some other function, >which will be called in any case. > >What do you think? > I prefer platform S4 as default... --Luming - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Runtime GPEs not saved over suspend/resume if type != "platform"
Hi, On Wednesday, 25 October 2006 16:42, Alexey Starikovskiy wrote: > Hi, > > There is a problem with swsuspend and GPE events. > Now they are restored from acpi_pm_finish(), which is called only if we > suspend with "platform" option, what means that if we suspended to disk > with the default "shutdown" option after resume all the GPEs will be disabled. > This presents us with the overheating problem after resume at very least. > I see two solutions: one is to make "platform" to be default option if ACPI > is enabled, > and second -- enable GPE events from some other function, which will be > called in any case. > > What do you think? Obviously we can "fix" that in the short run by causing "platform" to be the default. Still, I think swsusp should work regardless of whether "platform" or "shutdown" is used. 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
Runtime GPEs not saved over suspend/resume if type != "platform"
Hi, There is a problem with swsuspend and GPE events. Now they are restored from acpi_pm_finish(), which is called only if we suspend with "platform" option, what means that if we suspended to disk with the default "shutdown" option after resume all the GPEs will be disabled. This presents us with the overheating problem after resume at very least. I see two solutions: one is to make "platform" to be default option if ACPI is enabled, and second -- enable GPE events from some other function, which will be called in any case. What do you think? 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
[PATCH] make ibm_acpi work right with notify handlers.
Hi, There is a bug in ibm_acpi module, which prevents its clean removal. This patch fixes the problem by moving setting notify_installed to the right place. Thanks, Alex. make unload of ibm_acpi right. From: Alexey Starikovskiy <[EMAIL PROTECTED]> --- drivers/acpi/ibm_acpi.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c index 003a987..719a320 100644 --- a/drivers/acpi/ibm_acpi.c +++ b/drivers/acpi/ibm_acpi.c @@ -1805,7 +1805,7 @@ static int __init setup_notify(struct ib ibm->name, status); return -ENODEV; } - + ibm->notify_installed = 1; return 0; } @@ -1882,7 +1882,6 @@ static int __init ibm_init(struct ibm_st ret = setup_notify(ibm); if (ret < 0) return ret; - ibm->notify_installed = 1; } return 0;
Re: [patch 0/2] acpi: driverregistration again can report ENODEV
On Wed, 2006-10-25 at 18:40 +0800, Zhang Rui wrote: > We won't have such issues if we make ACPI use driver model. > I've sent out a patch series which throw the legacy ACPI driver model > away. The patches will be added to -mm tree. > > On Sat, 2006-10-21 at 00:55 +0800, Bjorn Helgaas wrote: > > > acpi_bus_register_driver must return -ENODEV when no device with > > > matching HID was found. E.g. battery also should currently get > > always > > > loaded even a system never has one. > > > > If the driver wants to unload if it doesn't find any devices, > > it can easily do so by counting calls to its add() method, as > > asus_acpi.c currently does. I don't think that's a good long- > > term solution, though. I think it would be better to have a > > hotplug scheme that loads the driver when the hardware is > > found, like we do for PCI. > > > that's true. With this patch series, .uevent method of ACPI bus will be > called when an ACPI device is found. Then udev script loads the right > driver by checking hid/cid offered by .uevent method. That are great news. Maybe you can CC linux-acpi list on further patches, I didn't know about this. I am looking forward to give these a try as soon as I get some time... Thanks, 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
Re: [patch 0/2] acpi: driverregistration again can report ENODEV
We won't have such issues if we make ACPI use driver model. I've sent out a patch series which throw the legacy ACPI driver model away. The patches will be added to -mm tree. On Sat, 2006-10-21 at 00:55 +0800, Bjorn Helgaas wrote: > > acpi_bus_register_driver must return -ENODEV when no device with > > matching HID was found. E.g. battery also should currently get > always > > loaded even a system never has one. > > If the driver wants to unload if it doesn't find any devices, > it can easily do so by counting calls to its add() method, as > asus_acpi.c currently does. I don't think that's a good long- > term solution, though. I think it would be better to have a > hotplug scheme that loads the driver when the hardware is > found, like we do for PCI. > that's true. With this patch series, .uevent method of ACPI bus will be called when an ACPI device is found. Then udev script loads the right driver by checking hid/cid offered by .uevent method. thanks, Rui - 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.19-rc2: known unfixed regressions (v3)
Quoting r. Pavel Machek <[EMAIL PROTECTED]>: > > > > > > Subject: T60 stops triggering any ACPI events > > > References : http://lkml.org/lkml/2006/10/4/425 > > > http://lkml.org/lkml/2006/10/16/262 > > > Submitter : "Michael S. Tsirkin" <[EMAIL PROTECTED]> > > > Status : unknown > > > > Just retested with 2.6.19-rc3 - it's still there: > > e.g. after I do a full kernel compile, my T60 stops triggering any ACPI > > events: > > tail -f /var/log/acpid does not show anything, even on Fn/F4 which is > > supposed > > to be always enabled. Restarting the acpid doesn't do anything either - > > ACPI > > starts working again, for a while, only after reboot. > > > > Works fine in 2.6.18 ( + this patch http://lkml.org/lkml/2006/7/20/56). > > Bugzilla.kernel.org, assign it to acpi people... Already done, http://bugzilla.kernel.org/show_bug.cgi?id=7408 -- MST - 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.19-rc2: known unfixed regressions (v3)
On Tue 2006-10-24 17:00:51, Michael S. Tsirkin wrote: > Quoting r. Adrian Bunk <[EMAIL PROTECTED]>: > > Subject: 2.6.19-rc2: known unfixed regressions (v3) > > > > This email lists some known unfixed regressions in 2.6.19-rc2 compared > > to 2.6.18 that are not yet fixed Linus' tree. > > > > If you find your name in the Cc header, you are either submitter of one > > of the bugs, maintainer of an affectected subsystem or driver, a patch > > of you caused a breakage or I'm considering you in any other way possibly > > involved with one or more of these issues. > > > > Due to the huge amount of recipients, please trim the Cc when answering. > > > > skip, hope I didn't trim too much. > > > > > Subject: T60 stops triggering any ACPI events > > References : http://lkml.org/lkml/2006/10/4/425 > > http://lkml.org/lkml/2006/10/16/262 > > Submitter : "Michael S. Tsirkin" <[EMAIL PROTECTED]> > > Status : unknown > > Just retested with 2.6.19-rc3 - it's still there: > e.g. after I do a full kernel compile, my T60 stops triggering any ACPI > events: > tail -f /var/log/acpid does not show anything, even on Fn/F4 which is supposed > to be always enabled. Restarting the acpid doesn't do anything either - ACPI > starts working again, for a while, only after reboot. > > Works fine in 2.6.18 ( + this patch http://lkml.org/lkml/2006/7/20/56). Bugzilla.kernel.org, assign it to acpi people... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.18-mm2] acpi: add backlight support to the sony_acpi driver
Hi! > > > a generic ACPI driver that exports the _BCL and _BCM method > > > implementations via that same interface, so that systems providing > > > that will "just work". drivers/acpi/video.c currently exports this > > > via /proc/acpi/video/$DEVICE/brightness, which isn't the same as > > > /sys/class/backlight. :-( > > > > Yes, I'm working on acpi video driver transition , and have posted a patch > > to user backlight for acpi video driver. > > http://marc.theaimsgroup.com/?l=linux-acpi&m=115574087203605&w=2 > > Just updated the backlight and output sysfs support for ACPI Video driver on > bugzilla. If you are interested this, please take a look at > http://bugzilla.kernel.org/show_bug.cgi?id=5749#c18 > [patch 1/3] vidoe sysfs support: Add dev argument for baclight sys dev Two typos in one line :-). > [patch 2/3] Add display output class support I guess this needs Documentation/ so we can tell if user<->kernel interface is sane.. > [patch 3/3] backlight and output sysfs support for acpi video driver Some whitespace is not okay there... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
