summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2/sram.h
AgeCommit message (Collapse)AuthorFilesLines
2022-04-22ARM: omap: un-merge plat/sram.cArnd Bergmann1-1/+4
The sram initialization code is the only shared omap1/2 code that is not a standalone driver, but it is very short. Having two copies of this code means some duplication of the sources, but actually saves object code size as it can be inlined better. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-06-19treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner1-4/+1
Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-14ARM: OMAP3: clock: remove un-used core dpll re-program codeTero Kristo1-14/+0
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 Nayak1-6/+0
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 Nayak1-1/+0
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 Lindgren1-0/+83
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>