On Thu, Jun 09, 2011 at 10:23:07PM +0530, Santosh Shilimkar wrote:
> On 6/9/2011 10:10 PM, Russell King - ARM Linux wrote:
>> On Thu, Jun 09, 2011 at 09:57:06PM +0530, Santosh Shilimkar wrote:
>>> On 6/9/2011 9:10 PM, Russell King - ARM Linux wrote:
>>>> On Thu, Jun 09, 2011 at 04:30:08PM +0100, Frank Hofmann wrote:
>>>>> Btw, when testing this I found that generic cpu_suspend seems to be just
>>>>> fine for OMAP3; the OMAP platforms though do not at this time use the
>>>>> generic cpu_suspend/resume for sleep, is it planned to change that ?
>>>>
>>>> That's because OMAP was doing changes to their sleep code while I was
>>>> consolidating the sleep code, and although I asked several times that
>>>> the OMAP folk should participate in this effort, but evidentally I was
>>>> unsuccessful in achieving anything in that direction.
>>>
>>> Agreed but the situation at that point was the code was not at
>>> all in convertible position. Looking at your below comment,
>>> it's still not :)
>>
>> Well, I had a look before posting this reply, and ran away from it.
>> I've gone back to it several times since, and got a similar reaction.
>>
>> I seem to remember that it looked _more_ convertable when I looked at
>> it when doing the generic suspend/resume support - I could see a nice
>> simple way to pull out the saving and just leave the PLL resume stuff
>> in SRAM.
>>
>> I'm now convinced that if I try to convert it use the generic support,
>> it will end up being a horrible broken mess.
>
> I must admit that I had same impression when I started looking at it.
>
> Few provisions are necessary for OMAP which I can think of are:
> 1. WFI loop should be made a seperate function so that it can pushed
> on SRAM which is must for OMAP3.
If you look at the generic cpu suspend, it sits in the suspend path.
Once cpu_suspend() has been called, it will return as normal and you
can then do whatever you require to place the system into suspend -
including calling out to a function in WFI.
> 2. A callback before WFI to implement the Errata WA's
"WA's" ?
> 3. Avoid direct write to AUXCTRL in generic suspend code.
This is the only problematical one that I can see. We need to restore
this on systems running in secure mode. What we could do is rather than
writing to the register, read it first and compare its value with what
was saved to see whether we need to write it.
Then, if platforms run in non-secure mode, they are responsible for
restoring that register back to its pre-suspend value before their
assembly calls cpu_resume().
> 4. Before MMU is enabled in resume a callback to restore
> secure register, setup auxctrl etc.
You can do this before your assembly calls cpu_resume().
> Additionally the L2 cache handling isn't part of
> these common suspend hooks.
L2 cache handling can't fit into the generic code - it doesn't really
belong there either. It needs to be in the parent or hooked into the
syscore_ops stuff as I've said previously.
So:
ENTRY(my_soc_suspend)
stmfd sp!, {r4 - r12, lr}
ldr r3, =resume
bl cpu_suspend
/*
* Insert whatever code is required here for suspend
* eg, save secure mode, then jump to sram to call WFI function
*/
resume:
ldmfd sp!, {r4 - r12, pc}
ENDPROC(my_soc_suspend)
ENTRY(my_soc_resume)
/*
* Insert whatever other code is required to be run before resume
* eg, WFI function returns to this symbol after DDR becomes
* accessible. restore secure mode state
*/
b cpu_resume
ENDPROC(my_soc_resume)
What makes it far more complicated in the OMAP case is all that "is l1 state
lost? is l2 state lost?" stuff.
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
