13 Jan, 2012
1 commit
-
Several platforms are now using the memblock_alloc+memblock_free+
memblock_remove trick to obtain memory which won't be mapped in the
kernel's page tables. Most platforms do this (correctly) in the
->reserve callback. However, OMAP has started to call these functions
outside of this callback, and this is extremely unsafe - memory will
not be unmapped, and could well be given out after memblock is no
longer responsible for its management.So, provide arm_memblock_steal() to perform this function, and ensure
that it panic()s if it is used inappropriately. Convert everyone
over, including OMAP.As a result, OMAP with OMAP4_ERRATA_I688 enabled will panic on boot
with this change. Mark this option as BROKEN and make it depend on
BROKEN. OMAP needs to be fixed, or 137d105d50 (ARM: OMAP4: Fix
errata i688 with MPU interconnect barriers.) reverted until such
time it can be fixed correctly.Signed-off-by: Russell King
09 Dec, 2011
2 commits
-
Allocate the memory to save secure ram context which needs
to be done when MPU is hitting OFF mode.The ROM code expects a physical address to this memory
and hence use memblock APIs to reserve this memory as part
of .reserve() callback. Maximum size as per secure RAM requirements
is allocated.To keep omap1 build working, omap-secure.h file is created
under plat-omap directory.Signed-off-by: Santosh Shilimkar
Acked-by: Jean Pihet
Reviewed-by: Kevin Hilman
Tested-by: Vishwanath BS
Signed-off-by: Kevin Hilman -
On OMAP secure/emulation devices, certain APIs are exported by secure
code. Add an infrastructure so that relevant operations on secure
devices can be implemented using it.While at this, rename omap44xx-smc.S to omap-smc.S since the common APIs
can be used on other OMAP's too.Signed-off-by: Santosh Shilimkar
Acked-by: Jean Pihet
Reviewed-by: Kevin Hilman
Tested-by: Vishwanath BS
Signed-off-by: Kevin Hilman
