What is the proper Linux suspend / resume kernel reentry point when the processor is powered down and back up

[victorascroft@gmail.com (victorascroft at gmail.com)]

On 15-09-02 15:51:57, John McCaskill wrote:
> I am working on expanding the suspend and resume capability for Linux
> running on a Xilinx Zynq Soc that has dual ARM A9s using the Xilinx 2014.4
> PetaLinux distribution that uses the 3.17 kernel.
> 
> The distribution currently supports suspend and resume without removing
> power to the processors. I am working on expanding the support to include
> removing power to the processors while the DDR memory is in self refresh
> mode, then performing a warm boot and having the first stage boot loader
> (FSBL) hand control back to the Linux kernel in the correct spot to continue
> with the resume process.
> 
> I am looking for what routine to have the first stage boot loader call. I
> think it might be cpu_resume in arch/arm/kernel/sleep.S, but I am not sure
> and would like to verify that it is the correct routine to be calling.
> 
> I am jumping to this from the FSBL after a suspend and warm boot, and single
> stepping through the code in a debugger. It gets to the end of this routine,
> but the debugger looses connection near the end of that routine shortly
> after this instruction is executed:  ARM(	ldmia	r0!, {r1, sp, pc}
> )
> 
> In an effort to see if this is the correct entry point, I have modified pm.c
> in arch/arm/mach-zynq.c to call soft_restart(virt_to_phys(cpu_resume)) just
> after the resume has happened in the case where the processors are not
> powered off, but are woken back up with an interrupt. The soft_restart
> routine turns off the MMUs and clears the caches, and I am using it to get
> the processors into a similar state as to what they would be in if they had
> been power cycled. The cpu_resume routine expects to be called with cache
> and MMU off. This test mostly works, and gets much further than calling
> cpu_resume from the FSBL. It gets out of assembly code, and back into C, and
> is printing messages. The cpu_resume routine expects to be called with cache
> and MMU off.
> 
> I have read the Documentation/power/devices.txt file, and anything else I
> could find.
> 
> I have already done a version of this that uses the no OS flow to put the
> DDR into self refresh and power cycle the processors, and tested it on
> hardware. That flow does not use virtual memory.
> 
> I have looked for other code that does this, but since the code performing
> the warm boot is device firmware and not kenel code I have not found an
> example yet.
> 
> Is cpu_resume the correct renentry point for resuming after a suspend?
> 
> Can anyone point me to an example I can look at?

Some of the suspend resume stuff is very specific to SoC's. For example,
look at arch/arm/mach-imx/pm-imx6.c. What and how exactly to do it depends
on the SoC in question. For example, which all power domains to take care
of, which clocks to bring up how and when and such. Also look at suspend-
imx6.S .

If you want to trace the functions called in suspend resume process, enable
"Power Management Debug support" under "Power management options" when you
run menuconfig.

After enabling them, you also to need to have "initcall_debug" in bootargs.

This should then print out a nice list of all functions called when suspend
resume happens.

- Sanchayan.