summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2/sram.h
AgeCommit message (Collapse)Author
2015-10-14ARM: OMAP3: clock: remove un-used core dpll re-program codeTero Kristo
Remove the OMAP3 core DPLL re-program code, and the associated SRAM code that does the low-level programming of the DPLL divider, idling of the SDRAM etc. This code was never fully implemented in the kernel; things missing were driver side handling of core clock changes (they need to account for their functional clock rate being changed on-the-fly), and the whole framework required for handling this. Thus, there is not much point to keep carrying the low-level support code either. Signed-off-by: Tero Kristo <t-kristo@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-09-18ARM: OMAP4+: Remove static iotable mappings for SRAMRajendra Nayak
In order to handle errata I688, a page of sram was reserved by doing a static iotable map. Now that we use gen_pool to manage sram, we can completely remove all of these static mappings and use gen_pool_alloc() to get the one page of sram space needed to implement errata I688. omap_bus_sync will be NOP until SRAM initialization happens. Suggested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-09-18ARM: OMAP4+: Move SRAM data to DTRajendra Nayak
Use drivers/misc/sram.c driver to manage SRAM on all DT only OMAP platforms (am33xx, am43xx, omap4 and omap5) instead of the existing private plat-omap/sram.c Address and size related data is removed from mach-omap2/sram.c and now passed to drivers/misc/sram.c from DT. Users can hence use general purpose allocator apis instead of OMAP private ones to manage and use SRAM. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-31ARM: OMAP: Split sram.h to local headers and minimal shared headerTony Lindgren
Most of the defines are specific to omap1 and omap2+, and should be in the local headers. Only minimal function prototypes need to be shared. As discussed on linux-arm-kernel, we want to avoid relative includes for the arch/arm/*omap* shared code: http://www.spinics.net/lists/linux-omap/msg80520.html So this patch re-adds a minimal plat/sram.h. The new plat/sram.h must not be included from drivers, that will break build for omap2+ CONFIG_MULTIPLATFORM. Note that this patch temporarily adds two more relative includes; Those will be removed in the following patch. Signed-off-by: Tony Lindgren <tony@atomide.com>