[RFC PATCH v5] ARM hibernation / suspend-to-disk (fwd)

Frank Hofmann frank.hofmann at tomtom.com
Mon Jun 13 08:40:21 EDT 2011



On Mon, 13 Jun 2011, Russell King - ARM Linux wrote:

> On Mon, Jun 13, 2011 at 01:04:02PM +0100, Frank Hofmann wrote:
>>   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)
>
> Nothing has that - because you can't execute that ldmfd after the call
> to cpu_suspend returns.  I don't think you've understood what I said on
> that subject in the previous thread.
>

Sorry typo.

Missed the critical lines:

ENTRY(acmeSoC_cpu_suspend)
 	stmfd	sp!, {r3-r12,lr}
 	ldr	r3, =resume_mmu_done
 	[ load r1 with v:p, whichever way - either you or your caller ]

 	bl cpu_suspend

 	[ ... do whatever low power entry stuff ... ]

 	[ function effectively ENDS HERE ... ]

resume_mmu_done:
 	ldmfd	sp!, {r3-r12,pc}



That's the key bits. DO NOTHING OF RELEVANCE BEFORE cpu_suspend AND DO 
NOTHING APART FROM ENTERING LOW POWER AFTERWARDS.


I _have_ understood what you've said. cpu_suspend is not made for this 
purpose, and hence I'm not claiming it should be. The use of it to create 
the core state snapshot for hibernation is merely something that, right 
now, works _by accident_ (or sheer luck, if you want to say that) rather 
than by intent / design.

Since there _is no design_ for what should work / how it should work in 
this context, I'm leaving it as-is, merely stating the constraints. Roll 
your own if you need / want to.


Does that clarify ?


FrankH.



More information about the linux-arm-kernel mailing list