[RFC PATCH 05/14] arm64: kernel: cpu_{suspend/resume} implementation

[Lorenzo Pieralisi]

On Fri, Aug 30, 2013 at 06:27:56PM +0100, Catalin Marinas wrote:
> On Wed, Aug 28, 2013 at 12:35:57PM +0100, Lorenzo Pieralisi wrote:
> > Kernel subsystems like CPU idle and suspend to RAM require a generic
> > mechanism to suspend a processor, save its context and put it into
> > a quiescent state. The cpu_{suspend}/{resume} implementation provides
> > such a framework through a kernel interface allowing to save/restore
> > registers, flush the context to DRAM and suspend/resume to/from
> > low-power states where processor context may be lost.
> > 
> > Different SoCs might require different operations to be carried out
> > before a power down request is committed. For this reason the kernel
> > allows the caller of cpu_suspend to provide a function pointer (fn in
> > the cpu_suspend prototype below),
> > 
> > int cpu_suspend(unsigned long arg, int (*fn)(unsigned long));
> > 
> > called suspend finisher, that is executed after the context is saved and
> > flushed to DRAM, so that SoC/platform specific operations can be carried out
> > before issuing power down commands.
> > 
> > Context memory is allocated on the stack, whose address is stashed in a
> > per-cpu variable to keep track of it and passed to core functions that
> > save/restore the registers required by the architecture.
> > 
> > Even though, upon successful execution, the cpu_suspend function shuts
> > down the suspending processor, the warm boot resume mechanism, based
> > on the cpu_resume function, makes the resume path operate as a
> > cpu_suspend function return, so that cpu_suspend can be treated as a C
> > function by the caller, which simplifies coding the PM drivers that rely
> > on the cpu_suspend API.
> > 
> > Upon context save, the minimal amount of memory is flushed to DRAM so
> > that it can be retrieved when the MMU is off and caches are not searched.
> > 
> > The suspend finisher, depending on the required operations (eg CPU vs
> > Cluster shutdown) is in charge of flushing the cache hierarchy either
> > implicitly (by calling firmware implementations like PSCI) or explicitly
> > by executing the required cache maintainance functions.
> 
> As we discussed, I would like the finisher argument to cpu_suspend() to be
> removed and just use the default cpu_operations.cpu_suspend (currently
> smp_operations) which is populated from DT and uses PSCI as the default
> finisher. The cpuidle drivers can still pass arguments that would make
> their way into the PSCI CPU_SUSPEND call (like how deep to go) but I
> would like to avoid each cpuidle driver implementing a finisher that
> does the PSCI call.
> 
> If PSCI is not available, the cpuidle driver can register a different
> cpu_suspend method.

This makes perfect sense, I will update the code as soon as cpu_operations
struct and suspend method are put in place in generic kernel code.

Thanks,
Lorenzo