Thread (18 messages) flat view 18 messages, 7 authors, 2013-10-08
STALE4689d

Revision v1 of 12 in this series.

Revisions (12)
  1. v1 [diff vs current]
  2. v1 current
  3. v1 [diff vs current]
  4. v1 [diff vs current]
  5. v2 [diff vs current]
  6. v2 [diff vs current]
  7. v2 [diff vs current]
  8. v2 [diff vs current]
  9. v2 [diff vs current]
  10. v1 [diff vs current]
  11. v1 [diff vs current]
  12. v1 [diff vs current]

[PATCH 2/2] ARM: OMAP4+: Move SRAM data to DT

From: Sekhar Nori <hidden>
Date: 2013-08-27 11:23:51
Also in: linux-omap

On Tuesday 27 August 2013 03:41 PM, Rajendra Nayak wrote:
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 implementation.

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.

Currently there are no users on SRAM on these platfoms.

Signed-off-by: Rajendra Nayak <redacted>
Nice getting rid of code.
quoted hunk ↗ jump to hunk
diff --git a/arch/arm/mach-omap2/sram.h b/arch/arm/mach-omap2/sram.h
index ca7277c..3f83b80 100644
--- a/arch/arm/mach-omap2/sram.h
+++ b/arch/arm/mach-omap2/sram.h
@@ -80,4 +80,3 @@ static inline void omap_push_sram_idle(void) {}
 #else
 #define OMAP4_SRAM_PA		0x40300000
 #endif
-#define AM33XX_SRAM_PA		0x40300000
I guess OMAP4_SRAM_PA is left in the code to take care of errata I688?
How about removing the iotable entry for SRAM on OMAP4 and converting
omap_barriers_init() to use the gen_pool API instead of passing an
incremented address to DT?

SRAM driver is a postcore initcall so I think you it will be ready
before first WFI hits (which is when the errata triggers).

Thanks,
Sekhar
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help