On Tue, 24 May 2011, wang leileis wrote: > Hi Frank, > > > I find that you submit the patch to implement suspend to disk on imx. > patch: http://patchwork.ozlabs.org/patch/96977/ > But I don't find your baseline code of this project. Where get the > baseline code from ? cc:'ing the mailing lists because this is relevant information for anyone who wants to experiment with this code ... and I admit to being too lazy to write this up multiple times ;-) The patch you link to above is not explicitly baselined; apart from having to adjust line numbers in arch/arm/Kconfig and arch/arm/kernel/Makefile the patch is quite generic and I've used it in kernels between 2.6.28 / Android Eclair, 2.6.32 / Android Froyo, 2.6.35 and compiled for 2.6.37-39. What kernel are you currently using ? > > I want to learn about the background of this patch(hardware, kernel > version, os ?) The patch doesn't provide hibernation support on imx - it just provides the generic ARM framework glue. If you try to compile it as-is, you'll notice that nothing happens, the compiler won't even look at the two new sourcefiles. That's because to get the code compiled, you both need a "CONFIG_HIBERNATION=y" in your defconfig file as well as compile for a platform that has ARCH_HIBERNATION_POSSIBLE set. My patch that you linked to above doesn't declare the latter anywhere, default of the value is 'n'. That is because you also need a machine-type specific supplement - something that provides: - the __save/__restore_processor_state hooks for the specific machine / platform type - a "select ARCH_HIBERNATION_POSSIBLE" in the Kconfig for that platform Only when you've got both the base patch above plus these "enablers" can you create a kernel that'll allow suspend-to-disk. Where to get that / how to create it: Read the following thread on the arm-kernel mailing list: http://lists.arm.linux.org.uk/lurker/thread/20110520.123937.760c528f.en.html#i20110520.123937.760c528f particularly the attachments of this message: http://lists.arm.linux.org.uk/lurker/message/20110520.123937.760c528f.en.html they provide these hooks for Samsung S5P64XX and TI OMAP3 - for pre-2.6.38 kernels. As said in that message, that's "for illustration". It works on OMAP3, and if you have a pre-2.6.38 kernel you can probably find the s3c_cpu_save() that the S5P64xx patch modifies. ========================================================================= NOTE: ========================================================================= __save_processor_state / __restore_processor_state: This part of the ARM hibernation support is not finalized. It needs a bit of work if you want to use it on anything else but OMAP3 / s5p64xx at the moment, and even on those the diffs referenced above don't cleanly patch into just about any kernel. That's why "illustrative" - understand them and then apply likewise changes to whatever exact sources you use. These diffs give instructions what to do but aren't explicit about how exactly to do that. ========================================================================= I understand the "baseline" question very well ... let's just say the patch that you linked to (what I posted yesterday) doesn't really require baselining against anything, as it's applicable to anything 2.6.28+ as good as unmodified. But the implementation of __save/__restore_processor_state is currently very kernel-rev-specific ... For 2.6.39+ kernels, the __save/__restore_processor_state hooks would, in many cases, be directly done by arch/arm/mm/proc-*.S as long as those have a cpu*_do_suspend() function. For those that exist, might try to add the following to swsusp.S: #include <asm/glue-proc.h> ENTRY(__save_processor_state) stmfd sp!,{r4-r11,lr} bl cpu_do_suspend ldmfd sp!,{r4-r11,lr} ENDPROC(__save_procesor_state) ENTRY(__restore_processor_state) stmfd sp!,{r4-r11,lr} bl cpu_do_resume ldmfd sp!,{r4-r11,lr} ENDPROC(__restore_processor_state) That _should_ do the job. Mind you, it's quite difficult for me to test that, as I only have omap3 and smdk64xx boards, and not currently got a 2.6.39 kernel running on any of them. That part, as indicated, is still work-in-progress. > And How to test this patch ? Can you provide some test cases ? The following is an example for "normal" swsusp, not tuxonice; for the latter, please post on the tuxonice-devel mailing list and/or read the docs about differences. When you've got the ARM hibernation support patch in, and have created a __save/__restore_processor_state() pair for your SoC plus the "select ARCH_HIBERNATION_POSSIBLE" switch in the ARCH_... Kconfig declaration, you simply: - add to your ..._defconfig file: CONFIG_SWAP=y CONFIG_PM=y CONFIG_HIBERNATION=y (you need these three but the first two might already be set) - do a "make mrproper; make ..._defconfig" in the kernel toplevel - run "make -j8 all" Then load that kernel as normal. You should now, when you boot it up and have sysfs mounted, find the following: # ls -l /sys/power -rw-rw---- radio system 4096 2000-01-04 01:55 state -rw-r--r-- root root 4096 2000-01-04 20:01 pm_test -rw-r--r-- root root 4096 2000-01-04 20:01 disk -rw-r--r-- root root 4096 2000-01-04 20:01 resume -rw-r--r-- root root 4096 2000-01-04 20:01 image_size At this point, you can test whether device suspend/resume works simply by doing: # echo disk >/sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.02 seconds) done. Stopping normal filesystems. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. PM: Preallocating image memory... done (allocated 33409 pages) PM: Allocated 133636 kbytes in 2.59 seconds (51.59 MB/s) Suspending console(s) (use no_console_suspend to debug) [ ... at this point there's a little "silence" ... ] PM: Creating hibernation image: PM: Need to copy 33410 pages PM: Hibernation image created (33410 pages copied) PM: Cannot find swap device, try swapon -a. Restarting all filesystems ... Restarting tasks ... done. If you've got problems with drivers not suspending or hanging on wakeup, it'll never make it past the [ ... ] section; try booting with "debug no_console_suspend loglevel=9" in that case, and find out which driver is stuck ... This needs to work _first_. It's a simple test whether all your drivers suspend/resume sufficiently well. If all that works, then create yourself a swap device. How you accommodate that on your specific device I can't say, any MMC partition would do that you have spare and that you can run "mkswap" on (busybox would provide both swapon and mkswap - suggest you use that). When you have that, use "swapon" to activate it, in which case you get: # swapon /dev/block/mmcblk0p4 Adding 218040k swap on /dev/block/mmcblk0p4. Priority:-1 extents:1 across:218040k SS When you try the above again now, it'll write the image out and stop the system: # echo disk > /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.01 seconds) done. Stopping normal filesystems. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. PM: Preallocating image memory... done (allocated 33410 pages) PM: Allocated 133640 kbytes in 2.66 seconds (50.24 MB/s) PM: Creating hibernation image: PM: Need to copy 30304 pages PM: Hibernation image created (30304 pages copied) Suspending console(s) (use no_console_suspend to debug) [ ... at this point there's a little "silence" ... ] PM: Saving image data pages (30334 pages) ... done PM: Wrote 121336 kbytes in 23.88 seconds (5.08 MB/s) PM:Power down. System halted. PM: Please power down manually When you reboot, you _must_ pass the appropriate "resume=..." command line argument to the kernel so that it finds the resume image. Depending on how your system is configured, that might be the _same_ as you used above, or it might be without the .../block/... in-between; check your system docs as to what you have. Boot up, and you'll see a resume attempt like: [ ... normal kernel bootup messages ... ] PM: Checking image partition /dev/mmcblk0p4 PM: Resume from partition 179:4 PM: Checking hibernation image. PM: Signature found, resuming PM: Basic memory bitmaps created PM: Preparing processes for restore. Freezing user space processes ... (elapsed 0.00 seconds) done. Stopping normal filesystems. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. PM: Loading image data pages (30334 pages) ... done PM: Read 121336 kbytes in 8.60 seconds (14.10 MB/s) Suspending console(s) (use no_console_suspend to debug) [ ... at this point there's a little "silence" ... ] Restarting all filesystems ... Restarting tasks ... done. If it works, you'll get your shell (and whatever else the board was running at the time) back at this point. The most critical bits happen during the [ ... ] sections, as this is when the device state is suspended, the image is restored and actual resume happens. If you enable power management debugging (CONFIG_PM_DEBUG, and boot with "debug loglevel=9 no_console_suspend" parameters) you'll see a lot of messages from the PM subsystems during that time about its activities. Good luck! FrankH. > > > > > All the best, > Ryan > _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
