Bug#452909: [PATCH] Support PMU Suspend Detection

2008-02-06 Thread Tim Dijkstra
On Sat, 02 Feb 2008 04:12:07 +0100
Michael Biebl [EMAIL PROTECTED] wrote:

 first of all, thanks for your efforts.
 The original intent of Tim Dykstra, who removed pm-pmu from the Debian 
 pm-utils package, was, that the functionality of pm-pmu is already 
 existent in s2ram (from the uswsusp package). Dropping pm-pmu from 
 pm-utils also made pm-utils an architecture:all package, which means, it 
 only contains shell scripts. This has the advantage, that pm-utils 
 doesn't have to be compiled for all the different architectures.

Adding some background to this... I did this also because I think the
different interface to suspend the machine on powerpc is a kernel bug.
Fixes for bugs/quirks are in the s2ram binary, hence that seemed to be
the right place for this one too. Also, when I decided this, there was 
a kernel-patch (by Johannes Berg IIRC) with a fix for this behavior. At
that time I got the impression that it was about to be accepted
upstream. That strengthened my believe that pm-pmu shouldn't be in
pm-utils.
It appears the patch still isn't applied, I still think however that
the current setup in debian is correct and the way to go. (If we manage
to get a one line fix in one of pm-utils scripts.)

grts Tim


signature.asc
Description: PGP signature


Bug#452909: [PATCH] Support PMU Suspend Detection

2008-02-06 Thread Matthew William Cox
On Wed, Feb 06, 2008 at 10:29:23PM +0100, Tim Dijkstra wrote:
 Adding some background to this... I did this also because I think the
 different interface to suspend the machine on powerpc is a kernel bug.

Agreed. Seems like there's no valid reason the /sys/power/state node
can't notify the PMU driver to suspend instead of the ACPI subsystem.

 Fixes for bugs/quirks are in the s2ram binary, hence that seemed to be
 the right place for this one too. Also, when I decided this, there was 
 a kernel-patch (by Johannes Berg IIRC) with a fix for this behavior. At
 that time I got the impression that it was about to be accepted
 upstream. That strengthened my believe that pm-pmu shouldn't be in
 pm-utils.
 It appears the patch still isn't applied, I still think however that
 the current setup in debian is correct and the way to go. (If we manage
 to get a one line fix in one of pm-utils scripts.)

I think that you mean this patch?

http://thread.gmane.org/gmane.linux.power-management.general/8651

Maybe we should punt this bug over to the kernel, and have the patch
applied to the debian sources?

In the mean time, I'll try installing s2ram.

Thanks for your interest.
Matthew


signature.asc
Description: Digital signature


Bug#452909: [PATCH] Support PMU Suspend Detection

2008-02-01 Thread Matthew William Cox
On Sat, Feb 02, 2008 at 12:49:38AM +0100, Michael Biebl wrote:
 That's not quite correct. Upstream is also broken, as pm-is-supported  
 doesn't recognize pmu support.

In the interests of getting this fixed, I dug into pm-pmu.c and added
the ability to query the PMU to detect if suspending is supported. I've
tested it by manually building pm-pmu and checking the suspend and
can-suspend functions:

 if sudo ./pm-pmu --can-suspend; then sudo ./pm-pmu --suspend; fi

This successfully suspends my Powerbook G4. I've tested it against
linux-image-2.6.22-3-powerpc, and against linux-image-2.6.24-1-powerpc.

Hopefully we can integrate this into pm-utils, and get this bug resolved.
My debian-fu isn't developed enough to understand how to dig into this
package fix the rest of it, but I am interested in doing the work. I'll
have to go read up on the debian packaging utilities before I continue.
In the mean time, if somebody else can use my patch to zap this bug,
please do.

Cheers,
Matthew
diff -ur pm-utils-0.99.2-orig/src/pm-pmu.c pm-utils-0.99.2/src/pm-pmu.c
--- pm-utils-0.99.2-orig/src/pm-pmu.c	2006-08-08 11:17:28.0 -0400
+++ pm-utils-0.99.2/src/pm-pmu.c	2008-02-01 21:12:07.0 -0500
@@ -53,10 +53,20 @@
 return 0;
 }
 
+static int
+pmu_can_sleep(const int fd)
+{
+unsigned long cap = 0;
+if (ioctl(fd, PMU_IOC_CAN_SLEEP, cap)  0 || cap != 1)
+return 1;
+
+return 0;
+}
+
 static inline int
 print_usage(FILE *output, int retval)
 {
-fprintf(output, usage: pm-pmu --suspend\n);
+fprintf(output, usage: pm-pmu [--suspend | --can-suspend]\n);
 return retval;
 }
 
@@ -80,6 +90,17 @@
 ret = pmu_sleep(fd);
 close(fd);
 return ret;
+} else if (!strcmp(argv[1], --can-suspend)) {
+int fd, ret;
+/* Need RDRW perm on pmu to issue PMU_IOC_CAN_SLEEP */
+if ((fd = open (/dev/pmu, O_RDWR))  0) {
+perror(open);
+return 1;
+}
+
+ret = pmu_can_sleep(fd);
+close(fd);
+return ret;
 }
 
 return print_usage(stderr, 1);


signature.asc
Description: Digital signature


Bug#452909: [PATCH] Support PMU Suspend Detection

2008-02-01 Thread Michael Biebl

Matthew William Cox wrote:

On Sat, Feb 02, 2008 at 12:49:38AM +0100, Michael Biebl wrote:
That's not quite correct. Upstream is also broken, as pm-is-supported  
doesn't recognize pmu support.


In the interests of getting this fixed, I dug into pm-pmu.c and added
the ability to query the PMU to detect if suspending is supported. I've
tested it by manually building pm-pmu and checking the suspend and
can-suspend functions:


if sudo ./pm-pmu --can-suspend; then sudo ./pm-pmu --suspend; fi


This successfully suspends my Powerbook G4. I've tested it against
linux-image-2.6.22-3-powerpc, and against linux-image-2.6.24-1-powerpc.

Hopefully we can integrate this into pm-utils, and get this bug resolved.
My debian-fu isn't developed enough to understand how to dig into this
package fix the rest of it, but I am interested in doing the work. I'll
have to go read up on the debian packaging utilities before I continue.
In the mean time, if somebody else can use my patch to zap this bug,
please do.


Hi Matthew,

first of all, thanks for your efforts.
The original intent of Tim Dykstra, who removed pm-pmu from the Debian 
pm-utils package, was, that the functionality of pm-pmu is already 
existent in s2ram (from the uswsusp package). Dropping pm-pmu from 
pm-utils also made pm-utils an architecture:all package, which means, it 
only contains shell scripts. This has the advantage, that pm-utils 
doesn't have to be compiled for all the different architectures.


I'll have to discuss with Tim, if we are going to put pm-pmu back into 
pm-utils or rely on s2ram solely.


There are also some issues left, which require investigation.
E.g. /usr/bin/pm-is-supported currently has a check
[ -f /sys/power/state ] || exit 1
and /sys/power/state afaik isn't (necessarily) existent on pmu machines.
Also the suspend) section has to be augmented to support pmu machines.
Either we should use pm-pmu --can-suspend there or s2ram --test (or 
support both: first try s2ram and fall back to pm-pmu)


We probably also have to remove the
[ -f /sys/power/state ] || exit 1
check in /usr/lib/pm-utils/bin/pm-action

And finally, if we put back pm-pmu, do_suspend() in 
/usr/lib/pm-utils/functions should also be updated to properly support 
pmu machines.


cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature