[PATCH 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Bedia, Vaibhav]

Hi Santosh, Kevin

On Tue, Nov 06, 2012 at 03:22:16, Shilimkar, Santosh wrote:
[...]

> >> +
> >> +/*
> >> + * This a subset of registers defined in drivers/memory/emif.h
> >> + * Move that to include/linux/?
> >> + */
> >
> > I'd probably suggest just moving the register definitions you
> > need into <plat/emif_plat.h> so they can be shared with the driver.
> >
> > Also, the EMIF stuff would benefit greatly from using symbolic defines
> > for the values being written.  Probably having those in
> > <plat/emif_plat.h> would also help out here.
> >
> > Or, maybe the EMIF driver can provide some self-contained stubs that can
> > be copied to OCP RAM for the functionality needed here?
> >
> > Santosh, what do you think of that?
> >
> Thats what I mentioned in my comment. I also don't know why such a bad
> hardware choice was made when we have perfectly working EMIF IP across
> low power states. Even the self refresh control is managed inside
> hardware upon idle.  My guess is DDR self-refresh might be the reason
> to use OCMC RAM.
> 
> In either case, Keeping EMIF changes separate as part of EMIF 
> driver/platform code is right way to go about it. May be the
> disable_selfrefresh() might need to kept in assembly files since it 
> needs to be running from SRAM but rest need not be part of
> PM code.
> 


In the suspend path we do lot of I/O manipulations to lower final power
number which must be done after the external memory has gone into
self-refresh. So, these steps will have to be done from code in OCMC RAM. 

Other than saving the EMIF configuration the other thing that we do during
suspend from assembly is to put the PLLs in bypass. We could possibly move
the DISP PLL bypass to C code. MPU PLL is another candidate but this might
add in more delays in the suspend and abort sequence (I don't have any
delay numbers to justify this right now)

The resume path undoes the I/O manipulations and then restores the EMIF
configuration all of which I think is necessary before we can jump back to
external memory.

So, I think we'll have just the EMIF context save and possibly the PLL
bypass for DISP PLL during suspend that we can move out of assembly.

Coming to point of sharing the EMIF register definitions, with the recent
changes to move around the header files out of plat-omap, is it ok to
add in the required offsets and related bit-field definitions from
the EMIF driver to plat-omap?

Regards,
Vaibhav