"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. Kevin -- 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
