Hi, to make one thing clear to start with: This is not a proposal to integrate the hibernation feature into mainline. It's not ripe for that because it's unclear what exactly the differences are between what the hibernation / S2RAM codepaths have to do, and/or how much code sharing between these codepaths is advisable. Therefore, I'm merely putting this out as-is as a reference / base for those who want to do their own experiments with the feature. Prerequisites: * The patch requires a working cpu_reset(); for v6/v7, that's in Will Deacon's patch series from last week. * It also requires being able to take the address of cpu_reset and on MULTI_CPU configs therefore, again see Will Deacon's patch series. * It uses on cpu_suspend() / cpu_resume(), therefore a recent-enough kernel (or a port of those to whatever you're using) is required. Important / Limitations: A) For platforms that currently use cpu_suspend/cpu_resume in their s2ram codepaths AND DO NOTHING ELSE BEFORE AND NOTHING ELSE AFTER THAT BUT TO "ENTER LOW POWER", the way the hibernation state snapshot for the CPU core is done by this patch is sufficient. To make it clear: IF AND ONLY IF your suspend(-to-ram) func looks like: ENTRY(acmeSoC_cpu_suspend) stmfd sp!, {r4-r12,lr} ldr r3, resume_mmu_done bl cpu_suspend resume_mmu_done: ldmfd sp!, {r3-r12,pc} ENDPROC(acmeSoC_cpu_suspend) then this patch is ok to provide hibernation support for your CPU core. In all other cases, item B). IN ALL CASES, read item C) below; there's more than the core to the SoC. B) If there's any cpu-specific / SoC-specific state that needs (re)init over a suspend-to-disk/resume-from-disk cycle, this patch is incomplete because it provides no hooks/code for that. This is the case e.g. for "secure" SoCs that have different sets of control registers and/or different CR reg access patterns. It's also the case e.g. for SoCs with L2 caches as the activation sequence there is SoC-dependent; a full off-on cycle for L2 is not done by the hibernation support code. It's also the case if the SoC requires steps on wakeup _before_ the "generic" parts done by cpu_suspend / cpu_resume can work correctly. (OMAP is an example of such a SoC; the patch "works" on OMAP in the sense that it gets you a non-secure OMAP back from hibernation but as mentioned, your mileage may vary; I for example don't know what the consequences of not disabling / reenabling the L2 cache over cpu_reset are) C) The current low-power handling may perform SoC-specific tasks such as GPIO state handling, which is currently also not addressed by this patch; the assumption is rather that device suspend/resume deals with this. That is not guaranteed to be complete / sufficient - if your SoC and/or your device drivers have particular needs in this area, you can put hooks performing these actions into save_/restore_processor_state(). D) If you wish to extend this to a SoC for which the generic CPU core hooks (i.e. what cpu_suspend/resume provide) are either insufficient or unavailable, hook your own state snapshot mechanism into the places where this code currently calls cpu_suspend and cpu_resume. The main assumption by the assembly code within swusp_arch_resume() is that __swsusp_arch_restore_image() returns to its caller with the stack restored - how you achieve that is up to you, the patch as-is does it by cpu_reset(cpu_resume) but your mileage may vary. I will, at this point, not send further iterations of this patch. I'll answer questions about it though, if there are any. Thanks for all the comments during the previous threads - learned a lot ! Best regards, FrankH. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm