On Wed, Apr 11, 2012 at 03:35:53PM -0700, Kevin Hilman wrote: > "Mark A. Greer" <mgreer@xxxxxxxxxxxxxxx> writes: > > > From: "Mark A. Greer" <mgreer@xxxxxxxxxxxxxxx> > > > > The typical SDRAM Controller Subsystem module (SDRC) > > on TI OMAP3 devices has two submodules: the SDRAM Memory > > Scheduler (SMS) submodule, and the SDRC submodule--the > > 'SDRC' acronym/term is overloaded. The am35x family of > > devices is different in that it has an EMIF4 submodule > > instead of an SDRC submodule. The SMS submodules are > > similar, though. > > > > The difference in SDRC/EMIF4 submodules is important because > > omap34xx_cpu_suspend() will ultimately access the submodule's > > registers and the register sets are different. To support > > the EMIF4 submodule, add the omap3_emif4_do_wfi() routine which > > roughly does for the EMIF4 submodule what omap3_do_wfi() does > > for the SDRC submodule. This requires omap34xx_cpu_suspend() > > to use a pointer set up in omap_push_sram_idle() so that it > > jumps to the correct omap3*_do_wfi() routine in either SDRAM > > or SRAM. > > > > Credits: arch/arm/mach-omap2/sleep3517.S in TI's am35x SDK > > (05.03.02.00) which appears to be authored by Ranjith Lohithakshan > > <ranjithl@xxxxxx> was used as a reference. > > > > CC: Ranjith Lohithakshan <ranjithl@xxxxxx> > > Signed-off-by: Mark A. Greer <mgreer@xxxxxxxxxxxxxxx> > > Dumb Q: do you actually need to do the EMIF4 self-refresh control from > SRAM? > > The reason I ask is because on OMAP3, we tried going down the path of > not running any of this from SRAM (run it from cache instead.) However, > due to some errata (c.f. wait_sdrc*, wait_dll_* ...), we had to handle > these errata from SRAM. > > Looking at your omap3_emif4_do_wfi, it looks like that's very minimal, > and can probably be prefetched/run from cache. I don't see why it wouldn't work but I haven't tried. I did it the way that I did hoping to fit in with the existing infrastructure as neatly as possible. I'll try out leaving it in cache. Mark -- -- 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
