ARM suspend to disk?
Subsystems (5)
Hey there,
I last posted a few weeks ago; I'm Peter Tseng, using the Gumstix Overo for a project. I'm interested in power management and a few related things. A few of the things I am interested in are suspend to disk and snapshot boot.
I found a page on elinux.org with a few notes on the issue for ARM. However, it looks to be a bit outdated:
http://elinux.org/Suspend_To_Disk_For_ARM
I am wondering how applicable anything on this page is to the current omap-pm developments. Or, if not, any pointers on how it might be done - for example, if I felt like I should do some hacking to try to get this working and contribute these back, a general outline of what I might have to do)
Thanks for your time,
Peter Tseng
Quoted 9 lines · Peter Tseng
I last posted a few weeks ago; I'm Peter Tseng, using the Gumstix Overo for a project. I'm interested in power management and a few related things. A few of the things I am interested in are suspend to disk and snapshot boot.
I found a page on elinux.org with a few notes on the issue for ARM. However, it looks to be a bit outdated:
http://elinux.org/Suspend_To_Disk_For_ARM
Quoted 5 lines
I am wondering how applicable anything on this page is to the current omap-pm developments. Or, if not, any pointers on how it might be done - for example, if I felt like I should do some hacking to try to get this working and contribute these back, a general outline of what I might have to do)
Not really and answer to your question since I don't know the answer, but just curious about your goals, since there may be an easier way.
What do you expect to gain from suspend-to-disk + snapshot boot that you don't already get from suspend-to-RAM using off-mode?
On OMAP, with off-mode enabled, a suspend to RAM puts the entire OMAP into full-chip off, and essentially reboots the ARM when waking up from suspend (or idle) already.
Kevin
Quoted 6 lines · Kevin Hilman
What do you expect to gain from suspend-to-disk + snapshot boot that you don't already get from suspend-to-RAM using off-mode?
On OMAP, with off-mode enabled, a suspend to RAM puts the entire OMAP into full-chip off, and essentially reboots the ARM when waking up from suspend (or idle) already.
What does the resume process look like in off mode? Does the resume pass through the bootloader? If so, are the bits that detects resume from "off" available in U-boot?
Thanks,
Cliff
Quoted 6 lines · Cliff Brake
Quoted 3 lines · Kevin Hilman
What do you expect to gain from suspend-to-disk + snapshot boot that you don't already get from suspend-to-RAM using off-mode?
Quoted 7 lines
Quoted 3 lines
On OMAP, with off-mode enabled, a suspend to RAM puts the entire OMAP into full-chip off, and essentially reboots the ARM when waking up from suspend (or idle) already.
What does the resume process look like in off mode? Does the resume pass through the bootloader? If so, are the bits that detects resume from "off" available in U-boot?
No, it does not pass through the boot loader.
In general terms, resume from off-mode is the same to "normal" resume (from retention) except that some additional state has to be restored before continuing where you left off since the ARM core (as well as most the OMAP itself) was turned off.
Kevin
Quoted 24 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Kevin Hilman
Sent: Saturday, May 01, 2010 3:36 AM
To: Cliff Brake
Cc: Peter Tseng; [email protected]
Subject: Re: ARM suspend to disk?Quoted 6 lines · Cliff Brake
Quoted 3 lines · Kevin Hilman
What do you expect to gain from suspend-to-disk + snapshot boot that you don't already get from suspend-to-RAM using off-mode?
Quoted 7 lines
Quoted 3 lines
On OMAP, with off-mode enabled, a suspend to RAM puts the entire OMAP into full-chip off, and essentially reboots the ARM when waking up from suspend (or idle) already.
What does the resume process look like in off mode? Does the resume pass through the bootloader? If so, are the bits that detects resume from "off" available in U-boot?
Quoted 7 lines
No, it does not pass through the boot loader.
In general terms, resume from off-mode is the same to "normal" resume (from retention) except that some additional state has to be restored before continuing where you left off since the ARM core (as well as most the OMAP itself) was turned off.
On suspend to disk topic, Raghu under Romit's guidance did a prototype few months back as part of his internship using some of the earlier ARM work. The whole system snapshot was stored to the MMC card and one can take that MMC card on another board and continue from where it was suspended.
We should have these patches somewhere.
Regards,
Santosh
Quoted 20 lines · Kevin Hilman
Quoted 9 lines · Peter Tseng
I last posted a few weeks ago; I'm Peter Tseng, using the Gumstix Overo for a project. I'm interested in power management and a few related things. A few of the things I am interested in are suspend to disk and snapshot boot.
I found a page on elinux.org with a few notes on the issue for ARM. However, it looks to be a bit outdated:
http://elinux.org/Suspend_To_Disk_For_ARMQuoted 5 lines
I am wondering how applicable anything on this page is to the current omap-pm developments. Or, if not, any pointers on how it might be done - for example, if I felt like I should do some hacking to try to get this working and contribute these back, a general outline of what I might have to do)
Not really and answer to your question since I don't know the answer, but just curious about your goals, since there may be an easier way.
Quoted 7 lines
What do you expect to gain from suspend-to-disk + snapshot boot that you don't already get from suspend-to-RAM using off-mode?
On OMAP, with off-mode enabled, a suspend to RAM puts the entire OMAP into full-chip off, and essentially reboots the ARM when waking up from suspend (or idle) already.
My goals: I am researching very low power devices - the ideal final goal is to make devices such as e-book readers that can last for several months (with regular use) on a single battery charge.
The power management capabilities of the OMAP have been helpful, but it does appear (unless I am doing something wrong?) that even with off-mode enabled, a suspend to RAM does still draw a few milliwatts of power. Granted, this isn't much, but when we multiply that over several months, it does add up. So I'd like to know if there's a way to reach zero, hence my earlier questions.
Peter
Quoted 31 lines · Santosh
Quoted 24 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Kevin Hilman
Sent: Saturday, May 01, 2010 3:36 AM
To: Cliff Brake
Cc: Peter Tseng; [email protected]
Subject: Re: ARM suspend to disk?Quoted 6 lines · Cliff Brake
Quoted 3 lines · Kevin Hilman
What do you expect to gain from suspend-to-disk + snapshot boot that you don't already get from suspend-to-RAM using off-mode?
Quoted 7 lines
Quoted 3 lines
On OMAP, with off-mode enabled, a suspend to RAM puts the entire OMAP into full-chip off, and essentially reboots the ARM when waking up from suspend (or idle) already.
What does the resume process look like in off mode? Does the resume pass through the bootloader? If so, are the bits that detects resume from "off" available in U-boot?
Quoted 7 lines
No, it does not pass through the boot loader.
In general terms, resume from off-mode is the same to "normal" resume (from retention) except that some additional state has to be restored before continuing where you left off since the ARM core (as well as most the OMAP itself) was turned off.
Quoted 7 lines
On suspend to disk topic, Raghu under Romit's guidance did a prototype few months back as part of his internship using some of the earlier ARM work. The whole system snapshot was stored to the MMC card and one can take that MMC card on another board and continue from where it was suspended.
We should have these patches somewhere.
It would be interesting to see these. Are you able to find these patches somewhere?
Peter
Please find the patch which Romit and Raghu had worked on. Hope it helps.
Regards
Teerth
arch/arm/kernel/vmlinux.lds.S 2009-06-30 11:05:16.000000000 +0530 renamed from arch/arm/kernel/vmlinux.lds.S 2009-06-30 14:29:09.000000000 +0530 +7 -6
@@ -87,6 +87,7 @@ SECTIONS } .text : { /* Real text segment */ + _kern_text_start = .; _text = .; /* Text and read-only data */ __exception_text_start = .; *(.exception.text)
@@ -108,6 +109,7 @@ SECTIONS RODATA _etext = .; /* End of text and rodata section */ + _kern_text_end = .; #ifdef CONFIG_XIP_KERNEL __data_loc = ALIGN(4); /* location in binary */
@@ -134,12 +136,6 @@ SECTIONS __init_end = .; #endif - . = ALIGN(4096); - __nosave_begin = .; - *(.data.nosave) - . = ALIGN(4096); - __nosave_end = .; - /* * then the cacheline aligned data */
@@ -165,6 +161,11 @@ SECTIONS _edata = .; } _edata_loc = __data_loc + SIZEOF(.data); + . = ALIGN(4096); + __nosave_begin = .; + .data.nosave : { *(.data.nosave) } + . = ALIGN(4096); + __nosave_end = .; .bss : { __bss_start = .; /* BSS */
arch/arm/Makefile 2009-06-30 11:05:16.000000000 +0530 renamed from arch/arm/Makefile 2009-06-30 14:29:09.000000000 +0530 +1 -0
@@ -198,6 +198,7 @@ core-$(CONFIG_ARCH_MXC) += arch/arm/pla drivers-$(CONFIG_OPROFILE) += arch/arm/oprofile/ drivers-$(CONFIG_ARCH_CLPS7500) += drivers/acorn/char/ drivers-$(CONFIG_ARCH_L7200) += drivers/acorn/char/ +drivers-$(CONFIG_HIBERNATION) += arch/arm/power/ libs-y := arch/arm/lib/ $(libs-y)
arch/arm/mm/init.c 2009-06-30 11:05:16.000000000 +0530 renamed from arch/arm/mm/init.c 2009-06-30 14:29:09.000000000 +0530 +19 -0
@@ -354,6 +354,25 @@ static inline void free_area(unsigned lo printk(KERN_INFO "Freeing %s memory: %dK\n", s, size); } +#if defined(CONFIG_HIBERNATION) + +/* + * Swap suspend & friends need this for resume. + */ + +/* pgd_t is unsigned long [2], so 2 * 4 (byte/word) */ + +char __nosavedata swsusp_pg_dir[PTRS_PER_PGD * 2 * 4] +/* Translation Table Base must be on 16KB boundary. */ +__attribute__ ((aligned (1UL << 14))); + +void swsusp_save_pg_dir(void) +{ + memcpy(swsusp_pg_dir, swapper_pg_dir, PTRS_PER_PGD * 2 * 4); +} +#endif + + static inline void free_memmap(int node, unsigned long start_pfn, unsigned long end_pfn) {
arch/arm/power/cpu.c 2009-07-06 15:45:30.000000000 +0530 renamed from arch/arm/power/cpu.c 1970-01-01 05:30:00.000000000 +0530 +157 -0
157 lines not on this page · raw message
arch/arm/power/Makefile 2009-06-29 15:35:58.000000000 +0530 renamed from arch/arm/power/Makefile 1970-01-01 05:30:00.000000000 +0530 +1 -0
@@ -0,0 +1 @@ +obj-$(CONFIG_HIBERNATION) += cpu.o swsusp.o suspend.o
arch/arm/power/suspend.c 2009-06-29 15:34:04.000000000 +0530 renamed from arch/arm/power/suspend.c 1970-01-01 05:30:00.000000000 +0530 +29 -0
@@ -0,0 +1,29 @@ +/* + * Suspend support specific for ARM - temporary page tables + * + * Distribute under GPLv2 + * + * Copyright (c) 2006 Rafael J. Wysocki <[email protected]> + */ + +#include <linux/suspend.h> +#include <linux/bootmem.h> + +#include <asm/system.h> +#include <asm/page.h> +#include <asm/pgtable.h> + +/* References to section boundaries */ +extern const void __nosave_begin, __nosave_end; + + +/* + * pfn_is_nosave - check if given pfn is in the 'nosave' section + */ + +int pfn_is_nosave(unsigned long pfn) +{ + unsigned long nosave_begin_pfn = __pa_symbol(&__nosave_begin) >> PAGE_SHIFT; + unsigned long nosave_end_pfn = PAGE_ALIGN(__pa_symbol(&__nosave_end)) >> PAGE_SHIFT; + return (pfn >= nosave_begin_pfn) && (pfn < nosave_end_pfn); +}
arch/arm/power/swsusp.S 2009-07-07 16:08:33.000000000 +0530 renamed from arch/arm/power/swsusp.S 1970-01-01 05:30:00.000000000 +0530 +447 -0
447 lines not on this page · raw message
.config_mindrivers 2009-06-30 11:05:16.000000000 +0530 renamed from .config_mindrivers 1970-01-01 05:30:00.000000000 +0530 +1211 -0
1,211 lines not on this page · raw message
drivers/mmc/core/core.c 2009-07-09 09:55:43.000000000 +0530 renamed from drivers/mmc/core/core.c 2009-07-08 12:15:46.000000000 +0530 +3 -2
@@ -619,8 +619,8 @@ void mmc_detect_change(struct mmc_host * WARN_ON(host->removed); spin_unlock_irqrestore(&host->lock, flags); #endif - - mmc_schedule_delayed_work(&host->detect, delay); + mmc_rescan(&host->detect.work); + //mmc_schedule_delayed_work(&host->detect, delay); } EXPORT_SYMBOL(mmc_detect_change);
@@ -688,6 +688,7 @@ void mmc_rescan(struct work_struct *work mmc_bus_put(host); } } +EXPORT_SYMBOL(mmc_rescan); void mmc_start_host(struct mmc_host *host) {
drivers/mmc/host/omap_hsmmc.c 2009-07-09 10:14:46.000000000 +0530 renamed from drivers/mmc/host/omap_hsmmc.c 2009-07-08 12:15:46.000000000 +0530 +4 -1
@@ -139,6 +137,8 @@ static int bytec; #endif +extern void mmc_rescan(struct work_struct *); + struct mmc_omap_host { struct device *dev; struct mmc_host *mmc;
@@ -1398,7 +1395,8 @@ static int __init omap_mmc_probe(struct platform_set_drvdata(pdev, host); mmc_add_host(mmc); - + cancel_delayed_work(&mmc->detect.work); + mmc_rescan(&mmc->detect.work); return 0; err:
include/asm-arm/page.h 2009-06-30 11:26:56.000000000 +0530 renamed from include/asm-arm/page.h 2009-06-30 14:29:37.000000000 +0530 +2 -0
@@ -178,6 +178,8 @@ typedef unsigned long pgprot_t; #include <asm/memory.h> +#define __pa_symbol(x) __pa(RELOC_HIDE((unsigned long)(x),0)) + #endif /* !__ASSEMBLY__ */ #define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC | \
include/asm-arm/suspend.h 2009-06-30 11:14:10.000000000 +0530 renamed from include/asm-arm/suspend.h 2009-06-30 14:29:37.000000000 +0530 +77 -0
81 lines not on this page · raw message
kernel/power/disk.c 2009-06-30 11:14:50.000000000 +0530 renamed from kernel/power/disk.c 2009-06-30 14:29:37.000000000 +0530 +1 -0
@@ -21,6 +21,7 @@ #include <linux/console.h> #include <linux/cpu.h> #include <linux/freezer.h> +#include <asm/suspend.h> #include "power.h"
kernel/power/Kconfig 2009-06-30 11:10:36.000000000 +0530 renamed from kernel/power/Kconfig 2009-06-30 14:29:37.000000000 +0530 +1 -1
@@ -99,7 +99,7 @@ config SUSPEND config HIBERNATION_UP_POSSIBLE bool - depends on X86 || PPC64_SWSUSP || PPC32 + depends on X86 || PPC64_SWSUSP || PPC32 || ARM depends on !SMP default y
Quoted 60 lines
-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Peter Tseng
Sent: Monday, May 03, 2010 10:41 AM
To: Shilimkar, Santosh
Cc: Kevin Hilman; Cliff Brake; [email protected]
Subject: Re: ARM suspend to disk?Quoted 2 lines · Santosh
Quoted 2 lines
-----Original Message-----
From: [email protected] [mailto:linux-omap-[email protected]] On Behalf Of Kevin
Quoted 18 lines
Quoted 18 lines
Hilman
Sent: Saturday, May 01, 2010 3:36 AM
To: Cliff Brake
Cc: Peter Tseng; [email protected]
Subject: Re: ARM suspend to disk?Quoted 10 lines · Cliff Brake
Quoted 6 lines · Kevin Hilman
What do you expect to gain from suspend-to-disk + snapshot boot that you don't already get from suspend-to-RAM using off-mode?
On OMAP, with off-mode enabled, a suspend to RAM puts the entire OMAP into full-chip off, and essentially reboots the ARM when waking up from suspend (or idle) already.
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
What does the resume process look like in off mode? Does the resume pass through the bootloader? If so, are the bits that detects resume from "off" available in U-boot?
No, it does not pass through the boot loader.
In general terms, resume from off-mode is the same to "normal" resume
(from
Quoted 6 lines
Quoted 4 lines
retention) except that some additional state has to be restored before continuing where you left off since the ARM core (as well as most the OMAP itself) was turned off.
On suspend to disk topic, Raghu under Romit's guidance did a prototype few months back as part of his internship using some of the
earlier
Quoted 2 lines
ARM work. The whole system snapshot was stored to the MMC card and one can take that MMC card on another board and continue from where it was
suspended.
Quoted 3 lines
We should have these patches somewhere.
It would be interesting to see these. Are you able to find these patches somewhere?
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html