Hi!
Here's lid support for ACPI, please apply.
Pavel
--- clean/drivers/acpi/power.c Wed Jan 31 16:14:33 2001
+++ linux/drivers/acpi/power.c Sun Apr 22 23:02:25 2001
@@ -30,11 +30,11 @@
int acpi_cmbatt_init(void);
int acpi_cmbatt_terminate(void);
-/* ACPI-specific defines */
-#define ACPI_AC_ADAPTER_HID "ACPI0003"
-
static int ac_count = 0;
+static int lid_count = 0;
static ACPI_HANDLE ac_handle = 0;
+static ACPI_HANDLE lid_handle = 0;
+
/*
* We found a device with the correct HID
@@ -60,11 +60,28 @@
}
printk(KERN_INFO "AC Adapter: found\n");
-
ac_handle = handle;
-
ac_count++;
+ return AE_OK;
+}
+static ACPI_STATUS
+acpi_found_lid(ACPI_HANDLE handle, u32 level, void *ctx, void **value)
+{
+ ACPI_DEVICE_INFO info;
+
+ if (lid_count > 0) {
+ printk(KERN_ERR "Lid: more than one!\n");
+ return (AE_OK);
+ }
+
+ if (!(info.valid & ACPI_VALID_STA)) {
+ printk(KERN_ERR "Lid: _STA invalid\n");
+ }
+
+ printk(KERN_INFO "Lid: found\n");
+ lid_handle = handle;
+ lid_count++;
return AE_OK;
}
@@ -101,23 +118,54 @@
return len;
}
+static int
+proc_read_lid_status(char *page, char **start, off_t off,
+ int count, int *eof, void *data)
+{
+ ACPI_OBJECT obj;
+ ACPI_BUFFER buf;
+
+ char *p = page;
+ int len;
+
+ buf.length = sizeof(obj);
+ buf.pointer = &obj;
+ if (!ACPI_SUCCESS(acpi_evaluate_object(lid_handle, "_LID", NULL, &buf))
+ || obj.type != ACPI_TYPE_INTEGER) {
+ p += sprintf(p, "Could not read lid status\n");
+ goto end;
+ }
+
+ if (obj.integer.value)
+ p += sprintf(p, "open\n");
+ else
+ p += sprintf(p, "closed\n");
+
+end:
+ len = (p - page);
+ if (len <= off+count) *eof = 1;
+ *start = page + off;
+ len -= off;
+ if (len>count) len = count;
+ if (len<0) len = 0;
+ return len;
+}
+
int
acpi_power_init(void)
{
- acpi_get_devices(ACPI_AC_ADAPTER_HID,
- acpi_found_ac_adapter,
- NULL,
- NULL);
+ acpi_get_devices("ACPI0003", acpi_found_ac_adapter, NULL, NULL);
+ acpi_get_devices("PNP0C0D", acpi_found_lid, NULL, NULL);
if (!proc_mkdir("power", NULL))
- return 0;
+ return -EBUSY;
- if (ac_handle) {
- create_proc_read_entry("power/ac", 0, NULL,
- proc_read_ac_adapter_status, NULL);
- }
+ if (ac_handle)
+ create_proc_read_entry("power/ac", 0, NULL, proc_read_ac_adapter_status, NULL);
+ if (lid_handle)
+ create_proc_read_entry("power/lid", 0, NULL, proc_read_lid_status, NULL);
acpi_cmbatt_init();
return 0;
}
@@ -127,9 +176,8 @@
{
acpi_cmbatt_terminate();
- if (ac_handle) {
- remove_proc_entry("power/ac", NULL);
- }
+ if (ac_handle) remove_proc_entry("power/ac", NULL);
+ if (lid_handle) remove_proc_entry("power/lid", NULL);
remove_proc_entry("power", NULL);
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Pavel,
We already have lid support in the latest ACPI versions (not in the official
kernel yet.) You can download this code from
http://developer.intel.com/technology/iapc/acpi/downloads.htm .
It'd be great if you could focus your testing and patches on this code base
-- I think it's a lot better but it's still a work in progress.
Regards -- Andy
PS I'm not quite sure why you copied the acpi list *and* lkml.. ;-)
> -----Original Message-----
> From: Pavel Machek [mailto:[email protected]]
> Hi!
>
> Here's lid support for ACPI, please apply.
>
Hi!
> We already have lid support in the latest ACPI versions (not in the official
> kernel yet.) You can download this code from
> http://developer.intel.com/technology/iapc/acpi/downloads.htm .
This site is as ugly as hell but does the trick. (And btw link to
"kernel howto" points to list of howtos [after really ugly
disclaimer], not to kernel howto directly; and size of patch with
"debug version" on page is wrong).
> It'd be great if you could focus your testing and patches on this code base
> -- I think it's a lot better but it's still a work in progress.
Are you planning to merge to 2.4.4?
> PS I'm not quite sure why you copied the acpi list *and* lkml.. ;-)
Is acpi list some kind of lkml subset? [I wanted people to know that
I'm playing with acpi. I probably should stop mailing to acpi list
that I do not read...]
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
> > It'd be great if you could focus your testing and patches
> on this code base
> > -- I think it's a lot better but it's still a work in progress.
>
> Are you planning to merge to 2.4.4?
Planning on merging ASAP. That may be 2.4.4, we'll see.
> > PS I'm not quite sure why you copied the acpi list *and* lkml.. ;-)
>
> Is acpi list some kind of lkml subset? [I wanted people to know that
> I'm playing with acpi. I probably should stop mailing to acpi list
> that I do not read...]
We have a dedicated list for ACPI so you should subscribe to it and use it.
Regards -- Andy
Hi!
> We already have lid support in the latest ACPI versions (not in the official
> kernel yet.) You can download this code from
> http://developer.intel.com/technology/iapc/acpi/downloads.htm .
>
> It'd be great if you could focus your testing and patches on this code base
> -- I think it's a lot better but it's still a work in progress.
I was just browsing its sources:
+ if (tz->policy.temperature >=
+ tz->policy.critical.threshold->temperature) {
+ DEBUG_PRINT(ACPI_WARN, ("Critical threshold reached - shutting down system.\n"));
+ /* TODO: 'halt' */
+ }
Are you sure that kill(init, SIGTERM) is not right answer here?
Pavel
PS: This seems very strange. What if machine is so crashed so that it
can no longer shutdown properly. Will that mean that its CPU will
damage itself?
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Hi!
> >PS: This seems very strange. What if machine is so crashed so that it
> >can no longer shutdown properly. Will that mean that its CPU will
> >damage itself?
>
> No, the ACPI standard requires CPUs to shut themselves down before
> any damage would occur from overheading. Well, at least the 1.0b
> version of the standard did; I haven't read 2.0 yet.
BTW shut themselves down to halt, or shut themselves to *very* low speed?
Slow down to 10% speed is what my toshiba does. Is there way back from such
mode?
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
(btw ACPI 2.0 spec section 12.1.1 discusses this)
> From: Pavel Machek [mailto:[email protected]]
> > No, the ACPI standard requires CPUs to shut themselves down before
> > any damage would occur from overheading. Well, at least the 1.0b
> > version of the standard did; I haven't read 2.0 yet.
> BTW shut themselves down to halt, or shut themselves to
> *very* low speed?
Both. When a CPU overheats, the OS implements either active (turning on a
fan) or passive (cpu throttling). If the temperature still exceeds the
critical threshold, the OS must shut down.
> Slow down to 10% speed is what my toshiba does. Is there way
> back from such
> mode?
Once the temperature drops below the active and passive cooling thresholds,
the OS should stop its cooling measures, such as throttling.
That said, I seem to recall your laptop is doing throttling in a non-OS
visible way (BIOS) so I don't know under what circumstances it stops cpu
throttling.
Regards -- Andy
>PS: This seems very strange. What if machine is so crashed so that it
>can no longer shutdown properly. Will that mean that its CPU will
>damage itself?
No, the ACPI standard requires CPUs to shut themselves down before
any damage would occur from overheading. Well, at least the 1.0b
version of the standard did; I haven't read 2.0 yet.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/