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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
