Re: [PATCH 11/12] arm: omap3: am35x: Add do_wfi routine for EMIF4 submodules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
> > ( 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
> 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.

To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux