Re: suspend-to-disk
On Mon, 2007-07-09 at 01:06 -0400, C. Scott Ananian wrote: The existing linux suspend-to-disk does this: pages that are disk-backed are not duplicated, and dirty pages are written out rather than saved dirty. There is a time penalty for doing this. Suspend2 has support for page compression as well (http://www.tuxonice.net/) and seems to be fairly mature and under active development, although I've only used the stock kernel STD myself. I know it's a minor detail, but in userspace there's a convention of calling suspend-to-disk hibernation and suspend-to-ram suspend - most people now are using the new names. Please see http://cvs.gnome.org/viewcvs/*checkout*/gnome-power-manager/docs/sleep-names.html and http://live.gnome.org/GnomePowerManager/SleepNames I would really like the OLPC userspace to stick to this nomenclature, even if it's just in the UI. Thanks! Richard. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: add powerbutton and lid platform devices
On 08/07/07 18:10 -0400, Marcelo Tosatti wrote:
Jordan,
This allows configuration of powerbutton/lid events... Are the
gpio_gpio_{clear,set} calls correct for enabling/disabling LID
events?
What else do we want to support?
The obvious ones would be RTC (but you already covered that), and SCI.
But this is an excellent start.
--- olpc-pm.c.orig2007-07-08 17:09:07.0 -0400
+++ olpc-pm.c 2007-07-08 18:07:03.0 -0400
@@ -54,6 +54,18 @@
static int gpio_wake_events = 0;
static int ebook_state = -1;
+static u16 olpc_wakeup_mask = 0;
+
+struct platform_device olpc_powerbutton_dev = {
+ .name = powerbutton,
+ .id = 0,
+};
+
+struct platform_device olpc_lid_dev = {
+ .name = lid,
+ .id = 0,
+};
+
static void __init init_ebook_state(void)
{
@@ -250,6 +262,16 @@
/* Save the MFGPT MSRs */
rdmsrl(MFGPT_IRQ_MSR, mfgpt_irq_msr);
rdmsrl(MFGPT_NR_MSR, mfgpt_nr_msr);
+
+ if (device_may_wakeup(olpc_powerbutton_dev.dev))
+ olpc_wakeup_mask |= CS5536_PM_PWRBTN;
+ else
+ olpc_wakeup_mask = ~(CS5536_PM_PWRBTN);
+
+ if (device_may_wakeup(olpc_lid_dev.dev))
+ geode_gpio_clear(OLPC_GPIO_LID, GPIO_EVENTS_ENABLE);
+ else
+ geode_gpio_set(OLPC_GPIO_LID, GPIO_EVENTS_ENABLE);
}
As was already mentioned before, the clear and set clauses should be
reversed.
You'll also need to get rid of
outl(1 31, acpi_base + PM_GPE0_EN);
in olpc_pm_enter() since that would have the undesired effect of eliminating
the LID completely from the list of wakeup sources. We should leave the
value of GPE0_EN the same through the lifetime of the system,
and control the individual events through the event enable bit(s) as you
have done above.
static int olpc_pm_enter(suspend_state_t pm_state)
@@ -275,8 +297,6 @@
return 0;
}
-static u16 olpc_wakeup_mask = CS5536_PM_PWRBTN;
-
int asmlinkage olpc_do_sleep(u8 sleep_state)
{
void *pgd_addr = __va(read_cr3());
@@ -596,15 +616,20 @@
.resource = rtc_platform_resource,
};
-static int __init olpc_rtc_init(void)
+static int __init olpc_platform_init(void)
{
(void)platform_device_register(olpc_rtc_device);
-
device_init_wakeup(olpc_rtc_device.dev, 1);
+ (void)platform_device_register(olpc_powerbutton_dev);
+ device_init_wakeup(olpc_powerbutton_dev.dev, 1);
+
+ (void)platform_device_register(olpc_lid_dev);
+ device_init_wakeup(olpc_lid_dev.dev, 1);
+
return 0;
}
I agree that the default setting for the power button should be to
wake up, but I don't know about the lid. Imagine a scenario where somebody
manually puts the machine to sleep and then shuts the lid. You wouldn't want
the machine to turn back on when you lifted it. Lid behavior is so policy
driven, I think we should leave it off by default, and let the power manager
decide what to do.
-arch_initcall(olpc_rtc_init);
+arch_initcall(olpc_platform_init);
#endif /* CONFIG_RTC_DRV_CMOS */
static void olpc_pm_exit(void)
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
On 7/9/07, Mitch Bradley [EMAIL PROTECTED] wrote: I looked at those git trees and didn't see the python runtime stuff in the initramfs tree. How does it get included, and how big is it? Packages in initramfs are specified by: http://dev.laptop.org/git?p=users/cscott/d-i;a=blob;f=build/pkg-lists/olpc/common;hb=HEAD python2.5-minimal is about 2MB of the 3MB compressed initramfs. The python2.5 binary is 1.4M (compressed) of that; it's likely that I could trim this down a bit more -- I notice that the python2.5 binary is unstripped, and stripping yields 470k compressed -- but I'm reluctant to minimize stuff until Ivan's written his activation code and we know roughly what packages we'll be wanting. For instance, there are a lot of different encodings represented in /usr/lib/python2.5/encodings which I've left because I don't know at this point if activation will require a localized UI. For comparison, the existing traditional 'mayflower' initrd created used for emulation is 2.3MB. So at the instant we're paying about 700k for the privilege of writing our activation code in python, but this number is pretty bogus. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
C. Scott Ananian wrote: On 7/9/07, Mitch Bradley [EMAIL PROTECTED] wrote: I looked at those git trees and didn't see the python runtime stuff in the initramfs tree. How does it get included, and how big is it? Packages in initramfs are specified by: http://dev.laptop.org/git?p=users/cscott/d-i;a=blob;f=build/pkg-lists/olpc/common;hb=HEAD python2.5-minimal is about 2MB of the 3MB compressed initramfs. The python2.5 binary is 1.4M (compressed) of that; it's likely that I could trim this down a bit more -- I notice that the python2.5 binary is unstripped, and stripping yields 470k compressed -- but I'm reluctant to minimize stuff until Ivan's written his activation code and we know roughly what packages we'll be wanting. For instance, there are a lot of different encodings represented in /usr/lib/python2.5/encodings which I've left because I don't know at this point if activation will require a localized UI. For comparison, the existing traditional 'mayflower' initrd created used for emulation is 2.3MB. So at the instant we're paying about 700k for the privilege of writing our activation code in python, but this number is pretty bogus. At that 3M size, I'm beginning to have second thoughts about the one initrd for both activation and normal booting idea. A busybox (statically linked with uclibc) with enough trimmings to do darn near anything compresses to about 0.6 MB. The fact that the kernel can currently boot with no initrd at all makes it hard for me to swallow the proposition of tripling the load image size in the usual case. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
C. Scott Ananian wrote: On 7/9/07, Mitch Bradley [EMAIL PROTECTED] wrote: At that 3M size, I'm beginning to have second thoughts about the one initrd for both activation and normal booting idea. A busybox (statically linked with uclibc) with enough trimmings to do darn near anything compresses to about 0.6 MB. The fact that the kernel can currently boot with no initrd at all makes it hard for me to swallow the proposition of tripling the load image size in the usual case. I'll look into how small I can make it tomorrow. If we've got to have the initrd for activation, we might as well do normal boot with it, since the time spent decompressing is still minimal for the sizes we're talking about. I can try to quantify that claim once I get my B4. ;-) --scott Decompression is fast, but the signature verification is not so fast, especially since there are several different algorithms. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
